Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
----------------------------------------------------------------
Vladimir Zapolskiy (3):
arm: lpc32xx: switch to common clock framework
arm: lpc32xx: remove selected HAVE_IDE
arm: lpc32xx: remove direct control of GPIOs from shared mach file
arch/arm/Kconfig | 4 +-
arch/arm/mach-lpc32xx/Makefile | 3 +-
arch/arm/mach-lpc32xx/clock.c | 1284 ---------------------------------------
arch/arm/mach-lpc32xx/phy3250.c | 53 --
arch/arm/mach-lpc32xx/serial.c | 3 -
arch/arm/mach-lpc32xx/timer.c | 144 -----
6 files changed, 3 insertions(+), 1488 deletions(-)
delete mode 100644 arch/arm/mach-lpc32xx/clock.c
delete mode 100644 arch/arm/mach-lpc32xx/timer.c
From: Olof Johansson <hidden> Date: 2016-02-24 21:36:33
Hi!
On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
In the future, please use the decription you wrote above as part of a tag
description, and sign your tags. For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).
It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right. If we get
regression reports we'll have to re-evaluate the approach. :)
Roland, any chance we can get a word from you on this? Thanks!
-Olof
Hi Olof,
On Wed, 2016-02-24 at 13:36 -0800, Olof Johansson wrote:
Hi!
On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
quoted
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
In the future, please use the decription you wrote above as part of a tag
description, and sign your tags. For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).
It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right. If we get
regression reports we'll have to re-evaluate the approach. :)
Roland, any chance we can get a word from you on this? Thanks!
-Olof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Sylvain,
On 25.02.2016 16:14, Sylvain Lemieux wrote:
Hi Olof,
On Wed, 2016-02-24 at 13:36 -0800, Olof Johansson wrote:
quoted
Hi!
On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
quoted
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
In the future, please use the decription you wrote above as part of a tag
description, and sign your tags. For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).
It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right. If we get
regression reports we'll have to re-evaluate the approach. :)
I am running this patchset and the LPC32xx DT update patchset on a
custom LPC32xx board; I did have any problem while running
those changes.
based on http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/406699.html
and links below I hope it should be read as you did *not* have any
problem while running the changes, but please feel free to correct me :)
I think that if this PR is applied to v4.6 then switching to a new
irqchip driver which properly handles virtual irqs might be simpler,
at least there should be less merge conflicts in the shared mach file.
Ok, thank you for testing. I have to submit v2 of the irqchip
driver with some changes, if you retest them I'll add your Tested-by
tag. I still have to think about the wakeup controller driver, not
sure if it should be a part of irqchip driver or separated from it.
Most probably it is too late for v4.6 for another pull request with
irqchip changes (fix requires this pull request to be applied first),
so that "unexpected IRQ trap at vector 00" critical problem from
legacy mapped hardware irqs to virtual irqs will be fixed only in v4.7,
as a reminder the problem was unveiled in v3.18-rc1 -- almost one
and a half years ago.
Best wishes,
Vladimir
Sylvain Lemieux
quoted
Roland, any chance we can get a word from you on this? Thanks!
-Olof
Hi Vladimir,
On Mon, 2016-02-29 at 02:18 +0200, Vladimir Zapolskiy wrote:
Hi Sylvain,
On 25.02.2016 16:14, Sylvain Lemieux wrote:
quoted
Hi Olof,
On Wed, 2016-02-24 at 13:36 -0800, Olof Johansson wrote:
quoted
Hi!
On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
quoted
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
In the future, please use the decription you wrote above as part of a tag
description, and sign your tags. For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).
It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right. If we get
regression reports we'll have to re-evaluate the approach. :)
I am running this patchset and the LPC32xx DT update patchset on a
custom LPC32xx board; I did have any problem while running
those changes.
Thanks for catching it;
yes, everything run fine, I did "NOT" have any issue.
I think that if this PR is applied to v4.6 then switching to a new
irqchip driver which properly handles virtual irqs might be simpler,
at least there should be less merge conflicts in the shared mach file.
Ok, thank you for testing. I have to submit v2 of the irqchip
driver with some changes, if you retest them I'll add your Tested-by
tag. I still have to think about the wakeup controller driver, not
sure if it should be a part of irqchip driver or separated from it.
Please cc me on the new version of the irqchip patchset;
I can test the patch and send a Tested-by tag.
Most probably it is too late for v4.6 for another pull request with
irqchip changes (fix requires this pull request to be applied first),
so that "unexpected IRQ trap at vector 00" critical problem from
legacy mapped hardware irqs to virtual irqs will be fixed only in v4.7,
as a reminder the problem was unveiled in v3.18-rc1 -- almost one
and a half years ago.
I think fixing the platform should be the first step
(i.e. standalone patchset for the irqchip);
the wakeup controller can be send in a separate patchset.
Sylvain Lemieux
Best wishes,
Vladimir
quoted
Sylvain Lemieux
quoted
Roland, any chance we can get a word from you on this? Thanks!
-Olof
Hi Olof,
On 24.02.2016 23:36, Olof Johansson wrote:
Hi!
On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
quoted
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.
I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).
----------------------------------------------------------------
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
https://github.com/vzapolskiy/linux.git lpc32xx/soc
for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
In the future, please use the decription you wrote above as part of a tag
description, and sign your tags.
got it, will do. Please let me know, if this pull request should be
resubmitted.
For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).
I'll ask nearby guys to sign my key on Free Thursday event next week.
It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right.
All the proposed changes are found on LAKML, and thanks to Sylvain Lemieux
for his spent time to test this pull request independently, plus Sylvain
also tested my irqchip changes on top of this pull request, which
bring the platform back to life.
I would really appreciate, if this pull request is accepted for v4.6, if it
happens then most probably v4.7 will contain all needed irqchip fixes --
this pull request removes a duplicated timer driver, which in turn strictly
depends on a legacy platform clock driver (removed) and on hardware irq
numbering provided by a legacy irqchip driver (will be removed in v4.7
hopefully).
I've discussed the situation with Arnd some time ago [1], the LPC32xx
platform is broken since v3.18-rc1 dated October 2014, and about that
time Roland presumably lost his interest in maintaining the platform...
If we get regression reports we'll have to re-evaluate the approach. :)
Sure.
Roland, any chance we can get a word from you on this? Thanks!
On Thursday 03 March 2016 00:56:43 Vladimir Zapolskiy wrote:
I would really appreciate, if this pull request is accepted for v4.6, if it
happens then most probably v4.7 will contain all needed irqchip fixes --
this pull request removes a duplicated timer driver, which in turn strictly
depends on a legacy platform clock driver (removed) and on hardware irq
numbering provided by a legacy irqchip driver (will be removed in v4.7
hopefully).
As far as I can tell, Olof merged the series into the next/cleanup
branch on Feb 24, but did not make that clear enough in his reply.
I don't see anything holding up your patches from going into 4.6,
everything should be fine, let me know if there are any other
problems here, and please check if the arm-soc/for-next branch
works for you.
Arnd
Hi Arnd,
On 03.03.2016 01:27, Arnd Bergmann wrote:
On Thursday 03 March 2016 00:56:43 Vladimir Zapolskiy wrote:
quoted
I would really appreciate, if this pull request is accepted for v4.6, if it
happens then most probably v4.7 will contain all needed irqchip fixes --
this pull request removes a duplicated timer driver, which in turn strictly
depends on a legacy platform clock driver (removed) and on hardware irq
numbering provided by a legacy irqchip driver (will be removed in v4.7
hopefully).
As far as I can tell, Olof merged the series into the next/cleanup
branch on Feb 24, but did not make that clear enough in his reply.
I don't see anything holding up your patches from going into 4.6,
everything should be fine, let me know if there are any other
problems here, and please check if the arm-soc/for-next branch
works for you.
I've checked it and everything is fine, thank you for pointing it out.
--
With best wishes,
Vladimir