* Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
@ 2008-12-16 14:03 Christian Rund
[not found] ` <OF89278B7C.B7D060FF-ONC1257521.004C9E27-C1257521.004D3F55-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Christian Rund @ 2008-12-16 14:03 UTC (permalink / raw)
To: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
[-- Attachment #1.1.1: Type: text/plain, Size: 24980 bytes --]
Dear Subscribers and Readers,
this is a reminder for review. Feedback appreciated!
For convenience I removed the disclaimer etc.
On dec 5th I posted our (complete) draft version of the Cell/B.E. device
tree documentation.
See also in devicetree-discuss Digest, Vol 6, Issue 1.
Goal of these review should be to finally establish the document as
Power.org
PAPR Binding for the Cell/B.E. processor.
Please review and give us feedback.
Thanks.
_________________________________
DRAFT Power.org Standard for the Cell Broadband Engine architecture device
tree
Table of Contents
1 Overview 5
1.1 Scope 5
1.2 Purpose 5
2 Terminology 5
2.1 Definitions 5
2.2 Abbreviations 5
2.3 Acronyms 5
3 Introduction 6
4 The Cell Broadband Engine architecture processor representation
in
the device tree 7
4.1 "be" node 7
4.1.1 ioc node 10
4.1.2 "bic0" node 11
4.1.3 "bic1" node 11
4.1.4 "mic-tm" node 12
4.1.5 "pervasive" node 12
4.1.6 "ppe-mmio" node 14
4.1.7 "interrupt-controller" node 15
4.1.8 "spe" nodes 16
DRAFT Power.org Standard for the Cell Broadband Engine architecture device
tree
Overview
1 Scope
This document is intended to apply the Power.org Standard for Power
Architecture Platform Requirements (Workstation, Server) PAPR on
Cell Broadband Engine architecture compliant processors. This
encompasses requirements therein and additional requirements for
device tree nodes and properties pertaining to Cell Broadband
Engine
architecture compliant processors.
2 Purpose
This document is intended to indicate the architectural option and
feature set of Cell Broadband Engine architecture processors to
software via Open Firmware (OF).
Terminology
This document uses definitions, abbreviations and acronyms as
indicated below or in the PAPR specification [3].
1 Definitions
Device Tree: Open Firmware data structure representing the set of
devices attached to a system. See [1] for details.
2 Abbreviations
Define key abbreviations here (use "paragraph" plus tab), such as
l.t.s.f.l.r. Leaving this section for later revisions of this
document - to be removed if not used !!!!!!!!!!!!
3 Acronyms
Define key acronyms here (use "paragraph" style with tabs"), such
as
EIB Element Interconnect Bus
IIC Internal Interrupt Controller
IOC Input Output Controller
MMIO Memory Mapped Input Output
OF Open Firmware (see [1]).
PPE PowerPC Processing Element
SPE Synergistic Processing Element
Introduction
The specific goals of this specification are as follows:
. To provide the address map for the components in a Cell
Broadband Engine Architecture processor. Subcomponent address
information is detected by the OF and passed to the OS in the
device tree.
. To build upon the OF boot environment defined in IEEE 1275,
IEEE Standard for Boot (Initialization Configuration)
Firmware:
Core Requirements and Practices.
. To provide device tree nodes and property values necessary
for
access to and configuration of the Cell Broadband Engine
Architecture processor subcomponents.
The Cell Broadband Engine architecture processors are implemented as
systems on a chip. Besides a PowerPC processor it contains eight
Synergistic Processing Elements (SPEs) in addition. Each SPE has access to
256kB of associated local store. All logic of the non-processor part is
accessed via MMIO. Mapping and structure of the MMIO space are described
with the "be" node. A nodes' unit address is the MMIO address of that
particular BE. The "be" node is located in the device tree as child of the
root node '/'.
The Cell Broadband Engine architecture processor representation in the
device tree
The following contents are outlined according to the hierarchy of the
components in the sub-tree containing the components of the Cell Broadband
Engine processor.
All device tree nodes detailed below contain a "name" property in addition
to the mentioned properties as follows
. Specifies the name of the node
. Encoded as with encode-string
. Default is the name of the node
Throughout the description below the notation
phandle(<expression>) is used to retrieve the phandle of a
node. A phandle of a device tree node is the cell-sized datum
identifying the particular device tree node.
1 "be" node
The "be" node contains a set of properties and sub-nodes, which describe
the structure of a Cell Broadband Engine Architecture processor. All the
devices are contained, except the Power PC processor core nodes, which are
located under the "/cpus" path according to the PowerPC Processor binding
to the IEEE 1275 standard.
"reg" property
Standard property name specifying the < address, size > pair
of
the Cell Broadband Engine processor's MMIO mapped registers.
Prop-encoded array: Encoded as with encode-phys for the
address. The size part is encoded with two encode-ints.
The array consists of four 32-bit values. Value one and two
in
this array correspond to the 64-bit address value the the
Cell
Broadband Engine Architecture processor is mapped into. Value
three and four correspond to the 64-bit size. Both pairs
represent the < address, size > pair of MMIO mapped registers
in the Cell Broadband Engine processor's MMIO mapped register
space.
Default value is { 0x00000iii 0x00000000 0x00000000
0x000800000
}, where iii is the offset defined by the hardware settings.
"ranges" property
Standard property name which specifies the mapping of the
child
of the "be" node within the "be" nodes' parent address space
using the < child, parent, size > triple.
Prop-encoded array: Encoded as with encode-int for the childs
range, encode-phys for the parents range and encode-int for
the
size.
The array consists of four 32-bit values. Value one in this
array corresponds to the 32-bit child address encoded as with
encode-int. Value two and three correspond to the 64-bit
parent
address encoded as with encode-phys. Value three in this
array
corresponds to the 32-bit size.
Default value is { 0x00000000 0x00000iii 0x00000000
0x00080000
}, mapping address 0 of child to 0x00000iii 00000000.
"device-type" property
Standard property name which specifies the type of the node.
Encoded as with encode-string.
Default value is { "be" }.
"model" property
property name: Specifies model of node.
Encoded as with encode-string.
Default value is { "IBM,CBEA" }.
"ibm,dt-version" property
property name: Specifies the current device tree version number. The
version number format is major.minor.
Whenever the device tree is changed or extended in a way that OS changes
are required the major version is changed.
The minor version is changed when at least one new property is added or
removed.
Encoded as with encode-string
The default value is { 1.1 }
"#address-cells" property
property name which specifies the number of address cells for child nodes
to the current node.
Encoded as with encode-int.
Default value is { 1 }
"#size-cells" property
Standard property name which specifies the number of size cells for child
nodes to the current node.
Encoded as with encode-int.
Default value is { 1 }
"ibm,associativity" property
property name: Property to define the associativity domains for this
resource.
See Power Architecture Platform Requirements (PAPR) [3], Sections
14.11.2.2, 15.2, 15.3, 18.3 and C.6.2.2 for details on this property.
Set values to { 4 0x00000000, 0x00000000, 0x0000000i, 0x0000000i }; i = 0
for associativity to Cell Broadband Engine processor 0, i = 1 for
associativity to Cell Broadband Engine processor 1.
"interrupt-parent" property
property name: Property that specifies the interrupt handler responsible
for this node.
The value represents a phandle of the interrupt handler node, encoded as
with encode-int.
Default value is { phandle( my-self/interrupt-controller) }
"cpus" property
property name: Porperty to specify the PPE component of the Cell Broadband
Engine architecture processor chip.
phandle of the cpu node, encoded as with encode-int.
Default value is { phandle(/cpus/PowerPC,BE@i) }; i = 0 for Cell Broadband
Engine Architecture processor 0, i = 1 for Cell Broadband Engine
Architecture processor 1.
1 ioc node
The Input/Output Controller (IOC) node contains among others the
properties
specifying the address range of MMIO register space controlling the IOC.
"reg" property
Default property name: Property to specify the MMIO offset of the IOC,
which are two sets of registers each represented by an < offset, size >
pair.
prop-encoded-array: Encoded as with encode-phys for the offset values,
encode-int for the size values.
The array consists of four 32-bit values to represent two < offset, size >
pairs. Value one in this array corresponds to the first offset value
within
the child address space, encoded as with encode-phys. Value two
corresponds
to the size, encoded as with encode-int. Value three in this array
corresponds to the second offset value, value four to the second size.
Default value is { 0x00510000 0x00001000 0x00511000 0x00001000 }.
"device_type" property
Standard property name: Specify the type of this node
Encoded as with encode-string
Default value is { "ioc" }
"interrupts" property
Standard property name: Property which specifies the interrupt number of
the interrupt issued by the IOC for IIC "IO Exceptions"
Encoded as with encode-int.
The property value consists of four bytes each representing a specific
value for a node, an Internal Interrupt Controller Interrupt Service
Routine bit mask, a class and a unit
0xNN3d010e (NN=node, bit 3d (61) in IIC_ISR, class=1, unit=E for IIC_ISR
interrupt)
Default value is { 0i3d010e }, i = 0 for Cell Broadband Engine processor
0,
i = 1 for Cell Broadband Engine processor 1.
2 "bic0" node
The Bus Interface Controller (BIC) 0 node describes the address range of
MMIO register space controlling the BIC0.
"reg" property
Default property name: Property to specify the MMIO offset of the BIC0,
which is one set of registers representing an < offset, size > pair.
prop-encoded-array: Encoded as with encode-phys for the offset value,
encode-int for the size.
Default value is { 0x00512000 0x00001000 }
"device_type" property
Standard property name: Property to specify the type of this node.
Encoded as with encode-string.
Default value is { "bic0" }.
3 "bic1" node
The Bus Interface Controller (BIC) 1 node describes the address range of
MMIO register space controlling the BIC1.
"reg" property
Default property name: Property to specify the MMIO offset of the BIC1,
which is one set of registers representing an < offset, size > pair.
prop-encoded-array: Encoded as with encode-phys for the offset value,
encode-int for the size.
Default value is { 0x00513000 0x00001000 }
"device_type" property
Standard property name: Property to pecify the type of this node.
Encoded as with encode-string.
Default value is { "bic1" }.
4 "mic-tm" node
The "mic-tm" node represents the Memory Interface Controller (MIC) in the
device tree. The main property value is the address range of MMIO register
space controlling the MIC.
"reg" property
Default property name: Property to specify the MMIO offset of the BIC1,
which is one set of registers representing an < offset, size > pair.
prop-encoded-array: Encoded as with encode-phys for the offset value,
encode-int for the size.
Default value is { 0x0050a000 0x00001000 }.
"device_type" property
Standard property name: Specify the type of this node.
Encoded as with encode-string.
Default value is { "mic-tm" }.
5 "pervasive" node
The pervasive node node represents the pervasive unit in the device tree.
T>he main property value is the address range of MMIO register space
controlling the pervasive unit.
"reg" property
Default property name: Property to specify the MMIO offset of the BIC1,
which is one set of registers representing an < offset, size > pair.
prop-encoded-array: Encoded as with encode-phys for the offset value,
encode-int for the size.
Default value is { 0x00509000 0x00001000 }.
"device_type" property
Standard property name: Property to specify the type of this node.
Encoded as with encode-string.
Default value is { "pervasive" }.
"ppe-throttle-temp" property
property name: Property to specify the minimum temperature the PPE is
throttled.
Temperature in °C, encoded as with encode-int.
Default value is { 0x65 } for 101°C
"ppe-end-throttle-temp" property
Standard property name: Property to specify the temperature below the PPE
throttling is exited.
Temperature in °C, encoded as with encode-int.
Default value is { 0x5b } for 91°C
"ppe-full-throttle-temp" property
property name: Property to specify the minimum temperature the PPE is
stopped.
Temperature in °C, encoded as with encode-int.
Default value is { 0x7f } for 127°C
"spe-throttle-temp" property
property name: : Property to specify the minimum temperature the SPEs are
throttled.
Temperature in °C, encoded as with encode-int.
Default value is { 0x65 } for 101°C
"spe-end-throttle-temp" property
property name: : Property to specify the temperature below the SPEs
throttling is exited.
Temperature in °C, encoded as with encode-int.
Default value is { 0x5b } for 91°C
"spe-full-throttle-temp" property
property name: Property to specify the minimum temperature the PPE is
stopped.
Temperature in °C, encoded as with encode-int.
Default value is { 0x6f } for 111°C
6 "ppe-mmio" node
The "ppe-mmio" node represents the PowerPC Processing Element (PPE) in the
device tree. The main property is the address range of MMIO register space
controlling the PPE part of the Cell Broadband Engine processor.
"reg" property
Standard property name: Property to specify the MMIO offset of the mic.
prop-encoded-array: Encoded as with encode-phys for the offset, encode-int
for the size.
Default value is { 0x00500000 0x00001000 }
"device_type" property
Standard property name: Property to specify the type of this node.
Encoded as with encode-string.
Default value is { "ppe-mmio" }.
7 "interrupt-controller" node
The Cell Broadband Engine Architecture processor contains an Internal
Interrupt Controller (IIC), which is handling all the interrupts from the
PPE, the SPE and the connected IO.
"reg" property
Standard property name: Property to specify the MMIO offset of the IIC,
one
range for each of the two threads contained in each PPE and one range for
the common MMIO.
prop-encoded-array: Consisting of six 32-bit values. The values form three
< offset,length > pairs of the denoted space encoded as with encode-phys
for the offsets and encode-int for the sizes
1. for MMIO space of thread one
2. for MMIO space of thread two
3. for MMIO space of the common PPE MMIO space.
Default value is
{ 0x00508400 0x00000020 0x00508420 0x00000020 0x00508000 0x00001000 }.
"device_type" property
Standard property name: Property to specify the type of this node.
Encoded as with encode-string.
Default value is { "CBEA-Internal-Interrupt-Controller" }.
"compatible" property
property name: Property to specify the compatiblity of this interrupt
controller.
Encoded as with encode-string.
Default values is { "IBM,CBEA-Internal-Interrupt-Controller" }.
"interrupt-controller" property
property name: Property to specify that this node is an interrupt
controller.
The mere presence of this property denotes the current node being an
interrupt controller.
Zero length property.
The value is {}.
"#interrupt-cells" property
Standard property name: Property to specify the number of interrupt cells.
Encoded as with encode-int.
Default value is { 0x1 }.
"ibm,interrupt-server-ranges" property
property name: Property to specify the threads handled by this interrupt
controller.
Array of threads, encoded as with encode-int.
Default values for
|Cell Broadband Engine |Property Value |
|Architecture processor # | |
|0 |{ 0x00000000 0x00000001 }|
|1 |{ 0x00000000 0x00000001 }|
8 "spe" nodes
The Cell Broadband Engine Architecture processor contains eight SPEs, each
consisting of an SPU, 256kB local store and a Memory Flow Controller
(MFC).
The SPEs are connected to the EIB (Element Interconnect Bus) ring. The
access to the internal devices is done via MMIO reads, with a fixed offset
to the Cell Broadband Engine processor base address.
"reg" property
Standard property name: Specifies the MMIO offset and size of the SPEs
Local Storage, Problem-State, Privilege 2 Area and Privilege 1 Area.
prop-encoded array: Encoded as four < offset, length > pairs per SPE
encoded as with encode-phys for the offsets, encode-int for the size. The
pairs define the following SPE units:
1. Local Store (LS)
2. Problem State MMIO Registers
3. Privilege State 2 MMIO Registers
4. Privilege State 1 MMIO Registers
The property exists once in each spe node.
Default values for SPE
|# |Property Value |
|spe@0 |{ 0x00000000 0x00040000 0x00040000 |
| |0x00020000 |
| |0x00060000 0x00020000 0x00400000 |
| |0x00002000 } |
|spe@80000 |{ 0x00080000 0x00040000 0x000c0000 |
| |0x00020000 |
| |0x000e0000 0x00020000 0x00402000 |
| |0x00002000 } |
|spe@100000 |{ 0x00100000 0x00040000 0x00140000 |
| |0x00020000 |
| |0x00160000 0x00020000 0x00404000 |
| |0x00002000 } |
|spe@180000 |{ 0x00180000 0x00040000 0x001c0000 |
| |0x00020000 |
| |0x001e0000 0x00020000 0x00406000 |
| |0x00002000 } |
|spe@200000 |{ 0x00200000 0x00040000 0x00240000 |
| |0x00020000 |
| |0x00260000 0x00020000 0x00408000 |
| |0x00002000 } |
|spe@280000 |{ 0x00280000 0x00040000 0x002c0000 |
| |0x00020000 |
| |0x002e0000 0x00020000 0x0040a000 |
| |0x00002000 } |
|spe@300000 |{ 0x00280000 0x00040000 0x002c0000 |
| |0x00020000 |
| |0x002e0000 0x00020000 0x0040a000 |
| |0x00002000 } |
|spe@380000 |{ 0x00380000 0x00040000 0x003c0000 |
| |0x00020000 |
| |0x003e0000 0x00020000 0x0040e000 |
| |0x00002000 } |
"device_type" property
Standard property name: Specifies the type of this node.
Encoded as with encode-string.
Default value is {"spe" }.
"interrupts" property
Standard property name: Property to specify the interrupt numbers of the
interrupts issued by SPE.
prop-encoded array: List of interrupt numbers issued by the SPE. Each
value
in the list is encoded as with encode-int.
The property exists once in each spe node.
Default values for SPEs are
|# |Property Value |
|spe@0 |{ 0x4, 0x104, 0x204 } |
|spe@80000 |{ 0x7, 0x107, 0x207 } |
|spe@100000 |{ 0x3, 0x103, 0x203 } |
|spe@180000 |{ 0x8, 0x108, 0x208 } |
|spe@200000 |{ 0x2, 0x102, 0x202 } |
|spe@280000 |{ 0x9, 0x109, 0x209 } |
|spe@300000 |{0x1, 0x101, 0x201 } |
|spe@380000 |{0xa, 0x10a, 0x20a } |
"vicinity" property
property name: Specifies the direct neighbouring componentes on the EIB
ring related to each SPE.
prop-encoded array: Pairs of phandles ( < phandle, phandle >) of the
neighbouring nodes, each phandle is encoded as with encode-int.
The property exists once in each spe node.
Default values for SPEs
|# |Property Value |
|spe@0 |{ phandle(mic-tm, SPE 3) } |
|spe@80000 |{ phandle(mic-tm, SPE 2) } |
|spe@100000 |{ phandle(SPE 0, SPE 4) } |
|spe@180000 |{ phandle(SPE 1, SPE 5) } |
|spe@200000 |{ phandle(SPE 2, SPE 6) } |
|spe@280000 |{ phandle(SPE 3, SPE 7) } |
|spe@300000 |{ phandle(SPE 4, BIC0) } |
|spe@380000 |{ phandle(SPE 5, BIC0) } |
"physical-id" property
property name: Property to specify the physical id of an SPE.
Default values for the physical id is encoded as with encode-int.
The property exists once in each spe node.
|# |Property Value |
|spe@0 |{ 0 } |
|spe@80000 |{ 1 } |
|spe@100000 |{ 2 } |
|spe@180000 |{ 3 } |
|spe@200000 |{ 4 } |
|spe@280000 |{ 5 } |
|spe@300000 |{ 6 } |
|spe@380000 |{ 7 } |
Appendix A - Bibliography
This section lists documents which were referenced in this specification
or
which provide additional information, and some useful information
for
obtaining these documents. Referenced documents are listed below. When
any
of the following standards are superseded by an approved revision,
the
revision shall apply.
1. IEEE 1275, IEEE Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
IEEE part number DS02683, ISBN 1-55937-426-8
2. PowerPC Processor binding to: IEEE 1275, IEEE Standard for
Boot
(Initialization Configuration) Firmware: Core Requirements and
Practices
3. Power.org Standard for Power Architecture Platform
Requirements
(Workstation, Server) Version 2.2, 9th Oct 2007
Mit freundlichen Grüßen / Kind regards
Christian Rund
Engineer in Development, SLOF, directCell, Systems Management
IBM Systems & Technology Group, Integrated Systems Development
Open Systems Firmware Development
Phone:
+49-7031-16-3235
IBM Deutschland
E-Mail:
Christian.Rund-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Schoenaicher Str. 220
71032 Boeblingen
Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #1.1.2: Type: text/html, Size: 38542 bytes --]
[-- Attachment #1.2: Type: image/gif, Size: 1851 bytes --]
[-- Attachment #2: Type: text/plain, Size: 194 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
[not found] ` <OF89278B7C.B7D060FF-ONC1257521.004C9E27-C1257521.004D3F55-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
@ 2008-12-16 22:08 ` Grant Likely
[not found] ` <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Grant Likely @ 2008-12-16 22:08 UTC (permalink / raw)
To: Christian Rund; +Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
On Tue, Dec 16, 2008 at 7:03 AM, Christian Rund
<Christian.Rund-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> wrote:
> this is a reminder for review. Feedback appreciated!
> For convenience I removed the disclaimer etc.
>
> On dec 5th I posted our (complete) draft version of the Cell/B.E. device
> tree documentation.
>
> Goal of these review should be to finally establish the document as
> Power.org
> PAPR Binding for the Cell/B.E. processor.
>
> Please review and give us feedback.
First comments; This document is quite verbose. Much time is spent
describing how standard properties work (ie; content of the 'reg' and
'ranges' properties). Reviewing takes more effort when there is a
large amount of boilerplate to filter.
Second, very few nodes have a 'compatible' value defined. Currently,
the 'compatible' list is the preferred method for device drivers to
find supported devices in the tree. Each distinct device should have
a unique compatible value defined.
More comments below
> 1 "be" node
[...]
> "device-type" property
>
> Standard property name which specifies the type of the node.
>
> Encoded as with encode-string.
>
> Default value is { "be" }.
Is a new OpenFirmware driver interface being defined for working with
'be' devices? If not then the device-type property should not be
defined.
> "model" property
> property name: Specifies model of node.
> Encoded as with encode-string.
> Default value is { "IBM,CBEA" }.
> "ibm,dt-version" property
I'm concerned about the usage model of this property. It is not
common for driver to go looking for an additional version property
when interpreting node data. Are all drivers expected to test the
value of this property? What should they do when the major or minor
values do not match?
> 1 ioc node
>
>
> The Input/Output Controller (IOC) node contains among others the properties
> specifying the address range of MMIO register space controlling the IOC.
>
> "reg" property
>
> Default property name: Property to specify the MMIO offset of the IOC,
> which are two sets of registers each represented by an < offset, size >
> pair.
>
> prop-encoded-array: Encoded as with encode-phys for the offset values,
> encode-int for the size values.
>
> The array consists of four 32-bit values to represent two < offset, size >
> pairs. Value one in this array corresponds to the first offset value within
> the child address space, encoded as with encode-phys. Value two corresponds
> to the size, encoded as with encode-int. Value three in this array
> corresponds to the second offset value, value four to the second size.
>
> Default value is { 0x00510000 0x00001000 0x00511000 0x00001000 }.
These spaces are contiguous; what is the reason for the two array entries?
> "device_type" property
>
> Standard property name: Specify the type of this node
>
> Encoded as with encode-string
>
> Default value is { "ioc" }
Again, if an OpenFirmware driver interface is not being defined, then
don't use the device-type property.
> 2 "bic0" node
[...]
> "device_type" property
>
> Standard property name: Property to specify the type of this node.
>
> Encoded as with encode-string.
>
> Default value is { "bic0" }.
ditto on device_type
> 3 "bic1" node
This is identical to bic0
> 4 "mic-tm" node
> 6 "ppe-mmio" node
mic-tm, ppe-mmio, and the bic* node documentation just duplicates the
definition of standard node properties. In this case is should be
sufficient to describe what device the node describes an that it uses
the standard properties.
> 5 "pervasive" node
>
>
> The pervasive node node represents the pervasive unit in the device tree.
> T>he main property value is the address range of MMIO register space
> controlling the pervasive unit.
Umm, what is a "pervasive unit"?
> "device_type" property
>
> Standard property name: Property to specify the type of this node.
>
> Encoded as with encode-string.
>
> Default value is { "pervasive" }.
ditto on device_type
> "ppe-throttle-temp" property
> "ppe-end-throttle-temp" property
> "ppe-full-throttle-temp" property
> "spe-throttle-temp" property
> "spe-end-throttle-temp" property
> "spe-full-throttle-temp" property
These properties look good.
> 7 "interrupt-controller" node
>
> The Cell Broadband Engine Architecture processor contains an Internal
> Interrupt Controller (IIC), which is handling all the interrupts from the
> PPE, the SPE and the connected IO.
>
> "reg" property
>
> Standard property name: Property to specify the MMIO offset of the IIC, one
> range for each of the two threads contained in each PPE and one range for
> the common MMIO.
>
> prop-encoded-array: Consisting of six 32-bit values. The values form three
> < offset,length > pairs of the denoted space encoded as with encode-phys
> for the offsets and encode-int for the sizes
>
> 1. for MMIO space of thread one
>
> 2. for MMIO space of thread two
>
> 3. for MMIO space of the common PPE MMIO space.
>
> Default value is
> { 0x00508400 0x00000020 0x00508420 0x00000020 0x00508000 0x00001000 }.
>
>
>
> "device_type" property
>
> Standard property name: Property to specify the type of this node.
>
> Encoded as with encode-string.
>
> Default value is { "CBEA-Internal-Interrupt-Controller" }.
ditto on device_type. In fact, you should not be inventing new values
for device_type at all. Either use an already established
device_type, or don't assign the property at all. And, if you do use
device_type, you are claiming that OpenFirmware has a driver interface
for the device.
> 8 "spe" nodes
>
> The Cell Broadband Engine Architecture processor contains eight SPEs, each
> consisting of an SPU, 256kB local store and a Memory Flow Controller (MFC).
> The SPEs are connected to the EIB (Element Interconnect Bus) ring. The
> access to the internal devices is done via MMIO reads, with a fixed offset
> to the Cell Broadband Engine processor base address.
>
> "reg" property
>
> Standard property name: Specifies the MMIO offset and size of the SPEs
> Local Storage, Problem-State, Privilege 2 Area and Privilege 1 Area.
>
> prop-encoded array: Encoded as four < offset, length > pairs per SPE
> encoded as with encode-phys for the offsets, encode-int for the size. The
> pairs define the following SPE units:
>
> 1. Local Store (LS)
>
> 2. Problem State MMIO Registers
>
> 3. Privilege State 2 MMIO Registers
>
> 4. Privilege State 1 MMIO Registers
>
> The property exists once in each spe node.
I like the above description. It provides good information about how
data is organized in the reg property.
> "device_type" property
>
> Standard property name: Specifies the type of this node.
>
> Encoded as with encode-string.
>
> Default value is {"spe" }.
ditto on device_type
> "interrupts" property
>
> Standard property name: Property to specify the interrupt numbers of the
> interrupts issued by SPE.
>
> prop-encoded array: List of interrupt numbers issued by the SPE. Each value
> in the list is encoded as with encode-int.
>
> The property exists once in each spe node.
>
> Default values for SPEs are
>
>
>
> |# |Property Value |
> |spe@0 |{ 0x4, 0x104, 0x204 } |
> |spe@80000 |{ 0x7, 0x107, 0x207 } |
> |spe@100000 |{ 0x3, 0x103, 0x203 } |
> |spe@180000 |{ 0x8, 0x108, 0x208 } |
> |spe@200000 |{ 0x2, 0x102, 0x202 } |
> |spe@280000 |{ 0x9, 0x109, 0x209 } |
> |spe@300000 |{0x1, 0x101, 0x201 } |
> |spe@380000 |{0xa, 0x10a, 0x20a } |
>
>
> "vicinity" property
>
> property name: Specifies the direct neighbouring componentes on the EIB
> ring related to each SPE.
>
> prop-encoded array: Pairs of phandles ( < phandle, phandle >) of the
> neighbouring nodes, each phandle is encoded as with encode-int.
>
> The property exists once in each spe node.
>
> Default values for SPEs
>
>
>
> |# |Property Value |
> |spe@0 |{ phandle(mic-tm, SPE 3) } |
> |spe@80000 |{ phandle(mic-tm, SPE 2) } |
> |spe@100000 |{ phandle(SPE 0, SPE 4) } |
> |spe@180000 |{ phandle(SPE 1, SPE 5) } |
> |spe@200000 |{ phandle(SPE 2, SPE 6) } |
> |spe@280000 |{ phandle(SPE 3, SPE 7) } |
> |spe@300000 |{ phandle(SPE 4, BIC0) } |
> |spe@380000 |{ phandle(SPE 5, BIC0) } |
>
>
> "physical-id" property
>
> property name: Property to specify the physical id of an SPE.
>
> Default values for the physical id is encoded as with encode-int.
Unless there is some shared register set that needs the SPE physical
id to operate then I encourage you not to define this property. If it
is just a logical number, the I think it is better to rely on the node
name instead of an arbitrarily defined logical number. However, if
there is a register set shared between the SPEs that needs the SPE
number, then you should follow the lead of other existing bindings and
use the property name "cell-index" instead of physical-id.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
[not found] ` <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2008-12-30 23:08 ` Matt Sealey
[not found] ` <495AA9FB.40902-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
2008-12-30 23:20 ` Matt Sealey
1 sibling, 1 reply; 5+ messages in thread
From: Matt Sealey @ 2008-12-30 23:08 UTC (permalink / raw)
To: Grant Likely; +Cc: Christian Rund, devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
Grant Likely wrote:
> On Tue, Dec 16, 2008 at 7:03 AM, Christian Rund
> <Christian.Rund-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> wrote:
>
>> 1 "be" node
> [...]
>> "device-type" property
>>
>> Standard property name which specifies the type of the node.
>>
>> Encoded as with encode-string.
>>
>> Default value is { "be" }.
>
> Is a new OpenFirmware driver interface being defined for working with
> 'be' devices? If not then the device-type property should not be
> defined.
I think that while the distinction that it requires a driver interface
is moot (and probably overdiscussed and therefore after this, I will
drop it)..
** more prudent in this case is that even if it is specified or not, the
property is named "device_type" with an underscore, not a hyphen **
> First comments; This document is quite verbose. Much time is spent
> describing how standard properties work (ie; content of the 'reg' and
> 'ranges' properties). Reviewing takes more effort when there is a
> large amount of boilerplate to filter.
I would let this go through if only because getting access to the
original OpenFirmware specification is getting more and more "difficult"
these days (while it's available in many places, some of them are a
little obscure and most people won't find it in a portable, easily
readable format from a Google search. No, I don't consider PostScript an
easily readable format..)
Having the Cell/BE DT specification self-contained makes it harder to
review but far more useful as a document unto itself. Cross-referencing
is time consuming and there is already far, far too much to read up on
the subject for very little benefit.
Perhaps, though, the "boilerplate" could be whittled down slightly such
that it does not overshadow the real new specification in the document.
> Second, very few nodes have a 'compatible' value defined. Currently,
> the 'compatible' list is the preferred method for device drivers to
> find supported devices in the tree. Each distinct device should have
> a unique compatible value defined.
Since Linux and every other OpenFirmware-supporting device implements
device_type (see below) and this is checked BEFORE compatible properties
when searching for compatible entries, this distinction is moot.
As long as device_type exists in the node, compatible is not necessarily
required. This conforms to the OpenFirmware specification, and produces
completely acceptable behaviour within Linux and any other OS.
The OF spec for device_type states is MEANT to supply information about
how to access the device programmatically, whether this be through a
client interface API such as "serial" or "network", I think while this
distinction may be "clever" from the point of view of redefining it for
Linux DTBs and reducing some redundancy, I prefer to think of this in
the same way as a PCI class code or similar - a device_type of
"fsl,mpc5200b-i2c" therefore specifies that it is a Freescale i2c bus on
the MPC5200B, and a compatible property would dictate that it is
compatible with generic "fsl,i2c" bus specification and register set.
If there is no standard client interface methods defined for it then at
least it gives a fairly good hint as to the device in order to program
it by any other means.
It also looks better when you're a human reading device trees. Chip
company's XX1234 controller is not "only" compatible, it *IS* a Chip
XX1234. Having device_type list the specific chip and compatible listing
register-compatible or API-compatible devices (for instance
chip,xx1233). There is no other place to reference this distinction of
which chip it actually is, and not which chips it is simply very similar
or identical to, apart from the OPTIONAL "model" property.
Please let's not nitpick that "device_type" is obselete, because it
isn't, you could not remove the check for device_type from the device
tree code, nor any device tree on a real OF machine.
It is still a useful and informative property which COULD be given
something of a new meaning (which implies or does not imply certain
attributes for hardware components). Anyone can put in device_type into
a DTS and it will not destroy the spacetime continuum or cause world
famine or wars to get worse. The mere fact that it goes from being
required to "completely optional and practically obselete" from OF
specification (which does not dictate that device_type MUST conform to a
CIF package or set of methods, only that it should if it could) to the
DTS specification is just makes the Linux spec contrary for the sake of
being contrary.
--
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
[not found] ` <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-30 23:08 ` Matt Sealey
@ 2008-12-30 23:20 ` Matt Sealey
1 sibling, 0 replies; 5+ messages in thread
From: Matt Sealey @ 2008-12-30 23:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Christian Rund, devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
Grant Likely wrote:
> On Tue, Dec 16, 2008 at 7:03 AM, Christian Rund
>> "model" property
>> property name: Specifies model of node.
>> Encoded as with encode-string.
>> Default value is { "IBM,CBEA" }.
>
>> "ibm,dt-version" property
>
> I'm concerned about the usage model of this property. It is not
> common for driver to go looking for an additional version property
> when interpreting node data.
Then that sucks, because they SHOULD be checking the model property if
it is known that a device may have errata, quirks or other problems
which cannot be programmatically detected in other ways (for instance
via version registers in the chip itself).
> Are all drivers expected to test the value of this property?
I would expect that once the model or version property is filled by the
device tree compiler or by the OF implementation, people will get used
to it being there. When it comes time that it may need to be checked
for, then it already exists; nobody will have to update their firmwares,
or device trees, or program any flash chips, just update their kernel or
recompile a module and unload/load it to get the changes and/or fixes.
You never complained that we fill out the version of the firmware (and
the build-date integer) in the Pegasos or Efika device trees. And rather
than make any particular checks on them, code has been submitted which
makes blanket changes not dependant on version, but on the presence of
certain nodes (and also NOT on the lack of properties inside those
nodes, too, when creating new property data). I've always thought such
trashing of firmware data without proper checks is both intrusive and
also creates yet another moving target for software developers to take
heed of. It makes working with Linux far, far more frustrating from
board bring-up all the way up to end users installing a prebaked
distribution..
> What should they do when the major or minor values do not match?
I would expect that this is to be determined when the version number
becomes an actual, actionable item.
One might stop booting if the firmware version is too old, or initiate
some fixups (such as using a compiled-in ACPI table as is done on many
older PC motherboards). Certain VIA EPIA boards have lots of weird
behaviours and the BIOS vendor string plus a few other heuristics are
employed to make sure they are worked around.
--
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
[not found] ` <495AA9FB.40902-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
@ 2008-12-31 0:09 ` Mitch Bradley
0 siblings, 0 replies; 5+ messages in thread
From: Mitch Bradley @ 2008-12-31 0:09 UTC (permalink / raw)
To: Matt Sealey; +Cc: Christian Rund, devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
> The OF spec for device_type states is MEANT to supply information
> about how to access the device programmatically, whether this be
> through a client interface API such as "serial" or "network", I think
> while this distinction may be "clever" from the point of view of
> redefining it for Linux DTBs and reducing some redundancy,
IEEE Std 1275-1994 page 132:
"device_type"
Standard property name to specify the implemented interface
(Note: this is the brief description, which is a hint, not the normative
part)
...
(Normative text:)
Specifies the "device type" of this package, thus implying a
specific set of package class methods implemented by the package.
Note that it does not specify the programming model of the hardware - it
specifies the *package* interface.
In the context of a device tree that is disconnected from a functional
Open Firmware implementation, device_type is meaningless and arguably
inaccurate, asserting the existence of a set of methods that is not in
fact present.
For binding an OS driver to hardware, you need to know the hardware
programming model, as specified by "compatible". "device_type" doesn't
specify the hardware programming model, so misusing it for driver
binding is a bad idea. Please don't propagate such mistakes.
The original use of device_name was for an Open Firmware implementation
to find nodes that might be candidates for specific internal uses, most
notably console devices. The most compelling use case is when a plug-in
video card would automatically become the preferred console output
device. But in a lot of real-world situations, automated device choice
of this ilk is a problem. You often need to wire down a device list to
avoid user confusion and make it possible to write definitive
documentation. (There were also some diagnostic-related uses such as
probe-scsi-all.)
If I could redo history, device_type would not have been included in the
standard. It was an OBP1-ism and, unfortunately, I didn't realize my
mistake until it was too late.
> I prefer to think of this in the same way as a PCI class code or
> similar - a device_type of "fsl,mpc5200b-i2c" therefore specifies that
> it is a Freescale i2c bus on the MPC5200B, and a compatible property
> would dictate that it is compatible with generic "fsl,i2c" bus
> specification and register set.
There is a legitimate need for something like a "class code" to indicate
in a vague way what general kind of device it is. That is accomplished
by the "name" property as reinterpreted by the "generic names"
recommended practice.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-12-31 0:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-16 14:03 Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1 Christian Rund
[not found] ` <OF89278B7C.B7D060FF-ONC1257521.004C9E27-C1257521.004D3F55-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2008-12-16 22:08 ` Grant Likely
[not found] ` <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-30 23:08 ` Matt Sealey
[not found] ` <495AA9FB.40902-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
2008-12-31 0:09 ` Mitch Bradley
2008-12-30 23:20 ` Matt Sealey
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.