Bug 213857 - ELAN1203 Touchpad not detected
Summary: ELAN1203 Touchpad not detected
Status: RESOLVED DUPLICATE of bug 213579
Alias: None
Product: Drivers
Classification: Unclassified
Component: I2C (show other bugs)
Hardware: Other Linux
: P1 high
Assignee: Drivers/I2C virtual user
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-25 23:25 UTC by Lovesh
Modified: 2021-08-04 15:38 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.12.5, 5.12.8, 5.12.11, 5.13.1, 5.13.4, 5.13.5, 5.13.6, 5.14-rc2, 5.14-rc3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
xinput (1.10 KB, text/plain)
2021-07-25 23:25 UTC, Lovesh
Details
lspci (2.42 KB, text/plain)
2021-07-25 23:25 UTC, Lovesh
Details
dmesg (91.67 KB, text/plain)
2021-07-25 23:26 UTC, Lovesh
Details
cat /proc/bus/input/devices (7.15 KB, text/plain)
2021-07-27 08:23 UTC, Lovesh
Details
Output of udevadm info --export-db (282.01 KB, text/plain)
2021-08-01 07:58 UTC, Lovesh
Details
Output of cat /proc/interrupts. I had a USB mouse connected. (16.49 KB, text/plain)
2021-08-01 09:50 UTC, Lovesh
Details
Output of cat /sys/kernel/debug/pinctrl/INT34C6:00/pins. Running kernel 5.14-rc3 (23.01 KB, text/plain)
2021-08-01 12:52 UTC, Lovesh
Details
Output of dmesg. Running kernel 5.14-rc3 (89.57 KB, text/plain)
2021-08-01 12:57 UTC, Lovesh
Details
Output of acpidump. (1.99 MB, text/plain)
2021-08-02 07:16 UTC, Lovesh
Details
Ouptut of cat /sys/kernel/debug/pinctrl/INT34C6:00/pins after patching kernel with a change to pin mapping (23.01 KB, text/plain)
2021-08-04 11:17 UTC, Lovesh
Details
Ouptut of dmesg after patching kernel with a change to pin mapping (87.74 KB, text/plain)
2021-08-04 11:19 UTC, Lovesh
Details

Description Lovesh 2021-07-25 23:25:07 UTC
Created attachment 298037 [details]
xinput

Machine: ASUS TUF F15 FX506HM_FX566HM laptop

OS: Kubuntu 21.04

BIOS: FX506HM.303

Touchpad info from file /sys/bus/i2c/devices/i2c-ELAN1203\:00/modalias
acpi:ELAN1203:PNP0C50:
Comment 1 Lovesh 2021-07-25 23:25:48 UTC
Created attachment 298039 [details]
lspci
Comment 2 Lovesh 2021-07-25 23:26:25 UTC
Created attachment 298041 [details]
dmesg
Comment 3 Lovesh 2021-07-25 23:27:27 UTC
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
Comment 4 Lovesh 2021-07-27 08:23:33 UTC
Created attachment 298067 [details]
cat /proc/bus/input/devices
Comment 5 Lovesh 2021-08-01 07:58:00 UTC
Created attachment 298135 [details]
Output of udevadm info --export-db
Comment 6 Hans de Goede 2021-08-01 09:04:24 UTC
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 ?
Comment 7 Lovesh 2021-08-01 09:50:54 UTC
Created attachment 298137 [details]
Output of cat /proc/interrupts. I had a USB mouse connected.
Comment 8 Lovesh 2021-08-01 09:51:43 UTC
(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?
Comment 9 Andy Shevchenko 2021-08-01 11:34:45 UTC
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).
Comment 10 Lovesh 2021-08-01 12:52:10 UTC
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).
Comment 11 Lovesh 2021-08-01 12:55:09 UTC
(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?
Comment 12 Lovesh 2021-08-01 12:57:20 UTC
Created attachment 298143 [details]
Output of dmesg. Running kernel 5.14-rc3
Comment 13 Lovesh 2021-08-01 12:57:56 UTC
(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.
Comment 14 Andy Shevchenko 2021-08-01 16:40:02 UTC
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.
Comment 15 Lovesh 2021-08-01 17:23:17 UTC
(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?
Comment 16 Andy Shevchenko 2021-08-01 17:49:53 UTC
(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! :-)
Comment 17 Lovesh 2021-08-01 19:14:17 UTC
I couldn't find anything reliable online. Will try to find it from the manufacturer or somewhere else. Thanks for your help on this.
Comment 18 Lovesh 2021-08-02 07:16:50 UTC
Created attachment 298147 [details]
Output of acpidump.
Comment 19 Lovesh 2021-08-02 07:24:37 UTC
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
Comment 20 Werner Sembach [TUXEDO] 2021-08-03 17:50:12 UTC
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
Comment 21 Andy Shevchenko 2021-08-03 18:05:34 UTC
(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.
Comment 22 Lovesh 2021-08-03 21:35:53 UTC
(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);
```
Comment 23 Werner Sembach [TUXEDO] 2021-08-04 09:05:15 UTC
(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.
Comment 24 Lovesh 2021-08-04 11:17:59 UTC
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
Comment 25 Lovesh 2021-08-04 11:19:16 UTC
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
Comment 26 Lovesh 2021-08-04 11:21:15 UTC
(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)
Comment 27 Andy Shevchenko 2021-08-04 12:12:36 UTC

*** This bug has been marked as a duplicate of bug 213579 ***
Comment 28 Werner Sembach [TUXEDO] 2021-08-04 15:37:02 UTC
(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
Comment 29 Werner Sembach [TUXEDO] 2021-08-04 15:38:06 UTC
with that patch you must ofcourse not use the if-hack I posted

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