| Message ID | 1348531338-16624-6-git-send-email-sebastian.hesselbarth@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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,
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
* 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.)
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
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
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
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@20300 { - compatible = "marvell,orion-wdt"; - reg = <0x20300 0x28>; - }; - gpio0: gpio@d0400 { compatible = "marvell,orion-gpio"; #gpio-cells = <2>;
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@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/boot/dts/dove.dtsi | 5 ----- 1 file changed, 5 deletions(-)