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 five patches:

(*) First patch reworks the addr-map code to use void __iomem * where
appropriate instead of u32, as per the suggestion of Arnd Bergmann.

(*) Second 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.

(*) Third 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.

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

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

Changes since v2:
* Remove one more useless (void __iomem *) cast in the Armada 370/XP addr-map.c file, as noticed by Arnd Bergmann.

Changes since v1:
* Use void __iomem * in addr-map code. Suggested by Arnd Bergmann.
* Add Acked-by on patches 2->5 from Gr?gory Cl?ment

Thanks,

Thomas Petazzoni

Use 'void __iomem *' instead of u32 where appropriate in the addr-map code. It requires adding a few casts in SoC-specific addr-map.c files, but those casts will disappear once those SoC are migrated to the device tree, in which case the address will come from the DT instead of from #define values.

---
 arch/arm/mach-dove/addr-map.c               |    2 +-
 arch/arm/mach-kirkwood/addr-map.c           |    5 +++--
 arch/arm/mach-mv78xx0/addr-map.c            |    4 ++--
 arch/arm/mach-orion5x/addr-map.c            |    5 +++--
 arch/arm/plat-orion/addr-map.c              |   11 ++++-------
 arch/arm/plat-orion/include/plat/addr-map.h |    4 ++--
 6 files changed, 15 insertions(+), 16 deletions(-)

