[PATCH 0/6] Dove fixes for arm-soc/for-next

[PATCH 0/6] Dove fixes for arm-soc/for-next

[Sebastian Hesselbarth]

With the current speed of changes within arm kernel tree, there
have been some issues related to the mach-dove DT support patches
introduced lately. This patch set keeps up with the changes between
initial patch submission and current status of arm-soc/for-next.

Sebastian Hesselbarth (6):
  ARM: dove: Add pcie clock support
  ARM: dove: Fix tauros2 device tree init
  ARM: dove: Fix clock names of sata and gbe
  ARM: dove: Restructure SoC device tree descriptor
  ARM: dove: Remove watchdog from DT
  ARM: dove: Add crypto engine to DT

 arch/arm/boot/dts/dove.dtsi |   49 ++++++++++++++++++++++++++++---------------
 arch/arm/mach-dove/common.c |    8 +++----
 arch/arm/mach-dove/pcie.c   |    5 +++++
 3 files changed, 41 insertions(+), 21 deletions(-)

---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.10.4

[PATCH 1/6] ARM: dove: Add pcie clock support

[Sebastian Hesselbarth]

As dove now has clock gating control ensure pcie ports grab their
clocks.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-dove/pcie.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-dove/pcie.c b/arch/arm/mach-dove/pcie.c
index bb15b26..0ef4435 100644
--- a/arch/arm/mach-dove/pcie.c
+++ b/arch/arm/mach-dove/pcie.c
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/pci.h>
+#include <linux/clk.h>
 #include <video/vga.h>
 #include <asm/mach/pci.h>
 #include <asm/mach/arch.h>
@@ -188,6 +189,10 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 	if (orion_pcie_link_up(base)) {
 		struct pcie_port *pp = &pcie_port[num_pcie_ports++];
+		struct clk *clk = clk_get_sys("pcie", (index ? "1" : "0"));
+
+		if (!IS_ERR(clk))
+			clk_prepare_enable(clk);
 
 		printk(KERN_INFO "link up\n");
 
-- 
1.7.10.4

[PATCH 2/6] ARM: dove: Fix tauros2 device tree init

[Sebastian Hesselbarth]

During the review process of dove DT patches, Tauros2 cache
init call was changed and DT support added. This patch fixes
the call to Tauros2 init and adds a DT node. Moreover, plat/irq.h
include was missing from mach-dove/common.c.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |    5 +++++
 arch/arm/mach-dove/common.c |    3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 96fb824..3f41f50 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -20,6 +20,11 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		l2: l2-cache {
+			compatible = "marvell,tauros2-cache";
+			marvell,tauros2-cache-features = <0>;
+		};
+
 		uart0: serial at 12000 {
 			compatible = "ns16550a";
 			reg = <0x12000 0x100>;
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index b37bef1..343a4bc 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -32,6 +32,7 @@
 #include <linux/irq.h>
 #include <plat/time.h>
 #include <linux/platform_data/usb-ehci-orion.h>
+#include <plat/irq.h>
 #include <plat/common.h>
 #include <plat/addr-map.h>
 #include "common.h"
@@ -399,7 +400,7 @@ static void __init dove_dt_init(void)
 		(dove_tclk + 499999) / 1000000);
 
 #ifdef CONFIG_CACHE_TAUROS2
-	tauros2_init();
+	tauros2_init(0);
 #endif
 	dove_setup_cpu_mbus();
 
-- 
1.7.10.4

[PATCH 3/6] ARM: dove: Fix clock names of sata and gbe

[Sebastian Hesselbarth]

This patch fixes wrong clock names of lately added clock gates
for sata and gbe (mv64xx_eth).

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-dove/common.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 343a4bc..ffec26f 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -110,8 +110,8 @@ static void __init dove_clk_init(void)
 
 	orion_clkdev_add(NULL, "orion-ehci.0", usb0);
 	orion_clkdev_add(NULL, "orion-ehci.1", usb1);
-	orion_clkdev_add(NULL, "mv643xx_eth.0", ge);
-	orion_clkdev_add("0", "sata_mv.0", sata);
+	orion_clkdev_add(NULL, "mv643xx_eth_port.0", ge);
+	orion_clkdev_add(NULL, "sata_mv.0", sata);
 	orion_clkdev_add("0", "pcie", pex0);
 	orion_clkdev_add("1", "pcie", pex1);
 	orion_clkdev_add(NULL, "sdhci-dove.0", sdio0);
-- 
1.7.10.4

[PATCH 4/6] ARM: dove: Restructure SoC device tree descriptor

[Sebastian Hesselbarth]

This patch adds proper ranges for all mapped addresses within
dove SoC and moves the interrupt controller node inside the simple-bus
node.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |   30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 3f41f50..792bab0 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -4,27 +4,33 @@
 	compatible = "marvell,dove";
 	model = "Marvell Armada 88AP510 SoC";
 
-	interrupt-parent = <&intc>;
-
-	intc: interrupt-controller {
-		compatible = "marvell,orion-intc";
-		interrupt-controller;
-		#interrupt-cells = <1>;
-		reg = <0xf1020204 0x04>,
-		      <0xf1020214 0x04>;
-	};
-
-	mbus at f1000000 {
+	soc at f1000000 {
 		compatible = "simple-bus";
-		ranges = <0 0xf1000000 0x4000000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
+		interrupt-parent = <&intc>;
+
+		ranges = <0xc8000000 0xc8000000 0x0100000   /* CESA SRAM   1M */
+		          0xe0000000 0xe0000000 0x8000000   /* PCIe0 Mem 128M */
+		          0xe8000000 0xe8000000 0x8000000   /* PCIe1 Mem 128M */
+		          0xf0000000 0xf0000000 0x0100000   /* ScratchPad  1M */
+		          0x00000000 0xf1000000 0x1000000   /* SB/NB regs 16M */
+		          0xf2000000 0xf2000000 0x0100000   /* PCIe0 I/O   1M */
+		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
+		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
 
 		l2: l2-cache {
 			compatible = "marvell,tauros2-cache";
 			marvell,tauros2-cache-features = <0>;
 		};
 
+		intc: interrupt-controller {
+			compatible = "marvell,orion-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0x20204 0x04>, <0x20214 0x04>;
+		};
+
 		uart0: serial at 12000 {
 			compatible = "ns16550a";
 			reg = <0x12000 0x100>;
-- 
1.7.10.4

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Sebastian Hesselbarth]

The watchdog on dove requires an interrupt that is not yet
available on DT. Therefore, the watchdog DT node is removed
until the corresponding chained intc is available.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 792bab0..c59c529 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -67,11 +67,6 @@
 			status = "disabled";
 		};
 
-		wdt: wdt at 20300 {
-			compatible = "marvell,orion-wdt";
-			reg = <0x20300 0x28>;
-		};
-
 		gpio0: gpio at d0400 {
 			compatible = "marvell,orion-gpio";
 			#gpio-cells = <2>;
-- 
1.7.10.4

[PATCH 6/6] ARM: dove: Add crypto engine to DT

[Sebastian Hesselbarth]

Make use of DT support for the crypto engine on dove and remove
the obsolete init call.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |    9 +++++++++
 arch/arm/mach-dove/common.c |    1 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index c59c529..5a00022 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -145,5 +145,14 @@
 			nr-ports = <1>;
 			status = "disabled";
 		};
+
+		crypto: crypto at 30000 {
+			compatible = "marvell,orion-crypto";
+			reg = <0x30000 0x10000>,
+			      <0xc8000000 0x800>;
+			reg-names = "regs", "sram";
+			interrupts = <31>;
+			status = "okay";
+		};
 	};
 };
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index ffec26f..f723fe1 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -416,7 +416,6 @@ static void __init dove_dt_init(void)
 	dove_ehci0_init();
 	dove_ehci1_init();
 	dove_pcie_init(1, 1);
