blob: 5e03610e186f986c5cc3a21a5e4f9bbac3ee4332 [file] [log] [blame]
Grant Likely05cbbc62007-02-12 13:36:54 -07001MPC5200 Device Tree Bindings
Grant Likelyb1e253c2006-11-27 14:16:22 -07002----------------------------
3
Grant Likely05cbbc62007-02-12 13:36:54 -07004(c) 2006-2007 Secret Lab Technologies Ltd
Grant Likelyb1e253c2006-11-27 14:16:22 -07005Grant Likely <grant.likely at secretlab.ca>
6
Grant Likely121361f2007-01-19 00:00:14 -07007********** DRAFT ***********
8* WARNING: Do not depend on the stability of these bindings just yet.
9* The MPC5200 device tree conventions are still in flux
10* Keep an eye on the linuxppc-dev mailing list for more details
11********** DRAFT ***********
12
Grant Likelyb1e253c2006-11-27 14:16:22 -070013I - Introduction
14================
15Boards supported by the arch/powerpc architecture require device tree be
16passed by the boot loader to the kernel at boot time. The device tree
17describes what devices are present on the board and how they are
18connected. The device tree can either be passed as a binary blob (as
19described in Documentation/powerpc/booting-without-of.txt), or passed
Matt LaPlante01dd2fb2007-10-20 01:34:40 +020020by Open Firmware (IEEE 1275) compatible firmware using an OF compatible
Grant Likelyb1e253c2006-11-27 14:16:22 -070021client interface API.
22
Grant Likely05cbbc62007-02-12 13:36:54 -070023This document specifies the requirements on the device-tree for mpc5200
Grant Likelyb1e253c2006-11-27 14:16:22 -070024based boards. These requirements are above and beyond the details
Matt LaPlante01dd2fb2007-10-20 01:34:40 +020025specified in either the Open Firmware spec or booting-without-of.txt
Grant Likelyb1e253c2006-11-27 14:16:22 -070026
Grant Likely05cbbc62007-02-12 13:36:54 -070027All new mpc5200-based boards are expected to match this document. In
Grant Likelyb1e253c2006-11-27 14:16:22 -070028cases 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.
30
31II - Philosophy
32===============
33The core of this document is naming convention. The whole point of
34defining this convention is to reduce or eliminate the number of
Grant Likely05cbbc62007-02-12 13:36:54 -070035special cases required to support a 5200 board. If all 5200 boards
36follow the same convention, then generic 5200 support code will work
Grant Likelyb1e253c2006-11-27 14:16:22 -070037rather than coding special cases for each new board.
38
39This section tries to capture the thought process behind why the naming
40convention is what it is.
41
Grant Likely05cbbc62007-02-12 13:36:54 -0700421. names
43---------
Grant Likelyb1e253c2006-11-27 14:16:22 -070044There is strong convention/requirements already established for children
45of the root node. 'cpus' describes the processor cores, 'memory'
46describes memory, and 'chosen' provides boot configuration. Other nodes
47are added to describe devices attached to the processor local bus.
Grant Likelyb1e253c2006-11-27 14:16:22 -070048
Grant Likely05cbbc62007-02-12 13:36:54 -070049Following convention already established with other system-on-chip
50processors, 5200 device trees should use the name 'soc5200' for the
51parent node of on chip devices, and the root node should be its parent.
52
53Child nodes are typically named after the configured function. ie.
54the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'.
Grant Likelyb1e253c2006-11-27 14:16:22 -070055
562. device_type property
57-----------------------
58similar to the node name convention above; the device_type reflects the
59configured function of a device. ie. 'serial' for a uart and 'spi' for
60an spi controller. However, while node names *should* reflect the
61configured function, device_type *must* match the configured function
62exactly.
63
643. compatible property
65----------------------
66Since device_type isn't enough to match devices to drivers, there also
67needs to be a naming convention for the compatible property. Compatible
68is an list of device descriptions sorted from specific to generic. For
Grant Likely05cbbc62007-02-12 13:36:54 -070069the mpc5200, the required format for each compatible value is
70<chip>-<device>[-<mode>]. The OS should be able to match a device driver
71to the device based solely on the compatible value. If two drivers
72match on the compatible list; the 'most compatible' driver should be
73selected.
Grant Likelyb1e253c2006-11-27 14:16:22 -070074
Grant Likely05cbbc62007-02-12 13:36:54 -070075The split between the MPC5200 and the MPC5200B leaves a bit of a
Matt LaPlante01dd2fb2007-10-20 01:34:40 +020076conundrum. How should the compatible property be set up to provide
77maximum compatibility information; but still accurately describe the
Grant Likely05cbbc62007-02-12 13:36:54 -070078chip? 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>".
Grant Likelyb1e253c2006-11-27 14:16:22 -070082
Grant Likely05cbbc62007-02-12 13:36:54 -070083The 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.
Matt LaPlante01dd2fb2007-10-20 01:34:40 +020087To express this information as completely as possible, 5200B device trees
Grant Likely05cbbc62007-02-12 13:36:54 -070088should 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"
Grant Likelyb1e253c2006-11-27 14:16:22 -070098
99Modal devices, like PSCs, also append the configured function to the
100end of the compatible field. ie. A PSC in i2s mode would specify
Grant Likely05cbbc62007-02-12 13:36:54 -0700101"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to
Grant Likelyb1e253c2006-11-27 14:16:22 -0700102avoid naming conflicts with non-psc devices providing the same
Grant Likely05cbbc62007-02-12 13:36:54 -0700103function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe
Grant Likelyb1e253c2006-11-27 14:16:22 -0700104the mpc5200 simple spi device and a PSC spi mode respectively.
105
106If the soc device is more generic and present on other SOCs, the
107compatible property can specify the more generic device type also.
108
Grant Likely05cbbc62007-02-12 13:36:54 -0700109ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan";
Grant Likelyb1e253c2006-11-27 14:16:22 -0700110
111At the time of writing, exact chip may be either 'mpc5200' or
112'mpc5200b'.
113
114Device drivers should always try to match as generically as possible.
115
116III - Structure
117===============
Grant Likely05cbbc62007-02-12 13:36:54 -0700118The device tree for an mpc5200 board follows the structure defined in
Grant Likelyb1e253c2006-11-27 14:16:22 -0700119booting-without-of.txt with the following additional notes:
120
1210) the root node
122----------------
123Typical root description node; see booting-without-of
124
1251) The cpus node
126----------------
127The cpus node follows the basic layout described in booting-without-of.
128The bus-frequency property holds the XLB bus frequency
129The clock-frequency property holds the core frequency
130
1312) The memory node
132------------------
133Typical memory description node; see booting-without-of.
134
1353) The soc5200 node
136-------------------
Grant Likely05cbbc62007-02-12 13:36:54 -0700137This node describes the on chip SOC peripherals. Every mpc5200 based
Grant Likelyb1e253c2006-11-27 14:16:22 -0700138board will have this node, and as such there is a common naming
139convention for SOC devices.
140
141Required properties:
142name type description
143---- ---- -----------
144device_type string must be "soc"
145ranges int should be <0 baseaddr baseaddr+10000>
146reg int must be <baseaddr 10000>
Grant Likely05cbbc62007-02-12 13:36:54 -0700147compatible 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>.
Grant Likelyb1e253c2006-11-27 14:16:22 -0700154
155Recommended properties:
156name type description
157---- ---- -----------
Grant Likely05cbbc62007-02-12 13:36:54 -0700158model string Exact model of the chip;
159 ie: model="fsl,mpc5200"
160revision string Silicon revision of chip
161 ie: revision="M08A"
162
163The 'model' and 'revision' properties are *strongly* recommended. Having
164them presence acts as a bit of a safety net for working around as yet
165undiscovered bugs on one version of silicon. For example, device drivers
166can use the model and revision properties to decide if a bug fix should
167be turned on.
Grant Likelyb1e253c2006-11-27 14:16:22 -0700168
1694) soc5200 child nodes
170----------------------
171Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
172
Grant Likely05cbbc62007-02-12 13:36:54 -0700173Note: The tables below show the value for the mpc5200. A mpc5200b device
174tree should use the "mpc5200b-<device>\0mpc5200-<device> form.
Grant Likelyb1e253c2006-11-27 14:16:22 -0700175
176Required soc5200 child nodes:
177name device_type compatible Description
178---- ----------- ---------- -----------
Grant Likely05cbbc62007-02-12 13:36:54 -0700179cdm@<addr> cdm mpc5200-cmd Clock Distribution
180pic@<addr> interrupt-controller mpc5200-pic need an interrupt
Grant Likelyb1e253c2006-11-27 14:16:22 -0700181 controller to boot
Grant Likely05cbbc62007-02-12 13:36:54 -0700182bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
183 the bestcomm device
Grant Likelyb1e253c2006-11-27 14:16:22 -0700184
185Recommended soc5200 child nodes; populate as needed for your board
Grant Likely05cbbc62007-02-12 13:36:54 -0700186name device_type compatible Description
187---- ----------- ---------- -----------
Marian Balakowiczd24bc312007-10-19 04:44:24 +1000188gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
Grant Likely05cbbc62007-02-12 13:36:54 -0700189rtc@<addr> rtc mpc5200-rtc Real time clock
190mscan@<addr> mscan mpc5200-mscan CAN bus controller
191pci@<addr> pci mpc5200-pci PCI bridge
192serial@<addr> serial mpc5200-psc-uart PSC in serial mode
193i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode
194ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode
195spi@<addr> spi mpc5200-psc-spi PSC in spi mode
196irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode
197spi@<addr> spi mpc5200-spi MPC5200 spi device
198ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
199ata@<addr> ata mpc5200-ata IDE ATA interface
200i2c@<addr> i2c mpc5200-i2c I2C controller
201usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
Matt LaPlante01dd2fb2007-10-20 01:34:40 +0200202xlb@<addr> xlb mpc5200-xlb XLB arbitrator
Grant Likely05cbbc62007-02-12 13:36:54 -0700203
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
Marian Balakowiczd24bc312007-10-19 04:44:24 +1000216include the empty property 'fsl,has-wdt'.
Grant Likely05cbbc62007-02-12 13:36:54 -0700217
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.
Grant Likelyb1e253c2006-11-27 14:16:22 -0700227
228IV - Extra Notes
229================
230
2311. Interrupt mapping
232--------------------
Grant Likely05cbbc62007-02-12 13:36:54 -0700233The mpc5200 pic driver splits hardware IRQ numbers into two levels. The
Grant Likelyb1e253c2006-11-27 14:16:22 -0700234split reflects the layout of the PIC hardware itself, which groups
235interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
236Bestcomm dma engine has it's own set of interrupt sources which are
237cascaded off of peripheral interrupt 0, which the driver interprets as a
238fourth group, SDMA.
239
Grant Likely05cbbc62007-02-12 13:36:54 -0700240The interrupts property for device nodes using the mpc5200 pic consists
Grant Likelyb1e253c2006-11-27 14:16:22 -0700241of three cells; <L1 L2 level>
242
243 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
244 L2 := interrupt number; directly mapped from the value in the
245 "ICTL PerStat, MainStat, CritStat Encoded Register"
246 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
Grant Likely05cbbc62007-02-12 13:36:54 -0700247
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.