[PATCH 00/21] Move DT kirkwood into mach-mvebu

[PATCH 00/21] Move DT kirkwood into mach-mvebu

[Andrew Lunn]

The process of making most kirkwood boards boot using DT is nearly
complete. We can now move these boards into mach-mvebu, freeing them
of the legacy code needed for none-DT systems. At the same time, they
can become part of ARCH_MULTI_V5.

Andrew Lunn (21):
  ARM: Kirkwood: Give pm.c its own header file.
  IRQ: Orion: Fix getting generic chip pointer.
  ARM: Kirkwood: Convert mv88f6281gtw_ge switch setup to DT
  ARM: Kirkwood: Drop printing the SoC type and revision
  ARM: Kirkwood: Seperate board-dt from common and pcie code.
  ARM: Kirkwood: ioremap the cpu_config register before using it.
  ARM: Kirkwood: ioremap memory control register
  ARM: MVEBU: Add ARCH_MULTI_V7 to SoCs
  ARM: Orion: Move cache-feroceon-l2.h out of plat-orion
  ARM: MM: Add DT binding for Feroceon L2 cache
  ARM: Fix default CPU selection for ARCH_MULTI_V5
  ARM: Fix MULTI_TLB for feroceon
  ARM: MM Enable building Feroceon L2 cache controller with ARCH_MVEBU
  ARM: Move kirkwood DT boards into mach-mvebu
  ARM: MVEBU: Let kirkwood use the system controller for restart
  drivers: Enable building of Kirkwood drivers for mach-mvebu
  ARM: MVEBU: Enable mvebu-soc-id on Kirkwood
  ARM: config: Add a multi_v5_defconfig
  ARM: MVEBU: Simplifiy headers and make local
  ARM: MVEBU: Remove unneeded headers
  ARM: Kirkwood: Remove DT support

 .../devicetree/bindings/arm/mrvl/forocean.txt      |  19 +++
 arch/arm/Kconfig                                   |   2 +-
 arch/arm/boot/dts/Makefile                         |  34 ++--
 arch/arm/boot/dts/kirkwood.dtsi                    |  10 ++
 arch/arm/configs/kirkwood_defconfig                |   6 -
 arch/arm/configs/multi_v5_defconfig                | 183 ++++++++++++++++++++
 arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  13 ++
 arch/arm/mach-kirkwood/Kconfig                     |  25 ---
 arch/arm/mach-kirkwood/Makefile                    |   6 +-
 arch/arm/mach-kirkwood/Module.symvers              |   0
 arch/arm/mach-kirkwood/board-dt.c                  | 150 ----------------
 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c     |  50 ------
 arch/arm/mach-kirkwood/common.c                    |   3 +-
 arch/arm/mach-kirkwood/common.h                    |  13 --
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h  |   2 +
 arch/arm/mach-kirkwood/pm.c                        |   9 +-
 arch/arm/mach-kirkwood/pm.h                        |  26 +++
 arch/arm/mach-mv78xx0/common.c                     |   2 +-
 arch/arm/mach-mvebu/Kconfig                        |  28 ++-
 arch/arm/mach-mvebu/Makefile                       |   1 +
 arch/arm/mach-mvebu/kirkwood-pm.c                  |  76 +++++++++
 arch/arm/mach-mvebu/kirkwood-pm.h                  |  26 +++
 arch/arm/mach-mvebu/kirkwood.c                     | 189 +++++++++++++++++++++
 arch/arm/mach-mvebu/kirkwood.h                     |  22 +++
 arch/arm/mach-mvebu/mvebu-soc-id.c                 |   1 +
 arch/arm/mm/Kconfig                                |   2 +-
 arch/arm/mm/cache-feroceon-l2.c                    |  48 +++++-
 arch/arm/mm/proc-feroceon.S                        |   2 +-
 arch/arm/mm/tlb-v4wbi.S                            |   3 +
 .../plat-orion/include/plat/cache-feroceon-l2.h    |  11 --
 drivers/cpufreq/Kconfig.arm                        |   2 +-
 drivers/cpuidle/Kconfig.arm                        |   2 +-
 drivers/irqchip/irq-orion.c                        |   3 +-
 drivers/leds/Kconfig                               |   4 +-
 drivers/phy/Kconfig                                |   2 +-
 drivers/thermal/Kconfig                            |   2 +-
 sound/soc/kirkwood/Kconfig                         |   2 +-
 37 files changed, 682 insertions(+), 297 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mrvl/forocean.txt
 create mode 100644 arch/arm/configs/multi_v5_defconfig
 create mode 100644 arch/arm/include/asm/hardware/cache-feroceon-l2.h
 create mode 100644 arch/arm/mach-kirkwood/Module.symvers
 delete mode 100644 arch/arm/mach-kirkwood/board-dt.c
 delete mode 100644 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
 create mode 100644 arch/arm/mach-kirkwood/pm.h
 create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.c
 create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.h
 create mode 100644 arch/arm/mach-mvebu/kirkwood.c
 create mode 100644 arch/arm/mach-mvebu/kirkwood.h
 delete mode 100644 arch/arm/plat-orion/include/plat/cache-feroceon-l2.h

-- 
1.8.5.3

[PATCH 01/21] ARM: Kirkwood: Give pm.c its own header file.

[Andrew Lunn]

The pm code needs to be seperated from common.h in order to split DT
and non-DT systems apart. Move the declarations into a header file of
its own and include it where needed.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/board-dt.c |  1 +
 arch/arm/mach-kirkwood/common.c   |  1 +
 arch/arm/mach-kirkwood/common.h   |  6 ------
 arch/arm/mach-kirkwood/pm.h       | 26 ++++++++++++++++++++++++++
 4 files changed, 28 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-kirkwood/pm.h

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 78188159484d..ceffdc8ffbbd 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -24,6 +24,7 @@
 #include <mach/bridge-regs.h>
 #include <plat/common.h>
 #include "common.h"
+#include "pm.h"
 
 #define MV643XX_ETH_MAC_ADDR_LOW	0x0414
 #define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index f3407a5db216..52aca25432a7 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -36,6 +36,7 @@
 #include <plat/time.h>
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
+#include "pm.h"
 
 /* These can go away once Kirkwood uses the mvebu-mbus DT binding */
 #define KIRKWOOD_MBUS_NAND_TARGET 0x01
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 05fd648df543..1296de94febf 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -58,12 +58,6 @@ void kirkwood_cpufreq_init(void);
 void kirkwood_restart(enum reboot_mode, const char *);
 void kirkwood_clk_init(void);
 
-#ifdef CONFIG_PM
-void kirkwood_pm_init(void);
-#else
-static inline void kirkwood_pm_init(void) {};
-#endif
-
 /* board init functions for boards not fully converted to fdt */
 #ifdef CONFIG_MACH_MV88F6281GTW_GE_DT
 void mv88f6281gtw_ge_init(void);
diff --git a/arch/arm/mach-kirkwood/pm.h b/arch/arm/mach-kirkwood/pm.h
new file mode 100644
index 000000000000..21e7530f368b
--- /dev/null
+++ b/arch/arm/mach-kirkwood/pm.h
@@ -0,0 +1,26 @@
+/*
+ * Power Management driver for Marvell Kirkwood SoCs
+ *
+ * Copyright (C) 2013 Ezequiel Garcia <ezequiel@free-electrons.com>
+ * Copyright (C) 2010 Simon Guinot <sguinot@lacie.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License,
+ * version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_KIRKWOOD_PM_H
+#define __ARCH_KIRKWOOD_PM_H
+
+#ifdef CONFIG_PM
+void kirkwood_pm_init(void);
+#else
+static inline void kirkwood_pm_init(void) {};
+#endif
+
+#endif
-- 
1.8.5.3

[PATCH 02/21] IRQ: Orion: Fix getting generic chip pointer.

[Andrew Lunn]

Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/irqchip/irq-orion.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index e51d40031884..7d4e189ab4ec 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -111,7 +111,8 @@ IRQCHIP_DECLARE(orion_intc, "marvell,orion-intc", orion_irq_init);
 static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
 	struct irq_domain *d = irq_get_handler_data(irq);
-	struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, irq);
+
+	struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
 	u32 stat = readl_relaxed(gc->reg_base + ORION_BRIDGE_IRQ_CAUSE) &
 		   gc->mask_cache;
 
-- 
1.8.5.3

[PATCH 02/21] IRQ: Orion: Fix getting generic chip pointer.

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:41:58AM +0100, Andrew Lunn wrote:
> Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
> handler. The bridge interrupt is implemented using a single generic
> chip. Thus the parameter passed to irq_get_domain_generic_chip()
> should always be zero.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/irqchip/irq-orion.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

applied to mvebu-next/irqchip-fixes with:

Fixes: 9dbd90f17e4f ("irqchip: Add support for Marvell Orion SoCs")
Cc: <stable@vger.kernel.org> # v3.11+

thx,

Jason.

[PATCH 02/21] IRQ: Orion: Fix getting generic chip pointer.

[Sebastian Hesselbarth]

On 02/07/2014 12:41 AM, Andrew Lunn wrote:
> Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
> handler. The bridge interrupt is implemented using a single generic
> chip. Thus the parameter passed to irq_get_domain_generic_chip()
> should always be zero.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Indeed, I remember we talked about it: irq_get_domain_generic_chip takes
hwirqs, so passing 0 is sane here.

Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

> ---
>   drivers/irqchip/irq-orion.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
> index e51d40031884..7d4e189ab4ec 100644
> --- a/drivers/irqchip/irq-orion.c
> +++ b/drivers/irqchip/irq-orion.c
> @@ -111,7 +111,8 @@ IRQCHIP_DECLARE(orion_intc, "marvell,orion-intc", orion_irq_init);
>   static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
>   {
>   	struct irq_domain *d = irq_get_handler_data(irq);
> -	struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, irq);
> +
> +	struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
>   	u32 stat = readl_relaxed(gc->reg_base + ORION_BRIDGE_IRQ_CAUSE) &
>   		   gc->mask_cache;
>
>

[PATCH 02/21] IRQ: Orion: Fix getting generic chip pointer.

[Jason Cooper]

On Fri, Feb 07, 2014 at 11:32:57PM +0100, Sebastian Hesselbarth wrote:
> On 02/07/2014 12:41 AM, Andrew Lunn wrote:
> >Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
> >handler. The bridge interrupt is implemented using a single generic
> >chip. Thus the parameter passed to irq_get_domain_generic_chip()
> >should always be zero.
> >
> >Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> 
> Indeed, I remember we talked about it: irq_get_domain_generic_chip takes
> hwirqs, so passing 0 is sane here.
> 
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Added and pushed to mvebu-next/irqchip-fixes

thx,

Jason.

[PATCH 03/21] ARM: Kirkwood: Convert mv88f6281gtw_ge switch setup to DT

[Andrew Lunn]

The mv88f6281gtw_ge has a ethernet switch connected to the ethernet
port of the SoC. Convert the platform device instantiationn to a DT
instantiation.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/Kconfig                 |  7 ----
 arch/arm/mach-kirkwood/Makefile                |  1 -
 arch/arm/mach-kirkwood/Module.symvers          |  0
 arch/arm/mach-kirkwood/board-dt.c              |  3 --
 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c | 50 --------------------------
 arch/arm/mach-kirkwood/common.h                |  7 ----
 6 files changed, 68 deletions(-)
 create mode 100644 arch/arm/mach-kirkwood/Module.symvers
 delete mode 100644 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index fe8319ad3158..df4b26340ae4 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -106,13 +106,6 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
-config MACH_MV88F6281GTW_GE_DT
-	bool "Marvell 88F6281 GTW GE Board (Flattened Device Tree)"
-	depends on ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell 88F6281 GTW GE Board (Flattened Device Tree).
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 144b51102939..dc22bf5b21ed 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -13,4 +13,3 @@ obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
-obj-$(CONFIG_MACH_MV88F6281GTW_GE_DT)	+= board-mv88f6281gtw_ge.o
diff --git a/arch/arm/mach-kirkwood/Module.symvers b/arch/arm/mach-kirkwood/Module.symvers
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index ceffdc8ffbbd..e74b31aa9736 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -131,9 +131,6 @@ static void __init kirkwood_dt_init(void)
 	kexec_reinit = kirkwood_enable_pcie;
 #endif
 
-	if (of_machine_is_compatible("marvell,mv88f6281gtw-ge"))
-		mv88f6281gtw_ge_init();
-
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
diff --git a/arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c b/arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
deleted file mode 100644
index ee5eea678c11..000000000000
--- a/arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
- *
- * Marvell 88F6281 GTW GE Board Setup
- *
- * 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/platform_device.h>
-#include <linux/irq.h>
-#include <linux/timer.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/ethtool.h>
-#include <linux/gpio.h>
-#include <net/dsa.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/pci.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data mv88f6281gtw_ge_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_NONE,
-	.speed		= SPEED_1000,
-	.duplex		= DUPLEX_FULL,
-};
-
-static struct dsa_chip_data mv88f6281gtw_ge_switch_chip_data = {
-	.port_names[0]	= "lan1",
-	.port_names[1]	= "lan2",
-	.port_names[2]	= "lan3",
-	.port_names[3]	= "lan4",
-	.port_names[4]	= "wan",
-	.port_names[5]	= "cpu",
-};
-
-static struct dsa_platform_data mv88f6281gtw_ge_switch_plat_data = {
-	.nr_chips	= 1,
-	.chip		= &mv88f6281gtw_ge_switch_chip_data,
-};
-
-void __init mv88f6281gtw_ge_init(void)
-{
-	kirkwood_ge00_init(&mv88f6281gtw_ge_ge00_data);
-	kirkwood_ge00_switch_init(&mv88f6281gtw_ge_switch_plat_data, NO_IRQ);
-}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 1296de94febf..832a4e2ab8d7 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -58,13 +58,6 @@ void kirkwood_cpufreq_init(void);
 void kirkwood_restart(enum reboot_mode, const char *);
 void kirkwood_clk_init(void);
 
-/* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_MV88F6281GTW_GE_DT
-void mv88f6281gtw_ge_init(void);
-#else
-static inline void mv88f6281gtw_ge_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.8.5.3

[PATCH 03/21] ARM: Kirkwood: Convert mv88f6281gtw_ge switch setup to DT

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri,  7 Feb 2014 00:41:59 +0100, Andrew Lunn wrote:
> The mv88f6281gtw_ge has a ethernet switch connected to the ethernet
> port of the SoC. Convert the platform device instantiationn to a DT
> instantiation.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/mach-kirkwood/Kconfig                 |  7 ----
>  arch/arm/mach-kirkwood/Makefile                |  1 -
>  arch/arm/mach-kirkwood/Module.symvers          |  0
>  arch/arm/mach-kirkwood/board-dt.c              |  3 --
>  arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c | 50 --------------------------
>  arch/arm/mach-kirkwood/common.h                |  7 ----
>  6 files changed, 68 deletions(-)
>  create mode 100644 arch/arm/mach-kirkwood/Module.symvers

This is probably a mistake.

>  delete mode 100644 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c

Hum, I maybe missed something, but where are the corresponding DT
informations added to replace the C description of the Ethernet switch?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 03/21] ARM: Kirkwood: Convert mv88f6281gtw_ge switch setup to DT

[Andrew Lunn]

On Fri, Feb 07, 2014 at 09:25:05AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri,  7 Feb 2014 00:41:59 +0100, Andrew Lunn wrote:
> > The mv88f6281gtw_ge has a ethernet switch connected to the ethernet
> > port of the SoC. Convert the platform device instantiationn to a DT
> > instantiation.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/mach-kirkwood/Kconfig                 |  7 ----
> >  arch/arm/mach-kirkwood/Makefile                |  1 -
> >  arch/arm/mach-kirkwood/Module.symvers          |  0
> >  arch/arm/mach-kirkwood/board-dt.c              |  3 --
> >  arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c | 50 --------------------------
> >  arch/arm/mach-kirkwood/common.h                |  7 ----
> >  6 files changed, 68 deletions(-)
> >  create mode 100644 arch/arm/mach-kirkwood/Module.symvers
> 
> This is probably a mistake.
> 
> >  delete mode 100644 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
> 
> Hum, I maybe missed something, but where are the corresponding DT
> informations added to replace the C description of the Ethernet switch?

Hi Thomas

Yes, i screwed that patch up somewhere.

It will be fixed in v2.

   Andrew

[PATCH 04/21] ARM: Kirkwood: Drop printing the SoC type and revision

[Andrew Lunn]

This will be added back using the mach-mvebu equivelent once the move
has been made.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/board-dt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e74b31aa9736..a0c0ff39788e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -107,8 +107,6 @@ eth_fixup_skip:
 
 static void __init kirkwood_dt_init(void)
 {
-	pr_info("Kirkwood: %s.\n", kirkwood_id());
-
 	/*
 	 * Disable propagation of mbus errors to the CPU local bus,
 	 * as this causes mbus errors (which can occur for example
-- 
1.8.5.3

[PATCH 05/21] ARM: Kirkwood: Seperate board-dt from common and pcie code.

[Andrew Lunn]

In order to be able to move DT support into mach-mvebu, the DT code
needs to be cleanly separated from common and pcie code. Import the
needed bits of these files into board-dt.c. The "common" code then
becomes purely legacy, supporting none DT boards, so reflect this in
the Makefile targets.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/Makefile   |  3 +-
 arch/arm/mach-kirkwood/board-dt.c | 88 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 88 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index dc22bf5b21ed..3a72c5c6e747 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,5 +1,4 @@
-obj-y				+= common.o pcie.o
-obj-$(CONFIG_KIRKWOOD_LEGACY)	+= irq.o mpp.o
+obj-$(CONFIG_KIRKWOOD_LEGACY)	+= irq.o mpp.o common.o pcie.o
 obj-$(CONFIG_PM)		+= pm.o
 
 obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index a0c0ff39788e..64151a4a378f 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -21,11 +21,97 @@
 #include <linux/irqchip.h>
 #include <linux/kexec.h>
 #include <asm/mach/arch.h>
+#include <asm/mach/map.h>
 #include <mach/bridge-regs.h>
 #include <plat/common.h>
-#include "common.h"
+#include <plat/cache-feroceon-l2.h>
+#include <plat/pcie.h>
 #include "pm.h"
 
+static struct map_desc kirkwood_io_desc[] __initdata = {
+	{
+		.virtual	= (unsigned long) KIRKWOOD_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(KIRKWOOD_REGS_PHYS_BASE),
+		.length		= KIRKWOOD_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+static void __init kirkwood_map_io(void)
+{
+	iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc));
+}
+
+static void __init kirkwood_l2_init(void)
+{
+#ifdef CONFIG_CACHE_FEROCEON_L2
+#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
+	writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG);
+	feroceon_l2_init(1);
+#else
+	writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG);
+	feroceon_l2_init(0);
+#endif
+#endif
+}
+
+static struct resource kirkwood_cpufreq_resources[] = {
+	[0] = {
+		.start  = CPU_CONTROL_PHYS,
+		.end    = CPU_CONTROL_PHYS + 3,
+		.flags  = IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device kirkwood_cpufreq_device = {
+	.name		= "kirkwood-cpufreq",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(kirkwood_cpufreq_resources),
+	.resource	= kirkwood_cpufreq_resources,
+};
+
+static void __init kirkwood_cpufreq_init(void)
+{
+	platform_device_register(&kirkwood_cpufreq_device);
+}
+
+static struct resource kirkwood_cpuidle_resource[] = {
+	{
+		.flags	= IORESOURCE_MEM,
+		.start	= DDR_OPERATION_BASE,
+		.end	= DDR_OPERATION_BASE + 3,
+	},
+};
+
+static struct platform_device kirkwood_cpuidle = {
+	.name		= "kirkwood_cpuidle",
+	.id		= -1,
+	.resource	= kirkwood_cpuidle_resource,
+	.num_resources	= 1,
+};
+
+static void __init kirkwood_cpuidle_init(void)
+{
+	platform_device_register(&kirkwood_cpuidle);
+}
+
+/* Temporary here since mach-mvebu has a function we can use */
+static void kirkwood_restart(enum reboot_mode mode, const char *cmd)
+{
+	/*
+	 * Enable soft reset to assert RSTOUTn.
+	 */
+	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
+
+	/*
+	 * Assert soft reset.
+	 */
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
+
+	while (1)
+		;
+}
+
 #define MV643XX_ETH_MAC_ADDR_LOW	0x0414
 #define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
 
-- 
1.8.5.3

[PATCH 06/21] ARM: Kirkwood: ioremap the cpu_config register before using it.

[Andrew Lunn]

With the move to mach-mvebu and MULTI_V5, the global iomap for all
registers will be going away. So explicitly map the CPU configuration
register before using it.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/board-dt.c                 | 22 +++++++++++++++-------
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  1 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 64151a4a378f..91b61a971af2 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -191,15 +191,23 @@ eth_fixup_skip:
 	}
 }
 
