aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorGrant Likely <grant.likely@secretlab.ca>2007-02-12 15:36:54 -0500
committerPaul Mackerras <paulus@samba.org>2007-02-12 23:35:53 -0500
commit05cbbc692f513c0e62372abeab01b04b07096582 (patch)
tree882223fb48ddbaa5d8f92d7c1e48020e7539a668 /Documentation
parente3aba81d154c53a82e2a7e0ff5e7f1162a53cf27 (diff)
[POWERPC] mpc5200 device tree bindings refinement
Much needed refinement of mpc5200 device tree binding specifications. Short list: - drop mpc52xx designator; only two supported chips exist, 5200 and 5200b. It's premature to refer to them as '52xx'. - Specify optional 'model' and 'revision' properties in the soc5200 node - Specify reqiured 'cell-index' property to identify between multiple SOC devices of the same type. (Useful for arbitrating shared register access) - Specify optional 'port-number' property for adjusting the logical serial port assignments. - Specify optional 'has-wdt' property for gpt0 node. - Add system-frequency property to soc5200 node Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/powerpc/mpc52xx-device-tree-bindings.txt183
1 files changed, 121 insertions, 62 deletions
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index 69f016f02bb0..e59fcbbe338c 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -1,7 +1,7 @@
1MPC52xx Device Tree Bindings 1MPC5200 Device Tree Bindings
2---------------------------- 2----------------------------
3 3
4(c) 2006 Secret Lab Technologies Ltd 4(c) 2006-2007 Secret Lab Technologies Ltd
5Grant Likely <grant.likely at secretlab.ca> 5Grant Likely <grant.likely at secretlab.ca>
6 6
7********** DRAFT *********** 7********** DRAFT ***********
@@ -20,11 +20,11 @@ described in Documentation/powerpc/booting-without-of.txt), or passed
20by Open Firmare (IEEE 1275) compatible firmware using an OF compatible 20by Open Firmare (IEEE 1275) compatible firmware using an OF compatible
21client interface API. 21client interface API.
22 22
23This document specifies the requirements on the device-tree for mpc52xx 23This document specifies the requirements on the device-tree for mpc5200
24based boards. These requirements are above and beyond the details 24based boards. These requirements are above and beyond the details
25specified in either the OpenFirmware spec or booting-without-of.txt 25specified in either the OpenFirmware spec or booting-without-of.txt
26 26
27All new mpc52xx-based boards are expected to match this document. In 27All new mpc5200-based boards are expected to match this document. In
28cases where this document is not sufficient to support a new board port, 28cases where this document is not sufficient to support a new board port,
29this document should be updated as part of adding the new board support. 29this document should be updated as part of adding the new board support.
30 30
@@ -32,26 +32,26 @@ II - Philosophy
32=============== 32===============
33The core of this document is naming convention. The whole point of 33The core of this document is naming convention. The whole point of
34defining this convention is to reduce or eliminate the number of 34defining this convention is to reduce or eliminate the number of
35special cases required to support a 52xx board. If all 52xx boards 35special cases required to support a 5200 board. If all 5200 boards
36follow the same convention, then generic 52xx support code will work 36follow the same convention, then generic 5200 support code will work
37rather than coding special cases for each new board. 37rather than coding special cases for each new board.
38 38
39This section tries to capture the thought process behind why the naming 39This section tries to capture the thought process behind why the naming
40convention is what it is. 40convention is what it is.
41 41
421. Node names 421. names
43------------- 43---------
44There is strong convention/requirements already established for children 44There is strong convention/requirements already established for children
45of the root node. 'cpus' describes the processor cores, 'memory' 45of the root node. 'cpus' describes the processor cores, 'memory'
46describes memory, and 'chosen' provides boot configuration. Other nodes 46describes memory, and 'chosen' provides boot configuration. Other nodes
47are added to describe devices attached to the processor local bus. 47are added to describe devices attached to the processor local bus.
48
48Following convention already established with other system-on-chip 49Following convention already established with other system-on-chip
49processors, MPC52xx boards must have an 'soc5200' node as a child of the 50processors, 5200 device trees should use the name 'soc5200' for the
50root node. 51parent node of on chip devices, and the root node should be its parent.
51 52
52The soc5200 node holds child nodes for all on chip devices. Child nodes 53Child nodes are typically named after the configured function. ie.
53are typically named after the configured function. ie. the FEC node is 54the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'.
54named 'ethernet', and a PSC in uart mode is named 'serial'.
55 55
562. device_type property 562. device_type property
57----------------------- 57-----------------------
@@ -66,28 +66,47 @@ exactly.
66Since device_type isn't enough to match devices to drivers, there also 66Since device_type isn't enough to match devices to drivers, there also
67needs to be a naming convention for the compatible property. Compatible 67needs to be a naming convention for the compatible property. Compatible
68is an list of device descriptions sorted from specific to generic. For 68is an list of device descriptions sorted from specific to generic. For
69the mpc52xx, the required format for each compatible value is 69the mpc5200, the required format for each compatible value is
70<chip>-<device>[-<mode>]. At the minimum, the list shall contain two 70<chip>-<device>[-<mode>]. The OS should be able to match a device driver
71items; the first specifying the exact chip, and the second specifying 71to the device based solely on the compatible value. If two drivers
72mpc52xx for the chip. 72match on the compatible list; the 'most compatible' driver should be
73 73selected.
74ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet" 74
75 75The split between the MPC5200 and the MPC5200B leaves a bit of a
76The idea here is that most drivers will match to the most generic field 76connundrum. How should the compatible property be set up to provide
77in the compatible list (mpc52xx-*), but can also test the more specific 77maximum compatability information; but still acurately describe the
78field for enabling bug fixes or extra features. 78chip? For the MPC5200; the answer is easy. Most of the SoC devices
79originally appeared on the MPC5200. Since they didn't exist anywhere
80else; the 5200 compatible properties will contain only one item;
81"mpc5200-<device>".
82
83The 5200B is almost the same as the 5200, but not quite. It fixes
84silicon bugs and it adds a small number of enhancements. Most of the
85devices either provide exactly the same interface as on the 5200. A few
86devices have extra functions but still have a backwards compatible mode.
87To express this infomation as completely as possible, 5200B device trees
88should have two items in the compatible list;
89"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended
90that 5200B device trees follow this convention (instead of only listing
91the base mpc5200 item).
92
93If another chip appear on the market with one of the mpc5200 SoC
94devices, then the compatible list should include mpc5200-<device>.
95
96ie. ethernet on mpc5200: compatible = "mpc5200-ethernet"
97 ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet"
79 98
80Modal devices, like PSCs, also append the configured function to the 99Modal devices, like PSCs, also append the configured function to the
81end of the compatible field. ie. A PSC in i2s mode would specify 100end of the compatible field. ie. A PSC in i2s mode would specify
82"mpc52xx-psc-i2s", not "mpc52xx-i2s". This convention is chosen to 101"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to
83avoid naming conflicts with non-psc devices providing the same 102avoid naming conflicts with non-psc devices providing the same
84function. For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe 103function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe
85the mpc5200 simple spi device and a PSC spi mode respectively. 104the mpc5200 simple spi device and a PSC spi mode respectively.
86 105
87If the soc device is more generic and present on other SOCs, the 106If the soc device is more generic and present on other SOCs, the
88compatible property can specify the more generic device type also. 107compatible property can specify the more generic device type also.
89 108
90ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan"; 109ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan";
91 110
92At the time of writing, exact chip may be either 'mpc5200' or 111At the time of writing, exact chip may be either 'mpc5200' or
93'mpc5200b'. 112'mpc5200b'.
@@ -96,7 +115,7 @@ Device drivers should always try to match as generically as possible.
96 115
97III - Structure 116III - Structure
98=============== 117===============
99The device tree for an mpc52xx board follows the structure defined in 118The device tree for an mpc5200 board follows the structure defined in
100booting-without-of.txt with the following additional notes: 119booting-without-of.txt with the following additional notes:
101 120
1020) the root node 1210) the root node
@@ -115,7 +134,7 @@ Typical memory description node; see booting-without-of.
115 134
1163) The soc5200 node 1353) The soc5200 node
117------------------- 136-------------------
118This node describes the on chip SOC peripherals. Every mpc52xx based 137This node describes the on chip SOC peripherals. Every mpc5200 based
119board will have this node, and as such there is a common naming 138board will have this node, and as such there is a common naming
120convention for SOC devices. 139convention for SOC devices.
121 140
@@ -125,71 +144,111 @@ name type description
125device_type string must be "soc" 144device_type string must be "soc"
126ranges int should be <0 baseaddr baseaddr+10000> 145ranges int should be <0 baseaddr baseaddr+10000>
127reg int must be <baseaddr 10000> 146reg int must be <baseaddr 10000>
147compatible string mpc5200: "mpc5200-soc"
148 mpc5200b: "mpc5200b-soc\0mpc5200-soc"
149system-frequency int Fsystem frequency; source of all
150 other clocks.
151bus-frequency int IPB bus frequency in HZ. Clock rate
152 used by most of the soc devices.
153#interrupt-cells int must be <3>.
128 154
129Recommended properties: 155Recommended properties:
130name type description 156name type description
131---- ---- ----------- 157---- ---- -----------
132compatible string should be "<chip>-soc\0mpc52xx-soc" 158model string Exact model of the chip;
133 ie. "mpc5200b-soc\0mpc52xx-soc" 159 ie: model="fsl,mpc5200"
134#interrupt-cells int must be <3>. If it is not defined 160revision string Silicon revision of chip
135 here then it must be defined in every 161 ie: revision="M08A"
136 soc device node. 162
137bus-frequency int IPB bus frequency in HZ. Clock rate 163The 'model' and 'revision' properties are *strongly* recommended. Having
138 used by most of the soc devices. 164them presence acts as a bit of a safety net for working around as yet
139 Defining it here avoids needing it 165undiscovered bugs on one version of silicon. For example, device drivers
140 added to every device node. 166can use the model and revision properties to decide if a bug fix should
167be turned on.
141 168
1424) soc5200 child nodes 1694) soc5200 child nodes
143---------------------- 170----------------------
144Any on chip SOC devices available to Linux must appear as soc5200 child nodes. 171Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
145 172
146Note: in the tables below, '*' matches all <chip> values. ie. 173Note: The tables below show the value for the mpc5200. A mpc5200b device
147*-pic would translate to "mpc5200-pic\0mpc52xx-pic" 174tree should use the "mpc5200b-<device>\0mpc5200-<device> form.
148 175
149Required soc5200 child nodes: 176Required soc5200 child nodes:
150name device_type compatible Description 177name device_type compatible Description
151---- ----------- ---------- ----------- 178---- ----------- ---------- -----------
152cdm@<addr> cdm *-cmd Clock Distribution 179cdm@<addr> cdm mpc5200-cmd Clock Distribution
153pic@<addr> interrupt-controller *-pic need an interrupt 180pic@<addr> interrupt-controller mpc5200-pic need an interrupt
154 controller to boot 181 controller to boot
155bestcomm@<addr> dma-controller *-bestcomm 52xx pic also requires 182bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
156 the bestcomm device 183 the bestcomm device
157 184
158Recommended soc5200 child nodes; populate as needed for your board 185Recommended soc5200 child nodes; populate as needed for your board
159name device_type compatible Description 186name device_type compatible Description
160---- ----------- ---------- ----------- 187---- ----------- ---------- -----------
161gpt@<addr> gpt *-gpt General purpose timers 188gpt@<addr> gpt mpc5200-gpt General purpose timers
162rtc@<addr> rtc *-rtc Real time clock 189rtc@<addr> rtc mpc5200-rtc Real time clock
163mscan@<addr> mscan *-mscan CAN bus controller 190mscan@<addr> mscan mpc5200-mscan CAN bus controller
164pci@<addr> pci *-pci PCI bridge 191pci@<addr> pci mpc5200-pci PCI bridge
165serial@<addr> serial *-psc-uart PSC in serial mode 192serial@<addr> serial mpc5200-psc-uart PSC in serial mode
166i2s@<addr> sound *-psc-i2s PSC in i2s mode 193i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode
167ac97@<addr> sound *-psc-ac97 PSC in ac97 mode 194ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode
168spi@<addr> spi *-psc-spi PSC in spi mode 195spi@<addr> spi mpc5200-psc-spi PSC in spi mode
169irda@<addr> irda *-psc-irda PSC in IrDA mode 196irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode
170spi@<addr> spi *-spi MPC52xx spi device 197spi@<addr> spi mpc5200-spi MPC5200 spi device
171ethernet@<addr> network *-fec MPC52xx ethernet device 198ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
172ata@<addr> ata *-ata IDE ATA interface 199ata@<addr> ata mpc5200-ata IDE ATA interface
173i2c@<addr> i2c *-i2c I2C controller 200i2c@<addr> i2c mpc5200-i2c I2C controller
174usb@<addr> usb-ohci-be *-ohci,ohci-be USB controller 201usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
175xlb@<addr> xlb *-xlb XLB arbritrator 202xlb@<addr> xlb mpc5200-xlb XLB arbritrator
203
204Important child node properties
205name type description
206---- ---- -----------
207cell-index int When multiple devices are present, is the
208 index of the device in the hardware (ie. There
209 are 6 PSC on the 5200 numbered PSC1 to PSC6)
210 PSC1 has 'cell-index = <0>'
211 PSC4 has 'cell-index = <3>'
212
2135) General Purpose Timer nodes (child of soc5200 node)
214On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
215design supports the internal wdt, then the device node for GPT0 should
216include the empty property 'has-wdt'.
217
2186) PSC nodes (child of soc5200 node)
219PSC nodes can define the optional 'port-number' property to force assignment
220order of serial ports. For example, PSC5 might be physically connected to
221the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would
222have a "port-number = <0>" property, and PSC1 would have "port-number = <1>".
223
224PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
225i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
226compatible field.
176 227
177IV - Extra Notes 228IV - Extra Notes
178================ 229================
179 230
1801. Interrupt mapping 2311. Interrupt mapping
181-------------------- 232--------------------
182The mpc52xx pic driver splits hardware IRQ numbers into two levels. The 233The mpc5200 pic driver splits hardware IRQ numbers into two levels. The
183split reflects the layout of the PIC hardware itself, which groups 234split reflects the layout of the PIC hardware itself, which groups
184interrupts into one of three groups; CRIT, MAIN or PERP. Also, the 235interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
185Bestcomm dma engine has it's own set of interrupt sources which are 236Bestcomm dma engine has it's own set of interrupt sources which are
186cascaded off of peripheral interrupt 0, which the driver interprets as a 237cascaded off of peripheral interrupt 0, which the driver interprets as a
187fourth group, SDMA. 238fourth group, SDMA.
188 239
189The interrupts property for device nodes using the mpc52xx pic consists 240The interrupts property for device nodes using the mpc5200 pic consists
190of three cells; <L1 L2 level> 241of three cells; <L1 L2 level>
191 242
192 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3] 243 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
193 L2 := interrupt number; directly mapped from the value in the 244 L2 := interrupt number; directly mapped from the value in the
194 "ICTL PerStat, MainStat, CritStat Encoded Register" 245 "ICTL PerStat, MainStat, CritStat Encoded Register"
195 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3] 246 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
247
2482. Shared registers
249-------------------
250Some SoC devices share registers between them. ie. the i2c devices use
251a single clock control register, and almost all device are affected by
252the port_config register. Devices which need to manipulate shared regs
253should look to the parent SoC node. The soc node is responsible
254for arbitrating all shared register access.