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:09:11AM +0100, Hans de Goede wrote:
>Hi,
>
...
>
>So I see 2 ways to move forward with his:
>
>1. Just disable the debounce filter for level type IRQs; or
>2. Add a helper to sanitize the debounce pulse-duration setting and
>   call that when setting the IRQ type.
>   This helper would read the setting check it is not crazy long for
>   an IRQ-line (lets say anything above 1 ms is crazy long) and if it
>   is crazy long then overwrite it with a saner value.
>
>2. is a bit tricky, because if the IRQ line comes from a chip then
>obviously max 1ms debouncing to catch eletrical interference should be
>fine. But sometimes cheap buttons for things like volume up/down on tablets
>are directly connected to GPIOs and then we may want longer debouncing...
>
>So if we do 2. we may want to limit it to only level type IRQs too.
>
>Note I have contacted AMD about this and asked them for some input on this,
>ideally they can tell us how exactly we should program the debounce filter
>and based on which data we should do that.

Is there any update from AMD? Based on the discussion, I'm going to
submit a patch to disable debounce filter for both level and edge
type IRQs, i.e. to remove relevant code in amd_gpio_irq_set_type of
drivers/pinctrl/pinctrl-amd.c since setting debounce filter is
orthogonal to setting irq type and Andy has submitted the patch to
support setting debounce setting supplied by ACPI in gpiolib-acpi.c

Btw, did you contact AMD through a representative? Obviously CC them
didn't get their attention. There is an inconsistency for configuring
debounce timeout in pinctrl-amd as was spotted by Andy [1]. I also need
their feedback for this matter.

[1] https://lore.kernel.org/patchwork/comment/1522675/
>
>Regards,
>
>Hans
>

--
Best regards,
Coiby