diff options
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.patch | 303 |
1 files changed, 0 insertions, 303 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 deleted file mode 100644 index 34e3969683..0000000000 --- a/target/linux/mvebu/patches-3.10/0065-bus-mvebu-mbus-Add-devicetree-binding.patch +++ /dev/null @@ -1,303 +0,0 @@ -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>; -+ }; -+ }; -+ }; |