When using Elan touchpad on a GLK system, the i2c-hid floods the dmesg with this message: [ 14.327810] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report (14/65535) Initially I thought the touchpad behaves wrong, but later I found the same touchpad doesn't have this issue on a WHL system. According to Elan, after the i2c-hid receives all data from the touchpad, it needs 7~8ms to pull the IRQ to high. So I wonder if this is related to the clock rate of LPSS's clock rate?
Created attachment 278889 [details] acpidump from WHL system (good)
Created attachment 278891 [details] acpidump from GLK system (bad)
Need to use attachment so using bugzilla instead of mailing list.
Andy, Mika, Do you know how to check i2c-designware's clock under Windows? I'd like to check if there's any difference under Linux and Windows.
You may try to read the LCNT/HCNT registers using some Windows tool that can read MMIO space. Unfortunately I don't know which tool can do that but I'm sure there exists such.
(In reply to Mika Westerberg from comment #5) > You may try to read the LCNT/HCNT registers using some Windows tool that can > read MMIO space. Unfortunately I don't know which tool can do that but I'm > sure there exists such. If the device is in the lowest 4G address space, the http://rweverything.com/download/ works good, I also heard about https://rekall.readthedocs.io/en/gh-pages/Tools/pmem.html, but I wouldn't be able to make it working.
Is there a way to check MMIO address for i2c-designware under Linux? Are both Linux and Windows use the same MMIO address?
Looks like the bad one does not include ACPI methods to specify LCNT/HCNT values so it could really be that those values are not correct in GLK Linux LPSS driver. Adding Jarkko who might be able to help here.
The *CNT registers are at MMIO offset (from the first BAR): #define DW_IC_FS_SCL_HCNT 0x1c #define DW_IC_FS_SCL_LCNT 0x20 Windows should use the same MMIO addresses if it gets assigned by the BIOS (I think it is).
Is the "first BAR" refers to LPSS? Seems like 0x1c and 0x20 are 0. 00:17.1 Signal processing controller: Intel Corporation Device 31b6 (rev 03) Subsystem: Dell Device 08d5 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 32 Region 0: Memory at a1230000 (64-bit, non-prefetchable) [size=4K] Region 2: Memory at a122f000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vendor Specific Information: Len=14 <?> Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 00: 86 80 b6 31 06 00 10 00 03 00 80 11 10 00 80 00 10: 04 00 23 a1 00 00 00 00 04 f0 22 a1 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 d5 08 30: 00 00 00 00 80 00 00 00 00 00 00 00 20 02 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 90 03 00 0b 00 00 00 00 00 00 00 00 00 00 00 90: 09 00 14 f0 10 00 40 01 01 21 00 00 c1 24 00 00 a0: 00 08 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 1c 0f 00 01 00 00 00 00
That's PCI config space. I mean these: Region 0: Memory at a1230000 (64-bit, non-prefetchable) [size=4K] Region 2: Memory at a122f000 (64-bit, non-prefetchable) [size=4K] The first one in particular (a1230000 + 1c) or so.
Thank you Mika! This is what I found: Offset Windows Linux 14 1F4 228 18 24C 28C 1c 64 64 20 D2 C8 24 FFFF 8 28 14 14 7C FFFF 10006 The issue goes away after I replace the original values with Windows' values in i2c_dw_init_master().
Hmm.. Our preliminary information was we can share the same I2C timings on Gemini Lake than on Broxton. Obviously they don't work your HW. I'll check have the default timings for GLK been changed/tuned after that and should be update them on Linux (code in drivers/mfd/intel-lpss-pci.c).
Jarkko, Do you get information from internal team for the I2C timings?
Not yet. I pinged yesterday again.
I got first information what values Windows is using. Fast speed timings (0x1c and 0x20) matches with what you are seeing but others differ a bit. I'll ask again what would explain the difference. I guess they are the most up to date but want to double check.
Created attachment 279437 [details] Patch adding I2C timing parameters for Gemini Lake
Hi Kai-Heng. Could you try does the attachment https://bugzilla.kernel.org/attachment.cgi?id=279437 work for you? It has timing values that should match with the Windows at least when using the I2C Fast Speed. For some reason Standard Speed values differ from what you are seeing but probably that is due different Windows version or something. According to Windows team there shouldn't be OEM specific tunings in the driver.
Hi Jarkko, I cab still see the issue with the patch applied.
Hmm.. did you use in your testing value 0xffff for the SDA hold register 0x7c? It kind of looks bogus and I thought Windows hadn't set it yet when dumping the registers.
Thanks for pointing it out. The issue goes aways as long as DW_IC_SDA_HOLD is set with 0xffff, with or without the path you provide.
It's quite odd. If I try to use that value on our GLK or Kabylake based machines the communication doesn't work at all.
Forgot to ask can you share your machine details or is it some prototype or other non-public early HW?
It's not on the market yet but we do see the same issue on later stage hardware.
Use 0xffff for DW_IC_SDA_HOLD solves the issue for another user: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/comments/39 Would it be possible that sda_hold_time needs to be disabled for certain devices?
I'm aware only some old designware IPs were not supporting SDA hold time. About the issue going away does it mean flooding stops or touchpad starts actually working?
The touchpad works in both cases, but the flooding stops when DW_IC_SDA_HOLD is set to 0xffff.
Could you attach here a full dmesg when DW_IC_SDA_HOLD is 0xffff? I'm curious to see how touchpad initializes during boot and also possible I2C errors. I'm somewhat idealess but was thinking is the touchpad fully i2c-hid device or does it use some other interface like USB or PS/2 for coordinates since it works independently from DW_IC_SDA_HOLD value.
Ok, I was wrong. When DW_IC_SDA_HOLD is set with 0xffff, the i2c-designware timed out so the touchpad uses psmouse.ko instead. After applying your patch, some of those values are still different from Windows. But even if I set Windows' value directly, the issue "i2c_hid_get_input: incomplete report (14/65535)" is still there. In the meantime, the same touchpad on KBL/WHL and AMD platforms doesn't have this issue...
Do those other machines use the psmouse or i2c-hid driver? Do you see difference between GLK and other machines in /sys/bus/i2c/devices/ and /dev/input/by-path/ related to touchpad device? Here's reference from a machine that uses i2c-hid compatible touchscreen and touchpad devices (I listed only those two devices): ls -l /sys/bus/i2c/devices/ lrwxrwxrwx 1 root root 0 Dec 3 14:45 i2c-ALPS0001:00 -> ../../../devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-9/i2c-ALPS0001:00 lrwxrwxrwx 1 root root 0 Dec 3 14:45 i2c-WCOM508E:00 -> ../../../devices/pci0000:00/0000:00:17.3/i2c_designware.7/i2c-12/i2c-WCOM508E:00 ls -l /dev/input/by-path/ lrwxrwxrwx 1 root root 9 Dec 3 14:42 pci-0000:00:17.0-platform-i2c_designware.4-event-mouse -> ../event3 lrwxrwxrwx 1 root root 9 Dec 3 14:42 pci-0000:00:17.3-platform-i2c_designware.7-event -> ../event5 lrwxrwxrwx 1 root root 9 Dec 3 14:42 pci-0000:00:17.3-platform-i2c_designware.7-event-mouse -> ../event4
All these platforms use i2c-hid driver. The platform in question also uses I2C HID under Windows. This may also happen to Windows, but maybe their driver simply ignore invalid data? Do you need physical hardware to debug? We can arrange one to you.
does the mentioned patch apply to my system? it's very frustrating. dmesg: http://termbin.com/jmw2 acpidump: http://termbin.com/o740 /dev/input/by-path: http://termbin.com/lir8 /sys/bus/i2c/devices: http://termbin.com/b1e7
If I googled right above Asus machine is Intel Apollo Lake based and the patch I've attached changes only Intel Gemini Lake I2C timing parameters.
Kai-Heng, I'm puzzled, you mentioned earlier your GLK uses psmouse driver for the touchpad instead of i2c-hid, even tough it binds the touchpad with i2c-hid too? Do those other working machines use only i2c-hid or psmouse too? What differences do you see between working and non-working configurations in related to touchpad?
Sorry for the wrong information. There are two cases: - Set DW_IC_SDA_HOLD as 0xffff. The i2c-designware timed out so the touchpad uses psmouse.ko instead. I mistakenly thought this solves the issue without checking. My apology. - Use unmodified kernel, or applying your patch, the touchpad works via i2c-hid transport. "i2c_hid_get_input: incomplete report (14/65535)" still happens under both cases. I _guess_ it's related to I2C controller's timing because I don't see this issue happen to the same touchpad under KBL or WHL, or even AMD platforms. That said, this can still be an issue at Elan touchpad's side. This can also happen under Windows but we don't have anyway to check it...
workaround from comment #35 on ubuntu issue tracker[1] makes the symptom go away for me. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/comments/35
Created attachment 280173 [details] attachment-2458-0.html This also fixed the _symptom_ for me, to emphasize your term, but definitely does not solve the real problem. Currently I have 13% CPU usage from irq/142-ELAN120 doing...something...forever. However, it is nice that this now doesn't also fill up my filesystem with logs. On Thu, Dec 27, 2018 at 3:16 PM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=201311 > > --- Comment #36 from mailinglists35@gmail.com --- > workaround from comment #35 on ubuntu issue tracker[1] makes the symptom go > away for me. > > [1] > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784152/comments/35 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Ryan Reich from comment #37) > Currently I have 13% CPU usage > from irq/142-ELAN120 I don't, it's not even on the powertop output on 80x25 terminal.
this appears to be fixed for me in 5.1.0-0.rc2.git0.1.fc31.x86_64 I only get this once the first time I use the touchpad: [ 228.913080] i2c_hid i2c-ELAN1300:00: i2c_hid_get_input: IRQ triggered but there's no data
*** Bug 201341 has been marked as a duplicate of this bug. ***