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
On Monday 06 October 2008, Pavel Machek wrote:
> 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?
That'd be as hardware dependent as the bad decision to mix such
signals on one line in the first place! As a rule, nothing gets
lost -- systems care about such events stable at the millisecond
granuarity, not nanosecond -- but I can't speak for all possible
bad hardware designs.
Recall that the systems with this support generally have no
shortage of interrupt lines, and thus no reason to share them.
The boards I'm working with right now have over two hundred
GPIOs, and all but a handful of them (if you exaggerate "two"
to be a "handful"!) can be configured as interrupt inputs.
And there's strong incentive NOT to share them ... if a signal
is dedicated to e.g. MMC1 card detect, it can gate the regulator
dedicated to that slot; but not if that signal is shared with
some other status. If two simple buttons both trigger the same
interrupt, you can't tell them apart. And so on.
- Dave