On Tue, Sep 22, 2009 at 09:06:05PM +0200, Ferenc Wagner wrote: > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > > > On Tue, Sep 22, 2009 at 05:14:22PM +0200, Ferenc Wagner wrote: > >> Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > >> > >>> On Wed, Sep 16, 2009 at 07:03:18PM +0400, Dmitry Eremin-Solenikov wrote: > >>>> There is nothing that disallows gpio-keys to share it's IRQ line > >>>> w/ other drivers. Make it use IRQF_SHARED in request_irq(). > >>>> > >>>> An example of other driver with which I'd like to share IRQ line > >>>> for GPIO buttons is ledtrig-gpio. > >>>> > >>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@xxxxxxxxx> > >>>> --- > >>>> drivers/input/keyboard/gpio_keys.c | 1 + > >>>> 1 files changed, 1 insertions(+), 0 deletions(-) > >>>> > >>>> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c > >>>> index efed0c9..9fc2fab 100644 > >>>> --- a/drivers/input/keyboard/gpio_keys.c > >>>> +++ b/drivers/input/keyboard/gpio_keys.c > >>>> @@ -147,6 +147,7 @@ static int __devinit gpio_keys_probe(struct platform_device *pdev) > >>>> } > >>>> > >>>> error = request_irq(irq, gpio_keys_isr, > >>>> + IRQF_SHARED | > >>>> IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, > >>>> button->desc ? button->desc : "gpio_keys", > >>>> bdata); > >>> > >>> How will you determine which device generated the interrupt? Because you > >>> can't return IRQ_HANDLED unconditionally and expect both devices work > >>> reliably. > >> > >> It would be possible, but commit > >> da0d03fe6cecde837f113a8a587f5a872d0fade0 states that: > >> > >> The gpio_get_value function may sleep, so it should not be called in a > >> timer function. > >> > >> But I don't see why it could sleep, is that really the case? > > > > There are things like i2c gpio extenders that require access to slow > > buses and can't sleep. > > I assume you mean "can sleep". Yes. > Please read my other reply in this > thread before the following. All this seems to mean that using level > triggered interrupts on such devices is impossible, unless we find a > way to acknowledge the interrupt without GPIO access. You probably want to look into threaded interrupt handlers and IRQF_ONESHOT. These can't be shared though, so it looks like you need nested IRQ handlers ifrastructure. > But level > triggering is needed for sharing. I believe that both level and edge-triggered interrupts can be shared. > Maybe we could make this > configurable on a per-button basis? Or by a module parameter? > Anyway, a gpio_cansleep test should go into the module initialisation > routine. > > >> Also, commit 57ffe9d539e0eb741bb9ca8f2834d210e70ee2e3 removed the > >> possibility of telling apart different keys, so that should be > >> reverted during the process. I already asked Uwe Kleine-König > >> about the whys, but didn't get a reply. > > > > I don't see why you say that... You request IRQ per button and you get > > that button structure as argument in the interrupt handler. > > In practice, several buttons often share a single IRQ line, possibly > even with other hardware, like the serial port in my case (as > described in my other reply). So generally you need the full platform > data for all GPIO buttons in the handler, to find out which generated > the interrupt. Your interrupt handler will get called for every button on that IRQ line and you can query button state I think. -- Dmitry -- 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