-	dove_crypto_init();
 
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     dove_auxdata_lookup, NULL);
-- 
1.7.10.4

[PATCH 2/6] ARM: dove: Fix tauros2 device tree init

[Sebastian Hesselbarth]

On 09/25/2012 02:02 AM, Sebastian Hesselbarth wrote:
> During the review process of dove DT patches, Tauros2 cache
> init call was changed and DT support added. This patch fixes
> the call to Tauros2 init and adds a DT node. Moreover, plat/irq.h
> include was missing from mach-dove/common.c.
 > ...
> diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
> index b37bef1..343a4bc 100644
> --- a/arch/arm/mach-dove/common.c
> +++ b/arch/arm/mach-dove/common.c
> @@ -32,6 +32,7 @@
>   #include<linux/irq.h>
>   #include<plat/time.h>
>   #include<linux/platform_data/usb-ehci-orion.h>
> +#include<plat/irq.h>
>   #include<plat/common.h>
>   #include<plat/addr-map.h>
>   #include "common.h"
> @@ -399,7 +400,7 @@ static void __init dove_dt_init(void)
>   		(dove_tclk + 499999) / 1000000);
>
>   #ifdef CONFIG_CACHE_TAUROS2
> -	tauros2_init();
> +	tauros2_init(0);
>   #endif
>   	dove_setup_cpu_mbus();
>

I thought about the importance of the individual patches and
except 2/6 all can wait for the next release cycle if too late.

But 2/6 is important because the change in tauros2_init
breaks build on dove.

Sebastian

[PATCH 2/6] ARM: dove: Fix tauros2 device tree init

[Andrew Lunn]

