mvebu: backport mainline patches from kernel 3.12

This is a backport of the patches accepted to the Linux mainline related to
mvebu SoC (Armada XP and Armada 370) between Linux v3.11, and Linux v3.12.
This work mainly covers:

* Ground work for sharing the pxa nand driver(drivers/mtd/nand/pxa3xx_nand.c)
  between the PXA family,and the Armada family.
* Further updates to the mvebu MBus.
* Work and ground work for enabling MSI on the Armada family.
* some phy / mdio bus initialization related work.
* Device tree binding documentation update.

Signed-off-by: Seif Mazareeb <seif.mazareeb@gmail.com>
CC: Luka Perkov <luka@openwrt.org>

SVN-Revision: 39565

1 files changed, 303 insertions, 0 deletions

diff --git a/target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch b/target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch
new file mode 100644
index 0000000000..34e3969683
--- /dev/null
+++ b/target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch
@@ -0,0 +1,303 @@
+From 442681ff6aca5e839fe41378ff919df1c340dc62 Mon Sep 17 00:00:00 2001
+From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+Date: Tue, 28 May 2013 07:58:31 -0300
+Subject: [PATCH 065/203] bus: mvebu-mbus: Add devicetree binding
+
+Introduce the devicetree binding for the mvebu MBus driver
+avaiable in the mvebu SoCs (Armada 370/XP, Kirkwood, Dove, ...).
+
+This binding provides an accurate model of the SoC address space,
+and allows to declare the address and size of the decoding windows the MBus
+needs to access the peripherals, together with the target ID and attribute
+for those windows.
+
+The binding is composed of two required nodes: one for the MBus bus
+and one for the MBus controller.
+
+Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+Tested-by: Andrew Lunn <andrew@lunn.ch>
+Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+---
+ .../devicetree/bindings/bus/mvebu-mbus.txt         | 276 +++++++++++++++++++++
+ 1 file changed, 276 insertions(+)
+ create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+
+--- /dev/null
++++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+@@ -0,0 +1,276 @@
++
++* Marvell MBus
++
++Required properties:
++
++- compatible:	 Should be set to one of the following:
++		 marvell,armada370-mbus
++		 marvell,armadaxp-mbus
++		 marvell,armada370-mbus
++		 marvell,armadaxp-mbus
++		 marvell,kirkwood-mbus
++		 marvell,dove-mbus
++		 marvell,orion5x-88f5281-mbus
++		 marvell,orion5x-88f5182-mbus
++		 marvell,orion5x-88f5181-mbus
++		 marvell,orion5x-88f6183-mbus
++		 marvell,mv78xx0-mbus
++
++- address-cells: Must be '2'. The first cell for the MBus ID encoding,
++                 the second cell for the address offset within the window.
++
++- size-cells:    Must be '1'.
++
++- ranges:        Must be set up to provide a proper translation for each child.
++	         See the examples below.
++
++- controller:    Contains a single phandle referring to the MBus controller
++                 node. This allows to specify the node that contains the
++		 registers that control the MBus, which is typically contained
++		 within the internal register window (see below).
++
++Optional properties:
++
++- pcie-mem-aperture:	This optional property contains the aperture for
++			the memory region of the PCIe driver.
++			If it's defined, it must encode the base address and
++			size for the address decoding windows allocated for
++			the PCIe memory region.
++
++- pcie-io-aperture:	Just as explained for the above property, this
++			optional property contains the aperture for the
++			I/O region of the PCIe driver.
++
++* Marvell MBus controller
++
++Required properties:
++
++- compatible:	Should be set to "marvell,mbus-controller".
++
++- reg:          Device's register space.
++		Two entries are expected (see the examples below):
++		the first one controls the devices decoding window and
++		the second one controls the SDRAM decoding window.
++
++Example:
++
++	soc {
++		compatible = "marvell,armada370-mbus", "simple-bus";
++		#address-cells = <2>;
++		#size-cells = <1>;
++		controller = <&mbusc>;
++		pcie-mem-aperture = <0xe0000000 0x8000000>;
++		pcie-io-aperture  = <0xe8000000 0x100000>;
++
++		internal-regs {
++			compatible = "simple-bus";
++
++			mbusc: mbus-controller@20000 {
++				compatible = "marvell,mbus-controller";
++				reg = <0x20000 0x100>, <0x20180 0x20>;
++			};
++
++			/* more children ...*/
++		};
++	};
++
++** MBus address decoding window specification
++
++The MBus children address space is comprised of two cells: the first one for
++the window ID and the second one for the offset within the window.
++In order to allow to describe valid and non-valid window entries, the
++following encoding is used:
++
++  0xSIAA0000 0x00oooooo
++
++Where:
++
++  S = 0x0 for a MBus valid window
++  S = 0xf for a non-valid window (see below)
++
++If S = 0x0, then:
++
++   I = 4-bit window target ID
++  AA = windpw attribute
++
++If S = 0xf, then:
++
++   I = don't care
++   AA = 1 for internal register
++
++Following the above encoding, for each ranges entry for a MBus valid window
++(S = 0x0), an address decoding window is allocated. On the other side,
++entries for translation that do not correspond to valid windows (S = 0xf)
++are skipped.
++
++	soc {
++		compatible = "marvell,armada370-mbus", "simple-bus";
++		#address-cells = <2>;
++		#size-cells = <1>;
++		controller = <&mbusc>;
++
++		ranges = <0xf0010000 0 0 0xd0000000 0x100000
++			  0x01e00000 0 0 0xfff00000 0x100000>;
++
++		bootrom {
++			compatible = "marvell,bootrom";
++			reg = <0x01e00000 0 0x100000>;
++		};
++
++		/* other children */
++		...
++
++		internal-regs {
++			compatible = "simple-bus";
++			ranges = <0 0xf0010000 0 0x100000>;
++
++			mbusc: mbus-controller@20000 {
++				compatible = "marvell,mbus-controller";
++				reg = <0x20000 0x100>, <0x20180 0x20>;
++			};
++
++			/* more children ...*/
++		};
++	};
++
++In the shown example, the translation entry in the 'ranges' property is what
++makes the MBus driver create a static decoding window for the corresponding
++given child device. Note that the binding does not require child nodes to be
++present. Of course, child nodes are needed to probe the devices.
++
++Since each window is identified by its target ID and attribute ID there's
++a special macro that can be use to simplify the translation entries:
++
++#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
++
++Using this macro, the above example would be:
++
++	soc {
++		compatible = "marvell,armada370-mbus", "simple-bus";
++		#address-cells = <2>;
++		#size-cells = <1>;
++		controller = <&mbusc>;
++
++		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
++			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
++
++		bootrom {
++			compatible = "marvell,bootrom";
++			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
++		};
++
++		/* other children */
++		...
++
++		internal-regs {
++			compatible = "simple-bus";
++			#address-cells = <1>;
++			#size-cells = <1>;
++			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
++
++			mbusc: mbus-controller@20000 {
++				compatible = "marvell,mbus-controller";
++				reg = <0x20000 0x100>, <0x20180 0x20>;
++			};
++
++			/* other children */
++			...
++		};
++	};
++
++
++** About the window base address
++
++Remember the MBus controller allows a great deal of flexibility for choosing
++the decoding window base address. When planning the device tree layout it's
++possible to choose any address as the base address, provided of course there's
++a region large enough available, and with the required alignment.
++
++Yet in other words: there's nothing preventing us from setting a base address
++of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
++unused.
++
++** Window allocation policy
++
++The mbus-node ranges property defines a set of mbus windows that are expected
++to be set by the operating system and that are guaranteed to be free of overlaps
++with one another or with the system memory ranges.
++
++Each entry in the property refers to exactly one window. If the operating system
++choses to use a different set of mbus windows, it must ensure that any address
++translations performed from downstream devices are adapted accordingly.
++
++The operating system may insert additional mbus windows that do not conflict
++with the ones listed in the ranges, e.g. for mapping PCIe devices.
++As a special case, the internal register window must be set up by the boot
++loader at the address listed in the ranges property, since access to that region
++is needed to set up the other windows.
++
++** Example
++
++See the example below, where a more complete device tree is shown:
++
++	soc {
++		compatible = "marvell,armadaxp-mbus", "simple-bus";
++		controller = <&mbusc>;
++
++		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
++			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
++			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
++
++		bootrom {
++			compatible = "marvell,bootrom";
++			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
++		};
++
++		devbus-bootcs {
++			status = "okay";
++			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
++
++			/* NOR */
++			nor {
++				compatible = "cfi-flash";
++				reg = <0 0x8000000>;
++				bank-width = <2>;
++			};
++		};
++
++		pcie-controller {
++			compatible = "marvell,armada-xp-pcie";
++			status = "okay";
++			device_type = "pci";
++
++			#address-cells = <3>;
++			#size-cells = <2>;
++
++			ranges =
++			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
++				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
++				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
++				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
++				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
++				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
++				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
++
++
++			pcie@1,0 {
++				/* Port 0, Lane 0 */
++				status = "okay";
++			};
++		};
++
++		internal-regs {
++			compatible = "simple-bus";
++			#address-cells = <1>;
++			#size-cells = <1>;
++			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
++
++			mbusc: mbus-controller@20000 {
++				reg = <0x20000 0x100>, <0x20180 0x20>;
++			};
++
++			interrupt-controller@20000 {
++			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
++			};
++		};
++	};