From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:02:47
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:02:51
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(+)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:02:55
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(-)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:02:59
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(-)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:03:04
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(-)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:03:15
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(-)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 00:03:39
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 <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <redacted>
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(-)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 01:22:10
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.
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-09-25 05:20:06
On Tue, Sep 25, 2012 at 03:22:04AM +0200, Sebastian Hesselbarth wrote:
On 09/25/2012 02:02 AM, Sebastian Hesselbarth wrote:
quoted
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.
...
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-09-25 05:35:57
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-09-25 05:38:05
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
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 08:56:36
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
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: 2012-09-25 09:11:48
On 09/25/2012 07:35 AM, Andrew Lunn wrote:
On Tue, Sep 25, 2012 at 02:02:17AM +0200, Sebastian Hesselbarth wrote:
quoted
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
From: Thomas Petazzoni <hidden> Date: 2012-09-25 09:18:46
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-09-25 09:46:27
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:
quoted
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
From: Thomas Petazzoni <hidden> Date: 2012-09-25 10:14:55
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.
quoted
* 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
From: Andrew Lunn <andrew@lunn.ch> Date: 2012-09-25 10:31:56
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:
quoted
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
On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
quoted
On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
quoted
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.
quoted
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
On Tuesday 25 September 2012, Arnd Bergmann wrote:
On Tuesday 25 September 2012, Andrew Lunn wrote:
quoted
quoted
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
On Tue, Sep 25, 2012 at 2:33 PM, Arnd Bergmann [off-list ref] wrote:
On Tuesday 25 September 2012, Arnd Bergmann wrote:
quoted
On Tuesday 25 September 2012, Andrew Lunn wrote:
quoted
quoted
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
On Tuesday 25 September 2012, sebastien requiem wrote:
On Tue, Sep 25, 2012 at 2:33 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 25 September 2012, Arnd Bergmann wrote:
quoted
On Tuesday 25 September 2012, Andrew Lunn wrote:
quoted
quoted
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