[PATCH] powerpc: Refactor device tree binding
Grant Likely
grant.likely at secretlab.ca
Wed Jun 24 02:10:35 EST 2009
On Fri, Jun 19, 2009 at 9:36 AM, Kumar Gala<galak at kernel.crashing.org> wrote:
> Split device tree binding out of booting-without-of.txt and put them
> into their own files per binding.
>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
Acked-by: Grant Likely <grant.likely at secretlab.ca>
> ---
> Documentation/powerpc/booting-without-of.txt | 1168 +---------------------
> Documentation/powerpc/dts-bindings/4xx/emac.txt | 148 +++
> Documentation/powerpc/dts-bindings/gpio/gpio.txt | 50 +
> Documentation/powerpc/dts-bindings/gpio/mdio.txt | 19 +
> Documentation/powerpc/dts-bindings/marvell.txt | 521 ++++++++++
> Documentation/powerpc/dts-bindings/phy.txt | 25 +
> Documentation/powerpc/dts-bindings/spi-bus.txt | 57 ++
> Documentation/powerpc/dts-bindings/usb-ehci.txt | 25 +
> Documentation/powerpc/dts-bindings/xilinx.txt | 295 ++++++
> 9 files changed, 1142 insertions(+), 1166 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/4xx/emac.txt
> create mode 100644 Documentation/powerpc/dts-bindings/gpio/gpio.txt
> create mode 100644 Documentation/powerpc/dts-bindings/gpio/mdio.txt
> create mode 100644 Documentation/powerpc/dts-bindings/marvell.txt
> create mode 100644 Documentation/powerpc/dts-bindings/phy.txt
> create mode 100644 Documentation/powerpc/dts-bindings/spi-bus.txt
> create mode 100644 Documentation/powerpc/dts-bindings/usb-ehci.txt
> create mode 100644 Documentation/powerpc/dts-bindings/xilinx.txt
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 8d999d8..79f533f 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at ffff0000 {
> - reg = <ffff0000 10000>;
> - }
> -
> - opb at 20000000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <20000000 20000000 20000000
> - 60000000 60000000 20000000
> - 80000000 80000000 40000000
> - c0000000 c0000000 20000000>;
> -
> - opb_uart16550_0: serial at a0000000 {
> - reg = <a00000000 2000>;
> - };
> -
> - opb_intc_0: interrupt-controller at 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 at 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 at 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 at 0 {
> - compatible = "micrel,ks8995m";
> - spi-max-frequency = <1000000>;
> - reg = <0>;
> - };
> -
> - codec at 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 at 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 at 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 at 2000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "marvell,mv64360-eth-block";
> - reg = <0x2000 0x2000>;
> - ethernet at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 1400 {
> - #gpio-cells = <2>;
> - compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> - reg = <0x1400 0x18>;
> - gpio-controller;
> - };
> -
> - qe_pio_e: gpio-controller at 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
> diff --git a/Documentation/powerpc/dts-bindings/4xx/emac.txt b/Documentation/powerpc/dts-bindings/4xx/emac.txt
> new file mode 100644
> index 0000000..2161334
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/4xx/emac.txt
> @@ -0,0 +1,148 @@
> + 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 at 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
> +
> diff --git a/Documentation/powerpc/dts-bindings/gpio/gpio.txt b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
> new file mode 100644
> index 0000000..edaa84d
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
> @@ -0,0 +1,50 @@
> +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 at 1400 {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> + reg = <0x1400 0x18>;
> + gpio-controller;
> + };
> +
> + qe_pio_e: gpio-controller at 1460 {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> + reg = <0x1460 0x18>;
> + gpio-controller;
> + };
> +
> +
> diff --git a/Documentation/powerpc/dts-bindings/gpio/mdio.txt b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
> new file mode 100644
> index 0000000..bc95495
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
> @@ -0,0 +1,19 @@
> +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>;
> +};
> diff --git a/Documentation/powerpc/dts-bindings/marvell.txt b/Documentation/powerpc/dts-bindings/marvell.txt
> new file mode 100644
> index 0000000..3708a2f
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/marvell.txt
> @@ -0,0 +1,521 @@
> +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 at 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 at 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 at 2000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,mv64360-eth-block";
> + reg = <0x2000 0x2000>;
> + ethernet at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 1400 {
> + compatible = "marvell,mv64360-mem-ctrl";
> + reg = <0x1400 0x60>;
> + interrupts = <17>;
> + interrupt-parent = <&PIC>;
> + };
> +
> +
> diff --git a/Documentation/powerpc/dts-bindings/phy.txt b/Documentation/powerpc/dts-bindings/phy.txt
> new file mode 100644
> index 0000000..bb8c742
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/phy.txt
> @@ -0,0 +1,25 @@
> +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 at 0 {
> + linux,phandle = <2452000>
> + interrupt-parent = <40000>;
> + interrupts = <35 1>;
> + reg = <0>;
> + device_type = "ethernet-phy";
> +};
> diff --git a/Documentation/powerpc/dts-bindings/spi-bus.txt b/Documentation/powerpc/dts-bindings/spi-bus.txt
> new file mode 100644
> index 0000000..e782add
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/spi-bus.txt
> @@ -0,0 +1,57 @@
> +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 at 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 at 0 {
> + compatible = "micrel,ks8995m";
> + spi-max-frequency = <1000000>;
> + reg = <0>;
> + };
> +
> + codec at 1 {
> + compatible = "ti,tlv320aic26";
> + spi-max-frequency = <100000>;
> + reg = <1>;
> + };
> + };
> diff --git a/Documentation/powerpc/dts-bindings/usb-ehci.txt b/Documentation/powerpc/dts-bindings/usb-ehci.txt
> new file mode 100644
> index 0000000..fa18612
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/usb-ehci.txt
> @@ -0,0 +1,25 @@
> +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 at e0000300 {
> + compatible = "ibm,usb-ehci-440epx", "usb-ehci";
> + interrupt-parent = <&UIC0>;
> + interrupts = <1a 4>;
> + reg = <0 e0000300 90 0 e0000390 70>;
> + big-endian;
> + };
> diff --git a/Documentation/powerpc/dts-bindings/xilinx.txt b/Documentation/powerpc/dts-bindings/xilinx.txt
> new file mode 100644
> index 0000000..80339fe
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/xilinx.txt
> @@ -0,0 +1,295 @@
> + 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 at 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 at 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 at 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 at 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 at 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 at ffff0000 {
> + reg = <ffff0000 10000>;
> + }
> +
> + opb at 20000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <20000000 20000000 20000000
> + 60000000 60000000 20000000
> + 80000000 80000000 40000000
> + c0000000 c0000000 20000000>;
> +
> + opb_uart16550_0: serial at a0000000 {
> + reg = <a00000000 2000>;
> + };
> +
> + opb_intc_0: interrupt-controller at 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
> +
> +
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
More information about the Linuxppc-dev
mailing list