On Tue, Oct 06, 2020 at 11:16:50AM +0200, Linus Walleij wrote:
On Tue, Oct 6, 2020 at 10:32 AM Coiby Xu <coiby.xu@xxxxxxxxx> wrote:
Disabling the glitch filter works like a charm! Other enthusiastic
Linux users who have been troubled by this issue for months would
also feel great to know this small tweaking could bring their
touchpad back to life:) Thank you!
Oh you found the bug :D
The credit should goes to Hans. Thanks to his expertise, only
one shot (disabling glitch filter) is needed. Thank you for
introducing him to me:)
$ git diff
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 9a760f5cd7ed..e786d779d6c8 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -463,7 +463,7 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF;
pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF);
- pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF;
+ /** pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF; */
irq_set_handler_locked(d, handle_level_irq);
break;
I will learn more about the glitch filter and the implementation of
pinctrl and see if I can disable glitch filter only for this touchpad.
Yes we certainly need a quirk for this of some kind, examine the ACPI
quirk infrastructure in drivers/gpio/gpiolib-acpi.c to see if you can use
that to handle this.
Thank you for pointing out where I should look at! A quirk is the only
foolproof way before we confirm the other two suggestions given by Hans.
Yours,
Linus Walleij
--
Best regards,
Coiby