[Linux-kernel-mentees] Any other ways to debug GPIO interrupt controller (pinctrl-amd) for broken touchpads of a new laptop model?

Coiby Xu coiby.xu at gmail.com
Fri Oct 30 04:58:39 UTC 2020

On Tue, Oct 27, 2020 at 11:52:14AM +0200, Andy Shevchenko wrote:
>On Tue, Oct 27, 2020 at 2:07 AM Coiby Xu <coiby.xu at gmail.com> wrote:
>> Hi Hans and Linus,
>> Will you interpret the 0x0000 value for debounce timeout in GPIO
>> Interrupt Connection Resource Descriptor as disabling debouncing
>> filter?
>> GpioInt (EdgeLevel, ActiveLevel, Shared, PinConfig, DebounceTimeout, ResourceSource,
>> ResourceSourceIndex, ResourceUsage, DescriptorName, VendorData) {PinList}
>According to the spec
>DebounceTimeout is an optional argument specifying the debounce wait
>time, in hundredths of
>milliseconds. The bit field name _DBT is automatically created to
>refer to this portion of the resource
>I interpret this as 0 == no debounce (or a minimum that hardware has
>if there is no possibility to disable).

Thanks for the explanation!
>> I'm not sure if Windows' implementation is the de facto standard like
>> i2c-hid. But if we are going to conform to the ACPI specs and we would
>> regard 0x0000 debounce timeout as disabling debouncing filter, then we
>> can fix this touchpad issue and potentially some related issues by
>> implementing the feature of supporting configuring debounce timeout in
>> drivers/gpio/gpiolib-acpi.c and removing all debounce filter
>> configuration in amd_gpio_irq_set_type of drivers/pinctrl/pinctrl-amd.c.
>> What do you think?
>> A favorable evidence is I've collected five DSDT tables when
>> investigating this issue. All 5 DSDT tables have an GpioInt specifying
>> an non-zero debounce timeout value for the edge type irq and for all
>> the level type irq, the debounce timeout is set to 0x0000.
>To the future mails: please, do not top-post.
>And please remove a huge amount of unrelated lines in the reply.
Thank you for the suggestion!
>With Best Regards,
>Andy Shevchenko

Best regards,

More information about the Linux-kernel-mentees mailing list