diff options
Diffstat (limited to 'Documentation/powerpc/mpc52xx-device-tree-bindings.txt')
-rw-r--r-- | Documentation/powerpc/mpc52xx-device-tree-bindings.txt | 277 |
1 files changed, 0 insertions, 277 deletions
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt deleted file mode 100644 index 6f12f1c79c0c..000000000000 --- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt +++ /dev/null | |||
@@ -1,277 +0,0 @@ | |||
1 | MPC5200 Device Tree Bindings | ||
2 | ---------------------------- | ||
3 | |||
4 | (c) 2006-2007 Secret Lab Technologies Ltd | ||
5 | Grant Likely <grant.likely at secretlab.ca> | ||
6 | |||
7 | ********** 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 | |||
13 | I - Introduction | ||
14 | ================ | ||
15 | Boards supported by the arch/powerpc architecture require device tree be | ||
16 | passed by the boot loader to the kernel at boot time. The device tree | ||
17 | describes what devices are present on the board and how they are | ||
18 | connected. The device tree can either be passed as a binary blob (as | ||
19 | described in Documentation/powerpc/booting-without-of.txt), or passed | ||
20 | by Open Firmware (IEEE 1275) compatible firmware using an OF compatible | ||
21 | client interface API. | ||
22 | |||
23 | This document specifies the requirements on the device-tree for mpc5200 | ||
24 | based boards. These requirements are above and beyond the details | ||
25 | specified in either the Open Firmware spec or booting-without-of.txt | ||
26 | |||
27 | All new mpc5200-based boards are expected to match this document. In | ||
28 | cases where this document is not sufficient to support a new board port, | ||
29 | this document should be updated as part of adding the new board support. | ||
30 | |||
31 | II - Philosophy | ||
32 | =============== | ||
33 | The core of this document is naming convention. The whole point of | ||
34 | defining this convention is to reduce or eliminate the number of | ||
35 | special cases required to support a 5200 board. If all 5200 boards | ||
36 | follow the same convention, then generic 5200 support code will work | ||
37 | rather than coding special cases for each new board. | ||
38 | |||
39 | This section tries to capture the thought process behind why the naming | ||
40 | convention is what it is. | ||
41 | |||
42 | 1. names | ||
43 | --------- | ||
44 | There is strong convention/requirements already established for children | ||
45 | of the root node. 'cpus' describes the processor cores, 'memory' | ||
46 | describes memory, and 'chosen' provides boot configuration. Other nodes | ||
47 | are added to describe devices attached to the processor local bus. | ||
48 | |||
49 | Following convention already established with other system-on-chip | ||
50 | processors, 5200 device trees should use the name 'soc5200' for the | ||
51 | parent node of on chip devices, and the root node should be its parent. | ||
52 | |||
53 | Child nodes are typically named after the configured function. ie. | ||
54 | the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'. | ||
55 | |||
56 | 2. device_type property | ||
57 | ----------------------- | ||
58 | similar to the node name convention above; the device_type reflects the | ||
59 | configured function of a device. ie. 'serial' for a uart and 'spi' for | ||
60 | an spi controller. However, while node names *should* reflect the | ||
61 | configured function, device_type *must* match the configured function | ||
62 | exactly. | ||
63 | |||
64 | 3. compatible property | ||
65 | ---------------------- | ||
66 | Since device_type isn't enough to match devices to drivers, there also | ||
67 | needs to be a naming convention for the compatible property. Compatible | ||
68 | is an list of device descriptions sorted from specific to generic. For | ||
69 | the mpc5200, the required format for each compatible value is | ||
70 | <chip>-<device>[-<mode>]. The OS should be able to match a device driver | ||
71 | to the device based solely on the compatible value. If two drivers | ||
72 | match on the compatible list; the 'most compatible' driver should be | ||
73 | selected. | ||
74 | |||
75 | The split between the MPC5200 and the MPC5200B leaves a bit of a | ||
76 | conundrum. How should the compatible property be set up to provide | ||
77 | maximum compatibility information; but still accurately describe the | ||
78 | chip? For the MPC5200; the answer is easy. Most of the SoC devices | ||
79 | originally appeared on the MPC5200. Since they didn't exist anywhere | ||
80 | else; the 5200 compatible properties will contain only one item; | ||
81 | "mpc5200-<device>". | ||
82 | |||
83 | The 5200B is almost the same as the 5200, but not quite. It fixes | ||
84 | silicon bugs and it adds a small number of enhancements. Most of the | ||
85 | devices either provide exactly the same interface as on the 5200. A few | ||
86 | devices have extra functions but still have a backwards compatible mode. | ||
87 | To express this information as completely as possible, 5200B device trees | ||
88 | should have two items in the compatible list; | ||
89 | "mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended | ||
90 | that 5200B device trees follow this convention (instead of only listing | ||
91 | the base mpc5200 item). | ||
92 | |||
93 | If another chip appear on the market with one of the mpc5200 SoC | ||
94 | devices, then the compatible list should include mpc5200-<device>. | ||
95 | |||
96 | ie. ethernet on mpc5200: compatible = "mpc5200-ethernet" | ||
97 | ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet" | ||
98 | |||
99 | Modal devices, like PSCs, also append the configured function to the | ||
100 | end of the compatible field. ie. A PSC in i2s mode would specify | ||
101 | "mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to | ||
102 | avoid naming conflicts with non-psc devices providing the same | ||
103 | function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe | ||
104 | the mpc5200 simple spi device and a PSC spi mode respectively. | ||
105 | |||
106 | If the soc device is more generic and present on other SOCs, the | ||
107 | compatible property can specify the more generic device type also. | ||
108 | |||
109 | ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan"; | ||
110 | |||
111 | At the time of writing, exact chip may be either 'mpc5200' or | ||
112 | 'mpc5200b'. | ||
113 | |||
114 | Device drivers should always try to match as generically as possible. | ||
115 | |||
116 | III - Structure | ||
117 | =============== | ||
118 | The device tree for an mpc5200 board follows the structure defined in | ||
119 | booting-without-of.txt with the following additional notes: | ||
120 | |||
121 | 0) the root node | ||
122 | ---------------- | ||
123 | Typical root description node; see booting-without-of | ||
124 | |||
125 | 1) The cpus node | ||
126 | ---------------- | ||
127 | The cpus node follows the basic layout described in booting-without-of. | ||
128 | The bus-frequency property holds the XLB bus frequency | ||
129 | The clock-frequency property holds the core frequency | ||
130 | |||
131 | 2) The memory node | ||
132 | ------------------ | ||
133 | Typical memory description node; see booting-without-of. | ||
134 | |||
135 | 3) The soc5200 node | ||
136 | ------------------- | ||
137 | This node describes the on chip SOC peripherals. Every mpc5200 based | ||
138 | board will have this node, and as such there is a common naming | ||
139 | convention for SOC devices. | ||
140 | |||
141 | Required properties: | ||
142 | name type description | ||
143 | ---- ---- ----------- | ||
144 | device_type string must be "soc" | ||
145 | ranges int should be <0 baseaddr baseaddr+10000> | ||
146 | reg int must be <baseaddr 10000> | ||
147 | compatible string mpc5200: "mpc5200-soc" | ||
148 | mpc5200b: "mpc5200b-soc\0mpc5200-soc" | ||
149 | system-frequency int Fsystem frequency; source of all | ||
150 | other clocks. | ||
151 | bus-frequency int IPB bus frequency in HZ. Clock rate | ||
152 | used by most of the soc devices. | ||
153 | #interrupt-cells int must be <3>. | ||
154 | |||
155 | Recommended properties: | ||
156 | name type description | ||
157 | ---- ---- ----------- | ||
158 | model string Exact model of the chip; | ||
159 | ie: model="fsl,mpc5200" | ||
160 | revision string Silicon revision of chip | ||
161 | ie: revision="M08A" | ||
162 | |||
163 | The 'model' and 'revision' properties are *strongly* recommended. Having | ||
164 | them presence acts as a bit of a safety net for working around as yet | ||
165 | undiscovered bugs on one version of silicon. For example, device drivers | ||
166 | can use the model and revision properties to decide if a bug fix should | ||
167 | be turned on. | ||
168 | |||
169 | 4) soc5200 child nodes | ||
170 | ---------------------- | ||
171 | Any on chip SOC devices available to Linux must appear as soc5200 child nodes. | ||
172 | |||
173 | Note: The tables below show the value for the mpc5200. A mpc5200b device | ||
174 | tree should use the "mpc5200b-<device>\0mpc5200-<device> form. | ||
175 | |||
176 | Required soc5200 child nodes: | ||
177 | name device_type compatible Description | ||
178 | ---- ----------- ---------- ----------- | ||
179 | cdm@<addr> cdm mpc5200-cmd Clock Distribution | ||
180 | pic@<addr> interrupt-controller mpc5200-pic need an interrupt | ||
181 | controller to boot | ||
182 | bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires | ||
183 | the bestcomm device | ||
184 | |||
185 | Recommended soc5200 child nodes; populate as needed for your board | ||
186 | name device_type compatible Description | ||
187 | ---- ----------- ---------- ----------- | ||
188 | gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers | ||
189 | gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose | ||
190 | timers in GPIO mode | ||
191 | gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio | ||
192 | controller | ||
193 | gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio | ||
194 | controller | ||
195 | rtc@<addr> rtc mpc5200-rtc Real time clock | ||
196 | mscan@<addr> mscan mpc5200-mscan CAN bus controller | ||
197 | pci@<addr> pci mpc5200-pci PCI bridge | ||
198 | serial@<addr> serial mpc5200-psc-uart PSC in serial mode | ||
199 | i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode | ||
200 | ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode | ||
201 | spi@<addr> spi mpc5200-psc-spi PSC in spi mode | ||
202 | irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode | ||
203 | spi@<addr> spi mpc5200-spi MPC5200 spi device | ||
204 | ethernet@<addr> network mpc5200-fec MPC5200 ethernet device | ||
205 | ata@<addr> ata mpc5200-ata IDE ATA interface | ||
206 | i2c@<addr> i2c mpc5200-i2c I2C controller | ||
207 | usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller | ||
208 | xlb@<addr> xlb mpc5200-xlb XLB arbitrator | ||
209 | |||
210 | Important child node properties | ||
211 | name type description | ||
212 | ---- ---- ----------- | ||
213 | cell-index int When multiple devices are present, is the | ||
214 | index of the device in the hardware (ie. There | ||
215 | are 6 PSC on the 5200 numbered PSC1 to PSC6) | ||
216 | PSC1 has 'cell-index = <0>' | ||
217 | PSC4 has 'cell-index = <3>' | ||
218 | |||
219 | 5) General Purpose Timer nodes (child of soc5200 node) | ||
220 | On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board | ||
221 | design supports the internal wdt, then the device node for GPT0 should | ||
222 | include the empty property 'fsl,has-wdt'. | ||
223 | |||
224 | 6) PSC nodes (child of soc5200 node) | ||
225 | PSC nodes can define the optional 'port-number' property to force assignment | ||
226 | order of serial ports. For example, PSC5 might be physically connected to | ||
227 | the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would | ||
228 | have a "port-number = <0>" property, and PSC1 would have "port-number = <1>". | ||
229 | |||
230 | PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in | ||
231 | i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the | ||
232 | compatible field. | ||
233 | |||
234 | 7) GPIO controller nodes | ||
235 | Each GPIO controller node should have the empty property gpio-controller and | ||
236 | #gpio-cells set to 2. First cell is the GPIO number which is interpreted | ||
237 | according to the bit numbers in the GPIO control registers. The second cell | ||
238 | is for flags which is currently unsused. | ||
239 | |||
240 | 8) FEC nodes | ||
241 | The FEC node can specify one of the following properties to configure | ||
242 | the MII link: | ||
243 | "fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire | ||
244 | mode instead of MII | ||
245 | "current-speed" - Specifies that the MII should be configured for a fixed | ||
246 | speed. This property should contain two cells. The | ||
247 | first cell specifies the speed in Mbps and the second | ||
248 | should be '0' for half duplex and '1' for full duplex | ||
249 | "phy-handle" - Contains a phandle to an Ethernet PHY. | ||
250 | |||
251 | IV - Extra Notes | ||
252 | ================ | ||
253 | |||
254 | 1. Interrupt mapping | ||
255 | -------------------- | ||
256 | The mpc5200 pic driver splits hardware IRQ numbers into two levels. The | ||
257 | split reflects the layout of the PIC hardware itself, which groups | ||
258 | interrupts into one of three groups; CRIT, MAIN or PERP. Also, the | ||
259 | Bestcomm dma engine has it's own set of interrupt sources which are | ||
260 | cascaded off of peripheral interrupt 0, which the driver interprets as a | ||
261 | fourth group, SDMA. | ||
262 | |||
263 | The interrupts property for device nodes using the mpc5200 pic consists | ||
264 | of three cells; <L1 L2 level> | ||
265 | |||
266 | L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3] | ||
267 | L2 := interrupt number; directly mapped from the value in the | ||
268 | "ICTL PerStat, MainStat, CritStat Encoded Register" | ||
269 | level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3] | ||
270 | |||
271 | 2. Shared registers | ||
272 | ------------------- | ||
273 | Some SoC devices share registers between them. ie. the i2c devices use | ||
274 | a single clock control register, and almost all device are affected by | ||
275 | the port_config register. Devices which need to manipulate shared regs | ||
276 | should look to the parent SoC node. The soc node is responsible | ||
277 | for arbitrating all shared register access. | ||