[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFwRZO30wf8GxQea@smile.fi.intel.com>
Date: Wed, 25 Jun 2025 18:10:28 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: "Limonciello, Mario" <Mario.Limonciello@....com>
Cc: Mario Limonciello <superm1@...nel.org>,
Hans de Goede <hansg@...nel.org>,
Mika Westerberg <westeri@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"open list:GPIO ACPI SUPPORT" <linux-gpio@...r.kernel.org>,
"open list:GPIO ACPI SUPPORT" <linux-acpi@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)..." <linux-input@...r.kernel.org>
Subject: Re: [PATCH 2/2] Revert "Input: soc_button_array - debounce the
buttons"
On Wed, Jun 25, 2025 at 03:02:18PM +0000, Limonciello, Mario wrote:
> On 6/25/25 9:41 AM, Mario Limonciello wrote:
> > On 6/25/25 9:31 AM, Hans de Goede wrote:
> >> On 25-Jun-25 4:09 PM, Mario Limonciello wrote:
> >>> On 6/25/25 4:09 AM, Hans de Goede wrote:
> >>>> On 24-Jun-25 10:22 PM, Mario Limonciello wrote:
...
> >> Ok, so specifically the gpiod_set_debounce() call with 50 ms
> >> done by gpio_keys.c is the problem I guess?
> >
> > Yep.
> >
> >> So amd_gpio_set_debounce() does accept the 50 ms debounce
> >> passed to it by gpio_keys.c as a valid value and then setting
> >> that breaks the wake from suspend?
> >
> > That's right.
> >>> Also comparing the GPIO register in Windows (where things work)
> >>> Windows never programs a debounce.
> >>
> >> So maybe the windows ACPI0011 driver always uses a software-
> >> debounce for the buttons? Windows not debouncing the mechanical
> >> switches at all seems unlikely.
> >>
> >> I think the best way to fix this might be to add a no-hw-debounce
> >> flag to the data passed from soc_button_array.c to gpio_keys.c
> >> and have gpio_keys.c not call gpiod_set_debounce() when the
> >> no-hw-debounce flag is set.
> >>
> >> I've checked and both on Bay Trail and Cherry Trail devices
> >> where soc_button_array is used a lot hw-debouncing is already
> >> unused. pinctrl-baytrail.c does not accept 50 ms as a valid
> >> value and pinctrl-cherryview.c does not support hw debounce
> >> at all.
> >
> > That sounds a like a generally good direction to me.
Thinking a bit more of this, perhaps the HW debounce support flag should be
per-GPIO-descriptor thingy. In such cases we don't need to distinguish the
platforms, the GPIO ACPI lib may simply set that flag based on 0 read from
the ACPI tables. It will also give a clue to any driver that uses GPIOs
(not only gpio-keys).
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists