Prev: teach gpiolib about gpio debouncing
Next: ipc: use shifts to extract seq/idx
From: David Brownell on 21 May 2010 09:20



--- On Fri, 5/21/10, Alan Cox <alan(a)lxorguk.ukuu.org.uk> 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 certain ports is fine. The platform vendor will
> have made
> sure they relevant ports have suitable debounce
> facilities.

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 sensitive to whether or
not the capability was available ... and moreover, whether the
debounce scale was adequate to compensate the contact chatter.
When not, then software debounce was inescapable.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on 21 May 2010 09:30

> > 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 debounce method would suffice when gpiolib is
in use (vs direct implementation of the API provided by gpiolib).


> or fallback to
> software emulation if chosen by the user.

ISTR that if you look back to the original discussion about
GPIO debouncing, you will find such a software implementation;
and maybe such an integration ...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 21 May 2010 09:30
> 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 sensitive to whether or
> not the capability was available ... and moreover, whether the
> debounce scale was adequate to compensate the contact chatter.
> When not, then software debounce was inescapable.

And someone who needs it can contribute it. The proposed patch causes no
problems in this area.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3
Prev: teach gpiolib about gpio debouncing
Next: ipc: use shifts to extract seq/idx