MBus DT binding: A new hope
Subsystems (6)
v5 cover MBus DT binding: A new hope
See the previous version of this patchset for further context:
http://www.spinics.net/lists/arm-kernel/msg253342.html
This is a new proposal, in an attempt to fix some obscurities in the previous MBus DT binding proposal.
In the current proposal we have now required a 'controller' property to specify the MBus controller MMIO registers. To us this looks more appropriate, since the MBus registers are effectively located within the internal register region, behind the so-called internal-regs window.
Personally, I can't see any disadvantage, and the binding looks much cleaner now. But of course I can be wrong, and I'm open to discussion.
There's another pending issue. Arnd Bergmann has required to add a property to specify the available space within the CPU address space for decoding windows. This property would allow to support fully dynamic mbus window allocation.
For now, this property is intentionally missing, and I expect that it can be added in the future, together with the full-dynamic MBus implementation.
@Arnd, @Jason:
Given the v4 patchset didn't receive any comments but wasn't accepted either, I'd like to know which other pending issues I'm forgetting to address.
As usual, comments and feedback more than welcome. Thanks!
Ezequiel Garcia (12):
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
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Remove the harcoded BootROM window allocation
memory: mvebu-devbus: Remove address decoding window workaround
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 PCIe device tree nodes
ARM: mvebu: Relocate Armada XP PCIe device tree nodes
.../devicetree/bindings/bus/mvebu-mbus.txt | 256 ++++++++++++++ arch/arm/boot/dts/armada-370-db.dts | 5 +- arch/arm/boot/dts/armada-370-mirabox.dts | 38 ++- arch/arm/boot/dts/armada-370-rd.dts | 5 +- arch/arm/boot/dts/armada-370-xp.dtsi | 109 +++--- arch/arm/boot/dts/armada-370.dtsi | 108 +++--- arch/arm/boot/dts/armada-xp-db.dts | 72 ++-- arch/arm/boot/dts/armada-xp-gp.dts | 108 +++--- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 209 ++++++------ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 247 +++++++------- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 379 +++++++++++---------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 84 ++--- arch/arm/boot/dts/armada-xp.dtsi | 9 +- arch/arm/mach-mvebu/armada-370-xp.c | 34 +- arch/arm/mach-mvebu/platsmp.c | 25 +- drivers/bus/mvebu-mbus.c | 209 +++++++++++- drivers/memory/mvebu-devbus.c | 64 +--- include/linux/mbus.h | 1 + 18 files changed, 1186 insertions(+), 776 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
Signature · 1 line
1.8.1.5
PATCH v5 1/12 bus: mvebu-mbus: Factor out initialization details
We 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.
Signed-off-by Thomas Petazzoni <[email protected]>
Signed-off-by Ezequiel Garcia <[email protected]>
--- drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 17 deletions(-)
drivers/bus/mvebu-mbus.c +30 -17
@@ -830,26 +830,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 ;
@@ -870,3 +858,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 v5 2/12 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.
Signed-off-by Thomas Petazzoni <[email protected]>
Signed-off-by Ezequiel Garcia <[email protected]>
--- drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/mbus.h | 1 + 2 files changed, 50 insertions(+)
drivers/bus/mvebu-mbus.c +49 -0
@@ -883,3 +883,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
@@ -68,5 +68,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 v5 3/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- .../devicetree/bindings/bus/mvebu-mbus.txt | 256 +++++++++++++++++++++ drivers/bus/mvebu-mbus.c | 121 +++++++++- 2 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
Documentation/devicetree/bindings/bus/mvebu-mbus.txt new file +256 -0
@@ -0,0 +1,256 @@ + +* Marvell MBus + +Required properties: + +- compatible: Should be set to one of the following: + marvell,armada370-mbus + marvell,armadaxp-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). + +* 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 windows. + +Example: + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + + 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 + AA = 2 for PCI-E + +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(0xf0, 0x02) 0xe0000000 0 0xe0000000 0x8100000 /* pcie */ + 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 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 0xe0000000 MBUS_ID(0xf0, 0x02) 0xe0000000 0 0x08000000 /* non-prefetchable memory */ + 0x81000000 0 0 MBUS_ID(0xf0, 0x02) 0xe8000000 0 0x00100000>; /* downstream I/O */ + + 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>; + }; + }; + };
drivers/bus/mvebu-mbus.c +120 -1
132 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH v5 4/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- 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 ) {mvebu_clocks_init ();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 v5 5/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- 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;
@@ -115,10 +119,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 v5 6/12 memory: mvebu-devbus: Remove address decoding window workaround
In reply to Ezequiel GarciaNow 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.
Cc Greg Kroah-Hartman <[email protected]>
Signed-off-by Ezequiel Garcia <[email protected]>
--- 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 v5 6/12 memory: mvebu-devbus: Remove address decoding window workaround
Quoted 10 lines · Ezequiel Garcia
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.Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Ezequiel Garcia <[email protected]>--- drivers/memory/mvebu-devbus.c | 64 ++----------------------------------------- 1 file changed, 2 insertions(+), 62 deletions(-)
PATCH v5 7/12 ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
In reply to Ezequiel GarciaSigned-off-by Ezequiel Garcia <[email protected]>
--- 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 v5 8/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- 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 | 2 ++ 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, 24 insertions(+), 13 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";
@@ -29,18 +31,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 +2 -0
@@ -30,6 +30,8 @@ }; soc { + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>; + internal-regs { serial at 12000 { clock-frequency = <250000000>;
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
@@ -23,6 +23,8 @@ compatible = "marvell,armadaxp", "marvell,armada-370-xp"; 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 v5 9/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- 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
@@ -25,6 +25,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 v5 10/12 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- arch/arm/boot/dts/armada-370-xp.dtsi | 94 +++++++++++++----------- arch/arm/boot/dts/armada-xp-gp.dts | 60 +++++++-------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 60 +++++++-------- 3 files changed, 110 insertions(+), 104 deletions(-)
arch/arm/boot/dts/armada-370-xp.dtsi +50 -44
@@ -36,6 +36,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>;
@@ -187,50 +237,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-gp.dts +30 -30
72 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +30 -30
72 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH v5 11/12 ARM: mvebu: Relocate Armada 370 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- arch/arm/boot/dts/armada-370-mirabox.dts | 33 +++++------ arch/arm/boot/dts/armada-370.dtsi | 97 ++++++++++++++++---------------- 2 files changed, 66 insertions(+), 64 deletions(-)
arch/arm/boot/dts/armada-370-mirabox.dts +17 -16
@@ -26,8 +26,25 @@ soc { ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + MBUS_ID(0xf0, 0x02) 0xe0000000 0xe0000000 0x8100000 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>;
@@ -122,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.dtsi +49 -48
109 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH v5 12/12 ARM: mvebu: Relocate Armada 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.
Signed-off-by Ezequiel Garcia <[email protected]>
--- arch/arm/boot/dts/armada-xp-db.dts | 67 ++-- arch/arm/boot/dts/armada-xp-gp.dts | 43 +-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 209 ++++++------- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 245 +++++++-------- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 377 ++++++++++++----------- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 +- 6 files changed, 483 insertions(+), 477 deletions(-)
arch/arm/boot/dts/armada-xp-db.dts +34 -33
@@ -31,8 +31,42 @@ soc { ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0xf0, 0x02) 0xe0000000 0 0xe0000000 0x8100000 MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>; + pcie-controller { + status = "okay"; + + /* + * All 6 slots are physically present as + * standard PCIe slots on the board. + */ + pcie at 1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + pcie at 2,0 { + /* Port 0, Lane 1 */ + status = "okay"; + }; + pcie at 3,0 { + /* Port 0, Lane 2 */ + status = "okay"; + }; + pcie at 4,0 { + /* Port 0, Lane 3 */ + status = "okay"; + }; + pcie at 9,0 { + /* Port 2, Lane 0 */ + status = "okay"; + }; + pcie at 10,0 { + /* Port 3, Lane 0 */ + status = "okay"; + }; + }; + internal-regs { serial at 12000 { clock-frequency = <250000000>;
@@ -125,39 +159,6 @@ spi-max-frequency = <20000000>; }; }; - - pcie-controller { - status = "okay"; - - /* - * All 6 slots are physically present as - * standard PCIe slots on the board. - */ - pcie at 1,0 { - /* Port 0, Lane 0 */ - status = "okay"; - }; - pcie at 2,0 { - /* Port 0, Lane 1 */ - status = "okay"; - }; - pcie at 3,0 { - /* Port 0, Lane 2 */ - status = "okay"; - }; - pcie at 4,0 { - /* Port 0, Lane 3 */ - status = "okay"; - }; - pcie at 9,0 { - /* Port 2, Lane 0 */ - status = "okay"; - }; - pcie at 10,0 { - /* Port 3, Lane 0 */ - status = "okay"; - }; - }; }; }; };
arch/arm/boot/dts/armada-xp-gp.dts +22 -21
61 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78230.dtsi +105 -104
221 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78260.dtsi +123 -122
257 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-mv78460.dtsi +189 -188
389 lines not on this page · raw message
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +10 -9
@@ -28,6 +28,7 @@ soc { ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0xf0, 0x02) 0xe0000000 0 0xe0000000 0x8100000 MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
@@ -59,6 +60,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>;
@@ -172,15 +182,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
v5 cover MBus DT binding: A new hope
In reply to Ezequiel GarciaQuoted 4 lines · Ezequiel Garcia
In the current proposal we have now required a 'controller' property to specify the MBus controller MMIO registers. To us this looks more appropriate, since the MBus registers are effectively located within the internal register region, behind the so-called internal-regs window.
Interesting, seems reasonable to me.
Quoted 7 lines
Personally, I can't see any disadvantage, and the binding looks much cleaner now. But of course I can be wrong, and I'm open to discussion.
There's another pending issue. Arnd Bergmann has required to add a property to specify the available space within the CPU address space for decoding windows. This property would allow to support fully dynamic mbus window allocation.
I wonder if this range is implied - eg it is address space not covered by the memory node or any mbus ranges? Is there a situation where that is not sufficient?
Quoted 7 lines
For now, this property is intentionally missing, and I expect that it can be added in the future, together with the full-dynamic MBus implementation.
@Arnd, @Jason: Given the v4 patchset didn't receive any comments but wasn't accepted either, I'd like to know which other pending issues I'm forgetting to address.
I took a quick look and it seems to match what was discussed..
Regards,
Jason
v5 cover MBus DT binding: A new hope
Quoted 5 lines · Jason Gunthorpe
Quoted 3 lines · Ezequiel Garcia
Personally, I can't see any disadvantage, and the binding looks much cleaner now. But of course I can be wrong, and I'm open to discussion.
Quoted 8 lines
Quoted 4 lines
There's another pending issue. Arnd Bergmann has required to add a property to specify the available space within the CPU address space for decoding windows. This property would allow to support fully dynamic mbus window allocation.
I wonder if this range is implied - eg it is address space not covered by the memory node or any mbus ranges? Is there a situation where that is not sufficient?
I think it's sufficient, yes. It feels odd to have the mbus code rely on the contents of the memory node for that, but it would work.
Arnd