On Tue, Sep 25, 2012 at 03:22:04AM +0200, Sebastian Hesselbarth wrote:
> On 09/25/2012 02:02 AM, Sebastian Hesselbarth wrote:
> >During the review process of dove DT patches, Tauros2 cache
> >init call was changed and DT support added. This patch fixes
> >the call to Tauros2 init and adds a DT node. Moreover, plat/irq.h
> >include was missing from mach-dove/common.c.
> > ...
> >diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
> >index b37bef1..343a4bc 100644
> >--- a/arch/arm/mach-dove/common.c
> >+++ b/arch/arm/mach-dove/common.c
> >@@ -32,6 +32,7 @@
> >  #include<linux/irq.h>
> >  #include<plat/time.h>
> >  #include<linux/platform_data/usb-ehci-orion.h>
> >+#include<plat/irq.h>
> >  #include<plat/common.h>
> >  #include<plat/addr-map.h>
> >  #include "common.h"
> >@@ -399,7 +400,7 @@ static void __init dove_dt_init(void)
> >  		(dove_tclk + 499999) / 1000000);
> >
> >  #ifdef CONFIG_CACHE_TAUROS2
> >-	tauros2_init();
> >+	tauros2_init(0);
> >  #endif
> >  	dove_setup_cpu_mbus();
> >
> 
> I thought about the importance of the individual patches and
> except 2/6 all can wait for the next release cycle if too late.
> 
> But 2/6 is important because the change in tauros2_init
> breaks build on dove.

Hi Sebastian

Interestingly, kisskb does not show this break:

http://kisskb.ellerman.id.au/kisskb/config/308/

and yesterdays build does not have the parameter to tauros2_init().
Is the cache not enabled in dove_defconfig?

Andrew

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 02:02:17AM +0200, Sebastian Hesselbarth wrote:
> The watchdog on dove requires an interrupt that is not yet
> available on DT. Therefore, the watchdog DT node is removed
> until the corresponding chained intc is available.

Hi Sebastian

Just for my understanding: Is the problem here:

	/* Clear watchdog timer interrupt */
	reg = readl(BRIDGE_CAUSE);
	reg &= ~WDT_INT_REQ;
	writel(reg, BRIDGE_CAUSE);

I ask, because there is no need to pass an interrupt in the DT node.

It is clear to me that bit of code above needs cleaning up sometime
soon.

	Thanks
		Andrew

[PATCH 0/6] Dove fixes for arm-soc/for-next

[Andrew Lunn]

On Tue, Sep 25, 2012 at 02:02:12AM +0200, Sebastian Hesselbarth wrote:
> With the current speed of changes within arm kernel tree, there
> have been some issues related to the mach-dove DT support patches
> introduced lately. This patch set keeps up with the changes between
> initial patch submission and current status of arm-soc/for-next.
> 
> Sebastian Hesselbarth (6):
>   ARM: dove: Add pcie clock support
>   ARM: dove: Fix tauros2 device tree init
>   ARM: dove: Fix clock names of sata and gbe
>   ARM: dove: Restructure SoC device tree descriptor
>   ARM: dove: Remove watchdog from DT
>   ARM: dove: Add crypto engine to DT
> 
>  arch/arm/boot/dts/dove.dtsi |   49 ++++++++++++++++++++++++++++---------------
>  arch/arm/mach-dove/common.c |    8 +++----
>  arch/arm/mach-dove/pcie.c   |    5 +++++
>  3 files changed, 41 insertions(+), 21 deletions(-)

Its a bit late, Jason has already sent the pull request. But:

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

None of my questions should be considered as NACKs for these patches.

     Andrew

[PATCH 2/6] ARM: dove: Fix tauros2 device tree init

[Sebastian Hesselbarth]

On 09/25/2012 07:19 AM, Andrew Lunn wrote:
> Interestingly, kisskb does not show this break:
>
> http://kisskb.ellerman.id.au/kisskb/config/308/
>
> and yesterdays build does not have the parameter to tauros2_init().
> Is the cache not enabled in dove_defconfig?

Andrew,

I checked dove_defconfig and CONFIG_CACHE_TAUROS2 is not set.
I put it on my list for the next release cycle.

Interestingly, the mmp guys changed the parameter within
non-DT dove_init.

Sebastian

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Sebastian Hesselbarth]

On 09/25/2012 07:35 AM, Andrew Lunn wrote:
> On Tue, Sep 25, 2012 at 02:02:17AM +0200, Sebastian Hesselbarth wrote:
>> The watchdog on dove requires an interrupt that is not yet
>> available on DT. Therefore, the watchdog DT node is removed
>> until the corresponding chained intc is available.
>
> Just for my understanding: Is the problem here:
>
> 	/* Clear watchdog timer interrupt */
> 	reg = readl(BRIDGE_CAUSE);
> 	reg&= ~WDT_INT_REQ;
> 	writel(reg, BRIDGE_CAUSE);
>
> I ask, because there is no need to pass an interrupt in the DT node.
>
> It is clear to me that bit of code above needs cleaning up sometime
> soon.

Andrew,

maybe I mixed up wdt and rtc here. It's not a big deal as wdt isn't
used at all on dove. Passing the irq on DT will require proper irq handler
for the bridge irqs. I had a discussion about chained irq vs shared irq
handlers a while ago with Gregory to reuse mvebu code for dove and I
finally implemented a chained irq for the bridge irqs.

I am not sure how wdt is implemented on Armada 370/XP but AFAIK they
don't have a bridge irq cause register. But having a chained irq handler
for the bridge irqs and power management irqs on dove will allow to share
wdt and rtc on dove and kirkwood and maybe even allow us to share the timer
with armada 370/xp.

