Bug 213463

Summary:	"tigerlake-pinctrl INT34C6:00: pin 267 cannot be used as IRQ" on TGL-H
Product:	Drivers	Reporter:	Kai-Heng Feng (kai.heng.feng)
Component:	Other	Assignee:	Andy Shevchenko (andy.shevchenko)
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	andy.shevchenko, luhaosheng, mika.westerberg
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	mainline, linux-next	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg acpidump debugfs pins Debug patch for GPIO offsets dmesg with cb8cc18508fb reverted dmesg with debugs enabled

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 ***