[POWERPC] Xilinx: hwicap: update booting-without-of.txt
[sfrench/cifs-2.6.git] / Documentation / powerpc / booting-without-of.txt
index a96e85397eb792cb10e5e5cc066664846a1b289e..2efea2d497f8ed86f1dffbeb2f5859610ac38fe9 100644 (file)
@@ -52,6 +52,11 @@ Table of Contents
       i) Freescale QUICC Engine module (QE)
       j) CFI or JEDEC memory-mapped NOR flash
       k) Global Utilities Block
+      l) Freescale Communications Processor Module
+      m) Chipselect/Local Bus
+      n) 4xx/Axon EMAC ethernet nodes
+      o) Xilinx IP cores
+      p) Freescale Synchronous Serial Interface
 
   VII - Specifying interrupt information for devices
     1) interrupts property
@@ -670,10 +675,10 @@ device or bus to be described by the device tree.
 
 In general, the format of an address for a device is defined by the
 parent bus type, based on the #address-cells and #size-cells
-property. In the absence of such a property, the parent's parent
-values are used, etc... The kernel requires the root node to have
-those properties defining addresses format for devices directly mapped
-on the processor bus.
+properties.  Note that the parent's parent definitions of #address-cells
+and #size-cells are not inhereted so every node with children must specify
+them.  The kernel requires the root node to have those properties defining
+addresses format for devices directly mapped on the processor bus.
 
 Those 2 properties define 'cells' for representing an address and a
 size. A "cell" is a 32-bit number. For example, if both contain 2
@@ -710,13 +715,14 @@ define a bus type with a more complex address format, including things
 like address space bits, you'll have to add a bus translator to the
 prom_parse.c file of the recent kernels for your bus type.
 
-The "reg" property only defines addresses and sizes (if #size-cells
-is non-0) within a given bus. In order to translate addresses upward
+The "reg" property only defines addresses and sizes (if #size-cells is
+non-0) within a given bus. In order to translate addresses upward
 (that is into parent bus addresses, and possibly into CPU physical
 addresses), all busses must contain a "ranges" property. If the
 "ranges" property is missing at a given level, it's assumed that
-translation isn't possible. The format of the "ranges" property for a
-bus is a list of:
+translation isn't possible, i.e., the registers are not visible on the
+parent bus.  The format of the "ranges" property for a bus is a list
+of:
 
        bus address, parent bus address, size
 
@@ -734,6 +740,10 @@ fit in a single 32-bit word.   New 32-bit powerpc boards should use a
 1/1 format, unless the processor supports physical addresses greater
 than 32-bits, in which case a 2/1 format is recommended.
 
+Alternatively, the "ranges" property may be empty, indicating that the
+registers are visible on the parent bus using an identity mapping
+translation.  In other words, the parent bus address space is the same
+as the child bus address space.
 
 2) Note about "compatible" properties
 -------------------------------------
@@ -851,12 +861,18 @@ address which can extend beyond that limit.
         /cpus/PowerPC,970FX@0
         /cpus/PowerPC,970FX@1
       (unit addresses do not require leading zeroes)
-    - d-cache-line-size : one cell, L1 data cache line size in bytes
-    - i-cache-line-size : one cell, L1 instruction cache line size in
+    - d-cache-block-size : one cell, L1 data cache block size in bytes (*)
+    - i-cache-block-size : one cell, L1 instruction cache block size in
       bytes
     - d-cache-size : one cell, size of L1 data cache in bytes
     - i-cache-size : one cell, size of L1 instruction cache in bytes
 
+(*) The cache "block" size is the size on which the cache management
+instructions operate. Historically, this document used the cache
+"line" size here which is incorrect. The kernel will prefer the cache
+block size and will fallback to cache line size for backward
+compatibility.
+
   Recommended properties:
 
     - timebase-frequency : a cell indicating the frequency of the
@@ -870,6 +886,10 @@ address which can extend beyond that limit.
       for the above, the common code doesn't use that property, but
       you are welcome to re-use the pSeries or Maple one. A future
       kernel version might provide a common function for this.
