Bug 213463 - "tigerlake-pinctrl INT34C6:00: pin 267 cannot be used as IRQ" on TGL-H
Summary: "tigerlake-pinctrl INT34C6:00: pin 267 cannot be used as IRQ" on TGL-H
Status: RESOLVED DUPLICATE of bug 213579
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andy Shevchenko
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-16 12:30 UTC by Kai-Heng Feng
Modified: 2021-08-04 12:12 UTC (History)
3 users (show)

See Also:
Kernel Version: mainline, linux-next
Tree: Mainline
Regression: No


Attachments
dmesg (82.68 KB, text/plain)
2021-06-16 12:31 UTC, Kai-Heng Feng
Details
acpidump (2.44 MB, text/plain)
2021-06-16 13:18 UTC, Kai-Heng Feng
Details
debugfs pins (24.60 KB, text/plain)
2021-06-16 13:19 UTC, Kai-Heng Feng
Details
Debug patch for GPIO offsets (1.10 KB, patch)
2021-06-18 13:06 UTC, Andy Shevchenko
Details | Diff
dmesg with cb8cc18508fb reverted (79.86 KB, text/plain)
2021-06-18 16:36 UTC, Kai-Heng Feng
Details
dmesg with debugs enabled (105.71 KB, text/plain)
2021-06-21 06:26 UTC, Kai-Heng Feng
Details

Description Kai-Heng Feng 2021-06-16 12:30:41 UTC
[    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.
Comment 1 Kai-Heng Feng 2021-06-16 12:31:00 UTC
Created attachment 297397 [details]
dmesg
Comment 2 Andy Shevchenko 2021-06-16 13:05:33 UTC
Any chance to have `acpidump -o tables.dat` on this platform to be attached here?
Comment 3 Andy Shevchenko 2021-06-16 13:07:27 UTC
(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.
Comment 4 Kai-Heng Feng 2021-06-16 13:18:56 UTC
Created attachment 297405 [details]
acpidump
Comment 5 Kai-Heng Feng 2021-06-16 13:19:15 UTC
Created attachment 297407 [details]
debugfs pins
Comment 6 Andy Shevchenko 2021-06-16 15:13:43 UTC
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.
Comment 7 Andy Shevchenko 2021-06-16 15:15:16 UTC
(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().
Comment 8 Kai-Heng Feng 2021-06-18 07:43:14 UTC
FWIW ODM confirmed the setting works under Windows.
Comment 9 Andy Shevchenko 2021-06-18 13:06:09 UTC
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`.
Comment 10 Kai-Heng Feng 2021-06-18 16:36:27 UTC
Created attachment 297461 [details]
dmesg with cb8cc18508fb reverted
Comment 11 Kai-Heng Feng 2021-06-18 16:38:32 UTC
Reverting cb8cc18508fb doesn't help.

According to ODM, the platform is using GPP_K0 for the touchpad.
Comment 12 Andy Shevchenko 2021-06-18 17:50:53 UTC
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`?
Comment 13 Kai-Heng Feng 2021-06-21 06:26:42 UTC
Created attachment 297527 [details]
dmesg with debugs enabled
Comment 14 Andy Shevchenko 2021-06-21 10:39:51 UTC
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).
Comment 15 Kai-Heng Feng 2021-06-21 16:09:15 UTC
So is this a firmware bug?
Comment 16 Andy Shevchenko 2021-06-21 16:46:12 UTC
Sounds like it's the case. The only patch that may messed up things you have checked already (as per comment #11).
Comment 17 Kai-Heng Feng 2021-06-22 03:55:19 UTC
It it possible to share the specific change required to fix the issue? ODM is totally lost...
Comment 18 Andy Shevchenko 2021-06-22 09:19:21 UTC
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.
Comment 19 Kai-Heng Feng 2021-06-22 11:58:53 UTC
Andy, thanks for your analysis!
Comment 20 Andy Shevchenko 2021-08-04 12:12:12 UTC

*** This bug has been marked as a duplicate of bug 213579 ***

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