Re: Any other ways to debug GPIO interrupt controller (pinctrl-amd) for broken touchpads of a new laptop model?

[Coiby Xu <coiby.xu@gmail.com>]

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@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
>descriptor.
>
>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,
Coiby