Re: PixArt touchpad not detected due to wrong pinctrl

[Andy Shevchenko via Bugspray Bot <bugbot@kernel.org>]

Andy Shevchenko writes via Kernel.org Bugzilla:

(In reply to Guido Trentalancia from comment #18)
> Andy, the patch that Ariel provided did sort the issue of I2C PIXA touchpad
> detection, although it's pretty clear that it uses duplicated pin numbering
> that needs proper grouping and ordering within the existing communities.
> 
> So Ariel intuition sounds correct to me, in that the pin definitions for I2C
> SDA and SCL lines are missing in the Alder Lake pinctrl driver.

> From an end-user point of view it's illogical and not intuitive that one has
> to use a kernel module targeting another chipset in order for I2C device
> detection to work properly.

It's how the hardware world works like it or not. Yeah, same code-named hardware can use different IP blocks in different revisions. This is a headache for users, I agree, but I can't do anything about this.

> Steps to reproduce:
> 
>  - grab an Intel Alder Lake based laptop using the PixArt touchpad from the
> list 
>    provided at:
>    https://linux-hardware.org/?id=ps/2:3848-3848-pixa3848-00-093a-touchpad
> 
>  - build a kernel with the pinctrl-alderlake module using the
>    CONFIG_PINCTRL_ALDERLAKE kernel configuration option: this is what a
> normal
>    end user does
> 
>  - install the newly built kernel and reboot
> 
>  - start an X session and realize that the touchpad is not working or
> otherwise
>    use "dmesg | grep -i input" to realize from the kernel log that the I2C
>    touchpad has not been detected

Okay, this part is clear.

> Steps to resolve the issue:
> 
>  - apply any of the patches provided in this bug report

This is totally unclear. The list of pins is defined in the specification, the change like proposed messes things up with that. I suspect there is something else is going on here.

>  - rebuild the kernel, install it and reboot
> 
>  - start an X session or type "dmesg | grep -i input" and realize that the
> I2C
>    PixArt touchpad is not detected, as the Alder Lake pinctrl driver now
>    includes the definitions for the I2C SDA and SCL lines that were missing
> in
>    the original version of the kernel Alder Lake pinctrl module

Please, make this one crystal clear: Does the switch from Alder Lake pin control driver to Tiger Lake driver solve the issue *without* any patches?

> Steps that might possibly lead to the creation of a proper patch:
> 
>  - edit the drivers/pinctrl/intel/pinctrl-alderlake.c kernel module source
> code
> 
>  - ask Intel to kindly provide the official documentation for the Alder Lake
> PCH

The EDS usually is available via Intel official site. I can look for the links later on after I get more information about the HW you are talking about.

>  - add the definition for the 4 I2C SDA and SCL lines in the proper group and
>    community: for example in the Tiger Lake driver that was group GPP_H and
>    community 1

No, this won't happen. The pin control Alder Lake driver is written for Alder Lake-N and Alder Lake-S, you are probably talking about different version of the Alder Lake, or not Alder Lake at all. I will know more after the requested (below) information provided.

>  - modify the bounds in the structures at the bottom of the kernel module
> source
>    code in order to account for the newly added I2C SDA and SCL lines

> I believe marking this as RESOLVED INVALID is not the way forward.

Fair enough.

Okay, let's go long way. Please, attach the followin outputs (all should be run as root):
1) `dmesg` (from the boot to the shell) when kernel command line has 'ignore_loglevel initcall_debug`. Ideally kernel should be build with `CONFIG_DEBUG_PINCTRL=y` and `CONFIG_DEBUG_GPIO=y`. Also make sure you use vanilla kernel without any custom patches.
2) `lspci -nk -vv`
3) `acpidump -o adl-xx-tables.dat` (the mentioned *.dat file)
4) `cat /proc/interrupts`
5) `lscpu`
6) `cat /proc/iomem`
7) `grep -H 15 /sys/bus/acpi/devices/*/status`

I believe with this information I can see more, currently this report is no go (only I may agree on the documentation changes).

View: https://bugzilla.kernel.org/show_bug.cgi?id=220056#c19
You can reply to this message to join the discussion.
-- 
Deet-doot-dot, I am a bot.
Kernel.org Bugzilla (bugspray 0.1-dev)