Bug 213579

The touchpad is unresponsive after boot.

In the logs I found these interesting lines:

```
Jun 23 13:56:36 patacca-laptop kernel: tigerlake-pinctrl INT34C6:00: pin 57 cannot be used as IRQ
Jun 23 13:56:36 patacca-laptop kernel: genirq: Setting trigger mode 8 for irq 148 failed (intel_gpio_irq_type+0x0/0x140)
Jun 23 13:56:36 patacca-laptop kernel: gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction
Jun 23 13:56:36 patacca-laptop kernel: gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 44 for IRQ
Jun 23 13:56:36 patacca-laptop kernel: genirq: Failed to request resources for ELAN0412:01 (irq 148) on irqchip INT34C6:00
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
```

Created attachment 297603 [details]
Logs

Created attachment 297605 [details]
pincntrl-pins

pincntrl pins

Created attachment 297607 [details]
pincntrl-gpio-ranges

pincntrl gpio-ranges

Created attachment 297609 [details]
DSDT

Similar bug #211957 (on FYI basis).

Created attachment 297749 [details]
/proc/interrupts

Thank you Andy for the link.
I don't think it's the same issue though. If you could guide me in diagnosing the issue it would be very nice.

Created attachment 297751 [details]
acpidump

Created attachment 297981 [details]
clevo.nh58hp.dmesg.log

Also seeing this on

5.11.0-7260-generic
Clevo NH58HP


```
[    3.291272] tigerlake-pinctrl INT34C6:00: pin 57 cannot be used as IRQ
[    3.291273] genirq: Setting trigger mode 8 for irq 150 failed (intel_gpio_irq_type+0x0/0x130)
[    3.291539] i2c_hid i2c-ELAN0412:01: supply vdd not found, using dummy regulator
[    3.291553] i2c_hid i2c-ELAN0412:01: supply vddl not found, using dummy regulator
[    3.295833] gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction
[    3.295835] gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 44 for IRQ
[    3.295836] genirq: Failed to request resources for ELAN0412:01 (irq 150) on irqchip INT34C6:00
[    3.295844] i2c_hid i2c-ELAN0412:01: Could not register for ELAN0412:01 interrupt, irq = 150, ret = -22
[    3.295893] i2c_hid: probe of i2c-ELAN0412:01 failed with error -22
[    3.296170] nvme nvme0: 16/0/0 default/read/poll queues
[    3.297349] checking generic (4000000000 7e9000) vs hw (6204000000 1000000)
[    3.297351] checking generic (4000000000 7e9000) vs hw (4000000000 10000000)
[    3.297352] fb0: switching to inteldrmfb from EFI VGA
[    3.297392] i915 0000:00:02.0: vgaarb: deactivate vga console
[    3.298228] ------------[ cut here ]------------
[    3.298228] Missing case (val == 65535)
[    3.298237] WARNING: CPU: 15 PID: 259 at drivers/gpu/drm/i915/intel_dram.c:96 skl_dram_get_dimm_info+0x79/0x1b0 [i915]
[    3.298282] Modules linked in: i915(+) nvme ahci nvme_core libahci i2c_algo_bit drm_kms_helper crct10dif_pclmul crc32_pclmul syscopyarea ghash_clmulni_intel sysfillrect aesni_intel sysimgblt fb_sys_fops crypto_simd cec cryptd rc_core glue_helper psmouse intel_lpss_pci(+) sdhci_pci i2c_i801 intel_lpss r8169 i2c_hid drm cqhci xhci_pci idma64 i2c_smbus sdhci realtek virt_dma vmd xhci_pci_renesas intel_pmt hid wmi video fjes(-) pinctrl_tigerlake
[    3.298298] CPU: 15 PID: 259 Comm: systemd-udevd Tainted: G        W         5.11.0-7620-generic #21~1624379747~21.04~3abeff8-Ubuntu
[    3.298300] Hardware name: Notebook NH5x_NH7xHP/NH5x_NH7xHP, BIOS 1.07.03LS1 06/15/2021
[    3.298301] RIP: 0010:skl_dram_get_dimm_info+0x79/0x1b0 [i915]
[    3.298336] Code: 0f 84 34 01 00 00 41 f7 c0 00 01 00 00 0f 84 27 01 00 00 41 0f b7 d0 48 c7 c6 51 33 9d c0 48 c7 c7 55 33 9d c0 e8 84 0d 1c d4 <0f> 0b 44 0f b7 0b b9 01 00 00 00 31 c0 31 f6 88 43 02 41 c1 ff 09
[    3.298337] RSP: 0018:ffffa8aa01617980 EFLAGS: 00010282
[    3.298339] RAX: 0000000000000000 RBX: ffffa8aa016179ec RCX: ffffffff95b23528
[    3.298340] RDX: c0000000ffffdfff RSI: 0000000000000000 RDI: 0000000000000247
[    3.298341] RBP: ffffa8aa016179a8 R08: 0000000000000000 R09: ffffa8aa01617760
[    3.298342] R10: ffffa8aa01617758 R11: ffffffff95b53568 R12: 0000000000000000
[    3.298342] R13: 000000000000004c R14: ffff967616520000 R15: 000000000000ffff
[    3.298343] FS:  00007f94404d78c0(0000) GS:ffff96853f7c0000(0000) knlGS:0000000000000000
[    3.298344] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.298345] CR2: 00007f9440b34000 CR3: 0000000116e4a002 CR4: 0000000000770ee0
[    3.298346] PKRU: 55555554
[    3.298346] Call Trace:
[    3.298348]  skl_dram_get_channel_info+0x2e/0x150 [i915]
[    3.298379]  skl_dram_get_channels_info+0x6e/0x190 [i915]
[    3.298407]  skl_get_dram_info+0x6e/0x100 [i915]
[    3.298434]  intel_dram_detect+0x3e/0xd0 [i915]
[    3.298459]  i915_driver_hw_probe+0x1cc/0x210 [i915]
[    3.298491]  i915_driver_probe+0xe5/0x2f0 [i915]
[    3.298521]  ? mutex_lock+0x13/0x40
[    3.298524]  ? acpi_dev_found+0x66/0x70
[    3.298528]  i915_pci_probe+0x58/0x140 [i915]
[    3.298557]  local_pci_probe+0x48/0x80
[    3.298559]  pci_call_probe+0x53/0xf0
[    3.298560]  pci_device_probe+0xad/0xf0
[    3.298561]  really_probe+0xff/0x460
[    3.298564]  driver_probe_device+0xe9/0x160
[    3.298565]  device_driver_attach+0xab/0xb0
[    3.298567]  __driver_attach+0x8f/0x150
[    3.298568]  ? device_driver_attach+0xb0/0xb0
[    3.298569]  bus_for_each_dev+0x7e/0xc0
[    3.298570]  driver_attach+0x1e/0x20
[    3.298572]  bus_add_driver+0x135/0x1f0
[    3.298573]  driver_register+0x95/0xf0
[    3.298574]  __pci_register_driver+0x54/0x60
[    3.298575]  i915_init+0x66/0x81 [i915]
[    3.298617]  ? 0xffffffffc0a53000
[    3.298619]  do_one_initcall+0x48/0x1d0
[    3.298622]  ? kmem_cache_alloc_trace+0xf6/0x200
[    3.298626]  ? do_init_module+0x28/0x290
[    3.298629]  do_init_module+0x62/0x290
[    3.298630]  load_module+0x6fd/0x780
[    3.298631]  __do_sys_finit_module+0xc2/0x120
[    3.298633]  __x64_sys_finit_module+0x1a/0x20
[    3.298634]  do_syscall_64+0x38/0x90
[    3.298636]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    3.298637] RIP: 0033:0x7f944098ff6d
[    3.298638] Code: 28 0d 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb de 0c 00 f7 d8 64 89 01 48
[    3.298639] RSP: 002b:00007ffd39f865e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    3.298641] RAX: ffffffffffffffda RBX: 000055bb4ec1ed10 RCX: 00007f944098ff6d
[    3.298641] RDX: 0000000000000000 RSI: 00007f9440b35e2d RDI: 0000000000000014
[    3.298643] RBP: 0000000000020000 R08: 0000000000000000 R09: 000055bb4dd7e8dd
[    3.298643] R10: 0000000000000014 R11: 0000000000000246 R12: 00007f9440b35e2d
[    3.298644] R13: 0000000000000000 R14: 000055bb4ec09450 R15: 000055bb4ec1ed10
[    3.298645] ---[ end trace 21d2b392d3814981 ]---
```

