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

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Tue, Oct 27, 2020 at 2:07 AM Coiby Xu <coiby.xu@xxxxxxxxx> 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).

> 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.

-- 
With Best Regards,
Andy Shevchenko