Messages in this thread | | | Date | Mon, 6 Oct 2008 17:10:03 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH/RFC] hardware irq debouncing support |
| |
On Wed 2008-09-24 12:51:32, David Brownell 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?
How is this going to work with shared interrupt lines? If one handler wants debouncing and second handler does not, you'll loose interrupts for second handler?
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |