Bug 213857

Created attachment 298039 [details]
lspci

Created attachment 298041 [details]
dmesg

Error from dmesg

[ 0.861200] genirq: Setting trigger mode 8 for irq 167 failed (intel_gpio_irq_type+0x0/0x130)
[ 0.862657] tigerlake-pinctrl INT34C6:00: pin 226 cannot be used as IRQ
[ 0.862658] genirq: Setting trigger mode 8 for irq 167 failed (intel_gpio_irq_type+0x0/0x130)
[ 0.862688] i2c_hid_acpi i2c-ELAN1203:00: Could not register for ELAN1203:00 interrupt, irq = 167, ret = -1
[ 0.862712] i2c_hid_acpi: probe of i2c-ELAN1203:00 failed with error -1
[ 0.876848] i915 0000:00:02.0: [drm] VT-d active for gfx access

Created attachment 298067 [details]
cat /proc/bus/input/devices

Created attachment 298135 [details]
Output of udevadm info --export-db

I saw your comment on bug 207759.

This issue seems to be similar to the issue in bug 213579, let me add Andy to the Cc here.

Andy, this is another GPIO/pinctrl IRQ setup not working on Tiger Lake issue, can you take a look please ?

Created attachment 298137 [details]
Output of cat /proc/interrupts. I had a USB mouse connected.

(In reply to Hans de Goede from comment #6)
> I saw your comment on bug 207759.
> 
> This issue seems to be similar to the issue in bug 213579, let me add Andy
> to the Cc here.
> 
> Andy, this is another GPIO/pinctrl IRQ setup not working on Tiger Lake
> issue, can you take a look please ?

Hi Hans, Andy

Thanks for checking this. Any other information I should be attaching to this issue?

You need to provide `dmesg` output when kernel is compiled with PINCTRL and GPIO debug enabled (see bug #213579 comment #22). Besides that you need to provide the `cat /sys/kernel/debug/pinctrl/INT34C6:00/pins`. Ah, and you need to test this on the most recent available kernel (something like v5.14-rc4 as of tomorrow). In any case if you don't know which pin is correct (find a schematic) we may go too far and even break the hardware if unknown pin was changed.

Seems like Windows went crazy in the point of allowing the drivers to ignore the ACPI tables (to some extent, i.e. IRQ resource).

Created attachment 298141 [details]
Output of cat /sys/kernel/debug/pinctrl/INT34C6:00/pins. Running kernel 5.14-rc3

I downloaded kernel 5.14-rc3 using the mainline tool (https://github.com/bkw777/mainline).

(In reply to Andy Shevchenko from comment #9)
> You need to provide `dmesg` output when kernel is compiled with PINCTRL and
> GPIO debug enabled (see bug #213579 comment #22). Besides that you need to
> provide the `cat /sys/kernel/debug/pinctrl/INT34C6:00/pins`. Ah, and you
> need to test this on the most recent available kernel (something like
> v5.14-rc4 as of tomorrow). In any case if you don't know which pin is
> correct (find a schematic) we may go too far and even break the hardware if
> unknown pin was changed.
> 
> Seems like Windows went crazy in the point of allowing the drivers to ignore
> the ACPI tables (to some extent, i.e. IRQ resource).

Please see the previous comment where I attached the output. If I still need to compile, I have the following question:

I have never compiled linux before but I am compiling the current master (commit f3438b4c4e692b49b7dc2bab864d20381024be16). I am following this guide https://www.cyberciti.biz/tips/compiling-linux-kernel-26.html. It says to copy the output of /boot/config-$(uname -r) for creating the .config file. I have 5.14-rc3, can I copy that config and set CONFIG_DEBUG_PINCTRL=y and CONFIG_DEBUG_GPIO=y?

Created attachment 298143 [details]
Output of dmesg. Running kernel 5.14-rc3

(In reply to Lovesh from comment #11)
> (In reply to Andy Shevchenko from comment #9)
> > You need to provide `dmesg` output when kernel is compiled with PINCTRL and
> > GPIO debug enabled (see bug #213579 comment #22). Besides that you need to
> > provide the `cat /sys/kernel/debug/pinctrl/INT34C6:00/pins`. Ah, and you
> > need to test this on the most recent available kernel (something like
> > v5.14-rc4 as of tomorrow). In any case if you don't know which pin is
> > correct (find a schematic) we may go too far and even break the hardware if
> > unknown pin was changed.
> > 
> > Seems like Windows went crazy in the point of allowing the drivers to
> ignore
> > the ACPI tables (to some extent, i.e. IRQ resource).
> 
> Please see the previous comment where I attached the output. If I still need
> to compile, I have the following question:
> 
> I have never compiled linux before but I am compiling the current master
> (commit f3438b4c4e692b49b7dc2bab864d20381024be16). I am following this guide
> https://www.cyberciti.biz/tips/compiling-linux-kernel-26.html. It says to
> copy the output of /boot/config-$(uname -r) for creating the .config file. I
> have 5.14-rc3, can I copy that config and set CONFIG_DEBUG_PINCTRL=y and
> CONFIG_DEBUG_GPIO=y?

Had forgotten attaching the output of dmesg, now attached.

Thanks, the pin mentioned in the logs is owned by ACPI, so it can't generate GPIO interrupts (see bug #2135790 comment #18 for the details). Without schematics I can't help you further. On your own risk you may try the pins that are marked as GPIOs and without ACPI ownership.

(In reply to Andy Shevchenko from comment #14)
> Without schematics I can't help you further. 

What are schematics here? How can I get the schematics? Is there some info from BIOS or other places I can check to get the schematics?

> On your own risk you may try the pins
> that are marked as GPIOs and without ACPI ownership.

I am not familiar with hardware programming so I don't know what am I supposed to try.


In one of your previous comments, you mentioned that Windows allows the drivers to ignore the ACPI tables, what are the adverse effects of that, and can I do it on just my machine like changing some config or building the kernel in a certain way?

(In reply to Lovesh from comment #15)
> (In reply to Andy Shevchenko from comment #14)
> > Without schematics I can't help you further. 
> 
> What are schematics here? How can I get the schematics? Is there some info
> from BIOS or other places I can check to get the schematics?

Electrical connections between the components on the PCB (Printed Circuit Board) are depicted on the schematics. Without seeing it, or somebody, who knows for sure, telling us which pin is exactly being used as IRQ for the touch device, it's close to impossible to tell what is the root cause and how to fix it.

For some laptops it's possible to google for it, some sites are forums where people are actually selling them (for $5..$10).

The ideal option is to communicate with vendor of your hardware (laptop / BIOS) and ask them what should be the right pin for the touch device.

> > On your own risk you may try the pins
> > that are marked as GPIOs and without ACPI ownership.
> 
> I am not familiar with hardware programming so I don't know what am I
> supposed to try.

I'm talking about the change similar to mentioned in the bug #213579 comment #32. The pins to try in the body of if branch are the ones which are GPIOs without ACPI ownership.

> In one of your previous comments, you mentioned that Windows allows the
> drivers to ignore the ACPI tables, what are the adverse effects of that, and
> can I do it on just my machine like changing some config or building the
> kernel in a certain way?

The effect is your very bug report! :-)

I couldn't find anything reliable online. Will try to find it from the manufacturer or somewhere else. Thanks for your help on this.

Created attachment 298147 [details]
Output of acpidump.

Andy, I was checking bugs related to this pins issue, bug 213579 and bug 213463. The error code returned when the touchpad interrupt fails to register is -22 but in my case it's -1. Can that mean that my issue is different?


From bug 213579
> Jun 23 13:56:36 patacca-laptop kernel: i2c_hid_acpi i2c-ELAN0412:01: Could
> not register for ELAN0412:01 interrupt, irq = 148, ret = -22


From bug 213463
> [    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

But in my case
> [ 0.862688] i2c_hid_acpi i2c-ELAN1203:00: Could not register for ELAN1203:00
> interrupt, irq = 167, ret = -1
> [ 0.862712] i2c_hid_acpi: probe of i2c-ELAN1203:00 failed with error -1

Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
can you try this hack: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
if (pin == 328)
    pin = 424;
?
If the touchpad works then, this would fule the assumption from the first link that gpio values comming from the acpi need an offset of +0x60 (pin 226 on tigerlake is gpio 328 -> + 0x60 = 424

(In reply to wse from comment #20)
> Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
> can you try this hack:
> https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
> if (pin == 328)
>     pin = 424;
> ?
> If the touchpad works then, this would fule the assumption from the first
> link that gpio values comming from the acpi need an offset of +0x60 (pin 226
> on tigerlake is gpio 328 -> + 0x60 = 424

Some info about how it's done.

History lesson:
The M$ decided that each GPIO _bank_ (in terms of our driver it's called groups or GPP) must have 32 pins except the last one independently of the reality, i.e. how many pins are really in the HW (I terrifically hope that the award found the ingenious mind). So, that's why we have a completely virtual numbering of GPIOs in the Windows driver and ACPI (firmware) and Linux must follow (unfortunately).

Current situation:
The 0x60 is 3 banks offset. it may explain that the last minute change the groups were reshuffled in the virtual number space that Windows/BIOS are using. This also may be other way around, we got driver based on last minute changes that did not make the real firmware / Windows driver.

If all the above is correct then we have an issue in the driver which is easy to fix if you know what numbers should be there. I'm trying to escalate this internally to get it done.

(In reply to wse from comment #20)
> Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
> can you try this hack:
> https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
> if (pin == 328)
>     pin = 424;
> ?
> If the touchpad works then, this would fule the assumption from the first
> link that gpio values comming from the acpi need an offset of +0x60 (pin 226
> on tigerlake is gpio 328 -> + 0x60 = 424

To be sure, the if condition has to go before the last return statement of the function `acpi_get_gpiod` so it becomes 
```
static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
{
...
....
 if (pin == 328)
    pin = 424;
 return gpiochip_get_desc(chip, pin);
```

(In reply to Andy Shevchenko from comment #21)
> (In reply to wse from comment #20)
> > Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
> > can you try this hack:
> > https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
> > if (pin == 328)
> >     pin = 424;
> > ?
> > If the touchpad works then, this would fule the assumption from the first
> > link that gpio values comming from the acpi need an offset of +0x60 (pin
> 226
> > on tigerlake is gpio 328 -> + 0x60 = 424
> 
> Some info about how it's done.
> 
> History lesson:
> The M$ decided that each GPIO _bank_ (in terms of our driver it's called
> groups or GPP) must have 32 pins except the last one independently of the
> reality, i.e. how many pins are really in the HW (I terrifically hope that
> the award found the ingenious mind). So, that's why we have a completely
> virtual numbering of GPIOs in the Windows driver and ACPI (firmware) and
> Linux must follow (unfortunately).
> 
> Current situation:
> The 0x60 is 3 banks offset. it may explain that the last minute change the
> groups were reshuffled in the virtual number space that Windows/BIOS are
> using. This also may be other way around, we got driver based on last minute
> changes that did not make the real firmware / Windows driver.

Thanks for the clarification.

So this basically means we have to try +- different multiples of 32 when this issue arises.

This at least make workaround try and error feasable till it's properly fixed.

> If all the above is correct then we have an issue in the driver which is
> easy to fix if you know what numbers should be there. I'm trying to escalate
> this internally to get it done.

Thanks, hope it gets patched soon.

Created attachment 298185 [details]
Ouptut of cat /sys/kernel/debug/pinctrl/INT34C6:00/pins after patching kernel with a change to pin mapping

Kernel at commit d5ad8ec3cfb56a017de6a784835666475b4be349 was patched with change at suggested in https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20

Created attachment 298187 [details]
Ouptut of dmesg after patching kernel with a change to pin mapping

Kernel at commit d5ad8ec3cfb56a017de6a784835666475b4be349 was patched with change suggested in https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20

(In reply to wse from comment #20)
> Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
> can you try this hack:
> https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
> if (pin == 328)
>     pin = 424;
> ?
> If the touchpad works then, this would fule the assumption from the first
> link that gpio values comming from the acpi need an offset of +0x60 (pin 226
> on tigerlake is gpio 328 -> + 0x60 = 424

Tried this and the touchpad still isn't detected. Have attached the output of dmesg and /sys/kernel/debug/pinctrl/INT34C6:00/pins (previous 2 comments)

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

(In reply to Lovesh from comment #26)
> (In reply to wse from comment #20)
> > Comming from: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c50 ,
> > can you try this hack:
> > https://bugzilla.kernel.org/show_bug.cgi?id=213579#c29 , but with:
> > if (pin == 328)
> >     pin = 424;
> > ?
> > If the touchpad works then, this would fule the assumption from the first
> > link that gpio values comming from the acpi need an offset of +0x60 (pin
> 226
> > on tigerlake is gpio 328 -> + 0x60 = 424
> 
> Tried this and the touchpad still isn't detected. Have attached the output
> of dmesg and /sys/kernel/debug/pinctrl/INT34C6:00/pins (previous 2 comments)

Andy Shevchenko created a real fix: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c56

Should fix the issue

with that patch you must ofcourse not use the if-hack I posted