+    - d-cache-line-size : one cell, L1 data cache line size in bytes
+      if different from the block size
+    - i-cache-line-size : one cell, L1 instruction cache line size in
+      bytes if different from the block size
 
   You are welcome to add any property you find relevant to your board,
   like some information about the mechanism used to soft-reset the
@@ -1207,16 +1227,14 @@ platforms are moved over to use the flattened-device-tree model.
 
   Required properties:
     - reg : Offset and length of the register set for the device
-    - device_type : Should be "mdio"
     - compatible : Should define the compatible device type for the
-      mdio.  Currently, this is most likely to be "gianfar"
+      mdio.  Currently, this is most likely to be "fsl,gianfar-mdio"
 
   Example:
 
        mdio@24520 {
                reg = <24520 20>;
-               device_type = "mdio"; 
-               compatible = "gianfar";
+               compatible = "fsl,gianfar-mdio";
 
                ethernet-phy@0 {
                        ......
@@ -1243,6 +1261,10 @@ platforms are moved over to use the flattened-device-tree model.
       services interrupts for this device.
     - phy-handle : The phandle for the PHY connected to this ethernet
       controller.
+    - fixed-link : <a b c d e> where a is emulated phy id - choose any,
+      but unique to the all specified fixed-links, b is duplex - 0 half,
+      1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
+      pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
 
   Recommended properties:
 
@@ -1397,7 +1419,6 @@ platforms are moved over to use the flattened-device-tree model.
 
    Example multi port host USB controller device node :
        usb@22000 {
-               device_type = "usb";
                compatible = "fsl-usb2-mph";
                reg = <22000 1000>;
                #address-cells = <1>;
@@ -1411,7 +1432,6 @@ platforms are moved over to use the flattened-device-tree model.
 
    Example dual role USB controller device node :
        usb@23000 {
-               device_type = "usb";
                compatible = "fsl-usb2-dr";
                reg = <23000 1000>;
                #address-cells = <1>;
@@ -1523,7 +1543,7 @@ platforms are moved over to use the flattened-device-tree model.
    i) Root QE device
 
    Required properties:
-   - device_type : should be "qe";
+   - compatible : should be "fsl,qe";
    - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
    - reg : offset and length of the device registers.
    - bus-frequency : the clock frequency for QUICC Engine.
@@ -1537,8 +1557,7 @@ platforms are moved over to use the flattened-device-tree model.
                #address-cells = <1>;
                #size-cells = <1>;
                #interrupt-cells = <2>;
-               device_type = "qe";
-               model = "QE";
+               compatible = "fsl,qe";
                ranges = <0 e0100000 00100000>;
                reg = <e0100000 480>;
                brg-frequency = <0>;
@@ -1549,8 +1568,8 @@ platforms are moved over to use the flattened-device-tree model.
    ii) SPI (Serial Peripheral Interface)
 
    Required properties:
-   - device_type : should be "spi".
-   - compatible : should be "fsl_spi".
+   - cell-index : SPI controller index.
+   - compatible : should be "fsl,spi".
    - mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
    - reg : Offset and length of the register set for the device
    - interrupts : <a b> where a is the interrupt number and b is a
@@ -1563,8 +1582,8 @@ platforms are moved over to use the flattened-device-tree model.
 
    Example:
        spi@4c0 {
-               device_type = "spi";
-               compatible = "fsl_spi";
+               cell-index = <0>;
+               compatible = "fsl,spi";
                reg = <4c0 40>;
                interrupts = <82 0>;
                interrupt-parent = <700>;
@@ -1575,7 +1594,6 @@ platforms are moved over to use the flattened-device-tree model.
    iii) USB (Universal Serial Bus Controller)
 
    Required properties:
-   - device_type : should be "usb".
    - compatible : could be "qe_udc" or "fhci-hcd".
    - mode : the could be "host" or "slave".
    - reg : Offset and length of the register set for the device
@@ -1589,7 +1607,6 @@ platforms are moved over to use the flattened-device-tree model.
 
    Example(slave):
        usb@6c0 {
-               device_type = "usb";
                compatible = "qe_udc";
                reg = <6c0 40>;
                interrupts = <8b 0>;
@@ -1602,7 +1619,7 @@ platforms are moved over to use the flattened-device-tree model.
 
    Required properties:
    - device_type : should be "network", "hldc", "uart", "transparent"
-    "bisync" or "atm".
+     "bisync", "atm", or "serial".
    - compatible : could be "ucc_geth" or "fsl_atm" and so on.
    - model : should be "UCC".
    - device-id : the ucc number(1-8), corresponding to UCCx in UM.
@@ -1615,6 +1632,26 @@ platforms are moved over to use the flattened-device-tree model.
    - interrupt-parent : the phandle for the interrupt controller that
      services interrupts for this device.
    - pio-handle : The phandle for the Parallel I/O port configuration.
+   - port-number : for UART drivers, the port number to use, between 0 and 3.
+     This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0.
+     The port number is added to the minor number of the device.  Unlike the
+     CPM UART driver, the port-number is required for the QE UART driver.
+   - soft-uart : for UART drivers, if specified this means the QE UART device
+     driver should use "Soft-UART" mode, which is needed on some SOCs that have
+     broken UART hardware.  Soft-UART is provided via a microcode upload.
+   - rx-clock-name: the UCC receive clock source
+     "none": clock source is disabled
+     "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+     "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+   - tx-clock-name: the UCC transmit clock source
+     "none": clock source is disabled
+     "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+     "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+   The following two properties are deprecated.  rx-clock has been replaced
+   with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
+   Drivers that currently use the deprecated properties should continue to
+   do so, in order to support older device trees, but they should be updated
+   to check for the new properties first.
    - rx-clock : represents the UCC receive clock source.
      0x00 : clock source is disabled;
      0x1~0x10 : clock source is BRG1~BRG16 respectively;
@@ -1634,8 +1671,9 @@ platforms are moved over to use the flattened-device-tree model.
      MAC addresses passed by the firmware when no information other
      than indices is available to associate an address with a device.
    - phy-connection-type : a string naming the controller/PHY interface type,
-     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi",
-     or "rtbi".
+     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+     Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+     "tbi", or "rtbi".
 
    Example:
        ucc@2000 {
@@ -1742,7 +1780,7 @@ platforms are moved over to use the flattened-device-tree model.
    vii) Multi-User RAM (MURAM)
 
    Required properties:
-   - device_type : should be "muram".
+   - compatible : should be "fsl,qe-muram", "fsl,cpm-muram".
    - mode : the could be "host" or "slave".
    - ranges : Should be defined as specified in 1) to describe the
       translation of MURAM addresses.
@@ -1752,14 +1790,42 @@ platforms are moved over to use the flattened-device-tree model.
    Example:
 
        muram@10000 {
-               device_type = "muram";
+               compatible = "fsl,qe-muram", "fsl,cpm-muram";
                ranges = <0 00010000 0000c000>;
 
                data-only@0{
+                       compatible = "fsl,qe-muram-data",
+                                    "fsl,cpm-muram-data";
                        reg = <0 c000>;
                };
        };
 
+   viii) Uploaded QE firmware
+
+        If a new firwmare has been uploaded to the QE (usually by the
+        boot loader), then a 'firmware' child node should be added to the QE
+        node.  This node provides information on the uploaded firmware that
+        device drivers may need.
+
+        Required properties:
+        - id: The string name of the firmware.  This is taken from the 'id'
+              member of the qe_firmware structure of the uploaded firmware.
+              Device drivers can search this string to determine if the
+              firmware they want is already present.
+        - extended-modes: The Extended Modes bitfield, taken from the
+                          firmware binary.  It is a 64-bit number represented
+                          as an array of two 32-bit numbers.
+        - virtual-traps: The virtual traps, taken from the firmware binary.
+                         It is an array of 8 32-bit numbers.
+
+        Example:
+
+               firmware {
+                       id = "Soft-UART";
+                       extended-modes = <0 0>;
+                       virtual-traps = <0 0 0 0 0 0 0 0>;
+               }
+
    j) CFI or JEDEC memory-mapped NOR flash
 
     Flash chips (Memory Technology Devices) are often used for solid state
