X-Git-Url: http://git.onelab.eu/?p=linux-2.6.git;a=blobdiff_plain;f=Documentation%2Fpowerpc%2Fmpc52xx-device-tree-bindings.txt;fp=Documentation%2Fpowerpc%2Fmpc52xx-device-tree-bindings.txt;h=69f016f02bb0f6055913528b2fa19428872a6584;hp=0000000000000000000000000000000000000000;hb=76828883507a47dae78837ab5dec5a5b4513c667;hpb=64ba3f394c830ec48a1c31b53dcae312c56f1604 diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt new file mode 100644 index 000000000..69f016f02 --- /dev/null +++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt @@ -0,0 +1,195 @@ +MPC52xx Device Tree Bindings +---------------------------- + +(c) 2006 Secret Lab Technologies Ltd +Grant Likely + +********** DRAFT *********** +* WARNING: Do not depend on the stability of these bindings just yet. +* The MPC5200 device tree conventions are still in flux +* Keep an eye on the linuxppc-dev mailing list for more details +********** DRAFT *********** + +I - Introduction +================ +Boards supported by the arch/powerpc architecture require device tree be +passed by the boot loader to the kernel at boot time. The device tree +describes what devices are present on the board and how they are +connected. The device tree can either be passed as a binary blob (as +described in Documentation/powerpc/booting-without-of.txt), or passed +by Open Firmare (IEEE 1275) compatible firmware using an OF compatible +client interface API. + +This document specifies the requirements on the device-tree for mpc52xx +based boards. These requirements are above and beyond the details +specified in either the OpenFirmware spec or booting-without-of.txt + +All new mpc52xx-based boards are expected to match this document. In +cases where this document is not sufficient to support a new board port, +this document should be updated as part of adding the new board support. + +II - Philosophy +=============== +The core of this document is naming convention. The whole point of +defining this convention is to reduce or eliminate the number of +special cases required to support a 52xx board. If all 52xx boards +follow the same convention, then generic 52xx support code will work +rather than coding special cases for each new board. + +This section tries to capture the thought process behind why the naming +convention is what it is. + +1. Node names +------------- +There is strong convention/requirements already established for children +of the root node. 'cpus' describes the processor cores, 'memory' +describes memory, and 'chosen' provides boot configuration. Other nodes +are added to describe devices attached to the processor local bus. +Following convention already established with other system-on-chip +processors, MPC52xx boards must have an 'soc5200' node as a child of the +root node. + +The soc5200 node holds child nodes for all on chip devices. Child nodes +are typically named after the configured function. ie. the FEC node is +named 'ethernet', and a PSC in uart mode is named 'serial'. + +2. device_type property +----------------------- +similar to the node name convention above; the device_type reflects the +configured function of a device. ie. 'serial' for a uart and 'spi' for +an spi controller. However, while node names *should* reflect the +configured function, device_type *must* match the configured function +exactly. + +3. compatible property +---------------------- +Since device_type isn't enough to match devices to drivers, there also +needs to be a naming convention for the compatible property. Compatible +is an list of device descriptions sorted from specific to generic. For +the mpc52xx, the required format for each compatible value is +-[-]. At the minimum, the list shall contain two +items; the first specifying the exact chip, and the second specifying +mpc52xx for the chip. + +ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet" + +The idea here is that most drivers will match to the most generic field +in the compatible list (mpc52xx-*), but can also test the more specific +field for enabling bug fixes or extra features. + +Modal devices, like PSCs, also append the configured function to the +end of the compatible field. ie. A PSC in i2s mode would specify +"mpc52xx-psc-i2s", not "mpc52xx-i2s". This convention is chosen to +avoid naming conflicts with non-psc devices providing the same +function. For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe +the mpc5200 simple spi device and a PSC spi mode respectively. + +If the soc device is more generic and present on other SOCs, the +compatible property can specify the more generic device type also. + +ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan"; + +At the time of writing, exact chip may be either 'mpc5200' or +'mpc5200b'. + +Device drivers should always try to match as generically as possible. + +III - Structure +=============== +The device tree for an mpc52xx board follows the structure defined in +booting-without-of.txt with the following additional notes: + +0) the root node +---------------- +Typical root description node; see booting-without-of + +1) The cpus node +---------------- +The cpus node follows the basic layout described in booting-without-of. +The bus-frequency property holds the XLB bus frequency +The clock-frequency property holds the core frequency + +2) The memory node +------------------ +Typical memory description node; see booting-without-of. + +3) The soc5200 node +------------------- +This node describes the on chip SOC peripherals. Every mpc52xx based +board will have this node, and as such there is a common naming +convention for SOC devices. + +Required properties: +name type description +---- ---- ----------- +device_type string must be "soc" +ranges int should be <0 baseaddr baseaddr+10000> +reg int must be + +Recommended properties: +name type description +---- ---- ----------- +compatible string should be "-soc\0mpc52xx-soc" + ie. "mpc5200b-soc\0mpc52xx-soc" +#interrupt-cells int must be <3>. If it is not defined + here then it must be defined in every + soc device node. +bus-frequency int IPB bus frequency in HZ. Clock rate + used by most of the soc devices. + Defining it here avoids needing it + added to every device node. + +4) soc5200 child nodes +---------------------- +Any on chip SOC devices available to Linux must appear as soc5200 child nodes. + +Note: in the tables below, '*' matches all values. ie. +*-pic would translate to "mpc5200-pic\0mpc52xx-pic" + +Required soc5200 child nodes: +name device_type compatible Description +---- ----------- ---------- ----------- +cdm@ cdm *-cmd Clock Distribution +pic@ interrupt-controller *-pic need an interrupt + controller to boot +bestcomm@ dma-controller *-bestcomm 52xx pic also requires + the bestcomm device + +Recommended soc5200 child nodes; populate as needed for your board +name device_type compatible Description +---- ----------- ---------- ----------- +gpt@ gpt *-gpt General purpose timers +rtc@ rtc *-rtc Real time clock +mscan@ mscan *-mscan CAN bus controller +pci@ pci *-pci PCI bridge +serial@ serial *-psc-uart PSC in serial mode +i2s@ sound *-psc-i2s PSC in i2s mode +ac97@ sound *-psc-ac97 PSC in ac97 mode +spi@ spi *-psc-spi PSC in spi mode +irda@ irda *-psc-irda PSC in IrDA mode +spi@ spi *-spi MPC52xx spi device +ethernet@ network *-fec MPC52xx ethernet device +ata@ ata *-ata IDE ATA interface +i2c@ i2c *-i2c I2C controller +usb@ usb-ohci-be *-ohci,ohci-be USB controller +xlb@ xlb *-xlb XLB arbritrator + +IV - Extra Notes +================ + +1. Interrupt mapping +-------------------- +The mpc52xx pic driver splits hardware IRQ numbers into two levels. The +split reflects the layout of the PIC hardware itself, which groups +interrupts into one of three groups; CRIT, MAIN or PERP. Also, the +Bestcomm dma engine has it's own set of interrupt sources which are +cascaded off of peripheral interrupt 0, which the driver interprets as a +fourth group, SDMA. + +The interrupts property for device nodes using the mpc52xx pic consists +of three cells; + + L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3] + L2 := interrupt number; directly mapped from the value in the + "ICTL PerStat, MainStat, CritStat Encoded Register" + level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]