I didn't try to post all the dove on mach-mvebu patches in the current
release cycle, because mach-mvebu is still evolving to fast for me to keep
up with my limited spare time. But I have dove running on mach-mvebu...

Sebastian

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Tue, 25 Sep 2012 11:11:42 +0200, Sebastian Hesselbarth wrote:

> I didn't try to post all the dove on mach-mvebu patches in the current
> release cycle, because mach-mvebu is still evolving to fast for me to keep
> up with my limited spare time. But I have dove running on mach-mvebu...

Yes, this work is really great. However, I think that instead of making
a big change at once, we should rather follow something like:

 * Make mach-dove, mach-kirkwood, mach-orion5x, mach-mv78xx0 use the
   new gpio/pinctrl code

 * Remove the plat-orion gpio/pinctrl code

 * Make mach-dove, mach-kirkwood, mach-orion5x, mach-mv78xx0 use DT for
   everything.

 * Remove the plat-orion common.c file (once all devices are probed
   through DT, common.c is no longer needed).

 * Add clock framework support for everybody, with the code in
   drivers/clk/.

 * Refactor the PCI code so that it can cover all cases. We should soon
   be working on PCI support on Armada 370/XP, so it will show what are
   the differences/issues in having something that covers all cases.

 * And then, only, merge everybody in mach-mvebu.

The idea here is to make the existing
mach-{dove,kirkwood,orion5x,mv78xx0} gradually converge to DT,
pinctrl/gpio, clock and other things, and only after that merge into
mach-mvebu. It will be much easier to do the merge as most of the code
in those mach- directory will have disappeared, as well as the code in
plat-orion.

Best regards,

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

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 11:18:26AM +0200, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
> 
> On Tue, 25 Sep 2012 11:11:42 +0200, Sebastian Hesselbarth wrote:
> 
> > I didn't try to post all the dove on mach-mvebu patches in the current
> > release cycle, because mach-mvebu is still evolving to fast for me to keep
> > up with my limited spare time. But I have dove running on mach-mvebu...
> 
> Yes, this work is really great. However, I think that instead of making
> a big change at once, we should rather follow something like:
> 
>  * Make mach-dove, mach-kirkwood, mach-orion5x, mach-mv78xx0 use the
>    new gpio/pinctrl code

I principle, i agree. However, i'm not too sure about mach-orion5x &
mach-mv78xx0. orion5x has probably been broken since -rc1 was released
and nobody noticed. In the same time, we got around 5 people
independently reporting kirkwood was broken. We have not received any
new boards for orion5x in the time i've been looking at Orion
platforms. mv78xx0 only has one board which is not a Marvell reference
design. So im tempted to not spend any effort moving orion5x or
mv78xx0 to DT unless these actually hinder the effort of moving the
others to DT.  What may make sense is to flatten mv78xx0 and orion5x
into plat-orion and then just watch the bit-rot happen.

I have patches which convert all existing DT based kirkwood boards to
the new gpio/pinctrl code. There are two outstanding issues:

1) I've no idea which kirkwood variant each board uses. Hence the
   compatibility string will be wrong for a lot of them.

2) I'm probably made lots of dumb typos.

So we need to get board maintainers to complete and test the work.

>  * Refactor the PCI code so that it can cover all cases. We should soon
>    be working on PCI support on Armada 370/XP, so it will show what are
>    the differences/issues in having something that covers all cases.

Have you looked at the orion5x PCI code? Its very different to all the
others and i doubt it will be easy to make work with all the others.

       Andrew

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Thomas Petazzoni]

Dear Andrew Lunn,

On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:

> I principle, i agree. However, i'm not too sure about mach-orion5x &
> mach-mv78xx0. orion5x has probably been broken since -rc1 was released
> and nobody noticed. In the same time, we got around 5 people
> independently reporting kirkwood was broken. We have not received any
> new boards for orion5x in the time i've been looking at Orion
> platforms. mv78xx0 only has one board which is not a Marvell reference
> design. So im tempted to not spend any effort moving orion5x or
> mv78xx0 to DT unless these actually hinder the effort of moving the
> others to DT.  What may make sense is to flatten mv78xx0 and orion5x
> into plat-orion and then just watch the bit-rot happen.

I'll try to see if I can get people from LaCie to test mach-orion5x as
I have a few contacts there, and I'll contact Marvell to see if they can
still provide Orion-based platforms.

Regarding mv78xx0, I agree that I'm not sure what to do. The number of
supported platforms is small. Should we simply mark mv78xx0 deprecated
now, wait a few release cycles to see if anyone shows up, and see what
to do at this point?

> I have patches which convert all existing DT based kirkwood boards to
> the new gpio/pinctrl code. There are two outstanding issues:
> 
> 1) I've no idea which kirkwood variant each board uses. Hence the
>    compatibility string will be wrong for a lot of them.
> 
> 2) I'm probably made lots of dumb typos.
> 
> So we need to get board maintainers to complete and test the work.