+/*
+ * Disable propagation of mbus errors to the CPU local bus, as this
+ * causes mbus errors (which can occur for example for PCI aborts) to
+ * throw CPU aborts, which we're not set up to deal with.
+ */
+void kirkwood_disable_mbus_error_propagation(void)
+{
+	void __iomem *cpu_config;
+
+	cpu_config = ioremap(CPU_CONFIG_PHYS, 4);
+	writel(readl(cpu_config) & ~CPU_CONFIG_ERROR_PROP, cpu_config);
+}
+
+
 static void __init kirkwood_dt_init(void)
 {
-	/*
-	 * Disable propagation of mbus errors to the CPU local bus,
-	 * as this causes mbus errors (which can occur for example
-	 * for PCI aborts) to throw CPU aborts, which we're not set
-	 * up to deal with.
-	 */
-	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
+	kirkwood_disable_mbus_error_propagation();
 
 	BUG_ON(mvebu_mbus_dt_init());
 
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index 8b9d1c9ff199..2bd12fde1781 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -14,6 +14,7 @@
 #include <mach/kirkwood.h>
 
 #define CPU_CONFIG		(BRIDGE_VIRT_BASE + 0x0100)
+#define CPU_CONFIG_PHYS		(BRIDGE_PHYS_BASE + 0x0100)
 #define CPU_CONFIG_ERROR_PROP	0x00000004
 
 #define CPU_CONTROL		(BRIDGE_VIRT_BASE + 0x0104)
-- 
1.8.5.3

[PATCH 07/21] ARM: Kirkwood: ioremap memory control register

[Andrew Lunn]

To allow removal of the global map of registers, make the pm code
ioremap the registers it needs.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
 arch/arm/mach-kirkwood/pm.c                       | 9 ++++++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index 2bd12fde1781..6e5077e2ec26 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -80,5 +80,6 @@
 #define CGC_RESERVED		(0x6 << 21)
 
 #define MEMORY_PM_CTRL		(BRIDGE_VIRT_BASE + 0x118)
+#define MEMORY_PM_CTRL_PHYS	(BRIDGE_PHYS_BASE + 0x118)
 
 #endif
diff --git a/arch/arm/mach-kirkwood/pm.c b/arch/arm/mach-kirkwood/pm.c
index c6ab8d9303a5..8e5e0329d04c 100644
--- a/arch/arm/mach-kirkwood/pm.c
+++ b/arch/arm/mach-kirkwood/pm.c
@@ -21,15 +21,16 @@
 #include "common.h"
 
 static void __iomem *ddr_operation_base;
+static void __iomem *memory_pm_ctrl;
 
 static void kirkwood_low_power(void)
 {
 	u32 mem_pm_ctrl;
 
-	mem_pm_ctrl = readl(MEMORY_PM_CTRL);
+	mem_pm_ctrl = readl(memory_pm_ctrl);
 
 	/* Set peripherals to low-power mode */
-	writel_relaxed(~0, MEMORY_PM_CTRL);
+	writel_relaxed(~0, memory_pm_ctrl);
 
 	/* Set DDR in self-refresh */
 	writel_relaxed(0x7, ddr_operation_base);
@@ -41,7 +42,7 @@ static void kirkwood_low_power(void)
 	 */
 	cpu_do_idle();
 
-	writel_relaxed(mem_pm_ctrl, MEMORY_PM_CTRL);
+	writel_relaxed(mem_pm_ctrl, memory_pm_ctrl);
 }
 
 static int kirkwood_suspend_enter(suspend_state_t state)
@@ -69,5 +70,7 @@ static const struct platform_suspend_ops kirkwood_suspend_ops = {
 void __init kirkwood_pm_init(void)
 {
 	ddr_operation_base = ioremap(DDR_OPERATION_BASE, 4);
+	memory_pm_ctrl = ioremap(MEMORY_PM_CTRL_PHYS, 4);
+
 	suspend_set_ops(&kirkwood_suspend_ops);
 }
-- 
1.8.5.3

[PATCH 08/21] ARM: MVEBU: Add ARCH_MULTI_V7 to SoCs

[Andrew Lunn]

Prepare mach-mvebu to house both ARCH_MULTI_V7 and ARCH_MULTI_V5
systems by adding ARCH_MULTI_V7 to the existing SOCs.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-mvebu/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..9ab22e1b26cd 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -29,7 +29,7 @@ config MACH_ARMADA_370_XP
 	select CPU_PJ4B
 
 config MACH_ARMADA_370
-	bool "Marvell Armada 370 boards"
+	bool "Marvell Armada 370 boards" if ARCH_MULTI_V7
 	select ARMADA_370_CLK
 	select MACH_ARMADA_370_XP
 	select PINCTRL_ARMADA_370
@@ -38,7 +38,7 @@ config MACH_ARMADA_370
 	  on the Marvell Armada 370 SoC with device tree.
 
 config MACH_ARMADA_XP
-	bool "Marvell Armada XP boards"
+	bool "Marvell Armada XP boards" if ARCH_MULTI_V7
 	select ARMADA_XP_CLK
 	select MACH_ARMADA_370_XP
 	select PINCTRL_ARMADA_XP
-- 
1.8.5.3

[PATCH 09/21] ARM: Orion: Move cache-feroceon-l2.h out of plat-orion

[Andrew Lunn]

With the gradual move to DT, kirkwood has become a lot less dependent
on plat-orion. cache-feroceon-l2.h is the last dependency. Move it out
so we can drop plat-orion when building DT only kirkwood boards.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/include/asm/hardware/cache-feroceon-l2.h    | 11 +++++++++++
 arch/arm/mach-kirkwood/board-dt.c                    |  2 +-
 arch/arm/mach-kirkwood/common.c                      |  2 +-
 arch/arm/mach-mv78xx0/common.c                       |  2 +-
 arch/arm/mm/cache-feroceon-l2.c                      |  2 +-
 arch/arm/plat-orion/include/plat/cache-feroceon-l2.h | 11 -----------
 6 files changed, 15 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm/include/asm/hardware/cache-feroceon-l2.h
 delete mode 100644 arch/arm/plat-orion/include/plat/cache-feroceon-l2.h

diff --git a/arch/arm/include/asm/hardware/cache-feroceon-l2.h b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
new file mode 100644
index 000000000000..8edd330aabf6
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
@@ -0,0 +1,11 @@
+/*
+ * arch/arm/include/asm/hardware/cache-feroceon-l2.h
+ *
+ * Copyright (C) 2008 Marvell Semiconductor
+ *
+ * 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.
+ */
+
+extern void __init feroceon_l2_init(int l2_wt_override);
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 91b61a971af2..34c35510fd17 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -20,11 +20,11 @@
 #include <linux/dma-mapping.h>
 #include <linux/irqchip.h>
 #include <linux/kexec.h>
+#include <asm/hardware/cache-feroceon-l2.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/bridge-regs.h>
 #include <plat/common.h>
-#include <plat/cache-feroceon-l2.h>
 #include <plat/pcie.h>
 #include "pm.h"
 
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index 52aca25432a7..255f33a3903c 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -25,10 +25,10 @@
 #include <asm/page.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
+#include <asm/hardware/cache-feroceon-l2.h>
 #include <mach/kirkwood.h>
 #include <mach/bridge-regs.h>
 #include <linux/platform_data/asoc-kirkwood.h>
-#include <plat/cache-feroceon-l2.h>
 #include <linux/platform_data/mmc-mvsdio.h>
 #include <linux/platform_data/mtd-orion_nand.h>
 #include <linux/platform_data/usb-ehci-orion.h>
diff --git a/arch/arm/mach-mv78xx0/common.c b/arch/arm/mach-mv78xx0/common.c
index 75062eff2494..e6ac679bece9 100644
--- a/arch/arm/mach-mv78xx0/common.c
+++ b/arch/arm/mach-mv78xx0/common.c
@@ -15,11 +15,11 @@
 #include <linux/ata_platform.h>
 #include <linux/clk-provider.h>
 #include <linux/ethtool.h>
+#include <asm/hardware/cache-feroceon-l2.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 #include <mach/mv78xx0.h>
 #include <mach/bridge-regs.h>
-#include <plat/cache-feroceon-l2.h>
 #include <linux/platform_data/usb-ehci-orion.h>
 #include <linux/platform_data/mtd-orion_nand.h>
 #include <plat/time.h>
diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
index 48bc3c0a87ce..898362e7972b 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -16,7 +16,7 @@
 #include <linux/highmem.h>
 #include <asm/cacheflush.h>
 #include <asm/cp15.h>
-#include <plat/cache-feroceon-l2.h>
+#include <asm/hardware/cache-feroceon-l2.h>
 
 /*
  * Low-level cache maintenance operations.
diff --git a/arch/arm/plat-orion/include/plat/cache-feroceon-l2.h b/arch/arm/plat-orion/include/plat/cache-feroceon-l2.h
deleted file mode 100644
index 06f982d55697..000000000000
--- a/arch/arm/plat-orion/include/plat/cache-feroceon-l2.h
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- * arch/arm/plat-orion/include/plat/cache-feroceon-l2.h
- *
- * Copyright (C) 2008 Marvell Semiconductor
- *
- * 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.
- */
-
-extern void __init feroceon_l2_init(int l2_wt_override);
-- 
1.8.5.3

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Andrew Lunn]

Instantiate the L2 cache from DT. Indicate in DT where the cache
control register is and if write through should be made.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 .../devicetree/bindings/arm/mrvl/foroceon.txt      | 19 +++++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |  5 +++
 arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  2 +
 arch/arm/mach-kirkwood/board-dt.c                  | 15 +------
 arch/arm/mm/cache-feroceon-l2.c                    | 46 ++++++++++++++++++++++
 5 files changed, 73 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mrvl/foroceon.txt

diff --git a/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
new file mode 100644
index 000000000000..8058676d1476
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
@@ -0,0 +1,19 @@
+* Marvell Feroceon Cache
+
+Required properties:
+- compatible : Should be "marvell,feroceon-kirkwood".
+- reg        : Address of the L2 cache control register
+
+Optional properties:
+- writethrough : only if present, the cache will be used in write through mode.
+
+Example:
+		l2: l2-cache at 20128 {
+			compatible = "marvell,marvell,feroceon-kirkwood";
+			reg = <0x20128 0x4>;
+		};
+
+There are at least two variants of the Feroceon, differing in how
+write through is enabled or not. If mv78xx0 support is added, it is
+expected to have a different compatibility string.
+
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 6abf44d257df..1d8129ac2672 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -161,6 +161,11 @@
 			#clock-cells = <1>;
 		};
 
+		l2: l2-cache at 20128 {
+			compatible = "marvell,feroceon-kirkwood";
+			reg = <0x20128 0x4>;
+		};
+
 		intc: main-interrupt-ctrl at 20200 {
 			compatible = "marvell,orion-intc";
 			interrupt-controller;
diff --git a/arch/arm/include/asm/hardware/cache-feroceon-l2.h b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
index 8edd330aabf6..12e1588dc4f1 100644
--- a/arch/arm/include/asm/hardware/cache-feroceon-l2.h
+++ b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
@@ -9,3 +9,5 @@
  */
 
 extern void __init feroceon_l2_init(int l2_wt_override);
+extern int __init feroceon_of_init(void);
+
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 34c35510fd17..2ef59ee2182d 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -42,19 +42,6 @@ static void __init kirkwood_map_io(void)
 	iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc));
 }
 
