[v3] Add basic address decoding support for Marvell 370/XP

[v3] Add basic address decoding support for Marvell 370/XP

[Thomas Petazzoni]

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

[PATCH 1/5] arm: plat-orion: use 'void __iomem *' in addr-map code

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 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(-)

diff --git a/arch/arm/mach-dove/addr-map.c b/arch/arm/mach-dove/addr-map.c
index 2a06c01..adb428e 100644
--- a/arch/arm/mach-dove/addr-map.c
+++ b/arch/arm/mach-dove/addr-map.c
@@ -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[] = {
diff --git a/arch/arm/mach-kirkwood/addr-map.c b/arch/arm/mach-kirkwood/addr-map.c
index e9a7180..2b27de6 100644
--- a/arch/arm/mach-kirkwood/addr-map.c
+++ b/arch/arm/mach-kirkwood/addr-map.c
@@ -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);
 }
diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
index 62b53d7..bac31e4 100644
--- a/arch/arm/mach-mv78xx0/addr-map.c
+++ b/arch/arm/mach-mv78xx0/addr-map.c
@@ -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,
diff --git a/arch/arm/mach-orion5x/addr-map.c b/arch/arm/mach-orion5x/addr-map.c
index eaac83d..bfe4f10 100644
--- a/arch/arm/mach-orion5x/addr-map.c
+++ b/arch/arm/mach-orion5x/addr-map.c
@@ -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)
diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/plat-orion/addr-map.c
index 367ca89..a7b8060 100644
--- a/arch/arm/plat-orion/addr-map.c
+++ b/arch/arm/plat-orion/addr-map.c
@@ -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?
diff --git a/arch/arm/plat-orion/include/plat/addr-map.h b/arch/arm/plat-orion/include/plat/addr-map.h
index fd556f7..0a746fd 100644
--- a/arch/arm/plat-orion/include/plat/addr-map.h
+++ b/arch/arm/plat-orion/include/plat/addr-map.h
@@ -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

[PATCH 2/5] arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/Kconfig             |   13 +++++++++----
 arch/arm/plat-orion/Makefile |    9 ++++-----
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..a2b6f74 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
 
diff --git a/arch/arm/plat-orion/Makefile b/arch/arm/plat-orion/Makefile
index c20ce0f..1251e5b 100644
--- a/arch/arm/plat-orion/Makefile
+++ b/arch/arm/plat-orion/Makefile
@@ -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

[PATCH 3/5] arm: plat-orion: make bridge_virt_base non-const to support DT use case

[Thomas Petazzoni]

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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/plat-orion/include/plat/addr-map.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/plat-orion/include/plat/addr-map.h b/arch/arm/plat-orion/include/plat/addr-map.h
index 0a746fd..ec63e4a 100644
--- a/arch/arm/plat-orion/include/plat/addr-map.h
+++ b/arch/arm/plat-orion/include/plat/addr-map.h
@@ -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

[PATCH 4/5] arm: mvebu: add basic address decoding support to Armada 370/XP

