Mika Westerberg <mika.westerberg@xxxxxx> writes: > On Sat, Nov 28, 2009 at 01:16:48PM +0100, Ferenc Wagner wrote: > >> Mika Westerberg <ext-mika.1.westerberg@xxxxxxxxx> writes: >> >>> How about if we just add one field to struct gpio_keys_button? >>> ... >>> bool can_disable; >>> >>> Then gpio_keys uses this field when it decides what irqflags it >>> is going to pass to request_irq() (we don't allow platform data >>> to pass exact flags). So in case of can_disable is set, we don't >>> pass IRQF_SHARED to request_irq(). >>> >>> When support for sharing single IRQ between multiple buttons arrives >>> this field is still valid and we just need to take care of disable IRQ >>> line only when all buttons that share it, are disabled. >>> >>> This won't break existing users of gpio_keys and allows future >>> extension to support case of multiple buttons sharing single >>> IRQ line, right? >> >> Please don't shoot me, but I've got a different idea: what if we leave >> this whole business to the generic kernel interrupt handling routines? >> It would be as easy as requesting the IRQ on device open (I guess the >> input layer can relay the open event down here) and freeing it on close. >> The IRQ could stat shared all the time, and the kernel would >> automatically disable it when all handlers are unregistered. All this >> means no need to extend the platform data, no need for a separate sysfs >> interface, and still the application would have complete control of its >> wakeup sources by opening/closing them as needed. What do you think? > > Yeah, that would be nice. But it won't work for us :( > > This is because the actual input device might be open for several > applications. Then we have single process which controls state of > the device. Now if, for example the device is locked by user, this > process just disables those buttons which are not allowed to wake > up the device and blanks the screen. > > So the input device is still open but we just prevent GPIO lines > from generating any interrupts while the device is locked. There > are other use-cases also where different buttons are > disabled/enabled. Hi, I thought we'd better ask our friends over at linux-pm, if they've got some interface for this task. To summarize: an embedded application wants to go into a "locked" state, where some input devices (gpio keys in this case) are "muted", ie. they don't even generate interrupts to minimize power consumption. This could be solved by adding a new interface to gpio-keys, but the problem seems more general, so I wonder if something like the USB selective runtime suspend is already available (or preferable to develop) for such tasks. (I hope I got the summary right; Mika will provide the missing bits if I didn't.) -- Thanks, Feri. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