-static void __init kirkwood_l2_init(void)
-{
-#ifdef CONFIG_CACHE_FEROCEON_L2
-#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
-	writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG);
-	feroceon_l2_init(1);
-#else
-	writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG);
-	feroceon_l2_init(0);
-#endif
-#endif
-}
-
 static struct resource kirkwood_cpufreq_resources[] = {
 	[0] = {
 		.start  = CPU_CONTROL_PHYS,
@@ -211,7 +198,7 @@ static void __init kirkwood_dt_init(void)
 
 	BUG_ON(mvebu_mbus_dt_init());
 
-	kirkwood_l2_init();
+	feroceon_of_init();
 
 	kirkwood_cpufreq_init();
 	kirkwood_cpuidle_init();
diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
index 898362e7972b..193fe7dbdb12 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -13,11 +13,17 @@
  */
 
 #include <linux/init.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/highmem.h>
+#include <linux/io.h>
 #include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/hardware/cache-feroceon-l2.h>
 
+#define L2_WRITETHROUGH_KIRKWOOD	0x00000010
+
+
 /*
  * Low-level cache maintenance operations.
  *
@@ -350,3 +356,43 @@ void __init feroceon_l2_init(int __l2_wt_override)
 	printk(KERN_INFO "Feroceon L2: Cache support initialised%s.\n",
 			 l2_wt_override ? ", in WT override mode" : "");
 }
+#ifdef CONFIG_OF
+static const struct of_device_id feroceon_ids[] __initconst = {
+	{ .compatible = "marvell,feroceon-kirkwood"},
+	{}
+};
+
+int __init feroceon_of_init(void)
+{
+	struct device_node *node;
+	void __iomem *base;
+	bool writethrough = false;
+	struct resource res;
+
+	node = of_find_matching_node(NULL, feroceon_ids);
+	if (!node) {
+		pr_info("Didn't find marvell,feroceon-*, not enabling it\n");
+		return -ENODEV;
+	}
+
+	if (of_property_read_bool(node, "writethrough"))
+		writethrough = true;
+
+	if (of_address_to_resource(node, 0, &res))
+		return -ENODEV;
+
+	base = ioremap(res.start, resource_size(&res));
+	if (!base)
+		return -ENOMEM;
+
+	if (writethrough) {
+		writel(readl(base) | L2_WRITETHROUGH_KIRKWOOD, base);
+		feroceon_l2_init(1);
+	} else {
+		writel(readl(base) & ~L2_WRITETHROUGH_KIRKWOOD, base);
+	feroceon_l2_init(0);
+	}
+
+	return 0;
+}
+#endif
-- 
1.8.5.3

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Jason Gunthorpe]

On Fri, Feb 07, 2014 at 12:42:06AM +0100, Andrew Lunn wrote:
  
> +#define L2_WRITETHROUGH_KIRKWOOD	0x00000010

BIT(x)?

> +#ifdef CONFIG_OF
> +static const struct of_device_id feroceon_ids[] __initconst = {
> +	{ .compatible = "marvell,feroceon-kirkwood"},
> +	{}
> +}

How about following the naming convention from l2x0:

"marvell,kirkwood-cache"
"marvell,feroceon-cache"

> +	if (writethrough) {
> +		writel(readl(base) | L2_WRITETHROUGH_KIRKWOOD, base);
> +		feroceon_l2_init(1);
> +	} else {
> +		writel(readl(base) & ~L2_WRITETHROUGH_KIRKWOOD, base);
> +	feroceon_l2_init(0);

This should only happen for "marvell,kirkwood-cache" - it is very
kirkwood specific.. Someday mv78xx0 will have a different bit of code.

Maybe pass -1 to feroceon_l2_init and don't print the writethrough
type at all for the "marvell,feroceon-cache" case?

Regards,
Jason

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:42:06AM +0100, Andrew Lunn wrote:
> Instantiate the L2 cache from DT. Indicate in DT where the cache
> control register is and if write through should be made.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  .../devicetree/bindings/arm/mrvl/foroceon.txt      | 19 +++++++++
>  arch/arm/boot/dts/kirkwood.dtsi                    |  5 +++
>  arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  2 +
>  arch/arm/mach-kirkwood/board-dt.c                  | 15 +------
>  arch/arm/mm/cache-feroceon-l2.c                    | 46 ++++++++++++++++++++++
>  5 files changed, 73 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/foroceon.txt

for the next revision, please split out the dtsi changes into a separate
patch.

> 
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> new file mode 100644
> index 000000000000..8058676d1476
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt

name typo.

> @@ -0,0 +1,19 @@
> +* Marvell Feroceon Cache
> +
> +Required properties:
> +- compatible : Should be "marvell,feroceon-kirkwood".

This is a little ambiguous, I'd like to see 'l2' in the compatible string.

> +- reg        : Address of the L2 cache control register
> +
> +Optional properties:
> +- writethrough : only if present, the cache will be used in write through mode.
> +
> +Example:
> +		l2: l2-cache at 20128 {
> +			compatible = "marvell,marvell,feroceon-kirkwood";

only need a single 'marvell'.

> +			reg = <0x20128 0x4>;
> +		};
> +
> +There are at least two variants of the Feroceon, differing in how
> +write through is enabled or not. If mv78xx0 support is added, it is
> +expected to have a different compatibility string.
> +
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 6abf44d257df..1d8129ac2672 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -161,6 +161,11 @@
>  			#clock-cells = <1>;
>  		};
>  
> +		l2: l2-cache at 20128 {
> +			compatible = "marvell,feroceon-kirkwood";
> +			reg = <0x20128 0x4>;
> +		};
> +
>  		intc: main-interrupt-ctrl at 20200 {
>  			compatible = "marvell,orion-intc";
>  			interrupt-controller;
> diff --git a/arch/arm/include/asm/hardware/cache-feroceon-l2.h b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
> index 8edd330aabf6..12e1588dc4f1 100644
> --- a/arch/arm/include/asm/hardware/cache-feroceon-l2.h
> +++ b/arch/arm/include/asm/hardware/cache-feroceon-l2.h
> @@ -9,3 +9,5 @@
>   */
>  
>  extern void __init feroceon_l2_init(int l2_wt_override);
> +extern int __init feroceon_of_init(void);
> +
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index 34c35510fd17..2ef59ee2182d 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -42,19 +42,6 @@ static void __init kirkwood_map_io(void)
>  	iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc));
>  }
>  
> -static void __init kirkwood_l2_init(void)
> -{
> -#ifdef CONFIG_CACHE_FEROCEON_L2
> -#ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
> -	writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG);
> -	feroceon_l2_init(1);
> -#else
> -	writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG);
> -	feroceon_l2_init(0);
> -#endif
> -#endif
> -}
> -
>  static struct resource kirkwood_cpufreq_resources[] = {
>  	[0] = {
>  		.start  = CPU_CONTROL_PHYS,
> @@ -211,7 +198,7 @@ static void __init kirkwood_dt_init(void)
>  
>  	BUG_ON(mvebu_mbus_dt_init());
>  
> -	kirkwood_l2_init();
> +	feroceon_of_init();
>  
>  	kirkwood_cpufreq_init();
>  	kirkwood_cpuidle_init();
> diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
> index 898362e7972b..193fe7dbdb12 100644
> --- a/arch/arm/mm/cache-feroceon-l2.c
> +++ b/arch/arm/mm/cache-feroceon-l2.c
> @@ -13,11 +13,17 @@
>   */
>  
>  #include <linux/init.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
>  #include <linux/highmem.h>
> +#include <linux/io.h>
>  #include <asm/cacheflush.h>
>  #include <asm/cp15.h>
>  #include <asm/hardware/cache-feroceon-l2.h>
>  
> +#define L2_WRITETHROUGH_KIRKWOOD	0x00000010
> +
> +
>  /*
>   * Low-level cache maintenance operations.
>   *
> @@ -350,3 +356,43 @@ void __init feroceon_l2_init(int __l2_wt_override)
>  	printk(KERN_INFO "Feroceon L2: Cache support initialised%s.\n",
>  			 l2_wt_override ? ", in WT override mode" : "");
>  }
> +#ifdef CONFIG_OF
> +static const struct of_device_id feroceon_ids[] __initconst = {
> +	{ .compatible = "marvell,feroceon-kirkwood"},
> +	{}
> +};
> +
> +int __init feroceon_of_init(void)
> +{
> +	struct device_node *node;
> +	void __iomem *base;
> +	bool writethrough = false;
> +	struct resource res;
> +
> +	node = of_find_matching_node(NULL, feroceon_ids);
> +	if (!node) {
> +		pr_info("Didn't find marvell,feroceon-*, not enabling it\n");
> +		return -ENODEV;
> +	}

I'd prefer to fallback to hardcoded register address here.  We know
we're on kirkwood at this point.

thx,

Jason.

> +
> +	if (of_property_read_bool(node, "writethrough"))
> +		writethrough = true;
> +
> +	if (of_address_to_resource(node, 0, &res))
> +		return -ENODEV;
> +
> +	base = ioremap(res.start, resource_size(&res));
> +	if (!base)
> +		return -ENOMEM;
> +
> +	if (writethrough) {
> +		writel(readl(base) | L2_WRITETHROUGH_KIRKWOOD, base);
> +		feroceon_l2_init(1);
> +	} else {
> +		writel(readl(base) & ~L2_WRITETHROUGH_KIRKWOOD, base);
> +	feroceon_l2_init(0);
> +	}
> +
> +	return 0;
> +}
> +#endif
> -- 
> 1.8.5.3
> 

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Andrew Lunn]

On Thu, Feb 06, 2014 at 08:27:52PM -0500, Jason Cooper wrote:
> On Fri, Feb 07, 2014 at 12:42:06AM +0100, Andrew Lunn wrote:
> > Instantiate the L2 cache from DT. Indicate in DT where the cache
> > control register is and if write through should be made.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  .../devicetree/bindings/arm/mrvl/foroceon.txt      | 19 +++++++++
> >  arch/arm/boot/dts/kirkwood.dtsi                    |  5 +++
> >  arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  2 +
> >  arch/arm/mach-kirkwood/board-dt.c                  | 15 +------
> >  arch/arm/mm/cache-feroceon-l2.c                    | 46 ++++++++++++++++++++++
> >  5 files changed, 73 insertions(+), 14 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> 
> for the next revision, please split out the dtsi changes into a separate
> patch.
> 
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> > new file mode 100644
> > index 000000000000..8058676d1476
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> 
> name typo.
> 
> > @@ -0,0 +1,19 @@
> > +* Marvell Feroceon Cache
> > +
> > +Required properties:
> > +- compatible : Should be "marvell,feroceon-kirkwood".
> 
> This is a little ambiguous, I'd like to see 'l2' in the compatible string.

I will take Jason's advice on naming and change this..

> > +#ifdef CONFIG_OF
> > +static const struct of_device_id feroceon_ids[] __initconst = {
> > +	{ .compatible = "marvell,feroceon-kirkwood"},
> > +	{}
> > +};
> > +
> > +int __init feroceon_of_init(void)
> > +{
> > +	struct device_node *node;
> > +	void __iomem *base;
> > +	bool writethrough = false;
> > +	struct resource res;
> > +
> > +	node = of_find_matching_node(NULL, feroceon_ids);
> > +	if (!node) {
> > +		pr_info("Didn't find marvell,feroceon-*, not enabling it\n");
> > +		return -ENODEV;
> > +	}
> 
> I'd prefer to fallback to hardcoded register address here.  We know
> we're on kirkwood at this point.

We could also be on mv78xx0, sometime in the future. So we need to at
least look at the compatible string to see what SoC we are. It is also
rather ugly having hard coded addresses. We might as well go back to
platform devices.

I would prefer upping this to pr_err(FW_INFO, and not falling back to
hard coded values. This is not a fatal error, the machine continues to
run, just a bit slower.

     Andrew

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Jason Cooper]

On Fri, Feb 07, 2014 at 10:32:06AM +0100, Andrew Lunn wrote:
> On Thu, Feb 06, 2014 at 08:27:52PM -0500, Jason Cooper wrote:
> > On Fri, Feb 07, 2014 at 12:42:06AM +0100, Andrew Lunn wrote:
> > > Instantiate the L2 cache from DT. Indicate in DT where the cache
> > > control register is and if write through should be made.
> > > 
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > ---
> > >  .../devicetree/bindings/arm/mrvl/foroceon.txt      | 19 +++++++++
> > >  arch/arm/boot/dts/kirkwood.dtsi                    |  5 +++
> > >  arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  2 +
> > >  arch/arm/mach-kirkwood/board-dt.c                  | 15 +------
> > >  arch/arm/mm/cache-feroceon-l2.c                    | 46 ++++++++++++++++++++++
> > >  5 files changed, 73 insertions(+), 14 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> > 
> > for the next revision, please split out the dtsi changes into a separate
> > patch.
> > 
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> > > new file mode 100644
> > > index 000000000000..8058676d1476
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> > 
> > name typo.
> > 
> > > @@ -0,0 +1,19 @@
> > > +* Marvell Feroceon Cache
> > > +
> > > +Required properties:
> > > +- compatible : Should be "marvell,feroceon-kirkwood".
> > 
> > This is a little ambiguous, I'd like to see 'l2' in the compatible string.
> 
> I will take Jason's advice on naming and change this..

Ack.  (I assume you meant JasonG)

> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id feroceon_ids[] __initconst = {
> > > +	{ .compatible = "marvell,feroceon-kirkwood"},
> > > +	{}
> > > +};
> > > +
> > > +int __init feroceon_of_init(void)
> > > +{
> > > +	struct device_node *node;
> > > +	void __iomem *base;
> > > +	bool writethrough = false;
> > > +	struct resource res;
> > > +
> > > +	node = of_find_matching_node(NULL, feroceon_ids);
> > > +	if (!node) {
> > > +		pr_info("Didn't find marvell,feroceon-*, not enabling it\n");
> > > +		return -ENODEV;
> > > +	}
> > 
> > I'd prefer to fallback to hardcoded register address here.  We know
> > we're on kirkwood at this point.
> 
> We could also be on mv78xx0, sometime in the future. So we need to at
> least look at the compatible string to see what SoC we are. It is also
> rather ugly having hard coded addresses. We might as well go back to
> platform devices.

reverting to default behavior for missing dt information is an
acceptable compromise to the evolving DT landscape.  However...

> I would prefer upping this to pr_err(FW_INFO, and not falling back to
> hard coded values. This is not a fatal error, the machine continues to
> run, just a bit slower.

You are correct, and it would encourage the user to update their DT
blob.  So I'm fine with the way you have it.

thx,

Jason.

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Jason Gunthorpe]

On Fri, Feb 07, 2014 at 10:32:06AM +0100, Andrew Lunn wrote:

> > I'd prefer to fallback to hardcoded register address here.  We know
> > we're on kirkwood at this point.
> 
> We could also be on mv78xx0, sometime in the future. So we need to at
> least look at the compatible string to see what SoC we are. It is also
> rather ugly having hard coded addresses. We might as well go back to
> platform devices.

The driver should have a default mode "marvell,feroceon-cache" which
doesn't manipulate the write through register at all. In this mode you
don't need any register mapping or DT block, just do the mcr/mrc
operations to switch the cache on and inhibit printing of the write
through status.

So, I'd suggest rough logic like:

int feroceon_of_init()
{
 writethrough = -1;
 if (np = of_find_compatible("marvell,kirkwood-cache")) {
     writethrough = set_writethrough(np, L2_WT_REG_KIRKWOOD, 
                                     L2_WRITETHROUGH_KIRKWOOD);
 else if (np = of_find_compatible("marvell,mv78xx0-cache")) {
     writethrough = set_writethrough(np, L2_WT_REG_MV78XX0,
                                     L2_WRITETHROUGH_MV78XX0);

 feroceon_l2_init(writethrough);

[..]
void __init feroceon_l2_init(int __l2_wt_override)
{
    /* If we don't know the write through state then assume it is
       write back, as that is the safest option. */
    if (__l2_wt_override == -1)
      l2_wt_override = 0;
    else
      l2_wt_override = __l2_wt_override;

[..]
        printk(KERN_INFO "Feroceon L2: Cache support initialised%s.\n",
                         l2_wt_override == 1 ? ", write through enabled" : "");

> I would prefer upping this to pr_err(FW_INFO, and not falling back to
> hard coded values. This is not a fatal error, the machine continues to
> run, just a bit slower.

The only loss with not having the register mappings is you must assume
write back and thus the system must do possibly useless cache flushes
in the DMA path. Otherwise the cache can be fully enabled without
needing model specific registers.

The writethrough disable is such an obscure feature, I think we can
just skip having a compatibility fall back for missing DT node.

BTW, if you have a git URL for your patch set I can probably give v2 a
try here on Kirkwood..

Regards,
Jason

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Sudeep Holla]

On 06/02/14 23:42, Andrew Lunn wrote:
> Instantiate the L2 cache from DT. Indicate in DT where the cache
> control register is and if write through should be made.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  .../devicetree/bindings/arm/mrvl/foroceon.txt      | 19 +++++++++
>  arch/arm/boot/dts/kirkwood.dtsi                    |  5 +++
>  arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  2 +
>  arch/arm/mach-kirkwood/board-dt.c                  | 15 +------
>  arch/arm/mm/cache-feroceon-l2.c                    | 46 ++++++++++++++++++++++
>  5 files changed, 73 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> new file mode 100644
> index 000000000000..8058676d1476
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mrvl/foroceon.txt
> @@ -0,0 +1,19 @@
> +* Marvell Feroceon Cache
> +
> +Required properties:
> +- compatible : Should be "marvell,feroceon-kirkwood".
> +- reg        : Address of the L2 cache control register
> +
> +Optional properties:
> +- writethrough : only if present, the cache will be used in write through mode.
> +

Looks more like a software configuration for me unless I am missing something.
It should not be here IMO if its pure software construct, may be you can use
already existing cachepolicy kernel parameter instead.

Also its better to Cc DT mailing list for any binding updates.

Regards,
Sudeep

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Jason Gunthorpe]

On Fri, Feb 07, 2014 at 02:48:26PM +0000, Sudeep Holla wrote:
> On 06/02/14 23:42, Andrew Lunn wrote:

> Looks more like a software configuration for me unless I am missing
> something. 

There is precedence for this, see
Documentation/devicetree/bindings/arm/l2cc.txt

Though the feorceon name should match 'wt-override'

> It should not be here IMO if its pure software construct, may be you
> can use already existing cachepolicy kernel parameter instead.

cachepolicy is already doing something very different, it would not be
appropriate to use it for this.

Jason

[PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache

[Sudeep Holla]

On 07/02/14 18:21, Jason Gunthorpe wrote:
> On Fri, Feb 07, 2014 at 02:48:26PM +0000, Sudeep Holla wrote:
>> On 06/02/14 23:42, Andrew Lunn wrote:
> 
>> Looks more like a software configuration for me unless I am missing
>> something. 
> 
> There is precedence for this, see
> Documentation/devicetree/bindings/arm/l2cc.txt
> 
> Though the feorceon name should match 'wt-override'
> 

Thanks for pointing out, may be its good to add reference to l2cc binding if its
applicable.

Do we need both wt-override and writethrough ?

>> It should not be here IMO if its pure software construct, may be you
>> can use already existing cachepolicy kernel parameter instead.
> 
> cachepolicy is already doing something very different, it would not be
> appropriate to use it for this.
> 

Yes I suspected that by a quick inspection at the code using it, but thought of
checking instead.

Regards,
Sudeep

[PATCH 11/21] ARM: Fix default CPU selection for ARCH_MULTI_V5

[Andrew Lunn]

CPU_ARM926T should be selected if no other CPU is. Put the ! in the
right place so this works.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e25419817791..beba369d74de 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -898,7 +898,7 @@ config ARCH_MULTI_V5
 	bool "ARMv5 based platforms (ARM926T, XSCALE, PJ1, ...)"
 	depends on !ARCH_MULTI_V6_V7
 	select ARCH_MULTI_V4_V5
-	select CPU_ARM926T if (!CPU_ARM946E || CPU_ARM1020 || \
+	select CPU_ARM926T if !(CPU_ARM946E || CPU_ARM1020 || \
 		CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
 		CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_FEROCEON)
 
-- 
1.8.5.3

[PATCH 12/21] ARM: Fix MULTI_TLB for feroceon

[Andrew Lunn]

Feroceon has the same flush operations as v4wbi, but has an additional
flag, TLB_L2CLEAN_FR. When building with MULTI_TLB this flag is placed
into cpu_tlb.tlb_flags, so there needs to be a cpu_tlb specifically
for feroceon, rather than sharing the v4wbi.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mm/proc-feroceon.S | 2 +-
 arch/arm/mm/tlb-v4wbi.S     | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S
index db79b62c92fb..b76c2706cb02 100644
--- a/arch/arm/mm/proc-feroceon.S
+++ b/arch/arm/mm/proc-feroceon.S
@@ -607,7 +607,7 @@ __\name\()_proc_info:
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP
 	.long	\cpu_name
 	.long	feroceon_processor_functions
-	.long	v4wbi_tlb_fns
+	.long	fr_tlb_fns
 	.long	feroceon_user_fns
 	.long	\cache
 	 .size	__\name\()_proc_info, . - __\name\()_proc_info
diff --git a/arch/arm/mm/tlb-v4wbi.S b/arch/arm/mm/tlb-v4wbi.S
index 1f6062b6c1c1..4e053fef3487 100644
--- a/arch/arm/mm/tlb-v4wbi.S
+++ b/arch/arm/mm/tlb-v4wbi.S
@@ -28,6 +28,7 @@
  *	- mm    - mm_struct describing address space
  */
 	.align	5
+ENTRY(fr_flush_user_tlb_range)
 ENTRY(v4wbi_flush_user_tlb_range)
 	vma_vm_mm ip, r2
 	act_mm	r3				@ get current->active_mm
@@ -46,6 +47,7 @@ ENTRY(v4wbi_flush_user_tlb_range)
 	blo	1b
 	mov	pc, lr
 
+ENTRY(fr_flush_kern_tlb_range)
 ENTRY(v4wbi_flush_kern_tlb_range)
 	mov	r3, #0
 	mcr	p15, 0, r3, c7, c10, 4		@ drain WB
@@ -62,3 +64,4 @@ ENTRY(v4wbi_flush_kern_tlb_range)
 
 	/* define struct cpu_tlb_fns (see <asm/tlbflush.h> and proc-macros.S) */
 	define_tlb_functions v4wbi, v4wbi_tlb_flags
+	define_tlb_functions fr, fr_tlb_flags
-- 
1.8.5.3

[PATCH 13/21] ARM: MM Enable building Feroceon L2 cache controller with ARCH_MVEBU

[Andrew Lunn]

Kirkwood, which uses the Feroceon L2 cache controller will soon be
moving into mach-mvebu. Allow the cache controller to be build in this
situration.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 1f8fed94c2a4..dccd7e177653 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -855,7 +855,7 @@ config OUTER_CACHE_SYNC
 
 config CACHE_FEROCEON_L2
 	bool "Enable the Feroceon L2 cache controller"
-	depends on ARCH_KIRKWOOD || ARCH_MV78XX0
+	depends on ARCH_KIRKWOOD || ARCH_MV78XX0 || ARCH_MVEBU
 	default y
 	select OUTER_CACHE
 	help
-- 
1.8.5.3

[PATCH 14/21] ARM: Move kirkwood DT boards into mach-mvebu

[Andrew Lunn]

Move the kirkwood DT support into mach-mvebu, and make them part of
ARCH_MULTI_V5. Minimal changes have been made in order to make it
boot. More intergration will take place in following patches.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/boot/dts/Makefile                     |  34 ++--
 arch/arm/mach-mvebu/Kconfig                    |  24 ++-
 arch/arm/mach-mvebu/Makefile                   |   1 +
 arch/arm/mach-mvebu/include/mach/bridge-regs.h |  85 ++++++++++
 arch/arm/mach-mvebu/include/mach/kirkwood.h    | 142 +++++++++++++++++
 arch/arm/mach-mvebu/kirkwood-pm.c              |  76 +++++++++
 arch/arm/mach-mvebu/kirkwood-pm.h              |  26 ++++
 arch/arm/mach-mvebu/kirkwood.c                 | 208 +++++++++++++++++++++++++
 8 files changed, 578 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/mach-mvebu/include/mach/bridge-regs.h
 create mode 100644 arch/arm/mach-mvebu/include/mach/kirkwood.h
 create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.c
 create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.h
 create mode 100644 arch/arm/mach-mvebu/kirkwood.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b485e0..c0253830c7db 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -82,7 +82,23 @@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
 	integratorcp.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
+dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
+dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \
+	qcom-msm8960-cdp.dtb \
+	qcom-apq8074-dragonboard.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
+	armada-370-mirabox.dtb \
+	armada-370-netgear-rn102.dtb \
+	armada-370-netgear-rn104.dtb \
+	armada-370-rd.dtb \
+	armada-xp-axpwifiap.dtb \
+	armada-xp-db.dtb \
+	armada-xp-gp.dtb \
+	armada-xp-netgear-rn2120.dtb \
+	armada-xp-matrix.dtb \
+	armada-xp-openblocks-ax3-4.dtb \
+	kirkwood-cloudbox.dtb \
 	kirkwood-db-88f6281.dtb \
 	kirkwood-db-88f6282.dtb \
 	kirkwood-dns320.dtb \
@@ -116,22 +132,6 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-topkick.dtb \
 	kirkwood-ts219-6281.dtb \
 	kirkwood-ts219-6282.dtb
-dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
-dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
-dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \
-	qcom-msm8960-cdp.dtb \
-	qcom-apq8074-dragonboard.dtb
-dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
-	armada-370-mirabox.dtb \
-	armada-370-netgear-rn102.dtb \
-	armada-370-netgear-rn104.dtb \
-	armada-370-rd.dtb \
-	armada-xp-axpwifiap.dtb \
-	armada-xp-db.dtb \
-	armada-xp-gp.dtb \
-	armada-xp-netgear-rn2120.dtb \
-	armada-xp-matrix.dtb \
-	armada-xp-openblocks-ax3-4.dtb
 dtb-$(CONFIG_ARCH_MXC) += \
 	imx25-karo-tx25.dtb \
 	imx25-pdk.dtb \
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 9ab22e1b26cd..2afbd59cad5e 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -1,5 +1,5 @@
 config ARCH_MVEBU
-	bool "Marvell SOCs with Device Tree support" if ARCH_MULTI_V7
+	bool "Marvell SOCs with Device Tree support" if (ARCH_MULTI_V7 || ARCH_MULTI_V5)
 	select ARCH_SUPPORTS_BIG_ENDIAN
 	select CLKSRC_MMIO
 	select COMMON_CLK
@@ -46,6 +46,28 @@ config MACH_ARMADA_XP
 	  Say 'Y' here if you want your kernel to support boards based
 	  on the Marvell Armada XP SoC with device tree.
 
+config MACH_KIRKWOOD
+	bool "Marvell Kirkwood boards" if ARCH_MULTI_V5
+	select ARCH_HAS_CPUFREQ
+	select ARCH_REQUIRE_GPIOLIB
+	select CPU_FEROCEON
+	select KIRKWOOD_CLK
+	select OF_IRQ
+	select ORION_IRQCHIP
+	select ORION_TIMER
+	select PCI
+	select PCI_QUIRKS
+	select PINCTRL_KIRKWOOD
+	select POWER_SUPPLY
+	select POWER_RESET
+	select POWER_RESET_GPIO
+	select REGULATOR
+	select REGULATOR_FIXED_VOLTAGE
+	select USE_OF
+	help
+	  Say 'Y' here if you want your kernel to support boards based
+	  on the Marvell Kirkwood device tree.
+
 endmenu
 
 endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe98dcc..c44976470ccf 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
 obj-$(CONFIG_ARCH_MVEBU)	 += coherency.o coherency_ll.o pmsu.o
 obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
+obj-$(CONFIG_MACH_KIRKWOOD)	 += kirkwood.o kirkwood-pm.o
\ No newline at end of file
diff --git a/arch/arm/mach-mvebu/include/mach/bridge-regs.h b/arch/arm/mach-mvebu/include/mach/bridge-regs.h
new file mode 100644
index 000000000000..6eb8fea1f76f
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/bridge-regs.h
@@ -0,0 +1,85 @@
+/*
+ * arch/arm/mach-mvebu/include/mach/bridge-regs.h
+ *
+ * Mbus-L to Mbus Bridge Registers
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARCH_BRIDGE_REGS_H
+#define __ASM_ARCH_BRIDGE_REGS_H
+
+#include <mach/kirkwood.h>
+
+#define CPU_CONFIG		(BRIDGE_VIRT_BASE + 0x0100)
+#define CPU_CONFIG_PHYS		(BRIDGE_PHYS_BASE + 0x0100)
+#define CPU_CONFIG_ERROR_PROP	0x00000004
+
+#define CPU_CONTROL		(BRIDGE_VIRT_BASE + 0x0104)
+#define CPU_CONTROL_PHYS	(BRIDGE_PHYS_BASE + 0x0104)
+#define CPU_RESET		0x00000002
+
+#define RSTOUTn_MASK		(BRIDGE_VIRT_BASE + 0x0108)
+#define SOFT_RESET_OUT_EN	0x00000004
+
+#define SYSTEM_SOFT_RESET	(BRIDGE_VIRT_BASE + 0x010c)
+#define SOFT_RESET		0x00000001
+
+#define BRIDGE_CAUSE		(BRIDGE_VIRT_BASE + 0x0110)
+
+#define BRIDGE_INT_TIMER1_CLR	(~0x0004)
+
+#define IRQ_VIRT_BASE		(BRIDGE_VIRT_BASE + 0x0200)
+#define IRQ_CAUSE_LOW_OFF	0x0000
+#define IRQ_MASK_LOW_OFF	0x0004
+#define IRQ_CAUSE_HIGH_OFF	0x0010
+#define IRQ_MASK_HIGH_OFF	0x0014
+
+#define TIMER_VIRT_BASE		(BRIDGE_VIRT_BASE + 0x0300)
+#define TIMER_PHYS_BASE		(BRIDGE_PHYS_BASE + 0x0300)
+
+#define L2_CONFIG_REG		(BRIDGE_VIRT_BASE + 0x0128)
+#define L2_WRITETHROUGH		0x00000010
+
+#define CLOCK_GATING_CTRL	(BRIDGE_VIRT_BASE + 0x11c)
+#define CGC_BIT_GE0		(0)
+#define CGC_BIT_PEX0		(2)
+#define CGC_BIT_USB0		(3)
+#define CGC_BIT_SDIO		(4)
+#define CGC_BIT_TSU		(5)
+#define CGC_BIT_DUNIT		(6)
+#define CGC_BIT_RUNIT		(7)
+#define CGC_BIT_XOR0		(8)
+#define CGC_BIT_AUDIO		(9)
+#define CGC_BIT_SATA0		(14)
+#define CGC_BIT_SATA1		(15)
+#define CGC_BIT_XOR1		(16)
+#define CGC_BIT_CRYPTO		(17)
+#define CGC_BIT_PEX1		(18)
+#define CGC_BIT_GE1		(19)
+#define CGC_BIT_TDM		(20)
+#define CGC_GE0			(1 << 0)
+#define CGC_PEX0		(1 << 2)
+#define CGC_USB0		(1 << 3)
+#define CGC_SDIO		(1 << 4)
+#define CGC_TSU			(1 << 5)
+#define CGC_DUNIT		(1 << 6)
+#define CGC_RUNIT		(1 << 7)
+#define CGC_XOR0		(1 << 8)
+#define CGC_AUDIO		(1 << 9)
+#define CGC_POWERSAVE           (1 << 11)
+#define CGC_SATA0		(1 << 14)
+#define CGC_SATA1		(1 << 15)
+#define CGC_XOR1		(1 << 16)
+#define CGC_CRYPTO		(1 << 17)
+#define CGC_PEX1		(1 << 18)
+#define CGC_GE1			(1 << 19)
+#define CGC_TDM			(1 << 20)
+#define CGC_RESERVED		(0x6 << 21)
+
+#define MEMORY_PM_CTRL		(BRIDGE_VIRT_BASE + 0x118)
+#define MEMORY_PM_CTRL_PHYS	(BRIDGE_PHYS_BASE + 0x118)
+
+#endif
diff --git a/arch/arm/mach-mvebu/include/mach/kirkwood.h b/arch/arm/mach-mvebu/include/mach/kirkwood.h
new file mode 100644
index 000000000000..9d966dc78d67
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/kirkwood.h
@@ -0,0 +1,142 @@
+/*
+ * arch/arm/mach-mvebu/include/mach/kirkwood.h
+ *
+ * Generic definitions for Marvell Kirkwood SoC flavors:
+ *  88F6180, 88F6192 and 88F6281.
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARCH_KIRKWOOD_H
+#define __ASM_ARCH_KIRKWOOD_H
+
+/*
+ * Marvell Kirkwood address maps.
+ *
+ * phys
+ * e0000000	PCIe #0 Memory space
+ * e8000000	PCIe #1 Memory space
+ * f1000000	on-chip peripheral registers
+ * f2000000	PCIe #0 I/O space
+ * f3000000	PCIe #1 I/O space
+ * f4000000	NAND controller address window
+ * f5000000	Security Accelerator SRAM
+ *
+ * virt		phys		size
+ * fed00000	f1000000	1M	on-chip peripheral registers
+ * fee00000	f2000000	1M	PCIe #0 I/O space
+ * fef00000	f3000000	1M	PCIe #1 I/O space
+ */
+
+#define KIRKWOOD_SRAM_PHYS_BASE		0xf5000000
+#define KIRKWOOD_SRAM_SIZE		SZ_2K
+
+#define KIRKWOOD_NAND_MEM_PHYS_BASE	0xf4000000
+#define KIRKWOOD_NAND_MEM_SIZE		SZ_1K
+
+#define KIRKWOOD_PCIE1_IO_PHYS_BASE	0xf3000000
+#define KIRKWOOD_PCIE1_IO_BUS_BASE	0x00010000
+#define KIRKWOOD_PCIE1_IO_SIZE		SZ_64K
+
+#define KIRKWOOD_PCIE_IO_PHYS_BASE	0xf2000000
+#define KIRKWOOD_PCIE_IO_BUS_BASE	0x00000000
+#define KIRKWOOD_PCIE_IO_SIZE		SZ_64K
+
+#define KIRKWOOD_REGS_PHYS_BASE		0xf1000000
+#define KIRKWOOD_REGS_VIRT_BASE		IOMEM(0xfed00000)
+#define KIRKWOOD_REGS_SIZE		SZ_1M
+
+#define KIRKWOOD_PCIE_MEM_PHYS_BASE	0xe0000000
+#define KIRKWOOD_PCIE_MEM_BUS_BASE	0xe0000000
+#define KIRKWOOD_PCIE_MEM_SIZE		SZ_128M
+
+#define KIRKWOOD_PCIE1_MEM_PHYS_BASE	0xe8000000
+#define KIRKWOOD_PCIE1_MEM_BUS_BASE	0xe8000000
+#define KIRKWOOD_PCIE1_MEM_SIZE		SZ_128M
+
+/*
+ * Register Map
+ */
+#define DDR_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x00000)
+#define DDR_PHYS_BASE           (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
+#define  DDR_WINDOW_CPU_BASE    (DDR_PHYS_BASE + 0x1500)
+#define  DDR_WINDOW_CPU_SZ      (0x20)
+#define DDR_OPERATION_BASE	(DDR_PHYS_BASE + 0x1418)
+
+#define DEV_BUS_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x10000)
+#define DEV_BUS_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x10000)
+#define  SAMPLE_AT_RESET	(DEV_BUS_VIRT_BASE + 0x0030)
+#define  DEVICE_ID		(DEV_BUS_VIRT_BASE + 0x0034)
+#define  GPIO_LOW_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x0100)
+#define  GPIO_HIGH_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x0140)
+#define  RTC_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x0300)
+#define  SPI_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x0600)
+#define  I2C_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x1000)
+#define  UART0_PHYS_BASE	(DEV_BUS_PHYS_BASE + 0x2000)
+#define  UART0_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x2000)
+#define  UART1_PHYS_BASE	(DEV_BUS_PHYS_BASE + 0x2100)
+#define  UART1_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x2100)
+
+#define BRIDGE_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x20000)
+#define BRIDGE_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x20000)
+#define  BRIDGE_WINS_BASE       (BRIDGE_PHYS_BASE)
+#define  BRIDGE_WINS_SZ         (0x80)
+
+#define CRYPTO_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x30000)
+
+#define PCIE_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x40000)
+#define PCIE_LINK_CTRL		(PCIE_VIRT_BASE + 0x70)
+#define PCIE_STATUS		(PCIE_VIRT_BASE + 0x1a04)
+#define PCIE1_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x44000)
+#define PCIE1_LINK_CTRL		(PCIE1_VIRT_BASE + 0x70)
+#define PCIE1_STATUS		(PCIE1_VIRT_BASE + 0x1a04)
+
+#define USB_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x50000)
+
+#define XOR0_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x60800)
+#define XOR0_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x60800)
+#define XOR1_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x60900)
+#define XOR1_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x60900)
+#define XOR0_HIGH_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x60A00)
+#define XOR0_HIGH_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x60A00)
+#define XOR1_HIGH_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x60B00)
+#define XOR1_HIGH_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x60B00)
+
+#define GE00_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x70000)
+#define GE01_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x74000)
+
+#define SATA_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x80000)
+#define SATA_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x80000)
+#define SATA0_IF_CTRL		(SATA_VIRT_BASE + 0x2050)
+#define SATA0_PHY_MODE_2	(SATA_VIRT_BASE + 0x2330)
+#define SATA1_IF_CTRL		(SATA_VIRT_BASE + 0x4050)
+#define SATA1_PHY_MODE_2	(SATA_VIRT_BASE + 0x4330)
+
+#define SDIO_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x90000)
+
+#define AUDIO_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0xA0000)
+#define AUDIO_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0xA0000)
+
+/*
+ * Supported devices and revisions.
+ */
+#define MV88F6281_DEV_ID	0x6281
+#define MV88F6281_REV_Z0	0
+#define MV88F6281_REV_A0	2
+#define MV88F6281_REV_A1	3
+
+#define MV88F6192_DEV_ID	0x6192
+#define MV88F6192_REV_Z0	0
+#define MV88F6192_REV_A0	2
+#define MV88F6192_REV_A1	3
+
+#define MV88F6180_DEV_ID	0x6180
+#define MV88F6180_REV_A0	2
+#define MV88F6180_REV_A1	3
+
+#define MV88F6282_DEV_ID	0x6282
+#define MV88F6282_REV_A0	0
+#define MV88F6282_REV_A1	1
+#endif
diff --git a/arch/arm/mach-mvebu/kirkwood-pm.c b/arch/arm/mach-mvebu/kirkwood-pm.c
new file mode 100644
index 000000000000..b8c8365b84d8
--- /dev/null
+++ b/arch/arm/mach-mvebu/kirkwood-pm.c
@@ -0,0 +1,76 @@
+/*
+ * Power Management driver for Marvell Kirkwood SoCs
+ *
+ * Copyright (C) 2013 Ezequiel Garcia <ezequiel@free-electrons.com>
+ * Copyright (C) 2010 Simon Guinot <sguinot@lacie.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License,
+ * version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/suspend.h>
+#include <linux/io.h>
+#include <mach/bridge-regs.h>
+
+static void __iomem *ddr_operation_base;
+static void __iomem *memory_pm_ctrl;
+
+static void kirkwood_low_power(void)
+{
+	u32 mem_pm_ctrl;
+
+	mem_pm_ctrl = readl(memory_pm_ctrl);
+
+	/* Set peripherals to low-power mode */
+	writel_relaxed(~0, memory_pm_ctrl);
+
+	/* Set DDR in self-refresh */
+	writel_relaxed(0x7, ddr_operation_base);
+
+	/*
+	 * Set CPU in wait-for-interrupt state.
+	 * This disables the CPU core clocks,
+	 * the array clocks, and also the L2 controller.
+	 */
+	cpu_do_idle();
+
+	writel_relaxed(mem_pm_ctrl, memory_pm_ctrl);
+}
+
+static int kirkwood_suspend_enter(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_STANDBY:
+		kirkwood_low_power();
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int kirkwood_pm_valid_standby(suspend_state_t state)
+{
+	return state == PM_SUSPEND_STANDBY;
+}
+
+static const struct platform_suspend_ops kirkwood_suspend_ops = {
+	.enter = kirkwood_suspend_enter,
+	.valid = kirkwood_pm_valid_standby,
+};
+
+int __init kirkwood_pm_init(void)
+{
+	ddr_operation_base = ioremap(DDR_OPERATION_BASE, 4);
+	memory_pm_ctrl = ioremap(MEMORY_PM_CTRL_PHYS, 4);
+
+	suspend_set_ops(&kirkwood_suspend_ops);
+	return 0;
+}
diff --git a/arch/arm/mach-mvebu/kirkwood-pm.h b/arch/arm/mach-mvebu/kirkwood-pm.h
new file mode 100644
index 000000000000..21e7530f368b
--- /dev/null
+++ b/arch/arm/mach-mvebu/kirkwood-pm.h
@@ -0,0 +1,26 @@
+/*
+ * Power Management driver for Marvell Kirkwood SoCs
+ *
+ * Copyright (C) 2013 Ezequiel Garcia <ezequiel@free-electrons.com>
+ * Copyright (C) 2010 Simon Guinot <sguinot@lacie.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License,
+ * version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_KIRKWOOD_PM_H
+#define __ARCH_KIRKWOOD_PM_H
+
+#ifdef CONFIG_PM
+void kirkwood_pm_init(void);
+#else
+static inline void kirkwood_pm_init(void) {};
+#endif
+
+#endif
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
new file mode 100644
index 000000000000..56e83035bc97
--- /dev/null
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright 2012 (C), Jason Cooper <jason@lakedaemon.net>
+ *
+ * arch/arm/mach-mvebu/kirkwood.c
+ *
+ * Flattened Device Tree board initialization
+ *
+ * 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/clk.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_net.h>
+#include <linux/of_platform.h>
+#include <linux/dma-mapping.h>
+#include <linux/irqchip.h>
+#include <linux/kexec.h>
+#include <asm/hardware/cache-feroceon-l2.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <mach/bridge-regs.h>
+#include <plat/common.h>
+#include <plat/pcie.h>
+#include "kirkwood-pm.h"
+
+static struct resource kirkwood_cpufreq_resources[] = {
+	[0] = {
+		.start  = CPU_CONTROL_PHYS,
+		.end    = CPU_CONTROL_PHYS + 3,
+		.flags  = IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device kirkwood_cpufreq_device = {
+	.name		= "kirkwood-cpufreq",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(kirkwood_cpufreq_resources),
+	.resource	= kirkwood_cpufreq_resources,
+};
+
+static void __init kirkwood_cpufreq_init(void)
+{
+	platform_device_register(&kirkwood_cpufreq_device);
+}
+
+static struct resource kirkwood_cpuidle_resource[] = {
+	{
+		.flags	= IORESOURCE_MEM,
+		.start	= DDR_OPERATION_BASE,
+		.end	= DDR_OPERATION_BASE + 3,
+	},
+};
+
+static struct platform_device kirkwood_cpuidle = {
+	.name		= "kirkwood_cpuidle",
+	.id		= -1,
+	.resource	= kirkwood_cpuidle_resource,
+	.num_resources	= 1,
+};
+
+static void __init kirkwood_cpuidle_init(void)
+{
+	platform_device_register(&kirkwood_cpuidle);
+}
+
+/* Temporary here since mach-mvebu has a function we can use */
+static void kirkwood_restart(enum reboot_mode mode, const char *cmd)
+{
+	/*
+	 * Enable soft reset to assert RSTOUTn.
+	 */
+	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
+
+	/*
+	 * Assert soft reset.
+	 */
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
+
+	while (1)
+		;
+}
+
+#define MV643XX_ETH_MAC_ADDR_LOW	0x0414
+#define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
+
+static void __init kirkwood_dt_eth_fixup(void)
+{
+	struct device_node *np;
+
+	/*
+	 * The ethernet interfaces forget the MAC address assigned by u-boot
+	 * if the clocks are turned off. Usually, u-boot on kirkwood boards
+	 * has no DT support to properly set local-mac-address property.
+	 * As a workaround, we get the MAC address from mv643xx_eth registers
+	 * and update the port device node if no valid MAC address is set.
+	 */
+	for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") {
+		struct device_node *pnp = of_get_parent(np);
+		struct clk *clk;
+		struct property *pmac;
+		void __iomem *io;
+		u8 *macaddr;
+		u32 reg;
+
+		if (!pnp)
+			continue;
+
+		/* skip disabled nodes or nodes with valid MAC address*/
+		if (!of_device_is_available(pnp) || of_get_mac_address(np))
+			goto eth_fixup_skip;
+
+		clk = of_clk_get(pnp, 0);
+		if (IS_ERR(clk))
+			goto eth_fixup_skip;
+
+		io = of_iomap(pnp, 0);
+		if (!io)
+			goto eth_fixup_no_map;
+
+		/* ensure port clock is not gated to not hang CPU */
+		clk_prepare_enable(clk);
+
+		/* store MAC address register contents in local-mac-address */
+		pr_err(FW_INFO "%s: local-mac-address is not set\n",
+		       np->full_name);
+
+		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
+		if (!pmac)
+			goto eth_fixup_no_mem;
+
+		pmac->value = pmac + 1;
+		pmac->length = 6;
+		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
+		if (!pmac->name) {
+			kfree(pmac);
+			goto eth_fixup_no_mem;
+		}
+
+		macaddr = pmac->value;
+		reg = readl(io + MV643XX_ETH_MAC_ADDR_HIGH);
+		macaddr[0] = (reg >> 24) & 0xff;
+		macaddr[1] = (reg >> 16) & 0xff;
+		macaddr[2] = (reg >> 8) & 0xff;
+		macaddr[3] = reg & 0xff;
+
+		reg = readl(io + MV643XX_ETH_MAC_ADDR_LOW);
+		macaddr[4] = (reg >> 8) & 0xff;
+		macaddr[5] = reg & 0xff;
+
+		of_update_property(np, pmac);
+
+eth_fixup_no_mem:
+		iounmap(io);
+		clk_disable_unprepare(clk);
+eth_fixup_no_map:
+		clk_put(clk);
+eth_fixup_skip:
+		of_node_put(pnp);
+	}
+}
+
+/*
+ * Disable propagation of mbus errors to the CPU local bus, as this
+ * causes mbus errors (which can occur for example for PCI aborts) to
+ * throw CPU aborts, which we're not set up to deal with.
+ */
+void kirkwood_disable_mbus_error_propagation(void)
+{
+	void __iomem *cpu_config;
+
+	cpu_config = ioremap(CPU_CONFIG_PHYS, 4);
+	writel(readl(cpu_config) & ~CPU_CONFIG_ERROR_PROP, cpu_config);
+}
+
+
+static void __init kirkwood_dt_init(void)
+{
+	kirkwood_disable_mbus_error_propagation();
+
+	BUG_ON(mvebu_mbus_dt_init());
+
+	feroceon_of_init();
+
+	kirkwood_cpufreq_init();
+	kirkwood_cpuidle_init();
+
+	kirkwood_pm_init();
+	kirkwood_dt_eth_fixup();
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const kirkwood_dt_board_compat[] = {
+	"marvell,kirkwood",
+	NULL
+};
+
+DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
+	/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
+	.init_machine	= kirkwood_dt_init,
+	.restart	= kirkwood_restart,
+	.dt_compat	= kirkwood_dt_board_compat,
+MACHINE_END
-- 
1.8.5.3

[PATCH 15/21] ARM: MVEBU: Let kirkwood use the system controller for restart

[Andrew Lunn]

The mvebu system controller already supports restarting orion
systems. Make use of it, rather than the kirkwood specific code.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/boot/dts/kirkwood.dtsi |  5 +++++
 arch/arm/mach-mvebu/kirkwood.c  | 20 ++------------------
 2 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 1d8129ac2672..6c4028e410fa 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -145,6 +145,11 @@
 			reg = <0x20000 0x80>, <0x1500 0x20>;
 		};
 
+		system-controller at 20000 {
+			compatible = "marvell,orion-system-controller";
+			reg = <0x20000 0x120>;
+		};
+
 		bridge_intc: bridge-interrupt-ctrl at 20110 {
 			compatible = "marvell,orion-bridge-intc";
 			interrupt-controller;
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index 56e83035bc97..af77923a3483 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -27,6 +27,7 @@
 #include <plat/common.h>
 #include <plat/pcie.h>
 #include "kirkwood-pm.h"
+#include "common.h"
 
 static struct resource kirkwood_cpufreq_resources[] = {
 	[0] = {
@@ -68,23 +69,6 @@ static void __init kirkwood_cpuidle_init(void)
 	platform_device_register(&kirkwood_cpuidle);
 }
 
-/* Temporary here since mach-mvebu has a function we can use */
-static void kirkwood_restart(enum reboot_mode mode, const char *cmd)
-{
-	/*
-	 * Enable soft reset to assert RSTOUTn.
-	 */
-	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
-
-	/*
-	 * Assert soft reset.
-	 */
-	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
-
-	while (1)
-		;
-}
-
 #define MV643XX_ETH_MAC_ADDR_LOW	0x0414
 #define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
 
@@ -203,6 +187,6 @@ static const char * const kirkwood_dt_board_compat[] = {
 DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
 	/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
 	.init_machine	= kirkwood_dt_init,
-	.restart	= kirkwood_restart,
+	.restart	= mvebu_restart,
 	.dt_compat	= kirkwood_dt_board_compat,
 MACHINE_END
-- 
1.8.5.3

[PATCH 15/21] ARM: MVEBU: Let kirkwood use the system controller for restart

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:42:11AM +0100, Andrew Lunn wrote:
> The mvebu system controller already supports restarting orion
> systems. Make use of it, rather than the kirkwood specific code.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/boot/dts/kirkwood.dtsi |  5 +++++

Please separate these into two patches.

thx,

Jason.

>  arch/arm/mach-mvebu/kirkwood.c  | 20 ++------------------
>  2 files changed, 7 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 1d8129ac2672..6c4028e410fa 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -145,6 +145,11 @@
>  			reg = <0x20000 0x80>, <0x1500 0x20>;
>  		};
>  
> +		system-controller at 20000 {
> +			compatible = "marvell,orion-system-controller";
> +			reg = <0x20000 0x120>;
> +		};
> +
>  		bridge_intc: bridge-interrupt-ctrl at 20110 {
>  			compatible = "marvell,orion-bridge-intc";
>  			interrupt-controller;
> diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
> index 56e83035bc97..af77923a3483 100644
> --- a/arch/arm/mach-mvebu/kirkwood.c
> +++ b/arch/arm/mach-mvebu/kirkwood.c
> @@ -27,6 +27,7 @@
>  #include <plat/common.h>
>  #include <plat/pcie.h>
>  #include "kirkwood-pm.h"
> +#include "common.h"
>  
>  static struct resource kirkwood_cpufreq_resources[] = {
>  	[0] = {
> @@ -68,23 +69,6 @@ static void __init kirkwood_cpuidle_init(void)
>  	platform_device_register(&kirkwood_cpuidle);
>  }
>  
> -/* Temporary here since mach-mvebu has a function we can use */
> -static void kirkwood_restart(enum reboot_mode mode, const char *cmd)
> -{
> -	/*
> -	 * Enable soft reset to assert RSTOUTn.
> -	 */
> -	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
> -
> -	/*
> -	 * Assert soft reset.
> -	 */
> -	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
> -
> -	while (1)
> -		;
> -}
> -
>  #define MV643XX_ETH_MAC_ADDR_LOW	0x0414
>  #define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
>  
> @@ -203,6 +187,6 @@ static const char * const kirkwood_dt_board_compat[] = {
>  DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
>  	/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
>  	.init_machine	= kirkwood_dt_init,
> -	.restart	= kirkwood_restart,
> +	.restart	= mvebu_restart,
>  	.dt_compat	= kirkwood_dt_board_compat,
>  MACHINE_END
> -- 
> 1.8.5.3
> 

[PATCH 16/21] drivers: Enable building of Kirkwood drivers for mach-mvebu

[Andrew Lunn]

With the move to mach-mvebu, drivers Kconfig need tweeking to allow
the kirkwood specific drivers to be built.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/cpufreq/Kconfig.arm | 2 +-
 drivers/cpuidle/Kconfig.arm | 2 +-
 drivers/leds/Kconfig        | 4 ++--
 drivers/phy/Kconfig         | 2 +-
 drivers/thermal/Kconfig     | 2 +-
 sound/soc/kirkwood/Kconfig  | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 31297499a60a..de931081fd01 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -113,7 +113,7 @@ config ARM_INTEGRATOR
 	  If in doubt, say Y.
 
 config ARM_KIRKWOOD_CPUFREQ
-	def_bool ARCH_KIRKWOOD && OF
+	def_bool (ARCH_KIRKWOOD || MACH_KIRKWOOD) && OF
 	help
 	  This adds the CPUFreq driver for Marvell Kirkwood
 	  SoCs.
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index d988948a89a0..97ccc31dbdd8 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -22,7 +22,7 @@ config ARM_HIGHBANK_CPUIDLE
 
 config ARM_KIRKWOOD_CPUIDLE
 	bool "CPU Idle Driver for Marvell Kirkwood SoCs"
-	depends on ARCH_KIRKWOOD
+	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
 	help
 	  This adds the CPU Idle driver for Marvell Kirkwood SoCs.
 
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 72156c123033..44c358ecf5a1 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -421,7 +421,7 @@ config LEDS_MC13783
 config LEDS_NS2
 	tristate "LED support for Network Space v2 GPIO LEDs"
 	depends on LEDS_CLASS
-	depends on ARCH_KIRKWOOD
+	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
 	default y
 	help
 	  This option enable support for the dual-GPIO LED found on the
@@ -431,7 +431,7 @@ config LEDS_NS2
 config LEDS_NETXBIG
 	tristate "LED support for Big Network series LEDs"
 	depends on LEDS_CLASS
-	depends on ARCH_KIRKWOOD
+	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
 	default y
 	help
 	  This option enable support for LEDs found on the LaCie 2Big
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index afa2354f6600..5e6b33f9c294 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -24,7 +24,7 @@ config PHY_EXYNOS_MIPI_VIDEO
 
 config PHY_MVEBU_SATA
 	def_bool y
-	depends on ARCH_KIRKWOOD || ARCH_DOVE
+	depends on ARCH_KIRKWOOD || ARCH_DOVE || MACH_KIRKWOOD
 	depends on OF
 	select GENERIC_PHY
 
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 35c066489a19..1bc9cbc4f1b8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -142,7 +142,7 @@ config RCAR_THERMAL
 
 config KIRKWOOD_THERMAL
 	tristate "Temperature sensor on Marvell Kirkwood SoCs"
-	depends on ARCH_KIRKWOOD
+	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
 	depends on OF
 	help
 	  Support for the Kirkwood thermal sensor driver into the Linux thermal
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 78ed4a42ad21..106e2e22fed2 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,6 +1,6 @@
 config SND_KIRKWOOD_SOC
 	tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
-	depends on ARCH_KIRKWOOD || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_KIRKWOOD || ARCH_DOVE || MACH_KIRKWOOD || COMPILE_TEST
 	help
 	  Say Y or M if you want to add support for codecs attached to
 	  the Kirkwood I2S interface. You will also need to select the
-- 
1.8.5.3

[PATCH 16/21] drivers: Enable building of Kirkwood drivers for mach-mvebu

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:42:12AM +0100, Andrew Lunn wrote:
> With the move to mach-mvebu, drivers Kconfig need tweeking to allow
> the kirkwood specific drivers to be built.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  drivers/cpufreq/Kconfig.arm | 2 +-
>  drivers/cpuidle/Kconfig.arm | 2 +-
>  drivers/leds/Kconfig        | 4 ++--
>  drivers/phy/Kconfig         | 2 +-
>  drivers/thermal/Kconfig     | 2 +-
>  sound/soc/kirkwood/Kconfig  | 2 +-
>  6 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 31297499a60a..de931081fd01 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -113,7 +113,7 @@ config ARM_INTEGRATOR
>  	  If in doubt, say Y.
>  
>  config ARM_KIRKWOOD_CPUFREQ
> -	def_bool ARCH_KIRKWOOD && OF
> +	def_bool (ARCH_KIRKWOOD || MACH_KIRKWOOD) && OF

I agree with creating MACH_KIRKWOOD underneath ARCH_MVEBU earlier in
this series, but the 'ARCH_KIRKWOOD || MACH_KIRKWOOD' just looks
confusing.  Also, MACH_KIRKWOOD implies OF so this particular one could
be reduced to

	def_bool MACH_KIRKWOOD

thx,

Jason.

>  	help
>  	  This adds the CPUFreq driver for Marvell Kirkwood
>  	  SoCs.
> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
> index d988948a89a0..97ccc31dbdd8 100644
> --- a/drivers/cpuidle/Kconfig.arm
> +++ b/drivers/cpuidle/Kconfig.arm
> @@ -22,7 +22,7 @@ config ARM_HIGHBANK_CPUIDLE
>  
>  config ARM_KIRKWOOD_CPUIDLE
>  	bool "CPU Idle Driver for Marvell Kirkwood SoCs"
> -	depends on ARCH_KIRKWOOD
> +	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
>  	help
>  	  This adds the CPU Idle driver for Marvell Kirkwood SoCs.
>  
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 72156c123033..44c358ecf5a1 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -421,7 +421,7 @@ config LEDS_MC13783
>  config LEDS_NS2
>  	tristate "LED support for Network Space v2 GPIO LEDs"
>  	depends on LEDS_CLASS
> -	depends on ARCH_KIRKWOOD
> +	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
>  	default y
>  	help
>  	  This option enable support for the dual-GPIO LED found on the
> @@ -431,7 +431,7 @@ config LEDS_NS2
>  config LEDS_NETXBIG
>  	tristate "LED support for Big Network series LEDs"
>  	depends on LEDS_CLASS
> -	depends on ARCH_KIRKWOOD
> +	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
>  	default y
>  	help
>  	  This option enable support for LEDs found on the LaCie 2Big
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index afa2354f6600..5e6b33f9c294 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -24,7 +24,7 @@ config PHY_EXYNOS_MIPI_VIDEO
>  
>  config PHY_MVEBU_SATA
>  	def_bool y
> -	depends on ARCH_KIRKWOOD || ARCH_DOVE
> +	depends on ARCH_KIRKWOOD || ARCH_DOVE || MACH_KIRKWOOD
>  	depends on OF
>  	select GENERIC_PHY
>  
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 35c066489a19..1bc9cbc4f1b8 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -142,7 +142,7 @@ config RCAR_THERMAL
>  
>  config KIRKWOOD_THERMAL
>  	tristate "Temperature sensor on Marvell Kirkwood SoCs"
> -	depends on ARCH_KIRKWOOD
> +	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
>  	depends on OF
>  	help
>  	  Support for the Kirkwood thermal sensor driver into the Linux thermal
> diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
> index 78ed4a42ad21..106e2e22fed2 100644
> --- a/sound/soc/kirkwood/Kconfig
> +++ b/sound/soc/kirkwood/Kconfig
> @@ -1,6 +1,6 @@
>  config SND_KIRKWOOD_SOC
>  	tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
> -	depends on ARCH_KIRKWOOD || ARCH_DOVE || COMPILE_TEST
> +	depends on ARCH_KIRKWOOD || ARCH_DOVE || MACH_KIRKWOOD || COMPILE_TEST
>  	help
>  	  Say Y or M if you want to add support for codecs attached to
>  	  the Kirkwood I2S interface. You will also need to select the
> -- 
> 1.8.5.3
> 

[PATCH 16/21] drivers: Enable building of Kirkwood drivers for mach-mvebu

[Andrew Lunn]

On Thu, Feb 06, 2014 at 08:59:15PM -0500, Jason Cooper wrote:
> On Fri, Feb 07, 2014 at 12:42:12AM +0100, Andrew Lunn wrote:
> > With the move to mach-mvebu, drivers Kconfig need tweeking to allow
> > the kirkwood specific drivers to be built.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  drivers/cpufreq/Kconfig.arm | 2 +-
> >  drivers/cpuidle/Kconfig.arm | 2 +-
> >  drivers/leds/Kconfig        | 4 ++--
> >  drivers/phy/Kconfig         | 2 +-
> >  drivers/thermal/Kconfig     | 2 +-
> >  sound/soc/kirkwood/Kconfig  | 2 +-
> >  6 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index 31297499a60a..de931081fd01 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -113,7 +113,7 @@ config ARM_INTEGRATOR
> >  	  If in doubt, say Y.
> >  
> >  config ARM_KIRKWOOD_CPUFREQ
> > -	def_bool ARCH_KIRKWOOD && OF
> > +	def_bool (ARCH_KIRKWOOD || MACH_KIRKWOOD) && OF
> 
> I agree with creating MACH_KIRKWOOD underneath ARCH_MVEBU earlier in
> this series, but the 'ARCH_KIRKWOOD || MACH_KIRKWOOD' just looks
> confusing.  Also, MACH_KIRKWOOD implies OF so this particular one could
> be reduced to
> 
> 	def_bool MACH_KIRKWOOD

Yes, will do.

Thanks
	Andrew

[PATCH 16/21] drivers: Enable building of Kirkwood drivers for mach-mvebu

[Jason Cooper]

On Fri, Feb 07, 2014 at 10:13:36AM +0100, Andrew Lunn wrote:
> On Thu, Feb 06, 2014 at 08:59:15PM -0500, Jason Cooper wrote:
> > On Fri, Feb 07, 2014 at 12:42:12AM +0100, Andrew Lunn wrote:
> > > With the move to mach-mvebu, drivers Kconfig need tweeking to allow
> > > the kirkwood specific drivers to be built.
> > > 
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > ---
> > >  drivers/cpufreq/Kconfig.arm | 2 +-
> > >  drivers/cpuidle/Kconfig.arm | 2 +-
> > >  drivers/leds/Kconfig        | 4 ++--
> > >  drivers/phy/Kconfig         | 2 +-
> > >  drivers/thermal/Kconfig     | 2 +-
> > >  sound/soc/kirkwood/Kconfig  | 2 +-
> > >  6 files changed, 7 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > > index 31297499a60a..de931081fd01 100644
> > > --- a/drivers/cpufreq/Kconfig.arm
> > > +++ b/drivers/cpufreq/Kconfig.arm
> > > @@ -113,7 +113,7 @@ config ARM_INTEGRATOR
> > >  	  If in doubt, say Y.
> > >  
> > >  config ARM_KIRKWOOD_CPUFREQ
> > > -	def_bool ARCH_KIRKWOOD && OF
> > > +	def_bool (ARCH_KIRKWOOD || MACH_KIRKWOOD) && OF
> > 
> > I agree with creating MACH_KIRKWOOD underneath ARCH_MVEBU earlier in
> > this series, but the 'ARCH_KIRKWOOD || MACH_KIRKWOOD' just looks
> > confusing.

Hmm, I was tired last night.  I should've offered a suggestion with my
complaint :)  Unfortunately, the only thing I can come up with is a
oneline comment explaining DT/non-DT...  other ideas?  Or, not worth the
effort?

thx,

Jason.

[PATCH 17/21] ARM: MVEBU: Enable mvebu-soc-id on Kirkwood

[Andrew Lunn]

Add the Kirkwood PCIe compatibility string to mvebu-soc-id, so that it
can get the SoC ID and revision from the PCIe endpoints.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-mvebu/mvebu-soc-id.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.c b/arch/arm/mach-mvebu/mvebu-soc-id.c
index f3b325f6cbd4..f3d4cf53f746 100644
--- a/arch/arm/mach-mvebu/mvebu-soc-id.c
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -38,6 +38,7 @@ static bool is_id_valid;
 static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-xp-pcie", },
 	{ .compatible = "marvell,armada-370-pcie", },
+	{ .compatible = "marvell,kirkwood-pcie" },
 	{},
 };
 
-- 
1.8.5.3

[PATCH 18/21] ARM: config: Add a multi_v5_defconfig

[Andrew Lunn]

To allow regression build testing of multi v5 systems, add a
multi_v5_defconfig, similar to the multi_v7_defconfig. This is based
on kirkwood_defconfig, but with a few other boards added which claim
to be MULTI_v5.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/configs/multi_v5_defconfig | 183 ++++++++++++++++++++++++++++++++++++
 1 file changed, 183 insertions(+)
 create mode 100644 arch/arm/configs/multi_v5_defconfig

diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
new file mode 100644
index 000000000000..8282fab6b514
--- /dev/null
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -0,0 +1,183 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=19
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_ARCH_MULTI_V7 is not set
+CONFIG_ARCH_MVEBU=y
+CONFIG_MACH_KIRKWOOD=y
+CONFIG_ARCH_MXC=y
+CONFIG_MACH_IMX25_DT=y
+CONFIG_MACH_IMX27_DT=y
+CONFIG_ARCH_U300=y
+CONFIG_PCI_MVEBU=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_KIRKWOOD_CPUIDLE=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IPV6 is not set
+CONFIG_NET_PKTGEN=m
+CONFIG_CFG80211=y
+CONFIG_MAC80211=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_GEOMETRY=y
+# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ORION=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_EEPROM_AT24=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=m
+CONFIG_CHR_DEV_SG=m
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_MV=y
+CONFIG_NETDEVICES=y
+CONFIG_NET_DSA_MV88E6123_61_65=y
+CONFIG_MV643XX_ETH=y
+CONFIG_R8169=y
+CONFIG_MARVELL_PHY=y
+CONFIG_LIBERTAS=y
+CONFIG_LIBERTAS_SDIO=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_GPIO=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_LEGACY_PTY_COUNT=16
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MV64XXX=y
+CONFIG_I2C_NOMADIK=y
+CONFIG_SPI=y
+CONFIG_SPI_ORION=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET_QNAP=y
+CONFIG_SENSORS_ADT7475=y
+CONFIG_SENSORS_LM63=y
+CONFIG_SENSORS_LM75=y
+CONFIG_SENSORS_LM85=y
+CONFIG_THERMAL=y
+CONFIG_KIRKWOOD_THERMAL=y
+CONFIG_WATCHDOG=y
+# CONFIG_ABX500_CORE is not set
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_KIRKWOOD_SOC=y
+CONFIG_HID_DRAGONRISE=y
+CONFIG_HID_GYRATION=y
+CONFIG_HID_TWINHAN=y
+CONFIG_HID_NTRIG=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_HID_PETALYNX=y
+CONFIG_HID_SAMSUNG=y
+CONFIG_HID_SONY=y
+CONFIG_HID_SUNPLUS=y
+CONFIG_HID_GREENASIA=y
+CONFIG_HID_SMARTJOYPLUS=y
+CONFIG_HID_TOPSEED=y
+CONFIG_HID_THRUSTMASTER=y
+CONFIG_HID_ZEROPLUS=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_PRINTER=m
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_MMC=y
+CONFIG_SDIO_UART=y
+CONFIG_MMC_MVSDIO=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_PCF8563=y
+CONFIG_RTC_DRV_S35390A=y
+CONFIG_RTC_DRV_MV=y
+CONFIG_DMADEVICES=y
+CONFIG_MV_XOR=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_FS_XATTR is not set
+CONFIG_EXT4_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_2=y
+CONFIG_NLS_UTF8=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_PREEMPT is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_DEBUG_MVEBU_UART_ALTERNATE=y
+CONFIG_DEBUG_UART_VIRT=0xfed12000
+CONFIG_EARLY_PRINTK=y
+CONFIG_CRYPTO_CBC=m
+CONFIG_CRYPTO_PCBC=m
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_MV_CESA=y
+CONFIG_CRC_CCITT=y
+CONFIG_LIBCRC32C=y
-- 
1.8.5.3

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Andrew Lunn]

kirkwood is very nearly fully DT. Remove most of the address
definitions from the header files and make it a local header file.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-mvebu/include/mach/bridge-regs.h |  85 ---------------
 arch/arm/mach-mvebu/include/mach/kirkwood.h    | 142 -------------------------
 arch/arm/mach-mvebu/kirkwood-pm.c              |   2 +-
 arch/arm/mach-mvebu/kirkwood.c                 |   2 +-
 arch/arm/mach-mvebu/kirkwood.h                 |  22 ++++
 5 files changed, 24 insertions(+), 229 deletions(-)
 delete mode 100644 arch/arm/mach-mvebu/include/mach/bridge-regs.h
 delete mode 100644 arch/arm/mach-mvebu/include/mach/kirkwood.h
 create mode 100644 arch/arm/mach-mvebu/kirkwood.h

diff --git a/arch/arm/mach-mvebu/include/mach/bridge-regs.h b/arch/arm/mach-mvebu/include/mach/bridge-regs.h
deleted file mode 100644
index 6eb8fea1f76f..000000000000
--- a/arch/arm/mach-mvebu/include/mach/bridge-regs.h
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * arch/arm/mach-mvebu/include/mach/bridge-regs.h
- *
- * Mbus-L to Mbus Bridge Registers
- *
- * 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.
- */
-
-#ifndef __ASM_ARCH_BRIDGE_REGS_H
-#define __ASM_ARCH_BRIDGE_REGS_H
-
-#include <mach/kirkwood.h>
-
-#define CPU_CONFIG		(BRIDGE_VIRT_BASE + 0x0100)
-#define CPU_CONFIG_PHYS		(BRIDGE_PHYS_BASE + 0x0100)
-#define CPU_CONFIG_ERROR_PROP	0x00000004
-
-#define CPU_CONTROL		(BRIDGE_VIRT_BASE + 0x0104)
-#define CPU_CONTROL_PHYS	(BRIDGE_PHYS_BASE + 0x0104)
-#define CPU_RESET		0x00000002
-
-#define RSTOUTn_MASK		(BRIDGE_VIRT_BASE + 0x0108)
-#define SOFT_RESET_OUT_EN	0x00000004
-
-#define SYSTEM_SOFT_RESET	(BRIDGE_VIRT_BASE + 0x010c)
-#define SOFT_RESET		0x00000001
-
-#define BRIDGE_CAUSE		(BRIDGE_VIRT_BASE + 0x0110)
-
-#define BRIDGE_INT_TIMER1_CLR	(~0x0004)
-
-#define IRQ_VIRT_BASE		(BRIDGE_VIRT_BASE + 0x0200)
-#define IRQ_CAUSE_LOW_OFF	0x0000
-#define IRQ_MASK_LOW_OFF	0x0004
-#define IRQ_CAUSE_HIGH_OFF	0x0010
-#define IRQ_MASK_HIGH_OFF	0x0014
-
-#define TIMER_VIRT_BASE		(BRIDGE_VIRT_BASE + 0x0300)
-#define TIMER_PHYS_BASE		(BRIDGE_PHYS_BASE + 0x0300)
-
-#define L2_CONFIG_REG		(BRIDGE_VIRT_BASE + 0x0128)
-#define L2_WRITETHROUGH		0x00000010
-
-#define CLOCK_GATING_CTRL	(BRIDGE_VIRT_BASE + 0x11c)
-#define CGC_BIT_GE0		(0)
-#define CGC_BIT_PEX0		(2)
-#define CGC_BIT_USB0		(3)
-#define CGC_BIT_SDIO		(4)
-#define CGC_BIT_TSU		(5)
-#define CGC_BIT_DUNIT		(6)
-#define CGC_BIT_RUNIT		(7)
-#define CGC_BIT_XOR0		(8)
-#define CGC_BIT_AUDIO		(9)
-#define CGC_BIT_SATA0		(14)
-#define CGC_BIT_SATA1		(15)
-#define CGC_BIT_XOR1		(16)
-#define CGC_BIT_CRYPTO		(17)
-#define CGC_BIT_PEX1		(18)
-#define CGC_BIT_GE1		(19)
-#define CGC_BIT_TDM		(20)
-#define CGC_GE0			(1 << 0)
-#define CGC_PEX0		(1 << 2)
-#define CGC_USB0		(1 << 3)
-#define CGC_SDIO		(1 << 4)
-#define CGC_TSU			(1 << 5)
-#define CGC_DUNIT		(1 << 6)
-#define CGC_RUNIT		(1 << 7)
-#define CGC_XOR0		(1 << 8)
-#define CGC_AUDIO		(1 << 9)
-#define CGC_POWERSAVE           (1 << 11)
-#define CGC_SATA0		(1 << 14)
-#define CGC_SATA1		(1 << 15)
-#define CGC_XOR1		(1 << 16)
-#define CGC_CRYPTO		(1 << 17)
-#define CGC_PEX1		(1 << 18)
-#define CGC_GE1			(1 << 19)
-#define CGC_TDM			(1 << 20)
-#define CGC_RESERVED		(0x6 << 21)
-
-#define MEMORY_PM_CTRL		(BRIDGE_VIRT_BASE + 0x118)
-#define MEMORY_PM_CTRL_PHYS	(BRIDGE_PHYS_BASE + 0x118)
-
-#endif
diff --git a/arch/arm/mach-mvebu/include/mach/kirkwood.h b/arch/arm/mach-mvebu/include/mach/kirkwood.h
deleted file mode 100644
index 9d966dc78d67..000000000000
--- a/arch/arm/mach-mvebu/include/mach/kirkwood.h
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * arch/arm/mach-mvebu/include/mach/kirkwood.h
- *
- * Generic definitions for Marvell Kirkwood SoC flavors:
- *  88F6180, 88F6192 and 88F6281.
- *
- * 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.
- */
-
-#ifndef __ASM_ARCH_KIRKWOOD_H
-#define __ASM_ARCH_KIRKWOOD_H
-
-/*
- * Marvell Kirkwood address maps.
- *
- * phys
- * e0000000	PCIe #0 Memory space
- * e8000000	PCIe #1 Memory space
- * f1000000	on-chip peripheral registers
- * f2000000	PCIe #0 I/O space
- * f3000000	PCIe #1 I/O space
- * f4000000	NAND controller address window
- * f5000000	Security Accelerator SRAM
- *
- * virt		phys		size
- * fed00000	f1000000	1M	on-chip peripheral registers
- * fee00000	f2000000	1M	PCIe #0 I/O space
- * fef00000	f3000000	1M	PCIe #1 I/O space
- */
-
-#define KIRKWOOD_SRAM_PHYS_BASE		0xf5000000
-#define KIRKWOOD_SRAM_SIZE		SZ_2K
-
-#define KIRKWOOD_NAND_MEM_PHYS_BASE	0xf4000000
-#define KIRKWOOD_NAND_MEM_SIZE		SZ_1K
-
-#define KIRKWOOD_PCIE1_IO_PHYS_BASE	0xf3000000
-#define KIRKWOOD_PCIE1_IO_BUS_BASE	0x00010000
-#define KIRKWOOD_PCIE1_IO_SIZE		SZ_64K
-
-#define KIRKWOOD_PCIE_IO_PHYS_BASE	0xf2000000
-#define KIRKWOOD_PCIE_IO_BUS_BASE	0x00000000
-#define KIRKWOOD_PCIE_IO_SIZE		SZ_64K
-
-#define KIRKWOOD_REGS_PHYS_BASE		0xf1000000
-#define KIRKWOOD_REGS_VIRT_BASE		IOMEM(0xfed00000)
-#define KIRKWOOD_REGS_SIZE		SZ_1M
-
-#define KIRKWOOD_PCIE_MEM_PHYS_BASE	0xe0000000
-#define KIRKWOOD_PCIE_MEM_BUS_BASE	0xe0000000
-#define KIRKWOOD_PCIE_MEM_SIZE		SZ_128M
-
-#define KIRKWOOD_PCIE1_MEM_PHYS_BASE	0xe8000000
-#define KIRKWOOD_PCIE1_MEM_BUS_BASE	0xe8000000
-#define KIRKWOOD_PCIE1_MEM_SIZE		SZ_128M
-
-/*
- * Register Map
- */
-#define DDR_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x00000)
-#define DDR_PHYS_BASE           (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
-#define  DDR_WINDOW_CPU_BASE    (DDR_PHYS_BASE + 0x1500)
-#define  DDR_WINDOW_CPU_SZ      (0x20)
-#define DDR_OPERATION_BASE	(DDR_PHYS_BASE + 0x1418)
-
-#define DEV_BUS_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x10000)
-#define DEV_BUS_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x10000)
-#define  SAMPLE_AT_RESET	(DEV_BUS_VIRT_BASE + 0x0030)
-#define  DEVICE_ID		(DEV_BUS_VIRT_BASE + 0x0034)
-#define  GPIO_LOW_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x0100)
-#define  GPIO_HIGH_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x0140)
-#define  RTC_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x0300)
-#define  SPI_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x0600)
-#define  I2C_PHYS_BASE		(DEV_BUS_PHYS_BASE + 0x1000)
-#define  UART0_PHYS_BASE	(DEV_BUS_PHYS_BASE + 0x2000)
-#define  UART0_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x2000)
-#define  UART1_PHYS_BASE	(DEV_BUS_PHYS_BASE + 0x2100)
-#define  UART1_VIRT_BASE	(DEV_BUS_VIRT_BASE + 0x2100)
-
-#define BRIDGE_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x20000)
-#define BRIDGE_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x20000)
-#define  BRIDGE_WINS_BASE       (BRIDGE_PHYS_BASE)
-#define  BRIDGE_WINS_SZ         (0x80)
-
-#define CRYPTO_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x30000)
-
-#define PCIE_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x40000)
-#define PCIE_LINK_CTRL		(PCIE_VIRT_BASE + 0x70)
-#define PCIE_STATUS		(PCIE_VIRT_BASE + 0x1a04)
-#define PCIE1_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x44000)
-#define PCIE1_LINK_CTRL		(PCIE1_VIRT_BASE + 0x70)
-#define PCIE1_STATUS		(PCIE1_VIRT_BASE + 0x1a04)
-
-#define USB_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x50000)
-
-#define XOR0_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x60800)
-#define XOR0_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x60800)
-#define XOR1_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x60900)
-#define XOR1_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x60900)
-#define XOR0_HIGH_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x60A00)
-#define XOR0_HIGH_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x60A00)
-#define XOR1_HIGH_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x60B00)
-#define XOR1_HIGH_VIRT_BASE	(KIRKWOOD_REGS_VIRT_BASE + 0x60B00)
-
-#define GE00_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x70000)
-#define GE01_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x74000)
-
-#define SATA_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x80000)
-#define SATA_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0x80000)
-#define SATA0_IF_CTRL		(SATA_VIRT_BASE + 0x2050)
-#define SATA0_PHY_MODE_2	(SATA_VIRT_BASE + 0x2330)
-#define SATA1_IF_CTRL		(SATA_VIRT_BASE + 0x4050)
-#define SATA1_PHY_MODE_2	(SATA_VIRT_BASE + 0x4330)
-
-#define SDIO_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0x90000)
-
-#define AUDIO_PHYS_BASE		(KIRKWOOD_REGS_PHYS_BASE + 0xA0000)
-#define AUDIO_VIRT_BASE		(KIRKWOOD_REGS_VIRT_BASE + 0xA0000)
-
-/*
- * Supported devices and revisions.
- */
-#define MV88F6281_DEV_ID	0x6281
-#define MV88F6281_REV_Z0	0
-#define MV88F6281_REV_A0	2
-#define MV88F6281_REV_A1	3
-
-#define MV88F6192_DEV_ID	0x6192
-#define MV88F6192_REV_Z0	0
-#define MV88F6192_REV_A0	2
-#define MV88F6192_REV_A1	3
-
-#define MV88F6180_DEV_ID	0x6180
-#define MV88F6180_REV_A0	2
-#define MV88F6180_REV_A1	3
-
-#define MV88F6282_DEV_ID	0x6282
-#define MV88F6282_REV_A0	0
-#define MV88F6282_REV_A1	1
-#endif
diff --git a/arch/arm/mach-mvebu/kirkwood-pm.c b/arch/arm/mach-mvebu/kirkwood-pm.c
index b8c8365b84d8..cbb816f2120c 100644
--- a/arch/arm/mach-mvebu/kirkwood-pm.c
+++ b/arch/arm/mach-mvebu/kirkwood-pm.c
@@ -17,7 +17,7 @@
 #include <linux/kernel.h>
 #include <linux/suspend.h>
 #include <linux/io.h>
-#include <mach/bridge-regs.h>
+#include "kirkwood.h"
 
 static void __iomem *ddr_operation_base;
 static void __iomem *memory_pm_ctrl;
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index af77923a3483..1df0c0b138d5 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -23,9 +23,9 @@
 #include <asm/hardware/cache-feroceon-l2.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <mach/bridge-regs.h>
 #include <plat/common.h>
 #include <plat/pcie.h>
+#include "kirkwood.h"
 #include "kirkwood-pm.h"
 #include "common.h"
 
diff --git a/arch/arm/mach-mvebu/kirkwood.h b/arch/arm/mach-mvebu/kirkwood.h
new file mode 100644
index 000000000000..89f3d1f51643
--- /dev/null
+++ b/arch/arm/mach-mvebu/kirkwood.h
@@ -0,0 +1,22 @@
+/*
+ * arch/arm/mach-mvebu/kirkwood.h
+ *
+ * Generic definitions for Marvell Kirkwood SoC flavors:
+ * 88F6180, 88F6192 and 88F6281.
+ *
+ * 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.
+ */
+
+#define KIRKWOOD_REGS_PHYS_BASE	0xf1000000
+#define DDR_PHYS_BASE           (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
+#define BRIDGE_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x20000)
+
+#define DDR_OPERATION_BASE	(DDR_PHYS_BASE + 0x1418)
+
+#define CPU_CONFIG_PHYS		(BRIDGE_PHYS_BASE + 0x0100)
+#define CPU_CONFIG_ERROR_PROP	0x00000004
+
+#define CPU_CONTROL_PHYS	(BRIDGE_PHYS_BASE + 0x0104)
+#define MEMORY_PM_CTRL_PHYS	(BRIDGE_PHYS_BASE + 0x0118)
-- 
1.8.5.3

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri,  7 Feb 2014 00:42:15 +0100, Andrew Lunn wrote:
> kirkwood is very nearly fully DT. Remove most of the address
> definitions from the header files and make it a local header file.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/mach-mvebu/include/mach/bridge-regs.h |  85 ---------------
>  arch/arm/mach-mvebu/include/mach/kirkwood.h    | 142 -------------------------
>  arch/arm/mach-mvebu/kirkwood-pm.c              |   2 +-
>  arch/arm/mach-mvebu/kirkwood.c                 |   2 +-
>  arch/arm/mach-mvebu/kirkwood.h                 |  22 ++++
>  5 files changed, 24 insertions(+), 229 deletions(-)
>  delete mode 100644 arch/arm/mach-mvebu/include/mach/bridge-regs.h
>  delete mode 100644 arch/arm/mach-mvebu/include/mach/kirkwood.h
>  create mode 100644 arch/arm/mach-mvebu/kirkwood.h

Is there any particular reason why this isn't part of PATCH 14/21. I
was very surprised when reading PATCH 14/21 to see a file named
"bridge-regs.h" containing Kirkwood-specific definitions added to
mach-mvebu, and so many address constants being defined, while we are
DT-based only in mach-mvebu.

> +#define KIRKWOOD_REGS_PHYS_BASE	0xf1000000
> +#define DDR_PHYS_BASE           (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
> +#define BRIDGE_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x20000)
> +
> +#define DDR_OPERATION_BASE	(DDR_PHYS_BASE + 0x1418)
> +
> +#define CPU_CONFIG_PHYS		(BRIDGE_PHYS_BASE + 0x0100)
> +#define CPU_CONFIG_ERROR_PROP	0x00000004
> +
> +#define CPU_CONTROL_PHYS	(BRIDGE_PHYS_BASE + 0x0104)
> +#define MEMORY_PM_CTRL_PHYS	(BRIDGE_PHYS_BASE + 0x0118)

Are there plans to also get rid of those constants at some point?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Andrew Lunn]

On Fri, Feb 07, 2014 at 09:31:04AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri,  7 Feb 2014 00:42:15 +0100, Andrew Lunn wrote:
> > kirkwood is very nearly fully DT. Remove most of the address
> > definitions from the header files and make it a local header file.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/mach-mvebu/include/mach/bridge-regs.h |  85 ---------------
> >  arch/arm/mach-mvebu/include/mach/kirkwood.h    | 142 -------------------------
> >  arch/arm/mach-mvebu/kirkwood-pm.c              |   2 +-
> >  arch/arm/mach-mvebu/kirkwood.c                 |   2 +-
> >  arch/arm/mach-mvebu/kirkwood.h                 |  22 ++++
> >  5 files changed, 24 insertions(+), 229 deletions(-)
> >  delete mode 100644 arch/arm/mach-mvebu/include/mach/bridge-regs.h
> >  delete mode 100644 arch/arm/mach-mvebu/include/mach/kirkwood.h
> >  create mode 100644 arch/arm/mach-mvebu/kirkwood.h
> 
> Is there any particular reason why this isn't part of PATCH 14/21. I
> was very surprised when reading PATCH 14/21 to see a file named
> "bridge-regs.h" containing Kirkwood-specific definitions added to
> mach-mvebu, and so many address constants being defined, while we are
> DT-based only in mach-mvebu.

Hi Thomas

I wanted to keep 14/21 as a simple move of files, doing the minimal
needed to make it boot. The patches that follow then clean up. I found
that simpler to follow what was going on, since there is nothing
hidden in the move patch.

I can however squash these together if that is what people want to
see.

	Andrew

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri, 7 Feb 2014 10:20:47 +0100, Andrew Lunn wrote:

> I wanted to keep 14/21 as a simple move of files, doing the minimal
> needed to make it boot. The patches that follow then clean up. I found
> that simpler to follow what was going on, since there is nothing
> hidden in the move patch.
> 
> I can however squash these together if that is what people want to
> see.

Ok. Then maybe the commit log should indicate this (that the commit is
only a move and that followup commits clean things up).

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Andrew Lunn]

On Fri, Feb 07, 2014 at 10:36:31AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri, 7 Feb 2014 10:20:47 +0100, Andrew Lunn wrote:
> 
> > I wanted to keep 14/21 as a simple move of files, doing the minimal
> > needed to make it boot. The patches that follow then clean up. I found
> > that simpler to follow what was going on, since there is nothing
> > hidden in the move patch.
> > 
> > I can however squash these together if that is what people want to
> > see.
> 
> Ok. Then maybe the commit log should indicate this (that the commit is
> only a move and that followup commits clean things up).

Hi Thomas

The commit log for 14/21 currently is:

Move the kirkwood DT support into mach-mvebu, and make them part of                                              
ARCH_MULTI_V5. Minimal changes have been made in order to make it                                                
boot. More integration will take place in following patches. 

I could change "integration" to "integration and cleanup".

  Andrew

[PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local

[Jason Gunthorpe]

> > +#define KIRKWOOD_REGS_PHYS_BASE	0xf1000000
> > +#define DDR_PHYS_BASE           (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
> > +#define BRIDGE_PHYS_BASE	(KIRKWOOD_REGS_PHYS_BASE + 0x20000)

Sorry I missed this earlier, but it would be *super nice* if
KIRKWOOD_REGS_PHYS_BASE could go away. 0xf1000000 is an arbitary
policy choice and with the mbus driver this is the last hold out.

That said, it could be revised after your series. :)

Regards,
Jason

[PATCH 20/21] ARM: MVEBU: Remove unneeded headers

[Andrew Lunn]

Remove headers which are no longer needed, and add a couple of missing
onces.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-mvebu/kirkwood.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index 1df0c0b138d5..5d7fef04c36d 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -13,18 +13,15 @@
 #include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
+#include <linux/mbus.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_net.h>
 #include <linux/of_platform.h>
-#include <linux/dma-mapping.h>
-#include <linux/irqchip.h>
-#include <linux/kexec.h>
+#include <linux/slab.h>
 #include <asm/hardware/cache-feroceon-l2.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <plat/common.h>
-#include <plat/pcie.h>
 #include "kirkwood.h"
 #include "kirkwood-pm.h"
 #include "common.h"
-- 
1.8.5.3

[PATCH 20/21] ARM: MVEBU: Remove unneeded headers

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:42:16AM +0100, Andrew Lunn wrote:
> Remove headers which are no longer needed, and add a couple of missing
> onces.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/mach-mvebu/kirkwood.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)

You could probably collapse this into the previous patch.

thx,

Jason.

> diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
> index 1df0c0b138d5..5d7fef04c36d 100644
> --- a/arch/arm/mach-mvebu/kirkwood.c
> +++ b/arch/arm/mach-mvebu/kirkwood.c
> @@ -13,18 +13,15 @@
>  #include <linux/clk.h>
>  #include <linux/kernel.h>
>  #include <linux/init.h>
> +#include <linux/mbus.h>
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/of_net.h>
>  #include <linux/of_platform.h>
> -#include <linux/dma-mapping.h>
> -#include <linux/irqchip.h>
> -#include <linux/kexec.h>
> +#include <linux/slab.h>
>  #include <asm/hardware/cache-feroceon-l2.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
> -#include <plat/common.h>
> -#include <plat/pcie.h>
>  #include "kirkwood.h"
>  #include "kirkwood-pm.h"
>  #include "common.h"
> -- 
> 1.8.5.3
> 

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

Now that all the device tree support is in mach-mvebu, remove it from
mach-kirkwood.

Regenerate kirkwood_defconfig, removing all DT support, and a couple
of other redundent options have been removed in the process.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/configs/kirkwood_defconfig |   6 -
 arch/arm/mach-kirkwood/Kconfig      |  18 ---
 arch/arm/mach-kirkwood/Makefile     |   2 -
 arch/arm/mach-kirkwood/board-dt.c   | 227 ------------------------------------
 4 files changed, 253 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-dt.c

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 2e762d94e94b..95b5585c1fbb 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -20,13 +20,9 @@ CONFIG_MACH_RD88F6281=y
 CONFIG_MACH_T5325=y
 CONFIG_MACH_TS219=y
 CONFIG_MACH_TS41X=y
-CONFIG_ARCH_KIRKWOOD_DT=y
-CONFIG_MACH_MV88F6281GTW_GE_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
-CONFIG_PCI_MVEBU=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
 CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
@@ -85,7 +81,6 @@ CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
 # CONFIG_I2C_COMPAT is not set
@@ -176,5 +171,4 @@ CONFIG_CRYPTO_PCBC=m
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
 CONFIG_CRYPTO_DEV_MV_CESA=y
 CONFIG_CRC_CCITT=y
-CONFIG_CRC16=y
 CONFIG_LIBCRC32C=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index df4b26340ae4..fb4560d2605f 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -88,24 +88,6 @@ config MACH_TS41X
 	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
 	  NAS devices.
 
-comment "Device tree entries"
-
-config ARCH_KIRKWOOD_DT
-	bool "Marvell Kirkwood Flattened Device Tree"
-	select KIRKWOOD_CLK
-	select OF_IRQ
-	select ORION_IRQCHIP
-	select ORION_TIMER
-	select POWER_SUPPLY
-	select POWER_RESET
-	select POWER_RESET_GPIO
-	select REGULATOR
-	select REGULATOR_FIXED_VOLTAGE
-	select USE_OF
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell Kirkwood using flattened device tree.
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 3a72c5c6e747..c772d7584937 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -10,5 +10,3 @@ obj-$(CONFIG_MACH_RD88F6281)		+= rd88f6281-setup.o
 obj-$(CONFIG_MACH_T5325)		+= t5325-setup.o
 obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
-
-obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
deleted file mode 100644
index 2ef59ee2182d..000000000000
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ /dev/null
@@ -1,227 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason@lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-dt.c
- *
- * Flattened Device Tree board initialization
- *
- * 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/clk.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_net.h>
-#include <linux/of_platform.h>
-#include <linux/dma-mapping.h>
-#include <linux/irqchip.h>
-#include <linux/kexec.h>
-#include <asm/hardware/cache-feroceon-l2.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include <mach/bridge-regs.h>
-#include <plat/common.h>
-#include <plat/pcie.h>
-#include "pm.h"
-
-static struct map_desc kirkwood_io_desc[] __initdata = {
-	{
-		.virtual	= (unsigned long) KIRKWOOD_REGS_VIRT_BASE,
-		.pfn		= __phys_to_pfn(KIRKWOOD_REGS_PHYS_BASE),
-		.length		= KIRKWOOD_REGS_SIZE,
-		.type		= MT_DEVICE,
-	},
-};
-
-static void __init kirkwood_map_io(void)
-{
-	iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc));
-}
-
-static struct resource kirkwood_cpufreq_resources[] = {
-	[0] = {
-		.start  = CPU_CONTROL_PHYS,
-		.end    = CPU_CONTROL_PHYS + 3,
-		.flags  = IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device kirkwood_cpufreq_device = {
-	.name		= "kirkwood-cpufreq",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(kirkwood_cpufreq_resources),
-	.resource	= kirkwood_cpufreq_resources,
-};
-
-static void __init kirkwood_cpufreq_init(void)
-{
-	platform_device_register(&kirkwood_cpufreq_device);
-}
-
-static struct resource kirkwood_cpuidle_resource[] = {
-	{
-		.flags	= IORESOURCE_MEM,
-		.start	= DDR_OPERATION_BASE,
-		.end	= DDR_OPERATION_BASE + 3,
-	},
-};
-
-static struct platform_device kirkwood_cpuidle = {
-	.name		= "kirkwood_cpuidle",
-	.id		= -1,
-	.resource	= kirkwood_cpuidle_resource,
-	.num_resources	= 1,
-};
-
-static void __init kirkwood_cpuidle_init(void)
-{
-	platform_device_register(&kirkwood_cpuidle);
-}
-
-/* Temporary here since mach-mvebu has a function we can use */
-static void kirkwood_restart(enum reboot_mode mode, const char *cmd)
-{
-	/*
-	 * Enable soft reset to assert RSTOUTn.
-	 */
-	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
-
-	/*
-	 * Assert soft reset.
-	 */
-	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
-
-	while (1)
-		;
-}
-
-#define MV643XX_ETH_MAC_ADDR_LOW	0x0414
-#define MV643XX_ETH_MAC_ADDR_HIGH	0x0418
-
-static void __init kirkwood_dt_eth_fixup(void)
-{
-	struct device_node *np;
-
-	/*
-	 * The ethernet interfaces forget the MAC address assigned by u-boot
-	 * if the clocks are turned off. Usually, u-boot on kirkwood boards
-	 * has no DT support to properly set local-mac-address property.
-	 * As a workaround, we get the MAC address from mv643xx_eth registers
-	 * and update the port device node if no valid MAC address is set.
-	 */
-	for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") {
-		struct device_node *pnp = of_get_parent(np);
-		struct clk *clk;
-		struct property *pmac;
-		void __iomem *io;
-		u8 *macaddr;
-		u32 reg;
-
-		if (!pnp)
-			continue;
-
-		/* skip disabled nodes or nodes with valid MAC address*/
-		if (!of_device_is_available(pnp) || of_get_mac_address(np))
-			goto eth_fixup_skip;
-
-		clk = of_clk_get(pnp, 0);
-		if (IS_ERR(clk))
-			goto eth_fixup_skip;
-
-		io = of_iomap(pnp, 0);
-		if (!io)
-			goto eth_fixup_no_map;
-
-		/* ensure port clock is not gated to not hang CPU */
-		clk_prepare_enable(clk);
-
-		/* store MAC address register contents in local-mac-address */
-		pr_err(FW_INFO "%s: local-mac-address is not set\n",
-		       np->full_name);
-
-		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
-		if (!pmac)
-			goto eth_fixup_no_mem;
-
-		pmac->value = pmac + 1;
-		pmac->length = 6;
-		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
-		if (!pmac->name) {
-			kfree(pmac);
-			goto eth_fixup_no_mem;
-		}
-
-		macaddr = pmac->value;
-		reg = readl(io + MV643XX_ETH_MAC_ADDR_HIGH);
-		macaddr[0] = (reg >> 24) & 0xff;
-		macaddr[1] = (reg >> 16) & 0xff;
-		macaddr[2] = (reg >> 8) & 0xff;
-		macaddr[3] = reg & 0xff;
-
-		reg = readl(io + MV643XX_ETH_MAC_ADDR_LOW);
-		macaddr[4] = (reg >> 8) & 0xff;
-		macaddr[5] = reg & 0xff;
-
-		of_update_property(np, pmac);
-
-eth_fixup_no_mem:
-		iounmap(io);
-		clk_disable_unprepare(clk);
-eth_fixup_no_map:
-		clk_put(clk);
-eth_fixup_skip:
-		of_node_put(pnp);
-	}
-}
-
-/*
- * Disable propagation of mbus errors to the CPU local bus, as this
- * causes mbus errors (which can occur for example for PCI aborts) to
- * throw CPU aborts, which we're not set up to deal with.
- */
-void kirkwood_disable_mbus_error_propagation(void)
-{
-	void __iomem *cpu_config;
-
-	cpu_config = ioremap(CPU_CONFIG_PHYS, 4);
-	writel(readl(cpu_config) & ~CPU_CONFIG_ERROR_PROP, cpu_config);
-}
-
-
-static void __init kirkwood_dt_init(void)
-{
-	kirkwood_disable_mbus_error_propagation();
-
-	BUG_ON(mvebu_mbus_dt_init());
-
-	feroceon_of_init();
-
-	kirkwood_cpufreq_init();
-	kirkwood_cpuidle_init();
-
-	kirkwood_pm_init();
-	kirkwood_dt_eth_fixup();
-
-#ifdef CONFIG_KEXEC
-	kexec_reinit = kirkwood_enable_pcie;
-#endif
-
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
-static const char * const kirkwood_dt_board_compat[] = {
-	"marvell,kirkwood",
-	NULL
-};
-
-DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
-	/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
-	.map_io		= kirkwood_map_io,
-	.init_machine	= kirkwood_dt_init,
-	.restart	= kirkwood_restart,
-	.dt_compat	= kirkwood_dt_board_compat,
-MACHINE_END
-- 
1.8.5.3

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri,  7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote:
> Now that all the device tree support is in mach-mvebu, remove it from
> mach-kirkwood.
> 
> Regenerate kirkwood_defconfig, removing all DT support, and a couple
> of other redundent options have been removed in the process.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/configs/kirkwood_defconfig |   6 -

So after this series we have a mvebu_defconfig that only builds the
ARMv7 platforms of mach-mvebu. I believe this may look strange to
people looking at the code, seeing that Kirkwood DT support is in
mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood
kernel.

I don't really have a solution, except maybe having mvebu_v7_defconfig
and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5
platforms.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

On Fri, Feb 07, 2014 at 09:33:13AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri,  7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote:
> > Now that all the device tree support is in mach-mvebu, remove it from
> > mach-kirkwood.
> > 
> > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > of other redundent options have been removed in the process.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/configs/kirkwood_defconfig |   6 -
> 
> So after this series we have a mvebu_defconfig that only builds the
> ARMv7 platforms of mach-mvebu. I believe this may look strange to
> people looking at the code, seeing that Kirkwood DT support is in
> mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood
> kernel.
> 
> I don't really have a solution, except maybe having mvebu_v7_defconfig
> and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5
> platforms.

Hi Thomas

I also have no solution, other than what you suggested. I think it
also goes against the rules for a platform to have multiple _defconfig
files. We probably do have a good cause to go against the rules
thought. Lets wait and see what ARM SOC maintainers suggest.

	 Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Fri, Feb 07, 2014 at 09:33:13AM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri,  7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote:
> > Now that all the device tree support is in mach-mvebu, remove it from
> > mach-kirkwood.
> > 
> > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > of other redundent options have been removed in the process.
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/configs/kirkwood_defconfig |   6 -
> 
> So after this series we have a mvebu_defconfig that only builds the
> ARMv7 platforms of mach-mvebu. I believe this may look strange to
> people looking at the code, seeing that Kirkwood DT support is in
> mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood
> kernel.
> 
> I don't really have a solution, except maybe having mvebu_v7_defconfig
> and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5
> platforms.

Ideally, I'd prefer multi_v7 and multi_v5 for DT, and
{kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building.
The latter going away once we deprecate non-DT booting.  There is a case
to be made for the arch-specific defconfigs, though.

Currently (includes modules if configured, and dtbs);

  mvebu_defconfig	00:02:56
  x86_64_defconfig	00:04:24
  multi_v7_defconfig	00:04:05

1 minute and 9 seconds doesn't drastically change a bathroom break or
tea time ;-)  But it is a 33% increase.

If we want something leaner than multi_v7, how about
armada_370-xp_defconfig to replace the current mvebu_defconfig?

kirkwood_defconfig could enable ARCH_KIRKWOOD and MACH_KIRKWOOD until we
remove legacy boot.  Same with dove_defconfig and the others.

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Thomas Petazzoni]

Dear Jason Cooper,

On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote:

> Ideally, I'd prefer multi_v7 and multi_v5 for DT, and
> {kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building.
> The latter going away once we deprecate non-DT booting.  There is a case
> to be made for the arch-specific defconfigs, though.
> 
> Currently (includes modules if configured, and dtbs);
> 
>   mvebu_defconfig	00:02:56
>   x86_64_defconfig	00:04:24
>   multi_v7_defconfig	00:04:05
> 
> 1 minute and 9 seconds doesn't drastically change a bathroom break or
> tea time ;-)  But it is a 33% increase.

I also like to have a more focused defconfig than multi_v7 for
development.

> If we want something leaner than multi_v7, how about
> armada_370-xp_defconfig to replace the current mvebu_defconfig?

Doesn't work for me: we're going to introduce soon the support for
other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should
be built as part of this.

Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
Dove and Armada 370/XP (and the other ones we are going to introduce
soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
enough time to work on this platform).

This way, ultimately we can simply remove kirkwood_defconfig and
dove_defconfig, as soon as all legacy platforms have been either
converted to DT, or removed.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Fri, Feb 07, 2014 at 04:09:54PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote:
> 
> > Ideally, I'd prefer multi_v7 and multi_v5 for DT, and
> > {kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building.
> > The latter going away once we deprecate non-DT booting.  There is a case
> > to be made for the arch-specific defconfigs, though.
> > 
> > Currently (includes modules if configured, and dtbs);
> > 
> >   mvebu_defconfig	00:02:56
> >   x86_64_defconfig	00:04:24
> >   multi_v7_defconfig	00:04:05
> > 
> > 1 minute and 9 seconds doesn't drastically change a bathroom break or
> > tea time ;-)  But it is a 33% increase.
> 
> I also like to have a more focused defconfig than multi_v7 for
> development.
> 
> > If we want something leaner than multi_v7, how about
> > armada_370-xp_defconfig to replace the current mvebu_defconfig?
> 
> Doesn't work for me: we're going to introduce soon the support for
> other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should
> be built as part of this.
> 
> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
> Dove and Armada 370/XP (and the other ones we are going to introduce
> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
> enough time to work on this platform).

Yeah, I can go with that, as long as Sebastian doesn't see a need for a
separate dove_defconfig in the long term (DT only).  Sebastian?

> This way, ultimately we can simply remove kirkwood_defconfig and
> dove_defconfig, as soon as all legacy platforms have been either
> converted to DT, or removed.

Yep, the fewer builds I have to do per patch submission, the better.

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Sebastian Hesselbarth]