@@ -2063,8 +2129,7 @@ platforms are moved over to use the flattened-device-tree model.
 
    Example:
        localbus@f0010100 {
-               compatible = "fsl,mpc8272ads-localbus",
-                            "fsl,mpc8272-localbus",
+               compatible = "fsl,mpc8272-localbus",
                             "fsl,pq2-localbus";
                #address-cells = <2>;
                #size-cells = <1>;
@@ -2242,6 +2307,488 @@ platforms are moved over to use the flattened-device-tree model.
                           available.
                           For Axon: 0x0000012a
 
+   o) Xilinx IP cores
+
+   The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
+   in Xilinx Spartan and Virtex FPGAs.  The devices cover the whole range
+   of standard device types (network, serial, etc.) and miscellanious
+   devices (gpio, LCD, spi, etc).  Also, since these devices are
+   implemented within the fpga fabric every instance of the device can be
+   synthesised with different options that change the behaviour.
+
+   Each IP-core has a set of parameters which the FPGA designer can use to
+   control how the core is synthesized.  Historically, the EDK tool would
+   extract the device parameters relevant to device drivers and copy them
+   into an 'xparameters.h' in the form of #define symbols.  This tells the
+   device drivers how the IP cores are configured, but it requres the kernel
+   to be recompiled every time the FPGA bitstream is resynthesized.
+
+   The new approach is to export the parameters into the device tree and
+   generate a new device tree each time the FPGA bitstream changes.  The
+   parameters which used to be exported as #defines will now become
+   properties of the device node.  In general, device nodes for IP-cores
+   will take the following form:
+
+       (name): (generic-name)@(base-address) {
+               compatible = "xlnx,(ip-core-name)-(HW_VER)"
+                            [, (list of compatible devices), ...];
+               reg = <(baseaddr) (size)>;
+               interrupt-parent = <&interrupt-controller-phandle>;
+               interrupts = < ... >;
+               xlnx,(parameter1) = "(string-value)";
+               xlnx,(parameter2) = <(int-value)>;
+       };
+
+       (generic-name):   an open firmware-style name that describes the
+                       generic class of device.  Preferably, this is one word, such
+                       as 'serial' or 'ethernet'.
+       (ip-core-name): the name of the ip block (given after the BEGIN
+                       directive in system.mhs).  Should be in lowercase
+                       and all underscores '_' converted to dashes '-'.
+       (name):         is derived from the "PARAMETER INSTANCE" value.
+       (parameter#):   C_* parameters from system.mhs.  The C_ prefix is
+                       dropped from the parameter name, the name is converted
+                       to lowercase and all underscore '_' characters are
+                       converted to dashes '-'.
+       (baseaddr):     the baseaddr parameter value (often named C_BASEADDR).
+       (HW_VER):       from the HW_VER parameter.
+       (size):         the address range size (often C_HIGHADDR - C_BASEADDR + 1).
+
+   Typically, the compatible list will include the exact IP core version
+   followed by an older IP core version which implements the same
+   interface or any other device with the same interface.
+
+   'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
+
+   For example, the following block from system.mhs:
+
+       BEGIN opb_uartlite
+               PARAMETER INSTANCE = opb_uartlite_0
+               PARAMETER HW_VER = 1.00.b
+               PARAMETER C_BAUDRATE = 115200
+               PARAMETER C_DATA_BITS = 8
+               PARAMETER C_ODD_PARITY = 0
+               PARAMETER C_USE_PARITY = 0
+               PARAMETER C_CLK_FREQ = 50000000
+               PARAMETER C_BASEADDR = 0xEC100000
+               PARAMETER C_HIGHADDR = 0xEC10FFFF
+               BUS_INTERFACE SOPB = opb_7
+               PORT OPB_Clk = CLK_50MHz
+               PORT Interrupt = opb_uartlite_0_Interrupt
+               PORT RX = opb_uartlite_0_RX
+               PORT TX = opb_uartlite_0_TX
+               PORT OPB_Rst = sys_bus_reset_0
+       END
+
+   becomes the following device tree node:
+
+       opb_uartlite_0: serial@ec100000 {
+               device_type = "serial";
+               compatible = "xlnx,opb-uartlite-1.00.b";
+               reg = <ec100000 10000>;
+               interrupt-parent = <&opb_intc_0>;
+               interrupts = <1 0>; // got this from the opb_intc parameters
+               current-speed = <d#115200>;     // standard serial device prop
+               clock-frequency = <d#50000000>; // standard serial device prop
+               xlnx,data-bits = <8>;
+               xlnx,odd-parity = <0>;
+               xlnx,use-parity = <0>;
+       };
+
+   Some IP cores actually implement 2 or more logical devices.  In
+   this case, the device should still describe the whole IP core with
+   a single node and add a child node for each logical device.  The
+   ranges property can be used to translate from parent IP-core to the
+   registers of each device.  In addition, the parent node should be
+   compatible with the bus type 'xlnx,compound', and should contain
+   #address-cells and #size-cells, as with any other bus.  (Note: this
+   makes the assumption that both logical devices have the same bus
+   binding.  If this is not true, then separate nodes should be used
+   for each logical device).  The 'cell-index' property can be used to
+   enumerate logical devices within an IP core.  For example, the
+   following is the system.mhs entry for the dual ps2 controller found
+   on the ml403 reference design.
+
+       BEGIN opb_ps2_dual_ref
+               PARAMETER INSTANCE = opb_ps2_dual_ref_0
+               PARAMETER HW_VER = 1.00.a
+               PARAMETER C_BASEADDR = 0xA9000000
+               PARAMETER C_HIGHADDR = 0xA9001FFF
+               BUS_INTERFACE SOPB = opb_v20_0
+               PORT Sys_Intr1 = ps2_1_intr
+               PORT Sys_Intr2 = ps2_2_intr
+               PORT Clkin1 = ps2_clk_rx_1
+               PORT Clkin2 = ps2_clk_rx_2
+               PORT Clkpd1 = ps2_clk_tx_1
+               PORT Clkpd2 = ps2_clk_tx_2
+               PORT Rx1 = ps2_d_rx_1
+               PORT Rx2 = ps2_d_rx_2
+               PORT Txpd1 = ps2_d_tx_1
+               PORT Txpd2 = ps2_d_tx_2
+       END
+
+   It would result in the following device tree nodes:
+
+       opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               compatible = "xlnx,compound";
+               ranges = <0 a9000000 2000>;
+               // If this device had extra parameters, then they would
+               // go here.
+               ps2@0 {
+                       compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+                       reg = <0 40>;
+                       interrupt-parent = <&opb_intc_0>;
+                       interrupts = <3 0>;
+                       cell-index = <0>;
+               };
+               ps2@1000 {
+                       compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+                       reg = <1000 40>;
+                       interrupt-parent = <&opb_intc_0>;
+                       interrupts = <3 0>;
+                       cell-index = <0>;
+               };
+       };
+
+   Also, the system.mhs file defines bus attachments from the processor
+   to the devices.  The device tree structure should reflect the bus
+   attachments.  Again an example; this system.mhs fragment:
+
+       BEGIN ppc405_virtex4
+               PARAMETER INSTANCE = ppc405_0
+               PARAMETER HW_VER = 1.01.a
+               BUS_INTERFACE DPLB = plb_v34_0
+               BUS_INTERFACE IPLB = plb_v34_0
+       END
+
+       BEGIN opb_intc
+               PARAMETER INSTANCE = opb_intc_0
+               PARAMETER HW_VER = 1.00.c
+               PARAMETER C_BASEADDR = 0xD1000FC0
+               PARAMETER C_HIGHADDR = 0xD1000FDF
+               BUS_INTERFACE SOPB = opb_v20_0
+       END
+
+       BEGIN opb_uart16550
+               PARAMETER INSTANCE = opb_uart16550_0
+               PARAMETER HW_VER = 1.00.d
+               PARAMETER C_BASEADDR = 0xa0000000
+               PARAMETER C_HIGHADDR = 0xa0001FFF
+               BUS_INTERFACE SOPB = opb_v20_0
+       END
+
+       BEGIN plb_v34
+               PARAMETER INSTANCE = plb_v34_0
+               PARAMETER HW_VER = 1.02.a
+       END
+
+       BEGIN plb_bram_if_cntlr
+               PARAMETER INSTANCE = plb_bram_if_cntlr_0
+               PARAMETER HW_VER = 1.00.b
+               PARAMETER C_BASEADDR = 0xFFFF0000
+               PARAMETER C_HIGHADDR = 0xFFFFFFFF
+               BUS_INTERFACE SPLB = plb_v34_0
+       END
+
+       BEGIN plb2opb_bridge
+               PARAMETER INSTANCE = plb2opb_bridge_0
+               PARAMETER HW_VER = 1.01.a
+               PARAMETER C_RNG0_BASEADDR = 0x20000000
+               PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
+               PARAMETER C_RNG1_BASEADDR = 0x60000000
+               PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
+               PARAMETER C_RNG2_BASEADDR = 0x80000000
+               PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
+               PARAMETER C_RNG3_BASEADDR = 0xC0000000
+               PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
+               BUS_INTERFACE SPLB = plb_v34_0
+               BUS_INTERFACE MOPB = opb_v20_0
+       END
+
+   Gives this device tree (some properties removed for clarity):
+
+       plb@0 {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               compatible = "xlnx,plb-v34-1.02.a";
+               device_type = "ibm,plb";
+               ranges; // 1:1 translation
+
+               plb_bram_if_cntrl_0: bram@ffff0000 {
+                       reg = <ffff0000 10000>;
+               }
+
+               opb@20000000 {
+                       #address-cells = <1>;
+                       #size-cells = <1>;
+                       ranges = <20000000 20000000 20000000
+                                 60000000 60000000 20000000
+                                 80000000 80000000 40000000
+                                 c0000000 c0000000 20000000>;
+
+                       opb_uart16550_0: serial@a0000000 {
+                               reg = <a00000000 2000>;
+                       };
+
+                       opb_intc_0: interrupt-controller@d1000fc0 {
+                               reg = <d1000fc0 20>;
+                       };
+               };
+       };
+
+   That covers the general approach to binding xilinx IP cores into the
+   device tree.  The following are bindings for specific devices:
+
+      i) Xilinx ML300 Framebuffer
+
+      Simple framebuffer device from the ML300 reference design (also on the
+      ML403 reference design as well as others).
+
+      Optional properties:
+       - resolution = <xres yres> : pixel resolution of framebuffer.  Some
+                                    implementations use a different resolution.
+                                    Default is <d#640 d#480>
+       - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
+                                           Default is <d#1024 d#480>.
+       - rotate-display (empty) : rotate display 180 degrees.
+
+      ii) Xilinx SystemACE
+
+      The Xilinx SystemACE device is used to program FPGAs from an FPGA
+      bitstream stored on a CF card.  It can also be used as a generic CF
+      interface device.
+
+      Optional properties:
+       - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
+
+      iii) Xilinx EMAC and Xilinx TEMAC
+
+      Xilinx Ethernet devices.  In addition to general xilinx properties
+      listed above, nodes for these devices should include a phy-handle
+      property, and may include other common network device properties
+      like local-mac-address.
+      
+      iv) Xilinx Uartlite
+
+      Xilinx uartlite devices are simple fixed speed serial ports.
+
+      Requred properties:
+       - current-speed : Baud rate of uartlite
+
+      v) Xilinx hwicap
+
+               Xilinx hwicap devices provide access to the configuration logic
+               of the FPGA through the Internal Configuration Access Port
+               (ICAP).  The ICAP enables partial reconfiguration of the FPGA,
+               readback of the configuration information, and some control over
+               'warm boots' of the FPGA fabric.
+
+               Required properties:
+               - xlnx,family : The family of the FPGA, necessary since the
+                      capabilities of the underlying ICAP hardware
+                      differ between different families.  May be
+                      'virtex2p', 'virtex4', or 'virtex5'.
+
+    p) Freescale Synchronous Serial Interface
+
+       The SSI is a serial device that communicates with audio codecs.  It can
+       be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+       Required properties:
+       - compatible      : compatible list, containing "fsl,ssi"
+       - cell-index      : the SSI, <0> = SSI1, <1> = SSI2, and so on
+       - reg             : offset and length of the register set for the device
+       - interrupts      : <a b> where a is the interrupt number and b is a
+                            field that represents an encoding of the sense and
+                           level information for the interrupt.  This should be
+                           encoded based on the information in section 2)
+                           depending on the type of interrupt controller you
+                           have.
+       - interrupt-parent : the phandle for the interrupt controller that
+                            services interrupts for this device.
+       - fsl,mode        : the operating mode for the SSI interface
+                           "i2s-slave" - I2S mode, SSI is clock slave
+                           "i2s-master" - I2S mode, SSI is clock master
+                           "lj-slave" - left-justified mode, SSI is clock slave
+                           "lj-master" - l.j. mode, SSI is clock master
+                           "rj-slave" - right-justified mode, SSI is clock slave
+                           "rj-master" - r.j., SSI is clock master
+                           "ac97-slave" - AC97 mode, SSI is clock slave
+                           "ac97-master" - AC97 mode, SSI is clock master
+
+       Optional properties:
+       - codec-handle    : phandle to a 'codec' node that defines an audio
+                           codec connected to this SSI.  This node is typically
+                           a child of an I2C or other control node.
+
+       Child 'codec' node required properties:
+       - compatible      : compatible list, contains the name of the codec
+
+       Child 'codec' node optional properties:
+       - clock-frequency  : The frequency of the input clock, which typically
+                            comes from an on-board dedicated oscillator.
+
+    * Freescale 83xx DMA Controller
+
+    Freescale PowerPC 83xx have on chip general purpose DMA controllers.
+
+    Required properties:
+
+    - compatible        : compatible list, contains 2 entries, first is
+                        "fsl,CHIP-dma", where CHIP is the processor
+                        (mpc8349, mpc8360, etc.) and the second is
+                        "fsl,elo-dma"
+    - reg               : <registers mapping for DMA general status reg>
+    - ranges           : Should be defined as specified in 1) to describe the
+                         DMA controller channels.
+    - cell-index        : controller index.  0 for controller @ 0x8100
+    - interrupts        : <interrupt mapping for DMA IRQ>
+    - interrupt-parent  : optional, if needed for interrupt mapping
+
+
+    - DMA channel nodes:
+           - compatible        : compatible list, contains 2 entries, first is
+                                "fsl,CHIP-dma-channel", where CHIP is the processor
+                                (mpc8349, mpc8350, etc.) and the second is
+                                "fsl,elo-dma-channel"
+           - reg               : <registers mapping for channel>
+           - cell-index        : dma channel index starts at 0.
+
+    Optional properties:
+           - interrupts        : <interrupt mapping for DMA channel IRQ>
+                                 (on 83xx this is expected to be identical to
+                                  the interrupts property of the parent node)
+           - interrupt-parent  : optional, if needed for interrupt mapping
+
+  Example:
+       dma@82a8 {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
+               reg = <82a8 4>;
+               ranges = <0 8100 1a4>;
+               interrupt-parent = <&ipic>;
+               interrupts = <47 8>;
+               cell-index = <0>;
+               dma-channel@0 {
+                       compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+                       cell-index = <0>;
+                       reg = <0 80>;
+               };
+               dma-channel@80 {
+                       compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+                       cell-index = <1>;
+                       reg = <80 80>;
+               };
+               dma-channel@100 {
+                       compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+                       cell-index = <2>;
+                       reg = <100 80>;
+               };
+               dma-channel@180 {
+                       compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+                       cell-index = <3>;
+                       reg = <180 80>;
+               };
+       };
+
+   * Freescale 85xx/86xx DMA Controller
+
+    Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
+
+    Required properties:
+
+    - compatible        : compatible list, contains 2 entries, first is
+                        "fsl,CHIP-dma", where CHIP is the processor
+                        (mpc8540, mpc8540, etc.) and the second is
+                        "fsl,eloplus-dma"
+    - reg               : <registers mapping for DMA general status reg>
+    - cell-index        : controller index.  0 for controller @ 0x21000,
+                                             1 for controller @ 0xc000
+    - ranges           : Should be defined as specified in 1) to describe the
+                         DMA controller channels.
+
+    - DMA channel nodes:
+           - compatible        : compatible list, contains 2 entries, first is
+                                "fsl,CHIP-dma-channel", where CHIP is the processor
+                                (mpc8540, mpc8560, etc.) and the second is
+                                "fsl,eloplus-dma-channel"
+           - cell-index        : dma channel index starts at 0.
+           - reg               : <registers mapping for channel>
+           - interrupts        : <interrupt mapping for DMA channel IRQ>
+           - interrupt-parent  : optional, if needed for interrupt mapping
+
+  Example:
+       dma@21300 {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
+               reg = <21300 4>;
+               ranges = <0 21100 200>;
+               cell-index = <0>;
+               dma-channel@0 {
+                       compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+                       reg = <0 80>;
+                       cell-index = <0>;
+                       interrupt-parent = <&mpic>;
+                       interrupts = <14 2>;
+               };
+               dma-channel@80 {
+                       compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+                       reg = <80 80>;
+                       cell-index = <1>;
+                       interrupt-parent = <&mpic>;
+                       interrupts = <15 2>;
+               };
+               dma-channel@100 {
+                       compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+                       reg = <100 80>;
+                       cell-index = <2>;
+                       interrupt-parent = <&mpic>;
+                       interrupts = <16 2>;
+               };
+               dma-channel@180 {
+                       compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+                       reg = <180 80>;
+                       cell-index = <3>;
+                       interrupt-parent = <&mpic>;
+                       interrupts = <17 2>;
+               };
+       };
+
+    * Freescale 8xxx/3.0 Gb/s SATA nodes
+
+    SATA nodes are defined to describe on-chip Serial ATA controllers.
+    Each SATA port should have its own node.
+
+    Required properties:
+    - compatible        : compatible list, contains 2 entries, first is
+                        "fsl,CHIP-sata", where CHIP is the processor
+                        (mpc8315, mpc8379, etc.) and the second is
+                        "fsl,pq-sata"
+    - interrupts        : <interrupt mapping for SATA IRQ>
+    - cell-index        : controller index.
+                              1 for controller @ 0x18000
+                              2 for controller @ 0x19000
+                              3 for controller @ 0x1a000
+                              4 for controller @ 0x1b000
+
+    Optional properties:
+    - interrupt-parent  : optional, if needed for interrupt mapping
+    - reg               : <registers mapping>
+
+   Example:
+
+       sata@18000 {
+               compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
+               reg = <0x18000 0x1000>;
+               cell-index = <1>;
+               interrupts = <2c 8>;
+               interrupt-parent = < &ipic >;
+        };
+
    More devices will be defined as this spec matures.
 
 VII - Specifying interrupt information for devices