Merge commit 'kumar/next' into merge

1 files changed, 2 insertions, 1166 deletions

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 8d999d862d0e..79f533f38c61 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1238,1122 +1238,7 @@ descriptions for the SOC devices for which new nodes have been
 defined; this list will expand as more and more SOC-containing
 platforms are moved over to use the flattened-device-tree model.
 
-   a) PHY nodes
-
-   Required properties:
-
-    - device_type : Should be "ethernet-phy"
-    - 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.
-    - reg : The ID number for the phy, usually a small integer
-    - linux,phandle :  phandle for this node; likely referenced by an
-      ethernet controller node.
-
-
-   Example:
-
-        ethernet-phy@0 {
-                linux,phandle = <2452000>
-                interrupt-parent = <40000>;
-                interrupts = <35 1>;
-                reg = <0>;
-                device_type = "ethernet-phy";
-        };
-
-
-   b) Interrupt controllers
-
-   Some SOC devices contain interrupt controllers that are different
-   from the standard Open PIC specification.  The SOC device nodes for
-   these types of controllers should be specified just like a standard
-   OpenPIC controller.  Sense and level information should be encoded
-   as specified in section 2) of this chapter for each device that
-   specifies an interrupt.
-
-   Example :
-
-        pic@40000 {
-                linux,phandle = <40000>;
-                interrupt-controller;
-                #address-cells = <0>;
-                reg = <40000 40000>;
-                compatible = "chrp,open-pic";
-                device_type = "open-pic";
-        };
-
-    c) 4xx/Axon EMAC ethernet nodes
-
-    The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
-    the Axon bridge.  To operate this needs to interact with a ths
-    special McMAL DMA controller, and sometimes an RGMII or ZMII
-    interface.  In addition to the nodes and properties described
-    below, the node for the OPB bus on which the EMAC sits must have a
-    correct clock-frequency property.
-
-      i) The EMAC node itself
-
-    Required properties:
-    - device_type       : "network"
-
-    - compatible        : compatible list, contains 2 entries, first is
-                          "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
-                          405gp, Axon) and second is either "ibm,emac" or
-                          "ibm,emac4".  For Axon, thus, we have: "ibm,emac-axon",
-                          "ibm,emac4"
-    - interrupts        : <interrupt mapping for EMAC IRQ and WOL IRQ>
-    - interrupt-parent  : optional, if needed for interrupt mapping
-    - reg               : <registers mapping>
-    - local-mac-address : 6 bytes, MAC address
-    - mal-device        : phandle of the associated McMAL node
-    - mal-tx-channel    : 1 cell, index of the tx channel on McMAL associated
-                          with this EMAC
-    - mal-rx-channel    : 1 cell, index of the rx channel on McMAL associated
-                          with this EMAC
-    - cell-index        : 1 cell, hardware index of the EMAC cell on a given
-                          ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
-                          each Axon chip)
-    - max-frame-size    : 1 cell, maximum frame size supported in bytes
-    - rx-fifo-size      : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
-                          operations.
-                          For Axon, 2048
-    - tx-fifo-size      : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
-                          operations.
-                          For Axon, 2048.
-    - fifo-entry-size   : 1 cell, size of a fifo entry (used to calculate
-                          thresholds).
-                          For Axon, 0x00000010
-    - mal-burst-size    : 1 cell, MAL burst size (used to calculate thresholds)
-                          in bytes.
-                          For Axon, 0x00000100 (I think ...)
-    - phy-mode          : string, mode of operations of the PHY interface.
-                          Supported values are: "mii", "rmii", "smii", "rgmii",
-                          "tbi", "gmii", rtbi", "sgmii".
-                          For Axon on CAB, it is "rgmii"
-    - mdio-device       : 1 cell, required iff using shared MDIO registers
-                          (440EP).  phandle of the EMAC to use to drive the
-                          MDIO lines for the PHY used by this EMAC.
-    - zmii-device       : 1 cell, required iff connected to a ZMII.  phandle of
-                          the ZMII device node
-    - zmii-channel      : 1 cell, required iff connected to a ZMII.  Which ZMII
-                          channel or 0xffffffff if ZMII is only used for MDIO.
-    - rgmii-device      : 1 cell, required iff connected to an RGMII. phandle
-                          of the RGMII device node.
-                          For Axon: phandle of plb5/plb4/opb/rgmii
-    - rgmii-channel     : 1 cell, required iff connected to an RGMII.  Which
-                          RGMII channel is used by this EMAC.
-                          Fox Axon: present, whatever value is appropriate for each
-                          EMAC, that is the content of the current (bogus) "phy-port"
-                          property.
-
-    Optional properties:
-    - phy-address       : 1 cell, optional, MDIO address of the PHY. If absent,
-                          a search is performed.
-    - phy-map           : 1 cell, optional, bitmap of addresses to probe the PHY
-                          for, used if phy-address is absent. bit 0x00000001 is
-                          MDIO address 0.
-                          For Axon it can be absent, though my current driver
-                          doesn't handle phy-address yet so for now, keep
-                          0x00ffffff in it.
-    - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
-                          operations (if absent the value is the same as
-                          rx-fifo-size).  For Axon, either absent or 2048.
-    - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
-                          operations (if absent the value is the same as
-                          tx-fifo-size). For Axon, either absent or 2048.
-    - tah-device        : 1 cell, optional. If connected to a TAH engine for
-                          offload, phandle of the TAH device node.
-    - tah-channel       : 1 cell, optional. If appropriate, channel used on the
-                          TAH engine.
-
-    Example:
-
-        EMAC0: ethernet@40000800 {
-                device_type = "network";
-                compatible = "ibm,emac-440gp", "ibm,emac";
-                interrupt-parent = <&UIC1>;
-                interrupts = <1c 4 1d 4>;
-                reg = <40000800 70>;
-                local-mac-address = [00 04 AC E3 1B 1E];
-                mal-device = <&MAL0>;
-                mal-tx-channel = <0 1>;
-                mal-rx-channel = <0>;
-                cell-index = <0>;
-                max-frame-size = <5dc>;
-                rx-fifo-size = <1000>;
-                tx-fifo-size = <800>;
-                phy-mode = "rmii";
-                phy-map = <00000001>;
-                zmii-device = <&ZMII0>;
-                zmii-channel = <0>;
-        };
-
-      ii) McMAL node
-
-    Required properties:
-    - device_type        : "dma-controller"
-    - compatible         : compatible list, containing 2 entries, first is
-                           "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
-                           emac) and the second is either "ibm,mcmal" or
-                           "ibm,mcmal2".
-                           For Axon, "ibm,mcmal-axon","ibm,mcmal2"
-    - interrupts         : <interrupt mapping for the MAL interrupts sources:
-                           5 sources: tx_eob, rx_eob, serr, txde, rxde>.
-                           For Axon: This is _different_ from the current
-                           firmware.  We use the "delayed" interrupts for txeob
-                           and rxeob. Thus we end up with mapping those 5 MPIC
-                           interrupts, all level positive sensitive: 10, 11, 32,
-                           33, 34 (in decimal)
-    - dcr-reg            : < DCR registers range >
-    - dcr-parent         : if needed for dcr-reg
-    - num-tx-chans       : 1 cell, number of Tx channels
-    - num-rx-chans       : 1 cell, number of Rx channels
-
-      iii) ZMII node
-
-    Required properties:
-    - compatible         : compatible list, containing 2 entries, first is
-                           "ibm,zmii-CHIP" where CHIP is the host ASIC (like
-                           EMAC) and the second is "ibm,zmii".
-                           For Axon, there is no ZMII node.
-    - reg                : <registers mapping>
-
-      iv) RGMII node
-
-    Required properties:
-    - compatible         : compatible list, containing 2 entries, first is
-                           "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
-                           EMAC) and the second is "ibm,rgmii".
-                           For Axon, "ibm,rgmii-axon","ibm,rgmii"
-    - reg                : <registers mapping>
-    - revision           : as provided by the RGMII new version register if
-                           available.
-                           For Axon: 0x0000012a
-
-   d) 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 miscellaneous
-   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.
-
-      Required 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'.
-
-      vi) Xilinx Uart 16550
-
-      Xilinx UART 16550 devices are very similar to the NS16550 but with
-      different register spacing and an offset from the base address.
-
-      Required properties:
-       - clock-frequency : Frequency of the clock input
-       - reg-offset : A value of 3 is required
-       - reg-shift : A value of 2 is required
-
-    e) USB EHCI controllers
-
-    Required properties:
-      - compatible : should be "usb-ehci".
-      - reg : should contain at least address and length of the standard EHCI
-        register set for the device. Optional platform-dependent registers
-        (debug-port or other) can be also specified here, but only after
-        definition of standard EHCI registers.
-      - interrupts : one EHCI interrupt should be described here.
-    If device registers are implemented in big endian mode, the device
-    node should have "big-endian-regs" property.
-    If controller implementation operates with big endian descriptors,
-    "big-endian-desc" property should be specified.
-    If both big endian registers and descriptors are used by the controller
-    implementation, "big-endian" property can be specified instead of having
-    both "big-endian-regs" and "big-endian-desc".
-
-     Example (Sequoia 440EPx):
-            ehci@e0000300 {
-                   compatible = "ibm,usb-ehci-440epx", "usb-ehci";
-                   interrupt-parent = <&UIC0>;
-                   interrupts = <1a 4>;
-                   reg = <0 e0000300 90 0 e0000390 70>;
-                   big-endian;
-           };
-
-   f) MDIO on GPIOs
-
-   Currently defined compatibles:
-   - virtual,gpio-mdio
-
-   MDC and MDIO lines connected to GPIO controllers are listed in the
-   gpios property as described in section VIII.1 in the following order:
-
-   MDC, MDIO.
-
-   Example:
-
-        mdio {
-                compatible = "virtual,mdio-gpio";
-                #address-cells = <1>;
-                #size-cells = <0>;
-                gpios = <&qe_pio_a 11
-                         &qe_pio_c 6>;
-        };
-
-    g) SPI (Serial Peripheral Interface) busses
-
-    SPI busses can be described with a node for the SPI master device
-    and a set of child nodes for each SPI slave on the bus.  For this
-    discussion, it is assumed that the system's SPI controller is in
-    SPI master mode.  This binding does not describe SPI controllers
-    in slave mode.
-
-    The SPI master node requires the following properties:
-    - #address-cells  - number of cells required to define a chip select
-                        address on the SPI bus.
-    - #size-cells     - should be zero.
-    - compatible      - name of SPI bus controller following generic names
-                        recommended practice.
-    No other properties are required in the SPI bus node.  It is assumed
-    that a driver for an SPI bus device will understand that it is an SPI bus.
-    However, the binding does not attempt to define the specific method for
-    assigning chip select numbers.  Since SPI chip select configuration is
-    flexible and non-standardized, it is left out of this binding with the
-    assumption that board specific platform code will be used to manage
-    chip selects.  Individual drivers can define additional properties to
-    support describing the chip select layout.
-
-    SPI slave nodes must be children of the SPI master node and can
-    contain the following properties.
-    - reg             - (required) chip select address of device.
-    - compatible      - (required) name of SPI device following generic names
-                        recommended practice
-    - spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
-    - spi-cpol        - (optional) Empty property indicating device requires
-                        inverse clock polarity (CPOL) mode
-    - spi-cpha        - (optional) Empty property indicating device requires
-                        shifted clock phase (CPHA) mode
-    - spi-cs-high     - (optional) Empty property indicating device requires
-                        chip select active high
-
-    SPI example for an MPC5200 SPI bus:
-                spi@f00 {
-                        #address-cells = <1>;
-                        #size-cells = <0>;
-                        compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
-                        reg = <0xf00 0x20>;
-                        interrupts = <2 13 0 2 14 0>;
-                        interrupt-parent = <&mpc5200_pic>;
-
-                        ethernet-switch@0 {
-                                compatible = "micrel,ks8995m";
-                                spi-max-frequency = <1000000>;
-                                reg = <0>;
-                        };
-
-                        codec@1 {
-                                compatible = "ti,tlv320aic26";
-                                spi-max-frequency = <100000>;
-                                reg = <1>;
-                        };
-                };
-
-VII - Marvell Discovery mv64[345]6x System Controller chips
-===========================================================
-
-The Marvell mv64[345]60 series of system controller chips contain
-many of the peripherals needed to implement a complete computer
-system.  In this section, we define device tree nodes to describe
-the system controller chip itself and each of the peripherals
-which it contains.  Compatible string values for each node are
-prefixed with the string "marvell,", for Marvell Technology Group Ltd.
-
-1) The /system-controller node
-
-  This node is used to represent the system-controller and must be
-  present when the system uses a system controller chip. The top-level
-  system-controller node contains information that is global to all
-  devices within the system controller chip. The node name begins
-  with "system-controller" followed by the unit address, which is
-  the base address of the memory-mapped register set for the system
-  controller chip.
-
-  Required properties:
-
-    - ranges : Describes the translation of system controller addresses
-      for memory mapped registers.
-    - clock-frequency: Contains the main clock frequency for the system
-      controller chip.
-    - reg : This property defines the address and size of the
-      memory-mapped registers contained within the system controller
-      chip.  The address specified in the "reg" property should match
-      the unit address of the system-controller node.
-    - #address-cells : Address representation for system controller
-      devices.  This field represents the number of cells needed to
-      represent the address of the memory-mapped registers of devices
-      within the system controller chip.
-    - #size-cells : Size representation for for the memory-mapped
-      registers within the system controller chip.
-    - #interrupt-cells : Defines the width of cells used to represent
-      interrupts.
-
-  Optional properties:
-
-    - model : The specific model of the system controller chip.  Such
-      as, "mv64360", "mv64460", or "mv64560".
-    - compatible : A string identifying the compatibility identifiers
-      of the system controller chip.
-
-  The system-controller node contains child nodes for each system
-  controller device that the platform uses.  Nodes should not be created
-  for devices which exist on the system controller chip but are not used
-
-  Example Marvell Discovery mv64360 system-controller node:
-
-    system-controller@f1000000 { /* Marvell Discovery mv64360 */
-            #address-cells = <1>;
-            #size-cells = <1>;
-            model = "mv64360";                      /* Default */
-            compatible = "marvell,mv64360";
-            clock-frequency = <133333333>;
-            reg = <0xf1000000 0x10000>;
-            virtual-reg = <0xf1000000>;
-            ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
-                    0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
-                    0xa0000000 0xa0000000 0x4000000 /* User FLASH */
-                    0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
-                    0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
-
-            [ child node definitions... ]
-    }
-
-2) Child nodes of /system-controller
-
-   a) Marvell Discovery MDIO bus
-
-   The MDIO is a bus to which the PHY devices are connected.  For each
-   device that exists on this bus, a child node should be created.  See
-   the definition of the PHY node below for an example of how to define
-   a PHY.
-
-   Required properties:
-     - #address-cells : Should be <1>
-     - #size-cells : Should be <0>
-     - device_type : Should be "mdio"
-     - compatible : Should be "marvell,mv64360-mdio"
-
-   Example:
-
-     mdio {
-             #address-cells = <1>;
-             #size-cells = <0>;
-             device_type = "mdio";
-             compatible = "marvell,mv64360-mdio";
-
-             ethernet-phy@0 {
-                     ......
-             };
-     };
-
-
-   b) Marvell Discovery ethernet controller
-
-   The Discover ethernet controller is described with two levels
-   of nodes.  The first level describes an ethernet silicon block
-   and the second level describes up to 3 ethernet nodes within
-   that block.  The reason for the multiple levels is that the
-   registers for the node are interleaved within a single set
-   of registers.  The "ethernet-block" level describes the
-   shared register set, and the "ethernet" nodes describe ethernet
-   port-specific properties.
-
-   Ethernet block node
-
-   Required properties:
-     - #address-cells : <1>
-     - #size-cells : <0>
-     - compatible : "marvell,mv64360-eth-block"
-     - reg : Offset and length of the register set for this block
-
-   Example Discovery Ethernet block node:
-     ethernet-block@2000 {
-             #address-cells = <1>;
-             #size-cells = <0>;
-             compatible = "marvell,mv64360-eth-block";
-             reg = <0x2000 0x2000>;
-             ethernet@0 {
-                     .......
-             };
-     };
-
-   Ethernet port node
-
-   Required properties:
-     - device_type : Should be "network".
-     - compatible : Should be "marvell,mv64360-eth".
-     - reg : Should be <0>, <1>, or <2>, according to which registers
-       within the silicon block the device uses.
-     - interrupts : <a> where a is the interrupt number for the port.
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-     - phy : the phandle for the PHY connected to this ethernet
-       controller.
-     - local-mac-address : 6 bytes, MAC address
-
-   Example Discovery Ethernet port node:
-     ethernet@0 {
-             device_type = "network";
-             compatible = "marvell,mv64360-eth";
-             reg = <0>;
-             interrupts = <32>;
-             interrupt-parent = <&PIC>;
-             phy = <&PHY0>;
-             local-mac-address = [ 00 00 00 00 00 00 ];
-     };
-
-
-
-   c) Marvell Discovery PHY nodes
-
-   Required properties:
-     - device_type : Should be "ethernet-phy"
-     - interrupts : <a> where a is the interrupt number for this phy.
-     - interrupt-parent : the phandle for the interrupt controller that
-       services interrupts for this device.
-     - reg : The ID number for the phy, usually a small integer
-
-   Example Discovery PHY node:
-     ethernet-phy@1 {
-             device_type = "ethernet-phy";
-             compatible = "broadcom,bcm5421";
-             interrupts = <76>;      /* GPP 12 */
-             interrupt-parent = <&PIC>;
-             reg = <1>;
-     };
-
-
-   d) Marvell Discovery SDMA nodes
-
-   Represent DMA hardware associated with the MPSC (multiprotocol
-   serial controllers).
-
-   Required properties:
-     - compatible : "marvell,mv64360-sdma"
-     - reg : Offset and length of the register set for this device
-     - interrupts : <a> where a is the interrupt number for the DMA
-       device.
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery SDMA node:
-     sdma@4000 {
-             compatible = "marvell,mv64360-sdma";
-             reg = <0x4000 0xc18>;
-             virtual-reg = <0xf1004000>;
-             interrupts = <36>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   e) Marvell Discovery BRG nodes
-
-   Represent baud rate generator hardware associated with the MPSC
-   (multiprotocol serial controllers).
-
-   Required properties:
-     - compatible : "marvell,mv64360-brg"
-     - reg : Offset and length of the register set for this device
-     - clock-src : A value from 0 to 15 which selects the clock
-       source for the baud rate generator.  This value corresponds
-       to the CLKS value in the BRGx configuration register.  See
-       the mv64x60 User's Manual.
-     - clock-frequence : The frequency (in Hz) of the baud rate
-       generator's input clock.
-     - current-speed : The current speed setting (presumably by
-       firmware) of the baud rate generator.
-
-   Example Discovery BRG node:
-     brg@b200 {
-             compatible = "marvell,mv64360-brg";
-             reg = <0xb200 0x8>;
-             clock-src = <8>;
-             clock-frequency = <133333333>;
-             current-speed = <9600>;
-     };
-
-
-   f) Marvell Discovery CUNIT nodes
-
-   Represent the Serial Communications Unit device hardware.
-
-   Required properties:
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery CUNIT node:
-     cunit@f200 {
-             reg = <0xf200 0x200>;
-     };
-
-
-   g) Marvell Discovery MPSCROUTING nodes
-
-   Represent the Discovery's MPSC routing hardware
-
-   Required properties:
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery CUNIT node:
-     mpscrouting@b500 {
-             reg = <0xb400 0xc>;
-     };
-
-
-   h) Marvell Discovery MPSCINTR nodes
-
-   Represent the Discovery's MPSC DMA interrupt hardware registers
-   (SDMA cause and mask registers).
-
-   Required properties:
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery MPSCINTR node:
-     mpsintr@b800 {
-             reg = <0xb800 0x100>;
-     };
-
-
-   i) Marvell Discovery MPSC nodes
-
-   Represent the Discovery's MPSC (Multiprotocol Serial Controller)
-   serial port.
-
-   Required properties:
-     - device_type : "serial"
-     - compatible : "marvell,mv64360-mpsc"
-     - reg : Offset and length of the register set for this device
-     - sdma : the phandle for the SDMA node used by this port
-     - brg : the phandle for the BRG node used by this port
-     - cunit : the phandle for the CUNIT node used by this port
-     - mpscrouting : the phandle for the MPSCROUTING node used by this port
-     - mpscintr : the phandle for the MPSCINTR node used by this port
-     - cell-index : the hardware index of this cell in the MPSC core
-     - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
-       register
-     - interrupts : <a> where a is the interrupt number for the MPSC.
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery MPSCINTR node:
-     mpsc@8000 {
-             device_type = "serial";
-             compatible = "marvell,mv64360-mpsc";
-             reg = <0x8000 0x38>;
-             virtual-reg = <0xf1008000>;
-             sdma = <&SDMA0>;
-             brg = <&BRG0>;
-             cunit = <&CUNIT>;
-             mpscrouting = <&MPSCROUTING>;
-             mpscintr = <&MPSCINTR>;
-             cell-index = <0>;
-             max_idle = <40>;
-             interrupts = <40>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   j) Marvell Discovery Watch Dog Timer nodes
-
-   Represent the Discovery's watchdog timer hardware
-
-   Required properties:
-     - compatible : "marvell,mv64360-wdt"
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery Watch Dog Timer node:
-     wdt@b410 {
-             compatible = "marvell,mv64360-wdt";
-             reg = <0xb410 0x8>;
-     };
-
-
-   k) Marvell Discovery I2C nodes
-
-   Represent the Discovery's I2C hardware
-
-   Required properties:
-     - device_type : "i2c"
-     - compatible : "marvell,mv64360-i2c"
-     - reg : Offset and length of the register set for this device
-     - interrupts : <a> where a is the interrupt number for the I2C.
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery I2C node:
-             compatible = "marvell,mv64360-i2c";
-             reg = <0xc000 0x20>;
-             virtual-reg = <0xf100c000>;
-             interrupts = <37>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
-
-   Represent the Discovery's PIC hardware
-
-   Required properties:
-     - #interrupt-cells : <1>
-     - #address-cells : <0>
-     - compatible : "marvell,mv64360-pic"
-     - reg : Offset and length of the register set for this device
-     - interrupt-controller
-
-   Example Discovery PIC node:
-     pic {
-             #interrupt-cells = <1>;
-             #address-cells = <0>;
-             compatible = "marvell,mv64360-pic";
-             reg = <0x0 0x88>;
-             interrupt-controller;
-     };
-
-
-   m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
-
-   Represent the Discovery's MPP hardware
-
-   Required properties:
-     - compatible : "marvell,mv64360-mpp"
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery MPP node:
-     mpp@f000 {
-             compatible = "marvell,mv64360-mpp";
-             reg = <0xf000 0x10>;
-     };
-
-
-   n) Marvell Discovery GPP (General Purpose Pins) nodes
-
-   Represent the Discovery's GPP hardware
-
-   Required properties:
-     - compatible : "marvell,mv64360-gpp"
-     - reg : Offset and length of the register set for this device
-
-   Example Discovery GPP node:
-     gpp@f000 {
-             compatible = "marvell,mv64360-gpp";
-             reg = <0xf100 0x20>;
-     };
-
-
-   o) Marvell Discovery PCI host bridge node
-
-   Represents the Discovery's PCI host bridge device.  The properties
-   for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
-   1275-1994.  A typical value for the compatible property is
-   "marvell,mv64360-pci".
-
-   Example Discovery PCI host bridge node
-     pci@80000000 {
-             #address-cells = <3>;
-             #size-cells = <2>;
-             #interrupt-cells = <1>;
-             device_type = "pci";
-             compatible = "marvell,mv64360-pci";
-             reg = <0xcf8 0x8>;
-             ranges = <0x01000000 0x0        0x0
-                             0x88000000 0x0 0x01000000
-                       0x02000000 0x0 0x80000000
-                             0x80000000 0x0 0x08000000>;
-             bus-range = <0 255>;
-             clock-frequency = <66000000>;
-             interrupt-parent = <&PIC>;
-             interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
-             interrupt-map = <
-                     /* IDSEL 0x0a */
-                     0x5000 0 0 1 &PIC 80
-                     0x5000 0 0 2 &PIC 81
-                     0x5000 0 0 3 &PIC 91
-                     0x5000 0 0 4 &PIC 93
-
-                     /* IDSEL 0x0b */
-                     0x5800 0 0 1 &PIC 91
-                     0x5800 0 0 2 &PIC 93
-                     0x5800 0 0 3 &PIC 80
-                     0x5800 0 0 4 &PIC 81
-
-                     /* IDSEL 0x0c */
-                     0x6000 0 0 1 &PIC 91
-                     0x6000 0 0 2 &PIC 93
-                     0x6000 0 0 3 &PIC 80
-                     0x6000 0 0 4 &PIC 81
-
-                     /* IDSEL 0x0d */
-                     0x6800 0 0 1 &PIC 93
-                     0x6800 0 0 2 &PIC 80
-                     0x6800 0 0 3 &PIC 81
-                     0x6800 0 0 4 &PIC 91
-             >;
-     };
-
-
-   p) Marvell Discovery CPU Error nodes
-
-   Represent the Discovery's CPU error handler device.
-
-   Required properties:
-     - compatible : "marvell,mv64360-cpu-error"
-     - reg : Offset and length of the register set for this device
-     - interrupts : the interrupt number for this device
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery CPU Error node:
-     cpu-error@0070 {
-             compatible = "marvell,mv64360-cpu-error";
-             reg = <0x70 0x10 0x128 0x28>;
-             interrupts = <3>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   q) Marvell Discovery SRAM Controller nodes
-
-   Represent the Discovery's SRAM controller device.
-
-   Required properties:
-     - compatible : "marvell,mv64360-sram-ctrl"
-     - reg : Offset and length of the register set for this device
-     - interrupts : the interrupt number for this device
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery SRAM Controller node:
-     sram-ctrl@0380 {
-             compatible = "marvell,mv64360-sram-ctrl";
-             reg = <0x380 0x80>;
-             interrupts = <13>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   r) Marvell Discovery PCI Error Handler nodes
-
-   Represent the Discovery's PCI error handler device.
-
-   Required properties:
-     - compatible : "marvell,mv64360-pci-error"
-     - reg : Offset and length of the register set for this device
-     - interrupts : the interrupt number for this device
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery PCI Error Handler node:
-     pci-error@1d40 {
-             compatible = "marvell,mv64360-pci-error";
-             reg = <0x1d40 0x40 0xc28 0x4>;
-             interrupts = <12>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-   s) Marvell Discovery Memory Controller nodes
-
-   Represent the Discovery's memory controller device.
-
-   Required properties:
-     - compatible : "marvell,mv64360-mem-ctrl"
-     - reg : Offset and length of the register set for this device
-     - interrupts : the interrupt number for this device
-     - interrupt-parent : the phandle for the interrupt controller
-       that services interrupts for this device.
-
-   Example Discovery Memory Controller node:
-     mem-ctrl@1400 {
-             compatible = "marvell,mv64360-mem-ctrl";
-             reg = <0x1400 0x60>;
-             interrupts = <17>;
-             interrupt-parent = <&PIC>;
-     };
-
-
-VIII - Specifying interrupt information for devices
+VII - Specifying interrupt information for devices
 ===================================================
 
 The device tree represents the busses and devices of a hardware