On 02/07/2014 04:15 PM, Jason Cooper wrote:
> On Fri, Feb 07, 2014 at 04:09:54PM +0100, Thomas Petazzoni wrote:
>> On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote:
>>> If we want something leaner than multi_v7, how about
>>> armada_370-xp_defconfig to replace the current mvebu_defconfig?
>>
>> Doesn't work for me: we're going to introduce soon the support for
>> other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should
>> be built as part of this.
>>
>> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
>> Dove and Armada 370/XP (and the other ones we are going to introduce
>> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
>> enough time to work on this platform).
>
> Yeah, I can go with that, as long as Sebastian doesn't see a need for a
> separate dove_defconfig in the long term (DT only).  Sebastian?

Nope, I have no plans to keep a special dove_defconfig for Dove in
mach-mvebu.

>> This way, ultimately we can simply remove kirkwood_defconfig and
>> dove_defconfig, as soon as all legacy platforms have been either
>> converted to DT, or removed.
>
> Yep, the fewer builds I have to do per patch submission, the better.

Sounds good to me.

Sebastian

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
> Dove and Armada 370/XP (and the other ones we are going to introduce
> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
> enough time to work on this platform).

Hi Thomas

Could you produce a patch moving mvebu_defconfig to
mvebu_v7_defconfig? I will generate the mvebu_v5_defconfig based on
kirkwood_defconfig as part of my patchset.

