From sacadmin Tue Sep 26 08:12:54 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8QFCr1J020004 for ; Tue, 26 Sep 2006 08:12:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k8QFCWHn018378; Tue, 26 Sep 2006 16:12:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6700A3RGXEDV00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Sep 2006 08:12:50 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6700A1KGXECY00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Sep 2006 08:12:50 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8QFCn3d025745; Tue, 26 Sep 2006 09:12:49 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6700C01GOKPG00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Tue, 26 Sep 2006 09:12:49 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6700036GXC8D51@mail-amer.sun.com>; Tue, 26 Sep 2006 09:12:49 -0600 (MDT) Date: Tue, 26 Sep 2006 11:10:56 -0400 From: Stephen Ehring Subject: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions Sender: Stephen.Ehring@sun.com To: Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <45194300.6080109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 669 I am sponsoring this fast tack for myself. The case times out on October 6th, 2006. The documents are in the materials directory at: http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/niu-siu-binding.txt http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/interface-table.txt The case materials serve as the device tree binding for Niagara2's NIU subsystem, and also defines the Machine Description entries. Release Binding: firmware: minor/micro firmware release I'm going to be on vacation for the next three days (9/27 - 9/29) so I won't be able to answer questions (which is why I've extended the normal 1-week timer by three days). thanks, Steve From sacadmin Fri Sep 29 17:14:04 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8U0E3X6022357 for ; Fri, 29 Sep 2006 17:14:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k8U0Dl28003440; Sat, 30 Sep 2006 01:13:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6D00505PZ90Q00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Sep 2006 17:13:57 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6D00C00PZ7XF50@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Sep 2006 17:13:55 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8U0Dt50020571; Fri, 29 Sep 2006 18:13:55 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6D00501PWQRY00@mail-amer.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Fri, 29 Sep 2006 18:13:55 -0600 (MDT) Received: from [129.150.33.49] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6D000EXPZ68DU1@mail-amer.sun.com>; Fri, 29 Sep 2006 18:13:55 -0600 (MDT) Date: Fri, 29 Sep 2006 17:13:55 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45194300.6080109@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: NIU-SW-Stack-Development@sun.com Message-id: <451DB6C3.5030407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 1812 Stephen Ehring wrote: > I am sponsoring this fast tack for myself. The case times out > on October 6th, 2006. > > The documents are in the materials directory at: > > http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/niu-siu-binding.txt > http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/interface-table.txt Few comments/questions. 1. Can we change the "name" property "siu" to be more descriptive such as, "niagara-system-interface" 2. Does "#interrupt-vectors" represent total number of vectors under SIU or under each NIU? I am assuming that it represents total number for EACH NIU, is that correct? Why is this property needed under "siu" and not under "niu"? 3. For NIU, instead of relying on consecutive MAC addresses, why not define a property called "mac-addresses" as an array of integers? This way it does not have to be contiguous starting from the "local- mac-address" property value. The set of addresses can be any value and the number of MAC addresses are the number of properties in the array. 4. In the property names "tx-dma-channels-begin" and "rx-dma-channels-begin" can we change "begin" to "base"? Not sure if the "begin" a proper use to represent the base of the dma channels. 5. Under NIU there is "device-type" property in MD node but not under the device node. Is that correct? Further, why the "device-type" is "mac" and not "network"? 6. Are the properties for Neptune part of this bindings? I am asking since there were some discussions on this with Yuming few weeks back. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Fri Sep 29 17:43:22 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8U0hLsK022551 for ; Fri, 29 Sep 2006 17:43:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k8U0hLe20201; Fri, 29 Sep 2006 17:43:21 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6D00907RC8L200@brm-avmta-1.central.sun.com>; Fri, 29 Sep 2006 18:43:20 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6D001TCRC8Z450@brm-avmta-1.central.sun.com>; Fri, 29 Sep 2006 18:43:20 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8U0hJpB027012; Fri, 29 Sep 2006 18:43:20 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6D00301R3PV400@mail-amer.sun.com> (original mail from Yuming.Chen@Sun.COM); Fri, 29 Sep 2006 18:43:19 -0600 (MDT) Received: from [129.149.2.74] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6D00I4PRC71WS7@mail-amer.sun.com>; Fri, 29 Sep 2006 18:43:19 -0600 (MDT) Date: Fri, 29 Sep 2006 17:43:19 -0700 From: Yuming Dell Chen Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <451DB6C3.5030407@sun.com> Sender: Yuming.Chen@Sun.COM To: Hitendra Zhangada Cc: Firmware Arch , NIU-SW-Stack-Development@Sun.COM Reply-to: Yuming.Chen@Sun.COM Message-id: <451DBDA7.4090904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 3079 Hi Hitu, This NIU/SIU FWARC case does *not* include Neptune because there are too many n2-niu specific items. I need your input about whether or not we need a Neptune FWARC case. All the properties on the Neptune device property list are properties already used by existing NIC cards (such as Cassini based and Ophir based adapters). The only change needed by Neptune is to add "xgf" and "xgc" (stands for 10G fiber and 10G copper) as two new values for the "phy-type" property. Steve's NIU binding also needs "xgf" and "xgc" for phy-type and he already included them in his document. If his case gets approved, then all Neptune properties are covered. Maybe we do not need a Neptune FWARC case at all? Thanks. -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ |\ _|_ Yuming Dell Chen |/ _|_ Sun Microsystems |||_|_| Mailstop202, 7788 Gateway Blvd, Bldg19 |/|_|_| Newark, CA 94560, USA | /|\ W: 510-936-2861 M: 408-390-7740 | /\| \ Yuming.Chen@Sun.com /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Hitendra Zhangada wrote On 09/29/06 05:13 PM,: > Stephen Ehring wrote: > >> I am sponsoring this fast tack for myself. The case times out >> on October 6th, 2006. >> >> The documents are in the materials directory at: >> >> http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/niu-siu-binding.txt >> >> http://sac.sfbay.sun.com/arc/FWARC/2006/556/materials/interface-table.txt >> > > > Few comments/questions. > > 1. Can we change the "name" property "siu" to be more descriptive > such as, > > "niagara-system-interface" > > 2. Does "#interrupt-vectors" represent total number of vectors under SIU > or under each NIU? I am assuming that it represents total number for > EACH NIU, is that correct? > > Why is this property needed under "siu" and not under "niu"? > > 3. For NIU, instead of relying on consecutive MAC addresses, why not > define a property called "mac-addresses" as an array of integers? > This way it does not have to be contiguous starting from the "local- > mac-address" property value. The set of addresses can be any value > and the number of MAC addresses are the number of properties in > the array. > > 4. In the property names "tx-dma-channels-begin" and > "rx-dma-channels-begin" > can we change "begin" to "base"? Not sure if the "begin" a proper > use > to represent the base of the dma channels. > > 5. Under NIU there is "device-type" property in MD node but not under > the device node. Is that correct? Further, why the "device-type" > is "mac" and not "network"? > > 6. Are the properties for Neptune part of this bindings? I am asking > since > there were some discussions on this with Yuming few weeks back. > -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ |\ _|_ Yuming Dell Chen |/ _|_ Sun Microsystems |||_|_| Mailstop202, 7788 Gateway Blvd, Bldg19 |/|_|_| Newark, CA 94560, USA | /|\ W: 510-936-2861 M: 408-390-7740 | /\| \ Yuming.Chen@Sun.com /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From sacadmin Fri Sep 29 21:12:05 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8U4C4N3008028 for ; Fri, 29 Sep 2006 21:12:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k8U4BkE1011482; Sat, 30 Sep 2006 12:12:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6E00I05100HC00@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Sep 2006 21:12:00 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6E00DOY100WG50@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Sep 2006 21:12:00 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8U4BxFA022256; Fri, 29 Sep 2006 21:11:59 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8U4BwjN003899; Fri, 29 Sep 2006 21:11:58 -0700 (PDT) Date: Fri, 29 Sep 2006 21:11:57 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Yuming Dell Chen Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <451DEE8D.5020108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1251 Yuming Dell Chen wrote: > Hi Hitu, > This NIU/SIU FWARC case does *not* include Neptune because there are > too many n2-niu specific items. > I need your input about whether or not we need a Neptune FWARC case. > All the properties on the Neptune device property list are properties > already used by existing NIC cards (such as Cassini based and Ophir > based adapters). The only change needed by Neptune is to add "xgf" and > "xgc" (stands for 10G fiber and 10G copper) as two new values for the > "phy-type" property. Steve's NIU binding also needs "xgf" and "xgc" > for phy-type and he already included them in his document. If his case > gets approved, then all Neptune properties are covered. Maybe we do not > need a Neptune FWARC case at all? Thanks. > Even if you're using all standard propnames and propvals, the project team still needs to file a "device binding", which lists all the properties and values in that node or nodes. You only need to use the short definitions for standard properties, or properties defined in bus bindings (if that's applicable) since you can just reference the other documents for the full definitions. You should be able to find an example if you look at the case list. -David From sacadmin Fri Sep 29 21:20:42 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8U4KgF0008889 for ; Fri, 29 Sep 2006 21:20:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k8U4Kfe00440; Fri, 29 Sep 2006 21:20:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6E00K0F1EF9K00@brm-avmta-1.central.sun.com>; Fri, 29 Sep 2006 22:20:39 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6E001VY1EFYRA0@brm-avmta-1.central.sun.com>; Fri, 29 Sep 2006 22:20:39 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k8U4KdDx008586; Fri, 29 Sep 2006 21:20:39 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8U4KbVd004065; Fri, 29 Sep 2006 21:20:38 -0700 (PDT) Date: Fri, 29 Sep 2006 21:20:37 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Firmware Arch Cc: NIU-SW-Stack-Development@sun.com Message-id: <451DF095.4020206@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 724 Hitendra Zhangada wrote: > Few comments/questions. > > 1. Can we change the "name" property "siu" to be more descriptive such as, > > "niagara-system-interface" Or maybe sun4v-io or something like that? I don't care for either name, to be honest, but I agree that if we can find a suitable generic name for this node we should use one. What does the siu node represent? There's no specification for the address formats of this "bus". I'm not sure what it represents. This probably needs to be in bus binding format, rather than device binding format, with the sections that describe the reg-format for children of this node, etc. What registers are mapped by this node? What's the purpose of this node? -David From sacadmin Fri Sep 29 21:40:42 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8U4eg11010142 for ; Fri, 29 Sep 2006 21:40:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k8U4efe03689; Fri, 29 Sep 2006 21:40:41 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6E00K012BTRL00@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Sep 2006 21:40:41 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6E00D0Z2BTWG90@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Sep 2006 21:40:41 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8U4efJW028038; Fri, 29 Sep 2006 21:40:41 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8U4edge004366; Fri, 29 Sep 2006 21:40:40 -0700 (PDT) Date: Fri, 29 Sep 2006 21:40:39 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Stephen Ehring Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <451DF547.3030109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1012 Hitendra Zhangada wrote: > 4. In the property names "tx-dma-channels-begin" and > "rx-dma-channels-begin" > can we change "begin" to "base"? Not sure if the "begin" a proper use > to represent the base of the dma channels. One possible way to deal with this is to define a property, such as [rt]x-dma-channel-ranges to be one or more pairs of encoded integers, where each pair is defined as {base-channel#, #channels} So if you allocated the first 32 dma channels to a node x, the propval would be {0, 32}. If the next 32 dma channels were allocated to a node y, the propval would be {32, 32}. If you want to keep them separate, I would name them as #[rt]x-dma-channels and [rt]-dma-channel-base (as Hitu suggested) for the base channel number. I think the compound property is more flexible, since it doesn't require one single range of consecutive channel numbers. (things can be reallocated without renumbering other channels in use by other devices, maybe something for the future.) -David From sacadmin Wed Oct 4 09:42:46 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94Ggjgv003756 for ; Wed, 4 Oct 2006 09:42:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k94GeTib007023; Wed, 4 Oct 2006 17:42:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6M00501EF7ZB00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 09:42:43 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6M00EOKEF7H4A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 09:42:43 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k94GggAD028396; Wed, 04 Oct 2006 10:42:43 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6M00301E62F400@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Wed, 04 Oct 2006 10:42:42 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6M001K8EF5Y3O1@mail-amer.sun.com>; Wed, 04 Oct 2006 10:42:42 -0600 (MDT) Date: Wed, 04 Oct 2006 12:40:48 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <451DB6C3.5030407@sun.com> Sender: Stephen.Ehring@sun.com To: Hitendra Zhangada Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <4523E410.6010604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 6302 Hitendra Zhangada wrote: > Few comments/questions. > > 1. Can we change the "name" property "siu" to be more descriptive such as, > > "niagara-system-interface" > Since this is specific to niagara2, the best generic name I can think of is 'niagara2-system-interface'. Does the NIU team have any other suggestions? > 2. Does "#interrupt-vectors" represent total number of vectors under SIU > or under each NIU? I am assuming that it represents total number for > EACH NIU, is that correct? > #interrupt-vectors is the total for all NIU children (which is why it is in the SIU node and not the NIU node). > Why is this property needed under "siu" and not under "niu"? > > 3. For NIU, instead of relying on consecutive MAC addresses, why not > define a property called "mac-addresses" as an array of integers? > This way it does not have to be contiguous starting from the "local- > mac-address" property value. The set of addresses can be any value > and the number of MAC addresses are the number of properties in the > array. This solution was discussed, but the NIU mac-addresses are allocated per XAUI card (NIU leaf), and so they will always be a contiguous block. If we used a list, each MAC address would required 2 32 bit integers, and there are 16 mac addresses available for use, which means that would require a property that is 128 bytes long. > > 4. In the property names "tx-dma-channels-begin" and > "rx-dma-channels-begin" > can we change "begin" to "base"? Not sure if the "begin" a proper use > to represent the base of the dma channels. I like DavidK's idea about having a ranges-like propery to allow for possible noncontiguous allocation of channels. I'll update the binding accordingly. > 5. Under NIU there is "device-type" property in MD node but not under > the device node. Is that correct? Further, why the "device-type" > is "mac" and not "network"? Looking at how the current device-tree is built, there is not 'device-type'. I assume that means that Solaris is not using it. Can someone on the NIU Solaris team comment? I don't think the Solaris driver is extracting it from the MD, so maybe we can remove that from the MD node. > 6. Are the properties for Neptune part of this bindings? I am asking > since > there were some discussions on this with Yuming few weeks back. > No, Neptune is not a part of this binding. There were too many differences since Neptune is a simple PCIE device. ---snip--- David Kahn wrote: > > > Hitendra Zhangada wrote: > >> Few comments/questions. >> >> 1. Can we change the "name" property "siu" to be more descriptive >> such as, >> >> "niagara-system-interface" > > Or maybe sun4v-io or something like that? I don't > care for either name, to be honest, but I agree that if > we can find a suitable generic name for this node we > should use one. As above, I'm proposing to use 'niagara2-system-interface'. > > What does the siu node represent? There's no specification for > the address formats of this "bus". I'm not sure what it represents. > This probably needs to be in bus binding format, rather than > device binding format, with the sections that describe the > reg-format for children of this node, etc. > What registers are mapped by this node? What's the purpose of this > node? The OBP SIU node is the device calls into the hypervisor when setting up the logical page registers inside of the NIU (FWARC 2006/524), acts as the mmu, and maps in the NIU's register space. Someone from the Solaris team might be able to comment more on what the Solaris SUNW,niumx driver does. The registers describe the physical addresses inside of N2 that are needed to control the NIU device. I agree that the child register space should probably be specified in the binding. How about adding this section: ---snip--- 2.1. Child Address Formats SIU addresses have 2 address cells and 2 size cells. 2.1.1. Numerical Representation The address format is two 32-bit cells, real.hi, real.lo. The numerical representation is given in the following table: 63-60--------------------------------32 | | cccc.cccc.cccc.cccc.cccc.cccc.cccc.cccc 31-------------------------------------0 | | llll.llll.llll.llll.llll.llll.llll.llll The size format is two 32-bit cells, size.hi, size.lo. The first cell represents the most significant bits of a 64-bit number and the second cell represents the low order 32-bits of the 64-bit number. The 64-bit number is the size of the resource in bytes. A size value of 0 means there are no addressable resources. Where cc...cc - defines the configuration handle of the device. This value is extracted from the MD node's 'cfg-handle' property ll...ll - Lower address bits. The lower (least significant) offset or address bits. These bits are the offset from the base of the register range and describe the child's configuration registers 2.1.2. Text Representation CCCCCCCC where CCCCCCCC is the hex-ASCII representation of the device number which is encoded as a 32-bit value in the cc...cc bits. Leading zeros may be omitted. The canonical form of a SIU address omits leading zeros, uses the lower case characters "a" through "f" to represent the corresponding hex-ASCII digits and a single '0' to represent DDDDDDD when the hh..hh bits are all zero. ---snip--- The 'ranges' property of the SIU node would look like: ranges 00000000 00000000 80000081 00000000 00000000 05008000 00000001 02000000 80000081 02000000 00000000 05008000 Then the 'reg' property of the child nodes will look like: network@0 reg 00000000 00000000 00000000 01000000 00000000 01000000 00000000 00008000 00000000 05000000 00000000 00008000 network@1 reg 00000001 00000000 00000000 01000000 00000001 02000000 00000000 00008000 00000001 07000000 00000000 00008000 Before I update the case materials, please let me know if the additional section above is sufficient, or if you had something else in mind. Steve From sacadmin Wed Oct 4 11:37:17 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94IbHq5006651 for ; Wed, 4 Oct 2006 11:37:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k94IbGG26716; Wed, 4 Oct 2006 11:37:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6M0061LJQ3UQ00@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 12:37:15 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6M00HWSJQ1BKE0@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 12:37:13 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k94IbDBt028304; Wed, 04 Oct 2006 12:37:13 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6M00J01JF8VN00@mail-amer.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Wed, 04 Oct 2006 12:37:13 -0600 (MDT) Received: from [129.150.35.73] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6M00MITJPZ3A23@mail-amer.sun.com>; Wed, 04 Oct 2006 12:37:13 -0600 (MDT) Date: Wed, 04 Oct 2006 11:37:12 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <4523E410.6010604@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Cc: NIU-SW-Stack-Development@Sun.COM Message-id: <4523FF58.2070401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> <4523E410.6010604@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 8307 Stephen Ehring wrote: > Hitendra Zhangada wrote: > >> Few comments/questions. >> >> 1. Can we change the "name" property "siu" to be more descriptive >> such as, >> >> "niagara-system-interface" >> > > Since this is specific to niagara2, the best generic name I can think > of is 'niagara2-system-interface'. Does the NIU team have any other > suggestions? I am fine with that. > >> 2. Does "#interrupt-vectors" represent total number of vectors under >> SIU >> or under each NIU? I am assuming that it represents total number for >> EACH NIU, is that correct? >> > > #interrupt-vectors is the total for all NIU children (which is why it > is in the SIU node and not the NIU node). > You may want to make that clear in the description. What is an intended use of this property by Solaris? >> Why is this property needed under "siu" and not under "niu"? >> >> 3. For NIU, instead of relying on consecutive MAC addresses, why not >> define a property called "mac-addresses" as an array of integers? >> This way it does not have to be contiguous starting from the "local- >> mac-address" property value. The set of addresses can be any value >> and the number of MAC addresses are the number of properties in >> the array. > > > This solution was discussed, but the NIU mac-addresses are allocated > per XAUI card (NIU leaf), and so they will always be a contiguous > block. If we used a list, each MAC address would required 2 32 bit > integers, and there are 16 mac addresses available for use, which > means that would require a property that is 128 bytes long. > I still feel that having a property which does not rely on having all of the addresses contiguous is a better property. I understand that today they are generated in a contiguous manner and hence it will work but what if this is not true in future. I think having an array will give us the flexibility for future. Does anyone else have an opinion on this, one way or the other? >> >> 4. In the property names "tx-dma-channels-begin" and >> "rx-dma-channels-begin" >> can we change "begin" to "base"? Not sure if the "begin" a proper >> use >> to represent the base of the dma channels. > > > I like DavidK's idea about having a ranges-like propery to allow for > possible noncontiguous allocation of channels. I'll update the binding > accordingly. Ok. >> 5. Under NIU there is "device-type" property in MD node but not under >> the device node. Is that correct? Further, why the "device-type" >> is "mac" and not "network"? > > > Looking at how the current device-tree is built, there is not > 'device-type'. I assume that means that Solaris is not using it. Can > someone on the NIU Solaris team comment? I don't think the Solaris > driver is extracting it from the MD, so maybe we can remove that from > the MD node. The device_type represents set of properties and methods a particular device need to implement/support. I don't think Solaris consumes it. If the device acts as a "network" device then properties and methods related to a device of type "network" are required in the node. If you are creating a new device type called "mac" then we need to describe what that is and set of properties and methods that go with it. Does NIU fall into any of the device types we do currently support? As per IEEE 1275, It is not necessary for every node to have a “device_type” property. If a particular device is not useful for any Open Firmware function (e.g., booting, console, probing) then it need not have a device type. BUT IMO, the node does need a "device_type" property. > >> 6. Are the properties for Neptune part of this bindings? I am >> asking since >> there were some discussions on this with Yuming few weeks back. >> > > No, Neptune is not a part of this binding. There were too many > differences since Neptune is a simple PCIE device. Ok, I will work with Yuming to get the Neptune case going. > > ---snip--- > > David Kahn wrote: > > > > > > Hitendra Zhangada wrote: > > > >> Few comments/questions. > >> > >> 1. Can we change the "name" property "siu" to be more descriptive > >> such as, > >> > >> "niagara-system-interface" > > > > Or maybe sun4v-io or something like that? I don't > > care for either name, to be honest, but I agree that if > > we can find a suitable generic name for this node we > > should use one. > > As above, I'm proposing to use 'niagara2-system-interface'. > > > > > What does the siu node represent? There's no specification for > > the address formats of this "bus". I'm not sure what it represents. > > This probably needs to be in bus binding format, rather than > > device binding format, with the sections that describe the > > reg-format for children of this node, etc. > > What registers are mapped by this node? What's the purpose of this > > node? > > The OBP SIU node is the device calls into the hypervisor when setting > up the logical page registers inside of the NIU (FWARC 2006/524), acts > as the mmu, and maps in the NIU's register space. Someone from the > Solaris team might be able to comment more on what the Solaris > SUNW,niumx driver does. The registers describe the physical addresses > inside of N2 that are needed to control the NIU device. > > I agree that the child register space should probably be specified in > the binding. How about adding this section: > > ---snip--- > > 2.1. Child Address Formats > > SIU addresses have 2 address cells and 2 size cells. > > 2.1.1. Numerical Representation > > The address format is two 32-bit cells, real.hi, real.lo. > The numerical representation is given in the following table: > > > 63-60--------------------------------32 > | | > cccc.cccc.cccc.cccc.cccc.cccc.cccc.cccc > > 31-------------------------------------0 > | | > llll.llll.llll.llll.llll.llll.llll.llll > > The size format is two 32-bit cells, size.hi, size.lo. The first > cell represents the most significant bits of a 64-bit number and > the second cell represents the low order 32-bits of the 64-bit > number. > The 64-bit number is the size of the resource in bytes. A size value > of 0 means there are no addressable resources. > > Where > > cc...cc - defines the configuration handle of the device. This > value is extracted from the MD node's 'cfg-handle' > property > > ll...ll - Lower address bits. > > The lower (least significant) offset or address bits. These > bits are the offset from the base of the register > range and > describe the child's configuration registers > > > 2.1.2. Text Representation > > CCCCCCCC > > where CCCCCCCC is the hex-ASCII representation of the device > number > which is encoded as a 32-bit value in the cc...cc bits. > Leading zeros may be omitted. > > The canonical form of a SIU address omits leading zeros, uses the > lower case characters "a" through "f" to represent the > corresponding > hex-ASCII digits and a single '0' to represent DDDDDDD when > the hh..hh > bits are all zero. > > ---snip--- > > The 'ranges' property of the SIU node would look like: > > ranges 00000000 00000000 80000081 00000000 00000000 05008000 > 00000001 02000000 80000081 02000000 00000000 05008000 > > Then the 'reg' property of the child nodes will look like: > network@0 > reg 00000000 00000000 00000000 01000000 > 00000000 01000000 00000000 00008000 > 00000000 05000000 00000000 00008000 > > network@1 > reg 00000001 00000000 00000000 01000000 > 00000001 02000000 00000000 00008000 > 00000001 07000000 00000000 00008000 > > > Before I update the case materials, please let me know if the > additional section above is sufficient, or if you had something else > in mind. > > Steve -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Wed Oct 4 12:42:11 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94JgAta007709 for ; Wed, 4 Oct 2006 12:42:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k94Jg7R1014110; Thu, 5 Oct 2006 03:42:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6M00M0FMQ7Y700@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 12:42:07 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6M00IKYMQ6A930@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 12:42:06 -0700 (PDT) Received: from kerouac.sfbay.sun.com (kerouac.SFBay.Sun.COM [129.146.96.111]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k94Jg6sf029333; Wed, 04 Oct 2006 12:42:06 -0700 (PDT) Received: from kerouac.sfbay.sun.com (localhost [127.0.0.1]) by kerouac.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id k94JjRUN013474; Wed, 04 Oct 2006 12:45:27 -0700 (PDT) Received: (from rath@localhost) by kerouac.sfbay.sun.com (8.12.10+Sun/8.12.10/Submit) id k94JjRtm013473; Wed, 04 Oct 2006 12:45:27 -0700 (PDT) Date: Wed, 04 Oct 2006 12:45:27 -0700 From: Kevin Rathbun Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <4523FF58.2070401@sun.com> To: Hitendra Zhangada Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com Reply-to: Kevin Rathbun Message-id: <20061004194527.GG3904@kerouac> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> <4523E410.6010604@sun.com> <4523FF58.2070401@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1655 On Wed, Oct 04, 2006 at 11:37:12AM -0700, Hitendra Zhangada wrote: ... > >> Why is this property needed under "siu" and not under "niu"? > >> > >>3. For NIU, instead of relying on consecutive MAC addresses, why not > >> define a property called "mac-addresses" as an array of integers? > >> This way it does not have to be contiguous starting from the "local- > >> mac-address" property value. The set of addresses can be any value > >> and the number of MAC addresses are the number of properties in > >>the array. > > > > > >This solution was discussed, but the NIU mac-addresses are allocated > >per XAUI card (NIU leaf), and so they will always be a contiguous > >block. If we used a list, each MAC address would required 2 32 bit > >integers, and there are 16 mac addresses available for use, which > >means that would require a property that is 128 bytes long. > > > I still feel that having a property which does not rely on having all of > the addresses contiguous is a better property. I understand that today > they are generated in a contiguous manner and hence it will work but what > if this is not true in future. I think having an array will give us the > flexibility for future. > > Does anyone else have an opinion on this, one way or the other? I think we should have a consistent mac-addresses property definition across network devices. The more general definition that supports non-contiguous values seems better in that respect. We should probably have done ontario this way as well. I believe this is how many of the MD properties generated and consumed by the ldom manager for managing ldoms also work. kvn From sacadmin Wed Oct 4 12:45:48 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94JjmlV007727 for ; Wed, 4 Oct 2006 12:45:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k94JjjG24082; Wed, 4 Oct 2006 12:45:45 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6M0000BMVZH500@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 12:45:35 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6M00F24MVZ0160@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 12:45:35 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k94JjYQx019643; Wed, 04 Oct 2006 13:45:35 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6M00901MR36T00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Wed, 04 Oct 2006 13:45:34 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6M00I60MVW1L1M@mail-amer.sun.com>; Wed, 04 Oct 2006 13:45:34 -0600 (MDT) Date: Wed, 04 Oct 2006 15:43:39 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <4523FF58.2070401@sun.com> Sender: Stephen.Ehring@Sun.COM To: Hitendra Zhangada Cc: Firmware Arch , NIU-SW-Stack-Development@Sun.COM Message-id: <45240EEB.4000003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> <4523E410.6010604@sun.com> <4523FF58.2070401@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2763 Hitendra Zhangada wrote: > Stephen Ehring wrote: > >> Hitendra Zhangada wrote: >> >>> Few comments/questions. >>> >>> 1. Can we change the "name" property "siu" to be more descriptive >>> such as, >>> >>> "niagara-system-interface" >>> >> >> Since this is specific to niagara2, the best generic name I can think >> of is 'niagara2-system-interface'. Does the NIU team have any other >> suggestions? > > > I am fine with that. Actually, are we even allowed to use 'niagara' in device names? I think we need to come up with something else. 'sun4v-io' is a little to generic in my opinion. How about either 'system-interface-unit', or 'network-interface-unit'? /network-interface-unit@80/network@0 /network-interface-unit@80/network@1 /system-interface-unit@80/network@0 /system-interface-unit@80/network@1 > >> >>> 2. Does "#interrupt-vectors" represent total number of vectors under >>> SIU >>> or under each NIU? I am assuming that it represents total number for >>> EACH NIU, is that correct? >>> >> >> #interrupt-vectors is the total for all NIU children (which is why it >> is in the SIU node and not the NIU node). >> > > You may want to make that clear in the description. What is an intended > use of > this property by Solaris? I'll let the Solaris team respond to this. >>> 5. Under NIU there is "device-type" property in MD node but not under >>> the device node. Is that correct? Further, why the "device-type" >>> is "mac" and not "network"? >> >> >> Looking at how the current device-tree is built, there is not >> 'device-type'. I assume that means that Solaris is not using it. Can >> someone on the NIU Solaris team comment? I don't think the Solaris >> driver is extracting it from the MD, so maybe we can remove that from >> the MD node. > > The device_type represents set of properties and methods a particular > device > need to implement/support. I don't think Solaris consumes it. If the > device > acts as a "network" device then properties and methods related to a device > of type "network" are required in the node. If you are creating a new > device type called "mac" then we need to describe what that is and set of > properties and methods that go with it. > > Does NIU fall into any of the device types we do currently support? As per > IEEE 1275, > > It is not necessary for every node to have a “device_type” property. If a > particular device is not useful for any Open Firmware function (e.g., > booting, > console, probing) then it need not have a device type. > > BUT IMO, the node does need a "device_type" property. Okay, I'll add 'device_type' of network, since the NIU supports the functionality described in IEEE1275 section 3.7.4 ("network" devices). Steve From sacadmin Wed Oct 4 14:49:21 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94LnKKu010322 for ; Wed, 4 Oct 2006 14:49:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k94LnEgn024636; Wed, 4 Oct 2006 22:49:18 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6M00905SM6G300@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 14:49:18 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6M00I5JSM5AHA0@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 14:49:17 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k94LnHwI028720; Wed, 04 Oct 2006 14:49:17 -0700 (PDT) Received: from [129.146.96.102] (x-files [129.146.96.102]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k94LnGOA051703; Wed, 04 Oct 2006 14:49:16 -0700 (PDT) Date: Wed, 04 Oct 2006 14:49:16 -0700 From: Greg Onufer Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45240EEB.4000003@sun.com> To: Stephen Ehring Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <45242C5C.3070006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> <4523E410.6010604@sun.com> <4523FF58.2070401@sun.com> <45240EEB.4000003@sun.com> User-Agent: Thunderbird 2.0b1pre (X11/20061003) Status: RO Content-Length: 963 Stephen Ehring wrote: >>> Since this is specific to niagara2, the best generic name I can think >>> of is 'niagara2-system-interface'. Does the NIU team have any other >>> suggestions?>> >> >> I am fine with that. > > Actually, are we even allowed to use 'niagara' in device names? It might be a good idea for cpu-specific devices. What's the point of generic names for non-generic devices? > I think > we need to come up with something else. 'sun4v-io' is a little to > generic in my opinion. How about either 'system-interface-unit', or > 'network-interface-unit'? Is there a reason for the intermediate SIU nodes? The network interfaces seem to be root-bus-level devices. I would think they could be "/network@500,0" and "/network@500,1" or whatever, replace the "500" with the appropriate devhandle. At the non-virtualized level, the SIU is also the "parent" of the PCI interface. But that's not exposed to the guest either. Cheers!greg From sacadmin Wed Oct 4 15:34:22 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94MYMBp011549 for ; Wed, 4 Oct 2006 15:34:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k94MYLG24584; Wed, 4 Oct 2006 15:34:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6M00H01UP8JI00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 15:34:20 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6M00H5MUP78R00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 15:34:19 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k94MYJfQ018733; Wed, 04 Oct 2006 15:34:19 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k94MYHEQ053605; Wed, 04 Oct 2006 15:34:18 -0700 (PDT) Date: Wed, 04 Oct 2006 15:34:16 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Stephen Ehring Cc: Greg Onufer , Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <452436E8.6060809@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1029 Greg Onufer wrote: > Is there a reason for the intermediate SIU nodes? The network > interfaces seem to be root-bus-level devices. I would think they could > be "/network@500,0" and "/network@500,1" or whatever, replace the "500" > with the appropriate devhandle. At the non-virtualized level, the SIU > is also the "parent" of the PCI interface. But that's not exposed to > the guest either. That was going to be my comment as well. If each network node has a different configuration address, they should be network@x and network@y. Greg's example makes sense if there's a single config addr for both nodes. We don't create artificial nodes in the device tree. There's no bus there, so there should be no node there. And for interrupts, we should be using standard interrupt properties, like everybody else uses. The network nodes must have "interrupts" properties. The parent node has interrupt-map-mask and interrupt-map properties that convert the local interrupt number to a system interrupt number. -David From sacadmin Wed Oct 4 15:56:33 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94MuWdb012201 for ; Wed, 4 Oct 2006 15:56:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k94MuSw8013673; Thu, 5 Oct 2006 06:56:31 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6M00E05VQ5QN00@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 15:56:29 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6M00IVQVQ4AHD0@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Oct 2006 15:56:29 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k94MuSq0027497; Wed, 04 Oct 2006 15:56:28 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k94MuQpt054684; Wed, 04 Oct 2006 15:56:27 -0700 (PDT) Date: Wed, 04 Oct 2006 15:56:26 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Stephen Ehring Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <45243C1A.8030101@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 360 As I understand it, in the MD node, you define "device-type" and that's it. If you do that, the OBP device node will contain the "device_type" property with the same value as the MD nodes "device-type" property. Is that correct Kevin? I don't know why the MD did it differently, because it *always* causes this type of confusion. (as predicted.) -David From sacadmin Wed Oct 4 16:02:06 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94N26Jo012493 for ; Wed, 4 Oct 2006 16:02:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k94N26x12553; Wed, 4 Oct 2006 16:02:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6M00I09VZG5I00@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 17:02:04 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6M00F47VZG1PD0@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 17:02:04 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k94N23Ov019039; Wed, 04 Oct 2006 16:02:03 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k94N22Up055118; Wed, 04 Oct 2006 16:02:02 -0700 (PDT) Date: Wed, 04 Oct 2006 16:02:02 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45243C1A.8030101@sun.com> To: Stephen Ehring Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <45243D6A.5090601@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45243C1A.8030101@sun.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 607 David Kahn wrote: > > > As I understand it, in the MD node, you define > "device-type" and that's it. If you do that, > the OBP device node will contain the "device_type" > property with the same value as the MD nodes > "device-type" property. Is that correct Kevin? > > I don't know why the MD did it differently, because > it *always* causes this type of confusion. (as > predicted.) Actually, if the device has FCode, the FCode will override the MDs node device-type propval, if the FCode defines it. Assuming the niu nodes are bootable, they will have FCode. (Is there a device binding?) -David From sacadmin Wed Oct 4 17:47:54 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k950lsFA013535 for ; Wed, 4 Oct 2006 17:47:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k950lr810613; Wed, 4 Oct 2006 18:47:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6N008010VT9300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 17:47:53 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6N00H7H0VS8X70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 17:47:52 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k950lqwq025281; Wed, 04 Oct 2006 17:47:52 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6N008010SC0L00@d1-sfbay-09.sun.com> (original mail from John.Fitzgerald@Sun.COM); Wed, 04 Oct 2006 17:47:52 -0700 (PDT) Received: from [129.153.85.35] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6N00DIU0VRVTPV@d1-sfbay-09.sun.com>; Wed, 04 Oct 2006 17:47:52 -0700 (PDT) Date: Wed, 04 Oct 2006 17:47:51 -0700 From: John.Fitzgerald@Sun.COM Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45240EEB.4000003@sun.com> Sender: John.Fitzgerald@Sun.COM To: Stephen Ehring Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@Sun.COM Message-id: <45245637.6080109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=windows-1252 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45194300.6080109@sun.com> <451DB6C3.5030407@sun.com> <4523E410.6010604@sun.com> <4523FF58.2070401@sun.com> <45240EEB.4000003@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 Status: RO Content-Length: 3131 Stephen Ehring wrote: > Hitendra Zhangada wrote: > >> Stephen Ehring wrote: >> >>> Hitendra Zhangada wrote: >>> >>>> Few comments/questions. >>>> >>>> 1. Can we change the "name" property "siu" to be more descriptive >>>> such as, >>>> >>>> "niagara-system-interface" >>>> >>> >>> Since this is specific to niagara2, the best generic name I can >>> think of is 'niagara2-system-interface'. Does the NIU team have any >>> other suggestions? >> >> >> >> I am fine with that. > > > Actually, are we even allowed to use 'niagara' in device names? I > think we need to come up with something else. 'sun4v-io' is a little > to generic in my opinion. How about either 'system-interface-unit', or > 'network-interface-unit'? > > /network-interface-unit@80/network@0 > /network-interface-unit@80/network@1 > /system-interface-unit@80/network@0 > /system-interface-unit@80/network@1 > >> >>> >>>> 2. Does "#interrupt-vectors" represent total number of vectors >>>> under SIU >>>> or under each NIU? I am assuming that it represents total number for >>>> EACH NIU, is that correct? >>>> >>> >>> #interrupt-vectors is the total for all NIU children (which is why >>> it is in the SIU node and not the NIU node). >>> >> >> You may want to make that clear in the description. What is an >> intended use of >> this property by Solaris? > > > I'll let the Solaris team respond to this. Steve's response above is correct, this is the total number of interrupts for all NIU devices, children of the SIU node. It is used to determine the number of available interrupts to be fed into the DDI framework (DDI_INTROPS_NAVAIL). Regards, John. > >>>> 5. Under NIU there is "device-type" property in MD node but not under >>>> the device node. Is that correct? Further, why the "device-type" >>>> is "mac" and not "network"? >>> >>> >>> >>> Looking at how the current device-tree is built, there is not >>> 'device-type'. I assume that means that Solaris is not using it. Can >>> someone on the NIU Solaris team comment? I don't think the Solaris >>> driver is extracting it from the MD, so maybe we can remove that >>> from the MD node. >> >> >> The device_type represents set of properties and methods a particular >> device >> need to implement/support. I don't think Solaris consumes it. If the >> device >> acts as a "network" device then properties and methods related to a >> device >> of type "network" are required in the node. If you are creating a new >> device type called "mac" then we need to describe what that is and >> set of >> properties and methods that go with it. >> >> Does NIU fall into any of the device types we do currently support? >> As per >> IEEE 1275, >> >> It is not necessary for every node to have a device_type property. >> If a >> particular device is not useful for any Open Firmware function (e.g., >> booting, >> console, probing) then it need not have a device type. >> >> BUT IMO, the node does need a "device_type" property. > > > Okay, I'll add 'device_type' of network, since the NIU supports the > functionality described in IEEE1275 section 3.7.4 ("network" devices). > > Steve From sacadmin Wed Oct 4 18:10:03 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k951A2G1014027 for ; Wed, 4 Oct 2006 18:10:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k951A2815373; Wed, 4 Oct 2006 19:10:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6N00A071WPMD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 18:10:01 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6N00HNJ1WP9580@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Oct 2006 18:10:01 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k951A1ge005870; Wed, 04 Oct 2006 18:10:01 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9519x0R058824; Wed, 04 Oct 2006 18:10:00 -0700 (PDT) Date: Wed, 04 Oct 2006 18:09:59 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: John.Fitzgerald@sun.com Cc: Stephen Ehring , Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <45245B67.9090408@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1131 John.Fitzgerald@Sun.COM wrote: >>>>> 2. Does "#interrupt-vectors" represent total number of vectors >>>>> under SIU >>>>> or under each NIU? I am assuming that it represents total number for >>>>> EACH NIU, is that correct? >>>>> >>>> >>>> #interrupt-vectors is the total for all NIU children (which is why >>>> it is in the SIU node and not the NIU node). >>>> >>> >>> You may want to make that clear in the description. What is an >>> intended use of >>> this property by Solaris? >> >> >> I'll let the Solaris team respond to this. > > Steve's response above is correct, this is the total number of > interrupts for all NIU devices, children of the SIU node. > It is used to determine the number of available interrupts to be fed > into the DDI framework (DDI_INTROPS_NAVAIL). Huh? What sort of interrupts does the NIU support? The ddi interrupt infrastructure is setup to support standard bus type interrupts as in INTx on pci* and MSI* on pci. The niu is not a pci* device, right? Again, you don't need to invent a node for this. How are available interrupts distributed to each of the network interfaces? -David From sacadmin Wed Oct 4 19:07:48 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9527lKR014657 for ; Wed, 4 Oct 2006 19:07:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9527fdE011830; Thu, 5 Oct 2006 03:07:42 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6N004094KT2Q00@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 20:07:41 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6N00J0P4KS5PC0@brm-avmta-1.central.sun.com>; Wed, 04 Oct 2006 20:07:40 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9527e5b028321; Wed, 04 Oct 2006 19:07:40 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9527ckZ060511; Wed, 04 Oct 2006 19:07:38 -0700 (PDT) Date: Wed, 04 Oct 2006 19:07:38 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: John.Fitzgerald@Sun.COM, Stephen Ehring Cc: Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@Sun.COM Message-id: <452468EA.6090005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1735 ok .. after reading the N2 PRM (v1.2, is that current for the NIU?) It looks like there's some shared logic and registers for managing the NIU, and then there's per-mac registers for each of 2 physical ports. There's also the ability to configure virtual "functions" (for lack of a better word) which can be configured into logical devices and those into logical device groups. Is there a software architecture spec on how we plan on managing the NIU and its ports for both the short term and the long term and how this is all presented to the domain manager for assignment of virtual devices to domains? If there are, indeed, shared registers in the NIU that are used to manage and control the device, I can see the need for a sun4v "niu" bus node (child of root, device_type "sun4v"), with the 2 physical network ports below the "niu" node. Is 7.2.1 the actual format of the data sent to the dev mondo queue??? If not, are there mondo data tables for the 64 NIU device interrupts so that software can choose the value that's put on dev mondo when the interrupt is sent to dev mondo by the NCU? I guess I'm confused because it said somewhere that software can't choose the values used for NIU interrupts. Anyway, it's difficult to evaluate any of this without understanding requirements and the overall architecture. Probably the closest model I can see that works overall is to have an NIU node for management of the niu and a node per physical port. That leaves the virtualization model undefined and software can pretty much do whatever it wants there, except that the assignment of resources to a logical device (or group) and the interrupt mapping has to be managed somewhere by device specific code. -David From sacadmin Thu Oct 5 01:38:02 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k958c23a020020 for ; Thu, 5 Oct 2006 01:38:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k958bx2X013182; Thu, 5 Oct 2006 09:38:01 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6N00M01MNAEE00@brm-avmta-1.central.sun.com>; Thu, 05 Oct 2006 02:37:58 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6N00L91MNA7R10@brm-avmta-1.central.sun.com>; Thu, 05 Oct 2006 02:37:58 -0600 (MDT) Received: from kerouac.sfbay.sun.com (kerouac.SFBay.Sun.COM [129.146.96.111]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k958bvrE021486; Thu, 05 Oct 2006 01:37:57 -0700 (PDT) Received: from kerouac.sfbay.sun.com (localhost [127.0.0.1]) by kerouac.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id k958fJUN016263; Thu, 05 Oct 2006 01:41:19 -0700 (PDT) Received: (from rath@localhost) by kerouac.sfbay.sun.com (8.12.10+Sun/8.12.10/Submit) id k958fJgR016262; Thu, 05 Oct 2006 01:41:19 -0700 (PDT) Date: Thu, 05 Oct 2006 01:41:19 -0700 From: Kevin Rathbun Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45243C1A.8030101@sun.com> To: David Kahn Cc: Stephen Ehring , Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Reply-to: Kevin Rathbun Message-id: <20061005084119.GR13817@kerouac> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <45243C1A.8030101@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 939 On Wed, Oct 04, 2006 at 03:56:26PM -0700, David Kahn wrote: > > > As I understand it, in the MD node, you define > "device-type" and that's it. If you do that, > the OBP device node will contain the "device_type" > property with the same value as the MD nodes > "device-type" property. Is that correct Kevin? I don't believe that is the case. I'm aware of device tree nodes without device_type properties whose MD node counterparts do have device-type properties. I don't recall a FWARC case stipulating it be present universally if present in the MD. Seems to be less an MD spec question and more a device binding question or fcode implementation privilege. It was discussed at one time to instantiate the MD props in the device tree where they had proper homes but nothing came of it. kvn > > I don't know why the MD did it differently, because > it *always* causes this type of confusion. (as > predicted.) > > -David > > > From sacadmin Thu Oct 5 01:45:24 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k958jNdu020059 for ; Thu, 5 Oct 2006 01:45:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k958jN802090; Thu, 5 Oct 2006 02:45:23 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6N00G0TMZJG500@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Oct 2006 01:45:19 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6N00BQ7MZIRJ40@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Oct 2006 01:45:18 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k958jHl7025221; Thu, 05 Oct 2006 01:45:17 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k958jGlm067862; Thu, 05 Oct 2006 01:45:16 -0700 (PDT) Date: Thu, 05 Oct 2006 01:45:16 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <20061005084119.GR13817@kerouac> To: Kevin Rathbun Cc: Stephen Ehring , Hitendra Zhangada , Firmware Arch , NIU-SW-Stack-Development@sun.com Message-id: <4524C61C.1090609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <45243C1A.8030101@sun.com> <20061005084119.GR13817@kerouac> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 507 Kevin Rathbun wrote: > I don't recall a FWARC case stipulating it be present > universally if present in the MD. Seems to be less an > MD spec question and more a device binding question > or fcode implementation privilege. It was discussed > at one time to instantiate the MD props in the device > tree where they had proper homes but nothing came of it. So only devices with FCode get device_type properties, if created by the FCode. That seems ok to me. Thanks for clearing up my confusion. -David From sacadmin Thu Oct 5 09:21:34 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k95GLXjB028922 for ; Thu, 5 Oct 2006 09:21:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k95GLJac028432; Thu, 5 Oct 2006 17:21:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6O00A2S83W7W00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Oct 2006 09:21:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6O00MK183UYB90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Oct 2006 09:21:31 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k95GLUPS005313; Thu, 05 Oct 2006 10:21:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6O00E017ZK8F00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Thu, 05 Oct 2006 10:21:30 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6O0017683SY3Y1@mail-amer.sun.com>; Thu, 05 Oct 2006 10:21:30 -0600 (MDT) Date: Thu, 05 Oct 2006 12:19:36 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <452468EA.6090005@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Cc: NIU-SW-Stack-Development@sun.com Message-id: <45253098.9090909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <452468EA.6090005@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2454 David Kahn wrote: > > ok .. after reading the N2 PRM (v1.2, is that current for the NIU?) Yes, that is the latest official version. > It looks like there's some shared logic and registers for managing > the NIU, and then there's per-mac registers for each of 2 physical > ports. There's also the ability to configure virtual "functions" > (for lack of a better word) which can be configured into logical > devices and those into logical device groups. > > Is there a software architecture spec on how we plan on managing > the NIU and its ports for both the short term and the long term > and how this is all presented to the domain manager for assignment > of virtual devices to domains? I'm not aware of any such document. Perhaps someone on the Solaris NIU team can respond? > > If there are, indeed, shared registers in the NIU that are used > to manage and control the device, I can see the need for a sun4v > "niu" bus node (child of root, device_type "sun4v"), with the 2 > physical network ports below the "niu" node. > > Is 7.2.1 the actual format of the data sent to the dev mondo > queue??? If not, are there mondo data tables for the 64 NIU > device interrupts so that software can choose the value that's > put on dev mondo when the interrupt is sent to dev mondo > by the NCU? I guess I'm confused because it said somewhere that > software can't choose the values used for NIU interrupts. > > Anyway, it's difficult to evaluate any of this without understanding > requirements and the overall architecture. > > Probably the closest model I can see that works overall is to > have an NIU node for management of the niu and a node per > physical port. That leaves the virtualization model undefined > and software can pretty much do whatever it wants there, except > that the assignment of resources to a logical device (or group) > and the interrupt mapping has to be managed somewhere by device > specific code. This is the model that is being proposed by the binding. I've upated the binding with the following changes based on everyone's comments: - Replace '#mac-addresses' with 'mac-addresses'. - Replace [rt]x-dma-channel properties with new scheme that uses single property - Add SIU bus address format section - Change siu device name - Add 'device_type' property to siu and niu OBP nodes New binding is in the materials directory (binding is under SCCS control, so we can access older versions if necessary). Steve From sacadmin Thu Oct 5 13:44:18 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k95KiIb0005714 for ; Thu, 5 Oct 2006 13:44:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k95KiHx00756; Thu, 5 Oct 2006 13:44:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6O0000NK9TF700@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Oct 2006 13:44:17 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6O0081YK9S7QB0@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Oct 2006 13:44:16 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k95KiGqP002343; Thu, 05 Oct 2006 13:44:16 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6O00H01K78O600@d1-sfbay-09.sun.com> (original mail from Michael.Speer@Sun.COM); Thu, 05 Oct 2006 13:44:16 -0700 (PDT) Received: from 129.149.2.75 ([129.149.2.75]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6O00DI2K9RW19W@d1-sfbay-09.sun.com>; Thu, 05 Oct 2006 13:44:15 -0700 (PDT) Date: Thu, 05 Oct 2006 13:44:15 -0700 From: "Michael F. Speer" Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45253098.9090909@sun.com> Sender: Michael.Speer@Sun.COM To: Stephen Ehring Cc: Firmware Arch , NIU-SW-Stack-Development@Sun.COM Reply-to: Michael.Speer@Sun.COM Message-id: <1160081055.32240.13.camel@sr1-unwk-28> Organization: Throughput Networking MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Content-type: text/plain; charset=iso8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <452468EA.6090005@sun.com> <45253098.9090909@sun.com> Status: RO Content-Length: 3025 David, See comments inline ... Tycho, please clarify anything that I miss. On Thu, 2006-10-05 at 09:19, Stephen Ehring wrote: > David Kahn wrote: > > > > ok .. after reading the N2 PRM (v1.2, is that current for the NIU?) > > Yes, that is the latest official version. > > > It looks like there's some shared logic and registers for managing > > the NIU, and then there's per-mac registers for each of 2 physical > > ports. There's also the ability to configure virtual "functions" > > (for lack of a better word) which can be configured into logical > > devices and those into logical device groups. > > > > Is there a software architecture spec on how we plan on managing > > the NIU and its ports for both the short term and the long term > > and how this is all presented to the domain manager for assignment > > of virtual devices to domains? > > I'm not aware of any such document. Perhaps someone on the Solaris NIU team can respond? > > > > > If there are, indeed, shared registers in the NIU that are used > > to manage and control the device, I can see the need for a sun4v > > "niu" bus node (child of root, device_type "sun4v"), with the 2 > > physical network ports below the "niu" node. > > > > Is 7.2.1 the actual format of the data sent to the dev mondo > > queue??? If not, are there mondo data tables for the 64 NIU > > device interrupts so that software can choose the value that's > > put on dev mondo when the interrupt is sent to dev mondo > > by the NCU? I guess I'm confused because it said somewhere that > > software can't choose the values used for NIU interrupts. For the NIU, Hypervisor choose the assignment for the NIU's logical devices interrupts in dev mondo table. The mapping maps each of the 36 logical devices (16 rx, 16 tx, 2 mac, 1 mif, and 1 system err) to it own vector in the NCU table. For the specific format and mapping, Tycho can provide the details. > > > > Anyway, it's difficult to evaluate any of this without understanding > > requirements and the overall architecture. > > > > Probably the closest model I can see that works overall is to > > have an NIU node for management of the niu and a node per > > physical port. That leaves the virtualization model undefined > > and software can pretty much do whatever it wants there, except > > that the assignment of resources to a logical device (or group) > > and the interrupt mapping has to be managed somewhere by device > > specific code. > > This is the model that is being proposed by the binding. I've upated the binding with the following changes > based on everyone's comments: > > - Replace '#mac-addresses' with 'mac-addresses'. > - Replace [rt]x-dma-channel properties with new scheme that uses single property > - Add SIU bus address format section > - Change siu device name > - Add 'device_type' property to siu and niu OBP nodes > > New binding is in the materials directory (binding is under SCCS control, so we can access older versions if > necessary). > > Steve Regards, Michael From sacadmin Thu Oct 5 18:44:11 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k961iAQv013654 for ; Thu, 5 Oct 2006 18:44:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k961i4Pm018752; Fri, 6 Oct 2006 02:44:09 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6O00M01Y5JIM00@brm-avmta-1.central.sun.com>; Thu, 05 Oct 2006 19:44:07 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6O007IUY5IALE0@brm-avmta-1.central.sun.com>; Thu, 05 Oct 2006 19:44:07 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k961i6JV015360; Thu, 05 Oct 2006 18:44:06 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k961i5en000259; Thu, 05 Oct 2006 18:44:05 -0700 (PDT) Date: Thu, 05 Oct 2006 18:44:04 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Stephen Ehring Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com, Ashley Saulsbury Message-id: <4525B4E4.40804@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1827 Issues: 1. What's being mapped in the SIU node and why do we need an SIU parent node? I don't understand this device tree layout or why it's needed. I might understand a node representing the niu as the parent, if, in fact, there are shared registers representing resources or management controls that apply to both mac nodes, and then a node for each mac as a peer or child of that node. What registers are mapped here? What resources are managed here? If this is artificial, we should get rid of it. 2. #interrupt-vectors: Why not use standard interrupts, interrupt-map and interrupt-map-mask properties? 3. Do the NIU interrupts allow software to set the data sent in the data that gets queued to dev mondo? Either way, what's the format of the data sent to dev mondo and is it consistent with the way we're handling existing interrupts? What are the hv interfaces for NIU interrupts? How are these events dispatched to an interrupt handler? 4. Why is the name in the siu MD node "iodevice"? 5. What is pio-size and pio-base for? Shouldn't they simply be well-defined entries in the nodes "reg" property? Same issue for vio*-size and base. 6. Section 2 does not describe the characteristics of the "siu" bus adequately. Look at other bus bindings or bus binding boilerplate text. (c.f. #1) 7. Is there another case for how the network interfaces are allocated to the domains or how they are going to be used by the OS? How will Linux use them? 8. Where is the architecture document describing the overall NIU software/firmware architecture? The interface table seems to be out of sync with the document. Since many of these questions have been asked already and haven't been addressed, I'm derailing this case. -David From sacadmin Fri Oct 6 09:28:51 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96GSoAa027451 for ; Fri, 6 Oct 2006 09:28:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k96GSn121196; Fri, 6 Oct 2006 09:28:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6Q00J0F3400300@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 10:28:48 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6Q00G6M33ZTM40@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 10:28:48 -0600 (MDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96GSl0T005387; Fri, 06 Oct 2006 09:28:47 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q00H012YNU100@d1-sfbay-10.sun.com> (original mail from J.Tapia@Sun.COM) ; Fri, 06 Oct 2006 09:28:47 -0700 (PDT) Received: from [192.168.1.3] ([129.150.23.192]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q00DNY33YCBMA@d1-sfbay-10.sun.com>; Fri, 06 Oct 2006 09:28:47 -0700 (PDT) Date: Fri, 06 Oct 2006 09:11:19 -0700 From: Jorge Tapia Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <4525B4E4.40804@sun.com> Sender: J.Tapia@Sun.COM To: David Kahn Cc: Stephen Ehring , Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Message-id: <45268027.4070904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 2042 Michael, May, Tycho and John please formally respond by email to the questions below. Thanks, Jorge David Kahn wrote: > > Issues: > > 1. What's being mapped in the SIU node and why > do we need an SIU parent node? I don't understand > this device tree layout or why it's needed. I might > understand a node representing the niu as the parent, > if, in fact, there are shared registers representing resources > or management controls that apply to both mac nodes, > and then a node for each mac as a peer or child of that > node. What registers are mapped here? What resources are > managed here? If this is artificial, we should get rid of it. > > 2. #interrupt-vectors: Why not use standard interrupts, > interrupt-map and interrupt-map-mask properties? > > 3. Do the NIU interrupts allow software to set the > data sent in the data that gets queued to dev mondo? > Either way, what's the format of the data sent to dev mondo > and is it consistent with the way we're handling existing > interrupts? What are the hv interfaces for NIU interrupts? > How are these events dispatched to an interrupt handler? > > 4. Why is the name in the siu MD node "iodevice"? > > 5. What is pio-size and pio-base for? Shouldn't > they simply be well-defined entries in the nodes > "reg" property? Same issue for vio*-size and base. > > 6. Section 2 does not describe the characteristics > of the "siu" bus adequately. Look at other bus > bindings or bus binding boilerplate text. (c.f. #1) > > 7. Is there another case for how the network interfaces > are allocated to the domains or how they are going to > be used by the OS? How will Linux use them? > > 8. Where is the architecture document describing the overall > NIU software/firmware architecture? > > > The interface table seems to be out of sync with the > document. > > Since many of these questions have been asked already and > haven't been addressed, I'm derailing this case. > > -David > > > > > > > > > From sacadmin Fri Oct 6 09:38:30 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96GcTHc027552 for ; Fri, 6 Oct 2006 09:38:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k96GcTD00979; Fri, 6 Oct 2006 10:38:29 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6Q00J0D3K4F000@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 10:38:28 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6Q00GVQ3K3TO40@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 10:38:27 -0600 (MDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96GcRtl020458; Fri, 06 Oct 2006 10:38:27 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q0040130D8Y00@mail-amer.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Fri, 06 Oct 2006 10:38:27 -0600 (MDT) Received: from [129.150.35.181] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q0078H3K2R7Y4@mail-amer.sun.com>; Fri, 06 Oct 2006 10:38:27 -0600 (MDT) Date: Fri, 06 Oct 2006 09:38:26 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268027.4070904@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Jorge Tapia Cc: Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Message-id: <45268682.3010402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 2514 Jorge Tapia wrote: > Michael, May, Tycho and John please formally respond by email to the > questions below. Or just schedule a meeting with FWARC for 10/16/06 to discuss the specification. For this 20Q and updates to specification, if any, is needed. Thanks. > > Thanks, > Jorge > > > David Kahn wrote: > >> >> Issues: >> >> 1. What's being mapped in the SIU node and why >> do we need an SIU parent node? I don't understand >> this device tree layout or why it's needed. I might >> understand a node representing the niu as the parent, >> if, in fact, there are shared registers representing resources >> or management controls that apply to both mac nodes, >> and then a node for each mac as a peer or child of that >> node. What registers are mapped here? What resources are >> managed here? If this is artificial, we should get rid of it. >> >> 2. #interrupt-vectors: Why not use standard interrupts, >> interrupt-map and interrupt-map-mask properties? >> >> 3. Do the NIU interrupts allow software to set the >> data sent in the data that gets queued to dev mondo? >> Either way, what's the format of the data sent to dev mondo >> and is it consistent with the way we're handling existing >> interrupts? What are the hv interfaces for NIU interrupts? >> How are these events dispatched to an interrupt handler? >> >> 4. Why is the name in the siu MD node "iodevice"? >> >> 5. What is pio-size and pio-base for? Shouldn't >> they simply be well-defined entries in the nodes >> "reg" property? Same issue for vio*-size and base. >> >> 6. Section 2 does not describe the characteristics >> of the "siu" bus adequately. Look at other bus >> bindings or bus binding boilerplate text. (c.f. #1) >> >> 7. Is there another case for how the network interfaces >> are allocated to the domains or how they are going to >> be used by the OS? How will Linux use them? >> >> 8. Where is the architecture document describing the overall >> NIU software/firmware architecture? >> >> >> The interface table seems to be out of sync with the >> document. >> >> Since many of these questions have been asked already and >> haven't been addressed, I'm derailing this case. >> >> -David >> >> >> >> >> >> >> >> >> -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Fri Oct 6 09:49:24 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96GnNC8027620 for ; Fri, 6 Oct 2006 09:49:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k96GnHn3025996; Sat, 7 Oct 2006 00:49:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6Q00905429JJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Oct 2006 09:49:21 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6Q002UX4281A50@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Oct 2006 09:49:20 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96GnKwb004128; Fri, 06 Oct 2006 09:49:20 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q00L013XTD800@d1-sfbay-09.sun.com> (original mail from J.Tapia@Sun.COM) ; Fri, 06 Oct 2006 09:49:20 -0700 (PDT) Received: from [192.168.1.3] ([129.150.23.192]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q00DV841WVOUA@d1-sfbay-09.sun.com>; Fri, 06 Oct 2006 09:49:08 -0700 (PDT) Date: Fri, 06 Oct 2006 09:31:40 -0700 From: Jorge Tapia Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268682.3010402@sun.com> Sender: J.Tapia@sun.com To: Hitendra Zhangada Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com, Ashley Saulsbury Message-id: <452684EC.2000402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <45268682.3010402@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 2573 Hello All, Steve and Hitu please add us to the agenda for the next FWARC meeting on 10/16/06. Is this the earliest opportunity to meet and discuss this? Thanks, Jorge Hitendra Zhangada wrote: > Jorge Tapia wrote: > >> Michael, May, Tycho and John please formally respond by email to the >> questions below. > > > Or just schedule a meeting with FWARC for 10/16/06 to discuss the > specification. For this 20Q and updates to specification, if any, > is needed. > > > Thanks. > >> >> Thanks, >> Jorge >> >> >> David Kahn wrote: >> >>> >>> Issues: >>> >>> 1. What's being mapped in the SIU node and why >>> do we need an SIU parent node? I don't understand >>> this device tree layout or why it's needed. I might >>> understand a node representing the niu as the parent, >>> if, in fact, there are shared registers representing resources >>> or management controls that apply to both mac nodes, >>> and then a node for each mac as a peer or child of that >>> node. What registers are mapped here? What resources are >>> managed here? If this is artificial, we should get rid of it. >>> >>> 2. #interrupt-vectors: Why not use standard interrupts, >>> interrupt-map and interrupt-map-mask properties? >>> >>> 3. Do the NIU interrupts allow software to set the >>> data sent in the data that gets queued to dev mondo? >>> Either way, what's the format of the data sent to dev mondo >>> and is it consistent with the way we're handling existing >>> interrupts? What are the hv interfaces for NIU interrupts? >>> How are these events dispatched to an interrupt handler? >>> >>> 4. Why is the name in the siu MD node "iodevice"? >>> >>> 5. What is pio-size and pio-base for? Shouldn't >>> they simply be well-defined entries in the nodes >>> "reg" property? Same issue for vio*-size and base. >>> >>> 6. Section 2 does not describe the characteristics >>> of the "siu" bus adequately. Look at other bus >>> bindings or bus binding boilerplate text. (c.f. #1) >>> >>> 7. Is there another case for how the network interfaces >>> are allocated to the domains or how they are going to >>> be used by the OS? How will Linux use them? >>> >>> 8. Where is the architecture document describing the overall >>> NIU software/firmware architecture? >>> >>> >>> The interface table seems to be out of sync with the >>> document. >>> >>> Since many of these questions have been asked already and >>> haven't been addressed, I'm derailing this case. >>> >>> -David >>> >>> >>> >>> >>> >>> >>> >>> >>> > > From sacadmin Fri Oct 6 09:54:46 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96GskYp028075 for ; Fri, 6 Oct 2006 09:54:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k96Gsi101160; Fri, 6 Oct 2006 09:54:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6Q00K074B8BR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 09:54:44 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6Q00FEG4B7F230@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 09:54:43 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96Gshd7008265; Fri, 06 Oct 2006 10:54:43 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q00801484JG00@mail-amer.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Fri, 06 Oct 2006 10:54:43 -0600 (MDT) Received: from [129.150.35.181] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q00IPN4B524U3@mail-amer.sun.com>; Fri, 06 Oct 2006 10:54:42 -0600 (MDT) Date: Fri, 06 Oct 2006 09:54:42 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <452684EC.2000402@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Jorge Tapia Cc: Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Message-id: <45268A52.5090400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <45268682.3010402@sun.com> <452684EC.2000402@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 830 Jorge Tapia wrote: > Hello All, > Steve and Hitu please add us to the agenda for the next FWARC meeting > on 10/16/06. Is this the earliest opportunity to meet and discuss this? Yes. FWARC meets every Monday. It is too late to schedule for the next Monday and hence it needs to go out a week. Project team can work with Steve E. who owns the case for the logistics. After the meeting, if agreed by members, we can convert the case back to fast-track and get it approved. Note that having a meeting is just a suggestion. Project team can work with Steve to figure out the next step for this case. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Fri Oct 6 10:01:10 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96H1A1G028118 for ; Fri, 6 Oct 2006 10:01:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k96H17103342; Fri, 6 Oct 2006 10:01:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6Q00K014LTCQ00@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 11:01:05 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6Q00GMJ4LSTZ50@brm-avmta-1.central.sun.com>; Fri, 06 Oct 2006 11:01:05 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96H14H4005753; Fri, 06 Oct 2006 10:01:04 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q00G014GXI300@d1-sfbay-09.sun.com> (original mail from Sherri.Shieh@Sun.COM); Fri, 06 Oct 2006 10:01:04 -0700 (PDT) Received: from [192.168.2.2] ([24.5.245.185]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q00D4J4LSW0O8@d1-sfbay-09.sun.com>; Fri, 06 Oct 2006 10:01:04 -0700 (PDT) Date: Fri, 06 Oct 2006 10:01:05 -0700 From: Sherri Shieh Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268A52.5090400@sun.com> Sender: Sherri.Shieh@Sun.COM To: Hitendra Zhangada Cc: Jorge Tapia , Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Reply-to: Sherri.Shieh@Sun.COM Message-id: <45268BD1.7050907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <45268682.3010402@sun.com> <452684EC.2000402@sun.com> <45268A52.5090400@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 1384 OK, I will schedule this case for a discussion. - Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hitendra Zhangada wrote: > Jorge Tapia wrote: > >> Hello All, >> Steve and Hitu please add us to the agenda for the next FWARC meeting >> on 10/16/06. Is this the earliest opportunity to meet and discuss this? > > > Yes. FWARC meets every Monday. It is too late to schedule for the next > Monday and hence it needs to go out a week. > > Project team can work with Steve E. who owns the case for the logistics. > > After the meeting, if agreed by members, we can convert the case back > to fast-track and get it approved. > > > Note that having a meeting is just a suggestion. Project team can > work with Steve to figure out the next step for this case. > From sacadmin Fri Oct 6 10:14:28 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96HEROw028502 for ; Fri, 6 Oct 2006 10:14:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k96HERD13606; Fri, 6 Oct 2006 11:14:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6Q00M095824800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 10:14:26 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6Q00F8C581FG50@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 10:14:25 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96HEOmC006174; Fri, 06 Oct 2006 11:14:24 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q00601572HD00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Fri, 06 Oct 2006 11:14:24 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q0094S57ZWW31@mail-amer.sun.com>; Fri, 06 Oct 2006 11:14:24 -0600 (MDT) Date: Fri, 06 Oct 2006 13:12:30 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268BD1.7050907@sun.com> Sender: Stephen.Ehring@Sun.COM To: Sherri.Shieh@Sun.COM Cc: Hitendra Zhangada , Jorge Tapia , Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Message-id: <45268E7E.3090008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <45268682.3010402@sun.com> <452684EC.2000402@sun.com> <45268A52.5090400@sun.com> <45268BD1.7050907@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 532 I'm going to be traveling on 10/16, so 10/23 is the earliest we could have an inception review. If the NIU team can resolve all of David's issues via e-mail the inception review might not be necessary, but please schedule it then anyway. Since this is going to be a full ARC review, are there any FWARC interns who would like to volunteer? I (or an intern) will produce the 20Q and issues list documents and place them in the materials directory when they are ready (no later than one week before the inception review). Steve From sacadmin Fri Oct 6 10:17:30 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96HHT7f028617 for ; Fri, 6 Oct 2006 10:17:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k96HHSFF019139; Fri, 6 Oct 2006 18:17:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6Q00M035D1EG00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 10:17:25 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6Q00FVC5D0EX40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Oct 2006 10:17:25 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k96HHO95011984; Fri, 06 Oct 2006 10:17:24 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Q003015CSI100@d1-sfbay-09.sun.com> (original mail from Sherri.Shieh@Sun.COM); Fri, 06 Oct 2006 10:17:24 -0700 (PDT) Received: from [192.168.2.2] ([24.5.245.185]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Q00DWH5CZW0P8@d1-sfbay-09.sun.com>; Fri, 06 Oct 2006 10:17:24 -0700 (PDT) Date: Fri, 06 Oct 2006 10:17:25 -0700 From: Sherri Shieh Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268E7E.3090008@sun.com> Sender: Sherri.Shieh@Sun.COM To: Stephen Ehring Cc: Hitendra Zhangada , Jorge Tapia , Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Reply-to: Sherri.Shieh@Sun.COM Message-id: <45268FA5.2030109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <45268682.3010402@sun.com> <452684EC.2000402@sun.com> <45268A52.5090400@sun.com> <45268BD1.7050907@sun.com> <45268E7E.3090008@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 1379 Steve, I'll move it to the 23rd as an inception review. If things get resolved, please let me know and I can cancel it. - Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: 650-786-5245/x85245 Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stephen Ehring wrote: > I'm going to be traveling on 10/16, so 10/23 is the earliest we could > have an inception review. If the NIU team can resolve all of David's > issues via e-mail the inception review might not be necessary, but > please schedule it then anyway. > > Since this is going to be a full ARC review, are there any FWARC > interns who would like to volunteer? > > I (or an intern) will produce the 20Q and issues list documents and > place them in the materials directory when they are ready (no later > than one week before the inception review). > > Steve From sacadmin Mon Oct 9 12:33:48 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99JXlmR026279 for ; Mon, 9 Oct 2006 12:33:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k99JXk610682; Mon, 9 Oct 2006 12:33:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6V00F01VO8C300@brm-avmta-1.central.sun.com>; Mon, 09 Oct 2006 13:33:45 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6V00EMYVO81D10@brm-avmta-1.central.sun.com>; Mon, 09 Oct 2006 13:33:44 -0600 (MDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99JXiRn029314; Mon, 09 Oct 2006 12:33:44 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00901VMN1T00@d1-sfbay-10.sun.com> (original mail from Michael.Speer@Sun.COM); Mon, 09 Oct 2006 12:33:44 -0700 (PDT) Received: from 129.149.192.72 ([129.149.192.72]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00D06VO7CBII@d1-sfbay-10.sun.com>; Mon, 09 Oct 2006 12:33:43 -0700 (PDT) Date: Mon, 09 Oct 2006 12:33:43 -0700 From: "Michael F. Speer" Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <45268027.4070904@sun.com> Sender: Michael.Speer@Sun.COM To: David Kahn Cc: Michael.Speer@Sun.COM, Stephen Ehring , Firmware Arch , NIU-SW-Stack-Development@Sun.COM, Ashley Saulsbury Reply-to: Michael.Speer@Sun.COM Message-id: <1160422423.16638.70.camel@mtida> Organization: Sun Microsystems, Inc MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> Status: RO Content-Length: 6068 David: Here's our collective response to the issues and questions you have. Please let us know if this addresses the issues and concerns at hand such that we can move forward with the completion of this case. If more discussion is needed, then we will use the time we have scheduled on the FWARC calendar on Monday the 23rd. David Kahn wrote: > > Issues: > > 1. What's being mapped in the SIU node and why > do we need an SIU parent node? I don't understand > this device tree layout or why it's needed. I might > understand a node representing the niu as the parent, > if, in fact, there are shared registers representing resources > or management controls that apply to both mac nodes, > and then a node for each mac as a peer or child of that > node. What registers are mapped here? What resources are > managed here? If this is artificial, we should get rid of it. The SIU node was generically named because conceptually the PIU also uses this "interface" to access the NCU. From the device tree, though only the NIU devices are it's children. No registers mapped here, it's just providing connectivity into the device tree. > > 2. #interrupt-vectors: Why not use standard interrupts, > interrupt-map and interrupt-map-mask properties? The "#interrupt-vectors" reprents the total number of interrupts for the entire NIU. This approach was taken given the flexibility that can be taken in configuring the NIU's resources. > > 3. Do the NIU interrupts allow software to set the > data sent in the data that gets queued to dev mondo? > Either way, what's the format of the data sent to dev mondo > and is it consistent with the way we're handling existing > interrupts? What are the hv interfaces for NIU interrupts? > How are these events dispatched to an interrupt handler? > The interrupts use the same existing interfaces from VPCI (hvio_intr_xxx). We don't truly used mondos, but these interrupts are handled much like PCI "fixed" interrupts. > 4. Why is the name in the siu MD node "iodevice"? > The siu device was designed to be a peer of the PCI-E bus node in the phys_io node. There is not requirement to call this node 'iodevice', so if you think it should be something else we are open to alternatives. > 5. What is pio-size and pio-base for? Shouldn't > they simply be well-defined entries in the nodes > "reg" property? Same issue for vio*-size and base. > These MD properties are used to construct the "reg" property. We think that what you are asking is that rather than have 3 separate pairs of MD node entries, we could have a single PROP_DATA, right? What do you suggest be the name of this new property? registers? If that is what you are asking, let us know and we will update the binding. > 6. Section 2 does not describe the characteristics > of the "siu" bus adequately. Look at other bus > bindings or bus binding boilerplate text. (c.f. #1) Section 2 was based on the bus binding boilerplate text. I can elaborate on this section if you'd like. Updated binding is in case materials directory. > > 7. Is there another case for how the network interfaces > are allocated to the domains or how they are going to > be used by the OS? How will Linux use them? In case of virtualization, the network interfaces will be assigned to the I/O service domain for the system. It will then be utilized by the LDoms vSwitch of the service domain to move traffic in/out of the system on the behalf of the client domains. All I/O with the NIU is done via this proxied I/O. In the future, a hybrid I/O model will emerge, but this is not ready yet. > > 8. Where is the architecture document describing the overall > NIU software/firmware architecture? Here's a brief description of the architecture for what are doing. It largely mimics the model for what we do for PCI and PCI-Express devices today. In Niagar 2, NIU interfaces are connected to the system not via PCI-Express, but the SIU (System Interface Unit). N2 NIU may be viewed logically as a multi-function device. As with PCI devices it is desired to provide similar configuration, probing and initialization of the NIU device such that a new framework does not need to be invented for this device. With this in mind, here's the software components of the architecture and primary functions of each component: 1) Firmware (OBP): - Provide probing, binding and node creation. - Provide parent nodes with appropriate methods for NIU fcode driver to use OBP resources. 2) SIU/NCU nexus driver - Implement bus-specific DDI functions to support the NIU leaf device drivers. - Insultate the NIU leaf driver from Hypervisor such that NIU leaf driver may maintain a goal of being DDI/DKI compliant. 3) NIU Leaf Driver - Provide driver functions to access the NIU devices. - Manage and handle device specific errors generated by the NIU hardware. - Use DDI/DKI interfaces for interfacing with the operating system. 4) NIU fcode driver/OBP - Create device specific properties in addition to those created by OBP. - Device specific configuration based on machine descriptions - Provide standard Fcode workss for loading/booting over the network. - Provide register and loopback tests. 5) Hypervisor - Provide interfaces to the SIU/NCU nexus driver for handling interrupts and errors as a result of the NIU interracting with the SIU and/or NCU. - Program specific NIU registers that should not be programmed by the NIU Leaf driver because of system security issues at system and domaining level. For more details read the referenced document for any other unaswered questions found at the URL below: http://webhome/stargate/neptune/docs/niu_nexus.pdf > > > The interface table seems to be out of sync with the > document. > > Since many of these questions have been asked already and > haven't been addressed, I'm derailing this case. > > -David > Regards, Michael Speer, Steve Ehring and John Fitzgerald From sacadmin Mon Oct 9 14:15:20 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LFKY4000056 for ; Mon, 9 Oct 2006 14:15:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k99LFH616434; Mon, 9 Oct 2006 14:15:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6W00K0D0DEBU00@brm-avmta-1.central.sun.com>; Mon, 09 Oct 2006 15:15:14 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6W00E140DD1B80@brm-avmta-1.central.sun.com>; Mon, 09 Oct 2006 15:15:14 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99LFDCi022880; Mon, 09 Oct 2006 14:15:13 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k99LFAOf009861; Mon, 09 Oct 2006 14:15:11 -0700 (PDT) Date: Mon, 09 Oct 2006 14:15:09 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <1160422423.16638.70.camel@mtida> To: Michael.Speer@sun.com Cc: Stephen Ehring , Firmware Arch , NIU-SW-Stack-Development@sun.com, Ashley Saulsbury Message-id: <452ABBDD.2060900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <1160422423.16638.70.camel@mtida> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 9161 Thanks for your reply ... Michael F. Speer wrote: >> Issues: >> >> 1. What's being mapped in the SIU node and why >> do we need an SIU parent node? I don't understand >> this device tree layout or why it's needed. I might >> understand a node representing the niu as the parent, >> if, in fact, there are shared registers representing resources >> or management controls that apply to both mac nodes, >> and then a node for each mac as a peer or child of that >> node. What registers are mapped here? What resources are >> managed here? If this is artificial, we should get rid of it. > > The SIU node was generically named because conceptually the PIU also > uses this "interface" to access the NCU. From the device tree, though > only the NIU devices are it's children. No registers mapped here, > it's just providing connectivity into the device tree. Since no registers are mapped, this is unacceptable to have an artificial node in the device tree, but I can understand from the architecture that there might be a reason to have an NIU node as a parent of the mac nodes as I stated in the issue, if the sw design is one in which common functions are managed by one entity and the physical layer is managed by another function. The impression I got from the PRM is that the NIU part of it manages how the device is partitioned, manages virtual and logical devices and groups and basically does everything except the mac physical layer. The two physical mac "functions" handle only the physical layer. So things like checksums, filtering, dma etc, is all handled in the NIU (shared), and only the physical layer is handled by the 2 physical mac functions. Maybe you're providing a less flexible but more traditional view of it so it appears to software as two fully separate and distinct ethernet devices? There's just no "correct" way to create an artificial parent node here, since other things are also below the siu, but we don't publish a node for that logical entity because, while it represents some of the silicon, it doesn't represent anything explicity visible to the software since those things are encapsulated elsewhere. > >> 2. #interrupt-vectors: Why not use standard interrupts, >> interrupt-map and interrupt-map-mask properties? > > The "#interrupt-vectors" reprents the total number of interrupts > for the entire NIU. This approach was taken given the flexibility > that can be taken in configuring the NIU's resources. Yes, that's the same response I received before I wrote this, and if I thought it was resolved, I wouldn't have included it again in this list. The NIU has 64 fixed interrupts (inos) as I read the spec with some help from other people familiar with the NIU. It does not have MSI/X or PCI A-D virtual interrupt wires. We need to find a way to represent this in a normal, generic manner, if it's even needed at all. If you think the number of fixed interrupts changes from n2 -> n3 or vf, andw that we might reuse the NIU as implemented in N2 on future processors then we might want a different interface to provide this information. It's my understanding that on n2, the mapping from logical devices to ino is fixed by the hardware. > >> 3. Do the NIU interrupts allow software to set the >> data sent in the data that gets queued to dev mondo? >> Either way, what's the format of the data sent to dev mondo >> and is it consistent with the way we're handling existing >> interrupts? What are the hv interfaces for NIU interrupts? >> How are these events dispatched to an interrupt handler? >> > > The interrupts use the same existing interfaces from VPCI > (hvio_intr_xxx). We don't truly used mondos, but these > interrupts are handled much like PCI "fixed" interrupts. Yes it does use mondos. When NIU ino #n is armed and triggered (or times out, if you enable that part of the hw interface, with some non yet existing hv interface) a message is queued to dev mondo, targeting the thread programmed into the interrupt table in the PIU. Since the messages end up on the same dev mondo queues as all other interrupts it's imperative that the format of the data be compliant with anything else we queue to dev mondo. It's my understanding that there are basically two choices for the data, the first is a physical format defined by hardware and the second allows software to set mondo data 0 & 1. Since either one that we use creates an interface, that (the data format) must be guaranteed to be unique and documented somewhere. > >> 4. Why is the name in the siu MD node "iodevice"? >> > > The siu device was designed to be a peer of the PCI-E bus node in > the phys_io node. There is not requirement to call this node > 'iodevice', > so if you think it should be something else we are open to alternatives. I don't know how we've worked out this interface from the MD to OBP drivers and the device nodes, but the name should be something related to the NIU in my opinion. I'm not sure what the significance of "iodevice" is. > >> 5. What is pio-size and pio-base for? Shouldn't >> they simply be well-defined entries in the nodes >> "reg" property? Same issue for vio*-size and base. >> > > These MD properties are used to construct the "reg" property. We think > that what you are asking is that rather than have 3 separate pairs of > MD node entries, we could have a single PROP_DATA, right? What do you > suggest be the name of this new property? registers? If that is what > you are asking, let us know and we will update the binding. What do we do for the pci nodes? If we need a generic mechanism here, we should define one. > >> 6. Section 2 does not describe the characteristics >> of the "siu" bus adequately. Look at other bus >> bindings or bus binding boilerplate text. (c.f. #1) > > Section 2 was based on the bus binding boilerplate text. I can elaborate > on this section if you'd like. Updated binding is in case materials > directory. Yes, and this was my comment based on the "binding" text that Stephen added. It's missing stuff, and I don't think "siu" is even appropriate here. > >> 7. Is there another case for how the network interfaces >> are allocated to the domains or how they are going to >> be used by the OS? How will Linux use them? > > In case of virtualization, the network interfaces will be assigned > to the I/O service domain for the system. It will then be utilized > by the LDoms vSwitch of the service domain to move traffic in/out > of the system on the behalf of the client domains. All I/O with > the NIU is done via this proxied I/O. In the future, a hybrid I/O > model will emerge, but this is not ready yet. When it does emerge, how do we know that existing software and will still be able to use the existing interfaces with firmware that supports the new stuff? > >> 8. Where is the architecture document describing the overall >> NIU software/firmware architecture? > > Here's a brief description of the architecture for what are doing. It > largely mimics the model for what we do for PCI and PCI-Express devices > today. > > In Niagar 2, NIU interfaces are connected to the system not via > PCI-Express, but the SIU (System Interface Unit). N2 NIU may be > viewed logically as a multi-function device. As with PCI devices it > is desired to provide similar configuration, probing and > initialization of the NIU device such that a new framework does > not need to be invented for this device. ok, but it's not a pci* device. So we can't do that without a lot of hackery to make it work. So, I've been suggesting we make the software understand that this is a highly integrated device and that it be able to handle it as a highly integrated device. DDI compliance might be nice, but it isn't required for a highly integrated device, so it could be a goal, but not a requirement. It may mean you need an implementation specific "library" for building the different versions of the driver, and the highly integrated version of that "library" may not be ddi compliant, but the pci-express version of the library can be ddi compliant. ("library" means code implementing a common external interface here, not necesarily a libniu.a file.) > > With this in mind, here's the software components of the architecture > and primary functions of each component: > > 2) SIU/NCU nexus driver > - Implement bus-specific DDI functions to support the NIU leaf > device drivers. But there is no bus there. :) > - Insultate the NIU leaf driver from Hypervisor such that NIU > leaf driver may maintain a goal of being DDI/DKI compliant. What benefit is there in that goal? I don't see any for a highly integrated device that doesn't appear or act like a device on a standard bus. (There's other ways to share source code for similar standard bus implementations of this device if that's the real goal here.) > http://webhome/stargate/neptune/docs/niu_nexus.pdf Will read that later. Thanks for the reference. > >> >> The interface table seems to be out of sync with the >> document. This wasn't addressed. Thanks, David From sacadmin Tue Oct 10 08:27:22 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AFRLYt029622 for ; Tue, 10 Oct 2006 08:27:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9AFR4Af000819; Tue, 10 Oct 2006 16:27:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6X00409EXJHP00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Oct 2006 08:27:19 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6X00ITDEXIMEE0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Oct 2006 08:27:19 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AFRHwD009342; Tue, 10 Oct 2006 09:27:18 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00801EU1KT00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Tue, 10 Oct 2006 09:27:17 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00LMXEXGE9W4@mail-amer.sun.com>; Tue, 10 Oct 2006 09:27:17 -0600 (MDT) Date: Tue, 10 Oct 2006 11:25:20 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions In-reply-to: <452ABBDD.2060900@sun.com> Sender: Stephen.Ehring@sun.com To: Firmware Arch Cc: NIU-SW-Stack-Development@sun.com, Ashley Saulsbury Message-id: <452BBB60.2000705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4525B4E4.40804@sun.com> <45268027.4070904@sun.com> <1160422423.16638.70.camel@mtida> <452ABBDD.2060900@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 3136 I've added an issues list to the materials directory so we can track the open issue with this case: http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/issues I've also responded to some of them below... David Kahn wrote: >>> 4. Why is the name in the siu MD node "iodevice"? >>> >> >> The siu device was designed to be a peer of the PCI-E bus node in >> the phys_io node. There is not requirement to call this node >> 'iodevice', >> so if you think it should be something else we are open to alternatives. > > I don't know how we've worked out this interface from the MD > to OBP drivers and the device nodes, but the name should be > something related to the NIU in my opinion. I'm not sure > what the significance of "iodevice" is. We attach OBP device drivers to children of the phys_io node based on 'device-type' property (although we probably should be using 'compatible'). I don't think this ever went to FWARC, as none of the other vpci MD properties underwent FWARC review. The only documentation I found for the 'phys_io' nodes was figure 3A in this document. http://sac.sfbay/FWARC/2005/115/final.materials/md-info.pdf I wanted to keep the MD node name generic for io devices, with the device-type and compatible specifing the actual device (much like the execution unit nodes are all named 'exec_unit' but have the 'mau', 'cwq', etc as the 'type'). >> >>> 5. What is pio-size and pio-base for? Shouldn't >>> they simply be well-defined entries in the nodes >>> "reg" property? Same issue for vio*-size and base. >>> >> >> These MD properties are used to construct the "reg" property. We think >> that what you are asking is that rather than have 3 separate pairs of >> MD node entries, we could have a single PROP_DATA, right? What do you >> suggest be the name of this new property? registers? If that is what >> you are asking, let us know and we will update the binding. > > What do we do for the pci nodes? If we need a generic mechanism > here, we should define one. The PCI MD nodes only have the single zero-length reg line required of all sun4v devices (no addressable registers). Why don't we move all of these properties into a single 'reg' property in the MD? Is that generic enough? >> >>> 6. Section 2 does not describe the characteristics >>> of the "siu" bus adequately. Look at other bus >>> bindings or bus binding boilerplate text. (c.f. #1) >> >> Section 2 was based on the bus binding boilerplate text. I can elaborate >> on this section if you'd like. Updated binding is in case materials >> directory. > > Yes, and this was my comment based on the "binding" text that > Stephen added. It's missing stuff, and I don't think "siu" is > even appropriate here. What is it missing? I'm going to hold off on updating this section until we decide on what we want to call the sun4v child node (if we do end up using a nexus node). >>> The interface table seems to be out of sync with the >>> document. > > This wasn't addressed. The only difference I found was the 'name' property of the sun4v child node, which I've updated. Is there anything else missing? Steve From sacadmin Tue Oct 10 10:47:49 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AHlmwb005714 for ; Tue, 10 Oct 2006 10:47:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9AHllx04289; Tue, 10 Oct 2006 11:47:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6X00E0LLFLGL00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Oct 2006 10:47:45 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6X005THLFKBQ80@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Oct 2006 10:47:44 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AHhw5r000824; Tue, 10 Oct 2006 10:43:58 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9AHhv2M038847; Tue, 10 Oct 2006 10:43:58 -0700 (PDT) Date: Tue, 10 Oct 2006 10:43:59 -0700 From: David Kahn Subject: Re: FWARC 2006/556: NIU/SIU Device Tree Bindings and Machine Description Definitions To: Stephen Ehring Cc: Firmware Arch , NIU-SW-Stack-Development@sun.com, Ashley Saulsbury Message-id: <452BDBDF.4060707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 3045 Stephen Ehring wrote: >>>> 4. Why is the name in the siu MD node "iodevice"? >>>> >>> >>> The siu device was designed to be a peer of the PCI-E bus node in >>> the phys_io node. There is not requirement to call this node >>> 'iodevice', >>> so if you think it should be something else we are open to alternatives. >> >> I don't know how we've worked out this interface from the MD >> to OBP drivers and the device nodes, but the name should be >> something related to the NIU in my opinion. I'm not sure >> what the significance of "iodevice" is. > > We attach OBP device drivers to children of the phys_io node based on > 'device-type' property (although we probably should be using > 'compatible'). I don't think this ever went to FWARC, as none of the > other vpci MD properties underwent FWARC review. The only documentation > I found for the 'phys_io' nodes was figure 3A in this document. > > http://sac.sfbay/FWARC/2005/115/final.materials/md-info.pdf > > I wanted to keep the MD node name generic for io devices, with the > device-type and compatible specifing the actual device (much like the > execution unit nodes are all named 'exec_unit' but have the 'mau', > 'cwq', etc as the 'type'). For this, what's missing (overall, not just for this case) is a probing section in the bus bindings for sun4v and virtual-devices that describe the interfaces that OBP uses to create nodes, including how MD properties map to device node properties and how they are created. We have a similar probing section in the pci binding, if you want an example. It describes how probing is done on pci, what happens if there is an FCode driver, what happens when there isn't an FCode driver (create a default set of properties per node based on stuff in config space, do BAR assignments, etc). So I've been viewing the connection between the MD and OBP and the properties created in the device nodes as what should be documented in the an equivalent section in for sun4v and virtual-devices. I think Hitu is looking into doing this and for sun4v and virtual-devices, that's not part of this case, but if there is an artificial node then you would need the probing section for the artificial node. >>>> 6. Section 2 does not describe the characteristics >>>> of the "siu" bus adequately. Look at other bus >>>> bindings or bus binding boilerplate text. (c.f. #1) >>> >>> Section 2 was based on the bus binding boilerplate text. I can elaborate >>> on this section if you'd like. Updated binding is in case materials >>> directory. >> >> Yes, and this was my comment based on the "binding" text that >> Stephen added. It's missing stuff, and I don't think "siu" is >> even appropriate here. > > What is it missing? I'm going to hold off on updating this section until > we decide on what we want to call the sun4v child node (if we do end up > using a nexus node). Right now you have 1 sentence desribing it as the same as sun4v, but it isn't the same as sun4v. Also there's no section describing the interrupts stuff. -David From sacadmin Mon Oct 16 17:59:38 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H0xc8d013508 for ; Mon, 16 Oct 2006 17:59:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9H0xb201529; Mon, 16 Oct 2006 17:59:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7900E039FDSD00@brm-avmta-1.central.sun.com>; Mon, 16 Oct 2006 18:59:37 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7900E829FC8G10@brm-avmta-1.central.sun.com>; Mon, 16 Oct 2006 18:59:36 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9H0xaZW018075; Mon, 16 Oct 2006 18:59:36 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7900A018X83B00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Mon, 16 Oct 2006 18:59:36 -0600 (MDT) Received: from Sun.COM ([129.148.131.30]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J79000CB9FB8DO3@mail-amer.sun.com>; Mon, 16 Oct 2006 18:59:36 -0600 (MDT) Date: Mon, 16 Oct 2006 20:59:35 -0400 From: Stephen Ehring Subject: FWARC 2006/556 NIU Device Bindings Sender: Stephen.Ehring@Sun.COM To: Firmware Arch , NIU SW Dev Reply-to: Stephen.Ehring@Sun.COM Message-id: <45342AF7.60707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 Status: RO Content-Length: 844 I've restarted the fast-track timer on this case to expire one week from today (10/23). The project team has addressesed all issues. Updated binding and interface table here: http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/niu-siu-binding.txt http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/interface-table.txt Changes from the previous version are here: - Removed #interrupt-vectors property - replaced 'siu' names with 'niu' - removed 'pio*' and 'vio*' properties in favor of a well-defined 'reg' property - added explicit statement defining interrupt translation and format in section 2.1.2.4 - Added section 2.5 to describe OBP probing - modified 'mac-addresses' MD property description to make it required. Please read over the issues to determine if they have been resolved in a satisfactory manner. Steve From sacadmin Mon Oct 16 18:04:50 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H14nlP013548 for ; Mon, 16 Oct 2006 18:04:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9H14hwX015290 for <@sunmail2.sfbay.sun.com:fwarc@sun.com>; Tue, 17 Oct 2006 09:04:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7900M1B9NVAB00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 18:04:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7900JQF9NVTAA0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 18:04:43 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9H14gWp022217 for ; Mon, 16 Oct 2006 19:04:43 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J79004018YN7W00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 19:04:42 -0600 (MDT) Received: from Sun.COM ([129.148.131.30]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7900BCD9NTOY12@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 19:04:42 -0600 (MDT) Date: Mon, 16 Oct 2006 21:04:41 -0400 From: Stephen Ehring Subject: [Fwd: FWARC 2006/556 NIU Device Bindings] Sender: Stephen.Ehring@sun.com To: Firmware Arch Reply-to: Stephen.Ehring@sun.com Message-id: <45342C29.2030806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 Status: RO Content-Length: 348 Although the case cannot expire until next Monday, the project team requested that I ask for an expedited review since no new issues have been raised in over a week. If I can get positive acknowledgment from each member when you have decided that resolution of the issues is sufficient, I would be able to approve the case earlier. Thanks, Steve From sacadmin Mon Oct 16 18:34:22 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H1YLsW014865 for ; Mon, 16 Oct 2006 18:34:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9H1YLn06432; Mon, 16 Oct 2006 19:34:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7900203B180600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Oct 2006 18:34:20 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7900JLZB18U1D0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Oct 2006 18:34:20 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9H1YKX5006205; Mon, 16 Oct 2006 18:34:20 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9H1YIIC093658; Mon, 16 Oct 2006 18:34:19 -0700 (PDT) Date: Mon, 16 Oct 2006 18:34:18 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings To: Stephen Ehring Cc: Firmware Arch , NIU SW Dev Message-id: <4534331A.3020507@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1558 I still think the "child" bus address formats are not quite correct. For the NIU node, there's only a sun4v config-addr, and that node's address format is defined by the sun4v binding. Right? (There are no registers to be mapped in the niu node itself?) The sun4v binding address format is ssss.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh.hhhh llll.llll.llll.llll.llll.llll.llll.llll where ssss is the address type 0000 - cacheable memory address space 1000 - non-cacheable i/o address space 1100 - sun4v config space hh..hh and ll..ll are the offsets into each address space. So, the doc defined a ranges property in the niu node that converts from *what* form of child address space to the address format listed above? That's what we have to describe in this section. Do the children have a sun4v config address? I thought that what we were going to do was to make the ranges property in the niu node have no value meaning the child address and parent address space are 1:1, according to the definition of "ranges" in the 1275 spec and just publish the non-cacheable i/o addresses in the child nodes in the sun4v address format? Did I misunderstand? And, if there is no config-addr in the children, what's the unit-address format (textual and numeric) for the two child nodes? Either way, this needs a bit of work. Also, I don't think we need to publish the exact numeric reg values in the document, unless they are noted as informative. It's good enough to define what each reg entry represents. Those are physical addresses anyway, aren't they? -David From sacadmin Mon Oct 16 18:55:51 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H1toGG015336 for ; Mon, 16 Oct 2006 18:55:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9H1ton11963; Mon, 16 Oct 2006 19:55:50 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7900H01C11IV00@brm-avmta-1.central.sun.com>; Mon, 16 Oct 2006 19:55:49 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7900ERIC108I60@brm-avmta-1.central.sun.com>; Mon, 16 Oct 2006 19:55:48 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9H1tmXc023065; Mon, 16 Oct 2006 18:55:48 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9H1tkeJ094185; Mon, 16 Oct 2006 18:55:47 -0700 (PDT) Date: Mon, 16 Oct 2006 18:55:46 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <4534331A.3020507@sun.com> To: Stephen Ehring Cc: Firmware Arch , NIU SW Dev Message-id: <45343822.8080008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4534331A.3020507@sun.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1086 re-reading the document, It appears the doc format is Is that correct? So a reg prop for a child node might look like: c, 0, 0, 100.0000 # PIO region c, 100.0000, 0, 8000 # VIO 1 c, 200.0000, 0, 8000 # VIO 2 where 'c' is the config-addr of the child. and the same entries with c+1 (or something different from 'c') as the for the second device. The parent ranges property converts to the actual real address for each child, in sun4v address format, with a set of entries for child c, and a set of entries for child c'. I think you might want to require a first entry in the reg prop with a config addr, with offset 0, and size 0 and make the unit-address use the first reg entry for the canonical form of the address, so it would match the CC..CC format defined in the doc. Otherwise the CC..CC format requires the first entry to have an offset of 0, which it does, but it's odd to overload a config addr with a real reg address, otherwise the format would have to be CC..CC,ll..ll if the first entrie offset isn't 0. -David From sacadmin Mon Oct 16 19:00:48 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H20lcj015473 for ; Mon, 16 Oct 2006 19:00:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9H20LBI012080 for <@sunmail3.sfbay.sun.com:fwarc@sun.com>; Tue, 17 Oct 2006 03:00:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7900M03C98EQ00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 19:00:44 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7900EB4C97BF60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 16 Oct 2006 19:00:43 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9H20hsS014364; Mon, 16 Oct 2006 19:00:43 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9H20gRJ094360; Mon, 16 Oct 2006 19:00:42 -0700 (PDT) Date: Mon, 16 Oct 2006 19:00:42 -0700 From: David Kahn Subject: Re: [Fwd: FWARC 2006/556 NIU Device Bindings] To: Stephen Ehring , Firmware Arch Message-id: <4534394A.1060706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 742 Stephen Ehring wrote: > Although the case cannot expire until next Monday, the project team > requested that I ask for an expedited review since no new issues have > been raised in over a week. If I can get positive acknowledgment from > each member when you have decided that resolution of the issues is > sufficient, I would be able to approve the case earlier. Other than the unit-address, reg-format for children of the niu node, everything looks ok to me. To the other fwarc members: Please review and respond to Stephen with an ACK if everything looks ok. If you have any issues, send them now, so we can try to get this case done before the time-out. Please try to get your review done as soon as possible. Thanks, -David From sacadmin Mon Oct 16 19:06:38 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9H26cJs015516 for ; Mon, 16 Oct 2006 19:06:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9H26bn16778; Mon, 16 Oct 2006 20:06:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7900501CJ1IW00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Oct 2006 19:06:37 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7900JZNCJ0TUD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 16 Oct 2006 19:06:36 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9H26aIU014617; Mon, 16 Oct 2006 20:06:36 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7900K01AJKC300@mail-amer.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Mon, 16 Oct 2006 20:06:36 -0600 (MDT) Received: from [129.150.32.214] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J790013WCIZY6K3@mail-amer.sun.com>; Mon, 16 Oct 2006 20:06:36 -0600 (MDT) Date: Mon, 16 Oct 2006 19:06:37 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <45342AF7.60707@Sun.COM> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Cc: NIU SW Dev Message-id: <45343AAD.1080403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45342AF7.60707@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 1329 Stephen Ehring wrote: >I've restarted the fast-track timer on this case to expire one week from >today (10/23). The project team has addressesed all issues. Updated >binding and interface table here: > >http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/niu-siu-binding.txt >http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/interface-table.txt > >Changes from the previous version are here: > >- Removed #interrupt-vectors property >- replaced 'siu' names with 'niu' >- removed 'pio*' and 'vio*' properties in favor of a well-defined 'reg' >property >- added explicit statement defining interrupt translation and format in >section 2.1.2.4 >- Added section 2.5 to describe OBP probing >- modified 'mac-addresses' MD property description to make it required. > >Please read over the issues to determine if they have been resolved in a >satisfactory manner. > >Steve > > > Since there is no references to SIU in the specification, can we change the title of the specification and the file name to not include SIU in it? At least the "Title" should not include SIU in it. Thanks. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Tue Oct 17 09:21:23 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9HGLMNZ029958 for ; Tue, 17 Oct 2006 09:21:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9HGLM205325; Tue, 17 Oct 2006 09:21:22 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7A00D0NG3KY200@brm-avmta-1.central.sun.com>; Tue, 17 Oct 2006 10:21:20 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7A004MOG3J1YC0@brm-avmta-1.central.sun.com>; Tue, 17 Oct 2006 10:21:19 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9HGLJX6028857; Tue, 17 Oct 2006 10:21:19 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7A00401FPKQF00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Tue, 17 Oct 2006 10:21:19 -0600 (MDT) Received: from Sun.COM ([129.148.131.30]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7A000JLG3I8DT3@mail-amer.sun.com>; Tue, 17 Oct 2006 10:21:19 -0600 (MDT) Date: Tue, 17 Oct 2006 12:21:18 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <45343822.8080008@sun.com> Sender: Stephen.Ehring@Sun.COM To: David Kahn Cc: Firmware Arch , NIU SW Dev Reply-to: Stephen.Ehring@Sun.COM Message-id: <453502FE.4050002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4534331A.3020507@sun.com> <45343822.8080008@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 Status: RO Content-Length: 5398 For reference, I've included the current (version 1.5 of the binding) properties output. David Kahn wrote On 10/16/06 21:55,: > re-reading the document, > > It appears the doc format is > Is that correct? > > So a reg prop for a child node might look like: > > c, 0, 0, 100.0000 # PIO region > c, 100.0000, 0, 8000 # VIO 1 > c, 200.0000, 0, 8000 # VIO 2 > > where 'c' is the config-addr of the child. > > and the same entries with c+1 (or something different from 'c') > as the for the second device. This is not entirely true based on the current binding. What we currently have is: niu: ranges 00000000 00000000 80000081 00000000 00000000 05008000 00000001 02000000 80000081 02000000 00000000 05008000 network@0: reg 00000000 00000000 00000000 01000000 00000000 01000000 00000000 00008000 00000000 05000000 00000000 00008000 network@1: reg 00000001 02000000 00000000 01000000 00000001 03000000 00000000 00008000 00000001 07000000 00000000 00008000 > > The parent ranges property converts to the actual real address for each > child, in sun4v address format, with a set of entries > for child c, and a set of entries for child c'. > > I think you might want to require a first entry > in the reg prop with a config addr, with offset 0, and size 0 > and make the unit-address use the first reg entry for the > canonical form of the address, so it would match the CC..CC > format defined in the doc. Just so I'm clear, what you are requesting is the following (note the additional reg line, and the modified ranges so that the same reg offsets are used for both child devices). If that's what you are asking, I'm okay with it. Does the project team have any input? niu: ranges 00000000 00000000 80000081 00000000 00000000 05008000 00000001 00000000 80000081 02000000 00000000 05008000 network@0: reg 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 00000000 01000000 00000000 00008000 00000000 05000000 00000000 00008000 network@1: reg 00000001 00000000 00000000 00000000 00000001 00000000 00000000 01000000 00000001 01000000 00000000 00008000 00000001 05000000 00000000 00008000 > Otherwise the CC..CC format requires the first entry > to have an offset of 0, which it does, but it's odd > to overload a config addr with a real reg address, > otherwise the format would have to be CC..CC,ll..ll > if the first entrie offset isn't 0. > > -David > {0} ok cd /niu@80 {0} ok .properties ranges 00000000 00000000 80000081 00000000 00000000 05008000 00000001 02000000 80000081 02000000 00000000 05008000 reg c0000080 00000000 00000000 00000000 compatible SUNW,niumx #size-cells 00000002 #address-cells 00000002 name niu {0} ok {0} ok cd network@0 {0} ok .properties local-mac-address 00 14 4f 3f 8e 30 interrupts 00000010 00000011 00000012 00000013 00000014 00000015 00000016 00000017 00000018 00000019 0000001a 0000001b 0000001c 0000001d 0000001e 0000001f 00000020 00000021 00000022 reg 00000000 00000000 00000000 01000000 00000000 01000000 00000000 00008000 00000000 05000000 00000000 00008000 compatible SUNW,niusl rx-dma-channels 00 00 00 00 00 00 00 08 tx-dma-channels 00 00 00 00 00 00 00 08 name network {0} ok {0} ok cd .. {0} ok cd network@1 {0} ok {0} ok .properties local-mac-address 00 14 4f 3f 8e 31 interrupts 00000023 00000024 00000025 00000026 00000027 00000028 00000029 0000002a 0000002b 0000002c 0000002d 0000002e 0000002f 00000030 00000031 00000032 00000033 reg 00000001 02000000 00000000 01000000 00000001 03000000 00000000 00008000 00000001 07000000 00000000 00008000 compatible SUNW,niusl rx-dma-channels 00 00 00 08 00 00 00 08 tx-dma-channels 00 00 00 08 00 00 00 08 name network {0} ok -- Stephen Ehring Sun Microsystems (781)-442-2479 stephen.ehring@sun.com From sacadmin Tue Oct 17 09:36:33 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9HGaXIg002019 for ; Tue, 17 Oct 2006 09:36:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9HGaWn11140; Tue, 17 Oct 2006 10:36:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7A0024KGSW5C00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Oct 2006 09:36:32 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7A00KZEGSNWR20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Oct 2006 09:36:23 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9HGaMWI012056; Tue, 17 Oct 2006 09:36:23 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9HGaLGU014529; Tue, 17 Oct 2006 09:36:22 -0700 (PDT) Date: Tue, 17 Oct 2006 09:36:20 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <453502FE.4050002@Sun.COM> To: Stephen.Ehring@sun.com Cc: Firmware Arch , NIU SW Dev Message-id: <45350684.5070402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4534331A.3020507@sun.com> <45343822.8080008@sun.com> <453502FE.4050002@Sun.COM> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 2076 Stephen Ehring wrote: > This is not entirely true based on the current binding. What we > currently have is: > > niu: > ranges 00000000 00000000 80000081 00000000 00000000 05008000 > 00000001 02000000 80000081 02000000 00000000 05008000 > network@0: > reg 00000000 00000000 00000000 01000000 > 00000000 01000000 00000000 00008000 > 00000000 05000000 00000000 00008000 > network@1: > reg 00000001 02000000 00000000 01000000 > 00000001 03000000 00000000 00008000 > 00000001 07000000 00000000 00008000 Why should the child fcode have to know what instance it is in order to create its own "reg" prop? That's what ranges is for. I guess I just don't understand your bus binding for the "niu" bus. What is CC..CC supposed to be? A fake "niu" config addr, or a sun4v config-addr? You're using 0 and 1, so does that mean it's a fake "niu" config addr? > Just so I'm clear, what you are requesting is the following (note the > additional reg line, and the modified ranges so that the same reg > offsets are used for both child devices). If that's what you are asking, > I'm okay with it. > niu: > ranges 00000000 00000000 80000081 00000000 00000000 05008000 > 00000001 00000000 80000081 02000000 00000000 05008000 > network@0: > reg 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 01000000 > 00000000 01000000 00000000 00008000 > 00000000 05000000 00000000 00008000 > network@1: > reg 00000001 00000000 00000000 00000000 > 00000001 00000000 00000000 01000000 > 00000001 01000000 00000000 00008000 > 00000001 05000000 00000000 00008000 That seems better to me. You might want to check with Balaji to make sure. (And better text in the document to describe the fake bus binding, etc.) -David From sacadmin Tue Oct 17 14:06:26 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9HL6OmR012792 for ; Tue, 17 Oct 2006 14:06:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9HL6NMK020805; Wed, 18 Oct 2006 05:06:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7A00245TALQK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Oct 2006 14:06:21 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7A00G1ZTAKY970@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Oct 2006 14:06:20 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9HL6KjR020330; Tue, 17 Oct 2006 14:06:20 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7A00J01T5AMA00@d1-sfbay-09.sun.com> (original mail from Wesley.Shao@Sun.COM); Tue, 17 Oct 2006 14:06:20 -0700 (PDT) Received: from [129.146.96.108] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7A00JHBTAJLJQC@d1-sfbay-09.sun.com>; Tue, 17 Oct 2006 14:06:20 -0700 (PDT) Date: Tue, 17 Oct 2006 14:08:14 -0700 From: Wesley Shao Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <45350684.5070402@sun.com> Sender: Wesley.Shao@sun.com To: Firmware Arch Cc: NIU SW Dev Message-id: <4535463E.1080807@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4534331A.3020507@sun.com> <45343822.8080008@sun.com> <453502FE.4050002@Sun.COM> <45350684.5070402@sun.com> User-Agent: Thunderbird 2.0b1pre (X11/20061016) Status: RO Content-Length: 3394 David Kahn wrote: > > > Stephen Ehring wrote: > >> This is not entirely true based on the current binding. What we >> currently have is: >> >> niu: >> ranges 00000000 00000000 80000081 00000000 00000000 05008000 >> 00000001 02000000 80000081 02000000 00000000 05008000 >> network@0: >> reg 00000000 00000000 00000000 01000000 >> 00000000 01000000 00000000 00008000 >> 00000000 05000000 00000000 00008000 >> network@1: >> reg 00000001 02000000 00000000 01000000 >> 00000001 03000000 00000000 00008000 >> 00000001 07000000 00000000 00008000 > > Why should the child fcode have to know what instance > it is in order to create its own "reg" prop? That's > what ranges is for. Are you referring to the addr.hi cell in child node with the values of 00000000 and 00000001? Either we distinguish it in addr.hi or we have unique values in addr.lo. Or, I suppose we could use the unit-addr (network@0, network@1) to distinguish them? I would prefer the unit-addr if it is doable. > I guess I just don't understand your bus binding for > the "niu" bus. What is CC..CC supposed to be? > A fake "niu" config addr, or a sun4v config-addr? My interpretation is it is just part of the address. In this fake niu bus, there is no config space. > You're using 0 and 1, so does that mean it's a fake > "niu" config addr? > >> Just so I'm clear, what you are requesting is the following (note the >> additional reg line, and the modified ranges so that the same reg >> offsets are used for both child devices). If that's what you are asking, >> I'm okay with it. > >> niu: >> ranges 00000000 00000000 80000081 00000000 00000000 05008000 >> 00000001 00000000 80000081 02000000 00000000 05008000 >> network@0: >> reg 00000000 00000000 00000000 00000000 >> 00000000 00000000 00000000 01000000 >> 00000000 01000000 00000000 00008000 >> 00000000 05000000 00000000 00008000 >> network@1: >> reg 00000001 00000000 00000000 00000000 >> 00000001 00000000 00000000 01000000 >> 00000001 01000000 00000000 00008000 >> 00000001 05000000 00000000 00008000 > > > > That seems better to me. You might want to check with > Balaji to make sure. I don't understand this config reg entry. Why does every bus have to have a config space? The PCI bus does not really need it (for identification purpose) because we have all the BDFs encoded in addr-hi or every other "reg" entry. We pretty much have it so drivers can map them in (or for the case device don't have any BARs?). OK, so we have it for a good reason, they are real registers. The sun4v bus does not really need it because there is no real register, but we ran out of place to hold the devhandle because the px device node would otherwise have no reg entry at all. For the niu bus, there is no physical register behind this config reg entry, and we don't need a place holder for devhandle since this is not a sun4v device (rather a niu device), so why have it? I ran out of reasons to have it. Wes > > (And better text in the document to describe the fake > bus binding, etc.) > > -David From sacadmin Wed Oct 18 02:27:48 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9I9RlmK028480 for ; Wed, 18 Oct 2006 02:27:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9I9RVfd016775; Wed, 18 Oct 2006 10:27:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7B00809RM4RK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Oct 2006 02:27:40 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7B00KWRRM39X80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Oct 2006 02:27:39 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9I9Rdrm022956; Wed, 18 Oct 2006 02:27:39 -0700 (PDT) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9I9RbMn037158; Wed, 18 Oct 2006 02:27:38 -0700 (PDT) Date: Wed, 18 Oct 2006 02:27:36 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings To: Wesley Shao Cc: Firmware Arch , NIU SW Dev Message-id: <4535F388.4020105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 1182 Wesley Shao wrote: >> Why should the child fcode have to know what instance >> it is in order to create its own "reg" prop? That's >> what ranges is for. > > Are you referring to the addr.hi cell in child node with the values > of 00000000 and 00000001? No. The childs reg properties are relative to the entries in the parents ranges. Usually FCode drivers just know that they have registers relative to some offset for some size, based on my-space or my-addr at probe time. If the hardware guys have layed out the address space correctly, then low cell of the reg-props should be the same in both children. The ranges property in the parent node adds the offset for each instance for each range, which is hopefully a fixed value for each child. So, in this case, the hi-cell is 0 or 1 to distinguish the instance, the lo cell could be the same, I think. > I don't understand this config reg entry. Why does every bus have > to have a config space? Every bus doesn't have a config address. But this is a fake bus, and if you want the unit address of the children to be 0 and 1, there has to be a way to encode that somewhere, and define it in the fake bus binding. -David From sacadmin Wed Oct 18 09:27:04 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9IGR4G8006157 for ; Wed, 18 Oct 2006 09:27:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9IGR3n18874; Wed, 18 Oct 2006 10:27:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7C00155B118K00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Oct 2006 09:27:01 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7C00BZTB106PA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Oct 2006 09:27:00 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IGQxgu020189; Wed, 18 Oct 2006 10:26:59 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7C00B01AU45000@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Wed, 18 Oct 2006 10:26:59 -0600 (MDT) Received: from [129.148.131.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7C0099LB0VWL62@mail-amer.sun.com>; Wed, 18 Oct 2006 10:26:59 -0600 (MDT) Date: Wed, 18 Oct 2006 12:26:54 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <4535F388.4020105@sun.com> Sender: Stephen.Ehring@Sun.COM To: David Kahn Cc: Wesley Shao , Firmware Arch , NIU SW Dev Message-id: <453655CE.8070201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 3218 David Kahn wrote: > > > Wesley Shao wrote: > >>> Why should the child fcode have to know what instance >>> it is in order to create its own "reg" prop? That's >>> what ranges is for. >> >> Are you referring to the addr.hi cell in child node with the values >> of 00000000 and 00000001? > > No. The childs reg properties are relative to the entries in > the parents ranges. > > Usually FCode drivers just know that they have registers > relative to some offset for some size, based on my-space > or my-addr at probe time. If the hardware guys have layed out > the address space correctly, then low cell of the reg-props > should be the same in both children. The ranges property in > the parent node adds the offset for each instance for each > range, which is hopefully a fixed value for each child. > > So, in this case, the hi-cell is 0 or 1 to distinguish the > instance, the lo cell could be the same, I think. That is my understanding, too. I'm resending the proposed ranges/reg property below to reiterate what is being proposed. > >> I don't understand this config reg entry. Why does every bus have >> to have a config space? > > Every bus doesn't have a config address. But this is a fake > bus, and if you want the unit address of the children to be > 0 and 1, there has to be a way to encode that somewhere, > and define it in the fake bus binding. But it is defined in the binding as the upper cell of the child address (section 2.1.1). From my understanding, DaveK's issue was that we were overloading the first reg line (which represents real addressable region) to also be a config address. encode/decode unit uses the first regline entry to uniquely determine the unit address. If we rewhack the ranges property in the niu node as shown below, the two address cells of the first to reg entries are the same and the lower cell is zero, so technically we can get away without the config line, but Dave didn't want to overload that regline with the assumption of the zero low order bit. Is that correct? Before, 00000001 02000000 ---> encode-unit ---> " 1" so we have "network@1" But " 1" ---> decode-unit ---> 00000001 02000000 So we had to have some way of hard-coding the 0x02000000 to be associated with a cfg-handle of '1'. If we explicitly state that the first reg line is only concerned with the upper cell, then we don't have this problem. By the way, do people think it might be clearer to differentiate this fake bus from the sun4v bus by renaming 'cfg-handle' to 'port' and replacing "cc........cc" with "pp........pp"? Steve niu: ranges 00000000 00000000 80000081 00000000 00000000 05008000 00000001 00000000 80000081 02000000 00000000 05008000 network@0: reg 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 00000000 01000000 00000000 00008000 00000000 05000000 00000000 00008000 network@1: reg 00000001 00000000 00000000 00000000 00000001 00000000 00000000 01000000 00000001 01000000 00000000 00008000 00000001 05000000 00000000 00008000 From sacadmin Wed Oct 18 09:29:50 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9IGTnZB006262 for ; Wed, 18 Oct 2006 09:29:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9IGTRM3010533; Wed, 18 Oct 2006 17:29:36 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7C0043FB5KBQ00@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 10:29:44 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7C0035JB5IW930@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 10:29:42 -0600 (MDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IGTg0T022279; Wed, 18 Oct 2006 09:29:42 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7C00A01B5ECH00@d1-sfbay-10.sun.com> (original mail from J.Tapia@Sun.COM) ; Wed, 18 Oct 2006 09:29:42 -0700 (PDT) Received: from [129.153.85.35] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7C00COBB5HOH5I@d1-sfbay-10.sun.com>; Wed, 18 Oct 2006 09:29:42 -0700 (PDT) Date: Wed, 18 Oct 2006 09:29:40 -0700 From: Jorge Tapia Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <453655CE.8070201@sun.com> Sender: J.Tapia@sun.com To: Stephen Ehring Cc: David Kahn , Wesley Shao , Firmware Arch , NIU SW Dev Reply-to: J.Tapia@sun.com Message-id: <45365674.5080209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 3536 Wes, John, Michael, and May please review and respond asap. We need to close this item today so Steve can produce the binary. Thanks, Jorge Stephen Ehring wrote On 10/18/06 09:26,: > David Kahn wrote: > >> >> >> Wesley Shao wrote: >> >>>> Why should the child fcode have to know what instance >>>> it is in order to create its own "reg" prop? That's >>>> what ranges is for. >>> >>> >>> Are you referring to the addr.hi cell in child node with the values >>> of 00000000 and 00000001? >> >> >> No. The childs reg properties are relative to the entries in >> the parents ranges. >> >> Usually FCode drivers just know that they have registers >> relative to some offset for some size, based on my-space >> or my-addr at probe time. If the hardware guys have layed out >> the address space correctly, then low cell of the reg-props >> should be the same in both children. The ranges property in >> the parent node adds the offset for each instance for each >> range, which is hopefully a fixed value for each child. >> >> So, in this case, the hi-cell is 0 or 1 to distinguish the >> instance, the lo cell could be the same, I think. > > That is my understanding, too. I'm resending the proposed ranges/reg > property below to reiterate what is being proposed. > >> >>> I don't understand this config reg entry. Why does every bus have >>> to have a config space? >> >> >> Every bus doesn't have a config address. But this is a fake >> bus, and if you want the unit address of the children to be >> 0 and 1, there has to be a way to encode that somewhere, >> and define it in the fake bus binding. > > But it is defined in the binding as the upper cell of the child > address (section 2.1.1). From my understanding, DaveK's issue was that > we were overloading the first reg line (which represents real > addressable region) to also be a config address. encode/decode unit > uses the first regline entry to uniquely determine the unit address. > If we rewhack the ranges property in the niu node as shown below, the > two address cells of the first to reg entries are the same and the > lower cell is zero, so technically we can get away without the config > line, but Dave didn't want to overload that regline with the > assumption of the zero low order bit. Is that correct? > > Before, > 00000001 02000000 ---> encode-unit ---> " 1" so we have "network@1" > But > " 1" ---> decode-unit ---> 00000001 02000000 > So we had to have some way of hard-coding the 0x02000000 to be > associated with a cfg-handle of '1'. If we explicitly state that the > first reg line is only concerned with the upper cell, then we don't > have this problem. > > By the way, do people think it might be clearer to differentiate this > fake bus from the sun4v bus by renaming 'cfg-handle' to 'port' and > replacing "cc........cc" with "pp........pp"? > > Steve > > niu: > ranges 00000000 00000000 80000081 00000000 00000000 05008000 > 00000001 00000000 80000081 02000000 00000000 05008000 > network@0: > reg 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 01000000 > 00000000 01000000 00000000 00008000 > 00000000 05000000 00000000 00008000 > network@1: > reg 00000001 00000000 00000000 00000000 > 00000001 00000000 00000000 01000000 > 00000001 01000000 00000000 00008000 > 00000001 05000000 00000000 00008000 > > > From sacadmin Wed Oct 18 10:29:13 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9IHTDRR008011 for ; Wed, 18 Oct 2006 10:29:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9IHTCf24615; Wed, 18 Oct 2006 10:29:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7C0060BDWO6O00@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 11:29:12 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7C003FNDWNW190@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 11:29:11 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9IHTA9U029520; Wed, 18 Oct 2006 10:29:10 -0700 (PDT) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9IHT8jE049396; Wed, 18 Oct 2006 10:29:09 -0700 (PDT) Date: Wed, 18 Oct 2006 10:29:08 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <453655CE.8070201@sun.com> To: Stephen Ehring Cc: Wesley Shao , Firmware Arch , NIU SW Dev Message-id: <45366464.6080304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 243 Stephen Ehring wrote: > By the way, do people think it might be clearer to differentiate this > fake bus from the sun4v bus by renaming 'cfg-handle' to 'port' and > replacing "cc........cc" with "pp........pp"? I do. Good idea. -David From sacadmin Wed Oct 18 13:44:19 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9IKiJrO011811 for ; Wed, 18 Oct 2006 13:44:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9IKiFf19365; Wed, 18 Oct 2006 13:44:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7C00D0RMXR3B00@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 14:44:15 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7C009TGMXRPT50@brm-avmta-1.central.sun.com>; Wed, 18 Oct 2006 14:44:15 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IKiFjG001395; Wed, 18 Oct 2006 14:44:15 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7C00401MRL5H00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Wed, 18 Oct 2006 14:44:15 -0600 (MDT) Received: from [129.148.131.30] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7C001UDMXQY634@mail-amer.sun.com>; Wed, 18 Oct 2006 14:44:15 -0600 (MDT) Date: Wed, 18 Oct 2006 16:44:14 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <45365674.5080209@Sun.COM> Sender: Stephen.Ehring@Sun.COM To: Firmware Arch Cc: NIU SW Dev Message-id: <4536921E.306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> <45365674.5080209@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 858 Per DaveK's request, I've updated the case materials to add the zero-length port (configuration) reg property entry, and explained in the niu child address format section that this entry describes the unit address. I've also modified instances of 'cfg-handle' to 'port' when talking about the network node identifier. Finally (per Hitendra's request), I've removed 'SIU' from the binding title. The actual file is under SCCS history, so I left the filename alone (you can use the link 'n2-niu-binding.txt' if you'd like). http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/n2-niu-binding.txt Interface table has been updated, too. http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/interface-table.txt FWARC members; can you please give me positive acknowledgment when you've had time to review the materials. Thanks, Steve From sacadmin Thu Oct 19 09:39:50 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JGdoI9013679 for ; Thu, 19 Oct 2006 09:39:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JGdoL07315; Thu, 19 Oct 2006 09:39:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E0070D6AC7800@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 09:39:48 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E004P66ABRY20@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 09:39:47 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9JGdlXI016316; Thu, 19 Oct 2006 09:39:47 -0700 (PDT) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9JGdlqD091829; Thu, 19 Oct 2006 09:39:47 -0700 (PDT) Date: Thu, 19 Oct 2006 09:39:47 -0700 From: David Kahn Subject: Re: FWARC 2006/556 NIU Device Bindings To: Stephen Ehring Cc: Firmware Arch , NIU SW Dev Message-id: <4537AA53.8040403@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 952 Approve -David Stephen Ehring wrote: > Per DaveK's request, I've updated the case materials to add the > zero-length port (configuration) reg property entry, and explained in > the niu child address format section that this entry describes the unit > address. > > I've also modified instances of 'cfg-handle' to 'port' when talking > about the network node identifier. > > Finally (per Hitendra's request), I've removed 'SIU' from the binding > title. The actual file is under SCCS history, so I left the filename > alone (you can use the link 'n2-niu-binding.txt' if you'd like). > > http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/n2-niu-binding.txt > > > Interface table has been updated, too. > > http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/interface-table.txt > > > FWARC members; can you please give me positive acknowledgment when > you've had time to review the materials. > > Thanks, > Steve From sacadmin Thu Oct 19 09:41:55 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JGftQO013700 for ; Thu, 19 Oct 2006 09:41:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JGfs221722; Thu, 19 Oct 2006 10:41:54 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E00K096DSU200@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 10:41:52 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E00GWO6DRC470@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 10:41:52 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9JGfpbP017757; Thu, 19 Oct 2006 09:41:51 -0700 (PDT) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9JGfoHF091991; Thu, 19 Oct 2006 09:41:51 -0700 (PDT) Date: Thu, 19 Oct 2006 09:41:50 -0700 From: David Kahn Subject: email vote - FWARC 2006/556 NIU Device Bindings To: Stephen Ehring Cc: Firmware Arch , NIU SW Dev Message-id: <4537AACE.1020403@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) Status: RO Content-Length: 101 Please vote by COB today. (Approve, Reject, Abstain) I already voted to approve. Thanks, David From sacadmin Thu Oct 19 09:51:41 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JGpdKF013984 for ; Thu, 19 Oct 2006 09:51:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9JGpUmp013172; Fri, 20 Oct 2006 00:51:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7E006036TZDQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Oct 2006 09:51:35 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7E006TB6TY9700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Oct 2006 09:51:34 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JGpYeU014661; Thu, 19 Oct 2006 10:51:34 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E006016P08A00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) ; Thu, 19 Oct 2006 10:51:34 -0600 (MDT) Received: from [129.149.2.123] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E007YD6TXR7P6@mail-amer.sun.com>; Thu, 19 Oct 2006 10:51:34 -0600 (MDT) Date: Thu, 19 Oct 2006 09:51:33 -0700 From: Sunit Jain Subject: Re: email vote - FWARC 2006/556 NIU Device Bindings In-reply-to: <4537AACE.1020403@sun.com> Sender: S.Jain@sun.com To: David Kahn Cc: Stephen Ehring , Firmware Arch , NIU SW Dev Reply-to: S.Jain@sun.com Message-id: <4537AD15.2020607@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_91x/Ffe6b9nZwb3xhaaVGA)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4537AACE.1020403@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 5777 This is a multi-part message in MIME format. --Boundary_(ID_91x/Ffe6b9nZwb3xhaaVGA) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT I vote to approve. Regards, Sunit David Kahn wrote On 10/19/06 09:41,: > > Please vote by COB today. (Approve, Reject, Abstain) > > I already voted to approve. > > Thanks, > David > > > -- Sunit Jain Sun Microsystems, Inc. 7788 Gateway Blvd., Bldg 20, Mailstop UNWK20-210, Newark, CA 94560 Phone/Fax 510-996-7099 Internal x31726 --Boundary_(ID_91x/Ffe6b9nZwb3xhaaVGA) Content-type: multipart/related; boundary="Boundary_(ID_oFviNzskpkYsswKLRpPb/g)" --Boundary_(ID_oFviNzskpkYsswKLRpPb/g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I vote to approve.

Regards,
Sunit


David Kahn wrote On 10/19/06 09:41,:

Please vote by COB today. (Approve, Reject, Abstain)

I already voted to approve.

Thanks,
David




--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
7788 Gateway Blvd., Bldg 20,
Mailstop UNWK20-210,
Newark, CA 94560
Phone/Fax 510-996-7099
Internal x31726


--Boundary_(ID_oFviNzskpkYsswKLRpPb/g) Content-id: Content-type: image/gif; name=Sunlogo.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sunlogo.gif R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_oFviNzskpkYsswKLRpPb/g) Content-id: Content-type: image/gif; name=Sun2.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sun2.gif R0lGODlhrAB2AMQAAPGbUO6LL/jFl/Wwcq7D0cfV31qEoP738oKituHq7Z62x9Xg 5uyBHvvau/a6hP3q2fvhyf3z6fnRrP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKhWGMaKqubOu+cCzP dG1PiEHcfO//wKAsYToIj8ikEqkwIJbQqHSKyhWo2KzWtjBtv+DwqKkQm89S0wLN bgOJBqN7TpeVnvW8XkXe+/cmV3+DcyYJhIhoXSeJjWEETo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQakw7LCx66jyrJW zbGf0K1Nm9OpkHjXptnbqYvepgdF4aXJ5ZjS6JyV650ljO6XcHLyk4H2l335kvD8 kuMMHPrX6BnBRN0OIqKnEJHBhn8SQvTDcKKfhxbzSMxYp+IRCA0iiGgAQcSDkAMA //wYwODBDAcASsoQENNHyi34kLCUMOEBgwAiWD4AwOAHgAAuZRBt8JIBUxQwZxDd su+IAwYOJghg0HLC1KlbljZ9OgKASqVFtYBDIoHBgAksGQiYEEAl0atyRUgIwKDm 1b1uU0xtgJUoAJEoJBDlyhQC0QBvJ3AV0XfC1ZRYJXN1ugICXwY87/Kd2yBugJJX IWTGOwAxjXM/fAKtizVCYKIDrgIlPGAvUN14k4oY/NPBaBSEASh2GmE036w/Kau8 CsC4U8IBQq4gKqEBU8MsgULIHd4y15hXBVy2oU4IX58C6hIOnfZrV6IRrjLVj4J4 1rZZlcVASUttxZNqKlUm2f90nF0F3VnbgSbgcGmNMJmDItQlnQ13JMHSVUNhdV99 RS22WQP88TchYVmx2B+JKHK24Iwz8ueigits9ROBJE4QgYlFqbjZZjbAkQReQG0V AFBe9UiUcObtJyOFE7joooAuLfWXj5VFVyNnWz3owgO6NUkld5pFSRmTPcDmg2qV ERaYmWayNABIc6U4pZlWZjaCnQ0UWBmGfEnQFoMhPSkZkwai4JJtJTrZEpxq0iUX SKGdNkN7QRynGU90TvXAZ4M2uKd/VfopgmfncWbiYeb9ZFasP4G6mAMfvsjVXGBN ZRpflba12Vt8kQXDRkGAhJiyqz4FkggRNCCBTCeJVC39Cs9G+2gDUPYkwQPRItaA AMYaGgEEJZ1ErmsRdNdTXiNEO22z9Fb57Uk9aWdSd0nhO0MX2jQUVR4B1aOQA67V 4SZHbHDKcBvVPFwHshKj0WHFbqyFMRtGbtzGLx6LsXDIWoxMMhbMnCxGyiqDwXLL WzgMMxUyzyxFzTZDgXPOSuzMsyg6/Ixy0EJnQnTRUWCEdM/FLJ10004vYXLUbUJN NRIgX/1Dx1oLoXHXQFwMNhAUj31DxGb/4HPas1jNtg0Fv83D13LT0E7d7B2N9ytu 7w0D137HUHbgLKxNuAiwHP6CP4q/UFXjtxggCOQrME75Co9fjkJOmnfuOQ0hAAA7 --Boundary_(ID_oFviNzskpkYsswKLRpPb/g)-- --Boundary_(ID_91x/Ffe6b9nZwb3xhaaVGA)-- From sacadmin Thu Oct 19 10:22:52 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JHMphn014939 for ; Thu, 19 Oct 2006 10:22:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9JHMapF006145; Thu, 19 Oct 2006 18:22:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E0090R89ZY400@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 10:22:47 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E0045289YRY60@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 10:22:46 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JHMk2e002277; Thu, 19 Oct 2006 10:22:46 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00C0183EJF00@d1-sfbay-09.sun.com> (original mail from Tony.Sumpter@Sun.COM); Thu, 19 Oct 2006 10:22:46 -0700 (PDT) Received: from sun.com ([10.6.92.195]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E00BSM89VIK50@d1-sfbay-09.sun.com>; Thu, 19 Oct 2006 10:22:44 -0700 (PDT) Date: Thu, 19 Oct 2006 10:22:42 -0700 From: Tony Sumpter Subject: Re: email vote - FWARC 2006/556 NIU Device Bindings In-reply-to: <4537AACE.1020403@sun.com> Sender: Tony.Sumpter@sun.com To: Firmware Arch Cc: NIU SW Dev Message-id: <4537B462.1040008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4537AACE.1020403@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 169 I vote to approve. Tony. David Kahn wrote: > > Please vote by COB today. (Approve, Reject, Abstain) > > I already voted to approve. > > Thanks, > David > > > From sacadmin Thu Oct 19 14:59:59 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JLxxLF021301 for ; Thu, 19 Oct 2006 14:59:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JLxvf25039; Thu, 19 Oct 2006 14:59:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E0060FL3WY700@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 14:59:56 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E00KM6L3VPA60@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Oct 2006 14:59:56 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JLxtOH012272; Thu, 19 Oct 2006 14:59:55 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00F01L1ALX00@d1-sfbay-09.sun.com> (original mail from Yanmin.Sun@Sun.COM); Thu, 19 Oct 2006 14:59:55 -0700 (PDT) Received: from [129.153.85.30] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E001AYL3PDR5J@d1-sfbay-09.sun.com>; Thu, 19 Oct 2006 14:59:49 -0700 (PDT) Date: Thu, 19 Oct 2006 14:59:48 -0700 From: Yanmin Sun Subject: Re: email vote - FWARC 2006/556 NIU Device Bindings In-reply-to: <4537AACE.1020403@sun.com> Sender: Yanmin.Sun@Sun.COM To: David Kahn Cc: Stephen Ehring , Firmware Arch , NIU SW Dev Reply-to: Yanmin.Sun@Sun.COM Message-id: <4537F554.4060807@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4537AACE.1020403@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 179 Vote to approve. Yanmin David Kahn wrote On 10/19/06 09:41,: > > Please vote by COB today. (Approve, Reject, Abstain) > > I already voted to approve. > > Thanks, > David > > > From sacadmin Thu Oct 19 16:03:48 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JN3luQ022732 for ; Thu, 19 Oct 2006 16:03:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JN3l214629; Thu, 19 Oct 2006 17:03:47 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E00C1PO2A6100@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 17:03:46 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E00BFOO28GE70@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 17:03:44 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JN3iph015681; Thu, 19 Oct 2006 16:03:44 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00M01NZ0JJ00@d1-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Thu, 19 Oct 2006 16:03:44 -0700 (PDT) Received: from [129.153.85.31] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E00DXSO27VR1H@d1-sfbay-09.sun.com>; Thu, 19 Oct 2006 16:03:44 -0700 (PDT) Date: Thu, 19 Oct 2006 16:03:43 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <4536921E.306@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Cc: NIU SW Dev Message-id: <4538044F.8040300@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> <45365674.5080209@Sun.COM> <4536921E.306@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 2275 Stephen Ehring wrote On 10/18/06 13:44,: > Per DaveK's request, I've updated the case materials to add the > zero-length port (configuration) reg property entry, and explained in > the niu child address format section that this entry describes the unit > address. > > I've also modified instances of 'cfg-handle' to 'port' when talking > about the network node identifier. I don't agree with definition of "port" since it is going to cause confusion since we do not have a definition for "port" other then keeping it same as what "cfg-handle" represents. As per 2006/072, cfg-handle is 64-bit value representing a device. As per this case "port" is representing the same thing (which is 64-bit number to represent a device). May be we should define "port" being a 64-bit value representing a port of a device instead of representing the device itself (I think this is the case here since it is not referring to a virtual device but rather a port of a virtual device). > > Finally (per Hitendra's request), I've removed 'SIU' from the binding > title. The actual file is under SCCS history, so I left the filename > alone (you can use the link 'n2-niu-binding.txt' if you'd like). > > http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/n2-niu-binding.txt > Please delete the niu-siu-binding.txt file from the materials directory and check in n2-niu-binding.txt file so that a version number is established for the specification. > > Interface table has been updated, too. > > http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/interface-table.txt > > > FWARC members; can you please give me positive acknowledgment when > you've had time to review the materials. Other then my comments above, I do not have any other comments or issues with this case. If the definition of "port" is changed to following then I will approve this case or else I will abstain. port PROP_VAL Yes A 64-bit unsigned integer identifying a port of a device uniquely. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Thu Oct 19 20:25:34 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9K3PXO7026104 for ; Thu, 19 Oct 2006 20:25:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9K3PQxk020190; Fri, 20 Oct 2006 11:25:32 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7F0010306HJW00@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 21:25:29 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7F00GBR06HNI50@brm-avmta-1.central.sun.com>; Thu, 19 Oct 2006 21:25:29 -0600 (MDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9K3PTIY013405; Thu, 19 Oct 2006 21:25:29 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00001XTCEG00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Thu, 19 Oct 2006 21:25:29 -0600 (MDT) Received: from [192.168.2.48] ([66.31.86.247]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7F009IK06CWLO2@mail-amer.sun.com>; Thu, 19 Oct 2006 21:25:29 -0600 (MDT) Date: Thu, 19 Oct 2006 23:25:24 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <4538044F.8040300@Sun.COM> Sender: Stephen.Ehring@sun.com To: Hitendra Zhangada Cc: Firmware Arch , NIU SW Dev Message-id: <453841A4.7010009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> <45365674.5080209@Sun.COM> <4536921E.306@sun.com> <4538044F.8040300@Sun.COM> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 74 I vote approve. I'll update the IAM file when I'm in the office tomorrow. From sacadmin Fri Oct 20 11:59:40 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9KIxdMB013122 for ; Fri, 20 Oct 2006 11:59:40 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9KIxIUE019418; Fri, 20 Oct 2006 19:59:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7G003037FCQJ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Oct 2006 11:59:36 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7G00FGI7FB28B0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Oct 2006 11:59:36 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9KIxZ95016796; Fri, 20 Oct 2006 12:59:35 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7G00D0175WL700@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM); Fri, 20 Oct 2006 12:59:35 -0600 (MDT) Received: from [129.148.184.139] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7G00MMK7FA3AH7@mail-amer.sun.com>; Fri, 20 Oct 2006 12:59:35 -0600 (MDT) Date: Fri, 20 Oct 2006 14:57:35 -0400 From: Stephen Ehring Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <4538044F.8040300@Sun.COM> Sender: Stephen.Ehring@sun.com To: Hitendra Zhangada Cc: Firmware Arch , NIU SW Dev Message-id: <45391C1F.1050106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> <45365674.5080209@Sun.COM> <4536921E.306@sun.com> <4538044F.8040300@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2124 Comments below. Hitendra Zhangada wrote: > Stephen Ehring wrote On 10/18/06 13:44,: >> Per DaveK's request, I've updated the case materials to add the >> zero-length port (configuration) reg property entry, and explained in >> the niu child address format section that this entry describes the >> unit address. >> >> I've also modified instances of 'cfg-handle' to 'port' when talking >> about the network node identifier. > > I don't agree with definition of "port" since it is going to cause > confusion since we do not have a definition for "port" other then > keeping it same as what "cfg-handle" represents. As per 2006/072, > cfg-handle is 64-bit value representing a device. As per this case > "port" is representing the same thing (which is 64-bit number to > represent a device). The confusion is arising because I used cfg-handle in the first place. 2006/072 does not apply to the network nodes since they are not sun4v bus children. The port number does indeed represent the device since the NIU block can be thought of as two devices. The 'port' terminology is used throughout the PRM. Also, 'port' has to be defined as a 32 bit number since we only use one address cell to describe the child port number. >> >> Finally (per Hitendra's request), I've removed 'SIU' from the binding >> title. The actual file is under SCCS history, so I left the filename >> alone (you can use the link 'n2-niu-binding.txt' if you'd like). >> >> http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/n2-niu-binding.txt >> > > Please delete the niu-siu-binding.txt file from the materials > directory and check in n2-niu-binding.txt file so that a version > number is established for the specification. I don't really see why this matters, but if the file name is really bothering you, I'll change it. I've moved all old versions of the onepager into a 'materials.old' directory so we have the history of the documents progression. Now that the case is approved, I'm not going to use SCCS any more (we can use the version number in the table in the document like we do for other bindings). Steve From sacadmin Fri Oct 20 15:43:30 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9KMhTWk017664 for ; Fri, 20 Oct 2006 15:43:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9KMgQAL013107; Fri, 20 Oct 2006 23:43:17 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7G0080BHS5ZI00@brm-avmta-1.central.sun.com>; Fri, 20 Oct 2006 16:43:17 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7G007L2HS5A050@brm-avmta-1.central.sun.com>; Fri, 20 Oct 2006 16:43:17 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9KMhH8a012731; Fri, 20 Oct 2006 15:43:17 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7G00D01HRHTJ00@d1-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Fri, 20 Oct 2006 15:43:17 -0700 (PDT) Received: from [129.153.85.31] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7G005HSHS27GK3@d1-sfbay-09.sun.com>; Fri, 20 Oct 2006 15:43:15 -0700 (PDT) Date: Fri, 20 Oct 2006 15:43:14 -0700 From: Hitendra Zhangada Subject: Re: FWARC 2006/556 NIU Device Bindings In-reply-to: <45391C1F.1050106@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: NIU SW Dev Message-id: <45395102.6050505@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <4535F388.4020105@sun.com> <453655CE.8070201@sun.com> <45365674.5080209@Sun.COM> <4536921E.306@sun.com> <4538044F.8040300@Sun.COM> <45391C1F.1050106@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 2934 Stephen Ehring wrote On 10/20/06 11:57,: > > Comments below. > > Hitendra Zhangada wrote: > >> Stephen Ehring wrote On 10/18/06 13:44,: >> >>> Per DaveK's request, I've updated the case materials to add the >>> zero-length port (configuration) reg property entry, and explained in >>> the niu child address format section that this entry describes the >>> unit address. >>> >>> I've also modified instances of 'cfg-handle' to 'port' when talking >>> about the network node identifier. >> >> >> I don't agree with definition of "port" since it is going to cause >> confusion since we do not have a definition for "port" other then >> keeping it same as what "cfg-handle" represents. As per 2006/072, >> cfg-handle is 64-bit value representing a device. As per this case >> "port" is representing the same thing (which is 64-bit number to >> represent a device). > > > The confusion is arising because I used cfg-handle in the first place. > 2006/072 does not apply to the network nodes since they are not sun4v > bus children. The port number does indeed represent the device since the > NIU block can be thought of as two devices. The 'port' terminology is > used throughout the PRM. In that case I would think cfg-handle would have been just fine. > > Also, 'port' has to be defined as a 32 bit number since we only use one > address cell to describe the child port number. The bindings says it is a 64-bit value. So, are you saying that it is defined as 64-bit value but we will only use 32-bits of it? > >>> >>> Finally (per Hitendra's request), I've removed 'SIU' from the binding >>> title. The actual file is under SCCS history, so I left the filename >>> alone (you can use the link 'n2-niu-binding.txt' if you'd like). >>> >>> http://sac.eng/Archives/CaseLog/arc/FWARC/2006/556/materials/n2-niu-binding.txt >>> >> >> >> Please delete the niu-siu-binding.txt file from the materials >> directory and check in n2-niu-binding.txt file so that a version >> number is established for the specification. > > > I don't really see why this matters, but if the file name is really > bothering you, I'll change it. I've moved all old versions of the > onepager into a 'materials.old' directory so we have the history of the > documents progression. Now that the case is approved, I'm not going to > use SCCS any more (we can use the version number in the table in the > document like we do for other bindings). Leaving a bindings with SIU in the name would be confusing to developer trying to access it. When someone goes to see the specification in the directory there will be two documents. We only have one specification and hence only one document is needed. Thanks. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu