[PATCH v3] RFC: pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP

[Michael Zoran]

On Mon, 2016-11-28 at 14:08 -0800, Michael Zoran wrote:
> On Mon, 2016-11-28 at 12:18 -0800, Eric Anholt wrote:
> > Stefan Wahren <stefan.wahren at i2se.com> writes:
> > 
> > > Hi Linus,
> > > 
> > > > Linus Walleij <linus.walleij at linaro.org> hat am 24. November
> > > > 2016
> > > > um 16:16
> > > > geschrieben:
> > > > 
> > > > 
> > > > On Mon, Nov 14, 2016 at 6:52 PM, Linus Walleij <linus.walleij at l
> > > > in
> > > > aro.org>
> > > > wrote:
> > > > 
> > > > > It should be possible to use the GPIOLIB_IRQCHIP helper
> > > > > library with the BCM2835 driver since it is a pretty straight
> > > > > forward cascaded irqchip.
> > > > > 
> > > > > The only difference from other drivers is that the BCM2835
> > > > > has several banks for a single gpiochip, and each bank has
> > > > > a separate IRQ line. Instead of creating one gpiochip per
> > > > > bank, a single gpiochip covers all banks GPIO lines. This
> > > > > makes it necessary to resolve the bank ID in the IRQ
> > > > > handler.
> > > > > 
> > > > > The GPIOLIB_IRQCHIP allows several IRQs to be cascaded off
> > > > > the same gpiochip by calling gpiochip_set_chained_irqchip()
> > > > > repeatedly, but we have been a bit short on examples
> > > > > for how this should be handled in practice, so this is
> > > > > intended
> > > > > as an example of how this can be achieved.
> > > > > 
> > > > > The old code did not model the chip as a chained interrupt
> > > > > handler, but this patch also rectifies that situation.
> > > > > 
> > > > > Cc: Stephen Warren <swarren at wwwdotorg.org>
> > > > > Cc: Stefan Wahren <stefan.wahren at i2se.com>
> > > > > Cc: Eric Anholt <eric at anholt.net>
> > > > > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> > > > > ---
> > > > > ChangeLog v2->v3:
> > > > > - Rebase on top of the two new patches from the vendor tree.
> > > > > ChangeLog v1->v2:
> > > > > - Forgot to convert the driver to chained IRQ handler. Now
> > > > > fixed.
> > > > > 
> > > > > Rpi folks: I have no clue if this works or not, but would be
> > > > > happy
> > > > > if you could test it to see if IRQs fire as expected and
> > > > > provide
> > > > > some feedback.
> > > > 
> > > > Any testers?
> > > > 
> > > > I'm getting tempted to just apply it to get test coverage, at
> > > > the
> > > > cost of having to revert it if it just explodes...
> > > 
> > > i made a simple boot + reboot test on my RPI 1 Model B without
> > > any
> > > issues.
> > > Unfortunately i don't have any additional hardware with a GPIO
> > > interrupt.
> > > 
> > > In the case this is sufficient you can have my:
> > > 
> > > Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
> > 
> > Given that this is mostly about changing how IRQs are handled, it
> > would
> > be really nice to actually test that.  I've forwarded the patch on
> > to
> > Phil in the hopes he can test it.  Alternatively, we could make
> > HDMI
> > use
> > the GPIO line as an interrupt and turn off HPD polling and see if
> > that
> > works before and after.
> > 
> 
> 
> I might be able to help.  Over the years I've built little breakout
> boards of a USB PIC32 from Microchip that has a GPIO header just like
> the RPI.  I can hook up a test on a breadboard that connects the
> PIC32
> to both the USB port and the GPIO header of a RPI 2 or RPI 3.  That
> way
> I can do some loopback tests.
> 
> The only thing is I no nothing about the GPIO API of Linux, so it
> would
> take some learning on my part.
> 
> It would possibly take me a few days or to the end of the week to
> test
> everything well, since like I said I would need to setup a test and
> write some test code. 
> 
> I can't help if you need to get this in sooner, such as for 4.10.
> 

Or another possibility would be to simply hook two RPI s to each other
through the GPIO header.  I have pre-made wires with connectors to do
it, but again I would need to learn about the GPIO system of Linux so
it would take me a few days.

Let me know if I can help or if the deadline is very short.