Thanks
	Andrew


> 
> This way, ultimately we can simply remove kirkwood_defconfig and
> dove_defconfig, as soon as all legacy platforms have been either
> converted to DT, or removed.
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Sebastian Hesselbarth]

On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> Now that all the device tree support is in mach-mvebu, remove it from
> mach-kirkwood.
>
> Regenerate kirkwood_defconfig, removing all DT support, and a couple
> of other redundent options have been removed in the process.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---

Hmm, I wonder what Ian thinks of removing this so quickly again...

Maybe let it rot for 1-2 kernel versions?

Sebastian

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Fri, Feb 07, 2014 at 06:34:26PM +0100, Sebastian Hesselbarth wrote:
> On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> >Now that all the device tree support is in mach-mvebu, remove it from
> >mach-kirkwood.
> >
> >Regenerate kirkwood_defconfig, removing all DT support, and a couple
> >of other redundent options have been removed in the process.
> >
> >Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >---
> 
> Hmm, I wonder what Ian thinks of removing this so quickly again...
> 
> Maybe let it rot for 1-2 kernel versions?

The easiest answer is to modify kirkwood_defconfig to select both
ARCH_KIRKWOOD and MACH_KIRKWOOD until such time as we have a working dts
file for _every_ board file.  Only then should we look at beginning the
deprecation process for non-DT.

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > Now that all the device tree support is in mach-mvebu, remove it from
> > mach-kirkwood.
> >
> > Regenerate kirkwood_defconfig, removing all DT support, and a couple

