Bug 217644 - Chuwi Gemibook Pro Celeron N5100 touchpad not detected, PNP ID SYNA3602, i2c_designware timeout
Summary: Chuwi Gemibook Pro Celeron N5100 touchpad not detected, PNP ID SYNA3602, i2c_...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: I2C (show other bugs)
Hardware: Intel Linux
: P3 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-08 03:06 UTC by Paul Ausbeck
Modified: 2023-07-14 02:13 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.10, 5.15, 5.18, 6.0. 6.1
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Paul Ausbeck 2023-07-08 03:06:17 UTC
This bug is specific to the Chuwi Gemibook Pro Celeron N5100, 8GB DRAM model. The bug is specific to linux as the touchpad works normally under Windows 10. I have a J4125/16GB model of the same laptop and it works fine under linux, but has a different touchpad pnp ID.

The kernel log error at the heart of the matter:

[21615.530254] i2c_designware i2c_designware.0: controller timed out

The i2c subsystem attempts to talk to the touchpad device and immediately times out. This is a hard failure, no other errors ever occur. If I use i2cdetect on bus 0, where the device resides, it shows -- for addresses 30-37 and 50-5f and blank for all other addresses. Running i2cdetect on bus 0 takes far longer than running on any of the other 19 i2c buses on the machine. My feeling is that the touchpad is on i2c bus 0 but is not responding to any queries or commands. The presence of the misbehaving device is causing detection queries to take longer to timeout than on the other buses.

I feel like I've ruled out the following:
1. Runtime power management, failure the same with runtime power management disabled.
2. ACPI specifying the wrong bus for the SYNA3602 device. As far as I can tell, none of
   the other 19 i2c buses could be used for the touchpad.

Since i2cdetect does not detect the device, I am guessing that the problem is I/O pin location, speed or polarity related. This a jasperlake device and perhaps the pinctrl_jasperlake driver is not mapping the PCH I/O pins properly. Perhaps i2c bus 0 is not tied to the correct PCH pins, or not with the proper polarity, or incorrect clock speed.

I am no expert on any of these matters so any help with this would be greatly appreciated.

I have looked at other kernel bugs that may be related, and done quite a bit of general internet searching and haven't been able to find anything that seems connected to this particular problem.
Comment 1 Paul Ausbeck 2023-07-08 03:07:48 UTC
I've just added the kernel versions that I've tried with this machine. All behave exactly the same.
Comment 2 Paul Ausbeck 2023-07-08 03:32:40 UTC
Correction. There are 17 i2c buses on the machine. The SYNA3602 device purports to be on i2c bus 1, i2c_designware.0.

i2cdetect detects devices on buses 8 and 15, but no others.

sudo i2cdetect -y 8
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 09 0a 0b 0c 0d 0e 0f 
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: -- -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77        

sudo i2cdetect -y 15
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
Comment 3 Bagas Sanjaya 2023-07-08 14:05:58 UTC
Is this hardware issue?
Comment 4 Paul Ausbeck 2023-07-08 15:51:44 UTC
It's not what I would call a hardware issue. As I've noted previously, the same machine with the same touchpad works fine under Windows 10. It is jasperlake specific, though. The same model, though older, J4125 Gemibook Pro works fine under linux.
Comment 5 Paul Ausbeck 2023-07-14 02:07:08 UTC
I guess that this problem could be in three possible places, i2c-designware, pinctrl-jasperlake, or the machine's ACPI tables. I think the least likely culprit is i2c-designware, because i2cdetect doesn't find any devices where i2c-designware is looking. Given how these cheap Chinese manufacturers operate, I think it quite plausible that the ACPI tables are somewhat amiss. That's similar to a hardware problem in that as far as I can tell Chuwi never issues firmware/BIOS updates.

It would be nice if someone with more knowledge than I would give some pointers on how to load alternate BIOS tables and/or hack on pinctrl-jasperlake to route signals a bit differently.
Comment 6 Paul Ausbeck 2023-07-14 02:13:06 UTC
I also wanted to mention that Microsoft's i2c device discovery mechanism seems to be more robust than that of linux. Postulating that linux is looking in the wrong place for the i2c touchpad, how is it that Microsoft finds it? Perhaps MS does a more general search, looking at a larger set of possibilities than those given by ACPI. Or perhaps Windows has an analog to pinctrl-jasperlake that is more up to date and/or accurate than linux.

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