arm: mvebu: Add basic address decoding support for Marvell 370/XP

Andrew, Jason, Gr?gory,

Here is a small patch set that introduces basic support for address decoding on Armada 370 and Armada XP. The aim of this basic support is essentially to be able to configure a window to remap the BootROM, which is needed to startup the secondary CPUs for the SMP support.

As we had discussed already, the address decoding configuration is not described in the Device Tree, it is for now hardcoded on a per-SoC basis. We might later discuss how to extend this to the Device Tree.

This patch set has four patches:

(*) First patch introducing PLAT_ORION_LEGACY, which allows the
Marvell 370/XP platforms to be part of PLAT_ORION, and therefore re-use the existing address decoding code.

(*) Second patch making a small change to an address decoding
structure so that we can define at runtime the virtual address of the configuration registers. This is needed as on Armada 370/XP the address decoding "controller" is declared in the Device Tree.

(*) Third patch adding the 370/XP address decoding code itself. For
now, it only maps the BootROM on Armada XP.

(*) Fourth path adding the necessary DT code to instantiate the
address decoding "controller".

Thanks,

Thomas Petazzoni

Until now, the PLAT_ORION configuration option was common to all the Marvell EBU SoCs, and selecting this option had the effect of enabling the MPP code, GPIO code, address decoding and PCIe code from plat-orion, as well as providing access to driver-specific header files from plat-orion/include.

However, the Armada 370 and XP SoCs will not use the MPP and GPIO code (instead some proper pinctrl and gpio drivers are in preparation), and generally, we want to move away from plat-orion and instead have everything in mach-mvebu.

That said, in the mean time, we want to leverage the driver-specific headers as well as the address decoding code, so we introduce PLAT_ORION_LEGACY. The older Marvell SoCs need to select PLAT_ORION_LEGACY, while the newer Marvell SoCs need to select PLAT_ORION. Of course, when PLAT_ORION_LEGACY is selected, it automatically selects PLAT_ORION.

Then, with just PLAT_ORION, you have the address decoding code plus the driver-specific headers. If you add PLAT_ORION_LEGACY to this, you gain the old MPP, GPIO and PCIe code.

Again, this is only a temporary solution until we make all Marvell EBU platforms converge into the mach-mvebu directory. This solution avoids duplicating the existing address decoding code into mach-mvebu.

---
 arch/arm/Kconfig             |   13 +++++++++----
 arch/arm/plat-orion/Makefile |    9 ++++-----
 2 files changed, 13 insertions(+), 9 deletions(-)

index 7980873..fc36a93 100644
@@ -573,6 +573,7 @@ config ARCH_MVEBU
 	select GENERIC_IRQ_CHIP
 	select IRQ_DOMAIN
 	select COMMON_CLK
+	select PLAT_ORION
 	help
 	  Support for the Marvell SoC Family with device tree support
 

@@ -583,7 +584,7 @@ config ARCH_DOVE
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select NEED_MACH_IO_H
-	select PLAT_ORION
+	select PLAT_ORION_LEGACY
 	help
 	  Support for the Marvell Dove SoC 88AP510
 

@@ -594,7 +595,7 @@ config ARCH_KIRKWOOD
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select NEED_MACH_IO_H
-	select PLAT_ORION
+	select PLAT_ORION_LEGACY
 	help
 	  Support for the following Marvell Kirkwood series SoCs:
 	  88F6180, 88F6192 and 88F6281.

@@ -621,7 +622,7 @@ config ARCH_MV78XX0
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select NEED_MACH_IO_H
-	select PLAT_ORION
+	select PLAT_ORION_LEGACY
 	help
 	  Support for the following Marvell MV78xx0 series SoCs:
 	  MV781x0, MV782x0.

@@ -634,7 +635,7 @@ config ARCH_ORION5X
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select NEED_MACH_IO_H
-	select PLAT_ORION
+	select PLAT_ORION_LEGACY
 	help
 	  Support for the following Marvell Orion 5x series SoCs:
 	  Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182),

@@ -1153,6 +1154,10 @@ config PLAT_ORION
 	select GENERIC_IRQ_CHIP
 	select COMMON_CLK
 
+config PLAT_ORION_LEGACY
+	bool
+	select PLAT_ORION
+
 config PLAT_PXA
 	bool
 

index c20ce0f..1251e5b 100644
@@ -2,9 +2,8 @@
 # Makefile for the linux kernel.
 #
 
-obj-y	:= irq.o pcie.o time.o common.o mpp.o addr-map.o
-obj-m	:=
-obj-n	:=
-obj-	:=
+obj-y                             += addr-map.o
 