s/DT/board-file/?

> > of other redundent options have been removed in the process.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> 
> Hmm, I wonder what Ian thinks of removing this so quickly again...

I don't want to stand in the way of progress. What version is this
targeting so I can setup our tooling to DTRT and append a DTB under the
correct circumstances.

I still need to figure out how to distinguish the variations, but I
think I have a plan there (via which PCI buses are present, which is a
bit skanky but seems like the most workable solution).

Ian.

> Maybe let it rot for 1-2 kernel versions?
> 
> Sebastian
> 
> 

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > Now that all the device tree support is in mach-mvebu, remove it from
> > > mach-kirkwood.
> > >
> > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> 
> s/DT/board-file/?

We keep any system using -setup.c files, and remove the ability to
boot systems with a DT description. Thus mach-kirkwood becomes legacy,
and you should now be trying to only use mach-mvebu, compiled for v5
systems and a second compile for v7 systems.

There are four systems left in mach-kirkwood which don't have DT
equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
point is audio support, which no other board has done with DT yet.
The two LeCie boards have a custom LED driver which needs a DT
binding. My gut feeling is that we won't get these four converted to
DT in time for 3.15.
 
> > > of other redundent options have been removed in the process.
> > >
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > ---
> > 
> > Hmm, I wonder what Ian thinks of removing this so quickly again...
> 
> I don't want to stand in the way of progress. What version is this
> targeting so I can setup our tooling to DTRT and append a DTB under the
> correct circumstances.

My aim is 3.15. Most patches have been Acked now, so i think we are on
track for that.

 
> I still need to figure out how to distinguish the variations, but I
> think I have a plan there (via which PCI buses are present, which is a
> bit skanky but seems like the most workable solution).

Having the SoC ID available via lspci for systems using the new PCI
driver might be in 3.14. It was considered a regression so might get
merged into an rc. If not, it will be in 3.15.

We have also talked about putting the SOC version and revision into
/proc/cpuinfo, in the Revision field. However this has not happened
yet.

	Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Russell King - ARM Linux]

On Thu, Feb 20, 2014 at 11:58:54AM +0100, Andrew Lunn wrote:
> On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > > Now that all the device tree support is in mach-mvebu, remove it from
> > > > mach-kirkwood.
> > > >
> > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > 
> > s/DT/board-file/?
> 
> We keep any system using -setup.c files, and remove the ability to
> boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> and you should now be trying to only use mach-mvebu, compiled for v5
> systems and a second compile for v7 systems.
> 
> There are four systems left in mach-kirkwood which don't have DT
> equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> point is audio support, which no other board has done with DT yet.
> The two LeCie boards have a custom LED driver which needs a DT
> binding. My gut feeling is that we won't get these four converted to
> DT in time for 3.15.
>  
> > > > of other redundent options have been removed in the process.
> > > >
> > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > > ---
> > > 
> > > Hmm, I wonder what Ian thinks of removing this so quickly again...
> > 
> > I don't want to stand in the way of progress. What version is this
> > targeting so I can setup our tooling to DTRT and append a DTB under the
> > correct circumstances.
> 
> My aim is 3.15. Most patches have been Acked now, so i think we are on
> track for that.
> 
>  
> > I still need to figure out how to distinguish the variations, but I
> > think I have a plan there (via which PCI buses are present, which is a
> > bit skanky but seems like the most workable solution).
> 
> Having the SoC ID available via lspci for systems using the new PCI
> driver might be in 3.14. It was considered a regression so might get
> merged into an rc. If not, it will be in 3.15.
> 
> We have also talked about putting the SOC version and revision into
> /proc/cpuinfo, in the Revision field. However this has not happened
> yet.

NAK.

What's wrong with the soc subsystem (drivers/base/soc.c).  This provides
a way to export SoC through standardised interfaces.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

On Thu, Feb 20, 2014 at 11:19:14AM +0000, Russell King - ARM Linux wrote:
> > We have also talked about putting the SOC version and revision into
> > /proc/cpuinfo, in the Revision field. However this has not happened
> > yet.
> 
> NAK.
> 
> What's wrong with the soc subsystem (drivers/base/soc.c).  This provides
> a way to export SoC through standardised interfaces.

Hi Russell

Thanks for the tip. We will do this.

       Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote:
> What's wrong with the soc subsystem (drivers/base/soc.c).  This
> provides a way to export SoC through standardised interfaces. 

It looks like the thing to use to me.

It seems to have been around only since v3.3 though, which makes it a
bit tricky to use when upgrading from running board-file based v3.2
system (Debian Wheezy) to a newer DTB based kernel, we need to select
the new DTB while running the old system.

I'd prefer to use this thing as the primary mechanism but it seems like
I'd have to implement some sort of fallback at least for one Debian
release cycle. I'm sure it is doable...

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Thu, Feb 20, 2014 at 11:39:16AM +0000, Ian Campbell wrote:
> On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote:
> > What's wrong with the soc subsystem (drivers/base/soc.c).  This
> > provides a way to export SoC through standardised interfaces. 
> 
> It looks like the thing to use to me.
> 
> It seems to have been around only since v3.3 though, which makes it a
> bit tricky to use when upgrading from running board-file based v3.2
> system (Debian Wheezy) to a newer DTB based kernel, we need to select
> the new DTB while running the old system.
> 
> I'd prefer to use this thing as the primary mechanism but it seems like
> I'd have to implement some sort of fallback at least for one Debian
> release cycle. I'm sure it is doable...

back in v3.2, lspci should still work.  Would that given you the
information you need?

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 18:26 -0500, Jason Cooper wrote:
> On Thu, Feb 20, 2014 at 11:39:16AM +0000, Ian Campbell wrote:
> > On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote:
> > > What's wrong with the soc subsystem (drivers/base/soc.c).  This
> > > provides a way to export SoC through standardised interfaces. 
> > 
> > It looks like the thing to use to me.
> > 
> > It seems to have been around only since v3.3 though, which makes it a
> > bit tricky to use when upgrading from running board-file based v3.2
> > system (Debian Wheezy) to a newer DTB based kernel, we need to select
> > the new DTB while running the old system.
> > 
> > I'd prefer to use this thing as the primary mechanism but it seems like
> > I'd have to implement some sort of fallback at least for one Debian
> > release cycle. I'm sure it is doable...
> 
> back in v3.2, lspci should still work.  Would that given you the
> information you need?

I expect it will, yes.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

> > > > What's wrong with the soc subsystem (drivers/base/soc.c).  This
> > > > provides a way to export SoC through standardised interfaces. 
> > > 
> > > It looks like the thing to use to me.
> > > 
> > > It seems to have been around only since v3.3 though, which makes it a
> > > bit tricky to use when upgrading from running board-file based v3.2
> > > system (Debian Wheezy) to a newer DTB based kernel, we need to select
> > > the new DTB while running the old system.
> > > 
> > > I'd prefer to use this thing as the primary mechanism but it seems like
> > > I'd have to implement some sort of fallback at least for one Debian
> > > release cycle. I'm sure it is doable...
> > 
> > back in v3.2, lspci should still work.  Would that given you the
> > information you need?
> 
> I expect it will, yes.

3.14 with the new PCIe driver will also work. The patch was accepted
and considered a regression so made it into one of the -rc's.

     Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote:
> > > > > What's wrong with the soc subsystem (drivers/base/soc.c).  This
> > > > > provides a way to export SoC through standardised interfaces. 
> > > > 
> > > > It looks like the thing to use to me.
> > > > 
> > > > It seems to have been around only since v3.3 though, which makes it a
> > > > bit tricky to use when upgrading from running board-file based v3.2
> > > > system (Debian Wheezy) to a newer DTB based kernel, we need to select
> > > > the new DTB while running the old system.
> > > > 
> > > > I'd prefer to use this thing as the primary mechanism but it seems like
> > > > I'd have to implement some sort of fallback at least for one Debian
> > > > release cycle. I'm sure it is doable...
> > > 
> > > back in v3.2, lspci should still work.  Would that given you the
> > > information you need?
> > 
> > I expect it will, yes.
> 
> 3.14 with the new PCIe driver will also work. The patch was accepted
> and considered a regression so made it into one of the -rc's.

Great! Thanks.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Mon, Feb 24, 2014 at 04:26:16PM +0000, Ian Campbell wrote:
> On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote:
> > > > > > What's wrong with the soc subsystem (drivers/base/soc.c).  This
> > > > > > provides a way to export SoC through standardised interfaces. 
> > > > > 
> > > > > It looks like the thing to use to me.
> > > > > 
> > > > > It seems to have been around only since v3.3 though, which makes it a
> > > > > bit tricky to use when upgrading from running board-file based v3.2
> > > > > system (Debian Wheezy) to a newer DTB based kernel, we need to select
> > > > > the new DTB while running the old system.
> > > > > 
> > > > > I'd prefer to use this thing as the primary mechanism but it seems like
> > > > > I'd have to implement some sort of fallback at least for one Debian
> > > > > release cycle. I'm sure it is doable...
> > > > 
> > > > back in v3.2, lspci should still work.  Would that given you the
> > > > information you need?
> > > 
> > > I expect it will, yes.
> > 
> > 3.14 with the new PCIe driver will also work. The patch was accepted
> > and considered a regression so made it into one of the -rc's.
> 
> Great! Thanks.

fyi:

  322a8e91844f PCI: mvebu: Use Device ID and revision from underlying endpoint

It's in -rc4 and it's flagged for stable from v3.11 on up.  v3.11 is
when the pcie driver was introduced (and thus, the regression).

hth,

Jason.

Automatically detecting when to use kirkwood-tsXXX-6281.dtb vs -6282.dtb (Was: Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support)

[Ian Campbell]

On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote:
> > > back in v3.2, lspci should still work.  Would that given you the
> > > information you need?
> > 
> > I expect it will, yes.
> 
> 3.14 with the new PCIe driver will also work. The patch was accepted
> and considered a regression so made it into one of the -rc's.

I've finally gotten around to doing something about detecting the
various different ts-xxx platforms in order to select between the 6281
and 6282 dtbs (reminder: I need to do this when running both old board
file kernels and new dtb based ones in order to support upgrades).

On TS-419 the PCI ID method works fine when running under 3.2 and 3.14
both using a board file. I'm currently building 3.15 with dts support so
I can test that too (and the soc subsystem export of the SoC ID which
was added in 3.15) but I'm relatively confident that'll all be OK.

However on my 6281 based TS-219 system there seems to be no visible PCI
bus when running the 3.2 kernel in the current Debian stable release
(which of course uses board support). Some info:
        $ grep ^Hardw /proc/cpuinfo 
        Hardware	: QNAP TS-119/TS-219
        $ cat /proc/device-tree/model ; echo
        cat: /proc/device-tree/model: No such file or directory
        
        $ lspci
        $ ls /sys/bus/pci/devices/
        $ ls /sys/class/pci_bus/
        0000:00@
        $ dmesg | grep -i pci
        [    5.024108] Kirkwood PCIe port 0: 
        [    5.024126] Kirkwood PCIe port 1: 
        [    5.024143] PCI: bus0 uses PCIe port 1
        [    5.024342] PCI: bus0: Fast back to back transfers enabled
        [    5.048486] PCI: CLS 0 bytes, default 32
        $ dmesg | grep 628
        [    5.022263] Kirkwood: MV88F6281-A1, TCLK=200000000.
        
ts219-setup.c and ts41x-setup.c don't appear to differ meaningfully in
their pcie setup -- i.e. they both call kirkwood_pcie_init, so I suppose
the difference is whether there is anything on the bus or not.

Is the lack of anything on the PCI bus itself sufficient to determine
that this is a 6281 based ts219 rather than a 6282 one (I don't have any
6282 ts219 systems to try)?

Might PHYAD (reported by ethtool eth0) be a useful fallback mechanism?
AIUI the phy addr is 8 for 6281 systems and 0 for 6282 ones.

Any other ideas?

