On Thu, Apr 01, 2010 at 04:11:27PM +0300, Jani Nikula wrote: > On Thu, Apr 1, 2010 at 12:32, Felipe Balbi <[email protected]> wrote: > > On Thu, Apr 01, 2010 at 11:29:16AM +0200, ext Grazvydas Ignotas wrote: > >> > >> There is also an issue if somebody calls _set_gpio_debounce(bank, 1, > >> 310) and _set_gpio_debounce(bank, 2, 620), the second call will > >> override debounce setting of GPIO1 (as it's shared by the whole bank). > >> This might be not what the user intended, would be useful to detect > >> this and warn the user. > > > > good point. As this is RFC, I'll wait until everybody comments. > > Hi Felipe - > > You might want to have a look at [1] on irq debouncing. The hardware > support for debouncing varies (bank/gpio restrictions, debounce > timeouts, no support at all, what else?) so how can the users of this > interface rely on debouncing? What are the guarantees? AFAICS e.g. > gpio-keys would have to do software debouncing anyway. > > [1] http://lkml.org/lkml/2008/9/24/325
I think we could provide a generic software debouncing mechanism, sure, but if the hardware supports it, why not using ? I believe Dave's approach is really good, this is just another way to do it. The difference with this patch is that we have control over the debouncing time. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
