MBus DT binding for Armada 370/XP and Kirkwood
Subsystems (8)
v9 cover MBus DT binding for Armada 370/XP and Kirkwood
This is a minor revision of the patchset, splitting patches with DT bindings changes to separate patches. See the changelog for more context information.
Except for this patch splitting, this can be considered as a v8 resend.
This has been tested on several Armada 370/XP boards, and on Plathome Openblocks A6 Kirkwood board by myself; Kirkwood and Dove testing has been performed by Andrew Lunn and Sebastian Hesselbarth respectively.
If anyone wants to do further testing, there's a public branch:
https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v9
At this point all that's left is to have formal Acked-by from some DT maintainer/s to the DT binding itself.
This is based on v3.11-rc2.
Changelog
---------
v9:
* Split DT bindings in separate patches and send only these to the devicetree mailing list to avoid overloading it, as suggested by Olof Johansson.
v8:
* Introduce Kirkwood MBus DT binding and use it to relocate the PCIe nodes *only*.
* Allow MBus to initialize when the node has no ranges property.
* Add a sanity check for PCIe port base address to prevent a kernel panic when this address has not been obtained. Instead of panic, the PCIe won't work in such cases.
v7:
* Add two optional properties pcie-{mem,io}-aperture to the MBus node defining the PCIe mem and IO region apertures.
* Encode the PCIe port in the second cell of the ranges entries, using the PCIe slot; and remove such encoding from the first cell, since it was violating the specification.
Quoting Jason Gunthorpe:
""" [...] the OF spec says that the phys.hi fields of the child address spaces in the "ranges" property for PCI does not contain the same information as "reg" property entries within PCI nodes. The only information that is present in "ranges" phys.hi entries are the non-relocatable, prefetchable and the PCI address space bits for which the entry applies. I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0."""
v6:
* Change the PCIe ranges translations encoding, removing the big fake window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing the PCIe real windows with full 4 GiB size.
* The corresponding PCIe port is selected by encoding the bus in the first cell of the PCIe controller node ranges entry.
* Remove the name-based MBus window allocation API, replacing it by an ID-based API.
v5:
* Add a required a 'controller' property to specify a phandle containing the MBus controller MMIO registers.
v4:
* Fixed the pcie-controller to mbus address space translations, to match a 1:1 mapping between the PCI and CPU busses.
* Fixed the binding documentation with suggestions from Arnd Bergmann.
* Added a BootROM sanity check on AXP SMP initialization, as suggested by Jason Gunthorpe. This also implied changing slightly the bootrom node.
* Changed the first cell format for the MBus address space.
v3:
* Replaced the PCIe mapping with 0xffff0002, to avoid using a representation that might correspond to a possible window id.
* Remove every mbus-node 'ranges' property from the dtsi files. Having them on the per-board dts files only makes maintaince less painful.
* Declare children window size, in the children 'ranges' property, as large as possible (4 GiB size) and move the property to the dtsi files. The per-board dts, does not need to declare that property now.
* The MBus driver now creates the decoding window using the base address and size specified in the mbus-node, instead of using the children entries.
v2:
* Use the preprocessor on the DT and define a macro for the window ID.
* Changed the way the address spaces were declared: the window's base addresses are only present in the mbus-node ranges property. This makes sense since that information belongs only to the MBus address space.
* Drop the ranges dynamic update, since now the DT translations are complete.
* Replaced the internal register first cell mapping with 0xffff0001, to avoid clashing when using 0x00000000.
* Replaced the PCIe mapping with 0xffff0000.
v1:
* Initial proposal
Example
-------
Here's an example showing how the MBus DT binding looks now:
soc {
compatible = "marvell,armadaxp-mbus", "simple-bus";
controller = <&mbusc>;
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
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 */
0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
0x82000000 0x2 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
0x81000000 0x2 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;
pcie at 1,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
0x81000000 0 0 0x81000000 0x1 0 1 0>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &mpic 58>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 5>;
status = "disabled";
};
pcie at 2,0 {
device_type = "pci";
assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
0x81000000 0 0 0x81000000 0x2 0 1 0>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &mpic 62>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 9>;
status = "disabled";
};
};
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller at 20000 {
reg = <0x20000 0x100>, <0x20180 0x20>;
};
interrupt-controller at 20000 {
reg = <0x20a00 0x2d0>, <0x21070 0x58>;
};
};
};Ezequiel Garcia (19):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
PCI: mvebu: Check valid base address before port setup
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
ARM: kirkwood: Split DT and legacy MBus initialization
ARM: kirkwood: Use the preprocessor on device tree files
ARM: kirkwood: Introduce MBus DT node
ARM: kirkwood: Introduce MBUS_ID
ARM: kirkwood: Relocate PCIe device tree nodes
bus: mvebu-mbus: Add devicetree binding
Thomas Petazzoni (11):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM: mv78xx0: Move to ID based window creation
ARM: orion5x: Move to ID based window creation
ARM: dove: Move to ID based window creation
PCI: mvebu: Adapt to the new device tree layout
bus: mvebu-mbus: Remove the no longer used name-based API
bus: mvebu-mbus: Remove name -> target, attribute mapping tables
bus: mvebu-mbus: Update main description
bus: mvebu-mbus: Factorize Armada 370/XP data structures
PCI: mvebu: Adapt to the new device tree layout
.../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++ .../devicetree/bindings/pci/mvebu-pci.txt | 145 +++++-- arch/arm/boot/dts/armada-370-db.dts | 5 +- arch/arm/boot/dts/armada-370-mirabox.dts | 37 +- arch/arm/boot/dts/armada-370-rd.dts | 5 +- arch/arm/boot/dts/armada-370-xp.dtsi | 111 +++--- arch/arm/boot/dts/armada-370.dtsi | 112 +++--- arch/arm/boot/dts/armada-xp-db.dts | 131 +++--- arch/arm/boot/dts/armada-xp-gp.dts | 107 +++-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++++++----- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 263 ++++++------ arch/arm/boot/dts/armada-xp-mv78460.dtsi | 411 ++++++++++--------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 88 ++-- arch/arm/boot/dts/armada-xp.dtsi | 9 +- arch/arm/boot/dts/kirkwood-6281.dtsi | 66 +-- arch/arm/boot/dts/kirkwood-6282.dtsi | 102 ++--- arch/arm/boot/dts/kirkwood-cloudbox.dts | 4 +- arch/arm/boot/dts/kirkwood-db-88f6281.dts | 7 +- arch/arm/boot/dts/kirkwood-db-88f6282.dts | 7 +- arch/arm/boot/dts/kirkwood-db.dtsi | 10 +- arch/arm/boot/dts/kirkwood-dns320.dts | 2 +- arch/arm/boot/dts/kirkwood-dns325.dts | 2 +- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 4 +- arch/arm/boot/dts/kirkwood-dockstar.dts | 4 +- arch/arm/boot/dts/kirkwood-dreamplug.dts | 4 +- arch/arm/boot/dts/kirkwood-goflexnet.dts | 4 +- .../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 4 +- arch/arm/boot/dts/kirkwood-ib62x0.dts | 4 +- arch/arm/boot/dts/kirkwood-iconnect.dts | 23 +- arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 4 +- arch/arm/boot/dts/kirkwood-is2.dts | 2 +- arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 4 +- arch/arm/boot/dts/kirkwood-lschlv2.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxhl.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxl.dtsi | 4 +- arch/arm/boot/dts/kirkwood-mplcec4.dts | 23 +- .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 23 +- arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-ns2.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2lite.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2max.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2mini.dts | 2 +- arch/arm/boot/dts/kirkwood-nsa310.dts | 23 +- arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 2 +- arch/arm/boot/dts/kirkwood-sheevaplug.dts | 2 +- arch/arm/boot/dts/kirkwood-topkick.dts | 4 +- arch/arm/boot/dts/kirkwood-ts219-6281.dts | 6 +- arch/arm/boot/dts/kirkwood-ts219-6282.dts | 25 +- arch/arm/boot/dts/kirkwood-ts219.dtsi | 17 +- arch/arm/boot/dts/kirkwood.dtsi | 17 +- arch/arm/mach-dove/common.c | 68 ++-- arch/arm/mach-kirkwood/board-dt.c | 1 + arch/arm/mach-kirkwood/common.c | 26 +- arch/arm/mach-kirkwood/pcie.c | 40 +- arch/arm/mach-mv78xx0/pcie.c | 23 +- arch/arm/mach-mvebu/armada-370-xp.c | 34 +- arch/arm/mach-mvebu/platsmp.c | 25 +- arch/arm/mach-orion5x/common.c | 36 +- arch/arm/mach-orion5x/common.h | 17 + arch/arm/mach-orion5x/d2net-setup.c | 6 +- arch/arm/mach-orion5x/db88f5281-setup.c | 24 +- arch/arm/mach-orion5x/dns323-setup.c | 6 +- arch/arm/mach-orion5x/edmini_v2-setup.c | 6 +- arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 +- arch/arm/mach-orion5x/ls-chl-setup.c | 6 +- arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +- arch/arm/mach-orion5x/lsmini-setup.c | 6 +- arch/arm/mach-orion5x/mss2-setup.c | 6 +- arch/arm/mach-orion5x/mv2120-setup.c | 6 +- arch/arm/mach-orion5x/net2big-setup.c | 6 +- arch/arm/mach-orion5x/pci.c | 9 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5182-setup.c | 13 +- arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +- arch/arm/mach-orion5x/ts209-setup.c | 6 +- arch/arm/mach-orion5x/ts409-setup.c | 6 +- arch/arm/mach-orion5x/wnr854t-setup.c | 6 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +- drivers/bus/mvebu-mbus.c | 441 ++++++++++++--------- drivers/memory/mvebu-devbus.c | 64 +-- drivers/pci/host/pci-mvebu.c | 115 ++++-- include/linux/mbus.h | 16 +- 85 files changed, 2030 insertions(+), 1379 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
Signature · 1 line
1.8.1.5
PATCH v9 1/30 memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in the device tree, as described by the mbus binding documentation.
--- drivers/memory/mvebu-devbus.c | 64 ++----------------------------------------- 1 file changed, 2 insertions(+), 62 deletions(-)
drivers/memory/mvebu-devbus.c +2 -62
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev) {struct device *dev = &pdev->dev;struct device_node *node = pdev->dev.of_node; -struct device_node *parent;struct devbus *devbus;struct resource *res;struct clk *clk;unsigned long rate; -const __be32 *ranges; -int err, cs; -int addr_cells, p_addr_cells, size_cells; -int ranges_len, tuple_len; -u32 base, size; +int err; devbus =devm_kzalloc (&pdev->dev,sizeof (struct devbus ),GFP_KERNEL );if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)return err;/* -* Allocate an address window for this device. -* If the device probing fails, then we won't be able to -* remove the allocated address decoding window. -* -* FIXME: This is only a temporary hack! We need to do this here -* because we still don't have device tree bindings for mbus. -* Once that support is added, we will declare these address windows -* statically in the device tree, and remove the window configuration -* from here. -*/ - -/* -* Get the CS to choose the window string. -* This is a bit hacky, but it will be removed once the -* address windows are declared in the device tree. -*/ - cs = (((unsigned long )devbus->base) %0x400 ) /8 ; - -/* -* Parse 'ranges' property to obtain a (base,size) window tuple. -* This will be removed once the address windows -* are declared in the device tree. -*/ - parent =of_get_parent (node); -if (!parent) -return -EINVAL ; - - p_addr_cells =of_n_addr_cells (parent); -of_node_put (parent); - - addr_cells =of_n_addr_cells (node); - size_cells =of_n_size_cells (node); - tuple_len = (p_addr_cells + addr_cells + size_cells) *sizeof (__be32); - - ranges =of_get_property (node,"ranges" , &ranges_len); -if (ranges ==NULL || ranges_len != tuple_len) -return -EINVAL ; - - base =of_translate_address (node, ranges + addr_cells); -if (base ==OF_BAD_ADDR ) -return -EINVAL ; - size =of_read_number (ranges + addr_cells + p_addr_cells, size_cells); - -/* -* Create an mbus address windows. -* FIXME: Remove this, together with the above code, once the -* address windows are declared in the device tree. -*/ - err =mvebu_mbus_add_window (devbus_wins[cs], base, size); -if (err <0 ) -return err; - -/* * We need to create a child device explicitly from here to * guarantee that the child will be probed after the timing * parameters for the bus are written. */ err =of_platform_populate (node,NULL ,NULL , dev); -if (err <0 ) { -mvebu_mbus_del_window (base, size); +if (err <0 )return err; - }return 0 ; }
Signature · 1 line
1.8.1.5
PATCH v9 2/30 bus: mvebu-mbus: Add new API for window creation
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
We add an API to create MBus address decoding windows from the target ID and attribute. This function will be used later and deprecate the current name based scheme.
--- drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++-------- include/linux/mbus.h | 6 ++++++ 2 files changed, 31 insertions(+), 8 deletions(-)
drivers/bus/mvebu-mbus.c +25 -8
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {/* * Public API of the driver */ +int mvebu_mbus_add_window_remap_by_id (unsigned int target, +unsigned int attribute, +phys_addr_t base,size_t size, +phys_addr_t remap) +{ +struct mvebu_mbus_state *s = &mbus_state; + +if (!mvebu_mbus_window_conflicts (s, base, size, target, attribute)) { +pr_err ("cannot add window '%x:%x', conflicts with another window\n" , + target, attribute); +return -EINVAL ; + } + +return mvebu_mbus_alloc_window (s, base, size, remap, target, attribute); +} +int mvebu_mbus_add_window_remap_flags (const char *devname,phys_addr_t base,size_t size,phys_addr_t remap,unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,else if (flags ==MVEBU_MBUS_PCI_WA ) attr |=0x28 ; -if (!mvebu_mbus_window_conflicts (s, base, size, target, attr)) { -pr_err ("cannot add window '%s', conflicts with another window\n" , - devname); -return -EINVAL ; - } - -return mvebu_mbus_alloc_window (s, base, size, remap, target, attr); - +return mvebu_mbus_add_window_remap_by_id (target, attr, base, + size, remap); }int mvebu_mbus_add_window (const char *devname,phys_addr_t base,size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size) MVEBU_MBUS_NO_REMAP, 0); } +int mvebu_mbus_add_window_by_id (unsigned int target,unsigned int attribute, +phys_addr_t base,size_t size) +{ +return mvebu_mbus_add_window_remap_by_id (target, attribute, base, + size,MVEBU_MBUS_NO_REMAP ); +} +int mvebu_mbus_del_window (phys_addr_t base,size_t size) {int win;
include/linux/mbus.h +6 -0
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)int mvebu_mbus_add_window_remap_flags (const char *devname,phys_addr_t base,size_t size,phys_addr_t remap,unsigned int flags); +int mvebu_mbus_add_window_remap_by_id (unsigned int target, +unsigned int attribute, +phys_addr_t base,size_t size, +phys_addr_t remap);int mvebu_mbus_add_window (const char *devname,phys_addr_t base,size_t size); +int mvebu_mbus_add_window_by_id (unsigned int target,unsigned int attribute, +phys_addr_t base,size_t size);int mvebu_mbus_del_window (phys_addr_t base,size_t size); int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base, size_t mbus_size, phys_addr_t sdram_phys_base,
Signature · 1 line
1.8.1.5
PATCH v9 3/30 ARM: kirkwood: Move to ID based MBus window creation
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
With the introduction of the ID based MBus API, it's better to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every user is removed.
--- arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++---- arch/arm/mach-kirkwood/pcie.c | 40 ++++++++++++++++++++++++---------------- 2 files changed, 38 insertions(+), 20 deletions(-)
arch/arm/mach-kirkwood/common.c +14 -4
@@ -37,6 +37,12 @@#include <linux/platform_data/dma-mv_xor.h> #include "common.h" +/* These can go away once Kirkwood uses the mvebu-mbus DT binding */ +#define KIRKWOOD_MBUS_NAND_TARGET 0x01 +#define KIRKWOOD_MBUS_NAND_ATTR 0x2f +#define KIRKWOOD_MBUS_SRAM_TARGET 0x03 +#define KIRKWOOD_MBUS_SRAM_ATTR 0x01 +/***************************************************************************** * I/O Address Mapping ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)void __init kirkwood_setup_wins (void ) { -mvebu_mbus_add_window ("nand" ,KIRKWOOD_NAND_MEM_PHYS_BASE , -KIRKWOOD_NAND_MEM_SIZE ); -mvebu_mbus_add_window ("sram" ,KIRKWOOD_SRAM_PHYS_BASE , -KIRKWOOD_SRAM_SIZE ); +mvebu_mbus_add_window_by_id (KIRKWOOD_MBUS_NAND_TARGET , +KIRKWOOD_MBUS_NAND_ATTR , +KIRKWOOD_NAND_MEM_PHYS_BASE , +KIRKWOOD_NAND_MEM_SIZE ); +mvebu_mbus_add_window_by_id (KIRKWOOD_MBUS_SRAM_TARGET , +KIRKWOOD_MBUS_SRAM_ATTR , +KIRKWOOD_SRAM_PHYS_BASE , +KIRKWOOD_SRAM_SIZE ); }void __init kirkwood_l2_init (void )
arch/arm/mach-kirkwood/pcie.c +24 -16
@@ -20,6 +20,16 @@#include <mach/bridge-regs.h> #include "common.h" +/* These can go away once Kirkwood uses the mvebu-mbus DT binding */ +#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET 0x4 +#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR 0xe8 +#define KIRKWOOD_MBUS_PCIE0_IO_TARGET 0x4 +#define KIRKWOOD_MBUS_PCIE0_IO_ATTR 0xe0 +#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET 0x4 +#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR 0xd8 +#define KIRKWOOD_MBUS_PCIE1_IO_TARGET 0x4 +#define KIRKWOOD_MBUS_PCIE1_IO_ATTR 0xd0 +static void kirkwood_enable_pcie_clk (const char *port) {struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)void __init kirkwood_pcie_init (unsigned int portmask) { -mvebu_mbus_add_window_remap_flags ("pcie0.0" , +mvebu_mbus_add_window_remap_by_id (KIRKWOOD_MBUS_PCIE0_IO_TARGET , +KIRKWOOD_MBUS_PCIE0_IO_ATTR ,KIRKWOOD_PCIE_IO_PHYS_BASE ,KIRKWOOD_PCIE_IO_SIZE , -KIRKWOOD_PCIE_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pcie0.0" , -KIRKWOOD_PCIE_MEM_PHYS_BASE , -KIRKWOOD_PCIE_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); -mvebu_mbus_add_window_remap_flags ("pcie1.0" , +KIRKWOOD_PCIE_IO_BUS_BASE ); +mvebu_mbus_add_window_by_id (KIRKWOOD_MBUS_PCIE0_MEM_TARGET , +KIRKWOOD_MBUS_PCIE0_MEM_ATTR , +KIRKWOOD_PCIE_MEM_PHYS_BASE , +KIRKWOOD_PCIE_MEM_SIZE ); +mvebu_mbus_add_window_remap_by_id (KIRKWOOD_MBUS_PCIE1_IO_TARGET , +KIRKWOOD_MBUS_PCIE1_IO_ATTR ,KIRKWOOD_PCIE1_IO_PHYS_BASE ,KIRKWOOD_PCIE1_IO_SIZE , -KIRKWOOD_PCIE1_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pcie1.0" , -KIRKWOOD_PCIE1_MEM_PHYS_BASE , -KIRKWOOD_PCIE1_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); +KIRKWOOD_PCIE1_IO_BUS_BASE ); +mvebu_mbus_add_window_by_id (KIRKWOOD_MBUS_PCIE1_MEM_TARGET , +KIRKWOOD_MBUS_PCIE1_MEM_ATTR , +KIRKWOOD_PCIE1_MEM_PHYS_BASE , +KIRKWOOD_PCIE1_MEM_SIZE ); vga_base =KIRKWOOD_PCIE_MEM_PHYS_BASE ;
Signature · 1 line
1.8.1.5
PATCH v9 4/30 ARM: mv78xx0: Move to ID based window creation
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
With the introduction of the ID based MBus API, it's better to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every user is removed.
--- arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-)
arch/arm/mach-mv78xx0/pcie.c +11 -12
@@ -18,6 +18,11 @@#include <mach/mv78xx0.h> #include "common.h" +#define MV78XX0_MBUS_PCIE_MEM_TARGET (port, lane) ((port) ? 8 : 4) +#define MV78XX0_MBUS_PCIE_MEM_ATTR (port, lane) (0xf8 & ~(0x10 << (lane))) +#define MV78XX0_MBUS_PCIE_IO_TARGET (port, lane) ((port) ? 8 : 4) +#define MV78XX0_MBUS_PCIE_IO_ATTR (port, lane) (0xf0 & ~(0x10 << (lane))) +struct pcie_port {u8 maj;u8 min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void) start =MV78XX0_PCIE_MEM_PHYS_BASE ;for (i =0 ; i < num_pcie_ports; i++) {struct pcie_port *pp = pcie_port + i; -char winname[MVEBU_MBUS_MAX_WINNAME_SZ ];snprintf (pp->mem_space_name,sizeof (pp->mem_space_name),"PCIe %d.%d MEM" , pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)if (request_resource (&iomem_resource, &pp->res))panic ("can't allocate PCIe MEM sub-space" ); -snprintf (winname,sizeof (winname),"pcie%d.%d" , - pp->maj, pp->min); - -mvebu_mbus_add_window_remap_flags (winname, - pp->res.start, -resource_size (&pp->res), -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); -mvebu_mbus_add_window_remap_flags (winname, - i *SZ_64K ,SZ_64K , -0 ,MVEBU_MBUS_PCI_IO ); +mvebu_mbus_add_window_by_id (MV78XX0_MBUS_PCIE_MEM_TARGET (pp->maj, pp->min), +MV78XX0_MBUS_PCIE_MEM_ATTR (pp->maj, pp->min), + pp->res.start,resource_size (&pp->res)); +mvebu_mbus_add_window_remap_by_id (MV78XX0_MBUS_PCIE_IO_TARGET (pp->maj, pp->min), +MV78XX0_MBUS_PCIE_IO_ATTR (pp->maj, pp->min), + i *SZ_64K ,SZ_64K ,0 ); } }
Signature · 1 line
1.8.1.5
PATCH v9 5/30 ARM: orion5x: Move to ID based window creation
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
With the introduction of the ID based MBus API, it's better to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every user is removed.
--- arch/arm/mach-orion5x/common.c | 36 ++++++++++++++------------ arch/arm/mach-orion5x/common.h | 17 ++++++++++++ arch/arm/mach-orion5x/d2net-setup.c | 6 +++-- arch/arm/mach-orion5x/db88f5281-setup.c | 24 +++++++++++------ arch/arm/mach-orion5x/dns323-setup.c | 6 +++-- arch/arm/mach-orion5x/edmini_v2-setup.c | 6 +++-- arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 ++++++--- arch/arm/mach-orion5x/ls-chl-setup.c | 6 +++-- arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +++-- arch/arm/mach-orion5x/lsmini-setup.c | 6 +++-- arch/arm/mach-orion5x/mss2-setup.c | 6 +++-- arch/arm/mach-orion5x/mv2120-setup.c | 6 +++-- arch/arm/mach-orion5x/net2big-setup.c | 6 +++-- arch/arm/mach-orion5x/pci.c | 9 +++---- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +++-- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 6 +++-- arch/arm/mach-orion5x/rd88f5182-setup.c | 13 ++++++---- arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +++-- arch/arm/mach-orion5x/ts209-setup.c | 6 +++-- arch/arm/mach-orion5x/ts409-setup.c | 6 +++-- arch/arm/mach-orion5x/wnr854t-setup.c | 6 +++-- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +++-- 22 files changed, 137 insertions(+), 70 deletions(-)
arch/arm/mach-orion5x/common.c +20 -16
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)****************************************************************************/ static void __init orion5x_crypto_init (void ) { -mvebu_mbus_add_window ("sram" ,ORION5X_SRAM_PHYS_BASE , -ORION5X_SRAM_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_SRAM_TARGET , +ORION_MBUS_SRAM_ATTR , +ORION5X_SRAM_PHYS_BASE , +ORION5X_SRAM_SIZE );orion_crypto_init (ORION5X_CRYPTO_PHYS_BASE ,ORION5X_SRAM_PHYS_BASE ,SZ_8K ,IRQ_ORION5X_CESA ); }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)* The PCIe windows will no longer be statically allocated * here once Orion5x is migrated to the pci-mvebu driver. */ -mvebu_mbus_add_window_remap_flags ("pcie0.0" ,ORION5X_PCIE_IO_PHYS_BASE , +mvebu_mbus_add_window_remap_by_id (ORION_MBUS_PCIE_IO_TARGET , +ORION_MBUS_PCIE_IO_ATTR , +ORION5X_PCIE_IO_PHYS_BASE ,ORION5X_PCIE_IO_SIZE , -ORION5X_PCIE_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pcie0.0" ,ORION5X_PCIE_MEM_PHYS_BASE , -ORION5X_PCIE_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); -mvebu_mbus_add_window_remap_flags ("pci0.0" ,ORION5X_PCI_IO_PHYS_BASE , +ORION5X_PCIE_IO_BUS_BASE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_PCIE_MEM_TARGET , +ORION_MBUS_PCIE_MEM_ATTR , +ORION5X_PCIE_MEM_PHYS_BASE , +ORION5X_PCIE_MEM_SIZE ); +mvebu_mbus_add_window_remap_by_id (ORION_MBUS_PCI_IO_TARGET , +ORION_MBUS_PCI_IO_ATTR , +ORION5X_PCI_IO_PHYS_BASE ,ORION5X_PCI_IO_SIZE , -ORION5X_PCI_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pci0.0" ,ORION5X_PCI_MEM_PHYS_BASE , -ORION5X_PCI_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); +ORION5X_PCI_IO_BUS_BASE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_PCI_MEM_TARGET , +ORION_MBUS_PCI_MEM_ATTR , +ORION5X_PCI_MEM_PHYS_BASE , +ORION5X_PCI_MEM_SIZE ); }int orion5x_tclk;
arch/arm/mach-orion5x/common.h +17 -0
@@ -7,6 +7,23 @@ struct dsa_platform_data;struct mv643xx_eth_platform_data ;struct mv_sata_platform_data ; +#define ORION_MBUS_PCIE_MEM_TARGET 0x04 +#define ORION_MBUS_PCIE_MEM_ATTR 0x59 +#define ORION_MBUS_PCIE_IO_TARGET 0x04 +#define ORION_MBUS_PCIE_IO_ATTR 0x51 +#define ORION_MBUS_PCIE_WA_TARGET 0x04 +#define ORION_MBUS_PCIE_WA_ATTR 0x79 +#define ORION_MBUS_PCI_MEM_TARGET 0x03 +#define ORION_MBUS_PCI_MEM_ATTR 0x59 +#define ORION_MBUS_PCI_IO_TARGET 0x03 +#define ORION_MBUS_PCI_IO_ATTR 0x51 +#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01 +#define ORION_MBUS_DEVBUS_BOOT_ATTR 0x0f +#define ORION_MBUS_DEVBUS_TARGET (cs) 0x01 +#define ORION_MBUS_DEVBUS_ATTR (cs) (~(1 << cs)) +#define ORION_MBUS_SRAM_TARGET 0x00 +#define ORION_MBUS_SRAM_ATTR 0x00 +/* * Basic Orion init functions used early by machine-setup. */
arch/arm/mach-orion5x/d2net-setup.c +4 -2
@@ -317,8 +317,10 @@ static void __init d2net_init(void)d2net_sata_power_init ();orion5x_sata_init (&d2net_sata_data); -mvebu_mbus_add_window ("devbus-boot" ,D2NET_NOR_BOOT_BASE , -D2NET_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +D2NET_NOR_BOOT_BASE , +D2NET_NOR_BOOT_SIZE );platform_device_register (&d2net_nor_flash);platform_device_register (&d2net_gpio_buttons);
arch/arm/mach-orion5x/db88f5281-setup.c +16 -8
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)orion5x_uart0_init ();orion5x_uart1_init (); -mvebu_mbus_add_window ("devbus-boot" ,DB88F5281_NOR_BOOT_BASE , -DB88F5281_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +DB88F5281_NOR_BOOT_BASE , +DB88F5281_NOR_BOOT_SIZE );platform_device_register (&db88f5281_boot_flash); -mvebu_mbus_add_window ("devbus-cs0" ,DB88F5281_7SEG_BASE , -DB88F5281_7SEG_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_TARGET (0 ), +ORION_MBUS_DEVBUS_ATTR (0 ), +DB88F5281_7SEG_BASE , +DB88F5281_7SEG_SIZE ); -mvebu_mbus_add_window ("devbus-cs1" ,DB88F5281_NOR_BASE , -DB88F5281_NOR_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_TARGET (1 ), +ORION_MBUS_DEVBUS_ATTR (1 ), +DB88F5281_NOR_BASE , +DB88F5281_NOR_SIZE );platform_device_register (&db88f5281_nor_flash); -mvebu_mbus_add_window ("devbus-cs2" ,DB88F5281_NAND_BASE , -DB88F5281_NAND_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_TARGET (2 ), +ORION_MBUS_DEVBUS_ATTR (2 ), +DB88F5281_NAND_BASE , +DB88F5281_NAND_SIZE );platform_device_register (&db88f5281_nand_flash);i2c_register_board_info (0 , &db88f5281_i2c_rtc,1 );
arch/arm/mach-orion5x/dns323-setup.c +4 -2
@@ -611,8 +611,10 @@ static void __init dns323_init(void)/* setup flash mapping * CS3 holds a 8 MB Spansion S29GL064M90TFIR4 */ -mvebu_mbus_add_window ("devbus-boot" ,DNS323_NOR_BOOT_BASE , -DNS323_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +DNS323_NOR_BOOT_BASE , +DNS323_NOR_BOOT_SIZE );platform_device_register (&dns323_nor_flash);/* Sort out LEDs, Buttons and i2c devices */
arch/arm/mach-orion5x/edmini_v2-setup.c +4 -2
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)orion5x_ehci0_init ();orion5x_eth_init (&edmini_v2_eth_data); -mvebu_mbus_add_window ("devbus-boot" ,EDMINI_V2_NOR_BOOT_BASE , -EDMINI_V2_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +EDMINI_V2_NOR_BOOT_BASE , +EDMINI_V2_NOR_BOOT_SIZE );platform_device_register (&edmini_v2_nor_flash); pr_notice("edmini_v2: USB device port, flash write and power-off "
arch/arm/mach-orion5x/kurobox_pro-setup.c +8 -4
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)orion5x_uart1_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,KUROBOX_PRO_NOR_BOOT_BASE , -KUROBOX_PRO_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +KUROBOX_PRO_NOR_BOOT_BASE , +KUROBOX_PRO_NOR_BOOT_SIZE );platform_device_register (&kurobox_pro_nor_flash);if (machine_is_kurobox_pro ()) { -mvebu_mbus_add_window ("devbus-cs0" ,KUROBOX_PRO_NAND_BASE , -KUROBOX_PRO_NAND_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_TARGET (0 ), +ORION_MBUS_DEVBUS_ATTR (0 ), +KUROBOX_PRO_NAND_BASE , +KUROBOX_PRO_NAND_SIZE );platform_device_register (&kurobox_pro_nand_flash); }
arch/arm/mach-orion5x/ls-chl-setup.c +4 -2
@@ -294,8 +294,10 @@ static void __init lschl_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,LSCHL_NOR_BOOT_BASE , -LSCHL_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +LSCHL_NOR_BOOT_BASE , +LSCHL_NOR_BOOT_SIZE );platform_device_register (&lschl_nor_flash);platform_device_register (&lschl_leds);
arch/arm/mach-orion5x/ls_hgl-setup.c +4 -2
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,LS_HGL_NOR_BOOT_BASE , -LS_HGL_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +LS_HGL_NOR_BOOT_BASE , +LS_HGL_NOR_BOOT_SIZE );platform_device_register (&ls_hgl_nor_flash);platform_device_register (&ls_hgl_button_device);
arch/arm/mach-orion5x/lsmini-setup.c +4 -2
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,LSMINI_NOR_BOOT_BASE , -LSMINI_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +LSMINI_NOR_BOOT_BASE , +LSMINI_NOR_BOOT_SIZE );platform_device_register (&lsmini_nor_flash);platform_device_register (&lsmini_button_device);
arch/arm/mach-orion5x/mss2-setup.c +4 -2
@@ -241,8 +241,10 @@ static void __init mss2_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,MSS2_NOR_BOOT_BASE , -MSS2_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +MSS2_NOR_BOOT_BASE , +MSS2_NOR_BOOT_SIZE );platform_device_register (&mss2_nor_flash);platform_device_register (&mss2_button_device);
arch/arm/mach-orion5x/mv2120-setup.c +4 -2
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,MV2120_NOR_BOOT_BASE , -MV2120_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +MV2120_NOR_BOOT_BASE , +MV2120_NOR_BOOT_SIZE );platform_device_register (&mv2120_nor_flash);platform_device_register (&mv2120_button_device);
arch/arm/mach-orion5x/net2big-setup.c +4 -2
@@ -397,8 +397,10 @@ static void __init net2big_init(void)net2big_sata_power_init ();orion5x_sata_init (&net2big_sata_data); -mvebu_mbus_add_window ("devbus-boot" ,NET2BIG_NOR_BOOT_BASE , -NET2BIG_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +NET2BIG_NOR_BOOT_BASE , +NET2BIG_NOR_BOOT_SIZE );platform_device_register (&net2big_nor_flash);platform_device_register (&net2big_gpio_buttons);
arch/arm/mach-orion5x/pci.c +4 -5
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)if (dev ==MV88F5181_DEV_ID || dev ==MV88F5182_DEV_ID ) {printk (KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config " "read transaction workaround\n" ); -mvebu_mbus_add_window_remap_flags ("pcie0.0" , -ORION5X_PCIE_WA_PHYS_BASE , -ORION5X_PCIE_WA_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_WA ); +mvebu_mbus_add_window_by_id (ORION_MBUS_PCIE_WA_TARGET , +ORION_MBUS_PCIE_WA_ATTR , +ORION5X_PCIE_WA_PHYS_BASE , +ORION5X_PCIE_WA_SIZE ); pcie_ops.read = pcie_rd_conf_wa; }
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c +4 -2
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)orion5x_eth_switch_init (&rd88f5181l_fxo_switch_plat_data,NO_IRQ );orion5x_uart0_init (); -mvebu_mbus_add_window ("devbus-boot" ,RD88F5181L_FXO_NOR_BOOT_BASE , -RD88F5181L_FXO_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +RD88F5181L_FXO_NOR_BOOT_BASE , +RD88F5181L_FXO_NOR_BOOT_SIZE );platform_device_register (&rd88f5181l_fxo_nor_boot_flash); }
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c +4 -2
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)orion5x_i2c_init ();orion5x_uart0_init (); -mvebu_mbus_add_window ("devbus-boot" ,RD88F5181L_GE_NOR_BOOT_BASE , -RD88F5181L_GE_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +RD88F5181L_GE_NOR_BOOT_BASE , +RD88F5181L_GE_NOR_BOOT_SIZE );platform_device_register (&rd88f5181l_ge_nor_boot_flash);i2c_register_board_info (0 , &rd88f5181l_ge_i2c_rtc,1 );
arch/arm/mach-orion5x/rd88f5182-setup.c +8 -5
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)orion5x_uart0_init ();orion5x_xor_init (); -mvebu_mbus_add_window ("devbus-boot" ,RD88F5182_NOR_BOOT_BASE , -RD88F5182_NOR_BOOT_SIZE ); - -mvebu_mbus_add_window ("devbus-cs1" ,RD88F5182_NOR_BASE , -RD88F5182_NOR_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +RD88F5182_NOR_BOOT_BASE , +RD88F5182_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_TARGET (1 ), +ORION_MBUS_DEVBUS_ATTR (1 ), +RD88F5182_NOR_BASE , +RD88F5182_NOR_SIZE );platform_device_register (&rd88f5182_nor_flash);platform_device_register (&rd88f5182_gpio_leds);
arch/arm/mach-orion5x/terastation_pro2-setup.c +4 -2
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)/* * Configure peripherals. */ -mvebu_mbus_add_window ("devbus-boot" ,TSP2_NOR_BOOT_BASE , -TSP2_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +TSP2_NOR_BOOT_BASE , +TSP2_NOR_BOOT_SIZE );platform_device_register (&tsp2_nor_flash);orion5x_ehci0_init ();
arch/arm/mach-orion5x/ts209-setup.c +4 -2
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)/* * Configure peripherals. */ -mvebu_mbus_add_window ("devbus-boot" ,QNAP_TS209_NOR_BOOT_BASE , -QNAP_TS209_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +QNAP_TS209_NOR_BOOT_BASE , +QNAP_TS209_NOR_BOOT_SIZE );platform_device_register (&qnap_ts209_nor_flash);orion5x_ehci0_init ();
arch/arm/mach-orion5x/ts409-setup.c +4 -2
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)/* * Configure peripherals. */ -mvebu_mbus_add_window ("devbus-boot" ,QNAP_TS409_NOR_BOOT_BASE , -QNAP_TS409_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +QNAP_TS409_NOR_BOOT_BASE , +QNAP_TS409_NOR_BOOT_SIZE );platform_device_register (&qnap_ts409_nor_flash);orion5x_ehci0_init ();
arch/arm/mach-orion5x/wnr854t-setup.c +4 -2
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)orion5x_eth_switch_init (&wnr854t_switch_plat_data,NO_IRQ );orion5x_uart0_init (); -mvebu_mbus_add_window ("devbus-boot" ,WNR854T_NOR_BOOT_BASE , -WNR854T_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +WNR854T_NOR_BOOT_BASE , +WNR854T_NOR_BOOT_SIZE );platform_device_register (&wnr854t_nor_flash); }
arch/arm/mach-orion5x/wrt350n-v2-setup.c +4 -2
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)orion5x_eth_switch_init (&wrt350n_v2_switch_plat_data,NO_IRQ );orion5x_uart0_init (); -mvebu_mbus_add_window ("devbus-boot" ,WRT350N_V2_NOR_BOOT_BASE , -WRT350N_V2_NOR_BOOT_SIZE ); +mvebu_mbus_add_window_by_id (ORION_MBUS_DEVBUS_BOOT_TARGET , +ORION_MBUS_DEVBUS_BOOT_ATTR , +WRT350N_V2_NOR_BOOT_BASE , +WRT350N_V2_NOR_BOOT_SIZE );platform_device_register (&wrt350n_v2_nor_flash);platform_device_register (&wrt350n_v2_leds);platform_device_register (&wrt350n_v2_button_device);
Signature · 1 line
1.8.1.5
PATCH v9 6/30 ARM: dove: Move to ID based window creation
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
With the introduction of the ID based MBus API, it's better to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every user is removed.
--- arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++--------------- 1 file changed, 45 insertions(+), 23 deletions(-)
arch/arm/mach-dove/common.c +45 -23
@@ -27,6 +27,22 @@#include <plat/time.h> #include "common.h" +/* These can go away once Dove uses the mvebu-mbus DT binding */ +#define DOVE_MBUS_PCIE0_MEM_TARGET 0x4 +#define DOVE_MBUS_PCIE0_MEM_ATTR 0xe8 +#define DOVE_MBUS_PCIE0_IO_TARGET 0x4 +#define DOVE_MBUS_PCIE0_IO_ATTR 0xe0 +#define DOVE_MBUS_PCIE1_MEM_TARGET 0x8 +#define DOVE_MBUS_PCIE1_MEM_ATTR 0xe8 +#define DOVE_MBUS_PCIE1_IO_TARGET 0x8 +#define DOVE_MBUS_PCIE1_IO_ATTR 0xe0 +#define DOVE_MBUS_CESA_TARGET 0x3 +#define DOVE_MBUS_CESA_ATTR 0x1 +#define DOVE_MBUS_BOOTROM_TARGET 0x1 +#define DOVE_MBUS_BOOTROM_ATTR 0xfd +#define DOVE_MBUS_SCRATCHPAD_TARGET 0xd +#define DOVE_MBUS_SCRATCHPAD_ATTR 0x0 +/***************************************************************************** * I/O Address Mapping ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void) {/* * The PCIe windows will no longer be statically allocated -* here once Dove is migrated to the pci-mvebu driver. +* here once Dove is migrated to the pci-mvebu driver. The +* non-PCIe windows will no longer be created here once Dove +* fully moves to DT. */ -mvebu_mbus_add_window_remap_flags ("pcie0.0" , +mvebu_mbus_add_window_remap_by_id (DOVE_MBUS_PCIE0_IO_TARGET , +DOVE_MBUS_PCIE0_IO_ATTR ,DOVE_PCIE0_IO_PHYS_BASE ,DOVE_PCIE0_IO_SIZE , -DOVE_PCIE0_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pcie1.0" , +DOVE_PCIE0_IO_BUS_BASE ); +mvebu_mbus_add_window_remap_by_id (DOVE_MBUS_PCIE1_IO_TARGET , +DOVE_MBUS_PCIE1_IO_ATTR ,DOVE_PCIE1_IO_PHYS_BASE ,DOVE_PCIE1_IO_SIZE , -DOVE_PCIE1_IO_BUS_BASE , -MVEBU_MBUS_PCI_IO ); -mvebu_mbus_add_window_remap_flags ("pcie0.0" , -DOVE_PCIE0_MEM_PHYS_BASE , -DOVE_PCIE0_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); -mvebu_mbus_add_window_remap_flags ("pcie1.0" , -DOVE_PCIE1_MEM_PHYS_BASE , -DOVE_PCIE1_MEM_SIZE , -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); -mvebu_mbus_add_window ("cesa" ,DOVE_CESA_PHYS_BASE , -DOVE_CESA_SIZE ); -mvebu_mbus_add_window ("bootrom" ,DOVE_BOOTROM_PHYS_BASE , -DOVE_BOOTROM_SIZE ); -mvebu_mbus_add_window ("scratchpad" ,DOVE_SCRATCHPAD_PHYS_BASE , -DOVE_SCRATCHPAD_SIZE ); +DOVE_PCIE1_IO_BUS_BASE ); +mvebu_mbus_add_window_by_id (DOVE_MBUS_PCIE0_MEM_TARGET , +DOVE_MBUS_PCIE0_MEM_ATTR , +DOVE_PCIE0_MEM_PHYS_BASE , +DOVE_PCIE0_MEM_SIZE ); +mvebu_mbus_add_window_by_id (DOVE_MBUS_PCIE1_MEM_TARGET , +DOVE_MBUS_PCIE1_MEM_ATTR , +DOVE_PCIE1_MEM_PHYS_BASE , +DOVE_PCIE1_MEM_SIZE ); +mvebu_mbus_add_window_by_id (DOVE_MBUS_CESA_TARGET , +DOVE_MBUS_CESA_ATTR , +DOVE_CESA_PHYS_BASE , +DOVE_CESA_SIZE ); +mvebu_mbus_add_window_by_id (DOVE_MBUS_BOOTROM_TARGET , +DOVE_MBUS_BOOTROM_ATTR , +DOVE_BOOTROM_PHYS_BASE , +DOVE_BOOTROM_SIZE ); +mvebu_mbus_add_window_by_id (DOVE_MBUS_SCRATCHPAD_TARGET , +DOVE_MBUS_SCRATCHPAD_ATTR , +DOVE_SCRATCHPAD_PHYS_BASE , +DOVE_SCRATCHPAD_SIZE ); }void __init dove_init (void )
Signature · 1 line
1.8.1.5
PATCH v9 7/30 bus: mvebu-mbus: Factor out initialization details
In reply to Ezequiel GarciaWe introduce a common initialization function mvebu_mbus_common_init() that will be used by both legacy and device-tree initialization code. This patch is an intermediate step, which will allow to introduce the DT binding for this driver in a less intrusive way.
--- drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 17 deletions(-)
drivers/bus/mvebu-mbus.c +30 -17
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void) }fs_initcall (mvebu_mbus_debugfs_init); -int __init mvebu_mbus_init (const char *soc,phys_addr_t mbuswins_phys_base, -size_t mbuswins_size, -phys_addr_t sdramwins_phys_base, -size_t sdramwins_size) +static int __init mvebu_mbus_common_init (struct mvebu_mbus_state *mbus, +phys_addr_t mbuswins_phys_base, +size_t mbuswins_size, +phys_addr_t sdramwins_phys_base, +size_t sdramwins_size) { -struct mvebu_mbus_state *mbus = &mbus_state; -const struct of_device_id *of_id;int win; -for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++) -if (!strcmp (of_id->compatible, soc)) -break ; - -if (!of_id->compatible) { -pr_err ("could not find a matching SoC family\n" ); -return -ENODEV ; - } - - mbus->soc = of_id->data; - mbus->mbuswins_base =ioremap (mbuswins_phys_base, mbuswins_size);if (!mbus->mbuswins_base)return -ENOMEM ;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,return 0 ; } + +int __init mvebu_mbus_init (const char *soc,phys_addr_t mbuswins_phys_base, +size_t mbuswins_size, +phys_addr_t sdramwins_phys_base, +size_t sdramwins_size) +{ +const struct of_device_id *of_id; + +for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++) +if (!strcmp (of_id->compatible, soc)) +break ; + +if (!of_id->compatible) { +pr_err ("could not find a matching SoC family\n" ); +return -ENODEV ; + } + + mbus_state.soc = of_id->data; + +return mvebu_mbus_common_init (&mbus_state, + mbuswins_phys_base, + mbuswins_size, + sdramwins_phys_base, + sdramwins_size); +}
Signature · 1 line
1.8.1.5
PATCH v9 8/30 bus: mvebu-mbus: Introduce device tree binding
In reply to Ezequiel GarciaThis patch adds the most fundamental device-tree initialization. We only introduce what's required to be able to probe the mvebu-mbus driver from the DT. Follow-up patches will extend the device tree binding, allowing to describe static address decoding windows.
--- drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/mbus.h | 1 + 2 files changed, 50 insertions(+)
drivers/bus/mvebu-mbus.c +49 -0
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base, sdramwins_phys_base, sdramwins_size); } + +#ifdef CONFIG_OF +int __init mvebu_mbus_dt_init (void ) +{ +struct resource mbuswins_res, sdramwins_res; +struct device_node *np, *controller; +const struct of_device_id *of_id; +const __be32 *prop; +int ret; + + np =of_find_matching_node (NULL , of_mvebu_mbus_ids); +if (!np) { +pr_err ("could not find a matching SoC family\n" ); +return -ENODEV ; + } + + of_id =of_match_node (of_mvebu_mbus_ids, np); + mbus_state.soc = of_id->data; + + prop =of_get_property (np,"controller" ,NULL ); +if (!prop) { +pr_err ("required 'controller' property missing\n" ); +return -EINVAL ; + } + + controller =of_find_node_by_phandle (be32_to_cpup (prop)); +if (!controller) { +pr_err ("could not find an 'mbus-controller' node\n" ); +return -ENODEV ; + } + +if (of_address_to_resource (controller,0 , &mbuswins_res)) { +pr_err ("cannot get MBUS register address\n" ); +return -EINVAL ; + } + +if (of_address_to_resource (controller,1 , &sdramwins_res)) { +pr_err ("cannot get SDRAM register address\n" ); +return -EINVAL ; + } + + ret =mvebu_mbus_common_init (&mbus_state, + mbuswins_res.start, +resource_size (&mbuswins_res), + sdramwins_res.start, +resource_size (&sdramwins_res)); +return ret; +} +#endif
include/linux/mbus.h +1 -0
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);int mvebu_mbus_init (const char *soc,phys_addr_t mbus_phys_base,size_t mbus_size,phys_addr_t sdram_phys_base,size_t sdram_size); +int mvebu_mbus_dt_init (void );#endif /* __LINUX_MBUS_H */
Signature · 1 line
1.8.1.5
PATCH v9 9/30 bus: mvebu-mbus: Add static window allocation to the DT binding
In reply to Ezequiel GarciaThis patch adds static window allocation to the device tree binding. Each first-child of the mbus-compatible node, with a suitable 'ranges' property, declaring an address translation, will trigger an address decoding window allocation.
--- drivers/bus/mvebu-mbus.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 126 insertions(+), 1 deletion(-)
drivers/bus/mvebu-mbus.c +126 -1
@@ -902,6 +902,127 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base, }#ifdef CONFIG_OF +/* +* The window IDs in the ranges DT property have the following format: +* - bits 28 to 31: MBus custom field +* - bits 24 to 27: window target ID +* - bits 16 to 23: window attribute ID +* - bits 0 to 15: unused +*/ +#define CUSTOM (id) (((id) & 0xF0000000) >> 24) +#define TARGET (id) (((id) & 0x0F000000) >> 24) +#define ATTR (id) (((id) & 0x00FF0000) >> 16) + +static int __init mbus_dt_setup_win (struct mvebu_mbus_state *mbus, +u32 base,u32 size, +u8 target,u8 attr) +{ +const struct mvebu_mbus_mapping *map = mbus->soc->map; +const char *name; +int i; + +/* Search for a suitable window in the existing mappings */ +for (i =0 ; map[i].name; i++) +if (map[i].target == target && + map[i].attr == (attr & map[i].attrmask)) +break ; + + name = map[i].name; +if (!name) { +pr_err ("window 0x%x:0x%x is unknown, skipping\n" , + target, attr); +return -EINVAL ; + } + +if (!mvebu_mbus_window_conflicts (mbus, base, size, target, attr)) { +pr_err ("cannot add window '%s', conflicts with another window\n" , + name); +return -EBUSY ; + } + +if (mvebu_mbus_alloc_window (mbus, base, size,MVEBU_MBUS_NO_REMAP , + target, attr)) { +pr_err ("cannot add window '%s', too many windows\n" , + name); +return -ENOMEM ; + } +return 0 ; +} + +static int __init +mbus_parse_ranges (struct device_node *node, +int *addr_cells,int *c_addr_cells,int *c_size_cells, +int *cell_count,const __be32 **ranges_start, +const __be32 **ranges_end) +{ +const __be32 *prop; +int ranges_len, tuple_len; + +/* Allow a node with no 'ranges' property */ + *ranges_start =of_get_property (node,"ranges" , &ranges_len); +if (*ranges_start ==NULL ) { + *addr_cells = *c_addr_cells = *c_size_cells = *cell_count =0 ; + *ranges_start = *ranges_end =NULL ; +return 0 ; + } + *ranges_end = *ranges_start + ranges_len /sizeof (__be32); + + *addr_cells =of_n_addr_cells (node); + + prop =of_get_property (node,"#address-cells" ,NULL ); + *c_addr_cells =be32_to_cpup (prop); + + prop =of_get_property (node,"#size-cells" ,NULL ); + *c_size_cells =be32_to_cpup (prop); + + *cell_count = *addr_cells + *c_addr_cells + *c_size_cells; + tuple_len = (*cell_count) *sizeof (__be32); + +if (ranges_len % tuple_len) { +pr_warn ("malformed ranges entry '%s'\n" , node->name); +return -EINVAL ; + } +return 0 ; +} + +static int __init mbus_dt_setup (struct mvebu_mbus_state *mbus, +struct device_node *np) +{ +int addr_cells, c_addr_cells, c_size_cells; +int i, ret, cell_count; +const __be32 *r, *ranges_start, *ranges_end; + + ret =mbus_parse_ranges (np, &addr_cells, &c_addr_cells, + &c_size_cells, &cell_count, + &ranges_start, &ranges_end); +if (ret <0 ) +return ret; + +for (i =0 , r = ranges_start; r < ranges_end; r += cell_count, i++) { +u32 windowid, base, size; +u8 target, attr; + +/* +* An entry with a non-zero custom field do not +* correspond to a static window, so skip it. +*/ + windowid =of_read_number (r,1 ); +if (CUSTOM (windowid)) +continue ; + + target =TARGET (windowid); + attr =ATTR (windowid); + + base =of_read_number (r + c_addr_cells, addr_cells); + size =of_read_number (r + c_addr_cells + addr_cells, + c_size_cells); + ret =mbus_dt_setup_win (mbus, base, size, target, attr); +if (ret <0 ) +return ret; + } +return 0 ; +} +int __init mvebu_mbus_dt_init (void ) {struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1067,10 @@ int __init mvebu_mbus_dt_init(void)resource_size (&mbuswins_res), sdramwins_res.start, resource_size(&sdramwins_res)); - return ret; +if (ret) +return ret; + +/* Setup statically declared windows in the DT */ + return mbus_dt_setup(&mbus_state, np); }#endif
Signature · 1 line
1.8.1.5
PATCH v9 10/30 bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
In reply to Ezequiel GarciaWe add two optional properties to the MBus DT binding, to encode the PCIe memory and IO aperture. This allows such information to be retrieved by -for instance- the pci driver to allocate the MBus decoding windows.
Correspondingly, and in order to retrieve this information, we add two new APIs.
--- drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/mbus.h | 4 ++++ 2 files changed, 53 insertions(+)
drivers/bus/mvebu-mbus.c +49 -0
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {struct dentry *debugfs_root;struct dentry *debugfs_sdram;struct dentry *debugfs_devs; +struct resource pcie_mem_aperture; +struct resource pcie_io_aperture;const struct mvebu_mbus_soc_data *soc;int hw_io_coherency; };
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)return 0 ; } +void mvebu_mbus_get_pcie_mem_aperture (struct resource *res) +{ +if (!res) +return ; + *res = mbus_state.pcie_mem_aperture; +} + +void mvebu_mbus_get_pcie_io_aperture (struct resource *res) +{ +if (!res) +return ; + *res = mbus_state.pcie_io_aperture; +} +static __init int mvebu_mbus_debugfs_init (void ) {struct mvebu_mbus_state *s = &mbus_state;
@@ -1023,6 +1039,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,return 0 ; } +static void __init mvebu_mbus_get_pcie_resources (struct device_node *np, +struct resource *mem, +struct resource *io) +{ +u32 reg[2 ]; +int ret; + +/* +* These are optional, so we clear them and they'll +* be zero if they are missing from the DT. +*/ +memset (mem,0 ,sizeof (struct resource )); +memset (io,0 ,sizeof (struct resource )); + + ret =of_property_read_u32_array (np,"pcie-mem-aperture" , reg,ARRAY_SIZE (reg)); +if (!ret) { + mem->start = reg[0 ]; + mem->end = mem->start + reg[1 ]; + mem->flags =IORESOURCE_MEM ; + } + + ret =of_property_read_u32_array (np,"pcie-io-aperture" , reg,ARRAY_SIZE (reg)); +if (!ret) { + io->start = reg[0 ]; + io->end = io->start + reg[1 ]; + io->flags =IORESOURCE_IO ; + } +} +int __init mvebu_mbus_dt_init (void ) {struct resource mbuswins_res, sdramwins_res;
@@ -1062,6 +1107,10 @@ int __init mvebu_mbus_dt_init(void)return -EINVAL ; } +/* Get optional pcie-{mem,io}-aperture properties */ +mvebu_mbus_get_pcie_resources (np, &mbus_state.pcie_mem_aperture, + &mbus_state.pcie_io_aperture); + ret = mvebu_mbus_common_init(&mbus_state, mbuswins_res.start, resource_size(&mbuswins_res),
include/linux/mbus.h +4 -0
@@ -11,6 +11,8 @@#ifndef __LINUX_MBUS_H#define __LINUX_MBUS_H +struct resource ; +struct mbus_dram_target_info {/*
@@ -59,6 +61,8 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void) }#endif +void mvebu_mbus_get_pcie_mem_aperture (struct resource *res); +void mvebu_mbus_get_pcie_io_aperture (struct resource *res);int mvebu_mbus_add_window_remap_flags (const char *devname,phys_addr_t base,size_t size,phys_addr_t remap,unsigned int flags);
Signature · 1 line
1.8.1.5
PATCH v9 11/30 PCI: mvebu: Adapt to the new device tree layout
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
The new device tree layout encodes the window's target ID and attribute in the PCIe controller node's ranges property. This allows to parse such entries to obtain such information and use the recently introduced MBus API to create the windows, instead of using the current name based scheme.
--- drivers/pci/host/pci-mvebu.c | 113 ++++++++++++++++++++++++++++++++----------- 1 file changed, 84 insertions(+), 29 deletions(-)
drivers/pci/host/pci-mvebu.c +84 -29
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {u32 port;u32 lane;int devfn; +unsigned int mem_target; +unsigned int mem_attr; +unsigned int io_target; +unsigned int io_attr;struct clk *clk;struct mvebu_sw_pci_bridge bridge;struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port) (port->bridge.iolimitupper << 16)) - iobase); -mvebu_mbus_add_window_remap_flags (port->name, port->iowin_base, - port->iowin_size, - iobase, -MVEBU_MBUS_PCI_IO ); +mvebu_mbus_add_window_remap_by_id (port->io_target, port->io_attr, + port->iowin_base, port->iowin_size, + iobase);pci_ioremap_io (iobase, port->iowin_base); }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port) (((port->bridge.memlimit &0xFFF0 ) <<16 ) |0xFFFFF ) - port->memwin_base; -mvebu_mbus_add_window_remap_flags (port->name, port->memwin_base, - port->memwin_size, -MVEBU_MBUS_NO_REMAP , -MVEBU_MBUS_PCI_MEM ); +mvebu_mbus_add_window_by_id (port->mem_target, port->mem_attr, + port->memwin_base, port->memwin_size); }/*
@@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,return devm_request_and_ioremap (&pdev->dev, ®s); } +#define DT_FLAGS_TO_TYPE (flags) (((flags) >> 24) & 0x03) +#define DT_TYPE_IO 0x1 +#define DT_TYPE_MEM32 0x2 +#define DT_CPUADDR_TO_TARGET (cpuaddr) (((cpuaddr) >> 56) & 0xFF) +#define DT_CPUADDR_TO_ATTR (cpuaddr) (((cpuaddr) >> 48) & 0xFF) + +static int mvebu_get_tgt_attr (struct device_node *np,int devfn, +unsigned long type,int *tgt,int *attr) +{ +const int na =3 , ns =2 ; +const __be32 *range; +int rlen, nranges, rangesz, pna, i; + + range =of_get_property (np,"ranges" , &rlen); +if (!range) +return -EINVAL ; + + pna =of_n_addr_cells (np); + rangesz = pna + na + ns; + nranges = rlen /sizeof (__be32) / rangesz; + +for (i =0 ; i < nranges; i++) { +u32 flags =of_read_number (range,1 ); +u32 slot =of_read_number (range,2 ); +u64 cpuaddr =of_read_number (range + na, pna); +unsigned long rtype; + +if (DT_FLAGS_TO_TYPE (flags) ==DT_TYPE_IO ) + rtype =IORESOURCE_IO ; +else if (DT_FLAGS_TO_TYPE (flags) ==DT_TYPE_MEM32 ) + rtype =IORESOURCE_MEM ; + +if (slot ==PCI_SLOT (devfn) && type == rtype) { + *tgt =DT_CPUADDR_TO_TARGET (cpuaddr); + *attr =DT_CPUADDR_TO_ATTR (cpuaddr); +return 0 ; + } + + range += rangesz; + } + +return -ENOENT ; +} +static int __init mvebu_pcie_probe (struct platform_device *pdev) {struct mvebu_pcie *pcie;struct device_node *np = pdev->dev.of_node; -struct of_pci_range range; -struct of_pci_range_parser parser;struct device_node *child;int i, ret;
@@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) pcie->pdev = pdev; -if (of_pci_range_parser_init (&parser, np)) +/* Get the PCIe memory and I/O aperture */ +mvebu_mbus_get_pcie_mem_aperture (&pcie->mem); +if (resource_size (&pcie->mem) ==0 ) { +dev_err (&pdev->dev,"invalid memory aperture size\n" );return -EINVAL ; + } -/* Get the I/O and memory ranges from DT */ -for_each_of_pci_range (&parser, &range) { -unsigned long restype = range.flags &IORESOURCE_TYPE_BITS ; -if (restype ==IORESOURCE_IO ) { -of_pci_range_to_resource (&range, np, &pcie->io); -of_pci_range_to_resource (&range, np, &pcie->realio); - pcie->io.name ="I/O" ; - pcie->realio.start =max_t (resource_size_t, -PCIBIOS_MIN_IO , - range.pci_addr); - pcie->realio.end =min_t (resource_size_t, -IO_SPACE_LIMIT , - range.pci_addr + range.size); - } -if (restype ==IORESOURCE_MEM ) { -of_pci_range_to_resource (&range, np, &pcie->mem); - pcie->mem.name ="MEM" ; - } +mvebu_mbus_get_pcie_io_aperture (&pcie->io); +if (resource_size (&pcie->io) ==0 ) { +dev_err (&pdev->dev,"invalid I/O aperture size\n" ); +return -EINVAL ; } + pcie->realio.flags = pcie->io.flags; + pcie->realio.start =PCIBIOS_MIN_IO ; + pcie->realio.end =min_t (resource_size_t, +IO_SPACE_LIMIT , +resource_size (&pcie->io)); +/* Get the bus range */ ret =of_pci_parse_bus_range (np, &pcie->busn);if (ret) {
@@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)if (port->devfn <0 )continue ; + ret =mvebu_get_tgt_attr (np, port->devfn,IORESOURCE_MEM , + &port->mem_target, &port->mem_attr); +if (ret <0 ) { +dev_err (&pdev->dev,"PCIe%d.%d: cannot get tgt/attr for mem window\n" , + port->port, port->lane); +continue ; + } + + ret =mvebu_get_tgt_attr (np, port->devfn,IORESOURCE_IO , + &port->io_target, &port->io_attr); +if (ret <0 ) { +dev_err (&pdev->dev,"PCIe%d.%d: cannot get tgt/attr for io window\n" , + port->port, port->lane); +continue ; + } + port->base =mvebu_pcie_map_registers (pdev, child, port);if (!port->base) { dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
Signature · 1 line
1.8.1.5
PATCH v9 12/30 PCI: mvebu: Check valid base address before port setup
In reply to Ezequiel GarciaThis driver does not fail to probe when it cannot obtain a port base address. Therefore, add a check for NULL base address before setting up the port, which prevents a kernel panic in such cases.
--- drivers/pci/host/pci-mvebu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pci/host/pci-mvebu.c +2 -0
@@ -662,6 +662,8 @@ static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)for (i =0 ; i < pcie->nports; i++) {struct mvebu_pcie_port *port = &pcie->ports[i]; +if (!port->base) +continue ;mvebu_pcie_setup_hw (port); }
Signature · 1 line
1.8.1.5
PATCH v9 13/30 bus: mvebu-mbus: Remove the no longer used name-based API
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
Now that every user of the deprecated name-based API has been converted to using the ID-based API, let's remove the former one.
--- drivers/bus/mvebu-mbus.c | 38 -------------------------------------- include/linux/mbus.h | 5 ----- 2 files changed, 43 deletions(-)
drivers/bus/mvebu-mbus.c +0 -38
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,return mvebu_mbus_alloc_window (s, base, size, remap, target, attribute); } -int mvebu_mbus_add_window_remap_flags (const char *devname,phys_addr_t base, -size_t size,phys_addr_t remap, -unsigned int flags) -{ -struct mvebu_mbus_state *s = &mbus_state; -u8 target, attr; -int i; - -if (!s->soc->map) -return -ENODEV ; - -for (i =0 ; s->soc->map[i].name; i++) -if (!strcmp (s->soc->map[i].name, devname)) -break ; - -if (!s->soc->map[i].name) { -pr_err ("unknown device '%s'\n" , devname); -return -ENODEV ; - } - - target = s->soc->map[i].target; - attr = s->soc->map[i].attr; - -if (flags ==MVEBU_MBUS_PCI_MEM ) - attr |=0x8 ; -else if (flags ==MVEBU_MBUS_PCI_WA ) - attr |=0x28 ; - -return mvebu_mbus_add_window_remap_by_id (target, attr, base, - size, remap); -} - -int mvebu_mbus_add_window (const char *devname,phys_addr_t base,size_t size) -{ -return mvebu_mbus_add_window_remap_flags (devname, base, size, -MVEBU_MBUS_NO_REMAP ,0 ); -} -int mvebu_mbus_add_window_by_id (unsigned int target,unsigned int attribute,phys_addr_t base,size_t size) {
include/linux/mbus.h +0 -5
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)void mvebu_mbus_get_pcie_mem_aperture (struct resource *res);void mvebu_mbus_get_pcie_io_aperture (struct resource *res); -int mvebu_mbus_add_window_remap_flags (const char *devname,phys_addr_t base, -size_t size,phys_addr_t remap, -unsigned int flags);int mvebu_mbus_add_window_remap_by_id (unsigned int target,unsigned int attribute,phys_addr_t base,size_t size,phys_addr_t remap); -int mvebu_mbus_add_window (const char *devname,phys_addr_t base, -size_t size);int mvebu_mbus_add_window_by_id (unsigned int target,unsigned int attribute,phys_addr_t base,size_t size);int mvebu_mbus_del_window (phys_addr_t base,size_t size);
Signature · 1 line
1.8.1.5
PATCH v9 14/30 bus: mvebu-mbus: Remove name -> target, attribute mapping tables
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
This tables were used together with the name-based MBus window creation API. Since that's has been removed, we can also remove the tables.
--- drivers/bus/mvebu-mbus.c | 150 +++-------------------------------------------- 1 file changed, 7 insertions(+), 143 deletions(-)
drivers/bus/mvebu-mbus.c +7 -143
@@ -97,33 +97,6 @@#define DOVE_DDR_BASE_CS_OFF (n) ((n) << 4) -struct mvebu_mbus_mapping { -const char *name; -u8 target; -u8 attr; -u8 attrmask; -}; - -/* -* Masks used for the 'attrmask' field of mvebu_mbus_mapping. They -* allow to get the real attribute value, discarding the special bits -* used to select a PCI MEM region or a PCI WA region. This allows the -* debugfs code to reverse-match the name of a device from its -* target/attr values. -* -* For all devices except PCI, all bits of 'attr' must be -* considered. For most SoCs, only bit 3 should be ignored (it allows -* to select between PCI MEM and PCI I/O). On Orion5x however, there -* is the special bit 5 to select a PCI WA region. -*/ -#define MAPDEF_NOMASK 0xff -#define MAPDEF_PCIMASK 0xf7 -#define MAPDEF_ORIONPCIMASK 0xd7 - -/* Macro used to define one mvebu_mbus_mapping entry */ -#define MAPDEF (__n, __t, __a, __m) \ - { .name = __n, .target = __t, .attr = __a, .attrmask = __m } -struct mvebu_mbus_state ;struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {void (*setup_cpu_target)(struct mvebu_mbus_state *s);int (*show_cpu_target)(struct mvebu_mbus_state *s,struct seq_file *seq,void *v); -const struct mvebu_mbus_mapping *map; };struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)u64 wbase, wremap;u32 wsize;u8 wtarget, wattr; -int enabled, i; -const char *name; +int enabled; mvebu_mbus_read_window(mbus, win, &enabled, &wbase, &wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)continue ; } - -for (i =0 ; mbus->soc->map[i].name; i++) -if (mbus->soc->map[i].target == wtarget && - mbus->soc->map[i].attr == - (wattr & mbus->soc->map[i].attrmask)) -break ; - - name = mbus->soc->map[i].name ?:"unknown" ; - -seq_printf (seq,"[%02d] %016llx - %016llx : %s" , +seq_printf (seq,"[%02d] %016llx - %016llx : %04x:%04x" , win, (unsigned long long )wbase, - (unsigned long long )(wbase + wsize), name); + (unsigned long long )(wbase + wsize), wtarget, wattr);if (win < mbus->soc->num_remappable_wins) { seq_printf(seq, " (remap %016llx)\n",
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus) mvebu_mbus_dram_info.num_cs = cs; } -static const struct mvebu_mbus_mapping armada_370_map[] = { -MAPDEF ("bootrom" ,1 ,0xe0 ,MAPDEF_NOMASK ), -MAPDEF ("devbus-boot" ,1 ,0x2f ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs0" ,1 ,0x3e ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs1" ,1 ,0x3d ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs2" ,1 ,0x3b ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs3" ,1 ,0x37 ,MAPDEF_NOMASK ), -MAPDEF ("pcie0.0" ,4 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.0" ,8 ,0xe0 ,MAPDEF_PCIMASK ), - {}, -}; -static const struct mvebu_mbus_soc_data armada_370_mbus_data = { .num_wins =20 , .num_remappable_wins =8 , .win_cfg_offset = armada_370_xp_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = armada_370_map, -}; - -static const struct mvebu_mbus_mapping armada_xp_map[] = { -MAPDEF ("bootrom" ,1 ,0x1d ,MAPDEF_NOMASK ), -MAPDEF ("devbus-boot" ,1 ,0x2f ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs0" ,1 ,0x3e ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs1" ,1 ,0x3d ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs2" ,1 ,0x3b ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs3" ,1 ,0x37 ,MAPDEF_NOMASK ), -MAPDEF ("pcie0.0" ,4 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.1" ,4 ,0xd0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.2" ,4 ,0xb0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.3" ,4 ,0x70 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.0" ,8 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.1" ,8 ,0xd0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.2" ,8 ,0xb0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.3" ,8 ,0x70 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie2.0" ,4 ,0xf0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie3.0" ,8 ,0xf0 ,MAPDEF_PCIMASK ), - {}, };static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -625,15 +554,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = { .win_cfg_offset = armada_370_xp_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = armada_xp_map, -}; - -static const struct mvebu_mbus_mapping kirkwood_map[] = { -MAPDEF ("pcie0.0" ,4 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.0" ,4 ,0xd0 ,MAPDEF_PCIMASK ), -MAPDEF ("sram" ,3 ,0x01 ,MAPDEF_NOMASK ), -MAPDEF ("nand" ,1 ,0x2f ,MAPDEF_NOMASK ), - {}, };static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -642,16 +562,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = { .win_cfg_offset = orion_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = kirkwood_map, -}; - -static const struct mvebu_mbus_mapping dove_map[] = { -MAPDEF ("pcie0.0" ,0x4 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.0" ,0x8 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("cesa" ,0x3 ,0x01 ,MAPDEF_NOMASK ), -MAPDEF ("bootrom" ,0x1 ,0xfd ,MAPDEF_NOMASK ), -MAPDEF ("scratchpad" ,0xd ,0x0 ,MAPDEF_NOMASK ), - {}, };static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -660,18 +570,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = { .win_cfg_offset = orion_mbus_win_offset, .setup_cpu_target = mvebu_mbus_dove_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_dove, - .map = dove_map, -}; - -static const struct mvebu_mbus_mapping orion5x_map[] = { -MAPDEF ("pcie0.0" ,4 ,0x51 ,MAPDEF_ORIONPCIMASK ), -MAPDEF ("pci0.0" ,3 ,0x51 ,MAPDEF_ORIONPCIMASK ), -MAPDEF ("devbus-boot" ,1 ,0x0f ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs0" ,1 ,0x1e ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs1" ,1 ,0x1d ,MAPDEF_NOMASK ), -MAPDEF ("devbus-cs2" ,1 ,0x1b ,MAPDEF_NOMASK ), -MAPDEF ("sram" ,0 ,0x00 ,MAPDEF_NOMASK ), - {}, };/*
@@ -684,7 +582,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = { .win_cfg_offset = orion_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = orion5x_map, };static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -693,21 +590,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = { .win_cfg_offset = orion_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = orion5x_map, -}; - -static const struct mvebu_mbus_mapping mv78xx0_map[] = { -MAPDEF ("pcie0.0" ,4 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.1" ,4 ,0xd0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.2" ,4 ,0xb0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie0.3" ,4 ,0x70 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.0" ,8 ,0xe0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.1" ,8 ,0xd0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.2" ,8 ,0xb0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie1.3" ,8 ,0x70 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie2.0" ,4 ,0xf0 ,MAPDEF_PCIMASK ), -MAPDEF ("pcie3.0" ,8 ,0xf0 ,MAPDEF_PCIMASK ), - {}, };static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -716,7 +598,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = { .win_cfg_offset = mv78xx0_mbus_win_offset, .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, .show_cpu_target = mvebu_sdram_debug_show_orion, - .map = mv78xx0_map, };/*
@@ -895,33 +776,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus, u32 base, u32 size, u8 target, u8 attr) { - const struct mvebu_mbus_mapping *map = mbus->soc->map; -const char *name; -int i; - -/* Search for a suitable window in the existing mappings */ -for (i =0 ; map[i].name; i++) -if (map[i].target == target && - map[i].attr == (attr & map[i].attrmask)) -break ; - - name = map[i].name; -if (!name) { -pr_err ("window 0x%x:0x%x is unknown, skipping\n" , - target, attr); -return -EINVAL ; - } - if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) { -pr_err ("cannot add window '%s', conflicts with another window\n" , - name); + pr_err("cannot add window '%04x:%04x', conflicts with another window\n", + target, attr);return -EBUSY ; }if (mvebu_mbus_alloc_window (mbus, base, size,MVEBU_MBUS_NO_REMAP , target, attr)) { -pr_err ("cannot add window '%s', too many windows\n" , - name); +pr_err ("cannot add window '%04x:%04x', too many windows\n" , + target, attr);return -ENOMEM ; }return 0 ;
Signature · 1 line
1.8.1.5
PATCH v9 15/30 bus: mvebu-mbus: Update main description
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
After replacing the MBus name-based by the new ID-based API let's fix the general description of the driver at the beginning of the file.
--- drivers/bus/mvebu-mbus.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
drivers/bus/mvebu-mbus.c +3 -7
@@ -35,13 +35,9 @@* * - Provides an API for platform code or device drivers to * dynamically add or remove address decoding windows for the CPU -> -* device accesses. This API is mvebu_mbus_add_window(), -* mvebu_mbus_add_window_remap_flags() and -* mvebu_mbus_del_window(). Since the (target, attribute) values -* differ from one SoC family to another, the API uses a 'const char -* *' string to identify devices, and this driver is responsible for -* knowing the mapping between the name of a device and its -* corresponding (target, attribute) in the current SoC family. +* device accesses. This API is mvebu_mbus_add_window_by_id(), +* mvebu_mbus_add_window_remap_by_id() and +* mvebu_mbus_del_window(). * * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to * see the list of CPU -> SDRAM windows and their configuration
Signature · 1 line
1.8.1.5
PATCH v9 16/30 bus: mvebu-mbus: Factorize Armada 370/XP data structures
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
These structures were only different in the mapping tables. Now that those tables have been removed, it doesn't make any sense to keep different structures.
--- drivers/bus/mvebu-mbus.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-)
drivers/bus/mvebu-mbus.c +3 -11
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus) mvebu_mbus_dram_info.num_cs = cs; } -static const struct mvebu_mbus_soc_data armada_370_mbus_data = { - .num_wins =20 , - .num_remappable_wins =8 , - .win_cfg_offset = armada_370_xp_mbus_win_offset, - .setup_cpu_target = mvebu_mbus_default_setup_cpu_target, - .show_cpu_target = mvebu_sdram_debug_show_orion, -}; - -static const struct mvebu_mbus_soc_data armada_xp_mbus_data = { +static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = { .num_wins =20 , .num_remappable_wins =8 , .win_cfg_offset = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {*/ static const struct of_device_id of_mvebu_mbus_ids[] = { { .compatible ="marvell,armada370-mbus" , - .data = &armada_370_mbus_data, }, + .data = &armada_370_xp_mbus_data, }, { .compatible ="marvell,armadaxp-mbus" , - .data = &armada_xp_mbus_data, }, + .data = &armada_370_xp_mbus_data, }, { .compatible ="marvell,kirkwood-mbus" , .data = &kirkwood_mbus_data, }, { .compatible ="marvell,dove-mbus" ,
Signature · 1 line
1.8.1.5
PATCH v9 17/30 ARM: mvebu: Remove the harcoded BootROM window allocation
In reply to Ezequiel GarciaThe address decoding window to access the BootROM should not be allocated programatically, but instead declared in the device tree.
--- arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-)
arch/arm/mach-mvebu/platsmp.c +24 -1
@@ -21,6 +21,7 @@#include <linux/smp.h> #include <linux/clk.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/mbus.h> #include <asm/cacheflush.h> #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@#include "pmsu.h" #include "coherency.h" +#define AXP_BOOTROM_BASE 0xfff00000 +#define AXP_BOOTROM_SIZE 0x100000 +void __init set_secondary_cpus_clock (void ) {int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)void __init armada_xp_smp_prepare_cpus (unsigned int max_cpus) { +struct device_node *node; +struct resource res; +int err; +set_secondary_cpus_clock ();flush_cache_all ();set_cpu_coherent (cpu_logical_map (smp_processor_id ()),0 ); -mvebu_mbus_add_window ("bootrom" ,0xfff00000 ,SZ_1M ); + +/* +* In order to boot the secondary CPUs we need to ensure +* the bootROM is mapped at the correct address. +*/ + node =of_find_compatible_node (NULL ,NULL ,"marvell,bootrom" ); +if (!node) +panic ("Cannot find 'marvell,bootrom' compatible node" ); + + err =of_address_to_resource (node,0 , &res); +if (err <0 ) +panic ("Cannot get 'bootrom' node address" ); + +if (res.start !=AXP_BOOTROM_BASE || +resource_size (&res) !=AXP_BOOTROM_SIZE ) +panic ("The address for the BootROM is incorrect" ); }struct smp_operations armada_xp_smp_ops__initdata = {
Signature · 1 line
1.8.1.5
PATCH v9 18/30 ARM: mvebu: Initialize MBus using the DT binding
In reply to Ezequiel GarciaNow that the mbus device tree binding has been introduced, we can switch over to it.
Also, and since the initialization of the mbus driver is quite fundamental for the system to work properly, this patch adds a BUG() in case mbus fails to initialize.
--- arch/arm/mach-mvebu/armada-370-xp.c | 34 +--------------------------------- 1 file changed, 1 insertion(+), 33 deletions(-)
arch/arm/mach-mvebu/armada-370-xp.c +1 -33
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)debug_ll_io_init (); } -/* -* This initialization will be replaced by a DT-based -* initialization once the mvebu-mbus driver gains DT support. -*/ - -#define ARMADA_370_XP_MBUS_WINS_OFFS 0x20000 -#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100 -#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180 -#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20 - -static void __init armada_370_xp_mbus_init (void ) -{ -char *mbus_soc_name; -struct device_node *dn; -const __be32 mbus_wins_offs =cpu_to_be32 (ARMADA_370_XP_MBUS_WINS_OFFS ); -const __be32 sdram_wins_offs =cpu_to_be32 (ARMADA_370_XP_SDRAM_WINS_OFFS ); - -if (of_machine_is_compatible ("marvell,armada370" )) - mbus_soc_name ="marvell,armada370-mbus" ; -else - mbus_soc_name ="marvell,armadaxp-mbus" ; - - dn =of_find_node_by_name (NULL ,"internal-regs" ); -BUG_ON (!dn); - -mvebu_mbus_init (mbus_soc_name, -of_translate_address (dn, &mbus_wins_offs), -ARMADA_370_XP_MBUS_WINS_SIZE , -of_translate_address (dn, &sdram_wins_offs), -ARMADA_370_XP_SDRAM_WINS_SIZE ); -} -static void __init armada_370_xp_timer_and_clk_init (void ) {of_clk_init (NULL );armada_370_xp_timer_init ();coherency_init (); -armada_370_xp_mbus_init (); +BUG_ON (mvebu_mbus_dt_init ());#ifdef CONFIG_CACHE_L2X0 l2x0_of_init (0 , ~0UL );#endif
Signature · 1 line
1.8.1.5
PATCH v9 19/30 ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
In reply to Ezequiel Garcia--- arch/arm/boot/dts/armada-370-db.dts | 2 +- arch/arm/boot/dts/armada-370-mirabox.dts | 2 +- arch/arm/boot/dts/armada-370-rd.dts | 2 +- arch/arm/boot/dts/armada-370.dtsi | 2 +- arch/arm/boot/dts/armada-xp-db.dts | 2 +- arch/arm/boot/dts/armada-xp-gp.dts | 2 +- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +- arch/arm/boot/dts/armada-xp.dtsi | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-)
arch/arm/boot/dts/armada-370-db.dts +1 -1
@@ -14,7 +14,7 @@ */ /dts-v1/; -/include/ "armada-370.dtsi" +#include "armada-370.dtsi" / { model = "Marvell Armada 370 Evaluation Board";
arch/arm/boot/dts/armada-370-mirabox.dts +1 -1
@@ -9,7 +9,7 @@ */ /dts-v1/; -/include/ "armada-370.dtsi" +#include "armada-370.dtsi" / { model = "Globalscale Mirabox";
arch/arm/boot/dts/armada-370-rd.dts +1 -1
@@ -12,7 +12,7 @@ */ /dts-v1/; -/include/ "armada-370.dtsi" +#include "armada-370.dtsi" / { model = "Marvell Armada 370 Reference Design";
arch/arm/boot/dts/armada-370.dtsi +1 -1
@@ -15,7 +15,7 @@ * common to all Armada SoCs. */ -/include/ "armada-370-xp.dtsi" +#include "armada-370-xp.dtsi" /include/ "skeleton.dtsi" / {
arch/arm/boot/dts/armada-xp-db.dts +1 -1
@@ -14,7 +14,7 @@ */ /dts-v1/; -/include/ "armada-xp-mv78460.dtsi" +#include "armada-xp-mv78460.dtsi" / { model = "Marvell Armada XP Evaluation Board";
arch/arm/boot/dts/armada-xp-gp.dts +1 -1
@@ -14,7 +14,7 @@ */ /dts-v1/; -/include/ "armada-xp-mv78460.dtsi" +#include "armada-xp-mv78460.dtsi" / { model = "Marvell Armada XP Development Board DB-MV784MP-GP";
arch/arm/boot/dts/armada-xp-mv78260.dtsi +1 -1
@@ -13,7 +13,7 @@ * common to all Armada XP SoCs. */ -/include/ "armada-xp.dtsi" +#include "armada-xp.dtsi" / { model = "Marvell Armada XP MV78260 SoC";
arch/arm/boot/dts/armada-xp-mv78460.dtsi +1 -1
@@ -13,7 +13,7 @@ * common to all Armada XP SoCs. */ -/include/ "armada-xp.dtsi" +#include "armada-xp.dtsi" / { model = "Marvell Armada XP MV78460 SoC";
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +1 -1
@@ -11,7 +11,7 @@ */ /dts-v1/; -/include/ "armada-xp-mv78260.dtsi" +#include "armada-xp-mv78260.dtsi" / { model = "PlatHome OpenBlocks AX3-4 board";
arch/arm/boot/dts/armada-xp.dtsi +1 -1
@@ -16,7 +16,7 @@ * common to all Armada SoCs. */ -/include/ "armada-370-xp.dtsi" +#include "armada-370-xp.dtsi" / { model = "Marvell Armada XP family SoC";
Signature · 1 line
1.8.1.5
PATCH v9 20/30 ARM: mvebu: Add MBus to Armada 370/XP device tree
In reply to Ezequiel GarciaThe Armada 370/XP SoC family has a completely configurable address space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the 'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node, this makes all of them sit behind the mbus, thus describing the hardware accurately.
A translation entry has been added for the internal-regs mapping. This can't be done in the common armada-370-xp.dtsi because A370 and AXP have different addressing width.
--- arch/arm/boot/dts/armada-370-db.dts | 2 ++ arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++ arch/arm/boot/dts/armada-370-rd.dts | 2 ++ arch/arm/boot/dts/armada-370-xp.dtsi | 15 ++++++++++----- arch/arm/boot/dts/armada-370.dtsi | 4 ++-- arch/arm/boot/dts/armada-xp-db.dts | 4 +--- arch/arm/boot/dts/armada-xp-gp.dts | 4 +--- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 4 +--- arch/arm/boot/dts/armada-xp.dtsi | 2 ++ 9 files changed, 23 insertions(+), 16 deletions(-)
arch/arm/boot/dts/armada-370-db.dts +2 -0
@@ -30,6 +30,8 @@ }; soc { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + internal-regs { serial at 12000 { clock-frequency = <200000000>;
arch/arm/boot/dts/armada-370-mirabox.dts +2 -0
@@ -25,6 +25,8 @@ }; soc { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + internal-regs { serial at 12000 { clock-frequency = <200000000>;
arch/arm/boot/dts/armada-370-rd.dts +2 -0
@@ -28,6 +28,8 @@ }; soc { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + internal-regs { serial at 12000 { clock-frequency = <200000000>;
arch/arm/boot/dts/armada-370-xp.dtsi +10 -5
@@ -18,6 +18,8 @@ /include/ "skeleton64.dtsi" +#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16)) + / { model = "Marvell Armada 370 and XP SoC"; compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@ }; soc { - #address-cells = <1>; + #address-cells = <2>; #size-cells = <1>; - compatible = "simple-bus"; + controller = <&mbusc>; interrupt-parent = <&mpic>; - ranges = <0 0 0xd0000000 0x0100000 /* internal registers */ - 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>; internal-regs { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; - ranges; + ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; + + mbusc: mbus-controller at 20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>; + }; mpic: interrupt-controller at 20000 { compatible = "marvell,mpic";
arch/arm/boot/dts/armada-370.dtsi +2 -2
@@ -29,8 +29,8 @@ }; soc { - ranges = <0 0xd0000000 0x0100000 /* internal registers */ - 0xe0000000 0xe0000000 0x8100000 /* PCIe */>; + compatible = "marvell,armada370-mbus", "simple-bus"; + internal-regs { system-controller at 18200 { compatible = "marvell,armada-370-xp-system-controller";
arch/arm/boot/dts/armada-xp-db.dts +1 -3
@@ -30,9 +30,7 @@ }; soc { - ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ - 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ - 0xf0000000 0 0xf0000000 0x1000000>; /* Device Bus, NOR 16MiB */ + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp-gp.dts +1 -3
@@ -39,9 +39,7 @@ }; soc { - ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ - 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ - 0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB */>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +1 -3
@@ -27,9 +27,7 @@ }; soc { - ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ - 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ - 0xf0000000 0 0xf0000000 0x8000000 /* Device Bus, NOR 128MiB */>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp.dtsi +2 -0
@@ -27,6 +27,8 @@ }; soc { + compatible = "marvell,armadaxp-mbus", "simple-bus"; + internal-regs { L2: l2-cache { compatible = "marvell,aurora-system-cache";
Signature · 1 line
1.8.1.5
PATCH v9 21/30 ARM: mvebu: Add BootROM to Armada 370/XP device tree
In reply to Ezequiel GarciaIn order to access the SoC BootROM, we need to declare a mapping (through a ranges property). The mbus driver will use this property to allocate a suitable address decoding window.
--- arch/arm/boot/dts/armada-370-db.dts | 3 ++- arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++- arch/arm/boot/dts/armada-370-rd.dts | 3 ++- arch/arm/boot/dts/armada-370.dtsi | 5 +++++ arch/arm/boot/dts/armada-xp-db.dts | 3 ++- arch/arm/boot/dts/armada-xp-gp.dts | 3 ++- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++- arch/arm/boot/dts/armada-xp.dtsi | 5 +++++ 8 files changed, 22 insertions(+), 6 deletions(-)
arch/arm/boot/dts/armada-370-db.dts +2 -1
@@ -30,7 +30,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-370-mirabox.dts +2 -1
@@ -25,7 +25,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-370-rd.dts +2 -1
@@ -28,7 +28,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-370.dtsi +5 -0
@@ -31,6 +31,11 @@ soc { compatible = "marvell,armada370-mbus", "simple-bus"; + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>; + }; + internal-regs { system-controller at 18200 { compatible = "marvell,armada-370-xp-system-controller";
arch/arm/boot/dts/armada-xp-db.dts +2 -1
@@ -30,7 +30,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp-gp.dts +2 -1
@@ -39,7 +39,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +2 -1
@@ -27,7 +27,8 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp.dtsi +5 -0
@@ -29,6 +29,11 @@ soc { compatible = "marvell,armadaxp-mbus", "simple-bus"; + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>; + }; + internal-regs { L2: l2-cache { compatible = "marvell,aurora-system-cache";
Signature · 1 line
1.8.1.5
PATCH v9 22/30 ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
In reply to Ezequiel GarciaNow that mbus has been added to the device tree, it's possible to move the DeviceBus out of internal registers, placing it directly below the mbus. This is a more accurate representation of the hardware.
--- arch/arm/boot/dts/armada-370-xp.dtsi | 94 +++++++++++++----------- arch/arm/boot/dts/armada-xp-db.dts | 59 +++++++-------- arch/arm/boot/dts/armada-xp-gp.dts | 60 +++++++-------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++-------- 4 files changed, 140 insertions(+), 138 deletions(-)
arch/arm/boot/dts/armada-370-xp.dtsi +50 -44
@@ -45,6 +45,56 @@ controller = <&mbusc>; interrupt-parent = <&mpic>; + devbus-bootcs { + compatible = "marvell,mvebu-devbus"; + reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>; + ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + + devbus-cs0 { + compatible = "marvell,mvebu-devbus"; + reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>; + ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + + devbus-cs1 { + compatible = "marvell,mvebu-devbus"; + reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>; + ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + + devbus-cs2 { + compatible = "marvell,mvebu-devbus"; + reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>; + ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + + devbus-cs3 { + compatible = "marvell,mvebu-devbus"; + reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>; + ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&coreclk 0>; + status = "disabled"; + }; + internal-regs { compatible = "simple-bus"; #address-cells = <1>;
@@ -200,50 +250,6 @@ status = "disabled"; }; - devbus-bootcs at 10400 { - compatible = "marvell,mvebu-devbus"; - reg = <0x10400 0x8>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&coreclk 0>; - status = "disabled"; - }; - - devbus-cs0 at 10408 { - compatible = "marvell,mvebu-devbus"; - reg = <0x10408 0x8>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&coreclk 0>; - status = "disabled"; - }; - - devbus-cs1 at 10410 { - compatible = "marvell,mvebu-devbus"; - reg = <0x10410 0x8>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&coreclk 0>; - status = "disabled"; - }; - - devbus-cs2 at 10418 { - compatible = "marvell,mvebu-devbus"; - reg = <0x10418 0x8>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&coreclk 0>; - status = "disabled"; - }; - - devbus-cs3 at 10420 { - compatible = "marvell,mvebu-devbus"; - reg = <0x10420 0x8>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&coreclk 0>; - status = "disabled"; - }; }; }; };
arch/arm/boot/dts/armada-xp-db.dts +30 -29
71 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-gp.dts +30 -30
72 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +30 -35
77 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH v9 23/30 ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
In reply to Ezequiel GarciaNow that mbus has been added to the device tree, it's possible to move the PCIe nodes out of internal registers, placing it directly below the mbus. This is a more accurate representation of the hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to encode the window target ID and attribute. Since this depends on the PCIe port, we split the ranges translation entries, to correspond to each MBus window.
--- arch/arm/boot/dts/armada-370-mirabox.dts | 32 +- arch/arm/boot/dts/armada-370-xp.dtsi | 2 + arch/arm/boot/dts/armada-370.dtsi | 101 +++--- arch/arm/boot/dts/armada-xp-db.dts | 67 ++-- arch/arm/boot/dts/armada-xp-gp.dts | 42 +-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++++++------ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 261 ++++++++------- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 409 ++++++++++++----------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 18 +- 9 files changed, 612 insertions(+), 542 deletions(-)
arch/arm/boot/dts/armada-370-mirabox.dts +16 -16
@@ -28,6 +28,22 @@ ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; + pcie-controller { + status = "okay"; + + /* Internal mini-PCIe connector */ + pcie at 1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + + /* Connected on the PCB to a USB 3.0 XHCI controller */ + pcie at 2,0 { + /* Port 1, Lane 0 */ + status = "okay"; + }; + }; + internal-regs { serial at 12000 { clock-frequency = <200000000>;
@@ -123,22 +139,6 @@ reg = <0x25>; }; }; - - pcie-controller { - status = "okay"; - - /* Internal mini-PCIe connector */ - pcie at 1,0 { - /* Port 0, Lane 0 */ - status = "okay"; - }; - - /* Connected on the PCB to a USB 3.0 XHCI controller */ - pcie at 2,0 { - /* Port 1, Lane 0 */ - status = "okay"; - }; - }; }; }; };
arch/arm/boot/dts/armada-370-xp.dtsi +2 -0
@@ -44,6 +44,8 @@ #size-cells = <1>; controller = <&mbusc>; interrupt-parent = <&mpic>; + pcie-mem-aperture = <0xe0000000 0x8000000>; + pcie-io-aperture = <0xe8000000 0x100000>; devbus-bootcs { compatible = "marvell,mvebu-devbus";
arch/arm/boot/dts/armada-370.dtsi +53 -48
113 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-db.dts +33 -34
79 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-gp.dts +21 -21
54 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78230.dtsi +118 -104
234 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78260.dtsi +139 -122
273 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78460.dtsi +221 -188
421 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +9 -9
@@ -59,6 +59,15 @@ }; }; + pcie-controller { + status = "okay"; + /* Internal mini-PCIe connector */ + pcie at 1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + }; + internal-regs { serial at 12000 { clock-frequency = <250000000>;
@@ -176,15 +185,6 @@ usb at 51000 { status = "okay"; }; - - pcie-controller { - status = "okay"; - /* Internal mini-PCIe connector */ - pcie at 1,0 { - /* Port 0, Lane 0 */ - status = "okay"; - }; - }; }; }; };
Signature · 1 line
1.8.1.5
PATCH v9 24/30 ARM: kirkwood: Split DT and legacy MBus initialization
In reply to Ezequiel GarciaThis commit replaces the legacy MBus initialization with the new DT-based in Kirkwood. For boards that are not yet converted to DT, we keep the legacy initialization.
--- arch/arm/mach-kirkwood/board-dt.c | 1 + arch/arm/mach-kirkwood/common.c | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-)
arch/arm/mach-kirkwood/board-dt.c +1 -0
@@ -87,6 +87,7 @@ static void __init kirkwood_dt_init(void)*/ writel (readl (CPU_CONFIG ) & ~CPU_CONFIG_ERROR_PROP ,CPU_CONFIG ); +BUG_ON (mvebu_mbus_dt_init ());kirkwood_setup_wins ();kirkwood_l2_init ();
arch/arm/mach-kirkwood/common.c +4 -4
@@ -534,10 +534,6 @@ void __init kirkwood_cpuidle_init(void)void __init kirkwood_init_early (void ) {orion_time_set_base (TIMER_VIRT_BASE ); - -mvebu_mbus_init ("marvell,kirkwood-mbus" , -BRIDGE_WINS_BASE ,BRIDGE_WINS_SZ , -DDR_WINDOW_CPU_BASE ,DDR_WINDOW_CPU_SZ ); }int kirkwood_tclk;
@@ -713,6 +709,10 @@ void __init kirkwood_init(void)*/ writel (readl (CPU_CONFIG ) & ~CPU_CONFIG_ERROR_PROP ,CPU_CONFIG ); +BUG_ON (mvebu_mbus_init ("marvell,kirkwood-mbus" , +BRIDGE_WINS_BASE ,BRIDGE_WINS_SZ , +DDR_WINDOW_CPU_BASE ,DDR_WINDOW_CPU_SZ )); +kirkwood_setup_wins ();kirkwood_l2_init ();
Signature · 1 line
1.8.1.5
PATCH v9 25/30 ARM: kirkwood: Use the preprocessor on device tree files
In reply to Ezequiel Garcia--- arch/arm/boot/dts/kirkwood-cloudbox.dts | 4 ++-- arch/arm/boot/dts/kirkwood-db-88f6281.dts | 4 ++-- arch/arm/boot/dts/kirkwood-db-88f6282.dts | 4 ++-- arch/arm/boot/dts/kirkwood-db.dtsi | 2 +- arch/arm/boot/dts/kirkwood-dns320.dts | 2 +- arch/arm/boot/dts/kirkwood-dns325.dts | 2 +- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 4 ++-- arch/arm/boot/dts/kirkwood-dockstar.dts | 4 ++-- arch/arm/boot/dts/kirkwood-dreamplug.dts | 4 ++-- arch/arm/boot/dts/kirkwood-goflexnet.dts | 4 ++-- arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts | 4 ++-- arch/arm/boot/dts/kirkwood-ib62x0.dts | 4 ++-- arch/arm/boot/dts/kirkwood-iconnect.dts | 4 ++-- arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 4 ++-- arch/arm/boot/dts/kirkwood-is2.dts | 2 +- arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 4 ++-- arch/arm/boot/dts/kirkwood-lschlv2.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxhl.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxl.dtsi | 4 ++-- arch/arm/boot/dts/kirkwood-mplcec4.dts | 4 ++-- arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 4 ++-- arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 4 ++-- arch/arm/boot/dts/kirkwood-ns2.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2lite.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2max.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2mini.dts | 2 +- arch/arm/boot/dts/kirkwood-nsa310.dts | 4 ++-- arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 4 ++-- arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 4 ++-- arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 2 +- arch/arm/boot/dts/kirkwood-sheevaplug.dts | 2 +- arch/arm/boot/dts/kirkwood-topkick.dts | 4 ++-- arch/arm/boot/dts/kirkwood-ts219-6281.dts | 6 +++--- arch/arm/boot/dts/kirkwood-ts219-6282.dts | 6 +++--- 34 files changed, 58 insertions(+), 58 deletions(-)
arch/arm/boot/dts/kirkwood-cloudbox.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "LaCie CloudBox";
arch/arm/boot/dts/kirkwood-db-88f6281.dts +2 -2
@@ -11,8 +11,8 @@ /dts-v1/; -/include/ "kirkwood-db.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood-db.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Marvell DB-88F6281-BP Development Board";
arch/arm/boot/dts/kirkwood-db-88f6282.dts +2 -2
@@ -11,8 +11,8 @@ /dts-v1/; -/include/ "kirkwood-db.dtsi" -/include/ "kirkwood-6282.dtsi" +#include "kirkwood-db.dtsi" +#include "kirkwood-6282.dtsi" / { model = "Marvell DB-88F6282-BP Development Board";
arch/arm/boot/dts/kirkwood-db.dtsi +1 -1
@@ -12,7 +12,7 @@ * and 6282 variants of the Marvell Kirkwood Development Board. */ -/include/ "kirkwood.dtsi" +#include "kirkwood.dtsi" / { memory {
arch/arm/boot/dts/kirkwood-dns320.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-dnskw.dtsi" +#include "kirkwood-dnskw.dtsi" / { model = "D-Link DNS-320 NAS (Rev A1)";
arch/arm/boot/dts/kirkwood-dns325.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-dnskw.dtsi" +#include "kirkwood-dnskw.dtsi" / { model = "D-Link DNS-325 NAS (Rev A1)";
arch/arm/boot/dts/kirkwood-dnskw.dtsi +2 -2
@@ -1,5 +1,5 @@ -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "D-Link DNS NASes (kirkwood-based)";
arch/arm/boot/dts/kirkwood-dockstar.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Seagate FreeAgent Dockstar";
arch/arm/boot/dts/kirkwood-dreamplug.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Globalscale Technologies Dreamplug";
arch/arm/boot/dts/kirkwood-goflexnet.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Seagate GoFlex Net";
arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Globalscale Technologies Guruplug Server Plus";
arch/arm/boot/dts/kirkwood-ib62x0.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "RaidSonic ICY BOX IB-NAS62x0 (Rev B)";
arch/arm/boot/dts/kirkwood-iconnect.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Iomega Iconnect";
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "Iomega StorCenter ix2-200";
arch/arm/boot/dts/kirkwood-is2.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-ns2-common.dtsi" +#include "kirkwood-ns2-common.dtsi" / { model = "LaCie Internet Space v2";
arch/arm/boot/dts/kirkwood-km_kirkwood.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-98dx4122.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-98dx4122.dtsi" / { model = "Keymile Kirkwood Reference Design";
arch/arm/boot/dts/kirkwood-lschlv2.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-lsxl.dtsi" +#include "kirkwood-lsxl.dtsi" / { model = "Buffalo Linkstation LS-CHLv2";
arch/arm/boot/dts/kirkwood-lsxhl.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-lsxl.dtsi" +#include "kirkwood-lsxl.dtsi" / { model = "Buffalo Linkstation LS-XHL";
arch/arm/boot/dts/kirkwood-lsxl.dtsi +2 -2
@@ -1,5 +1,5 @@ -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { chosen {
arch/arm/boot/dts/kirkwood-mplcec4.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "MPL CEC4";
arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6282.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" / { model = "NETGEAR ReadyNAS Duo v2";
arch/arm/boot/dts/kirkwood-ns2-common.dtsi +2 -2
@@ -1,5 +1,5 @@ -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { chosen {
arch/arm/boot/dts/kirkwood-ns2.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-ns2-common.dtsi" +#include "kirkwood-ns2-common.dtsi" / { model = "LaCie Network Space v2";
arch/arm/boot/dts/kirkwood-ns2lite.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-ns2-common.dtsi" +#include "kirkwood-ns2-common.dtsi" / { model = "LaCie Network Space Lite v2";
arch/arm/boot/dts/kirkwood-ns2max.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-ns2-common.dtsi" +#include "kirkwood-ns2-common.dtsi" / { model = "LaCie Network Space Max v2";
arch/arm/boot/dts/kirkwood-ns2mini.dts +1 -1
@@ -1,6 +1,6 @@ /dts-v1/; -/include/ "kirkwood-ns2-common.dtsi" +#include "kirkwood-ns2-common.dtsi" / { /* This machine is embedded in the first LaCie CloudBox product. */
arch/arm/boot/dts/kirkwood-nsa310.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { model = "ZyXEL NSA310";
arch/arm/boot/dts/kirkwood-openblocks_a6.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6282.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" / { model = "Plat'Home OpenBlocksA6";
arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi +2 -2
@@ -6,8 +6,8 @@ * Licensed under GPLv2 */ -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" / { memory {
arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts +1 -1
@@ -8,7 +8,7 @@ /dts-v1/; -/include/ "kirkwood-sheevaplug-common.dtsi" +#include "kirkwood-sheevaplug-common.dtsi" / { model = "Globalscale Technologies eSATA SheevaPlug";
arch/arm/boot/dts/kirkwood-sheevaplug.dts +1 -1
@@ -8,7 +8,7 @@ /dts-v1/; -/include/ "kirkwood-sheevaplug-common.dtsi" +#include "kirkwood-sheevaplug-common.dtsi" / { model = "Globalscale Technologies SheevaPlug";
arch/arm/boot/dts/kirkwood-topkick.dts +2 -2
@@ -1,7 +1,7 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6282.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" / { model = "Univeral Scientific Industrial Co. Topkick-1281P2";
arch/arm/boot/dts/kirkwood-ts219-6281.dts +3 -3
@@ -1,8 +1,8 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6281.dtsi" -/include/ "kirkwood-ts219.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" +#include "kirkwood-ts219.dtsi" / { ocp at f1000000 {
arch/arm/boot/dts/kirkwood-ts219-6282.dts +3 -3
@@ -1,8 +1,8 @@ /dts-v1/; -/include/ "kirkwood.dtsi" -/include/ "kirkwood-6282.dtsi" -/include/ "kirkwood-ts219.dtsi" +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" +#include "kirkwood-ts219.dtsi" / { ocp at f1000000 {
Signature · 1 line
1.8.1.5
PATCH v9 26/30 ARM: kirkwood: Introduce MBus DT node
In reply to Ezequiel GarciaAdd a minimal MBus node, just to allow the MBus driver to probe. Follow-up patches will migrate the rest of the nodes appropriately.
--- arch/arm/boot/dts/kirkwood.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm/boot/dts/kirkwood.dtsi +10 -0
@@ -28,6 +28,11 @@ <0xf1020214 0x04>; }; + mbus { + compatible = "marvell,kirkwood-mbus", "simple-bus"; + controller = <&mbusc>; + }; + ocp at f1000000 { compatible = "simple-bus"; ranges = <0x00000000 0xf1000000 0x0100000
@@ -37,6 +42,11 @@ #address-cells = <1>; #size-cells = <1>; + mbusc: mbus-controller at 20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x80>, <0x1500 0x20>; + }; + core_clk: core-clocks at 10030 { compatible = "marvell,kirkwood-core-clock"; reg = <0x10030 0x4>;
Signature · 1 line
1.8.1.5
PATCH v9 27/30 ARM: kirkwood: Introduce MBUS_ID
In reply to Ezequiel GarciaThis macro is used to define window's target ID and attribute cells for the MBus ranges entries.
--- arch/arm/boot/dts/kirkwood.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/boot/dts/kirkwood.dtsi +2 -0
@@ -1,5 +1,7 @@ /include/ "skeleton.dtsi" +#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16)) + / { compatible = "marvell,kirkwood"; interrupt-parent = <&intc>;
Signature · 1 line
1.8.1.5
PATCH v9 28/30 ARM: kirkwood: Relocate PCIe device tree nodes
In reply to Ezequiel GarciaNow that mbus has been added to the device tree, it's possible to move the PCIe nodes out of the ocp node, placing it directly below the mbus. This is a more accurate representation of the hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to encode the window target ID and attribute. Since this depends on the PCIe port, we split the ranges translation entries, to correspond to each MBus window.
In addition, we encode the PCIe memory and I/O apertures in the MBus node, according to the MBus DT binding specification. The choice made is 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for I/O space. These apertures can be changed in each per-board DT file.
--- arch/arm/boot/dts/kirkwood-6281.dtsi | 66 ++++++------- arch/arm/boot/dts/kirkwood-6282.dtsi | 102 +++++++++++---------- arch/arm/boot/dts/kirkwood-db-88f6281.dts | 3 +- arch/arm/boot/dts/kirkwood-db-88f6282.dts | 3 +- arch/arm/boot/dts/kirkwood-db.dtsi | 8 -- arch/arm/boot/dts/kirkwood-iconnect.dts | 19 ++-- arch/arm/boot/dts/kirkwood-mplcec4.dts | 19 ++-- .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 19 ++-- arch/arm/boot/dts/kirkwood-nsa310.dts | 19 ++-- arch/arm/boot/dts/kirkwood-ts219-6282.dts | 19 ++-- arch/arm/boot/dts/kirkwood-ts219.dtsi | 17 ++-- arch/arm/boot/dts/kirkwood.dtsi | 5 +- 12 files changed, 163 insertions(+), 136 deletions(-)
arch/arm/boot/dts/kirkwood-6281.dtsi +35 -31
@@ -1,4 +1,39 @@ / { + mbus { + pcie-controller { + compatible = "marvell,kirkwood-pcie"; + status = "disabled"; + device_type = "pci"; + + #address-cells = <3>; + #size-cells = <2>; + + bus-range = <0x00 0xff>; + + ranges = + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */>; + + pcie at 1,0 { + device_type = "pci"; + assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>; + reg = <0x0800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 + 0x81000000 0 0 0x81000000 0x1 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc 9>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <0>; + clocks = <&gate_clk 2>; + status = "disabled"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 { compatible = "marvell,88f6281-pinctrl";
@@ -41,37 +76,6 @@ }; }; - pcie-controller { - compatible = "marvell,kirkwood-pcie"; - status = "disabled"; - device_type = "pci"; - - #address-cells = <3>; - #size-cells = <2>; - - bus-range = <0x00 0xff>; - - ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000 /* Port 0.0 registers */ - 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */ - 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */ - - pcie at 1,0 { - device_type = "pci"; - assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>; - reg = <0x0800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &intc 9>; - marvell,pcie-port = <0>; - marvell,pcie-lane = <0>; - clocks = <&gate_clk 2>; - status = "disabled"; - }; - }; - rtc at 10300 { compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; reg = <0x10300 0x20>;
arch/arm/boot/dts/kirkwood-6282.dtsi +55 -47
111 lines not on this page · raw message
arch/arm/boot/dts/kirkwood-db-88f6281.dts +2 -1
@@ -18,7 +18,8 @@ model = "Marvell DB-88F6281-BP Development Board"; compatible = "marvell,db-88f6281-bp", "marvell,kirkwood-88f6281", "marvell,kirkwood"; - ocp at f1000000 { + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; pcie-controller { status = "okay";
arch/arm/boot/dts/kirkwood-db-88f6282.dts +2 -1
@@ -18,7 +18,8 @@ model = "Marvell DB-88F6282-BP Development Board"; compatible = "marvell,db-88f6282-bp", "marvell,kirkwood-88f6282", "marvell,kirkwood"; - ocp at f1000000 { + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; pcie-controller { status = "okay";
arch/arm/boot/dts/kirkwood-db.dtsi +0 -8
@@ -77,13 +77,5 @@ cd-gpios = <&gpio1 6 0>; status = "okay"; }; - - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; };
arch/arm/boot/dts/kirkwood-iconnect.dts +11 -8
@@ -18,6 +18,17 @@ linux,initrd-end = <0x4800000>; }; + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; + pcie-controller { + status = "okay"; + + pcie at 1,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 { pmx_button_reset: pmx-button-reset {
@@ -101,14 +112,6 @@ reg = <0x980000 0x1f400000>; }; }; - - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; gpio-leds {
arch/arm/boot/dts/kirkwood-mplcec4.dts +11 -8
@@ -16,6 +16,17 @@ bootargs = "console=ttyS0,115200n8 earlyprintk"; }; + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; + pcie-controller { + status = "okay"; + + pcie at 1,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 { pmx_led_health: pmx-led-health {
@@ -134,14 +145,6 @@ cd-gpios = <&gpio1 15 1>; /* No WP GPIO */ }; - - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; gpio-leds {
arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts +11 -8
@@ -16,6 +16,17 @@ bootargs = "console=ttyS0,115200n8 earlyprintk"; }; + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; + pcie-controller { + status = "okay"; + + pcie at 1,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 { pmx_button_power: pmx-button-power {
@@ -101,14 +112,6 @@ status = "okay"; nr-ports = <2>; }; - - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; gpio-leds {
arch/arm/boot/dts/kirkwood-nsa310.dts +11 -8
@@ -16,6 +16,17 @@ bootargs = "console=ttyS0,115200"; }; + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; + pcie-controller { + status = "okay"; + + pcie at 1,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 { pinctrl-0 = <&pmx_unknown>;
@@ -162,14 +173,6 @@ reg = <0x5040000 0x2fc0000>; }; }; - - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; gpio_keys {
arch/arm/boot/dts/kirkwood-ts219-6282.dts +11 -8
@@ -5,6 +5,17 @@ #include "kirkwood-ts219.dtsi" / { + mbus { + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>; + pcie-controller { + status = "okay"; + + pcie at 2,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { pinctrl: pinctrl at 10000 {
@@ -30,14 +41,6 @@ marvell,function = "gpio"; }; }; - pcie-controller { - status = "okay"; - - pcie at 2,0 { - status = "okay"; - }; - }; - }; gpio_keys {
arch/arm/boot/dts/kirkwood-ts219.dtsi +10 -7
@@ -11,6 +11,16 @@ bootargs = "console=ttyS0,115200n8"; }; + mbus { + pcie-controller { + status = "okay"; + + pcie at 1,0 { + status = "okay"; + }; + }; + }; + ocp at f1000000 { i2c at 11000 { status = "okay";
@@ -87,12 +97,5 @@ status = "okay"; nr-ports = <2>; }; - pcie-controller { - status = "okay"; - - pcie at 1,0 { - status = "okay"; - }; - }; }; };
arch/arm/boot/dts/kirkwood.dtsi +4 -1
@@ -32,13 +32,16 @@ mbus { compatible = "marvell,kirkwood-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; controller = <&mbusc>; + pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256 MiB memory space */ + pcie-io-aperture = <0xf2000000 0x100000>; /* 1 MiB I/O space */ }; ocp at f1000000 { compatible = "simple-bus"; ranges = <0x00000000 0xf1000000 0x0100000 - 0xe0000000 0xe0000000 0x8100000 /* PCIE */ 0xf4000000 0xf4000000 0x0000400 0xf5000000 0xf5000000 0x0000400>; #address-cells = <1>;
Signature · 1 line
1.8.1.5
PATCH v9 29/30 bus: mvebu-mbus: Add devicetree binding
In reply to Ezequiel GarciaIntroduce 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.
--- .../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
Documentation/devicetree/bindings/bus/mvebu-mbus.txt new file +276 -0
@@ -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 at 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 at 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 at 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 at 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 at 20000 { + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + interrupt-controller at 20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + };
Signature · 1 line
1.8.1.5
PATCH v9 29/30 bus: mvebu-mbus: Add devicetree binding
DT Maintainers,
It's been a week since this was sent to the ml... It's been through *9* revisions with extensive commenting and corrections by Arnd Bergmann, Jason Gunthorpe, and others.
Unless someone has a serious objection, I'd like to apply this series shortly so it can get some time in -next before sending to Arnd and Olof.
thx,
Jason.
Quoted 309 lines · Ezequiel Garcia
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.
Cc devicetree at vger.kernel.orgSigned-off-by Ezequiel Garcia <[email protected]>Tested-by Andrew Lunn <[email protected]>--- .../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txtDocumentation/devicetree/bindings/bus/mvebu-mbus.txt new file +276
-0@@ -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 at 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 at 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 at 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 at 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 at 20000 { + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + interrupt-controller at 20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + };Signature · 6 lines
1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v9 29/30 bus: mvebu-mbus: Add devicetree binding
DT maintainers,
Quoted 9 lines · Jason Cooper
DT Maintainers,
It's been a week since this was sent to the ml... It's been through *9* revisions with extensive commenting and corrections by Arnd Bergmann, Jason Gunthorpe, and others.
Unless someone has a serious objection, I'd like to apply this series shortly so it can get some time in -next before sending to Arnd and Olof.
The final DT binding that is showed in this patch set was presented in an e-mail at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182095.html
Arnd Bergmann indicated his agreement on this DT binding as a reply to this e-mail, at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182097.html
And Jason Gunthorpe also agreed in a reply to Arnd's answer:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182371.html
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
DT binding stalemate proposal, was: Re: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
In reply to Ezequiel GarciaDT maintainers,
I understand you guys are swamped with reviewing atm. This binding in particular is complicated, has a long history (9 versions just for the devicetree binding itself), and no one wants to commit to supporting it forever without fully understanding where it came from and why it's needed.
On the other side of the coin, we have other patches depending on this work, and the submitters have been more than patient with the process (and the maintainership change). I'd prefer not to delay it if it can be helped.
So here's my proposal: Let use this as a guinea pig for the 'unstable' class of bindings. eg s:/bindings/:/bindings/unstable/: and merge it in.
As we've said a couple of times, Arnd Bergmann has helped out plenty with developing this binding, but he's not available for the next few months. So unless we do something, we're essentially starting over from scratch.
As a side note, Olof prefers all pull requests be sent by -rc6, which means I'd like to have the patches in by -rc5 so they get some coverage in -next before I send the PR to Olof. Which means time is getting short :)
thx,
Jason.
Quoted 309 lines · Ezequiel Garcia
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.
Cc devicetree at vger.kernel.orgSigned-off-by Ezequiel Garcia <[email protected]>Tested-by Andrew Lunn <[email protected]>--- .../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txtDocumentation/devicetree/bindings/bus/mvebu-mbus.txt new file +276
-0@@ -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 at 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 at 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 at 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 at 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 at 20000 { + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + interrupt-controller at 20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + };Signature · 6 lines
1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DT binding stalemate proposal, was: Re: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
Quoted 4 lines · Jason Cooper
As a side note, Olof prefers all pull requests be sent by -rc6, which means I'd like to have the patches in by -rc5 so they get some coverage in -next before I send the PR to Olof. Which means time is getting short :)
Just to clarify: I have never said that I require you to sit on patches for a week before we get them. So that one-week delay is self-imposed.
-Olof
Rob Herring
Acked-byDT binding stalemate proposal, was: Re: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
In reply to Jason CooperQuoted 7 lines · Jason Cooper
DT maintainers,
I understand you guys are swamped with reviewing atm. This binding in particular is complicated, has a long history (9 versions just for the devicetree binding itself), and no one wants to commit to supporting it forever without fully understanding where it came from and why it's needed.
Is there an actual objection in the current binding that is not addressed or just lack of approval? It seems to be the latter to me.
Quoted 8 lines
On the other side of the coin, we have other patches depending on this work, and the submitters have been more than patient with the process (and the maintainership change). I'd prefer not to delay it if it can be helped.
So here's my proposal: Let use this as a guinea pig for the 'unstable' class of bindings. eg s:/bindings/:/bindings/unstable/: and merge it in.
What the unstable process looks like is not fully flushed out, and until it is we can't really hold up submissions if there are no objections. It also means we should not accept anything known to be unstable. This is self-contained to mvebu, so it is your problem to support or deal with any change.
Quoted 4 lines
As we've said a couple of times, Arnd Bergmann has helped out plenty with developing this binding, but he's not available for the next few months. So unless we do something, we're essentially starting over from scratch.
My read of the history is that Arnd was pretty much in agreement.
The binding looks reasonable to me, but honestly I haven't studied it in depth. So given the above conditions:
Rob
Quoted 323 lines
As a side note, Olof prefers all pull requests be sent by -rc6, which means I'd like to have the patches in by -rc5 so they get some coverage in -next before I send the PR to Olof. Which means time is getting short :)
thx,
Jason.
Quoted 305 lines · Ezequiel Garcia
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.
Cc devicetree at vger.kernel.orgSigned-off-by Ezequiel Garcia <[email protected]>Tested-by Andrew Lunn <[email protected]>--- .../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txtDocumentation/devicetree/bindings/bus/mvebu-mbus.txt new file +276
-1@@ -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 at 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 at 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 at 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 at 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 at 20000 { + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + interrupt-controller at 20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + }; --1.8.1.5
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
DT binding stalemate proposal, was: Re: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
Quoted 11 lines · Rob Herring
Quoted 7 lines · Jason Cooper
DT maintainers,
I understand you guys are swamped with reviewing atm. This binding in particular is complicated, has a long history (9 versions just for the devicetree binding itself), and no one wants to commit to supporting it forever without fully understanding where it came from and why it's needed.
Is there an actual objection in the current binding that is not addressed or just lack of approval? It seems to be the latter to me.
Correct. The DT maintainership was announced just shortly before the final version of this series was posted. So it's purely bad timing. It was "good" according to the old rules, but we didn't want to assume that meant the same thing now.
Quoted 9 lines
Quoted 8 lines
On the other side of the coin, we have other patches depending on this work, and the submitters have been more than patient with the process (and the maintainership change). I'd prefer not to delay it if it can be helped.
So here's my proposal: Let use this as a guinea pig for the 'unstable' class of bindings. eg s:/bindings/:/bindings/unstable/: and merge it in.
Quoted 5 lines
What the unstable process looks like is not fully flushed out, and until it is we can't really hold up submissions if there are no objections. It also means we should not accept anything known to be unstable. This is self-contained to mvebu, so it is your problem to support or deal with any change.
Fair enough.
Quoted 11 lines
Quoted 4 lines
As we've said a couple of times, Arnd Bergmann has helped out plenty with developing this binding, but he's not available for the next few months. So unless we do something, we're essentially starting over from scratch.
My read of the history is that Arnd was pretty much in agreement.
The binding looks reasonable to me, but honestly I haven't studied it in depth. So given the above conditions:
Acked-by Rob Herring <[email protected]>
Thanks Rob! I appreciate it.
thx,
Jason.
DT binding stalemate proposal, was: Re: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
In reply to Rob HerringRob, Jason:
Quoted 1 line · Rob Herring
On Mon, Aug 5, 2013 at 3:36 PM, Jason Cooper <[email protected]> wrote:
[..]
Quoted 5 lines
Quoted 4 lines
As we've said a couple of times, Arnd Bergmann has helped out plenty with developing this binding, but he's not available for the next few months. So unless we do something, we're essentially starting over from scratch.
Quoted 7 lines
My read of the history is that Arnd was pretty much in agreement.
The binding looks reasonable to me, but honestly I haven't studied it in depth. So given the above conditions:
Acked-by Rob Herring <[email protected]>
Jason: Thanks a lot for taking care of this. It's really appreaciated.
Rob: Thanks for looking and acking!
If there's anything else you need from me, just let me know.
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
PATCH v9 30/30 PCI: mvebu: Adapt to the new device tree layout
In reply to Ezequiel GarciaFrom: Thomas Petazzoni <[email protected]>
The new device tree layout encodes the window's target ID and attribute in the PCIe controller node's ranges property. This allows to parse such entries to obtain such information and use the recently introduced MBus API to create the windows, instead of using the current name based scheme.
--- .../devicetree/bindings/pci/mvebu-pci.txt | 145 ++++++++++++++++----- 1 file changed, 109 insertions(+), 36 deletions(-)
Documentation/devicetree/bindings/pci/mvebu-pci.txt +109 -36
@@ -1,6 +1,7 @@ * Marvell EBU PCIe interfaces Mandatory properties: + - compatible: one of the following values: marvell,armada-370-pcie marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties: - #interrupt-cells, set to <1> - bus-range: PCI bus numbers covered - device_type, set to "pci" -- ranges: ranges for the PCI memory and I/O regions, as well as the - MMIO registers to control the PCIe interfaces. +- ranges: ranges describing the MMIO registers to control the PCIe + interfaces, and ranges describing the MBus windows needed to access + the memory and I/O regions of each PCIe interface. + +The ranges describing the MMIO registers have the following layout: + + 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s + +where: + + * r is a 32-bits value that gives the offset of the MMIO + registers of this PCIe interface, from the base of the internal + registers. + + * s is a 32-bits value that give the size of this MMIO + registers area. This range entry translates the '0x82000000 0 r' PCI + address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part + of the internal register window (as identified by MBUS_ID(0xf0, + 0x01)). + +The ranges describing the MBus windows have the following layout: + + 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0 + +where: + + * t is the type of the MBus window (as defined by the standard PCI DT + bindings), 1 for I/O and 2 for memory. -In addition, the Device Tree node must have sub-nodes describing each + * s is the PCI slot that corresponds to this PCIe interface + + * w is the 'target ID' value for the MBus window + + * a the 'attribute' value for the MBus window. + +Since the location and size of the different MBus windows is not fixed in +hardware, and only determined in runtime, those ranges cover the full first +4 GB of the physical address space, and do not translate into a valid CPU +address. + +In addition, the device tree node must have sub-nodes describing each PCIe interface, having the following mandatory properties: + - reg: used only for interrupt mapping, so only the first four bytes are used to refer to the correct bus number and device number. - assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties: - #address-cells, set to <3> - #size-cells, set to <2> - #interrupt-cells, set to <1> -- ranges, empty property. +- ranges, translating the MBus windows ranges of the parent node into + standard PCI addresses. - interrupt-map-mask and interrupt-map, standard PCI properties to define the mapping of the PCIe interface to interrupt numbers.
@@ -47,27 +87,50 @@ pcie-controller { bus-range = <0x00 0xff>; - ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ - 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */ - 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000 /* Port 0.1 registers */ - 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000 /* Port 0.2 registers */ - 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000 /* Port 0.3 registers */ - 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000 /* Port 1.0 registers */ - 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000 /* Port 3.0 registers */ - 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000 /* Port 1.1 registers */ - 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000 /* Port 1.2 registers */ - 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000 /* Port 1.3 registers */ - 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */ - 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */ + 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 */ + 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */ + 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */ + 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */ + 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */ + 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */ + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ + 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */ + 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */ + 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */ + 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */ + 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */ + 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */ + + 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ + 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */ + 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */ + 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */ + 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */ + 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */ + 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */ + 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */ + + 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */ + 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */ + + 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */ + 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>; pcie at 1,0 { device_type = "pci"; - assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>; + assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; reg = <0x0800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 + 0x81000000 0 0 0x81000000 0x1 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>;
@@ -78,12 +141,13 @@ pcie-controller { pcie at 2,0 { device_type = "pci"; - assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>; + assigned-addresses = <0x82001000 0 0x44000 0 0x2000>; reg = <0x1000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 + 0x81000000 0 0 0x81000000 0x2 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 59>; marvell,pcie-port = <0>;
@@ -94,12 +158,13 @@ pcie-controller { pcie at 3,0 { device_type = "pci"; - assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>; + assigned-addresses = <0x82001800 0 0x48000 0 0x2000>; reg = <0x1800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0 + 0x81000000 0 0 0x81000000 0x3 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 60>; marvell,pcie-port = <0>;
@@ -110,12 +175,13 @@ pcie-controller { pcie at 4,0 { device_type = "pci"; - assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>; + assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>; reg = <0x2000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0 + 0x81000000 0 0 0x81000000 0x4 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 61>; marvell,pcie-port = <0>;
@@ -126,12 +192,13 @@ pcie-controller { pcie at 5,0 { device_type = "pci"; - assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>; + assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; reg = <0x2800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0 + 0x81000000 0 0 0x81000000 0x5 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>;
@@ -142,12 +209,13 @@ pcie-controller { pcie at 6,0 { device_type = "pci"; - assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>; + assigned-addresses = <0x82003000 0 0x84000 0 0x2000>; reg = <0x3000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0 + 0x81000000 0 0 0x81000000 0x6 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 63>; marvell,pcie-port = <1>;
@@ -158,12 +226,13 @@ pcie-controller { pcie at 7,0 { device_type = "pci"; - assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>; + assigned-addresses = <0x82003800 0 0x88000 0 0x2000>; reg = <0x3800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0 + 0x81000000 0 0 0x81000000 0x7 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 64>; marvell,pcie-port = <1>;
@@ -174,12 +243,13 @@ pcie-controller { pcie at 8,0 { device_type = "pci"; - assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>; + assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>; reg = <0x4000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0 + 0x81000000 0 0 0x81000000 0x8 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 65>; marvell,pcie-port = <1>;
@@ -187,14 +257,16 @@ pcie-controller { clocks = <&gateclk 12>; status = "disabled"; }; + pcie at 9,0 { device_type = "pci"; - assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>; + assigned-addresses = <0x82004800 0 0x42000 0 0x2000>; reg = <0x4800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0 + 0x81000000 0 0 0x81000000 0x9 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 99>; marvell,pcie-port = <2>;
@@ -205,12 +277,13 @@ pcie-controller { pcie at 10,0 { device_type = "pci"; - assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>; + assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; reg = <0x5000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0 + 0x81000000 0 0 0x81000000 0xa 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 103>; marvell,pcie-port = <3>;
Signature · 1 line
1.8.1.5
PATCH v9 30/30 PCI: mvebu: Adapt to the new device tree layout
Quoted 307 lines · Ezequiel Garcia
From: Thomas Petazzoni <[email protected]>
The new device tree layout encodes the window's target ID and attribute in the PCIe controller node's ranges property. This allows to parse such entries to obtain such information and use the recently introduced MBus API to create the windows, instead of using the current name based scheme.
Cc devicetree at vger.kernel.orgAcked-by Bjorn Helgaas <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>Tested-by Andrew Lunn <[email protected]>--- .../devicetree/bindings/pci/mvebu-pci.txt | 145 ++++++++++++++++----- 1 file changed, 109 insertions(+), 36 deletions(-)Documentation/devicetree/bindings/pci/mvebu-pci.txt +109
-36@@ -1,6 +1,7 @@ * Marvell EBU PCIe interfaces Mandatory properties: + - compatible: one of the following values: marvell,armada-370-pcie marvell,armada-xp-pcie@@ -10,11 +11,49 @@ Mandatory properties: - #interrupt-cells, set to <1> - bus-range: PCI bus numbers covered - device_type, set to "pci" -- ranges: ranges for the PCI memory and I/O regions, as well as the - MMIO registers to control the PCIe interfaces. +- ranges: ranges describing the MMIO registers to control the PCIe + interfaces, and ranges describing the MBus windows needed to access + the memory and I/O regions of each PCIe interface. + +The ranges describing the MMIO registers have the following layout: + + 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s + +where: + + * r is a 32-bits value that gives the offset of the MMIO + registers of this PCIe interface, from the base of the internal + registers. + + * s is a 32-bits value that give the size of this MMIO + registers area. This range entry translates the '0x82000000 0 r' PCI + address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part + of the internal register window (as identified by MBUS_ID(0xf0, + 0x01)). + +The ranges describing the MBus windows have the following layout: + + 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0 + +where: + + * t is the type of the MBus window (as defined by the standard PCI DT + bindings), 1 for I/O and 2 for memory. -In addition, the Device Tree node must have sub-nodes describing each + * s is the PCI slot that corresponds to this PCIe interface + + * w is the 'target ID' value for the MBus window + + * a the 'attribute' value for the MBus window. + +Since the location and size of the different MBus windows is not fixed in +hardware, and only determined in runtime, those ranges cover the full first +4 GB of the physical address space, and do not translate into a valid CPU +address. + +In addition, the device tree node must have sub-nodes describing each PCIe interface, having the following mandatory properties: + - reg: used only for interrupt mapping, so only the first four bytes are used to refer to the correct bus number and device number. - assigned-addresses: reference to the MMIO registers used to control@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties: - #address-cells, set to <3> - #size-cells, set to <2> - #interrupt-cells, set to <1> -- ranges, empty property. +- ranges, translating the MBus windows ranges of the parent node into + standard PCI addresses. - interrupt-map-mask and interrupt-map, standard PCI properties to define the mapping of the PCIe interface to interrupt numbers.@@ -47,27 +87,50 @@ pcie-controller { bus-range = <0x00 0xff>; - ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ - 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */ - 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000 /* Port 0.1 registers */ - 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000 /* Port 0.2 registers */ - 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000 /* Port 0.3 registers */ - 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000 /* Port 1.0 registers */ - 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000 /* Port 3.0 registers */ - 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000 /* Port 1.1 registers */ - 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000 /* Port 1.2 registers */ - 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000 /* Port 1.3 registers */ - 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */ - 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */ + 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 */ + 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */ + 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */ + 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */ + 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */ + 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */ + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ + 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */ + 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */ + 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */ + 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */ + 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */ + 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */ + + 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ + 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */ + 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */ + 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */ + 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */ + 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */ + 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */ + 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */ + + 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */ + 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */ + + 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */ + 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>; pcie at 1,0 { device_type = "pci"; - assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>; + assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; reg = <0x0800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 + 0x81000000 0 0 0x81000000 0x1 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>;@@ -78,12 +141,13 @@ pcie-controller { pcie at 2,0 { device_type = "pci"; - assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>; + assigned-addresses = <0x82001000 0 0x44000 0 0x2000>; reg = <0x1000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 + 0x81000000 0 0 0x81000000 0x2 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 59>; marvell,pcie-port = <0>;@@ -94,12 +158,13 @@ pcie-controller { pcie at 3,0 { device_type = "pci"; - assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>; + assigned-addresses = <0x82001800 0 0x48000 0 0x2000>; reg = <0x1800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0 + 0x81000000 0 0 0x81000000 0x3 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 60>; marvell,pcie-port = <0>;@@ -110,12 +175,13 @@ pcie-controller { pcie at 4,0 { device_type = "pci"; - assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>; + assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>; reg = <0x2000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0 + 0x81000000 0 0 0x81000000 0x4 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 61>; marvell,pcie-port = <0>;@@ -126,12 +192,13 @@ pcie-controller { pcie at 5,0 { device_type = "pci"; - assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>; + assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; reg = <0x2800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0 + 0x81000000 0 0 0x81000000 0x5 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>;@@ -142,12 +209,13 @@ pcie-controller { pcie at 6,0 { device_type = "pci"; - assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>; + assigned-addresses = <0x82003000 0 0x84000 0 0x2000>; reg = <0x3000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0 + 0x81000000 0 0 0x81000000 0x6 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 63>; marvell,pcie-port = <1>;@@ -158,12 +226,13 @@ pcie-controller { pcie at 7,0 { device_type = "pci"; - assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>; + assigned-addresses = <0x82003800 0 0x88000 0 0x2000>; reg = <0x3800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0 + 0x81000000 0 0 0x81000000 0x7 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 64>; marvell,pcie-port = <1>;@@ -174,12 +243,13 @@ pcie-controller { pcie at 8,0 { device_type = "pci"; - assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>; + assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>; reg = <0x4000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0 + 0x81000000 0 0 0x81000000 0x8 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 65>; marvell,pcie-port = <1>;@@ -187,14 +257,16 @@ pcie-controller { clocks = <&gateclk 12>; status = "disabled"; }; + pcie at 9,0 { device_type = "pci"; - assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>; + assigned-addresses = <0x82004800 0 0x42000 0 0x2000>; reg = <0x4800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0 + 0x81000000 0 0 0x81000000 0x9 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 99>; marvell,pcie-port = <2>;@@ -205,12 +277,13 @@ pcie-controller { pcie at 10,0 { device_type = "pci"; - assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>; + assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; reg = <0x5000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0 + 0x81000000 0 0 0x81000000 0xa 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 103>; marvell,pcie-port = <3>;Signature · 1 line
1.8.1.5
Any feedback on this from the DT maintainers?
This patchset has been around for several months now and has been extensively discussed with Jason Gunthorpe and Arnd Bergmann, so we'd really like to have an Acked-by on the DT bindings and merge it.
Thanks!
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
v9 cover MBus DT binding for Armada 370/XP and Kirkwood
In reply to Ezequiel GarciaEzequiel,
Whole series applied to mvebu/mbus_dt
thx,
Jason.
Quoted 353 lines · Ezequiel Garcia
This is a minor revision of the patchset, splitting patches with DT bindings changes to separate patches. See the changelog for more context information.
Except for this patch splitting, this can be considered as a v8 resend.
This has been tested on several Armada 370/XP boards, and on Plathome Openblocks A6 Kirkwood board by myself; Kirkwood and Dove testing has been performed by Andrew Lunn and Sebastian Hesselbarth respectively.
If anyone wants to do further testing, there's a public branch:
https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v9
At this point all that's left is to have formal Acked-by from some DT maintainer/s to the DT binding itself.
This is based on v3.11-rc2.
Changelog
---------v9:
* Split DT bindings in separate patches and send only these to the devicetree mailing list to avoid overloading it, as suggested by Olof Johansson.
v8:
* Introduce Kirkwood MBus DT binding and use it to relocate the PCIe nodes *only*.
* Allow MBus to initialize when the node has no ranges property.
* Add a sanity check for PCIe port base address to prevent a kernel panic when this address has not been obtained. Instead of panic, the PCIe won't work in such cases.
v7:
* Add two optional properties pcie-{mem,io}-aperture to the MBus node defining the PCIe mem and IO region apertures.
* Encode the PCIe port in the second cell of the ranges entries, using the PCIe slot; and remove such encoding from the first cell, since it was violating the specification.
Quoting Jason Gunthorpe:
""" [...] the OF spec says that the phys.hi fields of the child address spaces in the "ranges" property for PCI does not contain the same information as "reg" property entries within PCI nodes. The only information that is present in "ranges" phys.hi entries are the non-relocatable, prefetchable and the PCI address space bits for which the entry applies. I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0."""v6:
* Change the PCIe ranges translations encoding, removing the big fake window encoded as
MBUS_ID(0xf0, 0x02)by an array of entries representing the PCIe real windows with full 4 GiB size.* The corresponding PCIe port is selected by encoding the bus in the first cell of the PCIe controller node ranges entry.
* Remove the name-based MBus window allocation API, replacing it by an ID-based API.
v5:
* Add a required a 'controller' property to specify a phandle containing the MBus controller MMIO registers.
v4:
* Fixed the pcie-controller to mbus address space translations, to match a 1:1 mapping between the PCI and CPU busses.
* Fixed the binding documentation with suggestions from Arnd Bergmann.
* Added a BootROM sanity check on AXP SMP initialization, as suggested by Jason Gunthorpe. This also implied changing slightly the bootrom node.
* Changed the first cell format for the MBus address space.
v3:
* Replaced the PCIe mapping with
0xffff0002, to avoid using a representation that might correspond to a possible window id.* Remove every mbus-node 'ranges' property from the dtsi files. Having them on the per-board dts files only makes maintaince less painful.
* Declare children window size, in the children 'ranges' property, as large as possible (4 GiB size) and move the property to the dtsi files. The per-board dts, does not need to declare that property now.
* The MBus driver now creates the decoding window using the base address and size specified in the mbus-node, instead of using the children entries.
v2:
* Use the preprocessor on the DT and define a macro for the window ID.
* Changed the way the address spaces were declared: the window's base addresses are only present in the mbus-node ranges property. This makes sense since that information belongs only to the MBus address space.
* Drop the ranges dynamic update, since now the DT translations are complete.
* Replaced the internal register first cell mapping with
0xffff0001, to avoid clashing when using0x00000000.* Replaced the PCIe mapping with
0xffff0000.v1:
* Initial proposal
Example
-------Here's an example showing how the MBus DT binding looks now:
soc { compatible = "marvell,armadaxp-mbus", "simple-bus"; controller = <&mbusc>; pcie-mem-aperture = <0xe0000000 0x8000000>; pcie-io-aperture = <0xe8000000 0x100000>; 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 */ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ 0x82000000 0x2 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ 0x81000000 0x2 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>; pcie at 1,0 { device_type = "pci"; assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; reg = <0x0800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 0x81000000 0 0 0x81000000 0x1 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; marvell,pcie-lane = <0>; clocks = <&gateclk 5>; status = "disabled"; }; pcie at 2,0 { device_type = "pci"; assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; reg = <0x1000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 0x81000000 0 0 0x81000000 0x2 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>; marvell,pcie-lane = <0>; clocks = <&gateclk 9>; status = "disabled"; }; }; internal-regs { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; mbusc: mbus-controller at 20000 { reg = <0x20000 0x100>, <0x20180 0x20>; }; interrupt-controller at 20000 { reg = <0x20a00 0x2d0>, <0x21070 0x58>; }; }; };Ezequiel Garcia (19):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
PCI: mvebu: Check valid base address before port setup
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
ARM: kirkwood: Split DT and legacy MBus initialization
ARM: kirkwood: Use the preprocessor on device tree files
ARM: kirkwood: Introduce MBus DT node
ARM: kirkwood: IntroduceMBUS_ID
ARM: kirkwood: Relocate PCIe device tree nodes
bus: mvebu-mbus: Add devicetree bindingThomas Petazzoni (11):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM: mv78xx0: Move to ID based window creation
ARM: orion5x: Move to ID based window creation
ARM: dove: Move to ID based window creation
PCI: mvebu: Adapt to the new device tree layout
bus: mvebu-mbus: Remove the no longer used name-based API
bus: mvebu-mbus: Remove name -> target, attribute mapping tables
bus: mvebu-mbus: Update main description
bus: mvebu-mbus: Factorize Armada 370/XP data structures
PCI: mvebu: Adapt to the new device tree layout.../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++ .../devicetree/bindings/pci/mvebu-pci.txt | 145 +++++-- arch/arm/boot/dts/armada-370-db.dts | 5 +- arch/arm/boot/dts/armada-370-mirabox.dts | 37 +- arch/arm/boot/dts/armada-370-rd.dts | 5 +- arch/arm/boot/dts/armada-370-xp.dtsi | 111 +++--- arch/arm/boot/dts/armada-370.dtsi | 112 +++--- arch/arm/boot/dts/armada-xp-db.dts | 131 +++--- arch/arm/boot/dts/armada-xp-gp.dts | 107 +++-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++++++----- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 263 ++++++------ arch/arm/boot/dts/armada-xp-mv78460.dtsi | 411 ++++++++++--------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 88 ++-- arch/arm/boot/dts/armada-xp.dtsi | 9 +- arch/arm/boot/dts/kirkwood-6281.dtsi | 66 +-- arch/arm/boot/dts/kirkwood-6282.dtsi | 102 ++--- arch/arm/boot/dts/kirkwood-cloudbox.dts | 4 +- arch/arm/boot/dts/kirkwood-db-88f6281.dts | 7 +- arch/arm/boot/dts/kirkwood-db-88f6282.dts | 7 +- arch/arm/boot/dts/kirkwood-db.dtsi | 10 +- arch/arm/boot/dts/kirkwood-dns320.dts | 2 +- arch/arm/boot/dts/kirkwood-dns325.dts | 2 +- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 4 +- arch/arm/boot/dts/kirkwood-dockstar.dts | 4 +- arch/arm/boot/dts/kirkwood-dreamplug.dts | 4 +- arch/arm/boot/dts/kirkwood-goflexnet.dts | 4 +- .../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 4 +- arch/arm/boot/dts/kirkwood-ib62x0.dts | 4 +- arch/arm/boot/dts/kirkwood-iconnect.dts | 23 +- arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 4 +- arch/arm/boot/dts/kirkwood-is2.dts | 2 +- arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 4 +- arch/arm/boot/dts/kirkwood-lschlv2.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxhl.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxl.dtsi | 4 +- arch/arm/boot/dts/kirkwood-mplcec4.dts | 23 +- .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 23 +- arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-ns2.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2lite.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2max.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2mini.dts | 2 +- arch/arm/boot/dts/kirkwood-nsa310.dts | 23 +- arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 2 +- arch/arm/boot/dts/kirkwood-sheevaplug.dts | 2 +- arch/arm/boot/dts/kirkwood-topkick.dts | 4 +- arch/arm/boot/dts/kirkwood-ts219-6281.dts | 6 +- arch/arm/boot/dts/kirkwood-ts219-6282.dts | 25 +- arch/arm/boot/dts/kirkwood-ts219.dtsi | 17 +- arch/arm/boot/dts/kirkwood.dtsi | 17 +- arch/arm/mach-dove/common.c | 68 ++-- arch/arm/mach-kirkwood/board-dt.c | 1 + arch/arm/mach-kirkwood/common.c | 26 +- arch/arm/mach-kirkwood/pcie.c | 40 +- arch/arm/mach-mv78xx0/pcie.c | 23 +- arch/arm/mach-mvebu/armada-370-xp.c | 34 +- arch/arm/mach-mvebu/platsmp.c | 25 +- arch/arm/mach-orion5x/common.c | 36 +- arch/arm/mach-orion5x/common.h | 17 + arch/arm/mach-orion5x/d2net-setup.c | 6 +- arch/arm/mach-orion5x/db88f5281-setup.c | 24 +- arch/arm/mach-orion5x/dns323-setup.c | 6 +- arch/arm/mach-orion5x/edmini_v2-setup.c | 6 +- arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 +- arch/arm/mach-orion5x/ls-chl-setup.c | 6 +- arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +- arch/arm/mach-orion5x/lsmini-setup.c | 6 +- arch/arm/mach-orion5x/mss2-setup.c | 6 +- arch/arm/mach-orion5x/mv2120-setup.c | 6 +- arch/arm/mach-orion5x/net2big-setup.c | 6 +- arch/arm/mach-orion5x/pci.c | 9 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5182-setup.c | 13 +- arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +- arch/arm/mach-orion5x/ts209-setup.c | 6 +- arch/arm/mach-orion5x/ts409-setup.c | 6 +- arch/arm/mach-orion5x/wnr854t-setup.c | 6 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +- drivers/bus/mvebu-mbus.c | 441 ++++++++++++--------- drivers/memory/mvebu-devbus.c | 64 +-- drivers/pci/host/pci-mvebu.c | 115 ++++-- include/linux/mbus.h | 16 +- 85 files changed, 2030 insertions(+), 1379 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txtSignature · 7 lines
1.8.1.5 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
v9 cover MBus DT binding for Armada 370/XP and Kirkwood
Hi Jason,
Quoted 3 lines · Jason Cooper
Whole series applied to mvebu/mbus_dt
Hooray!
Thanks a lot!
Quoted 355 lines · Ezequiel Garcia
Quoted 353 lines
This is a minor revision of the patchset, splitting patches with DT bindings changes to separate patches. See the changelog for more context information.
Except for this patch splitting, this can be considered as a v8 resend.
This has been tested on several Armada 370/XP boards, and on Plathome Openblocks A6 Kirkwood board by myself; Kirkwood and Dove testing has been performed by Andrew Lunn and Sebastian Hesselbarth respectively.
If anyone wants to do further testing, there's a public branch:
https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v9
At this point all that's left is to have formal Acked-by from some DT maintainer/s to the DT binding itself.
This is based on v3.11-rc2.
Changelog
---------v9:
* Split DT bindings in separate patches and send only these to the devicetree mailing list to avoid overloading it, as suggested by Olof Johansson.
v8:
* Introduce Kirkwood MBus DT binding and use it to relocate the PCIe nodes *only*.
* Allow MBus to initialize when the node has no ranges property.
* Add a sanity check for PCIe port base address to prevent a kernel panic when this address has not been obtained. Instead of panic, the PCIe won't work in such cases.
v7:
* Add two optional properties pcie-{mem,io}-aperture to the MBus node defining the PCIe mem and IO region apertures.
* Encode the PCIe port in the second cell of the ranges entries, using the PCIe slot; and remove such encoding from the first cell, since it was violating the specification.
Quoting Jason Gunthorpe:
""" [...] the OF spec says that the phys.hi fields of the child address spaces in the "ranges" property for PCI does not contain the same information as "reg" property entries within PCI nodes. The only information that is present in "ranges" phys.hi entries are the non-relocatable, prefetchable and the PCI address space bits for which the entry applies. I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0."""v6:
* Change the PCIe ranges translations encoding, removing the big fake window encoded as
MBUS_ID(0xf0, 0x02)by an array of entries representing the PCIe real windows with full 4 GiB size.* The corresponding PCIe port is selected by encoding the bus in the first cell of the PCIe controller node ranges entry.
* Remove the name-based MBus window allocation API, replacing it by an ID-based API.
v5:
* Add a required a 'controller' property to specify a phandle containing the MBus controller MMIO registers.
v4:
* Fixed the pcie-controller to mbus address space translations, to match a 1:1 mapping between the PCI and CPU busses.
* Fixed the binding documentation with suggestions from Arnd Bergmann.
* Added a BootROM sanity check on AXP SMP initialization, as suggested by Jason Gunthorpe. This also implied changing slightly the bootrom node.
* Changed the first cell format for the MBus address space.
v3:
* Replaced the PCIe mapping with
0xffff0002, to avoid using a representation that might correspond to a possible window id.* Remove every mbus-node 'ranges' property from the dtsi files. Having them on the per-board dts files only makes maintaince less painful.
* Declare children window size, in the children 'ranges' property, as large as possible (4 GiB size) and move the property to the dtsi files. The per-board dts, does not need to declare that property now.
* The MBus driver now creates the decoding window using the base address and size specified in the mbus-node, instead of using the children entries.
v2:
* Use the preprocessor on the DT and define a macro for the window ID.
* Changed the way the address spaces were declared: the window's base addresses are only present in the mbus-node ranges property. This makes sense since that information belongs only to the MBus address space.
* Drop the ranges dynamic update, since now the DT translations are complete.
* Replaced the internal register first cell mapping with
0xffff0001, to avoid clashing when using0x00000000.* Replaced the PCIe mapping with
0xffff0000.v1:
* Initial proposal
Example
-------Here's an example showing how the MBus DT binding looks now:
soc { compatible = "marvell,armadaxp-mbus", "simple-bus"; controller = <&mbusc>; pcie-mem-aperture = <0xe0000000 0x8000000>; pcie-io-aperture = <0xe8000000 0x100000>; 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 */ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ 0x82000000 0x2 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ 0x81000000 0x2 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>; pcie at 1,0 { device_type = "pci"; assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; reg = <0x0800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 0x81000000 0 0 0x81000000 0x1 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; marvell,pcie-lane = <0>; clocks = <&gateclk 5>; status = "disabled"; }; pcie at 2,0 { device_type = "pci"; assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; reg = <0x1000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 0x81000000 0 0 0x81000000 0x2 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>; marvell,pcie-lane = <0>; clocks = <&gateclk 9>; status = "disabled"; }; }; internal-regs { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; mbusc: mbus-controller at 20000 { reg = <0x20000 0x100>, <0x20180 0x20>; }; interrupt-controller at 20000 { reg = <0x20a00 0x2d0>, <0x21070 0x58>; }; }; };Ezequiel Garcia (19):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
PCI: mvebu: Check valid base address before port setup
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
ARM: kirkwood: Split DT and legacy MBus initialization
ARM: kirkwood: Use the preprocessor on device tree files
ARM: kirkwood: Introduce MBus DT node
ARM: kirkwood: IntroduceMBUS_ID
ARM: kirkwood: Relocate PCIe device tree nodes
bus: mvebu-mbus: Add devicetree bindingThomas Petazzoni (11):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM: mv78xx0: Move to ID based window creation
ARM: orion5x: Move to ID based window creation
ARM: dove: Move to ID based window creation
PCI: mvebu: Adapt to the new device tree layout
bus: mvebu-mbus: Remove the no longer used name-based API
bus: mvebu-mbus: Remove name -> target, attribute mapping tables
bus: mvebu-mbus: Update main description
bus: mvebu-mbus: Factorize Armada 370/XP data structures
PCI: mvebu: Adapt to the new device tree layout.../devicetree/bindings/bus/mvebu-mbus.txt | 276 +++++++++++++ .../devicetree/bindings/pci/mvebu-pci.txt | 145 +++++-- arch/arm/boot/dts/armada-370-db.dts | 5 +- arch/arm/boot/dts/armada-370-mirabox.dts | 37 +- arch/arm/boot/dts/armada-370-rd.dts | 5 +- arch/arm/boot/dts/armada-370-xp.dtsi | 111 +++--- arch/arm/boot/dts/armada-370.dtsi | 112 +++--- arch/arm/boot/dts/armada-xp-db.dts | 131 +++--- arch/arm/boot/dts/armada-xp-gp.dts | 107 +++-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++++++----- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 263 ++++++------ arch/arm/boot/dts/armada-xp-mv78460.dtsi | 411 ++++++++++--------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 88 ++-- arch/arm/boot/dts/armada-xp.dtsi | 9 +- arch/arm/boot/dts/kirkwood-6281.dtsi | 66 +-- arch/arm/boot/dts/kirkwood-6282.dtsi | 102 ++--- arch/arm/boot/dts/kirkwood-cloudbox.dts | 4 +- arch/arm/boot/dts/kirkwood-db-88f6281.dts | 7 +- arch/arm/boot/dts/kirkwood-db-88f6282.dts | 7 +- arch/arm/boot/dts/kirkwood-db.dtsi | 10 +- arch/arm/boot/dts/kirkwood-dns320.dts | 2 +- arch/arm/boot/dts/kirkwood-dns325.dts | 2 +- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 4 +- arch/arm/boot/dts/kirkwood-dockstar.dts | 4 +- arch/arm/boot/dts/kirkwood-dreamplug.dts | 4 +- arch/arm/boot/dts/kirkwood-goflexnet.dts | 4 +- .../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 4 +- arch/arm/boot/dts/kirkwood-ib62x0.dts | 4 +- arch/arm/boot/dts/kirkwood-iconnect.dts | 23 +- arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 4 +- arch/arm/boot/dts/kirkwood-is2.dts | 2 +- arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 4 +- arch/arm/boot/dts/kirkwood-lschlv2.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxhl.dts | 2 +- arch/arm/boot/dts/kirkwood-lsxl.dtsi | 4 +- arch/arm/boot/dts/kirkwood-mplcec4.dts | 23 +- .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 23 +- arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-ns2.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2lite.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2max.dts | 2 +- arch/arm/boot/dts/kirkwood-ns2mini.dts | 2 +- arch/arm/boot/dts/kirkwood-nsa310.dts | 23 +- arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 4 +- arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 2 +- arch/arm/boot/dts/kirkwood-sheevaplug.dts | 2 +- arch/arm/boot/dts/kirkwood-topkick.dts | 4 +- arch/arm/boot/dts/kirkwood-ts219-6281.dts | 6 +- arch/arm/boot/dts/kirkwood-ts219-6282.dts | 25 +- arch/arm/boot/dts/kirkwood-ts219.dtsi | 17 +- arch/arm/boot/dts/kirkwood.dtsi | 17 +- arch/arm/mach-dove/common.c | 68 ++-- arch/arm/mach-kirkwood/board-dt.c | 1 + arch/arm/mach-kirkwood/common.c | 26 +- arch/arm/mach-kirkwood/pcie.c | 40 +- arch/arm/mach-mv78xx0/pcie.c | 23 +- arch/arm/mach-mvebu/armada-370-xp.c | 34 +- arch/arm/mach-mvebu/platsmp.c | 25 +- arch/arm/mach-orion5x/common.c | 36 +- arch/arm/mach-orion5x/common.h | 17 + arch/arm/mach-orion5x/d2net-setup.c | 6 +- arch/arm/mach-orion5x/db88f5281-setup.c | 24 +- arch/arm/mach-orion5x/dns323-setup.c | 6 +- arch/arm/mach-orion5x/edmini_v2-setup.c | 6 +- arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 +- arch/arm/mach-orion5x/ls-chl-setup.c | 6 +- arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +- arch/arm/mach-orion5x/lsmini-setup.c | 6 +- arch/arm/mach-orion5x/mss2-setup.c | 6 +- arch/arm/mach-orion5x/mv2120-setup.c | 6 +- arch/arm/mach-orion5x/net2big-setup.c | 6 +- arch/arm/mach-orion5x/pci.c | 9 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 6 +- arch/arm/mach-orion5x/rd88f5182-setup.c | 13 +- arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +- arch/arm/mach-orion5x/ts209-setup.c | 6 +- arch/arm/mach-orion5x/ts409-setup.c | 6 +- arch/arm/mach-orion5x/wnr854t-setup.c | 6 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +- drivers/bus/mvebu-mbus.c | 441 ++++++++++++--------- drivers/memory/mvebu-devbus.c | 64 +-- drivers/pci/host/pci-mvebu.c | 115 ++++-- include/linux/mbus.h | 16 +- 85 files changed, 2030 insertions(+), 1379 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txtSignature · 7 lines
1.8.1.5 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com