On Thu, Apr 01, 2010 at 07:42:50PM +0300, Felipe Balbi wrote: > On Thu, Apr 01, 2010 at 04:11:27PM +0300, Jani Nikula wrote: > > 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. > I think we could provide a generic software debouncing mechanism, sure, > but if the hardware supports it, why not using ? I tend to agree here, especially for GPIOs on slow buses like I2C or which may be used as wake sources. I guess ideally we want something like the LEDs do with blinking where we use the hardware feature if present and suitable but fall back on software emulation transparently if it's not available or can't be configured appropriately. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