In both cases it's about this pin

pin 57 (SLP_S0B) 44:INT34C6:00 mode 1 0x44000700 0x00000051 0x00000000 [LOCKED full, ACPI]

The 'ACPI' marker makes it impossible to the driver to use as IRQ and on top of that the pin is in a wrong mode and locked which makes impossible to do anything about this on the driver side. There are few possibilities of the root cause of this (Cc'ed also to Mark from Lenovo):
1. Bug in firmware:
  a) wrong pin number;
  b) wrong pin configuration;
  c) wrong ASL code that makes 1a) to happen;
  d) combination of aboves.
2. Bug in the driver. The only possibility so far is the broken offsets for LOCK and/or PADOWN register sets, but the only possible commit that may affect this, i.e. cb8cc18508fb ("pinctrl: tigerlake: Fix register offsets for TGL-H variant"),  has been discussed in the bug #213463 comment #9 (also useful to read the entire discussion) and not confirmed to be a culprit.

So, to me it sounds quite likely that the issue is on firmware side. But I'm all ears for the information that may help to eliminate it from the equation.

Also seen on Clevo NH77HJ

[  +0.000242] idma64 idma64.0: Found Intel integrated DMA 64-bit
[  +0.003073] tigerlake-pinctrl INT34C6:00: pin 57 cannot be used as IRQ
[  +0.000002] genirq: Setting trigger mode 8 for irq 140 failed (intel_gpio_irq_type+0x0/0x140)
[  +0.001386] libphy: r8169: probed
[  +0.000140] r8169 0000:02:00.0 eth0: RTL8168h/8111h, 80:fa:5b:97:31:f8, XID 541, IRQ 141
[  +0.000003] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[  +0.000421] gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction
[  +0.000003] gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 44 for IRQ
[  +0.000001] genirq: Failed to request resources for ELAN0412:01 (irq 140) on irqchip INT34C6:00
[  +0.000023] i2c_hid_acpi i2c-ELAN0412:01: Could not register for ELAN0412:01 interrupt, irq = 140, ret = -22
[  +0.000042] i2c_hid_acpi: probe of i2c-ELAN0412:01 failed with error -22
[  +0.011757] random: crng init done
[  +0.000003] random: 3 urandom warning(s) missed due to ratelimiting

