Forwarding to i2c list ----- Forwarded message from bugzilla-daemon@xxxxxxxxxx ----- Date: Sat, 08 Jul 2023 03:06:17 +0000 From: bugzilla-daemon@xxxxxxxxxx To: bp@xxxxxxxxx Subject: [Bug 217644] New: Chuwi Gemibook Pro Celeron N5100 touchpad not detected, PNP ID SYNA3602, i2c_designware timeout Message-ID: <bug-217644-6385@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugzilla.kernel.org/show_bug.cgi?id=217644 Bug ID: 217644 Summary: Chuwi Gemibook Pro Celeron N5100 touchpad not detected, PNP ID SYNA3602, i2c_designware timeout Product: Platform Specific/Hardware Version: 2.5 Hardware: Intel OS: Linux Status: NEW Severity: normal Priority: P3 Component: x86-64 Assignee: platform_x86_64@xxxxxxxxxxxxxxxxxxxx Reporter: paula@xxxxxxxxxxxxxxxxxxx Regression: No 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. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ----- End forwarded message ----- -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