Agreed. If some don't answer, we could consider dropping support for
those boards. If people show up again later, it is still possible to
get through the git history and revive one particular board. But we
can't, and shouldn't be forced to remain in the past due to
unmaintained platforms, IMO.

> >  * Refactor the PCI code so that it can cover all cases. We should
> > soon be working on PCI support on Armada 370/XP, so it will show
> > what are the differences/issues in having something that covers all
> > cases.
> 
> Have you looked at the orion5x PCI code? Its very different to all the
> others and i doubt it will be easy to make work with all the others.

No, I haven't looked seriously at the PCI code for the moment. I should
have the opportunity to do so at some point.

Best regards,

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

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
> 
> > I principle, i agree. However, i'm not too sure about mach-orion5x &
> > mach-mv78xx0. orion5x has probably been broken since -rc1 was released
> > and nobody noticed. In the same time, we got around 5 people
> > independently reporting kirkwood was broken. We have not received any
> > new boards for orion5x in the time i've been looking at Orion
> > platforms. mv78xx0 only has one board which is not a Marvell reference
> > design. So im tempted to not spend any effort moving orion5x or
> > mv78xx0 to DT unless these actually hinder the effort of moving the
> > others to DT.  What may make sense is to flatten mv78xx0 and orion5x
> > into plat-orion and then just watch the bit-rot happen.
> 
> I'll try to see if I can get people from LaCie to test mach-orion5x as
> I have a few contacts there, and I'll contact Marvell to see if they can
> still provide Orion-based platforms.

Marvell supplied my one one reference platform. So i can do some
testing that the basic infrastructure works.

But the problem with converting to DT is that there is a lot of
brainless monkey work needed per supported board, and its very easy to
make a typo. So each board converted to DT needs testing. I don't know
if we can find testers for all the boards. But should we throw out
working boards just because we cannot find somebody to test the DT
version?

	Andrew

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnd Bergmann]

On Tuesday 25 September 2012, Andrew Lunn wrote:
> On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
> > On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
> > 
> > > I principle, i agree. However, i'm not too sure about mach-orion5x &
> > > mach-mv78xx0. orion5x has probably been broken since -rc1 was released
> > > and nobody noticed. In the same time, we got around 5 people
> > > independently reporting kirkwood was broken. We have not received any
> > > new boards for orion5x in the time i've been looking at Orion
> > > platforms. mv78xx0 only has one board which is not a Marvell reference
> > > design. So im tempted to not spend any effort moving orion5x or
> > > mv78xx0 to DT unless these actually hinder the effort of moving the
> > > others to DT.  What may make sense is to flatten mv78xx0 and orion5x
> > > into plat-orion and then just watch the bit-rot happen.
> > 
> > I'll try to see if I can get people from LaCie to test mach-orion5x as
> > I have a few contacts there, and I'll contact Marvell to see if they can
> > still provide Orion-based platforms.
> 
> Marvell supplied my one one reference platform. So i can do some
> testing that the basic infrastructure works.
> 
> But the problem with converting to DT is that there is a lot of
> brainless monkey work needed per supported board, and its very easy to
> make a typo. So each board converted to DT needs testing. I don't know
> if we can find testers for all the boards. But should we throw out
> working boards just because we cannot find somebody to test the DT
> version?

We can throw them out in a staged process. I think the first step should
be ensuring that the platform support works on one (or better a few)
board reliably, and merge support for that into mach-mvebu but leave
the other ~20 board files in mach-orion5x without spending too much work
on them. Whether that means pinctrl support for mach-orion5x is a something
you need to figure out.

The next step would be to label mach-orion5x as deprecated in Kconfig for
a release and change the help text so it tells people to move to mach-mvebu
and submit dts files.

After that, we can leave mach-orion5x in the kernel for another release but
completely disable the option to enable it in Kconfig as a last warning.
This means anyone who is using it will have to move on or talk to us about
extending the transition period.

Finally, we remove mach-orion5x. Hopefully by that time, everyone who is
using it will have contributed a dts file for it.

> > Regarding mv78xx0, I agree that I'm not sure what to do. The number of
> > supported platforms is small. Should we simply mark mv78xx0 deprecated
> > now, wait a few release cycles to see if anyone shows up, and see what
> > to do at this point?

We should let Sebastien Requiem comment. He is the only person outside of
Marvell who has contributed a board file for mv78xx0. If he's interested in
keeping it alive, he's hopefully also able to find the time to test the
devicetree version of that platform in mach-mvebu. Similarly, if anyone
has the MASA reference design, that one could be moved over to mach-mvebu
first.

There is a much smaller user base for mv78xx0 than for orion5x, so as long
as we can keep the support working with DT, we can throw out the legacy
code much faster than for orion. If it doesn't get put into mach-mvebu
and you can't find anyone who has hardware to test on, you could also
stop maintaining it and leave it to bitrot, but I wouldn't just remove it
on a fast track then.

	Arnd

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnaud Patard (Rtp)]