[Thomas Petazzoni]

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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 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

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index e61d2b8..2143558 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -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
diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-mvebu/addr-map.c
new file mode 100644
index 0000000..fe454a4
--- /dev/null
+++ b/arch/arm/mach-mvebu/addr-map.c
@@ -0,0 +1,134 @@
+/*
+ * Address map functions for Marvell 370 / XP SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mbus.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <plat/addr-map.h>
+
+/*
+ * Generic Address Decode Windows bit settings
+ */
+#define ARMADA_XP_TARGET_DEV_BUS	1
+#define   ARMADA_XP_ATTR_DEV_BOOTROM    0x1D
+#define ARMADA_XP_TARGET_ETH1		3
+#define ARMADA_XP_TARGET_PCIE_0_2	4
+#define ARMADA_XP_TARGET_ETH0		7
+#define ARMADA_XP_TARGET_PCIE_1_3	8
+
+#define ARMADA_370_TARGET_DEV_BUS       1
+#define   ARMADA_370_ATTR_DEV_BOOTROM   0x1D
+#define ARMADA_370_TARGET_PCIE_0        4
+#define ARMADA_370_TARGET_PCIE_1        8
+
+#define ARMADA_WINDOW_8_PLUS_OFFSET       0x90
+#define ARMADA_SDRAM_ADDR_DECODING_OFFSET 0x180
+
+static const struct __initdata orion_addr_map_info
+armada_xp_addr_map_info[] = {
+	/*
+	 * Window for the BootROM, needed for SMP on Armada XP
+	 */
+	{ 0, 0xfff00000, SZ_1M, ARMADA_XP_TARGET_DEV_BUS,
+	  ARMADA_XP_ATTR_DEV_BOOTROM, -1 },
+	/* End marker */
+	{ -1, 0, 0, 0, 0, 0 },
+};
+
+static const struct __initdata orion_addr_map_info
+armada_370_addr_map_info[] = {
+	/* End marker */
+	{ -1, 0, 0, 0, 0, 0 },
+};
+
+static struct of_device_id of_addr_decoding_controller_table[] = {
+	{ .compatible = "marvell,armada-addr-decoding-controller" },
+	{ /* end of list */ },
+};
+
+static void __iomem *
+armada_cfg_base(const struct orion_addr_map_cfg *cfg, int win)
+{
+	unsigned int offset;
+
+	/* The register layout is a bit annoying and the below code
+	 * tries to cope with it.
+	 * - At offset 0x0, there are the registers for the first 8
+	 *   windows, with 4 registers of 32 bits per window (ctrl,
+	 *   base, remap low, remap high)
+	 * - Then at offset 0x80, there is a hole of 0x10 bytes for
+	 *   the internal registers base address and internal units
+	 *   sync barrier register.
+	 * - Then at offset 0x90, there the registers for 12
+	 *   windows, with only 2 registers of 32 bits per window
+	 *   (ctrl, base).
+	 */
+	if (win < 8)
+		offset = (win << 4);
+	else
+		offset = ARMADA_WINDOW_8_PLUS_OFFSET + (win << 3);
+
+	return cfg->bridge_virt_base + offset;
+}
+
+static struct __initdata orion_addr_map_cfg addr_map_cfg = {
+	.num_wins = 20,
+	.remappable_wins = 8,
+	.win_cfg_base = armada_cfg_base,
+};
+
+static int __init armada_setup_cpu_mbus(void)
+{
+	struct device_node *np;
+	void __iomem *mbus_unit_addr_decoding_base;
+	void __iomem *sdram_addr_decoding_base;
+
+	np = of_find_matching_node(NULL, of_addr_decoding_controller_table);
+	if (!np)
+		return -ENODEV;
+
+	mbus_unit_addr_decoding_base = of_iomap(np, 0);
+	BUG_ON(!mbus_unit_addr_decoding_base);
+
+	sdram_addr_decoding_base =
+		mbus_unit_addr_decoding_base +
+		ARMADA_SDRAM_ADDR_DECODING_OFFSET;
+
+	addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
+
+	/*
+	 * Disable, clear and configure windows.
+	 */
+	if (of_machine_is_compatible("marvell,armadaxp"))
+		orion_config_wins(&addr_map_cfg, armada_xp_addr_map_info);
+	else if (of_machine_is_compatible("marvell,armada370"))
+		orion_config_wins(&addr_map_cfg, armada_370_addr_map_info);
+	else {
+		pr_err("Unsupported SoC\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Setup MBUS dram target info.
+	 */
+	orion_setup_cpu_mbus_target(&addr_map_cfg,
+				    sdram_addr_decoding_base);
+	return 0;
+}
+
+/* Using a early_initcall is needed so that this initialization gets
+ * done before the SMP initialization, which requires the BootROM to
+ * be remapped. */
+early_initcall(armada_setup_cpu_mbus);
-- 
1.7.9.5

[PATCH 5/5] arm: mvebu: add address decoding controller to the DT

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 6b6b932..16cc82c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -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

[v3] Add basic address decoding support for Marvell 370/XP

[Jason Cooper]

On Mon, Aug 06, 2012 at 11:42:16AM +0200, Thomas Petazzoni wrote:
> 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

Whole series applied to:

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

thx,

Jason.

[v3] Add basic address decoding support for Marvell 370/XP

[Jason Cooper]

On Thu, Aug 16, 2012 at 09:28:39AM -0400, Jason Cooper wrote:
> On Mon, Aug 06, 2012 at 11:42:16AM +0200, Thomas Petazzoni wrote:
> > 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
> 
> Whole series applied to:
> 
> git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7

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.

[v3] Add basic address decoding support for Marvell 370/XP

[Thomas Petazzoni]

Hello,

Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper <jason@lakedaemon.net> a ?crit :

> > Whole series applied to:
> > 
> > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
> 
> 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.

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

[v3] Add basic address decoding support for Marvell 370/XP

[Jason Cooper]

On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
> Le Thu, 16 Aug 2012 14:37:08 -0400,
> Jason Cooper <jason@lakedaemon.net> a ?crit :
> 
> > > Whole series applied to:
> > > 
> > > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
> > 
> > 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.
> 
> 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.

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.

[v3] Add basic address decoding support for Marvell 370/XP

[Arnd Bergmann]

On Sunday 19 August 2012, Jason Cooper wrote:
> On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
> > Le Thu, 16 Aug 2012 14:37:08 -0400,
> > Jason Cooper <jason@lakedaemon.net> a ?crit :
> > 
> > > > Whole series applied to:
> > > > 
> > > > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.

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

[v3] Add basic address decoding support for Marvell 370/XP

[Thomas Petazzoni]

Le Sat, 18 Aug 2012 21:23:03 -0400,
Jason Cooper <jason@lakedaemon.net> a ?crit :

> On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
> > Le Thu, 16 Aug 2012 14:37:08 -0400,
> > Jason Cooper <jason@lakedaemon.net> a ?crit :
> > 
> > > > Whole series applied to:
> > > > 
> > > > git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.

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

[v3] Add basic address decoding support for Marvell 370/XP

[Sebastian Hesselbarth]

On 8/21/12, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 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.).

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

[v3] Add basic address decoding support for Marvell 370/XP

[Thomas Petazzoni]

Le Tue, 21 Aug 2012 12:37:24 +0200,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> a ?crit :

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

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

[v3] Add basic address decoding support for Marvell 370/XP

[Sebastian Hesselbarth]

On 8/21/12, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 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?

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

Fix orion_nand build on ARCH_MVEBU

[Thomas Petazzoni]

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

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Thomas Petazzoni]

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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd at lists.infradead.org
Cc: Artem Bityutskiy <dedekind1@gmail.com>
---
 drivers/mtd/nand/orion_nand.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index fc5a868..9ee436d 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -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

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Andrew Lunn]

