> One of the earlier examples of why to want debouncing (in the
> original discussion, not this one) was for buttons (one signal
> per button press) and the hardware designers don't necessarily
> hook buttons up to only GPIOs with hardware debounce. So code
> to kick in debounce there needed to be
> > Not all GPIOs have hardware debounce though, so
> offering this
> > capability sort of begs the question of where/how to
> provide a software debounce mechanism too...
>
> how about adding a flag for supported features and if that
> hardware doesn't support we simply return,
Presense of a de
--- On Fri, 5/21/10, Alan Cox wrote:
> GPIO is almost always fairly tightly platform bound
Not entirely. SOC based ones, yes. But GPIOs on expanders
and ancillary chips have more variable capabilities, and many
SOC-based boards have a bunch of those.
> so features only
> existing on certa
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index cd85fd1..ed1ed74 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1461,9 +1461,14 @@ int gpio_set_debounce(unsigned gpio, unsigned debounce)
>
> spin_lock_irqsave(&gpio_lock, flags);
>
>
> stable and software has to cope with fewer events. We've lived without
> it for quite some time, though.
We lived without graphics for quite some time, without 64bit for quite
some time ;)
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to
On Fri, May 21, 2010 at 12:50:41AM +0200, ext David Brownell wrote:
This would be generally useful for embedded systems,
especially where the interrupt concerned is a wake source.
It allows drivers to avoid
spurious interrupts from noisy sources so if the hardware
supports it
the driver can a
> This would be generally useful for embedded systems,
> especially where the interrupt concerned is a wake source.
> It allows drivers to avoid
> spurious interrupts from noisy sources so if the hardware
> supports it
> the driver can avoid having to explicitly wait for the
> signal to become
>
> I'm still wobbling on the 35-vs-36 line. Is that a big need or a
> little need? What user-visible problem does it solve, etc?
>
> Did anyone test it on the MID boxes?
Yes and no - our code is subtly different but we'll just adapt to the
Nokia patch.
The MID bits are heading for .36 I hope so
On Mon, May 17, 2010 at 01:02:30PM +0300, felipe.ba...@nokia.com wrote:
> From: Felipe Balbi
>
> Few architectures, like OMAP, allow you to set
> a debouncing time for the gpio before generating
> the IRQ. Teach gpiolib about that.
>
> Signed-off-by: Felipe Balbi
Reviewed-by: Mark Brown
This
On Thu, 20 May 2010 20:04:17 +0100
Alan Cox wrote:
>
> > > +EXPORT_SYMBOL_GPL(gpio_set_debounce);
> >
> > nitlet: I suspect this function is taking gpio_lock sooner than it
> > strictly needs to. Find-tuning that would decrease contention by an
> > insignificant amount ;)
>
> We need this for
> > +EXPORT_SYMBOL_GPL(gpio_set_debounce);
>
> nitlet: I suspect this function is taking gpio_lock sooner than it
> strictly needs to. Find-tuning that would decrease contention by an
> insignificant amount ;)
We need this for Intel MID boxes as well Andrew - so its a generic need.
Alan
--
To
Hi,
On Thu, May 20, 2010 at 11:06:00AM -0700, Andrew Morton wrote:
> nitlet: I suspect this function is taking gpio_lock sooner than it
> strictly needs to. Find-tuning that would decrease contention by an
> insignificant amount ;)
heh, I can post another version if you like, but this is pretty
On Mon, 17 May 2010 13:02:30 +0300
felipe.ba...@nokia.com wrote:
> From: Felipe Balbi
>
> Few architectures, like OMAP, allow you to set
> a debouncing time for the gpio before generating
> the IRQ. Teach gpiolib about that.
>
> ...
>
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.
From: Felipe Balbi
Few architectures, like OMAP, allow you to set
a debouncing time for the gpio before generating
the IRQ. Teach gpiolib about that.
Signed-off-by: Felipe Balbi
---
drivers/gpio/gpiolib.c | 43 +++
include/asm-generic/gpio.h |5
14 matches
Mail list logo
