[OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: read initial state

[Linus Walleij]

On Mon, Jun 17, 2019 at 7:56 PM David Bauer <mail at david-bauer.net> wrote:

> Thanks for your suggestion. However, with your suggestion i still see the ghost press on bootup :(
> Just to clarify - I do not see multiple ghost presses, just one. The button is active low.
>
> After configuring the GPIO direction to input, the value of the GPIO reads 0 (pressed).
> After ~10ms, this changes to 1 (not pressed). I suppose your proposed solution does not work
> as interrupts are only registered after configuring the GPIO line as input and the GPIO line
> changes after registering the interrupt. So we are reading the interrupt state too early.

Hm this sounds like something that would be solved by debouncing.
It might even be a bounce effect of sorts, it can be a capacitance
or something in the mechanics causing this.

If you look in:
drivers/input/keyboard/gpio_keys.c
you will see that GPIO keys in the input subsystem has debouncing
support. I guess something like this needs to be copied over to
the OpenWrt netlink thingie.

If the GPIO driver supports debounce (some do, it doesn't look like
the ath79 does) that can be utilized. If someone can double-check
the ath79 datasheet to check if it can do debounce that'd be great
because it would solve this in hardware.

> If delays are allowed there, we could add a 20ms delay when configuring the GPIO line
> direction as input. This way we could also assure the line is stable for "normal" value
> reads. We would need to override the direction_input method provided by gpio-mmio for this.

That's like an initial debounce.

> Second:
> We could store the kernel uptime together with the GPIO line and for how long interrupts
> should be ignored within the driver. This could be checked when an interrupt is fired.

The third alternative is common software debounce. I.e. wait for any
value to stabilize before reporting keys. Some extra interrupts more
or less doesn't matter, we just frame it with some timer.

> I do not really like the second idea as dropping interrupts without feedback is probably not
> what we want.

I think it makes a lot of sense on mechanical pushbuttons to
implement generic debounce.

Yours,
Linus Walleij

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel