<br><tt><font size=2>devicetree-discuss-bounces+christian.rund=de.ibm.com@ozlabs.org
wrote on 17.12.2008 02:00:07:<br>
<br>
> Send devicetree-discuss mailing list submissions to<br>
> devicetree-discuss@ozlabs.org<br>
> <br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss<br>
> or, via email, send a message with subject or body 'help' to<br>
> devicetree-discuss-request@ozlabs.org<br>
> <br>
> You can reach the person managing the list at<br>
> devicetree-discuss-owner@ozlabs.org<br>
> <br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of devicetree-discuss digest..."<br>
> <br>
> <br>
> Today's Topics:<br>
> <br>
> 1. Re: Reminder 1: Device Tree documentation discussion
for<br>
> Cell/B.E. binding DRAFT - see Digest Vol
6, Issue 1 (Grant Likely)<br>
> <br>
> <br>
> ----------------------------------------------------------------------<br>
> <br>
> Message: 1<br>
> Date: Tue, 16 Dec 2008 15:08:17 -0700<br>
> From: "Grant Likely" <grant.likely@secretlab.ca><br>
> Subject: Re: Reminder 1: Device Tree documentation discussion for<br>
> Cell/B.E. binding DRAFT - see Digest Vol 6, Issue
1<br>
> To: "Christian Rund" <Christian.Rund@de.ibm.com><br>
> Cc: devicetree-discuss@ozlabs.org<br>
> Message-ID:<br>
> <fa686aa40812161408j3672ba5cs7d8526cd643b69de@mail.gmail.com><br>
> Content-Type: text/plain; charset=ISO-8859-1<br>
> <br>
> On Tue, Dec 16, 2008 at 7:03 AM, Christian Rund<br>
> <Christian.Rund@de.ibm.com> wrote:<br>
> > this is a reminder for review. Feedback appreciated!<br>
> > For convenience I removed the disclaimer etc.<br>
> ><br>
> > On dec 5th I posted our (complete) draft version of the Cell/B.E.
device<br>
> > tree documentation.<br>
> ><br>
> > Goal of these review should be to finally establish the document
as<br>
> > Power.org<br>
> > PAPR Binding for the Cell/B.E. processor.<br>
> ><br>
> > Please review and give us feedback.<br>
> <br>
> First comments; This document is quite verbose. Much time is
spent<br>
> describing how standard properties work (ie; content of the 'reg'
and<br>
> 'ranges' properties). Reviewing takes more effort when there
is a<br>
> large amount of boilerplate to filter.<br>
> <br>
> Second, very few nodes have a 'compatible' value defined. Currently,<br>
> the 'compatible' list is the preferred method for device drivers to<br>
> find supported devices in the tree. Each distinct device should
have<br>
> a unique compatible value defined.<br>
> <br>
> More comments below<br>
> <br>
> > 1 "be" node<br>
> [...]<br>
> > "device-type" property<br>
> ><br>
> > Standard property name
which specifies the type of the node.<br>
> ><br>
> > Encoded as with encode-string.<br>
> ><br>
> > Default value is {
"be" }.<br>
> <br>
> Is a new OpenFirmware driver interface being defined for working with<br>
> 'be' devices? </font></tt>
<br>
<br><tt><font size=2>No</font></tt>
<br>
<br><tt><font size=2>> If not then the device-type property should not
be<br>
> defined.</font></tt>
<br>
<br><tt><font size=2>The device-type property instances will be removed
where not </font></tt>
<br><tt><font size=2>necessary or no OpenFirmware binding recommendations
exist</font></tt>
<br><tt><font size=2>respectively.</font></tt>
<br><tt><font size=2><br>
> > "model" property<br>
> > property name: Specifies
model of node.<br>
> > Encoded as with encode-string.<br>
> > Default value is {
"IBM,CBEA" }.<br>
> <br>
> > "ibm,dt-version" property<br>
> <br>
> I'm concerned about the usage model of this property. It is
not<br>
> common for driver to go looking for an additional version property<br>
> when interpreting node data. Are all drivers expected to test
the<br>
> value of this property? What should they do when the major or
minor<br>
> values do not match?</font></tt>
<br>
<br><tt><font size=2>This property is meant to be informational. Drivers
could check whenever</font></tt>
<br><tt><font size=2>they require a certain level.</font></tt>
<br><tt><font size=2> <br>
> > 1 ioc node<br>
> ><br>
> ><br>
> > The Input/Output Controller (IOC) node contains among others
the properties<br>
> > specifying the address range of MMIO register space controlling
the IOC.<br>
> ><br>
> > "reg" property<br>
> ><br>
> > Default property name: Property to specify the MMIO offset of
the IOC,<br>
> > which are two sets of registers each represented by an < offset,
size ><br>
> > pair.<br>
> ><br>
> > prop-encoded-array: Encoded as with encode-phys for the offset
values,<br>
> > encode-int for the size values.<br>
> ><br>
> > The array consists of four 32-bit values to represent two <
offset, size ><br>
> > pairs. Value one in this array corresponds to the first offset
value within<br>
> > the child address space, encoded as with encode-phys. Value two
corresponds<br>
> > to the size, encoded as with encode-int. Value three in this
array<br>
> > corresponds to the second offset value, value four to the second
size.<br>
> ><br>
> > Default value is { 0x00510000 0x00001000 0x00511000 0x00001000
}.<br>
> <br>
> These spaces are contiguous; what is the reason for the two array
entries?</font></tt>
<br>
<br><tt><font size=2>The spaces are in fact contiguous, but belong to two
different units.</font></tt>
<br><tt><font size=2>0x00510xxx covers the IOC Address Translation MMIO
Registers, whereras</font></tt>
<br><tt><font size=2>0x00511xxx covers the I/O Command MMIO Registers.</font></tt>
<br><tt><font size=2>Despite, Linux is mapping the two ranges in one single
step, which means</font></tt>
<br><tt><font size=2>the range can well be summarized to </font></tt>
<br><tt><font size=2> Default value
is { 0x00510000 0x00002000 }.<br>
</font></tt>
<br><tt><font size=2>> <br>
> > "device_type" property<br>
> ><br>
> > Standard property name: Specify the type of this node<br>
> ><br>
> > Encoded as with encode-string<br>
> ><br>
> > Default value is { "ioc" }<br>
> <br>
> Again, if an OpenFirmware driver interface is not being defined, then<br>
> don't use the device-type property.<br>
</font></tt>
<br><tt><font size=2>see comment above.</font></tt>
<br>
<br><tt><font size=2>> > 2 "bic0" node<br>
> [...]<br>
> > "device_type" property<br>
> ><br>
> > Standard property name: Property to specify the type of this
node.<br>
> ><br>
> > Encoded as with encode-string.<br>
> ><br>
> > Default value is { "bic0" }.<br>
> <br>
> ditto on device_type</font></tt>
<br>
<br><tt><font size=2>see comment above</font></tt>
<br><tt><font size=2><br>
> <br>
> > 3 "bic1" node<br>
> <br>
> This is identical to bic0<br>
> <br>
> > 4 "mic-tm" node<br>
> > 6 "ppe-mmio" node<br>
> <br>
> mic-tm, ppe-mmio, and the bic* node documentation just duplicates
the<br>
> definition of standard node properties. In this case is should
be<br>
> sufficient to describe what device the node describes an that it uses<br>
> the standard properties.</font></tt>
<br>
<br><tt><font size=2>I will change the documentation to describe only one
of a kind.</font></tt>
<br><tt><font size=2><br>
> <br>
> > 5 "pervasive" node<br>
> ><br>
> ><br>
> > The pervasive node node represents the pervasive unit in
the device tree.<br>
> > T>he main property value is the address range of MMIO register
space<br>
> > controlling the pervasive unit.<br>
> <br>
> Umm, what is a "pervasive unit"?</font></tt>
<br>
<br><tt><font size=2>The pervasive node represents the 'Pervasive MMIO
Registers' (i.e.</font></tt>
<br><tt><font size=2>Pervasive Monitor, Power Management and Thermal Management
described</font></tt>
<br><tt><font size=2>in the Cell/B.E. public register spec.</font></tt>
<br><tt><font size=2><br>
> <br>
> > "device_type" property<br>
> ><br>
> > Standard property name: Property to specify the type of this
node.<br>
> ><br>
> > Encoded as with encode-string.<br>
> ><br>
> > Default value is { "pervasive" }.<br>
> <br>
> ditto on device_type</font></tt>
<br>
<br><tt><font size=2>See comment above.</font></tt>
<br><tt><font size=2><br>
> > "ppe-throttle-temp" property<br>
> > "ppe-end-throttle-temp" property<br>
> > "ppe-full-throttle-temp" property<br>
> > "spe-throttle-temp" property<br>
> > "spe-end-throttle-temp" property<br>
> > "spe-full-throttle-temp" property<br>
> <br>
> These properties look good.<br>
> <br>
> > 7 "interrupt-controller" node<br>
> ><br>
> > The Cell Broadband Engine Architecture processor contains an
Internal<br>
> > Interrupt Controller (IIC), which is handling all the interrupts
from the<br>
> > PPE, the SPE and the connected IO.<br>
> ><br>
> > "reg" property<br>
> ><br>
> > Standard property name: Property to specify the MMIO offset of
the IIC, one<br>
> > range for each of the two threads contained in each PPE and one
range for<br>
> > the common MMIO.<br>
> ><br>
> > prop-encoded-array: Consisting of six 32-bit values. The values
form three<br>
> > < offset,length > pairs of the denoted space encoded as
with encode-phys<br>
> > for the offsets and encode-int for the sizes<br>
> ><br>
> > 1. for MMIO space of thread one<br>
> ><br>
> > 2. for MMIO space of thread two<br>
> ><br>
> > 3. for MMIO space of the common PPE MMIO space.<br>
> ><br>
> > Default value is<br>
> > { 0x00508400 0x00000020 0x00508420 0x00000020 0x00508000 0x00001000
}.<br>
> ><br>
> ><br>
> ><br>
> > "device_type" property<br>
> ><br>
> > Standard property name: Property to specify the type of this
node.<br>
> ><br>
> > Encoded as with encode-string.<br>
> ><br>
> > Default value is { "CBEA-Internal-Interrupt-Controller"
}.<br>
> <br>
> ditto on device_type. In fact, you should not be inventing new
values<br>
> for device_type at all. Either use an already established<br>
> device_type, or don't assign the property at all. And, if you
do use<br>
> device_type, you are claiming that OpenFirmware has a driver interface<br>
> for the device.</font></tt>
<br>
<br><tt><font size=2>See comment above.<br>
<br>
> > 8 "spe" nodes<br>
> ><br>
> > The Cell Broadband Engine Architecture processor contains eight
SPEs, each<br>
> > consisting of an SPU, 256kB local store and a Memory Flow Controller
(MFC).<br>
> > The SPEs are connected to the EIB (Element Interconnect Bus)
ring. The<br>
> > access to the internal devices is done via MMIO reads, with a
fixed offset<br>
> > to the Cell Broadband Engine processor base address.<br>
> ><br>
> > "reg" property<br>
> ><br>
> > Standard property name: Specifies the MMIO offset and size of
the SPEs<br>
> > Local Storage, Problem-State, Privilege 2 Area and Privilege
1 Area.<br>
> ><br>
> > prop-encoded array: Encoded as four < offset, length >
pairs per SPE<br>
> > encoded as with encode-phys for the offsets, encode-int for the
size. The<br>
> > pairs define the following SPE units:<br>
> ><br>
> > 1. Local Store (LS)<br>
> ><br>
> > 2. Problem State MMIO Registers<br>
> ><br>
> > 3. Privilege State 2 MMIO Registers<br>
> ><br>
> > 4. Privilege State 1 MMIO Registers<br>
> ><br>
> > The property exists once in each spe node.<br>
> <br>
> I like the above description. It provides good information about
how<br>
> data is organized in the reg property.<br>
> <br>
> > "device_type" property<br>
> ><br>
> > Standard property name: Specifies the type of this node.<br>
> ><br>
> > Encoded as with encode-string.<br>
> ><br>
> > Default value is {"spe" }.<br>
> <br>
> ditto on device_type<br>
</font></tt>
<br><tt><font size=2>See comment above.</font></tt>
<br><tt><font size=2><br>
> > "interrupts" property<br>
> ><br>
> > Standard property name: Property to specify the interrupt numbers
of the<br>
> > interrupts issued by SPE.<br>
> ><br>
> > prop-encoded array: List of interrupt numbers issued by the SPE.
Each value<br>
> > in the list is encoded as with encode-int.<br>
> ><br>
> > The property exists once in each spe node.<br>
> ><br>
> > Default values for SPEs are<br>
> ><br>
> ><br>
> ><br>
> > |# |Property Value
|<br>
> > |spe@0 |{ 0x4, 0x104, 0x204 }
|<br>
> > |spe@80000 |{ 0x7, 0x107, 0x207 }
|<br>
> > |spe@100000 |{ 0x3, 0x103, 0x203 }
|<br>
> > |spe@180000 |{ 0x8, 0x108, 0x208 }
|<br>
> > |spe@200000 |{ 0x2, 0x102, 0x202 }
|<br>
> > |spe@280000 |{ 0x9, 0x109, 0x209 }
|<br>
> > |spe@300000 |{0x1, 0x101, 0x201 }
|<br>
> > |spe@380000 |{0xa, 0x10a, 0x20a }
|<br>
> ><br>
> ><br>
> > "vicinity" property<br>
> ><br>
> > property name: Specifies the direct neighbouring componentes
on the EIB<br>
> > ring related to each SPE.<br>
> ><br>
> > prop-encoded array: Pairs of phandles ( < phandle, phandle
>) of the<br>
> > neighbouring nodes, each phandle is encoded as with encode-int.<br>
> ><br>
> > The property exists once in each spe node.<br>
> ><br>
> > Default values for SPEs<br>
> ><br>
> ><br>
> ><br>
> > |# |Property Value
|<br>
> > |spe@0 |{ phandle(mic-tm, SPE 3) }
|<br>
> > |spe@80000 |{ phandle(mic-tm, SPE 2) }
|<br>
> > |spe@100000 |{ phandle(SPE 0, SPE 4) }
|<br>
> > |spe@180000 |{ phandle(SPE 1, SPE 5) }
|<br>
> > |spe@200000 |{ phandle(SPE 2, SPE 6) }
|<br>
> > |spe@280000 |{ phandle(SPE 3, SPE 7) }
|<br>
> > |spe@300000 |{ phandle(SPE 4, BIC0) }
|<br>
> > |spe@380000 |{ phandle(SPE 5, BIC0) }
|<br>
> ><br>
> ><br>
> > "physical-id" property<br>
> ><br>
> > property name: Property to specify the physical id of an SPE.<br>
> ><br>
> > Default values for the physical id is encoded as with encode-int.<br>
> <br>
> Unless there is some shared register set that needs the SPE physical<br>
> id to operate then I encourage you not to define this property. If
it<br>
> is just a logical number, the I think it is better to rely on the
node<br>
> name instead of an arbitrarily defined logical number. However,
if<br>
> there is a register set shared between the SPEs that needs the SPE<br>
> number, then you should follow the lead of other existing bindings
and<br>
> use the property name "cell-index" instead of physical-id.<br>
</font></tt>
<br><tt><font size=2>The "physical-id" property is used by Linux
(see information on ppc-patch below).</font></tt>
<br>
<br><tt><font size=2>linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org</font></tt>
<br><tt><font size=2>Subject: spu_manage: fix spu_unit_number for celleb
device tree<br>
<br>
From: Christian Krafft <krafft@de.ibm.com><br>
<br>
New device trees provide "physical-id".<br>
Celleb device tree provide the "unit-id".<br>
Legacy device tree used the reg property for the physical id of an spe.<br>
This patch fixes find_spu_unit_number to look for the spu id in that order.<br>
The length is checked to avoid misinterpretation in case the attributes<br>
unit-id or reg do not contain the id.<br>
<br>
Signed-off-by: Christian Krafft <krafft@de.ibm.com><br>
</font></tt>
<br><tt><font size=2>Index: linux/arch/powerpc/platforms/cell/spu_manage.c<br>
===================================================================<br>
--- linux.orig/arch/powerpc/platforms/cell/spu_manage.c<br>
+++ linux/arch/powerpc/platforms/cell/spu_manage.c<br>
@@ -48,10 +48,18 @@ static u64 __init find_spu_unit_number(s<br>
{<br>
const
unsigned int *prop;<br>
int
proplen;<br>
+<br>
+
/* new device trees should provide the physical-id attribute */<br>
prop
= of_get_property(spe, "physical-id", &proplen);<br>
if
(proplen == 4)<br>
return (u64)*prop;<br>
<br>
+
/* celleb device tree provides the unit-id */<br>
+
prop = of_get_property(spe, "unit-id", &proplen);<br>
+
if (proplen == 4)<br>
+
return
(u64)*prop;<br>
+<br>
+
/* legacy device trees provide the id in the reg attribute */<br>
prop
= of_get_property(spe, "reg", &proplen);<br>
if
(proplen == 4)<br>
return (u64)*prop;</font></tt>
<br><tt><font size=2><br>
> Cheers,<br>
> g.</font></tt>
<br>
<br><tt><font size=2>Thanks</font></tt>
<br><tt><font size=2>Chris</font></tt>
<br><tt><font size=2><br>
> <br>
> -- <br>
> Grant Likely, B.Sc., P.Eng.<br>
> Secret Lab Technologies Ltd.<br>
> <br>
> <br>
> ------------------------------<br>
> <br>
> _______________________________________________<br>
> devicetree-discuss mailing list<br>
> devicetree-discuss@ozlabs.org<br>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss<br>
> <br>
> <br>
> End of devicetree-discuss Digest, Vol 6, Issue 7<br>
> ************************************************<br>
</font></tt>