public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
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>
Subject: Re: [PATCH/RFC] hardware irq debouncing support
Date: Fri, 3 Oct 2008 16:06:21 +0300	[thread overview]
Message-ID: <20081003130618.GJ25482@atomide.com> (raw)
In-Reply-To: <200810030145.02779.david-b@pacbell.net>

* David Brownell <david-b@pacbell.net> [081003 11:45]:
> 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.  ;)

Well in linux-omap tree we have the gpio-switch.c that is handy for
generic state switched like headset connected etc. It shows the
events also via sysfs_notify() so userspace can pop up messages.

That code should use gpiolib..  But I was wondering if we'll need it
eventually at all.

Tony



> 
> - 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.  ;)

Sure :)

> 
> > 
> > > 
> > > ---
> > >  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 13:03 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 [this message]
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=20081003130618.GJ25482@atomide.com \
    --to=tony@atomide.com \
    --cc=david-b@pacbell.net \
    --cc=hskinnemoen@atmel.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@maxim.org.za \
    /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