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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mika Westerberg <mika.westerberg@xxxxxx> writes:

> On Mon, Nov 30, 2009 at 01:14:20AM -0800, Dmitry Torokhov wrote:
>
>> On Mon, Nov 30, 2009 at 10:27:37AM +0200, Mika Westerberg wrote:
>> 
>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux