[ 1.529468] tigerlake-pinctrl INT34C6:00: pin 267 cannot be used as IRQ [ 1.529471] genirq: Setting trigger mode 8 for irq 183 failed (intel_gpio_irq_type+0x0/0x130) [ 1.530890] gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction [ 1.530912] gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 416 for IRQ [ 1.530932] genirq: Failed to request resources for ELAN0755:00 (irq 183) on irqchip INT34C6:00 [ 1.530965] i2c_hid_acpi i2c-ELAN0755:00: Could not register for ELAN0755:00 interrupt, irq = 183, ret = -22 [ 1.531010] i2c_hid_acpi: probe of i2c-ELAN0755:00 failed with error -22 The issue happens because the driver doesn't pass intel_pad_acpi_mode() check. We asked OEM/ODM/BIOS vendor to "release" the GPP from BIOS to OS, but they don't quite understand what happened and need detailed instruction to fix it from BIOS.
Created attachment 297397 [details] dmesg
Any chance to have `acpidump -o tables.dat` on this platform to be attached here?
(In reply to Andy Shevchenko from comment #2) > Any chance to have `acpidump -o tables.dat` on this platform to be attached > here? Ah, and content of `/sys/kernel/debug/pinctrl/INT34C6:00/pins` file.
Created attachment 297405 [details] acpidump
Created attachment 297407 [details] debugfs pins
So, we are talking about this pin (according to logs in the report): pin 267 (PMCALERTB) 416:INT34C6:00 mode 1 0x04000702 0x00000056 0x00000000 [LOCKED full, ACPI] So, in the firmware they should have something like this GPIO_TGL_H_GPP_I0,GpioPadModeGpio,GpioHostOwnGpio,GpioDirIn,GpioOutDefault,GpioIntGpio,GpioIntLevel,GpioResetNormal,GpioTermNone,GpioLockDefault,GpioRxRaw1Default,0x00 According to the above the ownership is not a main issue here, the problem is that mode is not GPIO and pin configuration is fully locked down.
(In reply to Andy Shevchenko from comment #6) > According to the above the ownership is not a main issue here, the problem > is that mode is not GPIO and pin configuration is fully locked down. Another possibility that the BIOS hasn't properly configured Direct IRQ mode and provided rather Interrupt() resource instead of GpioInt().
FWIW ODM confirmed the setting works under Windows.
Created attachment 297451 [details] Debug patch for GPIO offsets Does the revert of the commit cb8cc18508fb ("pinctrl: tigerlake: Fix register offsets for TGL-H variant") affect this? If it does, please apply attached patch and resend `dmesg`.
Created attachment 297461 [details] dmesg with cb8cc18508fb reverted
Reverting cb8cc18508fb doesn't help. According to ODM, the platform is using GPP_K0 for the touchpad.
This is weird, because from the logs it's clearly about GPP_I0. Can you enable CONFIG_DEBUG_GPIO=y and CONFIG_DEBUG_PINCTRL=y and attach `dmesg`?
Created attachment 297527 [details] dmesg with debugs enabled
Thanks. It just confirms that pin in use is 416, which is GPP_I0 and locked by firmware. Windows may work because, e.g., they hard coded the numbers. This line tigerlake-pinctrl INT34C6:00: pin 267 cannot be used as IRQ is due to ACPI ownership of the pin, and this one gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction is due to mode is 1 (not GPIO, which is 0).
So is this a firmware bug?
Sounds like it's the case. The only patch that may messed up things you have checked already (as per comment #11).
It it possible to share the specific change required to fix the issue? ODM is totally lost...
I would love to help, but I'm not a firmware (BIOS) guy. Everything I knew I already shared in the above comments. Here I try to summarize what we have: 1) The pin in use seems GPP_I0, while ODM thinks it's GPP_K0 (AR: check with schematics). 2) In case the I0 is correct one, firmware is expected to program the ownership and lockdown bits accordingly. 3) The current ACPI table uses GpioInt() (so called "Legacy IRQ" mode of GPIO), it might be that in some cases the firmware wants to use "Direct IRQ" mode when it bypasses the GPIO driver in the OS (should be programmed by firmware in GPIO and IOxAPIC RTE). All above is information that driver expects from firmware to be supplied via ACPI tables and pre-programmed certain bits in GPIO address space. If above is done and we still have issues, then we need to be sure that driver has proper offsets for the special registers (see comment #11 and comment #16 for additional details). I'm closing it here, but feel free to open when firmware issues will be eliminated from the equation, or at lest be quite unlikely. Meanwhile I recommend them or you to contact to Intel representative who may give you a support on the firmware side.
Andy, thanks for your analysis!
*** This bug has been marked as a duplicate of bug 213579 ***