@@ -2439,56 +1324,7 @@ encodings listed below:
         2 =  high to low edge sensitive type enabled
         3 =  low to high edge sensitive type enabled
 
-IX - Specifying GPIO information for devices
-============================================
-
-1) gpios property
------------------
-
-Nodes that makes use of GPIOs should define them using `gpios' property,
-format of which is: <&gpio-controller1-phandle gpio1-specifier
-                     &gpio-controller2-phandle gpio2-specifier
-                     0 /* holes are permitted, means no GPIO 3 */
-                     &gpio-controller4-phandle gpio4-specifier
-                     ...>;
-
-Note that gpio-specifier length is controller dependent.
-
-gpio-specifier may encode: bank, pin position inside the bank,
-whether pin is open-drain and whether pin is logically inverted.
-
-Example of the node using GPIOs:
-
-        node {
-                gpios = <&qe_pio_e 18 0>;
-        };
-
-In this example gpio-specifier is "18 0" and encodes GPIO pin number,
-and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
-
-2) gpio-controller nodes
-------------------------
-
-Every GPIO controller node must have #gpio-cells property defined,
-this information will be used to translate gpio-specifiers.
-
-Example of two SOC GPIO banks defined as gpio-controller nodes:
-
-        qe_pio_a: gpio-controller@1400 {
-                #gpio-cells = <2>;
-                compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
-                reg = <0x1400 0x18>;
-                gpio-controller;
-        };
-
-        qe_pio_e: gpio-controller@1460 {
-                #gpio-cells = <2>;
-                compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
-                reg = <0x1460 0x18>;
-                gpio-controller;
-        };
-
-X - Specifying Device Power Management Information (sleep property)
+VIII - Specifying Device Power Management Information (sleep property)
 ===================================================================
 
 Devices on SOCs often have mechanisms for placing devices into low-power