Re: [linux-pm] [PATCH v2 1/2] Input: gpio-keys - allow platform to specify exact irq flags

Mika Westerberg [off-list ref] writes:

On Mon, Nov 30, 2009 at 01:14:20AM -0800, Dmitry Torokhov wrote:

quoted

On Mon, Nov 30, 2009 at 10:27:37AM +0200, Mika Westerberg wrote:

quoted

BTW: maybe this sharing the IRQ line between multiple buttons could be
implemented with threaded irq handler? Then it can go to sleep if, for
some reason, gpio_get_value() sleeps. Unfortunately I don't have such
hardware so I can't test it.

We still need debounce support there so you still need a timer and a
workqueue. In the current form theraded IRQ will not buy us anything.

Yes, but with threaded irq handler it should be possible to find
out which gpio line caused the irq (via gpio_get_value()) so we can
schedule the correct workqueue handler, right?

The principal problem is not sharing an IRQ between multiple GPIO
buttons, but between GPIO buttons and other devices.  Even if you use
threaded IRQs, you have to decide in atomic context whether the handler
thread should be woken up, and that already involves gpio_get_value()
calls.  Of course you can wake up the handler thread unconditionally,
but then

 1. you're running your handlers with IRQs enabled (IRQF_ONESHOT is not
    an option, because it isn't allowed to be shared), which could mean
    retriggering the IRQ before you could acknowledge it, and

 2. you're potentially wasting resources by waking up the handler thread
    needlessly (think about sharing the IRQ with a 115 kbaud serial
    line).

Maybe a good middle ground would be switching to threaded interrupts
only if some of the given GPIOs can sleep, and hope that in this case
the IRQ is not shared with anything speedy (or disallow it, even).  But
I'm pretty much a rookie on this field, so I won't jump on this until
the plan is acked by some authority (Dmitry? :).  This hasn't happened
yet, but critique hasn't been raised either.
-- 
Cheers,
Feri.