Also the ts219-setup.c board file supports the ts119 as well, but I
don't see a DTB for that, is that in the works? Any ideas how I can
distinguish a 219 from a 119? On the 219 /sys/class/pci_bus/0000:00
exists (there is nothing under /sys/bus/pci/devices/ though), and since
the main difference in ts219-setup.c is that 119 doesn't call
kirkwood_pcie_init() I suspect the presence or absence
of /sys/class/pci_bus/0000:00 might be sufficient to distinguish them,
does that sound likely? (I don't have a ts119 to try either).

Thanks for any advice.

Ian.

Automatically detecting when to use kirkwood-tsXXX-6281.dtb vs -6282.dtb (Was: Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support)

[Andrew Lunn]

> However on my 6281 based TS-219 system there seems to be no visible PCI
> bus when running the 3.2 kernel in the current Debian stable release
> (which of course uses board support). Some info:

The old PCI driver looks to see if there is anything on the bus, and
if not, does not register the PCI bus to the PCI core. The new PCI
driver always registers the busses, allowing hotplug of PCI devices.

> Is the lack of anything on the PCI bus itself sufficient to determine
> that this is a 6281 based ts219 rather than a 6282 one (I don't have any
> 6282 ts219 systems to try)?

No, this is not sufficient, as far as i know. I have a 6282 based
ts119. It also does not have any PCI devices. However, the 6282 DT
file works fine on it. There is no need to differentiate between 119
and 219, just between 6281 and 6282.

Your idea about Ethernet PHY is probably the best way to tell them
apart. But i will see if i can find anything else.

    Andrew

Automatically detecting when to use kirkwood-tsXXX-6281.dtb vs -6282.dtb (Was: Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support)

[Ian Campbell]

On Sat, 2014-05-03 at 16:40 +0200, Andrew Lunn wrote:
> > However on my 6281 based TS-219 system there seems to be no visible PCI
> > bus when running the 3.2 kernel in the current Debian stable release
> > (which of course uses board support). Some info:
> 
> The old PCI driver looks to see if there is anything on the bus, and
> if not, does not register the PCI bus to the PCI core. The new PCI
> driver always registers the busses, allowing hotplug of PCI devices.

Got it, thanks.

> > Is the lack of anything on the PCI bus itself sufficient to determine
> > that this is a 6281 based ts219 rather than a 6282 one (I don't have any
> > 6282 ts219 systems to try)?
> 
> No, this is not sufficient, as far as i know. I have a 6282 based
> ts119. It also does not have any PCI devices. However, the 6282 DT
> file works fine on it. There is no need to differentiate between 119
> and 219, just between 6281 and 6282.

Thanks.

> Your idea about Ethernet PHY is probably the best way to tell them
> apart. But i will see if i can find anything else.

Thanks, I'll start on the PHY base solution, it'll be easy enough to
switch if something even better gets thought up.

Cheers,
Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

(adding debian-arm/-kernel)
On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote:
> On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > > Now that all the device tree support is in mach-mvebu, remove it from
> > > > mach-kirkwood.
> > > >
> > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > 
> > s/DT/board-file/?
> 
> We keep any system using -setup.c files, and remove the ability to
> boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> and you should now be trying to only use mach-mvebu, compiled for v5
> systems and a second compile for v7 systems.

Just to check I've got it: The majority of the systems previously
supported by mach-kirkwood (either board file or DTB based) are now
supported by mach-mvebu.

Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same
v5 .config? IOW that all of the platforms currently supported by the
Debian kirkwood flavour remain supportable in the same binary after this
change. It looks like it should be to me, but I'm not 100% sure.

If not then Debian will need to introduce a new kernel flavour and
manage the transition somehow, which is going to be tricky if we need to
retain both flavours.

Is there a tree I can pull to see what is going into v3.15 in this area?

> There are four systems left in mach-kirkwood which don't have DT
> equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> point is audio support, which no other board has done with DT yet.
> The two LeCie boards have a custom LED driver which needs a DT
> binding. My gut feeling is that we won't get these four converted to
> DT in time for 3.15.
>  
> > > > of other redundent options have been removed in the process.
> > > >
> > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > > ---
> > > 
> > > Hmm, I wonder what Ian thinks of removing this so quickly again...
> > 
> > I don't want to stand in the way of progress. What version is this
> > targeting so I can setup our tooling to DTRT and append a DTB under the
> > correct circumstances.
> 
> My aim is 3.15. Most patches have been Acked now, so i think we are on
> track for that.

If kirkwood and mvebu are mutually exclusive on v5 then this sounds like
it might end up being more complicated than just setting Append-DTB-From
in the flash-kernel db. In that case if we could hold off on pulling the
existing kirkwood support until there is a transition plan here I'd be
very grateful.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote:
> (adding debian-arm/-kernel)
> On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote:
> > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > > > Now that all the device tree support is in mach-mvebu, remove it from
> > > > > mach-kirkwood.
> > > > >
> > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > > 
> > > s/DT/board-file/?
> > 
> > We keep any system using -setup.c files, and remove the ability to
> > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > and you should now be trying to only use mach-mvebu, compiled for v5
> > systems and a second compile for v7 systems.
> 
> Just to check I've got it: The majority of the systems previously
> supported by mach-kirkwood (either board file or DTB based) are now
> supported by mach-mvebu.

We plan to move all kirkwood systems which are DT to mach-mvebu. Any
systems which are not DT will get left in mach-kirkwood.

What would be interesting to know is, if any of the systems left
behind are supported by debian. So LaCie 2Big and 5Big, HP t5325 thin
client and Marvell OpenRD machines? If you don't support any of these,
you can drop mach-kirkwood.

> Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same
> v5 .config?

Armada XP, 370, and the new SoCs going in this cycle all use ARM v7
CPUs. Dove also uses an ARM v7 cpu and we intent to move it from
mach-dove into mach-mvebu.

Now ARM v7 cpu and ARM v5 CPUs are mutually incompatible. You cannot
combine them into one kernel. Do you currently build mach-mvebu as
part of a multi v7 kernel. That is, you have one kernel which boots on
all v7 machines?

What this patchset does is also make mach-mvebu part of the multi v5
kernel. So you just need one kernel for all ARM v5 machines which are
part of multi v5. The long term goal is that you need just two 32 ARM
kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
yet part of theses, so we are not there yet.

> IOW that all of the platforms currently supported by the
> Debian kirkwood flavour remain supportable in the same binary after this
> change. It looks like it should be to me, but I'm not 100% sure.

If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
Marvell OpenRD then yes, you have one binary. That binary could
potentially support over v5 machines, but i have no idea what ARM
machines Debian actually supports. Is there a list somewhere?
 
> Is there a tree I can pull to see what is going into v3.15 in this
> area?

At the moment there is not a tree with all the different parts.  I
have a tree with these specific patches. There are other trees which
contain new DT descriptions for new devices, like Bubba B3, and
systems which have been converted to DT, like the QNAP T4xx.

> > My aim is 3.15. Most patches have been Acked now, so i think we are on
> > track for that.
> 
> If kirkwood and mvebu are mutually exclusive on v5 then this sounds like
> it might end up being more complicated than just setting Append-DTB-From
> in the flash-kernel db. In that case if we could hold off on pulling the
> existing kirkwood support until there is a transition plan here I'd be
> very grateful.

Lets make sure we are all on the same page with v5, v7, kirkwood,
mvebu, multi, and what kernels Debian currently builds and how
flash-kernel works etc. We can then discuss transition plans.

     Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote:
> On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote:
> > (adding debian-arm/-kernel)
> > On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote:
> > > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> > > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > > > > Now that all the device tree support is in mach-mvebu, remove it from
> > > > > > mach-kirkwood.
> > > > > >
> > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > > > 
> > > > s/DT/board-file/?
> > > 
> > > We keep any system using -setup.c files, and remove the ability to
> > > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > > and you should now be trying to only use mach-mvebu, compiled for v5
> > > systems and a second compile for v7 systems.
> > 
> > Just to check I've got it: The majority of the systems previously
> > supported by mach-kirkwood (either board file or DTB based) are now
> > supported by mach-mvebu.
> 
> We plan to move all kirkwood systems which are DT to mach-mvebu. Any
> systems which are not DT will get left in mach-kirkwood.
> 
> What would be interesting to know is, if any of the systems left
> behind are supported by debian. So LaCie 2Big and 5Big, HP t5325 thin
> client and Marvell OpenRD machines? If you don't support any of these,
> you can drop mach-kirkwood.
> 
> > Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same
> > v5 .config?
> 
> Armada XP, 370, and the new SoCs going in this cycle all use ARM v7
> CPUs. Dove also uses an ARM v7 cpu and we intent to move it from
> mach-dove into mach-mvebu.
> 
> Now ARM v7 cpu and ARM v5 CPUs are mutually incompatible. You cannot
> combine them into one kernel. Do you currently build mach-mvebu as
> part of a multi v7 kernel. That is, you have one kernel which boots on
> all v7 machines?

Debian has a single v7 flavour, armmp which uses the multi platform
stuff. (actually there is a second armmp-lpae, but lets ignore that)

I'm only really concerned about the v5 stuff here. Debian has multiple
v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile.

> What this patchset does is also make mach-mvebu part of the multi v5
> kernel. So you just need one kernel for all ARM v5 machines which are
> part of multi v5. The long term goal is that you need just two 32 ARM
> kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> yet part of theses, so we are not there yet.

So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
coexist in the same binary?

> > IOW that all of the platforms currently supported by the
> > Debian kirkwood flavour remain supportable in the same binary after this
> > change. It looks like it should be to me, but I'm not 100% sure.
> 
> If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
> Marvell OpenRD then yes, you have one binary. That binary could
> potentially support over v5 machines, but i have no idea what ARM
> machines Debian actually supports. Is there a list somewhere?

http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=blob;f=db/all.db;h=fab340782c783c4f8a172f0424a791037dee90cf;hb=HEAD is a reasonable approximation for what is supported, at least in a well integrated way. I can see all of the LaCie systems, t5325 and openrd stuff which you mention in that list.

http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/config/armel/config.kirkwood?revision=20912&view=markup
is the kirkwood specific kernel config s/trunk/wheezy/ if you want to
see the current stable version. Other config.* for other flavours.

I'm only concerned with the impact of these changes on the kirkwood
flavour right now, I don't want to confuse the matter by considering the
possibility of consolidating flavours.

Ian.

>  
> > Is there a tree I can pull to see what is going into v3.15 in this
> > area?
> 
> At the moment there is not a tree with all the different parts.  I
> have a tree with these specific patches. There are other trees which
> contain new DT descriptions for new devices, like Bubba B3, and
> systems which have been converted to DT, like the QNAP T4xx.
> 
> > > My aim is 3.15. Most patches have been Acked now, so i think we are on
> > > track for that.
> > 
> > If kirkwood and mvebu are mutually exclusive on v5 then this sounds like
> > it might end up being more complicated than just setting Append-DTB-From
> > in the flash-kernel db. In that case if we could hold off on pulling the
> > existing kirkwood support until there is a transition plan here I'd be
> > very grateful.
> 
> Lets make sure we are all on the same page with v5, v7, kirkwood,
> mvebu, multi, and what kernels Debian currently builds and how
> flash-kernel works etc. We can then discuss transition plans.
> 
>      Andrew
> 

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

> > What this patchset does is also make mach-mvebu part of the multi v5
> > kernel. So you just need one kernel for all ARM v5 machines which are
> > part of multi v5. The long term goal is that you need just two 32 ARM
> > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> > yet part of theses, so we are not there yet.
> 
> So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
> coexist in the same binary?

Clearly ARCH_MVEBU v7 cannot. What i need to determine is if
ARCH_KIRKWOOD and ARCH_MVEBU v5 will go into one binary. I _think_ the
answer is no, but i need to take a closer look.

What i suspect we will end up doing it dropping the last patch for the
moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
I think that just needs care with arch/arm/boot/dts/Makefile.

Once we have the last four converted over to DT, you can then do a
straight swap, mach-kirkwood for mach-mvebu.

I will get back to you in a couple of days once i have this all
figured out.

	Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
> > > What this patchset does is also make mach-mvebu part of the multi v5
> > > kernel. So you just need one kernel for all ARM v5 machines which are
> > > part of multi v5. The long term goal is that you need just two 32 ARM
> > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> > > yet part of theses, so we are not there yet.
> > 
> > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
> > coexist in the same binary?
> 
> Clearly ARCH_MVEBU v7 cannot.

Yes, sorry, I meant v5 ARCH_KIRKWOOD and v5 ARCH_MVEBU.

>  What i need to determine is if
> ARCH_KIRKWOOD and ARCH_MVEBU v5 will go into one binary. I _think_ the
> answer is no, but i need to take a closer look.

Arnd has said no too.

> What i suspect we will end up doing it dropping the last patch for the
> moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
> I think that just needs care with arch/arm/boot/dts/Makefile.
> 
> Once we have the last four converted over to DT, you can then do a
> straight swap, mach-kirkwood for mach-mvebu.

That sounds like a good plan, thanks!

If we are going to do a straight swap I suppose it might as go for a v5
multiplatform flavour instead of a mvebu specific one.

> I will get back to you in a couple of days once i have this all
> figured out.

Thank you.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ben Hutchings]

On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote:
> On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
[...]
> > What i suspect we will end up doing it dropping the last patch for the
> > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
> > I think that just needs care with arch/arm/boot/dts/Makefile.
> > 
> > Once we have the last four converted over to DT, you can then do a
> > straight swap, mach-kirkwood for mach-mvebu.
> 
> That sounds like a good plan, thanks!
> 
> If we are going to do a straight swap I suppose it might as go for a v5
> multiplatform flavour instead of a mvebu specific one.
[...]

I would love it if we could do that.

By the way, we still have the problem that at least one supported
orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition.
So we would probably have to keep a reduced orion5x config for those
machines, alongside the mvebu or multiplatform kernel.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai Stevenson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140221/1faf904c/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Friday 21 February 2014 02:00:27 Ben Hutchings wrote:
> On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote:
> > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
> [...]
> > > What i suspect we will end up doing it dropping the last patch for the
> > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
> > > I think that just needs care with arch/arm/boot/dts/Makefile.
> > > 
> > > Once we have the last four converted over to DT, you can then do a
> > > straight swap, mach-kirkwood for mach-mvebu.
> > 
> > That sounds like a good plan, thanks!
> > 
> > If we are going to do a straight swap I suppose it might as go for a v5
> > multiplatform flavour instead of a mvebu specific one.
> [...]
> 
> I would love it if we could do that.
> 
> By the way, we still have the problem that at least one supported
> orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition.
> So we would probably have to keep a reduced orion5x config for those
> machines, alongside the mvebu or multiplatform kernel.

orion5x is still some time away from being included in mvebu, 3.16 at
the earliest, so it will have to stay separate anyway.

My hope is really that we get very little overhead in enabling
multiplatform on mvebu compared to a orion5x or kirkwood standalone
configuration, so depending on what the platforms have you could
end up with e.g. a 1.5MB "mini" multiplatform kernel that includes
all machines that have 2MB or less for their kernel partitions and
a "everything included" multiplatform kernel for the machines with
larger partititons. For instance kirkwood-rd88f6281 has a 2MB
uImage partition and everything else seems to have at least 4MB.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Fri, 2014-02-21 at 02:00 +0000, Ben Hutchings wrote:
> On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote:
> > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
> [...]
> > > What i suspect we will end up doing it dropping the last patch for the
> > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
> > > I think that just needs care with arch/arm/boot/dts/Makefile.
> > > 
> > > Once we have the last four converted over to DT, you can then do a
> > > straight swap, mach-kirkwood for mach-mvebu.
> > 
> > That sounds like a good plan, thanks!
> > 
> > If we are going to do a straight swap I suppose it might as go for a v5
> > multiplatform flavour instead of a mvebu specific one.
> [...]
> 
> I would love it if we could do that.
> 
> By the way, we still have the problem that at least one supported
> orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition.
> So we would probably have to keep a reduced orion5x config for those
> machines, alongside the mvebu or multiplatform kernel.

Sure. I think at worst we should aim to end up with as many flavour as
we have today, in reality I expect we should be able to end up with
fewer (even if only -= 1).

BTW, someone (I forget who) at Debconf in Cambridge last year floated
the idea of putting a stage 2 loader in flash to pull the real kernel
from some larger storage. I don't know if that is realistic here, and in
any case I don't intend to work on it myself.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ben Hutchings]

On Mon, 2014-02-24 at 16:03 +0000, Ian Campbell wrote:
> On Fri, 2014-02-21 at 02:00 +0000, Ben Hutchings wrote:
> > On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote:
> > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
> > [...]
> > > > What i suspect we will end up doing it dropping the last patch for the
> > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
> > > > I think that just needs care with arch/arm/boot/dts/Makefile.
> > > > 
> > > > Once we have the last four converted over to DT, you can then do a
> > > > straight swap, mach-kirkwood for mach-mvebu.
> > > 
> > > That sounds like a good plan, thanks!
> > > 
> > > If we are going to do a straight swap I suppose it might as go for a v5
> > > multiplatform flavour instead of a mvebu specific one.
> > [...]
> > 
> > I would love it if we could do that.
> > 
> > By the way, we still have the problem that at least one supported
> > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition.
> > So we would probably have to keep a reduced orion5x config for those
> > machines, alongside the mvebu or multiplatform kernel.
> 
> Sure. I think at worst we should aim to end up with as many flavour as
> we have today, in reality I expect we should be able to end up with
> fewer (even if only -= 1).
> 
> BTW, someone (I forget who) at Debconf in Cambridge last year floated
> the idea of putting a stage 2 loader in flash to pull the real kernel
> from some larger storage. I don't know if that is realistic here, and in
> any case I don't intend to work on it myself.

I do remember that, and I like it.  But in order to rely on this, I
think we would need to provide a mostly automatic and safe upgrade path
in Debian.  Unless someone is prepared to spend the (possibly
substantial) effort to do that, we're stuck with that limitation.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140224/cad41ce6/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
> On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote:
> > On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote:
> Debian has a single v7 flavour, armmp which uses the multi platform
> stuff. (actually there is a second armmp-lpae, but lets ignore that)
> 
> I'm only really concerned about the v5 stuff here. Debian has multiple
> v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile.

Unfortunately, this selection include multiple platforms that
we don't plan to (ever) support in a multiplatform kernel, while
a lot of platforms you don't currently support are already enabled
or will be at some point.

* ixp4xx is too different from the others and I don't think it's
  possible to turn it over to multiplatform.
* I see a iop32x_defconfig in svn that you didn't mention here,
  but it's basically the same problem as ixp4xx.
* kirkwood/mv78xx0/orion5x are essentially one platform and work
  in progress.
* versatile is easy to do as multiplatform, I just haven't gotten
  around to do it.

ARMv5 platforms that are already working with ARCH_MULTIPLATFORM:
* freescale mxc (i.mx21 and i.mx25)
* freescale mxs (i.mx23 and i.mx28)
* st-ericsson Nomadik
* st-ericsson u300
* st spear3xx
* st spear6xx
* TI NSpire
* VIA/Wondermedia vt85xx/wm85xx/wm86xx

The embedded mxs family is probably most interesting among these,
but there is also a community around the wondermedia stuff, which is
used in cheap tablets and laptops.

> > What this patchset does is also make mach-mvebu part of the multi v5
> > kernel. So you just need one kernel for all ARM v5 machines which are
> > part of multi v5. The long term goal is that you need just two 32 ARM
> > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> > yet part of theses, so we are not there yet.
> 
> So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
> coexist in the same binary?

That has been the plan for the kirkwood migration for the last few
years, yes. The idea is that every kirkwood machine that anyone is
interested in should be supported by ARCH_MVEBU, and we can keep
ARCH_KIRKWOOD for the ones we don't care about until it is just
dropped.

Same for orion5x, dove and mv78xx0, just a different schedule
for moving them over.

Now in theory, we could have them supported in a multiplatform kernel,
but that would mean extra work that we planned to avoid by converting
them to DT first.

As I said, it may be useful to do multiplatform support for MACH_ORION5x,
but for MACH_KIRKWOOD, we have come too far now to turn back.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote:
> On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
> > On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote:
> > > On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote:
> > Debian has a single v7 flavour, armmp which uses the multi platform
> > stuff. (actually there is a second armmp-lpae, but lets ignore that)
> > 
> > I'm only really concerned about the v5 stuff here. Debian has multiple
> > v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile.
> 
> Unfortunately, this selection include multiple platforms that
> we don't plan to (ever) support in a multiplatform kernel, while
> a lot of platforms you don't currently support are already enabled
> or will be at some point.

That's ok, Debian is happy to stick with separate flavours for v5 if
necessary for the existing ones, although I think we'd prefer to avoid
adding any new ones.

(for v7 we have gone multiplatform only already)

> * ixp4xx is too different from the others and I don't think it's
>   possible to turn it over to multiplatform.
> * I see a iop32x_defconfig in svn that you didn't mention here,
>   but it's basically the same problem as ixp4xx.

This is only in Wheezy and not in trunk (which will become Jessie). AIUI
support for these has been dropped for the next version of Debian so
Wheezy is the last one and we don't need to worry about upgrade for
these.

TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll
see.

> * kirkwood/mv78xx0/orion5x are essentially one platform and work
>   in progress.
> * versatile is easy to do as multiplatform, I just haven't gotten
>   around to do it.
> 
> ARMv5 platforms that are already working with ARCH_MULTIPLATFORM:
> * freescale mxc (i.mx21 and i.mx25)
> * freescale mxs (i.mx23 and i.mx28)
> * st-ericsson Nomadik
> * st-ericsson u300
> * st spear3xx
> * st spear6xx
> * TI NSpire
> * VIA/Wondermedia vt85xx/wm85xx/wm86xx
> 
> The embedded mxs family is probably most interesting among these,
> but there is also a community around the wondermedia stuff, which is
> used in cheap tablets and laptops.

Interesting. I don't know how many of these are supported by Debian --
mostly these things get added when someone acquires one and scratches
that itch.

I suppose if we could remove at least one existing flavour in favour of
a v5 multiplatform config then there probably wouldn't be many
objections to doing that.

> > > What this patchset does is also make mach-mvebu part of the multi v5
> > > kernel. So you just need one kernel for all ARM v5 machines which are
> > > part of multi v5. The long term goal is that you need just two 32 ARM
> > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> > > yet part of theses, so we are not there yet.
> > 
> > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
> > coexist in the same binary?
> 
> That has been the plan for the kirkwood migration for the last few
> years, yes. The idea is that every kirkwood machine that anyone is
> interested in should be supported by ARCH_MVEBU, and we can keep
> ARCH_KIRKWOOD for the ones we don't care about until it is just
> dropped.
> 
> Same for orion5x, dove and mv78xx0, just a different schedule
> for moving them over.
> 
> Now in theory, we could have them supported in a multiplatform kernel,
> but that would mean extra work that we planned to avoid by converting
> them to DT first.
> 
> As I said, it may be useful to do multiplatform support for MACH_ORION5x,
> but for MACH_KIRKWOOD, we have come too far now to turn back.

Understood. It sounds like mach-kirkwood is very close to being
removable altogether though (by migrating the last few boards to
mach-mvebu), which would make distro upgrades much simpler, since we can
just do a straight swap rather than trying to figure out which one we
need.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
> On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote:
> > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
> > * ixp4xx is too different from the others and I don't think it's
> >   possible to turn it over to multiplatform.
> > * I see a iop32x_defconfig in svn that you didn't mention here,
> >   but it's basically the same problem as ixp4xx.
> 
> This is only in Wheezy and not in trunk (which will become Jessie). AIUI
> support for these has been dropped for the next version of Debian so
> Wheezy is the last one and we don't need to worry about upgrade for
> these.

Ok, I see.

> TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll
> see.

For all I know, the only interesting ixp4xx platforms are the consumer
products listed on http://www.nslu2-linux.org/, the other ones you support
are development boards that tend to exist only in very small quantities.

The main limitation would be the amount of installed RAM, which is
either 32MB or 64MB depending on the machine for these. Running a
modern Debian with these constraints is probably possible but
doesn't sound like fun. ;-)

Also, the upstream kernel port isn't that well maintained, a lot
the development seems to have happened in OpenWRT and not mainlined,
including a dozen new machines that were already ported in 2009.

Then again, Martin Michlmayr has instructions for running Wheezy
on the 32MB nslu2, and I guess as long as he's interested in the
hardware, new versions of Debian will keep running on it.

> > The embedded mxs family is probably most interesting among these,
> > but there is also a community around the wondermedia stuff, which is
> > used in cheap tablets and laptops.
> 
> Interesting. I don't know how many of these are supported by Debian --
> mostly these things get added when someone acquires one and scratches
> that itch.
> 
> I suppose if we could remove at least one existing flavour in favour of
> a v5 multiplatform config then there probably wouldn't be many
> objections to doing that.

That will probably come as a natural progression after kirkwood
gets replaced with mvebu.

> > As I said, it may be useful to do multiplatform support for MACH_ORION5x,
> > but for MACH_KIRKWOOD, we have come too far now to turn back.
> 
> Understood. It sounds like mach-kirkwood is very close to being
> removable altogether though (by migrating the last few boards to
> mach-mvebu), which would make distro upgrades much simpler, since we can
> just do a straight swap rather than trying to figure out which one we
> need.

Yes, makes sense.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ben Hutchings]

On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
> On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
> > On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote:
> > > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
> > > * ixp4xx is too different from the others and I don't think it's
> > >   possible to turn it over to multiplatform.
> > > * I see a iop32x_defconfig in svn that you didn't mention here,
> > >   but it's basically the same problem as ixp4xx.
> > 
> > This is only in Wheezy and not in trunk (which will become Jessie). AIUI
> > support for these has been dropped for the next version of Debian so
> > Wheezy is the last one and we don't need to worry about upgrade for
> > these.
> 
> Ok, I see.
>
> > TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll
> > see.
> 
> For all I know, the only interesting ixp4xx platforms are the consumer
> products listed on http://www.nslu2-linux.org/, the other ones you support
> are development boards that tend to exist only in very small quantities.
> 
> The main limitation would be the amount of installed RAM, which is
> either 32MB or 64MB depending on the machine for these. Running a
> modern Debian with these constraints is probably possible but
> doesn't sound like fun. ;-)

Our most pressing constraint has actually been the size of the kernel
partition in flash, which is only ~1.4 MB on some of the iop32x and
ixp4xx machines (and ~1.5 MB on one of the orion5x machines).  We've
modularised as much as possible and turned off some of the features that
are otherwise standard across all Debian architectures.

But I got fed up with trying to make it fit, and no-one else stepped up
to maintain the reduced configurations, so the last time iop32x went
over the limit I removed it.  As Ian hinted, ixp4xx might follow.

> Also, the upstream kernel port isn't that well maintained, a lot
> the development seems to have happened in OpenWRT and not mainlined,
> including a dozen new machines that were already ported in 2009.
> 
> Then again, Martin Michlmayr has instructions for running Wheezy
> on the 32MB nslu2, and I guess as long as he's interested in the
> hardware, new versions of Debian will keep running on it.
[...]

Martin is not currently active in Debian kernel maintenance.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai Stevenson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140221/27dba2db/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Friday 21 February 2014 01:47:31 Ben Hutchings wrote:
> On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
> > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
>
> > For all I know, the only interesting ixp4xx platforms are the consumer
> > products listed on http://www.nslu2-linux.org/, the other ones you support
> > are development boards that tend to exist only in very small quantities.
> > 
> > The main limitation would be the amount of installed RAM, which is
> > either 32MB or 64MB depending on the machine for these. Running a
> > modern Debian with these constraints is probably possible but
> > doesn't sound like fun. 
> 
> Our most pressing constraint has actually been the size of the kernel
> partition in flash, which is only ~1.4 MB on some of the iop32x and
> ixp4xx machines (and ~1.5 MB on one of the orion5x machines).  We've
> modularised as much as possible and turned off some of the features that
> are otherwise standard across all Debian architectures.

Makes sense. I'm impressed you actually manage to get a modern kernel
in 1.5MB and have it boot up a (mostly) full distro. I think we have
in the past dropped a subarchitecture from the kernel when it turned
out its defconfig could no longer fit within the 2MB of flash it
has.

> But I got fed up with trying to make it fit, and no-one else stepped up
> to maintain the reduced configurations, so the last time iop32x went
> over the limit I removed it.  As Ian hinted, ixp4xx might follow.

