[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200810071019.08647.david-b@pacbell.net>
Date: Tue, 7 Oct 2008 10:19:08 -0700
From: David Brownell <david-b@...bell.net>
To: Pavel Machek <pavel@...e.cz>
Cc: lkml <linux-kernel@...r.kernel.org>,
Haavard Skinnemoen <hskinnemoen@...el.com>,
Andrew Victor <linux@...im.org.za>,
Kevin Hilman <khilman@...prootsystems.com>,
Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH/RFC] hardware irq debouncing support
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists