public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Tony Lindgren <tony@atomide.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Haavard Skinnemoen <hskinnemoen@atmel.com>,
	Andrew Victor <linux@maxim.org.za>,
	Kevin Hilman <khilman@deeprootsystems.com>
Subject: Re: [PATCH/RFC] hardware irq debouncing support
Date: Fri, 3 Oct 2008 01:45:01 -0700	[thread overview]
Message-ID: <200810030145.02779.david-b@pacbell.net> (raw)
In-Reply-To: <20081003073816.GB25482@atomide.com>

On Friday 03 October 2008, Tony Lindgren wrote:
> * David Brownell <david-b@pacbell.net> [080924 22:51]:
> > 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)
> >
> > 		...
> > Comments?
> > 
> > Having this mechanism in genirq would let boards remove a bunch of
> > nonportable code, and would let drivers like gpio_keys, gpio_mouse,
> > and various touchscreens work more reliably.  It'd also let various
> > SOC-specific MMC and CF card drivers switch over to more standard
> > (and widely understandable) mechanisms.
> 
> Yeah this would nuke bunch of omap specific code for dealing with
> battery covers, MMC slot open etc..

It would be hidden away behind IRQF_DEBOUNCE ... not so much
making the code vanish, as making hardware-specific interfaces
vanish in favor of what seems to be the most popular idiom.

(Regular input GPIOs could be debounced too, but every time
I've noticed debouncing in use, it's coupled to an IRQ.)


> > I'd like to submit such updates for the 2.6.28 merge window, in
> > part to let mainline avoid needing yet another driver-specific
> > programming interface for IRQ debouncing.  (For TWL4030/TPS659x0,
> > as used in most OMAP3 boards including the Gumstix Overo and the
> > BeagleBoard.)
> 
> What's the plan for sysfs_notify event for these switches? Are you
> planning to add something like that to gpiolib?

I'm not sure what you mean -- which particular switches?
If the issue is the MMC card detect switches, that seems
more like an MMC question...

There was discussion of having the gpio_export() code
support notification that way, triggered by interrupts
on IRQ-capable GPIOs, but nobody seems to have wanted
it enough to translate from talk to code.  ;)

- Dave

 
> Tony
> 
> 
> > p.s. Tony and Kevin:  note the locking bugfix in the OMAP2/3 bit.
> 
> Here's my ack for that:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

For the whole patch, I'll presume, not just that locking fix.  ;)

> 
> > 
> > ---
> >  arch/arm/mach-at91/gpio.c    |   13 +++++++++++++
> >  arch/arm/plat-omap/gpio.c    |   15 ++++++++++++++-
> >  arch/avr32/mach-at32ap/pio.c |   14 ++++++++++++++
> >  include/linux/interrupt.h    |    2 ++
> >  include/linux/irq.h          |    3 +++
> >  kernel/irq/manage.c          |   27 +++++++++++++++++++++++++++
> >  6 files changed, 73 insertions(+), 1 deletion(-)
> > 

  reply	other threads:[~2008-10-03  8:45 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 [this message]
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
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=200810030145.02779.david-b@pacbell.net \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox