mpc52xx-device-tree-bindings.txt 11 KB

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