Bug 215664 - Discrepancy between ACPI DebounceTimeout and Intel Pinctrl driver
Summary: Discrepancy between ACPI DebounceTimeout and Intel Pinctrl driver
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: GPIO/Pin Control (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andy Shevchenko
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-07 04:16 UTC by Kai-Heng Feng
Modified: 2024-09-11 16:28 UTC (History)
3 users (show)

See Also:
Kernel Version: mainline, linux-next
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (92.61 KB, text/plain)
2022-03-07 04:16 UTC, Kai-Heng Feng
Details
acpidump (2.75 MB, text/plain)
2022-03-07 04:16 UTC, Kai-Heng Feng
Details

Description Kai-Heng Feng 2022-03-07 04:16:08 UTC
Cirrus codec amplifier doesn't work:
[    4.695135] Serial bus multi instantiate pseudo device driver CSC3551:00: error -EINVAL: Error requesting irq at index 0: -22
[    4.696659] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -22

Cirrus folks identified the root cause is that the debounce unit between ACPI and Intel pinctrl driver are different.

ACPI spec [1] states "DebounceTimeout is an optional argument specifying the hardware debounce wait time, in hundredths of milliseconds. The bit field name _DBT is automatically created to refer to this portion of the resource descriptor."

However, intel_config_set_debounce() is using "debounce * NSEC_PER_USEC / DEBOUNCE_PERIOD_NSEC". To match the value with ACPI, NSEC_PER_USEC should be 10 * NSEC_PER_USEC instead.

[1] https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#gpioio-gpio-connection-io-resource-descriptor-macro
Comment 1 Kai-Heng Feng 2022-03-07 04:16:29 UTC
Created attachment 300541 [details]
dmesg
Comment 2 Kai-Heng Feng 2022-03-07 04:16:47 UTC
Created attachment 300542 [details]
acpidump
Comment 3 Andy Shevchenko 2022-03-07 10:39:46 UTC
Thanks for the report! Lemme check this and come up with something.
Comment 4 Andy Shevchenko 2022-03-07 11:31:46 UTC
Hans, this might explain why debounce setting wasn't working for you (I don't remember the details, though).
Comment 5 Hans de Goede 2022-03-07 11:45:19 UTC
(In reply to Andy Shevchenko from comment #4)
> Hans, this might explain why debounce setting wasn't working for you (I
> don't remember the details, though).

My issue was on Bay Trail, which has the issue of there being a single debounce timeout for all pins in a single GPIO island. Since this is about the new laptops with Cirrus Logic amplifiers directly exposed to the OS, this is likely Tiger Lake, or maybe even Alder Lake.

As discussed on the list the plan is to just disable setting the debounce timeout on Bay Trail since there is no way to get it to work and it has not even been hooked up for most of Bay Trail's life-cycle, so clearly not having support for it is not an issue, also see: https://lore.kernel.org/linux-gpio/051a9e42-02e3-4db0-bdbd-f8d7855b5db0@redhat.com/
Comment 6 Andy Shevchenko 2022-03-07 13:33:59 UTC
The fix has been submitted:

https://lore.kernel.org/linux-gpio/CAAd53p6UvOqGkhGuwtZ0hvEAQFb4DR-RUd7R1uZuR+Duhf72EQ@mail.gmail.com/T/#u

P.S. Hans, thank you for clarifications!

Note You need to log in before you can comment on or make changes to this bug.