Documentation/powerpc/mpc52xx-device-tree-bindings.txt

   1 MPC52xx Device Tree Bindings
   2 ----------------------------
   3
   4 (c) 2006 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 Firmare (IEEE 1275) compatible firmware using an OF compatible
  21 client interface API.
  22
  23 This document specifies the requirements on the device-tree for mpc52xx
  24 based boards.  These requirements are above and beyond the details
  25 specified in either the OpenFirmware spec or booting-without-of.txt
  26
  27 All new mpc52xx-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 52xx board.  If all 52xx boards
  36 follow the same convention, then generic 52xx 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. Node 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 Following convention already established with other system-on-chip
  49 processors, MPC52xx boards must have an 'soc5200' node as a child of the
  50 root node.
  51
  52 The soc5200 node holds child nodes for all on chip devices.  Child nodes
  53 are typically named after the configured function.  ie. the FEC node is
  54 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 mpc52xx, the required format for each compatible value is
  70 <chip>-<device>[-<mode>].  At the minimum, the list shall contain two
  71 items; the first specifying the exact chip, and the second specifying
  72 mpc52xx for the chip.
  73
  74 ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet"
  75
  76 The idea here is that most drivers will match to the most generic field
  77 in the compatible list (mpc52xx-*), but can also test the more specific
  78 field for enabling bug fixes or extra features.
  79
  80 Modal devices, like PSCs, also append the configured function to the
  81 end of the compatible field.  ie. A PSC in i2s mode would specify
  82 "mpc52xx-psc-i2s", not "mpc52xx-i2s".  This convention is chosen to
  83 avoid naming conflicts with non-psc devices providing the same
  84 function.  For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe
  85 the mpc5200 simple spi device and a PSC spi mode respectively.
  86
  87 If the soc device is more generic and present on other SOCs, the
  88 compatible property can specify the more generic device type also.
  89
  90 ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan";
  91
  92 At the time of writing, exact chip may be either 'mpc5200' or
  93 'mpc5200b'.
  94
  95 Device drivers should always try to match as generically as possible.
  96
  97 III - Structure
  98 ===============
  99 The device tree for an mpc52xx board follows the structure defined in
 100 booting-without-of.txt with the following additional notes:
 101
 102 0) the root node
 103 ----------------
 104 Typical root description node; see booting-without-of
 105
 106 1) The cpus node
 107 ----------------
 108 The cpus node follows the basic layout described in booting-without-of.
 109 The bus-frequency property holds the XLB bus frequency
 110 The clock-frequency property holds the core frequency
 111
 112 2) The memory node
 113 ------------------
 114 Typical memory description node; see booting-without-of.
 115
 116 3) The soc5200 node
 117 -------------------
 118 This node describes the on chip SOC peripherals.  Every mpc52xx based
 119 board will have this node, and as such there is a common naming
 120 convention for SOC devices.
 121
 122 Required properties:
 123 name                    type            description
 124 ----                    ----            -----------
 125 device_type             string          must be "soc"
 126 ranges                  int             should be <0 baseaddr baseaddr+10000>
 127 reg                     int             must be <baseaddr 10000>
 128
 129 Recommended properties:
 130 name                    type            description
 131 ----                    ----            -----------
 132 compatible              string          should be "<chip>-soc\0mpc52xx-soc"
 133                                         ie. "mpc5200b-soc\0mpc52xx-soc"
 134 #interrupt-cells        int             must be <3>.  If it is not defined
 135                                         here then it must be defined in every
 136                                         soc device node.
 137 bus-frequency           int             IPB bus frequency in HZ.  Clock rate
 138                                         used by most of the soc devices.
 139                                         Defining it here avoids needing it
 140                                         added to every device node.
 141
 142 4) soc5200 child nodes
 143 ----------------------
 144 Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
 145
 146 Note: in the tables below, '*' matches all <chip> values.  ie.
 147 *-pic would translate to "mpc5200-pic\0mpc52xx-pic"
 148
 149 Required soc5200 child nodes:
 150 name            device_type             compatible      Description
 151 ----            -----------             ----------      -----------
 152 cdm@<addr>      cdm                     *-cmd           Clock Distribution
 153 pic@<addr>      interrupt-controller    *-pic           need an interrupt
 154                                                         controller to boot
 155 bestcomm@<addr> dma-controller          *-bestcomm      52xx pic also requires
 156                                                         the bestcomm device
 157
 158 Recommended soc5200 child nodes; populate as needed for your board
 159 name            device_type     compatible      Description
 160 ----            -----------     ----------      -----------
 161 gpt@<addr>      gpt             *-gpt           General purpose timers
 162 rtc@<addr>      rtc             *-rtc           Real time clock
 163 mscan@<addr>    mscan           *-mscan         CAN bus controller
 164 pci@<addr>      pci             *-pci           PCI bridge
 165 serial@<addr>   serial          *-psc-uart      PSC in serial mode
 166 i2s@<addr>      sound           *-psc-i2s       PSC in i2s mode
 167 ac97@<addr>     sound           *-psc-ac97      PSC in ac97 mode
 168 spi@<addr>      spi             *-psc-spi       PSC in spi mode
 169 irda@<addr>     irda            *-psc-irda      PSC in IrDA mode
 170 spi@<addr>      spi             *-spi           MPC52xx spi device
 171 ethernet@<addr> network         *-fec           MPC52xx ethernet device
 172 ata@<addr>      ata             *-ata           IDE ATA interface
 173 i2c@<addr>      i2c             *-i2c           I2C controller
 174 usb@<addr>      usb-ohci-be     *-ohci,ohci-be  USB controller
 175 xlb@<addr>      xlb             *-xlb           XLB arbritrator
 176
 177 IV - Extra Notes
 178 ================
 179
 180 1. Interrupt mapping
 181 --------------------
 182 The mpc52xx pic driver splits hardware IRQ numbers into two levels.  The
 183 split reflects the layout of the PIC hardware itself, which groups
 184 interrupts into one of three groups; CRIT, MAIN or PERP.  Also, the
 185 Bestcomm dma engine has it's own set of interrupt sources which are
 186 cascaded off of peripheral interrupt 0, which the driver interprets as a
 187 fourth group, SDMA.
 188
 189 The interrupts property for device nodes using the mpc52xx pic consists
 190 of three cells; <L1 L2 level>
 191
 192     L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
 193     L2 := interrupt number; directly mapped from the value in the
 194           "ICTL PerStat, MainStat, CritStat Encoded Register"
 195     level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]