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