Messages in this thread |  | | | Date | Fri, 3 Oct 2008 11:22:14 +0200 | | From | Haavard Skinnemoen <> | | Subject | Re: [PATCH/RFC] hardware irq debouncing support |
| |
David Brownell <david-b@pacbell.net> wrote: > Hardware IRQ debouncing is common for IRQ controllers which are > part of GPIO modules ... they often deal with mechanical switches, > buttons, and so forth. This patch: > > - Provides simple support for that in genirq > > - Includes sample implementations for some Linux systems > which already include non-generic support for this: > > * Atmel SOCs (AT91, AT32 -- the same GPIO module) > * OMAP2/OMAP3 (not quite as simple) > > Control over how long to debounce is less common, and often applies > to banks of GPIOs not individual signals ... not addressed here. > > Drivers can request this (where available) with a new IRQF_DEBOUNCED > flag/hint passed to request_irq(): > > IF that flag is set when a handler is registered > AND the relevant irq_chip supports debouncing > AND the IRQ isn't already flagged as being debounced > THEN the irq_chip is asked to enable debouncing for this IRQ > UNTIL the IRQ's last handler is unregistered. > ELSE > nothing is done ... the hint is ignored > FI > > Comments?
Note that at least for AT91 and AVR32, the terminology used is "glitch filtering", not "debouncing". The filtering period is very short (half a clock cycle), so it probably won't help much when dealing with mechanical switches and buttons.
What kind of guarantees should IRQF_DEBOUNCE provide? Filtering short glitches may be useful, but if drivers start assuming it will do real debouncing of badly filtered switches and buttons, I think we're in for some trouble...
> Having this mechanism in genirq would let boards remove a bunch of > nonportable code, and would let drivers like gpio_keys, gpio_mouse, > and various touchscreens work more reliably. It'd also let various > SOC-specific MMC and CF card drivers switch over to more standard > (and widely understandable) mechanisms. > > I'd like to submit such updates for the 2.6.28 merge window, in > part to let mainline avoid needing yet another driver-specific > programming interface for IRQ debouncing. (For TWL4030/TPS659x0, > as used in most OMAP3 boards including the Gumstix Overo and the > BeagleBoard.)
Given that the limitations of this interface are clearly documented, I'm all for it.
What would be perhaps even more useful is generic software debouncing support. Something like
int request_debounced_irq(int irq, unsigned long debounce_us, void (*handler)(void *data), void *data);
which would set up a handler which disables the interrupt and sets up a timer which will ack/unmask the interrupt and run the handler.
This would mean the "interrupt handler" really gets run in softirq context, and shared interrupt would probably be impossible to support, but I think it would be useful for certain kinds of interrupts.
What do you think?
Haavard
|  |