[GIT PULL] NXP LPC32xx Platform Updates for v4.6 #1

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.

I am trying to run the major changes for the LPC32xx platform before 
the pull request take place; see the 2 link below:
http://permalink.gmane.org/gmane.linux.drivers.devicetree/155413
http://permalink.gmane.org/gmane.linux.drivers.devicetree/155560

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