Re: [PATCH] pinctrl: bcm2835: Use raw spinlock for RT compatibility

[Julia Cartwright <julia@xxxxxx>]

On Sun, Oct 28, 2018 at 08:27:35PM +0100, Linus Walleij wrote:
> On Sat, Oct 27, 2018 at 10:15 AM Lukas Wunner <lukas@xxxxxxxxx> wrote:
> 
> > The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable,
> > ->irq_disable and ->irq_set_type callbacks.  Spinlocks become sleeping
> > locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the
> > callbacks in atomic context may cause a hard lockup if at least two GPIO
> > pins in the same bank are used as interrupts.  The issue doesn't occur
> > with just a single interrupt pin per bank because the lock is never
> > contended.  I'm experiencing such lockups with GPIO 8 and 28 used as
> > level-triggered interrupts, i.e. with ->irq_disable being invoked on
> > reception of every IRQ.
> >
> > The critical section protected by the spinlock is very small (one bitop
> > and one RMW of an MMIO register), hence converting to a raw spinlock
> > seems a better trade-off than converting the driver to threaded IRQ
> > handling (which would increase latency to handle an interrupt).
> >
> > Cc: Mathias Duckeck <m.duckeck@xxxxxxxxx>
> > Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
> 
> Looks good to me but adding Julia Cartwright and Grygorii
> Strashko to this thread because they usually know this
> stuff way better than me.

The change seems reasonable to me.

As a side note: the bitops used to manage the enabled_irq_map are the
atomic variants (set_bit, etc), is this actually necessary?  In other
words, are they ever accessed outside of the spinlock?

   Julia