Dove fixes for arm-soc/for-next
Subsystems (4)
Sebastian Hesselbarth
maintainercover Dove fixes for arm-soc/for-next
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 <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signature · 1 line
1.7.10.4
Sebastian Hesselbarth
maintainerPATCH 1/6 ARM: dove: Add pcie clock support
As dove now has clock gating control ensure pcie ports grab their clocks.
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(+)
arch/arm/mach-dove/pcie.c +5 -0
@@ -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" );
Signature · 1 line
1.7.10.4
Sebastian Hesselbarth
maintainerPATCH 2/6 ARM: dove: Fix tauros2 device tree init
In reply to Sebastian HesselbarthDuring 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.
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(-)
arch/arm/boot/dts/dove.dtsi +5 -0
@@ -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>;
arch/arm/mach-dove/common.c +2 -1
@@ -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 ();
Signature · 1 line
1.7.10.4
Sebastian Hesselbarth
maintainerRe: [PATCH 2/6] ARM: dove: Fix tauros2 device tree init
Quoted 18 lines · 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.hinclude was missing frommach-dove/common.c.
...arch/arm/mach-dove/common.c +1
-0@@ -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"
arch/arm/mach-dove/common.c static void __init dove_dt_init(void) · line 406
Quoted 8 lines
arch/arm/mach-dove/common.c +1
-1@@ -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
Andrew Lunn
maintainerRe: [PATCH 2/6] ARM: dove: Fix tauros2 device tree init
Quoted 31 lines · Sebastian Hesselbarth
Quoted 18 lines · 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.hinclude was missing frommach-dove/common.c.
...arch/arm/mach-dove/common.c +1
-0@@ -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" arch/arm/mach-dove/common.c static void __init dove_dt_init(void) · line 406
Quoted 8 lines
arch/arm/mach-dove/common.c +1
-1@@ -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.
Quoted 2 lines
But 2/6 is important because the change in
tauros2_initbreaks 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
Sebastian Hesselbarth
maintainerRe: [PATCH 2/6] ARM: dove: Fix tauros2 device tree init
Quoted 6 lines · Andrew Lunn
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 indove_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
Sebastian Hesselbarth
maintainerPATCH 3/6 ARM: dove: Fix clock names of sata and gbe
In reply to Sebastian HesselbarthThis patch fixes wrong clock names of lately added clock gates for sata and gbe (mv64xx_eth).
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(-)
arch/arm/mach-dove/common.c +2 -2
@@ -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);
Signature · 1 line
1.7.10.4
Sebastian Hesselbarth
maintainerPATCH 4/6 ARM: dove: Restructure SoC device tree descriptor
In reply to Sebastian HesselbarthThis patch adds proper ranges for all mapped addresses within dove SoC and moves the interrupt controller node inside the simple-bus node.
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(-)
arch/arm/boot/dts/dove.dtsi +18 -12
@@ -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>;
Signature · 1 line
1.7.10.4
Sebastian Hesselbarth
maintainerPATCH 5/6 ARM: dove: Remove watchdog from DT
In reply to Sebastian HesselbarthThe 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.
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(-)
arch/arm/boot/dts/dove.dtsi +0 -5
@@ -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>;
Signature · 1 line
1.7.10.4
Andrew Lunn
maintainerRe: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 3 lines · 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.
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
Sebastian Hesselbarth
maintainerRe: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 12 lines · Andrew Lunn
Quoted 3 lines · 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.
Just for my understanding: Is the problem here:
/* Clear watchdog timer interrupt */ reg = readl(BRIDGE_CAUSE); reg&= ~WDT_INT_REQ; writel(reg, BRIDGE_CAUSE);
Quoted 4 lines
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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Dear Sebastian Hesselbarth,
Quoted 3 lines · Sebastian Hesselbarth
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Andrew Lunn
maintainerRe: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 8 lines · Thomas Petazzoni
Dear Sebastian Hesselbarth,
Quoted 3 lines · Sebastian Hesselbarth
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...
Quoted 5 lines
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.
Quoted 3 lines
* 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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Dear Andrew Lunn,
Quoted 10 lines · Andrew Lunn
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?
Quoted 9 lines
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.
Quoted 7 lines
Quoted 4 lines
* 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Andrew Lunn
maintainerRe: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 15 lines · Thomas Petazzoni
Dear Andrew Lunn,
Quoted 10 lines · Andrew Lunn
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.
Quoted 3 lines
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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 21 lines · Andrew Lunn
Quoted 13 lines · Thomas Petazzoni
Quoted 10 lines · Andrew Lunn
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
Quoted 4 lines
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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Arnd Bergmann <[email protected]> writes:
Hi,
Quoted 36 lines · Andrew Lunn
Quoted 21 lines · Thomas Petazzoni
Quoted 13 lines · Andrew Lunn
Quoted 11 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
The next step would be to label mach-orion5x as deprecated in
Kconfigfor 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.
Quoted 13 lines
After that, we can leave mach-orion5x in the kernel for another release but completely disable the option to enable it in
Kconfigas 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.
Quoted 4 lines
Quoted 4 lines
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?
Quoted 6 lines
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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 7 lines · Arnaud Patard
Quoted 5 lines · Arnd Bergmann
The next step would be to label mach-orion5x as deprecated in
Kconfigfor a release and change the help text so it tells people to move to mach-mvebu and submit dts files.
Quoted 5 lines
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
Kconfiginfo 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?
Quoted 9 lines
Quoted 6 lines
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
Quoted 3 lines · Arnd Bergmann
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.
...
Quoted 2 lines
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.)
Signature · 2 lines
Martin Michlmayr http://www.cyrius.com/
Andrew Lunn
maintainerPATCH 5/6 ARM: dove: Remove watchdog from DT
Hi Martin
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 14 lines · Andrew Lunn
Quoted 2 lines
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.Quoted 3 lines
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.
Quoted 6 lines
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.cfiles. 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
Andrew Lunn
maintainerPATCH 5/6 ARM: dove: Remove watchdog from DT
Hi Arnd
Quoted 10 lines
Quoted 6 lines
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.cfiles. 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
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
In reply to Arnd BergmannQuoted 13 lines · Arnd Bergmann
Quoted 4 lines · Andrew Lunn
Quoted 4 lines
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.
Quoted 6 lines
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
Quoted 21 lines · Arnd Bergmann
Quoted 13 lines · Arnd Bergmann
Quoted 4 lines · Andrew Lunn
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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,
Signature · 1 line
sebastien requiem
Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT
Quoted 25 lines · sebastien requiem
Quoted 21 lines · Arnd Bergmann
Quoted 13 lines · Arnd Bergmann
Quoted 4 lines · Andrew Lunn
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
The address I used for Sebastien appears to be dead. Maybe this one still works.
Quoted 7 lines
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
Sebastian Hesselbarth
maintainerPATCH 6/6 ARM: dove: Add crypto engine to DT
In reply to Sebastian HesselbarthMake use of DT support for the crypto engine on dove and remove the obsolete init call.
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
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(-)
arch/arm/boot/dts/dove.dtsi +9 -0
@@ -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"; + }; }; };
arch/arm/mach-dove/common.c +0 -1
@@ -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 );
Signature · 1 line
1.7.10.4
Quoted 13 lines · 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
Quoted 4 lines
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:
None of my questions should be considered as NACKs for these patches.
Andrew