Arnd Bergmann <arnd@arndb.de> writes:

Hi,

> On Tuesday 25 September 2012, Andrew Lunn wrote:
>> On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
>> > On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
>> > 
>> > > I principle, i agree. However, i'm not too sure about mach-orion5x &
>> > > mach-mv78xx0. orion5x has probably been broken since -rc1 was released
>> > > and nobody noticed. In the same time, we got around 5 people
>> > > independently reporting kirkwood was broken. We have not received any
>> > > new boards for orion5x in the time i've been looking at Orion
>> > > platforms. mv78xx0 only has one board which is not a Marvell reference
>> > > design. So im tempted to not spend any effort moving orion5x or
>> > > mv78xx0 to DT unless these actually hinder the effort of moving the
>> > > others to DT.  What may make sense is to flatten mv78xx0 and orion5x
>> > > into plat-orion and then just watch the bit-rot happen.
>> > 
>> > I'll try to see if I can get people from LaCie to test mach-orion5x as
>> > I have a few contacts there, and I'll contact Marvell to see if they can
>> > still provide Orion-based platforms.
>> 
>> Marvell supplied my one one reference platform. So i can do some
>> testing that the basic infrastructure works.
>> 
>> But the problem with converting to DT is that there is a lot of
>> brainless monkey work needed per supported board, and its very easy to
>> make a typo. So each board converted to DT needs testing. I don't know
>> if we can find testers for all the boards. But should we throw out
>> working boards just because we cannot find somebody to test the DT
>> version?
>
> We can throw them out in a staged process. I think the first step should
> be ensuring that the platform support works on one (or better a few)
> board reliably, and merge support for that into mach-mvebu but leave
> the other ~20 board files in mach-orion5x without spending too much work
> on them. Whether that means pinctrl support for mach-orion5x is a something
> you need to figure out.
>
> The next step would be to label mach-orion5x as deprecated in Kconfig for
> a release and change the help text so it tells people to move to mach-mvebu
> and submit dts files.
>

You seem to imply that every user of mach-orion5x can write a dts
file. Please don't forget that afaik some users are using the kernel
provided by their $distribution, so if it gets broken it may be noticed
months later. Moreover, this kind of user won't notice the Kconfig info
as all they'll get is a binary.

> After that, we can leave mach-orion5x in the kernel for another release but
> completely disable the option to enable it in Kconfig as a last warning.
> This means anyone who is using it will have to move on or talk to us about
> extending the transition period.
>
> Finally, we remove mach-orion5x. Hopefully by that time, everyone who is
> using it will have contributed a dts file for it.
>
>> > Regarding mv78xx0, I agree that I'm not sure what to do. The number of
>> > supported platforms is small. Should we simply mark mv78xx0 deprecated
>> > now, wait a few release cycles to see if anyone shows up, and see what
>> > to do at this point?
>
> We should let Sebastien Requiem comment. He is the only person outside of
> Marvell who has contributed a board file for mv78xx0. If he's interested in
> keeping it alive, he's hopefully also able to find the time to test the
> devicetree version of that platform in mach-mvebu. Similarly, if anyone
> has the MASA reference design, that one could be moved over to mach-mvebu
> first.

There are some mv78xx0 (BP) dev boards used in Debian infrastructure, so
at least, would nice to not break mv78xx0 support.

Arnaud

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnd Bergmann]

On Tuesday 25 September 2012, Arnaud Patard wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> >
> > The next step would be to label mach-orion5x as deprecated in Kconfig for
> > a release and change the help text so it tells people to move to mach-mvebu
> > and submit dts files.
> >
> 
> You seem to imply that every user of mach-orion5x can write a dts
> file. Please don't forget that afaik some users are using the kernel
> provided by their $distribution, so if it gets broken it may be noticed
> months later. Moreover, this kind of user won't notice the Kconfig info
> as all they'll get is a binary.

The hard part is finding those users. Once we know who they are, we can
either try to help out by writing a dts file and letting them test it,
or by assisting them in the process to write one themselves.

You certainly make a good point about users that just get pre-built
binaries. Do you think we can find them by printing a warning
message from the kernel that points to some wiki page with instructions
of how to contact people and let us know what they are using?

In case of Debian, would it be possible to use an old kernel (say, 3.7)
for as long as people need to run the with the old board files, while
at the same time moving on with 3.8 and later kernels to support only
the ones that are converted to a single binary and DT booting?

> > We should let Sebastien Requiem comment. He is the only person outside of
> > Marvell who has contributed a board file for mv78xx0. If he's interested in
> > keeping it alive, he's hopefully also able to find the time to test the
> > devicetree version of that platform in mach-mvebu. Similarly, if anyone
> > has the MASA reference design, that one could be moved over to mach-mvebu
> > first.
> 
> There are some mv78xx0 (BP) dev boards used in Debian infrastructure, so
> at least, would nice to not break mv78xx0 support.

Ah, very good to know. Do you know who has access to those machines
and is willing to help out with testing? Debian is probably the party
that benefits the most from the work to move mv78xx0/kirkwood/orion5x
into a single kernel together with iop32x, versatile and vt8500, so
hopefully they can help out in with the process to get there.