On Tue, Aug 28, 2012 at 01:35:28AM +0200, Thomas Petazzoni wrote:
> 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.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linux-mtd at lists.infradead.org
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> ---
>  drivers/mtd/nand/orion_nand.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index fc5a868..9ee436d 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -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.

Tested-by: Andrew Lunn <andrew@lunn.ch>

One other driver you might want to look at is:

drivers/watchdog/orion_wdt.c

It uses <mach/bridge-regs.h>

   Andrew

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Sebastian Hesselbarth]

On 8/28/12, Andrew Lunn <andrew@lunn.ch> wrote:
> One other driver you might want to look at is:
>
> drivers/watchdog/orion_wdt.c
> It uses <mach/bridge-regs.h>

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.
>From the work on timer together with Gregory, I expect Armada 370/XP
to have the watchdog cause bit also within timer registers.

Sebastian

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Thomas Petazzoni]

Le Tue, 28 Aug 2012 11:11:39 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :

> I compiled tested on Dove, Kirkwood, Orion5x and mv78xx0.
> 
> Tested-by: Andrew Lunn <andrew@lunn.ch>

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.

> One other driver you might want to look at is:
> 
> drivers/watchdog/orion_wdt.c
> 
> It uses <mach/bridge-regs.h>

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

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Jason Cooper]

On Tue, Aug 28, 2012 at 01:35:28AM +0200, Thomas Petazzoni wrote:
> 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.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linux-mtd at lists.infradead.org
> Cc: Artem Bityutskiy <dedekind1@gmail.com>

Applied to:

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

thx,

Jason.

[PATCH] mtd: orion_nand: remove <mach/hardware.h> include

[Artem Bityutskiy]

On Tue, 2012-08-28 at 01:35 +0200, Thomas Petazzoni wrote:
> 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.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

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>