Re: Wrong piix4_smbus address / slow trackpoint on Thinkpad P14s gen 2 (AMD)

["Miroslav Bendík" <miroslav.bendik@gmail.com>]

Hello,
i think, that SMBus works now pretty good and last problem is screaming 
interrupt from synaptics (1000 irq/s). I need little help to solve this 
problem.

Little summary first:

On this thinkpad is synaptics trackpoint/touchpad connected to PIIX4. To 
enable RMI4 mode, SMBus driver should support host notify protocol. I 
have added support of host notify and replaced active waiting 
transaction with completer + interrupt. Driver is now pretty stable and 
works way better, than old implementation. For example i2c-detect shows 
real devices (previous transaction code showed all addresses from 0x1c 
as active). Patch on following link is still hack, has hardcoded IRQ and 
supports host notifications and interrupts only on auxiliary port. I can 
implement other ports later.

Patch: 
https://lore.kernel.org/all/c9b0b147-2907-ff41-4f13-464b3b891c50@wisdomtech.sk/
This patch includes PM register access using MMIO: 
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/

Now i can load psmouse synaptics_intertouch=1 and everything works 
great, but it uses 5% CPU and interrupt is called 1000/s. I have changed 
interrupt from rising edge to active low (it's PCIE, PCIE has active 
low) and i have many times checked if all interrupt bits are cleared in 
interrupt request. Yes, they are always cleared. Interrupts are 
generated only after first touch if i have compiled only F12. If i 
compile F03, then interrupts are generated immediately after load of 
psmouse. After unload, interrupts are not generated (i2c-piix4 still 
loaded).

On this machine I2C is accessible using GPIO 19(SCL), 20(SDA). Using 
kernel thread with RT priority on isolated core i have tried to record 
pin values on GPIO pins. Latency is too high to record all transferred 
data. Some state changes are lost (approximately 1/50 bits). Not too low 
to read reliably all data, but good enough to see what happens at bus 
level. Here is recorded file: 
https://mireq.linuxos.sk/kernel/thinkpad_p14s/i2c_scl_sda.xz.

Every byte is sample, first bit is SCL, second SDA. Sample rate is cca 
500 000 Hz, but often drops under 100 000 (lost bit).

On this screenshot is typical activity on bus: 
https://mireq.linuxos.sk/kernel/thinkpad_p14s/i2c_1.png (pulseview with 
imported raw file)

Zoom to two packet is here: 
https://mireq.linuxos.sk/kernel/thinkpad_p14s/i2c_2.png

First packet is SMBus host notify. Address 0x08 is SMBus host address 
and 0x58 is address of synaptics (0x2c << 1). Second packet is reading 
of interrupt status registers. Data 02 is length of interrupt status 
register (9 bits) and last 2 bytes are zero (idle, when moving cursor, 
then interrupt status register contains one bit set).

Zoomed out: https://mireq.linuxos.sk/kernel/thinkpad_p14s/i2c_3.png

Before transaction SMBus slave state machine is disabled and after 
transaction enabled. If notification is received when state machine is 
disabled, then device writes only address and don't get response. If 
driver runs with always enabled slave state machine, then output will 
contain only notify + read interrupt status pairs and no separate 
addresses, but with this mode bus collisions occur more often.

Here is dmesg output: https://pastebin.com/RdDYHJn0

Cursor is moved until 2862.8, then i have not touched trackpoint.

Idle device don't produce bus collisions. Moving cursor produces 
collisions, but sample rate is stable 100Hz, which is way better, than 
<40 Hz with PS/2 mode. I don't know how to solve collisions. Maybe they 
are related to not silenced host notifications.

If i were to be optimistic, then i would say that clearing interrupt 
vector will solve all problems. According old RMI4 documentation, 
reading from interrupt status register should clear interrupts (status 
register is cleared), but this don't prevent device form sending host 
notifications. Maybe exists new way to disable interrupts. I don't know, 
i have no access to current documentation.

My device has this signature:
Synaptics, product: TM3471-030, fw id: 3418235

Any help welcome.