We should certainly make sure we don't remove those machines as long
as Debian supports them.

	Arnd

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnd Bergmann]

On Tuesday 25 September 2012, Arnd Bergmann wrote:
> On Tuesday 25 September 2012, Andrew Lunn wrote:
> > > Regarding mv78xx0, I agree that I'm not sure what to do. The number of
> > > supported platforms is small. Should we simply mark mv78xx0 deprecated
> > > now, wait a few release cycles to see if anyone shows up, and see what
> > > to do at this point?
> 
> We should let Sebastien Requiem comment. He is the only person outside of
> Marvell who has contributed a board file for mv78xx0. If he's interested in
> keeping it alive, he's hopefully also able to find the time to test the
> devicetree version of that platform in mach-mvebu. Similarly, if anyone
> has the MASA reference design, that one could be moved over to mach-mvebu
> first.
> 
> There is a much smaller user base for mv78xx0 than for orion5x, so as long
> as we can keep the support working with DT, we can throw out the legacy
> code much faster than for orion. If it doesn't get put into mach-mvebu
> and you can't find anyone who has hardware to test on, you could also
> stop maintaining it and leave it to bitrot, but I wouldn't just remove it
> on a fast track then.

The address I used for Sebastien appears to be dead. Maybe this one still
works.

	Arnd

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[sebastien requiem]

On Tue, Sep 25, 2012 at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 25 September 2012, Arnd Bergmann wrote:
>> On Tuesday 25 September 2012, Andrew Lunn wrote:
>> > > Regarding mv78xx0, I agree that I'm not sure what to do. The number of
>> > > supported platforms is small. Should we simply mark mv78xx0 deprecated
>> > > now, wait a few release cycles to see if anyone shows up, and see what
>> > > to do at this point?
>>
>> We should let Sebastien Requiem comment. He is the only person outside of
>> Marvell who has contributed a board file for mv78xx0. If he's interested in
>> keeping it alive, he's hopefully also able to find the time to test the
>> devicetree version of that platform in mach-mvebu. Similarly, if anyone
>> has the MASA reference design, that one could be moved over to mach-mvebu
>> first.
>>
>> There is a much smaller user base for mv78xx0 than for orion5x, so as long
>> as we can keep the support working with DT, we can throw out the legacy
>> code much faster than for orion. If it doesn't get put into mach-mvebu
>> and you can't find anyone who has hardware to test on, you could also
>> stop maintaining it and leave it to bitrot, but I wouldn't just remove it
>> on a fast track then.
>
> The address I used for Sebastien appears to be dead. Maybe this one still
> works.

Yes, this one works. Sorry for not having updated my email address.

I would be happy to convert the mv78xx0 platform to DT (and also do
the monkey work). My knowledge is quite limited regarding the recent changes
but I am sure that some of you could help me in the process.

Moreover, I still have a board to test at home.

regards,

-- 
sebastien requiem

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnd Bergmann]

On Tuesday 25 September 2012, sebastien requiem wrote:
> On Tue, Sep 25, 2012 at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 25 September 2012, Arnd Bergmann wrote:
> >> On Tuesday 25 September 2012, Andrew Lunn wrote:
> >> > > Regarding mv78xx0, I agree that I'm not sure what to do. The number of
> >> > > supported platforms is small. Should we simply mark mv78xx0 deprecated
> >> > > now, wait a few release cycles to see if anyone shows up, and see what
> >> > > to do at this point?
> >>
> >> We should let Sebastien Requiem comment. He is the only person outside of
> >> Marvell who has contributed a board file for mv78xx0. If he's interested in
> >> keeping it alive, he's hopefully also able to find the time to test the
> >> devicetree version of that platform in mach-mvebu. Similarly, if anyone
> >> has the MASA reference design, that one could be moved over to mach-mvebu
> >> first.
> >>
> >> There is a much smaller user base for mv78xx0 than for orion5x, so as long
> >> as we can keep the support working with DT, we can throw out the legacy
> >> code much faster than for orion. If it doesn't get put into mach-mvebu
> >> and you can't find anyone who has hardware to test on, you could also
> >> stop maintaining it and leave it to bitrot, but I wouldn't just remove it
> >> on a fast track then.
> >
> > The address I used for Sebastien appears to be dead. Maybe this one still
> > works.
> 
> Yes, this one works. Sorry for not having updated my email address.
> 
> I would be happy to convert the mv78xx0 platform to DT (and also do
> the monkey work). My knowledge is quite limited regarding the recent changes
> but I am sure that some of you could help me in the process.
> 
> Moreover, I still have a board to test at home.

Ok, excellent!

If you want to start looking into things, I suggest you follow the
examples from the mach-dove directory, which is similar to mv78xx0 in
that it also has only a small number of boards that are supported,
and we can convert them all at the same time, rather than supporting
both methods in parallel as we do for orion5x and kirkwood.

