From: Pavel Machek <pavel@suse.cz>
To: David Brownell <david-b@pacbell.net>
Cc: lkml <linux-kernel@vger.kernel.org>,
Haavard Skinnemoen <hskinnemoen@atmel.com>,
Andrew Victor <linux@maxim.org.za>,
Kevin Hilman <khilman@deeprootsystems.com>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH/RFC] hardware irq debouncing support
Date: Mon, 6 Oct 2008 17:10:03 +0200 [thread overview]
Message-ID: <20081006151003.GB1380@ucw.cz> (raw)
In-Reply-To: <200809241251.32606.david-b@pacbell.net>
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
next prev parent reply other threads:[~2008-10-07 13:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 19:51 [PATCH/RFC] hardware irq debouncing support David Brownell
2008-10-03 7:38 ` Tony Lindgren
2008-10-03 8:45 ` David Brownell
2008-10-03 13:06 ` Tony Lindgren
2008-10-03 9:22 ` Haavard Skinnemoen
2008-10-07 18:14 ` David Brownell
2008-10-08 7:48 ` Haavard Skinnemoen
2008-10-09 9:34 ` David Brownell
2008-10-09 10:30 ` Haavard Skinnemoen
2008-10-11 14:36 ` Pavel Machek
2008-10-11 18:01 ` David Brownell
2008-10-12 12:46 ` Haavard Skinnemoen
2008-11-07 22:56 ` David Brownell
2008-10-06 15:10 ` Pavel Machek [this message]
2008-10-07 17:19 ` David Brownell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081006151003.GB1380@ucw.cz \
--to=pavel@suse.cz \
--cc=david-b@pacbell.net \
--cc=hskinnemoen@atmel.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@maxim.org.za \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.