Tried on these kernels but no joy:

5.10.49-1
5.12.16-1
5.14.rc1.d0711.ge73f0f0-1

Are we doomed if no BIOS update is available or can this be worked around?

This isn't an issue related only to Clevo laptop though, see the dmesg logs for this MSI with AMI BIOS https://linux-hardware.org/?probe=3f205f2881

I can also confirm that it works on Windows, can we get at least a workaround?

(In reply to Rod Thomas from comment #13)
> Are we doomed if no BIOS update is available or can this be worked around?
If it will be evident that there is no driver bug (see above mentioned bug #213463 comment #9 for the details), then yes. OS may not affect this in any way on any of the levels of the access available.

Mark, any comment from Lenovo?

(In reply to Riccardo Mori from comment #14)
> This isn't an issue related only to Clevo laptop though, see the dmesg logs
> for this MSI with AMI BIOS https://linux-hardware.org/?probe=3f205f2881
> 
> I can also confirm that it works on Windows, can we get at least a
> workaround?

If there is no bug in the GPIO driver, from its perspective there is nothing we can do. Period.

Perhaps it's possible to work around via I²C HID driver or so.

Another affected device to add to the list: Tongfang GMxTGxx Barebone based laptops.

Here however the pin is not LOCKED full, but only ACPI:

pin 57 (SLP_S0B) 44:INT34C6:00 mode 1 0x84000500 0x00000051 0x00000000 [ACPI]

Running Ubuntu, but with 5.14-rc2 mainline kernel from here: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14-rc2/

Citing the hardware level documentation:

"Each GPIO pad ownership assignment is pre-determined via OEM system configuration through BIOS, soft strap and/or embedded subsystems’ firmware settings with corresponding pin list documentation.

...

In summary the pad ownership bit is used to determine:
   GPIO input event notification/status update to the subsystem owning the pad
    o setting of Host’s various interrupt status bits
    ...
  ...

PAD Ownership (PAD_OWN)
This register can be written by [Firmware] only.

...

00 = Host software (ACPI Mode or GPIO Driver Mode) has ownership of the pad. In Host GPIO Driver Mode (refer to HOSTSW_OWN), GPIO input event update is limited to GPI_STS update only. While in Host ACPI Mode, updates are limited to GPI_GPE_STS, GPI_NMI_STS and/or GPI_SMI_STS."

Sorry, but OEM has to fix this. I love to know how Windows works around this. If anybody has that information, please share.

(In reply to wse from comment #17)
> pin 57 (SLP_S0B) 44:INT34C6:00 mode 1 0x84000500 0x00000051 0x00000000 [ACPI]

What I'm wondering is if the pin list is broken and actual pin 57 is something else (+- few pins according to the current driver). May be someone can install libgpiod tools (such as `gpiomon`) and run with pins that are already in GPIO mode without [ACPI] bit set. Something like `gpiomon gpiochip0 43` (for pin #56) and `gpiomon gpiochip0 47` (for pin #60). Then if touchpad (when being touched I presume) generates the interrupts this will show them. But it's unlikely as 
per success story described in the bug #211957 where pin under question has much higher number and any pin list disturbance will be noticed immediately.

(In reply to Andy Shevchenko from comment #19)
> What I'm wondering is if the pin list is broken and actual pin 57 is
> something else (+- few pins according to the current driver). May be someone
> can install libgpiod tools (such as `gpiomon`) and run with pins that are
> already in GPIO mode without [ACPI] bit set. Something like `gpiomon
> gpiochip0 43` (for pin #56) and `gpiomon gpiochip0 47` (for pin #60). Then
> if touchpad (when being touched I presume) generates the interrupts this
> will show them. But it's unlikely as 
> per success story described in the bug #211957 where pin under question has
> much higher number and any pin list disturbance will be noticed immediately.


Thank you for helping us Andy.
I tried `gpiomon gpiochip0 $PIN` with the non-ACPI pins numbered from 15 up to 100 but unfortunately I didn't get any output.

(In reply to Riccardo Mori from comment #20)
> (In reply to Andy Shevchenko from comment #19)
> > What I'm wondering is if the pin list is broken and actual pin 57 is
> > something else (+- few pins according to the current driver). May be
> someone
> > can install libgpiod tools (such as `gpiomon`) and run with pins that are
> > already in GPIO mode without [ACPI] bit set. Something like `gpiomon
> > gpiochip0 43` (for pin #56) and `gpiomon gpiochip0 47` (for pin #60). Then
> > if touchpad (when being touched I presume) generates the interrupts this
> > will show them. But it's unlikely as 
> > per success story described in the bug #211957 where pin under question has
> > much higher number and any pin list disturbance will be noticed
> immediately.
> 
> 
> Thank you for helping us Andy.
> I tried `gpiomon gpiochip0 $PIN` with the non-ACPI pins numbered from 15 up
> to 100 but unfortunately I didn't get any output.

Maybe it's a typo in the firmware and it actually should be 157 or 257

Other interrupt related bug reports found with other touchpads, always had interrupt pins in the 2xx range

Created attachment 297983 [details]
dmesg

This is the dmesg output with the latest kernel 5.14.0-rc2 with the commit cb8cc18508fb0cad74929ffd080bebafe91609e2 "pinctrl: tigerlake: Fix register offsets for TGL-H variant" reverted and CONFIG_DEBUG_PINCTRL=y and CONFIG_DEBUG_GPIO=y.

The issue is still present

(In reply to Riccardo Mori from comment #22)

> This is the dmesg output with the latest kernel 5.14.0-rc2 with the commit
> cb8cc18508fb0cad74929ffd080bebafe91609e2 "pinctrl: tigerlake: Fix register
> offsets for TGL-H variant" reverted and CONFIG_DEBUG_PINCTRL=y and
> CONFIG_DEBUG_GPIO=y.
> 
> The issue is still present

...which effectively confirms that this fix isn't a culprit and according to our internal documentation has to be exist. In turn this more and more bending towards the firmware issue. Thanks for testing, by the way!

(In reply to wse from comment #21)
> (In reply to Riccardo Mori from comment #20)
> > (In reply to Andy Shevchenko from comment #19)
> > > What I'm wondering is if the pin list is broken and actual pin 57 is
> > > something else (+- few pins according to the current driver). May be
> > someone
> > > can install libgpiod tools (such as `gpiomon`) and run with pins that are
> > > already in GPIO mode without [ACPI] bit set. Something like `gpiomon
> > > gpiochip0 43` (for pin #56) and `gpiomon gpiochip0 47` (for pin #60).
> Then
> > > if touchpad (when being touched I presume) generates the interrupts this
> > > will show them. But it's unlikely as 
> > > per success story described in the bug #211957 where pin under question
> has
> > > much higher number and any pin list disturbance will be noticed
> > immediately.
> > 
> > 
> > Thank you for helping us Andy.
> > I tried `gpiomon gpiochip0 $PIN` with the non-ACPI pins numbered from 15 up
> > to 100 but unfortunately I didn't get any output.
> 
> Maybe it's a typo in the firmware and it actually should be 157 or 257
> 
> Other interrupt related bug reports found with other touchpads, always had
> interrupt pins in the 2xx range

I tested available pins between 200 and 300 with no avail ..

Did i get it right that this are the actuall physical pins on the bottom of the cpu?

Does anyone have a schematic for a device available where this issue arises?

So we could check where the physical connections between the touchpad controller and the cpu soc terminate.

(In reply to wse from comment #21)
> (In reply to Riccardo Mori from comment #20)

> Maybe it's a typo in the firmware and it actually should be 157 or 257
> 
> Other interrupt related bug reports found with other touchpads, always had
> interrupt pins in the 2xx range

It's solely depends to the PCB design. Without schematics it's hard to say. And no, we (our team of developers) do not possess any schematics for this OEM specific hardware.

(In reply to wse from comment #25)
> Did i get it right that this are the actuall physical pins on the bottom of
> the cpu?

Nope. Pins are actually pads on the die which may or may not be connected to the bumps. So, some of them are traced out some of them are internal for in-SoC devices.

> Does anyone have a schematic for a device available where this issue arises?

Extremely good question!

> So we could check where the physical connections between the touchpad
> controller and the cpu soc terminate.

Exactly my point in a comment above.

I found a schematic for the Clevo NH5xHP

According to that the touchpad is connected with 3 wires to the EC and with 3 wires to the CPU (and to vcc and gnd ofc):

TP_CLK -> GPF4/PS2CLK2/5VT (EC)
TP_DATA -> GPF5/PS2DAT2/5VT (EC)
TP_I2C_CLK -> BD21 -> GPP_C17/I2C0_SCL
TP_I2C_DAT -> BC22 -> GPP_C16/I2C0_SDA
LID_SW# -> GPB1/LID_SW# (EC)
TP_ATTN# -> BC48 -> GPP_R12/CLKOUT_48

Looking at https://elixir.bootlin.com/linux/v5.13/source/drivers/pinctrl/intel/pinctrl-tigerlake.c the CPU pins are:
PINCTRL_PIN(37, "CLKOUT_48"),
PINCTRL_PIN(121, "I2C0_SDA"),
PINCTRL_PIN(122, "I2C0_SCL"),

I hope this information helps.

(In reply to wse from comment #28)
> I found a schematic for the Clevo NH5xHP
> 
> According to that the touchpad is connected with 3 wires to the EC and with
> 3 wires to the CPU (and to vcc and gnd ofc):
> 
> TP_CLK -> GPF4/PS2CLK2/5VT (EC)
> TP_DATA -> GPF5/PS2DAT2/5VT (EC)
> TP_I2C_CLK -> BD21 -> GPP_C17/I2C0_SCL
> TP_I2C_DAT -> BC22 -> GPP_C16/I2C0_SDA
> LID_SW# -> GPB1/LID_SW# (EC)
> TP_ATTN# -> BC48 -> GPP_R12/CLKOUT_48
> 
> Looking at
> https://elixir.bootlin.com/linux/v5.13/source/drivers/pinctrl/intel/pinctrl-
> tigerlake.c the CPU pins are:
> PINCTRL_PIN(37, "CLKOUT_48"),
> PINCTRL_PIN(121, "I2C0_SDA"),
> PINCTRL_PIN(122, "I2C0_SCL"),
> 
> I hope this information helps.

Assuming that ATTN# pin is the one that has to be used as IRQ (anybody to look into TouchPad datasheet?) and the schematic is correct, the pin should be 37 and not 57 (seems like a typo in the BIOS code, typographically 3 and 5 are close enough).

To test this theory (and it sounds plausible because pin is in GPIO mode and with out ACPI flag set) one can try to hack the kernel here [1] by doing something like this:

  /* HACK! HACK! HACK! */
  if (pin == 57)
    pin = 37;

[1]: https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib-acpi.c#L127

I am going to test it soon

Created attachment 297989 [details]
dmesg

Unfortunately even after the hack it is still trying to use pin 57

(In reply to Riccardo Mori from comment #31)
> Created attachment 297989 [details]
> dmesg
> 
> Unfortunately even after the hack it is still trying to use pin 57

Are you sure you boot the kernel with the patch?

The call graph is

  i2c_acpi_get_irq() ->
    acpi_dev_gpio_irq_get_by() ->
      ...
      acpi_populate_gpio_lookup() ->
        acpi_get_gpiod()

Ah, okay, the pin there is actually GPIO #, so perhaps changing pair to be 

  if (pin == 44)
    pin = 140

?

Created attachment 297991 [details]
dmesg working

Ok, with the map from pin 44 to pin 140 it is indeed working
So the issue is actually a wrong pin number.
At least now we have a workaround for this.

Thank you very much to everyone that helped.

Yes, that seems to be it also for the Tongfang GMxTGxx.

I currently only have remote access to one of the affected devices (home office), but with this change the irq errors from the kernel logs are gone and xinput lists the touchpad.

Tomorrow I will ask a colleague to touch the touchpad to see if it's actually working.

Firmware vendors are usually faster when you can pinpoint the exact thing to change. So my noob question: From where in the firmware does this 57/44 pin come? Is it ACPI code (hope so, then a workaround could be crafted even without vendor support)? If yes: What am I looking for in the .dsl files?

(In reply to wse from comment #34)

> So my noob question: From where in the firmware does this 57/44 pin
> come? Is it ACPI code (hope so, then a workaround could be crafted even
> without vendor support)? If yes: What am I looking for in the .dsl files?

GPDI is a variable in NVS that is filled by BIOS. That variable is being converted on OS level to the INT1 with `INT1 = GNUM(GPDI)`. There are 4 (almost?) identical code snippets (one per each of I²C controllers), so you need to see which one is in use or change all of them. This will require to recompile complete DSDT.

I would suggest to whine at vendor and tell them that their BIOS is wrongly set the pin for TouchPad device in DSDT. It is quite likely that Windows drivers just ignore interrupt resource for touchpad (which is a mistake in Windows driver, but we all know that the quality there is simply awful).

From this:
TP_I2C_CLK -> BD21 -> GPP_C17/I2C0_SCL
TP_I2C_DAT -> BC22 -> GPP_C16/I2C0_SDA
I guess it's the first one I2C0

Thanks I will relay this and we hopefully get a fixed bios for the Tongfang.

And I wish good luck for the people Clevo devices also. I hope Clevo gives them a positive response also.

But I wonder now: Is there somewhere in this gpio code a quirk list, like in so many other places of the kernel, for redirecting misconfiggured firmware pins on specific devices?

(In reply to Riccardo Mori from comment #33)
> Created attachment 297991 [details]
> dmesg working
> 
> Ok, with the map from pin 44 to pin 140 it is indeed working
> So the issue is actually a wrong pin number.
> At least now we have a workaround for this.
> 
> Thank you very much to everyone that helped.

Sorry to be a noob but just want to understand this before I embark on my first kernel build.
My situation is identical to Riccardo's so presumably I can use the same hack. However I don't fully understand:
a) Where 44 comes from - is this the GPIO pin that corresponds to acpi pin 57?
b) Where the replacement 140 is obtained from - is this just a free pin?
Thanks

a) CPU Pin 57 = GPIO Pin 44
b) CPU PIN 37 = GPIO PIN 140
I don't know where one can look up the mapping CPU Pin <> GPIO Pin, Andy Shevchenko did.
Pin 37/140 is not choosen randomly, but it's the pin the touchpad interrupt line is physically attached to on the mainboards of the Tongfang GMxTGxx and the Clevo NH5xHP.
I found this out by looking up the schematics of the Clevo and the linux source code: https://bugzilla.kernel.org/show_bug.cgi?id=213579#c28

(In reply to Rod Thomas from comment #37)
> a) Where 44 comes from - is this the GPIO pin that corresponds to acpi pin
> 57?

You can find the mappings with `cat /sys/kernel/debug/pincntrl/INT346\:00/pins`
For example let's analyze the row for pin 57:
`pin 57 (SLP_S0B) 44:INT34C6:00 mode 1 0x44000700 0x00000051 0x00000000 [LOCKED full, ACPI]`
You can see that it is referring to line SLP_S0B, it is mapped to GPIO 44 and is not in GPIO mode (mode 1) and is fully locked and has ACPI ownership.
In contrast pin 37:
`pin 37 (CLKOUT_48) 140:INT34C6:00 GPIO 0x40800102 0x0000003d 0x00000000 [LOCKED tx]`
it is referring to line CLKOUT_48, it is mapped to GPIO 140, it is in GPIO mode and ACPI has no ownership of it


> Sorry to be a noob but just want to understand this before I embark on my
> first > kernel build.

I see you are using an archlinux based distro so you might find useful this repo I just created to build linux with this hack: https://github.com/patacca/linux-tigerlake-hack

(In reply to Riccardo Mori from comment #39)

> I see you are using an archlinux based distro so you might find useful this
> repo I just created to build linux with this hack:
> https://github.com/patacca/linux-tigerlake-hack


Cool! One side note: https://stackoverflow.com/q/27899104/2511795

Many thanks for the education guys, that's pretty clear now.
Riccardo, what version is your repo based on?

Rebuilt the kernel with the hack and the touchpad is now fixed. Let's hope we get a bios update before the next kernel update so we don't need to go round this again!
Thanks again for all the help.

I've learned alot with this thread. Thanks.

Confirmed also working for the equipment I was using as well.

CLEVO NH58HPQ

06:36:29 jm@jm ~ → lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

06:41:26 jm@jm ~ → uname -a
Linux jm 5.10.0+ #3 SMP Tue Jul 27 18:08:55 CDT 2021 x86_64 x86_64 x86_64 GNU/Linux

Found the offending code bit in the dsdt:

    Scope (_SB.PC00.I2C0)
    {
        Device (TPAD)
        {
            [...]
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                BADR = SADR /* \_SB_.PC00.I2C0.TPAD.SADR */
                INTA = GNUM (0x0801000C)
            }
            [...]
        }
    }

INTA should evaluate to 0x8C (140), but does evaluate to 0x2c (44).
GNUM is some kind of offset calculation, ignoring the 0x08, taking values from an array based on the 0x01 and adding it to the 0x000C. You can check it in the disassembled dsdt. I don't know ofcourse if GNUM is buggy, the array is wrong, or the 0x0801000C input value is wrong (you can choose an input value that makes GNUM evaluate to 0x8C).

(In reply to wse from comment #44)
> Found the offending code bit in the dsdt:
> 
>     Scope (_SB.PC00.I2C0)
>     {
>         Device (TPAD)
>         {
>             [...]
>             Method (_INI, 0, NotSerialized)  // _INI: Initialize
>             {
>                 BADR = SADR /* \_SB_.PC00.I2C0.TPAD.SADR */
>                 INTA = GNUM (0x0801000C)
>             }
>             [...]
>         }
>     }
> 
> INTA should evaluate to 0x8C (140), but does evaluate to 0x2c (44).
> GNUM is some kind of offset calculation, ignoring the 0x08, taking values
> from an array based on the 0x01 and adding it to the 0x000C. You can check
> it in the disassembled dsdt. I don't know ofcourse if GNUM is buggy, the
> array is wrong, or the 0x0801000C input value is wrong (you can choose an
> input value that makes GNUM evaluate to 0x8C).

However: Building and using a dsdt with INTA hardcoded to 0x8C makes the touchpad work on arbitrary kernels. Maybe a better workaround then a self compiled kernel.

(In reply to wse from comment #45)
> (In reply to wse from comment #44)
> > Found the offending code bit in the dsdt:
> > 
> >     Scope (_SB.PC00.I2C0)
> >     {
> >         Device (TPAD)
> >         {
> >             [...]
> >             Method (_INI, 0, NotSerialized)  // _INI: Initialize
> >             {
> >                 BADR = SADR /* \_SB_.PC00.I2C0.TPAD.SADR */
> >                 INTA = GNUM (0x0801000C)
> >             }
> >             [...]
> >         }
> >     }
> > 
> > INTA should evaluate to 0x8C (140), but does evaluate to 0x2c (44).
> > GNUM is some kind of offset calculation, ignoring the 0x08, taking values
> > from an array based on the 0x01 and adding it to the 0x000C. You can check
> > it in the disassembled dsdt. I don't know ofcourse if GNUM is buggy, the
> > array is wrong, or the 0x0801000C input value is wrong (you can choose an
> > input value that makes GNUM evaluate to 0x8C).
> 
> However: Building and using a dsdt with INTA hardcoded to 0x8C makes the
> touchpad work on arbitrary kernels. Maybe a better workaround then a self
> compiled kernel.

Thanks for this debugging and root causing the effort!
I totally agree that DSDT recompilation is much better approach, but it's still far from ideal (firmware fix by a vendor).

More testing: Using the fixed acpi table on windows breaks the touchpad.

So windows expects the 0x2C here?

Is there some offset not implemented in the Linux kernel?

More testing with same result: Hardcoding the adress to 0x2C works on widnows, but breaks on other values including 0x8C

(In reply to wse from comment #48)
> More testing with same result: Hardcoding the adress to 0x2C works on
> widnows, but breaks on other values including 0x8C

This is interesting, it may mean that Windows driver has a quirk against the firmware bug.

(In reply to Andy Shevchenko from comment #49)
> (In reply to wse from comment #48)
> > More testing with same result: Hardcoding the adress to 0x2C works on
> > widnows, but breaks on other values including 0x8C
> 
> This is interesting, it may mean that Windows driver has a quirk against the
> firmware bug.

Or maybe it is adding 0x60 to all GpioInt numbers for some reason, it seems we are having a lot of issues with GpioInt lookups on Tiger Lake, so I suspect that there is actually something which Linux is doing differently then Windows, rather then there being model specific quirks in Windows.

Also see bug 213857 which appears to be yet another instance of this problem, that is with a high-end Asus laptop, granted Asus ACPI table quality is all over the place but their higher end models tend to be pretty decent.

(In reply to Hans de Goede from comment #50)
> (In reply to Andy Shevchenko from comment #49)
> > (In reply to wse from comment #48)
> > > More testing with same result: Hardcoding the adress to 0x2C works on
> > > widnows, but breaks on other values including 0x8C
> > 
> > This is interesting, it may mean that Windows driver has a quirk against
> the
> > firmware bug.
> 
> Or maybe it is adding 0x60 to all GpioInt numbers for some reason, it seems
> we are having a lot of issues with GpioInt lookups on Tiger Lake, so I
> suspect that there is actually something which Linux is doing differently
> then Windows, rather then there being model specific quirks in Windows.

Actually you may be quite right because number of bugs is growing. The numbering scheme of GPIOs is mystery and subject to last minute changes (because it's pure artificial layer on top of the hardware). It's quite possible that the driver was upstreamed with outdated mapping (see 4th parameter to the groups in the communities in the driver). I'm investigating this.

For reference: Tongfang replied that they checked (on windows I guess) that "after kernel computation" the value for INTA is 0x8C.

I know it's a linux bugtracker, but does anyone actually know where pins could be checked on windows? Aka if I can check that the touchpad is really using 0x8C and what it is trying to use with a manipulated DSDT (to see if it's an offset or a mapping issue).

*** Bug 213463 has been marked as a duplicate of this bug. ***

*** Bug 213857 has been marked as a duplicate of this bug. ***

Created attachment 298191 [details]
Fix the GPIO mapping

Long story short: the GPIO (software) mapping is broken and it seems confirmed by a few different sources. Here is the patch to test.

(In reply to Andy Shevchenko from comment #56)
> Created attachment 298191 [details]
> Fix the GPIO mapping
> 
> Long story short: the GPIO (software) mapping is broken and it seems
> confirmed by a few different sources. Here is the patch to test.

Does the above patch need to be applied along with the change suggested in https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20?

(In reply to Lovesh from comment #57)
> (In reply to Andy Shevchenko from comment #56)
> > Created attachment 298191 [details]
> > Fix the GPIO mapping

> Does the above patch need to be applied along with the change suggested in
> https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20?

The patch is the real fix, you are referring to some hacks that mustn't be applied.

(In reply to Andy Shevchenko from comment #58)
> (In reply to Lovesh from comment #57)
> > (In reply to Andy Shevchenko from comment #56)
> > > Created attachment 298191 [details]
> > > Fix the GPIO mapping
> 
> > Does the above patch need to be applied along with the change suggested in
> > https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20?
> 
> The patch is the real fix, you are referring to some hacks that mustn't be
> applied.

Got it, thanks. Will build with it.

(In reply to Lovesh from comment #59)
> (In reply to Andy Shevchenko from comment #58)
> > (In reply to Lovesh from comment #57)
> > > (In reply to Andy Shevchenko from comment #56)
> > > > Created attachment 298191 [details]
> > > > Fix the GPIO mapping
> > 
> > > Does the above patch need to be applied along with the change suggested
> in
> > > https://bugzilla.kernel.org/show_bug.cgi?id=213857#c20?
> > 
> > The patch is the real fix, you are referring to some hacks that mustn't be
> > applied.
> 
> Got it, thanks. Will build with it.

Touchpad works great (click, tap, scroll) with this patch!. Thanks a lot.

Any idea when this will be part of the mainline kernel or even an rc?

After applying the patch, both touchpad and touchscreen work correctly.

Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

(In reply to Lovesh from comment #61)
> Any idea when this will be part of the mainline kernel or even an rc?

I have just sent the official patch. Now it's matter of maintainers to proceed. Hopefully it will be in within couple of weeks.

Thank you everybody who helped with the root causing and testing!

Thank you Andy for being so fast with the patch. Can you tell us where did you find those numbering for the GPP mappings?

I have a Clevo NH58HPQ and am having the same issue but slightly different error, I applied this patch this morning and still get an error.


[  924.443744] tigerlake-pinctrl INT34C6:00: pin 57 cannot be used as IRQ
[  924.443746] genirq: Setting trigger mode 8 for irq 131 failed (intel_gpio_irq_type+0x0/0x130)
[  924.448165] gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot get GPIO direction
[  924.448166] gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 44 for IRQ
[  924.448167] genirq: Failed to request resources for ELAN0412:01 (irq 131) on irqchip INT34C6:00
[  924.448174] i2c_hid_acpi i2c-ELAN0412:01: Could not register for ELAN0412:01 interrupt, irq = 131, ret = -22
[  924.448201] i2c_hid_acpi: probe of i2c-ELAN0412:01 failed with error -22

(In reply to Ben Long from comment #65)
> I have a Clevo NH58HPQ and am having the same issue but slightly different
> error, I applied this patch this morning and still get an error.
> 
> 
> [  924.443744] tigerlake-pinctrl INT34C6:00: pin 57 cannot be used as IRQ
> [  924.443746] genirq: Setting trigger mode 8 for irq 131 failed
> (intel_gpio_irq_type+0x0/0x130)
> [  924.448165] gpio gpiochip0: (INT34C6:00): gpiochip_lock_as_irq: cannot
> get GPIO direction
> [  924.448166] gpio gpiochip0: (INT34C6:00): unable to lock HW IRQ 44 for IRQ
> [  924.448167] genirq: Failed to request resources for ELAN0412:01 (irq 131)
> on irqchip INT34C6:00
> [  924.448174] i2c_hid_acpi i2c-ELAN0412:01: Could not register for
> ELAN0412:01 interrupt, irq = 131, ret = -22
> [  924.448201] i2c_hid_acpi: probe of i2c-ELAN0412:01 failed with error -22

Did you make sure that you booted the patched kernel?

Positive

Linux fedora 5.13.6-200.trakhak.fc34.x86_64 #1 SMP Wed Aug 4 10:25:19 EDT 2021 x86_64 x86_64 x86_64 GNU/Linux

(In reply to Ben Long from comment #67)
> Positive
> 
> Linux fedora 5.13.6-200.trakhak.fc34.x86_64 #1 SMP Wed Aug 4 10:25:19 EDT
> 2021 x86_64 x86_64 x86_64 GNU/Linux

It may be different error. Can you create another report and attach `acpidump -o clevo-tables.dat` along with the diff between the kernel you have before any patches applied and now?

(In reply to Andy Shevchenko from comment #56)
> Created attachment 298191 [details]
> Fix the GPIO mapping
> 
> Long story short: the GPIO (software) mapping is broken and it seems
> confirmed by a few different sources. Here is the patch to test.

For the sake of completness: Tested on the Tongfang GMxTGxx Barebone and works perfectly now.

Submitted a new report and included the requested acpidump there.

I do not have anything else custom in my kernel except for including the .patch file in the the above post. I added to the .patch file to the SOURCES dir and added it to the kernel.spec and rebuilt the kernel package and installed it.

Running Fedora 34

Hey Again,

So, yeah, I didn't patch the kernel, terribly sorry. Been a minute aince I had to patch something and I was just running -bb flag, using -ba or -bp and then -bb fixed the patch issue.

And with that, I can confirm that this is fixed on my Clevo NH58HPQ.

It also fixed another weird bug where the keyboard waits for the screen to poll (a little horz liine would go through each line of grub) and keyboard wouldnt be usable until that got to the bottom. Keyboard works fine now as soon as grub starts.

Thanks guys! Cant wait for it to hit upstream.

Created attachment 298207 [details]
tried gpio mapping patch

attaching acpidump
with tried gpio mapping patch

Created attachment 298209 [details]
attaching other info about boot

Not sure which patch Ben Long tried, but I just tried the patch to drivers/pinctrl/intel/pinctrl-tigerlake.c on the clevo NH58HPQ and it didn't appear to fix the issue.

The previous and not recommended hack worked

https://github.com/patacca/linux-tigerlake-hack/blob/main/pin-mapping-hack.patch

Created attachment 298211 [details]
xinput.list.props.evtest.txt

adding xinput, evtest info

*** Bug 213977 has been marked as a duplicate of this bug. ***

(In reply to James Munsch from comment #72)
> attaching acpidump
> with tried gpio mapping patch

I have checked your ACPI tables and they are the same (in terms of how GNUM() method works) as for the others for whom this patch fixes the issue. Please, carefully try again.