-obj-$(CONFIG_GENERIC_GPIO) += gpio.o
+orion-gpio-$(CONFIG_GENERIC_GPIO) += gpio.o
+obj-$(CONFIG_PLAT_ORION_LEGACY)   += irq.o pcie.o time.o common.o mpp.o
+obj-$(CONFIG_PLAT_ORION_LEGACY)   += $(orion-gpio-y)

1.7.9.5

[...]

Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

For the Armada 370 and XP SoCs where the DT is used, we need to fill at runtime the bridge_virt_base field on the orion_addr_map_cfg. Therefore, remove the 'const' qualifier on this field.

---
 arch/arm/plat-orion/include/plat/addr-map.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index fd556f7..aafdd79 100644
@@ -16,7 +16,7 @@ extern struct mbus_dram_target_info orion_mbus_dram_info;
 struct orion_addr_map_cfg {
 	const int num_wins;	/* Total number of windows */
 	const int remappable_wins;
-	const u32 bridge_virt_base;
+	u32 bridge_virt_base;
 
 	/* If NULL, the default cpu_win_can_remap will be used, using
 	   the value in remappable_wins */

1.7.9.5

[...]

Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Le Fri, 3 Aug 2012 13:41:32 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Yeah, I was also thinking about this cleanup. Will rework my patch series to include a patch fixing this before doing the other changes.

Thanks!

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

This commit adds basic support for address decoding configuration for the Armada 370 and Armada XP SoCs, re-using the infrastructure provided in plat-orion.

For now, only a BootROM window is configured on Armada XP, which is needed to get the non-boot CPUs started and is therefore a requirement for SMP support.

---
 arch/arm/mach-mvebu/Makefile   |    2 +-
 arch/arm/mach-mvebu/addr-map.c |  134 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mvebu/addr-map.c

index e61d2b8..2143558 100644
@@ -1,2 +1,2 @@
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o

1.7.9.5

[...]

Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

---
 arch/arm/boot/dts/armada-370-xp.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

index 6b6b932..16cc82c 100644
@@ -63,6 +63,11 @@
 			       reg = <0xd0020300 0x30>;
 			       interrupts = <37>, <38>, <39>, <40>;
 		};
+
+		addr-decoding at d0020000 {
+			compatible = "marvell,armada-addr-decoding-controller";
+			reg = <0xd0020000 0x258>;
+		};
 	};
 };
 

1.7.9.5

Makes sense. I wonder if there is a proper way to describe the setting in the device tree anyway, given that there is more than one valid option to do it.

Arnd

Le Fri, 3 Aug 2012 14:23:09 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Well, we could do something like:

addr-decoding at d0020000 {
        compatible = "marvell,armada-addr-decoding-controller";
        reg = <0xd0020000 0x258>;

        window at 0 {
		/* Window number */
		cell-index = <0>;                             

		/* Physical address and size at which the device will be mapped. */
		reg = <0xfff00000 0x100000>;

		/* Which device is being mapped. Can either have 1
		   integer (for "big" devices) or 2 integers (for devices
		   in the "Device Bus") */
                marvell,target = <0x1 0x1d>;

		/* Optional. Remapping address */
		marvell,remap = <...>;
	};

	window at 12 {
		cell-index = <12>;
		reg = <0x... 0x....>;
		marvell,target = <0x4>;
	};
};

This is just a rough draft, just written in the mail, I haven't even tried writing code that would work with it, but it should be relatively easy to do.

Would that make sense? Of course, suggestions welcome, I'm not an expert on how to decide what is the best DT encoding for such data.

Best regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

The point that I'm wondering about is where the physical address comes from. This one is not describing the hardware at all, and the OS is free to pick any other address, so why would be put that particular one into the device tree?

Maybe you can find a way to better represent the actual address hierarchy in a way that shows the remapping. I don't understand how the remapping works, but I think what we would need for this is an intermediate large address space and a ranges property that translate the large addresses into bus addresses, but with the option of the driver for that intermediate bus overriding the mapping.

remapped-bus at d0020000 {
	compatible = "marvell,armada-addr-decoding-controller";
	reg = <0xd0020000 0x258>;
	#address-cells = <3>;
	#size-cells = <1>;
	ranges = <0x1 0x1d 0x0     /* device 1 address */
		  0xfff00000	   /* host address */
		  0x100000>	   /* length */
		 <02 0x1e 0x0	   /* device 2 address */
		  0xffe00000	   /* host address */
		  0x100000>	   /* length */

	device at 1.1d.0 {
		compatible = "some-device";
		reg = <0x1 0x1d 0x0 0x5000>
	};
};

Arnd