Ok. As I mentioned, I believe OpenWRT is really the playground for
the remaining ixp4xx users that are doing new installs.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Fri, Feb 21, 2014 at 02:07:40PM +0100, Arnd Bergmann wrote:
> On Friday 21 February 2014 01:47:31 Ben Hutchings wrote:
> > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
> > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
> >
> > > For all I know, the only interesting ixp4xx platforms are the consumer
> > > products listed on http://www.nslu2-linux.org/, the other ones you support
> > > are development boards that tend to exist only in very small quantities.
> > > 
> > > The main limitation would be the amount of installed RAM, which is
> > > either 32MB or 64MB depending on the machine for these. Running a
> > > modern Debian with these constraints is probably possible but
> > > doesn't sound like fun. 
> > 
> > Our most pressing constraint has actually been the size of the kernel
> > partition in flash, which is only ~1.4 MB on some of the iop32x and
> > ixp4xx machines (and ~1.5 MB on one of the orion5x machines).  We've
> > modularised as much as possible and turned off some of the features that
> > are otherwise standard across all Debian architectures.
> 
> Makes sense. I'm impressed you actually manage to get a modern kernel
> in 1.5MB and have it boot up a (mostly) full distro. I think we have
> in the past dropped a subarchitecture from the kernel when it turned
> out its defconfig could no longer fit within the 2MB of flash it
> has.
> 
> > But I got fed up with trying to make it fit, and no-one else stepped up
> > to maintain the reduced configurations, so the last time iop32x went
> > over the limit I removed it.  As Ian hinted, ixp4xx might follow.
> 
> Ok. As I mentioned, I believe OpenWRT is really the playground for
> the remaining ixp4xx users that are doing new installs.

fwiw, I have two boards for this arch.  NSLU2 and a Gateworks board.
Both are ixp425 and both are gathering dust in a box.  I probably don't
have time to do anything with them.  So, if Kevin or Olof wants to add
them to the boot farm, or someone actually wants to boot test them, I
would be willing to send them where ever.

iirc, there are hacks to upgrade at least the RAM on the NSLU2.  I'm
pretty sure I maxed out the flash and the RAM on the Gateworks board
when I ordered it.  Also, the Gateworks board has 4 mini-pci slots (not
pcie).  Could be interesting.

hth,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ben Hutchings]

On Fri, 2014-02-21 at 14:07 +0100, Arnd Bergmann wrote:
> On Friday 21 February 2014 01:47:31 Ben Hutchings wrote:
> > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
> > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
> >
> > > For all I know, the only interesting ixp4xx platforms are the consumer
> > > products listed on http://www.nslu2-linux.org/, the other ones you support
> > > are development boards that tend to exist only in very small quantities.
> > > 
> > > The main limitation would be the amount of installed RAM, which is
> > > either 32MB or 64MB depending on the machine for these. Running a
> > > modern Debian with these constraints is probably possible but
> > > doesn't sound like fun. 
> > 
> > Our most pressing constraint has actually been the size of the kernel
> > partition in flash, which is only ~1.4 MB on some of the iop32x and
> > ixp4xx machines (and ~1.5 MB on one of the orion5x machines).  We've
> > modularised as much as possible and turned off some of the features that
> > are otherwise standard across all Debian architectures.
> 
> Makes sense. I'm impressed you actually manage to get a modern kernel
> in 1.5MB and have it boot up a (mostly) full distro. I think we have
> in the past dropped a subarchitecture from the kernel when it turned
> out its defconfig could no longer fit within the 2MB of flash it
> has.
[...]

These are the changes we make for orion5x:

# CONFIG_KPROBES is not set
# CONFIG_CRYPTO_FIPS is not set
# CONFIG_VGA_ARB is not set
# CONFIG_AUDITSYSCALL is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
#. Saves about 17K, and none of the quirks are likely to be needed
# CONFIG_PCI_QUIRKS is not set
# CONFIG_FTRACE is not set
# CONFIG_KSM is not set
CONFIG_IPV6=m
# CONFIG_NET_MPLS_GSO is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_RD_LZ4 is not set

For ixp4xx we have these as well:

#. Saves about 5K
# CONFIG_USER_NS is not set
#. Saves about 7K
# CONFIG_MEMCG is not set
#. Saves about 3K
# CONFIG_BPF_JIT is not set

(I think the built-in drivers for ixp4xx are smaller as well.)

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai Stevenson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140221/a367beee/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote:
> 
> What this patchset does is also make mach-mvebu part of the multi v5
> kernel. So you just need one kernel for all ARM v5 machines which are
> part of multi v5. The long term goal is that you need just two 32 ARM
> kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
> yet part of theses, so we are not there yet.

BTW, if converting enough of orion5x to DT takes too long to
deprecate that platform any time soon, I'd prefer moving it
over to multiplatform while keeping the legacy board files
in there. That should get substantially easier once
mv78xx0, kirkwood and dove have been dealt with and we can
collapse plat-orion and mach-orion5x into one directory.

> > IOW that all of the platforms currently supported by the
> > Debian kirkwood flavour remain supportable in the same binary after this
> > change. It looks like it should be to me, but I'm not 100% sure.
> 
> If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
> Marvell OpenRD then yes, you have one binary. That binary could
> potentially support over v5 machines, but i have no idea what ARM
> machines Debian actually supports. Is there a list somewhere?

http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup

just lists all kirkwood machines as enabled, but that of course
doesn't meant they are actually working or supported.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Ian Campbell]

On Thu, 2014-02-20 at 14:04 +0100, Arnd Bergmann wrote:
> On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote:
> > > IOW that all of the platforms currently supported by the
> > > Debian kirkwood flavour remain supportable in the same binary after this
> > > change. It looks like it should be to me, but I'm not 100% sure.
> > 
> > If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
> > Marvell OpenRD then yes, you have one binary. That binary could
> > potentially support over v5 machines, but i have no idea what ARM
> > machines Debian actually supports. Is there a list somewhere?
> 
> http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup
> 
> just lists all kirkwood machines as enabled, but that of course
> doesn't meant they are actually working or supported.

In general boards get added there by someone who is running Debian on
that platform. We don't really have any way to tell what platforms
people are actually using.

Ian.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 11:58:54 Andrew Lunn wrote:
> 
> > I still need to figure out how to distinguish the variations, but I
> > think I have a plan there (via which PCI buses are present, which is a
> > bit skanky but seems like the most workable solution).
> 
> Having the SoC ID available via lspci for systems using the new PCI
> driver might be in 3.14. It was considered a regression so might get
> merged into an rc. If not, it will be in 3.15.
> 
> We have also talked about putting the SOC version and revision into
> /proc/cpuinfo, in the Revision field. However this has not happened
> yet.

Another option would be to use the soc bus to provide that information
in /sys/devices/soc, and put the rest of the devices under that
node.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Thu, Feb 20, 2014 at 11:58:54AM +0100, Andrew Lunn wrote:
> On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote:
> > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
> > > On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> > > > Now that all the device tree support is in mach-mvebu, remove it from
> > > > mach-kirkwood.
> > > >
> > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple
> > 
> > s/DT/board-file/?
> 
> We keep any system using -setup.c files, and remove the ability to
> boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> and you should now be trying to only use mach-mvebu, compiled for v5
> systems and a second compile for v7 systems.
> 
> There are four systems left in mach-kirkwood which don't have DT
> equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> point is audio support, which no other board has done with DT yet.
> The two LeCie boards have a custom LED driver which needs a DT
> binding. My gut feeling is that we won't get these four converted to
> DT in time for 3.15.

Why not do like we did when we started the kirkwood dt conversion?
Create dts files for the remaining boards, and do

if (of_machine_is_compatible(...))
	legacy_audio_init()

in board-v5.c?

I suspect audio is going to take time to sort out.  I'd hate to delay
this just for that.

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Thomas Petazzoni]

Dear Jason Cooper,

On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote:

> > We keep any system using -setup.c files, and remove the ability to
> > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > and you should now be trying to only use mach-mvebu, compiled for v5
> > systems and a second compile for v7 systems.
> > 
> > There are four systems left in mach-kirkwood which don't have DT
> > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> > point is audio support, which no other board has done with DT yet.
> > The two LeCie boards have a custom LED driver which needs a DT
> > binding. My gut feeling is that we won't get these four converted to
> > DT in time for 3.15.
> 
> Why not do like we did when we started the kirkwood dt conversion?
> Create dts files for the remaining boards, and do
> 
> if (of_machine_is_compatible(...))
> 	legacy_audio_init()
> 
> in board-v5.c?
> 
> I suspect audio is going to take time to sort out.  I'd hate to delay
> this just for that.

Yes, I believe it's a good plan. Convert as much as possible to DT, and
only keep those few devices (audio and leds) probe in an old-style
fashion.

This way, we can progressively add the necessary missing DT bindings.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote:
> On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote:
> 
> > > We keep any system using -setup.c files, and remove the ability to
> > > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > > and you should now be trying to only use mach-mvebu, compiled for v5
> > > systems and a second compile for v7 systems.
> > > 
> > > There are four systems left in mach-kirkwood which don't have DT
> > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> > > point is audio support, which no other board has done with DT yet.
> > > The two LeCie boards have a custom LED driver which needs a DT
> > > binding. My gut feeling is that we won't get these four converted to
> > > DT in time for 3.15.
> > 
> > Why not do like we did when we started the kirkwood dt conversion?
> > Create dts files for the remaining boards, and do
> > 
> > if (of_machine_is_compatible(...))
> >       legacy_audio_init()
> > 
> > in board-v5.c?
> > 
> > I suspect audio is going to take time to sort out.  I'd hate to delay
> > this just for that.
> 
> Yes, I believe it's a good plan. Convert as much as possible to DT, and
> only keep those few devices (audio and leds) probe in an old-style
> fashion.
> 
> This way, we can progressively add the necessary missing DT bindings.

Makes sense.

I'm also adding Simon Guinot to Cc here. He contributed both the kernel
support and the Debian support for the LaCie 2Big/5Big. He might also be
able to verify that they work after the DT conversion, or even help
implementing it. Since there is already someone who is looking into
t5325, that would just leave the OpenRD reference design, right?

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

> I'm also adding Simon Guinot to Cc here. He contributed both the kernel
> support and the Debian support for the LaCie 2Big/5Big. He might also be
> able to verify that they work after the DT conversion, or even help
> implementing it. Since there is already someone who is looking into
> t5325, that would just leave the OpenRD reference design, right?

I'm onto both t5325 and OpenRD.

Thomas provided me with a basic t5325 DTS file from around kernel
version v3.5 which i have brought up to date. I'm now trying to get my
head around ASOC and simple-card, i.e. do it properly using DT.

OpenRD i'm at the same stage, just audio left, although i suspect i
will get some interesting comments for how i handled command line
parsing and enabling devices. I have a volunteer testing it, but
feedback is slow.

	 Andrew

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Jason Cooper]

On Fri, Feb 21, 2014 at 05:36:47PM +0100, Arnd Bergmann wrote:
> On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote:
> > On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote:
> > 
> > > > We keep any system using -setup.c files, and remove the ability to
> > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > > > and you should now be trying to only use mach-mvebu, compiled for v5
> > > > systems and a second compile for v7 systems.
> > > > 
> > > > There are four systems left in mach-kirkwood which don't have DT
> > > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> > > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> > > > point is audio support, which no other board has done with DT yet.
> > > > The two LeCie boards have a custom LED driver which needs a DT
> > > > binding. My gut feeling is that we won't get these four converted to
> > > > DT in time for 3.15.
> > > 
> > > Why not do like we did when we started the kirkwood dt conversion?
> > > Create dts files for the remaining boards, and do
> > > 
> > > if (of_machine_is_compatible(...))
> > >       legacy_audio_init()
> > > 
> > > in board-v5.c?
> > > 
> > > I suspect audio is going to take time to sort out.  I'd hate to delay
> > > this just for that.
> > 
> > Yes, I believe it's a good plan. Convert as much as possible to DT, and
> > only keep those few devices (audio and leds) probe in an old-style
> > fashion.
> > 
> > This way, we can progressively add the necessary missing DT bindings.
> 
> Makes sense.
> 
> I'm also adding Simon Guinot to Cc here. He contributed both the kernel
> support and the Debian support for the LaCie 2Big/5Big. He might also be
> able to verify that they work after the DT conversion, or even help
> implementing it. Since there is already someone who is looking into
> t5325, that would just leave the OpenRD reference design, right?

Yes.  Although we are running short on time.  I'd prefer not to rush
Dashie, as he's brand new to the community.  Also, Andrew has a Makefile
solution he's working on to keep life manageable for debian for v3.15.
We can take it out after the boards are converted with the above
solution.  It might even be fixes-non-critical for v3.16.

thx,

Jason.

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Simon Guinot]

On Fri, Feb 21, 2014 at 05:36:47PM +0100, Arnd Bergmann wrote:
> On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote:
> > On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote:
> > 
> > > > We keep any system using -setup.c files, and remove the ability to
> > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy,
> > > > and you should now be trying to only use mach-mvebu, compiled for v5
> > > > systems and a second compile for v7 systems.
> > > > 
> > > > There are four systems left in mach-kirkwood which don't have DT
> > > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and
> > > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking
> > > > point is audio support, which no other board has done with DT yet.
> > > > The two LeCie boards have a custom LED driver which needs a DT
> > > > binding. My gut feeling is that we won't get these four converted to
> > > > DT in time for 3.15.
> > > 
> > > Why not do like we did when we started the kirkwood dt conversion?
> > > Create dts files for the remaining boards, and do
> > > 
> > > if (of_machine_is_compatible(...))
> > >       legacy_audio_init()
> > > 
> > > in board-v5.c?
> > > 
> > > I suspect audio is going to take time to sort out.  I'd hate to delay
> > > this just for that.
> > 
> > Yes, I believe it's a good plan. Convert as much as possible to DT, and
> > only keep those few devices (audio and leds) probe in an old-style
> > fashion.
> > 
> > This way, we can progressively add the necessary missing DT bindings.
> 
> Makes sense.
> 
> I'm also adding Simon Guinot to Cc here. He contributed both the kernel
> support and the Debian support for the LaCie 2Big/5Big. He might also be
> able to verify that they work after the DT conversion, or even help
> implementing it. Since there is already someone who is looking into
> t5325, that would just leave the OpenRD reference design, right?

Hi Arnd,

I am quite busy this days but as soon I get some free time I will take
care of the DT conversion for the Lacie boards.

Basically, we need to fix some minor issues with the Thomas patches:

ARM: kirkwood: convert d2net_v2 to DT
ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT

And also a DT binding must be added to the LED driver leds-netxbig.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140223/839b53b7/attachment-0001.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Sunday 23 February 2014, Simon Guinot wrote:
> I am quite busy this days but as soon I get some free time I will take
> care of the DT conversion for the Lacie boards.
> 
> Basically, we need to fix some minor issues with the Thomas patches:
> 
> ARM: kirkwood: convert d2net_v2 to DT
> ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT
> 
> And also a DT binding must be added to the LED driver leds-netxbig.

I just took a brief look at the LED driver. I think it would be
reasonable to move almost all of the platform_data into the driver
itself and associate the two versions with distinct "compatible"
strings. That works in this particular case because while the driver
is generic enough to handle other cases, I also wouldn't expect
it to ever get used again on another platform.

The main change to the driver would be to add support for a binding
that gets the seven gpio numbers out of the DT then.

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Simon Guinot]

On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote:
> On Sunday 23 February 2014, Simon Guinot wrote:
> > I am quite busy this days but as soon I get some free time I will take
> > care of the DT conversion for the Lacie boards.
> > 
> > Basically, we need to fix some minor issues with the Thomas patches:
> > 
> > ARM: kirkwood: convert d2net_v2 to DT
> > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT
> > 
> > And also a DT binding must be added to the LED driver leds-netxbig.
> 
> I just took a brief look at the LED driver. I think it would be
> reasonable to move almost all of the platform_data into the driver
> itself and associate the two versions with distinct "compatible"
> strings. That works in this particular case because while the driver
> is generic enough to handle other cases, I also wouldn't expect
> it to ever get used again on another platform.

Actually, this driver is also used by the Atom-based LaCie NASes.
Mainline support for this platforms should be provided soon.

> 
> The main change to the driver would be to add support for a binding
> that gets the seven gpio numbers out of the DT then.

Unfortunately not, we have to pass the whole thing through DT.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140225/f3fc48f7/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Tuesday 25 February 2014, Simon Guinot wrote:
> On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote:
> > On Sunday 23 February 2014, Simon Guinot wrote:
> > > I am quite busy this days but as soon I get some free time I will take
> > > care of the DT conversion for the Lacie boards.
> > > 
> > > Basically, we need to fix some minor issues with the Thomas patches:
> > > 
> > > ARM: kirkwood: convert d2net_v2 to DT
> > > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT
> > > 
> > > And also a DT binding must be added to the LED driver leds-netxbig.
> > 
> > I just took a brief look at the LED driver. I think it would be
> > reasonable to move almost all of the platform_data into the driver
> > itself and associate the two versions with distinct "compatible"
> > strings. That works in this particular case because while the driver
> > is generic enough to handle other cases, I also wouldn't expect
> > it to ever get used again on another platform.
> 
> Actually, this driver is also used by the Atom-based LaCie NASes.
> Mainline support for this platforms should be provided soon.

Do you use DT for those machines as well, or how do you get the
data into the driver there?

> > The main change to the driver would be to add support for a binding
> > that gets the seven gpio numbers out of the DT then.
> 
> Unfortunately not, we have to pass the whole thing through DT.

Ok :(

	Arnd

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Simon Guinot]

On Tue, Feb 25, 2014 at 04:36:14PM +0100, Arnd Bergmann wrote:
> On Tuesday 25 February 2014, Simon Guinot wrote:
> > On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote:
> > > On Sunday 23 February 2014, Simon Guinot wrote:
> > > > I am quite busy this days but as soon I get some free time I will take
> > > > care of the DT conversion for the Lacie boards.
> > > > 
> > > > Basically, we need to fix some minor issues with the Thomas patches:
> > > > 
> > > > ARM: kirkwood: convert d2net_v2 to DT
> > > > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT
> > > > 
> > > > And also a DT binding must be added to the LED driver leds-netxbig.
> > > 
> > > I just took a brief look at the LED driver. I think it would be
> > > reasonable to move almost all of the platform_data into the driver
> > > itself and associate the two versions with distinct "compatible"
> > > strings. That works in this particular case because while the driver
> > > is generic enough to handle other cases, I also wouldn't expect
> > > it to ever get used again on another platform.
> > 
> > Actually, this driver is also used by the Atom-based LaCie NASes.
> > Mainline support for this platforms should be provided soon.
> 
> Do you use DT for those machines as well, or how do you get the
> data into the driver there?

We are using the old fashion platform_device mechanism. The resources
are defined in some board-setup files stored in the arch/x86/platform
repository.

> 
> > > The main change to the driver would be to add support for a binding
> > > that gets the seven gpio numbers out of the DT then.
> > 
> > Unfortunately not, we have to pass the whole thing through DT.
> 
> Ok :(

Yes, it is pain in the ass :(

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140225/12c47ef2/attachment.sig>

[PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Tuesday 25 February 2014 16:09:44 Simon Guinot wrote:
> On Tue, Feb 25, 2014 at 04:36:14PM +0100, Arnd Bergmann wrote:
> > On Tuesday 25 February 2014, Simon Guinot wrote:
> > > On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote:
> > > > I just took a brief look at the LED driver. I think it would be
> > > > reasonable to move almost all of the platform_data into the driver
> > > > itself and associate the two versions with distinct "compatible"
> > > > strings. That works in this particular case because while the driver
> > > > is generic enough to handle other cases, I also wouldn't expect
> > > > it to ever get used again on another platform.
> > > 
> > > Actually, this driver is also used by the Atom-based LaCie NASes.
> > > Mainline support for this platforms should be provided soon.
> > 
> > Do you use DT for those machines as well, or how do you get the
> > data into the driver there?
> 
> We are using the old fashion platform_device mechanism. The resources
> are defined in some board-setup files stored in the arch/x86/platform
> repository.

Then better be quick, before the x86 maintainers figure out what kind
of mess they are getting into, if they want to support lots of embedded
machines in the future. ;-)

	Arnd

[PATCH 00/21] Move DT kirkwood into mach-mvebu

[Jason Cooper]

On Fri, Feb 07, 2014 at 12:41:56AM +0100, Andrew Lunn wrote:
> The process of making most kirkwood boards boot using DT is nearly
> complete. We can now move these boards into mach-mvebu, freeing them
> of the legacy code needed for none-DT systems. At the same time, they
> can become part of ARCH_MULTI_V5.
> 
> Andrew Lunn (21):
>   ARM: Kirkwood: Give pm.c its own header file.
>   IRQ: Orion: Fix getting generic chip pointer.
>   ARM: Kirkwood: Convert mv88f6281gtw_ge switch setup to DT
>   ARM: Kirkwood: Drop printing the SoC type and revision
>   ARM: Kirkwood: Seperate board-dt from common and pcie code.
>   ARM: Kirkwood: ioremap the cpu_config register before using it.
>   ARM: Kirkwood: ioremap memory control register
>   ARM: MVEBU: Add ARCH_MULTI_V7 to SoCs
>   ARM: Orion: Move cache-feroceon-l2.h out of plat-orion
>   ARM: MM: Add DT binding for Feroceon L2 cache
>   ARM: Fix default CPU selection for ARCH_MULTI_V5
>   ARM: Fix MULTI_TLB for feroceon
>   ARM: MM Enable building Feroceon L2 cache controller with ARCH_MVEBU
>   ARM: Move kirkwood DT boards into mach-mvebu
>   ARM: MVEBU: Let kirkwood use the system controller for restart
>   drivers: Enable building of Kirkwood drivers for mach-mvebu
>   ARM: MVEBU: Enable mvebu-soc-id on Kirkwood
>   ARM: config: Add a multi_v5_defconfig
>   ARM: MVEBU: Simplifiy headers and make local
>   ARM: MVEBU: Remove unneeded headers
>   ARM: Kirkwood: Remove DT support
> 
>  .../devicetree/bindings/arm/mrvl/forocean.txt      |  19 +++

nit.  s/forocean/feroceon/

thx,

Jason.

>  arch/arm/Kconfig                                   |   2 +-
>  arch/arm/boot/dts/Makefile                         |  34 ++--
>  arch/arm/boot/dts/kirkwood.dtsi                    |  10 ++
>  arch/arm/configs/kirkwood_defconfig                |   6 -
>  arch/arm/configs/multi_v5_defconfig                | 183 ++++++++++++++++++++
>  arch/arm/include/asm/hardware/cache-feroceon-l2.h  |  13 ++
>  arch/arm/mach-kirkwood/Kconfig                     |  25 ---
>  arch/arm/mach-kirkwood/Makefile                    |   6 +-
>  arch/arm/mach-kirkwood/Module.symvers              |   0
>  arch/arm/mach-kirkwood/board-dt.c                  | 150 ----------------
>  arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c     |  50 ------
>  arch/arm/mach-kirkwood/common.c                    |   3 +-
>  arch/arm/mach-kirkwood/common.h                    |  13 --
>  arch/arm/mach-kirkwood/include/mach/bridge-regs.h  |   2 +
>  arch/arm/mach-kirkwood/pm.c                        |   9 +-
>  arch/arm/mach-kirkwood/pm.h                        |  26 +++
>  arch/arm/mach-mv78xx0/common.c                     |   2 +-
>  arch/arm/mach-mvebu/Kconfig                        |  28 ++-
>  arch/arm/mach-mvebu/Makefile                       |   1 +
>  arch/arm/mach-mvebu/kirkwood-pm.c                  |  76 +++++++++
>  arch/arm/mach-mvebu/kirkwood-pm.h                  |  26 +++
>  arch/arm/mach-mvebu/kirkwood.c                     | 189 +++++++++++++++++++++
>  arch/arm/mach-mvebu/kirkwood.h                     |  22 +++
>  arch/arm/mach-mvebu/mvebu-soc-id.c                 |   1 +
>  arch/arm/mm/Kconfig                                |   2 +-
>  arch/arm/mm/cache-feroceon-l2.c                    |  48 +++++-
>  arch/arm/mm/proc-feroceon.S                        |   2 +-
>  arch/arm/mm/tlb-v4wbi.S                            |   3 +
>  .../plat-orion/include/plat/cache-feroceon-l2.h    |  11 --
>  drivers/cpufreq/Kconfig.arm                        |   2 +-
>  drivers/cpuidle/Kconfig.arm                        |   2 +-
>  drivers/irqchip/irq-orion.c                        |   3 +-
>  drivers/leds/Kconfig                               |   4 +-
>  drivers/phy/Kconfig                                |   2 +-
>  drivers/thermal/Kconfig                            |   2 +-
>  sound/soc/kirkwood/Kconfig                         |   2 +-
>  37 files changed, 682 insertions(+), 297 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mrvl/forocean.txt
>  create mode 100644 arch/arm/configs/multi_v5_defconfig
>  create mode 100644 arch/arm/include/asm/hardware/cache-feroceon-l2.h
>  create mode 100644 arch/arm/mach-kirkwood/Module.symvers
>  delete mode 100644 arch/arm/mach-kirkwood/board-dt.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-mv88f6281gtw_ge.c
>  create mode 100644 arch/arm/mach-kirkwood/pm.h
>  create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.c
>  create mode 100644 arch/arm/mach-mvebu/kirkwood-pm.h
>  create mode 100644 arch/arm/mach-mvebu/kirkwood.c
>  create mode 100644 arch/arm/mach-mvebu/kirkwood.h
>  delete mode 100644 arch/arm/plat-orion/include/plat/cache-feroceon-l2.h
> 
> -- 
> 1.8.5.3
>