aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch
diff options
context:
space:
mode:
authorLuka Perkov <luka@openwrt.org>2014-02-11 02:07:41 +0000
committerLuka Perkov <luka@openwrt.org>2014-02-11 02:07:41 +0000
commit3af779eb172b0438f77e8a01a97dd0eb9a146076 (patch)
tree23838dbde109e79f4c4763dbf78a983aeeefafe1 /target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch
parent69d323f23119ce6986c2803f34d95869144a00e6 (diff)
downloadupstream-3af779eb172b0438f77e8a01a97dd0eb9a146076.tar.gz
upstream-3af779eb172b0438f77e8a01a97dd0eb9a146076.tar.bz2
upstream-3af779eb172b0438f77e8a01a97dd0eb9a146076.zip
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
Diffstat (limited to 'target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch')
-rw-r--r--target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch303
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>;
++ };
++ };
++ };