On Mon, May 25, 2020 at 4:22 AM Kent Gibson <warthog...@gmail.com> wrote:
> You mention timers for the gpio pins that cannot provide debounce, > so I'm confused. Could you clarify which strategy you have in mind? My idea is that the callback gpiod_set_debounce() for in-kernel consumers should more or less always return success. Either the hardware does the debounce, or gpiolib sets up a timer. > I've also had a quick look at the possibility of providing the software > debounce for in-kernel consumers. That is where I think it should start. > Are you anticipating new API for > that? e.g. allowing consumers to request gpio events? Cos, gpio_keys > grabs the irq itself - and that would bypass the software debouncer, > or even conflict with it. It may be hard or impossible. I suppose gpiolib would have to steal or intercept the interrupt by using e.g. IRQF_SHARED and then just return IRQ_HANDLED on the first IRQ so the underlying irq handler does not get called. After the timer times out it needs to retrigger the IRQ. So the consuming driver would se a "debounced and ready" IRQ so when it gets this IRQ it knows for sure there is no bounciness on it because gpiolib already took care of that. The above is in no way trivial, but it follows the design pattern of "narrow and deep" APIs. Failure is an option! Sorry if I push too complex ideas. Yours, Linus Walleij
