[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.
> 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?

(cesky, pictures)

 \ /
  Last update: 2008-10-07 15:11    [W:0.090 / U:1.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site