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

   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.