Re: [PATCH] gpio: omap: use raw locks for locking

[Thomas Gleixner <tglx@xxxxxxxxxxxxx>]

On Mon, 27 Jul 2015, Sebastian Andrzej Siewior wrote:
> On 07/27/2015 02:50 PM, Linus Walleij wrote:
> > Patch applied.
> thanks.
> 
> > 
> > Now this question appear in my head:
> > 
> > Is drivers/gpio full of stuff that will not work with the -RT kernel,
> > and is this a change that should be done mutatis mutandis on
> > all the GPIO drivers?
> 
> I described two call paths where you need a rawlock_t. If your gpio
> driver uses irq_chip_generic then you a rawlock here and things should
> be fine.
> 
> In general: If your gpio controller acts as an interrupts controller
> (that is via chained handler) then you need the raw-locks if you need
> any locking (if you have a write 1 to mask/unmask/enable/disable
> register then you probably don't need any locking here at all). If the
> gpio controller does not act as an interrupt controller than the
> spinlock_t type should be enough.
> If your gpio-interrupt controller requests its interrupt via
> requested_threaded_irq() then it should do handle_nested_irq() and a
> mutex is probably used for locking.
> 
> Using request_irq() with "0" flags is kind of broken. It works in
> IRQ-context and delivers the interrupts with generic_handle_irq() and
> this one passes it the handler (like handle_edge_irq() /
> handle_level_irq()) which takes a raw_lock. Now, if you boot the
> vanilla kernel with threadedirq then the irq-handler runs in threaded
> context and you can't take a spinlock here anymore. So I think you
> should use here IRQF_NO_THREAD here (and the raw lock type). I added
> tglx on Cc: to back up because it is Monday.

Indeed it was monday.

It's an RT only problem. On mainline spinlock resovles to raw_spinlock.

Now there is the story what breaks in RT:

1) irq controller specific locks which are taken in the irq chip
   callbacks need to be raw_spinlocks because these functions are
   called with irq_desc->lock helds and interrupts disabled.

   If that irq chip lock is not raw you rightfully get a backtrace.

   raw_spinlock_irq(&desc->lock);
   chip->callback()
     spin_lock(chip_private_lock);
       might_sleep() triggers

2) locks which are taken in chained interrupt handlers need to be raw
   on RT. These handlers run in hard interrupt context so again
   might_sleep() rightfully complains.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html