index 2a06c01..adb428e 100644
@@ -47,7 +47,7 @@ static inline void __iomem *ddr_map_sc(int i)
 static struct __initdata orion_addr_map_cfg addr_map_cfg = {
 	.num_wins = 8,
 	.remappable_wins = 4,
-	.bridge_virt_base = BRIDGE_VIRT_BASE,
+	.bridge_virt_base = (void __iomem *) BRIDGE_VIRT_BASE,
 };
 
 static const struct __initdata orion_addr_map_info addr_map_info[] = {

index e9a7180..2b27de6 100644
@@ -41,7 +41,7 @@
 static struct __initdata orion_addr_map_cfg addr_map_cfg = {
 	.num_wins = 8,
 	.remappable_wins = 4,
-	.bridge_virt_base = BRIDGE_VIRT_BASE,
+	.bridge_virt_base = (void __iomem *) BRIDGE_VIRT_BASE,
 };
 
 static const struct __initdata orion_addr_map_info addr_map_info[] = {

@@ -86,5 +86,6 @@ void __init kirkwood_setup_cpu_mbus(void)
 	/*
 	 * Setup MBUS dram target info.
 	 */
-	orion_setup_cpu_mbus_target(&addr_map_cfg, DDR_WINDOW_CPU_BASE);
+	orion_setup_cpu_mbus_target(&addr_map_cfg,
+				    (void __iomem *) DDR_WINDOW_CPU_BASE);
 }

index 62b53d7..bac31e4 100644
@@ -71,10 +71,10 @@ void __init mv78xx0_setup_cpu_mbus(void)
 	 */
 	if (mv78xx0_core_index() == 0)
 		orion_setup_cpu_mbus_target(&addr_map_cfg,
-					    DDR_WINDOW_CPU0_BASE);
+					    (void __iomem *) DDR_WINDOW_CPU0_BASE);
 	else
 		orion_setup_cpu_mbus_target(&addr_map_cfg,
-					    DDR_WINDOW_CPU1_BASE);
+					    (void __iomem *) DDR_WINDOW_CPU1_BASE);
 }
 
 void __init mv78xx0_setup_pcie_io_win(int window, u32 base, u32 size,

index eaac83d..bfe4f10 100644
@@ -79,7 +79,7 @@ static int __init cpu_win_can_remap(const struct orion_addr_map_cfg *cfg,
 static struct orion_addr_map_cfg addr_map_cfg __initdata = {
 	.num_wins = 8,
 	.cpu_win_can_remap = cpu_win_can_remap,
-	.bridge_virt_base = ORION5X_BRIDGE_VIRT_BASE,
+	.bridge_virt_base = (void __iomem *) ORION5X_BRIDGE_VIRT_BASE,
 };
 
 static const struct __initdata orion_addr_map_info addr_map_info[] = {

@@ -113,7 +113,8 @@ void __init orion5x_setup_cpu_mbus_bridge(void)
 	/*
 	 * Setup MBUS dram target info.
 	 */
-	orion_setup_cpu_mbus_target(&addr_map_cfg, ORION5X_DDR_WINDOW_CPU_BASE);
+	orion_setup_cpu_mbus_target(&addr_map_cfg,
+				    (void __iomem *) ORION5X_DDR_WINDOW_CPU_BASE);
 }
 
 void __init orion5x_setup_dev_boot_win(u32 base, u32 size)

index 367ca89..a7b8060 100644
@@ -48,7 +48,7 @@ EXPORT_SYMBOL_GPL(mv_mbus_dram_info);
 static void __init __iomem *
 orion_win_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
 {
-	return (void __iomem *)(cfg->bridge_virt_base + (win << 4));
+	return cfg->bridge_virt_base + (win << 4);
 }
 
 /*

@@ -143,19 +143,16 @@ void __init orion_config_wins(struct orion_addr_map_cfg * cfg,
  * Setup MBUS dram target info.
  */
 void __init orion_setup_cpu_mbus_target(const struct orion_addr_map_cfg *cfg,
-					const u32 ddr_window_cpu_base)
+					const void __iomem *ddr_window_cpu_base)
 {
-	void __iomem *addr;
 	int i;
 	int cs;
 
 	orion_mbus_dram_info.mbus_dram_target_id = TARGET_DDR;
 
-	addr = (void __iomem *)ddr_window_cpu_base;
-
 	for (i = 0, cs = 0; i < 4; i++) {
-		u32 base = readl(addr + DDR_BASE_CS_OFF(i));
-		u32 size = readl(addr + DDR_SIZE_CS_OFF(i));
+		u32 base = readl(ddr_window_cpu_base + DDR_BASE_CS_OFF(i));
+		u32 size = readl(ddr_window_cpu_base + DDR_SIZE_CS_OFF(i));
 
 		/*
 		 * Chip select enabled?

index fd556f7..0a746fd 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;
+	void __iomem * const bridge_virt_base;
 
 	/* If NULL, the default cpu_win_can_remap will be used, using
 	   the value in remappable_wins */

@@ -49,5 +49,5 @@ void __init orion_setup_cpu_win(const struct orion_addr_map_cfg *cfg,
 				const u8 attr, const int remap);
 
 void __init orion_setup_cpu_mbus_target(const struct orion_addr_map_cfg *cfg,
-					const u32 ddr_window_cpu_base);
+					const void __iomem *ddr_window_cpu_base);
 #endif

1.7.9.5

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 e91c7cd..a2b6f74 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),

@@ -1154,6 +1155,10 @@ config PLAT_ORION
 	select IRQ_DOMAIN
 	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

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 0a746fd..ec63e4a 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;
-	void __iomem * const bridge_virt_base;
+	void __iomem *bridge_virt_base;
 
 	/* If NULL, the default cpu_win_can_remap will be used, using
 	   the value in remappable_wins */

1.7.9.5

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

---
 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

Whole series applied to:

git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7

thx,

Jason.

I'm getting the following build error with orion_nand enabled:

CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No such file or directory
compilation terminated.

I don't have time to look at it right now, hopefully I can look at it tomorrow or this weekend.

thx,

Jason.

Hello,

Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper <[email protected]> a ?crit :

I have just built your boards-for-v3.7 for Kirkwood (which includes the orion_nand driver) and it builds just fine.

Are you perhaps trying to enable the orion_nand driver for a mach-mvebu platform (Armada 370 or XP)? If it's the case, then yes, this build breakage is expected: we haven't enabled any of the I/O for now, so we don't have hardware.h yet. This is not something that is broken due to the address decoding changes.

If however my guess was wrong, could you send me the failing .config so that I can reproduce and investigate?

Thanks!

Thomas Petazzoni

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

Ok, I've added Arnd and Olof to the CC. The above is exactly what I did.

Arnd, how extensive is the 'make randconfig' testing in next? Is this something that needs to be fixed before we push? I found it by a fluke, but the right randconfig would light it up as well.

thx,

Jason.

If there is a bug you know about, you should fix it. In the above example, I would guess that you should not actually need to include mach/hardware.h, so the fix should be simple. In general, we should eliminate mach/hardware.h where we can and put register locations into resource, and offsets into the drivers themselves.

Arnd

Le Sat, 18 Aug 2012 21:23:03 -0400,
Jason Cooper <[email protected]> a ?crit :

Well, this build failure is not caused by the address decoding changes themselves. So the breakage you're seeing with that particular configuration already exists. We would like to get these address decoding changes merged so that we can make progress on the SMP support.

In parallel to that, we will start enabling the different I/O: network interfaces, SATA, XOR engines, USB, etc. During this work, we'll progressively make all these drivers compatible with mach-mvebu and Armada 370/XP, and therefore fix the build issues like the one you're seeing.

Or maybe, you want me to change the "depends on PLAT_ORION" of the Orion NAND driver to "depends on PLAT_ORION_LEGACY" so that this driver cannot be selected for now with mach-mvebu? As part of the PLAT_ORION -> PLAT_ORION_LEGACY conversion, it would make sense. Of course, I would do it for the other drivers as well (crypto, dma, etc.).

Best regards,

Thomas

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

Thomas,

I have reworked addr-map to allow for both Armada 370/XP and Orion SoCs merging into mach-mvebu. Instead of reusing PLAT_ORION this is totally independent but reusing as much code as possible. I can send it hopefully today if I get it cleaned up. I also have irq-mvebu, irq-orion, and time-mvebu patches that merge code. With that patches booting Dove into mach-mvebu works until DMA kicks in because XOR hasn't event touched for DT support and is still missing.

Armada 370/XP should still work as they do with current patches in for-3.7 with little changes in DT. But that of course must be tested by you.

Sebastian

Le Tue, 21 Aug 2012 12:37:24 +0200,
Sebastian Hesselbarth <[email protected]> a ?crit :

Ok, I will look at your code, but the purpose of PLAT_ORION/PLAT_ORION_LEGACY was not only to re-use the addr-map code, but also to allow drivers to access the header files containing their platform_data structure and other stuff (i.e, all the header files from arch/arm/plat-orion/include/). How do you handle this problem if MACH_MVEBU is not a PLAT_ORION platform?

Thomas

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

Hmm, ok I wasn't aware of that. But I have a bad feeling about joining PLAT_ORION into MACH_MVEBU if you want to have ORION replaced by MVEBU in the future. Maybe it is better here to put all you need into mach-mvebu/include/mach/legacy.h that can be easily abandoned when everything is ported to something more general.

I know it is code duplication but it is only for the purpose of removing PLAT_ORION later on.

Sebastian

Jason,

I investigated a little bit, and found out that orion_nand driver was the only PLAT_ORION driver needing <mach/hardware.h>, and in fact this include was not needed. The attached patch therefore removes this include from orion_nand.

Thanks,

Thomas

Commit c085d965fb63ac3b4cc7379d45588c0b39e2bdb0 made the ARCH_MVEBU platform select PLAT_ORION, which means that now all Orion drivers can be enabled on ARCH_MVEBU. This works fine for most drivers, except for orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does not have a mach/hardware.h header (it is considered as a deprecated practice).

It turns out that the <mach/hardware.h> include in orion_nand is not
necessary: the driver builds perfectly fine without it, so we simply get rid of it.

---
 drivers/mtd/nand/orion_nand.c |    1 -
 1 file changed, 1 deletion(-)

index fc5a868..9ee436d 100644
@@ -21,7 +21,6 @@
 #include <linux/err.h>
 #include <asm/io.h>
 #include <asm/sizes.h>
-#include <mach/hardware.h>
 #include <plat/orion_nand.h>
 
 static void orion_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)

1.7.9.5

Hi Thomas

I compiled tested on Dove, Kirkwood, Orion5x and mv78xx0.

One other driver you might want to look at is:

drivers/watchdog/orion_wdt.c

It uses <mach/bridge-regs.h>

Andrew

Andrew, Thomas,

both current watchdog and timer are using the bridge-regs to clear the interrupt cause. On orion the cause register is located in bridge-regs.

to have the watchdog cause bit also within timer registers.

Sebastian

Le Tue, 28 Aug 2012 11:11:39 +0200,
Andrew Lunn <[email protected]> a ?crit :

Thanks! Will Jason take care of merging this on top of the previous address decoding patches? Note that if you want to keep build bisectability, it should be merged before my "arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option" patch.

This driver is:

config ORION_WATCHDOG
tristate "Orion watchdog"
depends on ARCH_ORION5X || ARCH_KIRKWOOD

so it isn't selectable with ARCH_MVEBU, so it will not cause problems for now. Of course, at some point, we'll have a look at the watchdog driver but for now, it's fine.

Best regards,

Thomas

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

Applied to:

git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2

thx,

Jason.

Pushed to l2-mtd.git, thanks!

Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120829/1f20e517/attachment.sig>