The basic idea is to start with a DT_START_MACHINE section that will
end up being used for all machines and just initializes all the
devices that you have on your machine, but also calls of_platform_populate.
Then you can gradually move over one device at a time from being
statically initialized to being added to a board description in
arch/arm/boot/dts/*.dts.

One thing that seems to be special about mv78xx0 (though not the wxl
in particular) is that we can have Linux running in two instances on
either core of the machine and just give it a few of the devices.
I think this can be handled nicely with DT by having a .dtsi include
file that actually describes all of the machine but marks most of the
devices as disabled, and then have different .dts files including
the main file and selectively enabling the parts that are used there.

	Arnd

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Martin Michlmayr]

* Arnd Bergmann <arnd@arndb.de> [2012-09-25 12:28]:
> The hard part is finding those users. Once we know who they are, we can
> either try to help out by writing a dts file and letting them test it,
> or by assisting them in the process to write one themselves.
...
> We should certainly make sure we don't remove those machines as long
> as Debian supports them.

Arnaud Patard pointed out this conversation to me.  I added Orion and
Kirkwood support to Debian.  Unfortunately, I don't have a lot of
time these days but there are definitely still Debian users on Orion
and I would like to continue supporting them.

If someone volunteers to keep the Orion code up-to-date and/or port it
to DT, I can perform tests from time to time.  I have the following
Orion devices: QNAP TS-209, QNAP TS-409, HP mv2120 and D-Link DNS-323.

If someone wants to work on Orion kernel support, I can also make a
QNAP TS-409 main board and a D-Link DNS-323 device available.

(Please CC me since I'm currently not subscribed.)
-- 
Martin Michlmayr
http://www.cyrius.com/

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

Hi Martin

> Arnaud Patard pointed out this conversation to me.  I added Orion and
> Kirkwood support to Debian. 

I used your guide at http://www.cyrius.com/debian/kirkwood/qnap/
to convert my QNAP-119P+ over to Debian. Works great.

> If someone volunteers to keep the Orion code up-to-date and/or port it
> to DT, I can perform tests from time to time.  I have the following
> Orion devices: QNAP TS-209, QNAP TS-409, HP mv2120 and D-Link DNS-323.

At the moment Kirkwood is my priority, but i think we should have most
of it converted to DT in the next three months. Once that is over, i
can look at Orion5x.

It is great you offered to test. I have a Marvell orion5x reference
system, rd88f5182. So i can do a lot of the conversion using
that. What i think will cause problems is PCI. There is scary looking
PCI code in the -setup.c files. I don't know how easy that will be to
convert to DT. However, it looks like most targets don't actually use
PCI, so maybe some will be easier to convert than others.

	Andrew

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Arnd Bergmann]

On Monday 08 October 2012, Andrew Lunn wrote:
> > Arnaud Patard pointed out this conversation to me.  I added Orion and
> > Kirkwood support to Debian. 
> 
> I used your guide at http://www.cyrius.com/debian/kirkwood/qnap/
> to convert my QNAP-119P+ over to Debian. Works great.
> 
> > If someone volunteers to keep the Orion code up-to-date and/or port it
> > to DT, I can perform tests from time to time.  I have the following
> > Orion devices: QNAP TS-209, QNAP TS-409, HP mv2120 and D-Link DNS-323.
> 
> At the moment Kirkwood is my priority, but i think we should have most
> of it converted to DT in the next three months. Once that is over, i
> can look at Orion5x.
> 
> It is great you offered to test. I have a Marvell orion5x reference
> system, rd88f5182. So i can do a lot of the conversion using
> that. What i think will cause problems is PCI. There is scary looking
> PCI code in the -setup.c files. I don't know how easy that will be to
> convert to DT. However, it looks like most targets don't actually use
> PCI, so maybe some will be easier to convert than others.

I can offer some help with the PCI bits. I don't have any orion hardware,
but if you get stuck, you can find me on IRC or we can talk on the phone
about how it should be done.

	Arnd

[PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

Hi Arnd

> > It is great you offered to test. I have a Marvell orion5x reference
> > system, rd88f5182. So i can do a lot of the conversion using
> > that. What i think will cause problems is PCI. There is scary looking
> > PCI code in the -setup.c files. I don't know how easy that will be to
> > convert to DT. However, it looks like most targets don't actually use
> > PCI, so maybe some will be easier to convert than others.
> 
> I can offer some help with the PCI bits. I don't have any orion hardware,
> but if you get stuck, you can find me on IRC or we can talk on the phone
> about how it should be done.

Thanks for the offer.

I know that the Free Electron guys, Thomas or Gregory, will be looking
at PCI for 370/XP soon and Kirkwood and Dove are in scope for that
work, as far as i know. So i will see how that developers, maybe lend
a hand, and see how easy it is to integrate support for Orion5x.

I suspect Orion5x might be a problem though. Its both PCI and PCIe,
where as the others are purely PCIe and orion5x has WA access method,
which all the other Marvell systems don't have. Also, it seems like
some Orion5x boards have the PCI IRQ on GPIO lines where as all the
other SoC have dedicated pins.

      Andrew