aboutsummaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@woody.osdl.org>2006-12-04 19:22:33 -0800
committerLinus Torvalds <torvalds@woody.osdl.org>2006-12-04 19:22:33 -0800
commit15a4cb9c25df05a5d4844e80a1aea83d66165868 (patch)
treebcb4f7c6e84f501ee6ce8c7a740cc7c4ec92447d /Documentation
parentff51a98799931256b555446b2f5675db08de6229 (diff)
parentd8594d639135b500bf6010f981ea854092d54030 (diff)
downloadleg-kernel-15a4cb9c25df05a5d4844e80a1aea83d66165868.tar.gz
Merge master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc
* master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc: (194 commits) [POWERPC] Add missing EXPORTS for mpc52xx support [POWERPC] Remove obsolete PPC_52xx and update CLASSIC32 comment [POWERPC] ps3: add a default zImage target [POWERPC] Add of_platform_bus support to mpc52xx psc uart driver [POWERPC] typo fix and whitespace cleanup on mpc52xx-uart driver [POWERPC] Fix debug printks for 32-bit resources in the PCI code [POWERPC] Replace kmalloc+memset with kzalloc [POWERPC] Linkstation / kurobox support [POWERPC] Add the e300c3 core to the CPU table. [POWERPC] ppc: m48t35 add missing bracket [POWERPC] iSeries: don't build head_64.o unnecessarily [POWERPC] iSeries: stop dt_mod.o being rebuilt unnecessarily [POWERPC] Fix cputable.h for combined build [POWERPC] Allow CONFIG_BOOTX_TEXT on iSeries [POWERPC] Allow xmon to build on legacy iSeries [POWERPC] Change ppc64_defconfig to use AUTOFS_V4 not V3 [POWERPC] Tell firmware we can handle POWER6 compatible mode [POWERPC] Clean images in arch/powerpc/boot [POWERPC] Fix OF pci flags parsing [POWERPC] defconfig for lite5200 board ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/powerpc/booting-without-of.txt39
-rw-r--r--Documentation/powerpc/mpc52xx-device-tree-bindings.txt189
2 files changed, 228 insertions, 0 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 4ac2d641fcb6..b3bd36668db3 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
IBM Corp.
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
Freescale Semiconductor, FSL SOC and 32-bit additions
+(c) 2006 MontaVista Software, Inc.
+ Flash chip node definition
May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
@@ -1693,6 +1695,43 @@ platforms are moved over to use the flattened-device-tree model.
};
};
+ g) Flash chip nodes
+
+ Flash chips (Memory Technology Devices) are often used for solid state
+ file systems on embedded devices.
+
+ Required properties:
+
+ - device_type : has to be "rom"
+ - compatible : Should specify what this ROM device is compatible with
+ (i.e. "onenand"). Currently, this is most likely to be "direct-mapped"
+ (which corresponds to the MTD physmap mapping driver).
+ - regs : Offset and length of the register set (or memory mapping) for
+ the device.
+
+ Recommended properties :
+
+ - bank-width : Width of the flash data bus in bytes. Required
+ for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
+ - partitions : Several pairs of 32-bit values where the first value is
+ partition's offset from the start of the device and the second one is
+ partition size in bytes with LSB used to signify a read only
+ partititon (so, the parition size should always be an even number).
+ - partition-names : The list of concatenated zero terminated strings
+ representing the partition names.
+
+ Example:
+
+ flash@ff000000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ regs = <ff000000 01000000>;
+ bank-width = <4>;
+ partitions = <00000000 00f80000
+ 00f80000 00080001>;
+ partition-names = "fs\0firmware";
+ };
+
More devices will be defined as this spec matures.
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
new file mode 100644
index 000000000000..d077d764f82b
--- /dev/null
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -0,0 +1,189 @@
+MPC52xx Device Tree Bindings
+----------------------------
+
+(c) 2006 Secret Lab Technologies Ltd
+Grant Likely <grant.likely at secretlab.ca>
+
+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
+<chip>-<device>[-<mode>]. 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 <baseaddr 10000>
+
+Recommended properties:
+name type description
+---- ---- -----------
+compatible string should be "<chip>-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 <chip> values. ie.
+*-pic would translate to "mpc5200-pic\0mpc52xx-pic"
+
+Required soc5200 child nodes:
+name device_type compatible Description
+---- ----------- ---------- -----------
+cdm@<addr> cdm *-cmd Clock Distribution
+pic@<addr> interrupt-controller *-pic need an interrupt
+ controller to boot
+bestcomm@<addr> 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@<addr> gpt *-gpt General purpose timers
+rtc@<addr> rtc *-rtc Real time clock
+mscan@<addr> mscan *-mscan CAN bus controller
+pci@<addr> pci *-pci PCI bridge
+serial@<addr> serial *-psc-uart PSC in serial mode
+i2s@<addr> i2s *-psc-i2s PSC in i2s mode
+ac97@<addr> ac97 *-psc-ac97 PSC in ac97 mode
+spi@<addr> spi *-psc-spi PSC in spi mode
+irda@<addr> irda *-psc-irda PSC in IrDA mode
+spi@<addr> spi *-spi MPC52xx spi device
+ethernet@<addr> network *-fec MPC52xx ethernet device
+ata@<addr> ata *-ata IDE ATA interface
+i2c@<addr> i2c *-i2c I2C controller
+usb@<addr> usb-ohci-be *-ohci,ohci-be USB controller
+xlb@<addr> 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 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]