MPC5200 Device Tree Bindings----------------------------(c) 2006-2007 Secret Lab Technologies LtdGrant Likely <grant.likely at secretlab.ca>********** 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 bepassed by the boot loader to the kernel at boot time.  The device treedescribes what devices are present on the board and how they areconnected.  The device tree can either be passed as a binary blob (asdescribed in Documentation/powerpc/booting-without-of.txt), or passedby Open Firmware (IEEE 1275) compatible firmware using an OF compatibleclient interface API.This document specifies the requirements on the device-tree for mpc5200based boards.  These requirements are above and beyond the detailsspecified in either the Open Firmware spec or booting-without-of.txtAll new mpc5200-based boards are expected to match this document.  Incases 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 ofdefining this convention is to reduce or eliminate the number ofspecial cases required to support a 5200 board.  If all 5200 boardsfollow the same convention, then generic 5200 support code will workrather than coding special cases for each new board.This section tries to capture the thought process behind why the namingconvention is what it is.1.  names---------There is strong convention/requirements already established for childrenof the root node.  'cpus' describes the processor cores, 'memory'describes memory, and 'chosen' provides boot configuration.  Other nodesare added to describe devices attached to the processor local bus.Following convention already established with other system-on-chipprocessors, 5200 device trees should use the name 'soc5200' for theparent node of on chip devices, and the root node should be its parent.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 theconfigured function of a device.  ie. 'serial' for a uart and 'spi' foran spi controller.  However, while node names *should* reflect theconfigured function, device_type *must* match the configured functionexactly.3. compatible property----------------------Since device_type isn't enough to match devices to drivers, there alsoneeds to be a naming convention for the compatible property.  Compatibleis an list of device descriptions sorted from specific to generic.  Forthe mpc5200, the required format for each compatible value is<chip>-<device>[-<mode>].  The OS should be able to match a device driverto the device based solely on the compatible value.  If two driversmatch on the compatible list; the 'most compatible' driver should beselected.The split between the MPC5200 and the MPC5200B leaves a bit of aconundrum.  How should the compatible property be set up to providemaximum compatibility information; but still accurately describe thechip?  For the MPC5200; the answer is easy.  Most of the SoC devicesoriginally appeared on the MPC5200.  Since they didn't exist anywhereelse; the 5200 compatible properties will contain only one item;"mpc5200-<device>".The 5200B is almost the same as the 5200, but not quite.  It fixessilicon bugs and it adds a small number of enhancements.  Most of thedevices either provide exactly the same interface as on the 5200.  A fewdevices have extra functions but still have a backwards compatible mode.To express this information as completely as possible, 5200B device treesshould have two items in the compatible list;"mpc5200b-<device>\0mpc5200-<device>".  It is *strongly* recommendedthat 5200B device trees follow this convention (instead of only listingthe base mpc5200 item).If another chip appear on the market with one of the mpc5200 SoCdevices, then the compatible list should include mpc5200-<device>.ie. ethernet on mpc5200: compatible = "mpc5200-ethernet"    ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet"Modal devices, like PSCs, also append the configured function to theend of the compatible field.  ie. A PSC in i2s mode would specify"mpc5200-psc-i2s", not "mpc5200-i2s".  This convention is chosen toavoid naming conflicts with non-psc devices providing the samefunction.  For example, "mpc5200-spi" and "mpc5200-psc-spi" describethe mpc5200 simple spi device and a PSC spi mode respectively.If the soc device is more generic and present on other SOCs, thecompatible property can specify the more generic device type also.ie. mscan: compatible = "mpc5200-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 mpc5200 board follows the structure defined inbooting-without-of.txt with the following additional notes:0) the root node----------------Typical root description node; see booting-without-of1) The cpus node----------------The cpus node follows the basic layout described in booting-without-of.The bus-frequency property holds the XLB bus frequencyThe clock-frequency property holds the core frequency2) The memory node------------------Typical memory description node; see booting-without-of.3) The soc5200 node-------------------This node describes the on chip SOC peripherals.  Every mpc5200 basedboard will have this node, and as such there is a common namingconvention 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 <baseaddr 10000>compatible		string		mpc5200: "mpc5200-soc"					mpc5200b: "mpc5200b-soc\0mpc5200-soc"system-frequency	int		Fsystem frequency; source of all					other clocks.bus-frequency		int		IPB bus frequency in HZ.  Clock rate					used by most of the soc devices.#interrupt-cells	int		must be <3>.Recommended properties:name			type		description----			----		-----------model			string		Exact model of the chip;					ie: model="fsl,mpc5200"revision		string		Silicon revision of chip					ie: revision="M08A"The 'model' and 'revision' properties are *strongly* recommended.  Havingthem presence acts as a bit of a safety net for working around as yetundiscovered bugs on one version of silicon.  For example, device driverscan use the model and revision properties to decide if a bug fix shouldbe turned on.4) soc5200 child nodes----------------------Any on chip SOC devices available to Linux must appear as soc5200 child nodes.Note: The tables below show the value for the mpc5200.  A mpc5200b devicetree should use the "mpc5200b-<device>\0mpc5200-<device> form.Required soc5200 child nodes:name		device_type		compatible	Description----		-----------		----------	-----------cdm@<addr>	cdm			mpc5200-cmd	Clock Distributionpic@<addr>	interrupt-controller	mpc5200-pic	need an interrupt							controller to bootbestcomm@<addr>	dma-controller		mpc5200-bestcomm 5200 pic also requires							 the bestcomm deviceRecommended soc5200 child nodes; populate as needed for your boardname		device_type	compatible	  Description----		-----------	----------	  -----------gpt@<addr>	gpt		fsl,mpc5200-gpt	  General purpose timersrtc@<addr>	rtc		mpc5200-rtc	  Real time clockmscan@<addr>	mscan		mpc5200-mscan	  CAN bus controllerpci@<addr>	pci		mpc5200-pci	  PCI bridgeserial@<addr>	serial		mpc5200-psc-uart  PSC in serial modei2s@<addr>	sound		mpc5200-psc-i2s	  PSC in i2s modeac97@<addr>	sound		mpc5200-psc-ac97  PSC in ac97 modespi@<addr>	spi		mpc5200-psc-spi	  PSC in spi modeirda@<addr>	irda		mpc5200-psc-irda  PSC in IrDA modespi@<addr>	spi		mpc5200-spi	  MPC5200 spi deviceethernet@<addr>	network		mpc5200-fec	  MPC5200 ethernet deviceata@<addr>	ata		mpc5200-ata	  IDE ATA interfacei2c@<addr>	i2c		mpc5200-i2c	  I2C controllerusb@<addr>	usb-ohci-be	mpc5200-ohci,ohci-be	USB controllerxlb@<addr>	xlb		mpc5200-xlb	  XLB arbitratorImportant child node propertiesname		type		description----		----		-----------cell-index	int		When multiple devices are present, is the				index of the device in the hardware (ie. There				are 6 PSC on the 5200 numbered PSC1 to PSC6)				    PSC1 has 'cell-index = <0>'				    PSC4 has 'cell-index = <3>'5) General Purpose Timer nodes (child of soc5200 node)On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the boarddesign supports the internal wdt, then the device node for GPT0 shouldinclude the empty property 'fsl,has-wdt'.6) PSC nodes (child of soc5200 node)PSC nodes can define the optional 'port-number' property to force assignmentorder of serial ports.  For example, PSC5 might be physically connected tothe port labeled 'COM1' and PSC1 wired to 'COM1'.  In this case, PSC5 wouldhave a "port-number = <0>" property, and PSC1 would have "port-number = <1>".PSC in i2s mode:  The mpc5200 and mpc5200b PSCs are not compatible when ini2s mode.  An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in thecompatible field.IV - Extra Notes================1. Interrupt mapping--------------------The mpc5200 pic driver splits hardware IRQ numbers into two levels.  Thesplit reflects the layout of the PIC hardware itself, which groupsinterrupts into one of three groups; CRIT, MAIN or PERP.  Also, theBestcomm dma engine has it's own set of interrupt sources which arecascaded off of peripheral interrupt 0, which the driver interprets as afourth group, SDMA.The interrupts property for device nodes using the mpc5200 pic consistsof three cells; <L1 L2 level>    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]2. Shared registers-------------------Some SoC devices share registers between them.  ie. the i2c devices usea single clock control register, and almost all device are affected bythe port_config register.  Devices which need to manipulate shared regsshould look to the parent SoC node.  The soc node is responsiblefor arbitrating all shared register access.