aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/powerpc/booting-without-of.txt39
-rw-r--r--Documentation/powerpc/mpc52xx-device-tree-bindings.txt189
2 files changed, 228 insertions, 0 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 4ac2d641fcb6..b3bd36668db3 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
6 IBM Corp. 6 IBM Corp.
7(c) 2005 Becky Bruce <becky.bruce at freescale.com>, 7(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
8 Freescale Semiconductor, FSL SOC and 32-bit additions 8 Freescale Semiconductor, FSL SOC and 32-bit additions
9(c) 2006 MontaVista Software, Inc.
10 Flash chip node definition
9 11
10 May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet. 12 May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
11 13
@@ -1693,6 +1695,43 @@ platforms are moved over to use the flattened-device-tree model.
1693 }; 1695 };
1694 }; 1696 };
1695 1697
1698 g) Flash chip nodes
1699
1700 Flash chips (Memory Technology Devices) are often used for solid state
1701 file systems on embedded devices.
1702
1703 Required properties:
1704
1705 - device_type : has to be "rom"
1706 - compatible : Should specify what this ROM device is compatible with
1707 (i.e. "onenand"). Currently, this is most likely to be "direct-mapped"
1708 (which corresponds to the MTD physmap mapping driver).
1709 - regs : Offset and length of the register set (or memory mapping) for
1710 the device.
1711
1712 Recommended properties :
1713
1714 - bank-width : Width of the flash data bus in bytes. Required
1715 for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
1716 - partitions : Several pairs of 32-bit values where the first value is
1717 partition's offset from the start of the device and the second one is
1718 partition size in bytes with LSB used to signify a read only
1719 partititon (so, the parition size should always be an even number).
1720 - partition-names : The list of concatenated zero terminated strings
1721 representing the partition names.
1722
1723 Example:
1724
1725 flash@ff000000 {
1726 device_type = "rom";
1727 compatible = "direct-mapped";
1728 regs = <ff000000 01000000>;
1729 bank-width = <4>;
1730 partitions = <00000000 00f80000
1731 00f80000 00080001>;
1732 partition-names = "fs\0firmware";
1733 };
1734
1696 More devices will be defined as this spec matures. 1735 More devices will be defined as this spec matures.
1697 1736
1698 1737
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
new file mode 100644
index 000000000000..d077d764f82b
--- /dev/null
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -0,0 +1,189 @@
1MPC52xx Device Tree Bindings
2----------------------------
3
4(c) 2006 Secret Lab Technologies Ltd
5Grant Likely <grant.likely at secretlab.ca>
6
7I - Introduction
8================
9Boards supported by the arch/powerpc architecture require device tree be
10passed by the boot loader to the kernel at boot time. The device tree
11describes what devices are present on the board and how they are
12connected. The device tree can either be passed as a binary blob (as
13described in Documentation/powerpc/booting-without-of.txt), or passed
14by Open Firmare (IEEE 1275) compatible firmware using an OF compatible
15client interface API.
16
17This document specifies the requirements on the device-tree for mpc52xx
18based boards. These requirements are above and beyond the details
19specified in either the OpenFirmware spec or booting-without-of.txt
20
21All new mpc52xx-based boards are expected to match this document. In
22cases where this document is not sufficient to support a new board port,
23this document should be updated as part of adding the new board support.
24
25II - Philosophy
26===============
27The core of this document is naming convention. The whole point of
28defining this convention is to reduce or eliminate the number of
29special cases required to support a 52xx board. If all 52xx boards
30follow the same convention, then generic 52xx support code will work
31rather than coding special cases for each new board.
32
33This section tries to capture the thought process behind why the naming
34convention is what it is.
35
361. Node names
37-------------
38There is strong convention/requirements already established for children
39of the root node. 'cpus' describes the processor cores, 'memory'
40describes memory, and 'chosen' provides boot configuration. Other nodes
41are added to describe devices attached to the processor local bus.
42Following convention already established with other system-on-chip
43processors, MPC52xx boards must have an 'soc5200' node as a child of the
44root node.
45
46The soc5200 node holds child nodes for all on chip devices. Child nodes
47are typically named after the configured function. ie. the FEC node is
48named 'ethernet', and a PSC in uart mode is named 'serial'.
49
502. device_type property
51-----------------------
52similar to the node name convention above; the device_type reflects the
53configured function of a device. ie. 'serial' for a uart and 'spi' for
54an spi controller. However, while node names *should* reflect the
55configured function, device_type *must* match the configured function
56exactly.
57
583. compatible property
59----------------------
60Since device_type isn't enough to match devices to drivers, there also
61needs to be a naming convention for the compatible property. Compatible
62is an list of device descriptions sorted from specific to generic. For
63the mpc52xx, the required format for each compatible value is
64<chip>-<device>[-<mode>]. At the minimum, the list shall contain two
65items; the first specifying the exact chip, and the second specifying
66mpc52xx for the chip.
67
68ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet"
69
70The idea here is that most drivers will match to the most generic field
71in the compatible list (mpc52xx-*), but can also test the more specific
72field for enabling bug fixes or extra features.
73
74Modal devices, like PSCs, also append the configured function to the
75end of the compatible field. ie. A PSC in i2s mode would specify
76"mpc52xx-psc-i2s", not "mpc52xx-i2s". This convention is chosen to
77avoid naming conflicts with non-psc devices providing the same
78function. For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe
79the mpc5200 simple spi device and a PSC spi mode respectively.
80
81If the soc device is more generic and present on other SOCs, the
82compatible property can specify the more generic device type also.
83
84ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan";
85
86At the time of writing, exact chip may be either 'mpc5200' or
87'mpc5200b'.
88
89Device drivers should always try to match as generically as possible.
90
91III - Structure
92===============
93The device tree for an mpc52xx board follows the structure defined in
94booting-without-of.txt with the following additional notes:
95
960) the root node
97----------------
98Typical root description node; see booting-without-of
99
1001) The cpus node
101----------------
102The cpus node follows the basic layout described in booting-without-of.
103The bus-frequency property holds the XLB bus frequency
104The clock-frequency property holds the core frequency
105
1062) The memory node
107------------------
108Typical memory description node; see booting-without-of.
109
1103) The soc5200 node
111-------------------
112This node describes the on chip SOC peripherals. Every mpc52xx based
113board will have this node, and as such there is a common naming
114convention for SOC devices.
115
116Required properties:
117name type description
118---- ---- -----------
119device_type string must be "soc"
120ranges int should be <0 baseaddr baseaddr+10000>
121reg int must be <baseaddr 10000>
122
123Recommended properties:
124name type description
125---- ---- -----------
126compatible string should be "<chip>-soc\0mpc52xx-soc"
127 ie. "mpc5200b-soc\0mpc52xx-soc"
128#interrupt-cells int must be <3>. If it is not defined
129 here then it must be defined in every
130 soc device node.
131bus-frequency int IPB bus frequency in HZ. Clock rate
132 used by most of the soc devices.
133 Defining it here avoids needing it
134 added to every device node.
135
1364) soc5200 child nodes
137----------------------
138Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
139
140Note: in the tables below, '*' matches all <chip> values. ie.
141*-pic would translate to "mpc5200-pic\0mpc52xx-pic"
142
143Required soc5200 child nodes:
144name device_type compatible Description
145---- ----------- ---------- -----------
146cdm@<addr> cdm *-cmd Clock Distribution
147pic@<addr> interrupt-controller *-pic need an interrupt
148 controller to boot
149bestcomm@<addr> dma-controller *-bestcomm 52xx pic also requires
150 the bestcomm device
151
152Recommended soc5200 child nodes; populate as needed for your board
153name device_type compatible Description
154---- ----------- ---------- -----------
155gpt@<addr> gpt *-gpt General purpose timers
156rtc@<addr> rtc *-rtc Real time clock
157mscan@<addr> mscan *-mscan CAN bus controller
158pci@<addr> pci *-pci PCI bridge
159serial@<addr> serial *-psc-uart PSC in serial mode
160i2s@<addr> i2s *-psc-i2s PSC in i2s mode
161ac97@<addr> ac97 *-psc-ac97 PSC in ac97 mode
162spi@<addr> spi *-psc-spi PSC in spi mode
163irda@<addr> irda *-psc-irda PSC in IrDA mode
164spi@<addr> spi *-spi MPC52xx spi device
165ethernet@<addr> network *-fec MPC52xx ethernet device
166ata@<addr> ata *-ata IDE ATA interface
167i2c@<addr> i2c *-i2c I2C controller
168usb@<addr> usb-ohci-be *-ohci,ohci-be USB controller
169xlb@<addr> xlb *-xlb XLB arbritrator
170
171IV - Extra Notes
172================
173
1741. Interrupt mapping
175--------------------
176The mpc52xx pic driver splits hardware IRQ numbers into two levels. The
177split reflects the layout of the PIC hardware itself, which groups
178interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
179Bestcomm dma engine has it's own set of interrupt sources which are
180cascaded off of peripheral interrupt 0, which the driver interprets as a
181fourth group, SDMA.
182
183The interrupts property for device nodes using the mpc52xx pic consists
184of three cells; <L1 L2 level>
185
186 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
187 L2 := interrupt number; directly mapped from the value in the
188 "ICTL PerStat, MainStat, CritStat Encoded Register"
189 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]