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

Subsystems: input (keyboard, mouse, joystick, touchscreen) drivers, the rest

16 messages, 6 authors, 2024-10-15 · open the first message on its own page

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

From: Miroslav Bendik <hidden>
Date: 2021-12-11 12:14:40

On Thinkpad P14s gen 2 with AMD (model 21A00003CK, BIOS R1MET43W - 1.13) SMBus
address detection don't work and trackpoint has slow rate (30 Hz) because can't
use SMBus. Email is divided to SMBus and trackpoint section, there are issues in
both modules.

I am using amd-pstate-dev-v5 branch of kernel, but problem is in all versions.


SMBUS
=====


After inserting i2c_piix4 i have address 0xff00 / 0xff20 in log, but
correct address is 0xb20:

[    0.349576] ACPI: \_SB_.PCI0.SMB1: Unsupported CMI method: _STA
[    0.349629] piix4_smbus 0000:00:14.0: Using IRQ for SMBus
[    0.349630] piix4_smbus 0000:00:14.0: SMBus Host Controller at
0xff00, revision 15
[    0.349632] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus
port selection
[    0.349652] i2c_dev: adapter [SMBus PIIX4 adapter port 0 at ff00]
registered as minor 2
[    0.349658] i2c i2c-2: adapter [SMBus PIIX4 adapter port 0 at ff00]
registered
[    0.349702] i2c_dev: adapter [SMBus PIIX4 adapter port 2 at ff00]
registered as minor 3
[    0.349705] i2c i2c-3: adapter [SMBus PIIX4 adapter port 2 at ff00]
registered
[    0.349720] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host
Controller at 0xff20
[    0.349734] i2c_dev: adapter [SMBus PIIX4 adapter port 1 at ff20]
registered as minor 4
[    0.349737] i2c i2c-4: adapter [SMBus PIIX4 adapter port 1 at ff20]
registered

Here is relevant section of ACPI DSDT:

Scope (_SB.PCI0)
{
    Device (SMB1)
    {
        Name (_HID, "SMB0001")  // _HID: Hardware ID
        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        {
            IO (Decode16,
                0x0B20,             // Range Minimum
                0x0B20,             // Range Maximum
                0x20,               // Alignment
                0x20,               // Length
                )
            IRQ (Level, ActiveLow, Shared, )
                {7}
        })
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (0x0F)
        }
    }
}

Here is SMBus section of lspci:

# lspci -vvv -b -x -nn -PP -P -s 00:14.0
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 51)
    Subsystem: Lenovo FCH SMBus Controller [17aa:5094]
    Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
    IOMMU group: 9
    Kernel driver in use: piix4_smbus
    Kernel modules: i2c_piix4, sp5100_tco
00: 22 10 0b 79 00 04 20 02 51 00 05 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 94 50
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Command i2cdetect -q -y 4 don't detect anything and log contains this messages:

[  813.156253] i2c i2c-9: Transaction (pre): CNT=ff, CMD=ff, ADD=ff,
DAT0=ff, DAT1=ff
[  813.156259] i2c i2c-9: SMBus busy (ff). Resetting...
[  813.156265] i2c i2c-9: Failed! (ff)
[  813.156272] i2c i2c-9: Probing failed, no device found

I tried to temporary fix problem on my machine. Relevant function is
piix4_setup_sb800 in drivers/i2c/buses/i2c-piix4.c. I have added debug messages
and changed address in this function.

     smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
     outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
     smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
+    printk(KERN_INFO "piix4 smba_en_lo %u", smba_en_lo);
+    printk(KERN_INFO "piix4 smba_en_hi %u", smba_en_hi);
+    smba_en_hi = 0x0b;

...

+    printk(KERN_INFO "piix4 irq %d", PIIX4_dev->irq);
+    printk(KERN_INFO "piix4 i2ccfg %u", i2ccfg);

Then log looks like this:

[    0.809897] piix4 smba_en_lo 255
[    0.809899] piix4 smba_en_hi 255
[    0.811592] piix4 irq 0
[    0.811594] piix4 i2ccfg 4
[    0.811595] piix4_smbus 0000:00:14.0: SMBus Host Controller at
0xb00, revision 0
[    0.811598] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus
port selection
[    0.822338] piix4 smba_en_lo 255
[    0.822340] piix4 smba_en_hi 255
[    0.822345] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host
Controller at 0xb20

And touchpad / trackpoint is detected:

# i2cdetect -q -y 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 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: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
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


Trackpoint (RMI4)
=================

SMBus is now working (probably).

Without any module parameters i have this output:

psmouse serio1: synaptics: Your touchpad (PNP: LEN2073 PNP0f13) says
it can support a different bus. If i2c-hid and hid-rmi are not used,
you might want to try setting psmouse.synaptics_intertouch to 1 and
report this to linux-input@vger.kernel.org.

When i try with synaptics_intertouch=1 i have this in dmesg:

psmouse serio1: synaptics: Trying to set up SMBus access
psmouse serio1: synaptics: SMbus companion is not ready yet

I have disabled I2C_FUNC_SMBUS_HOST_NOTIFY checks in psmouse-smbus.c,
synaptics.c and
rmi_smbus.c. Module i2c_piix4 dont export I2C_FUNC_SMBUS_HOST_NOTIFY. Exact
changes are:
diff --git a/drivers/input/mouse/psmouse-smbus.c
b/drivers/input/mouse/psmouse-smbus.c
index a472489cc..6205f8d65 100644
--- a/drivers/input/mouse/psmouse-smbus.c
+++ b/drivers/input/mouse/psmouse-smbus.c
@@ -30,8 +30,8 @@ static void psmouse_smbus_check_adapter(struct
i2c_adapter *adapter)
 {
     struct psmouse_smbus_dev *smbdev;

-    if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_HOST_NOTIFY))
-        return;
+    //if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_HOST_NOTIFY))
+    //    return;

     mutex_lock(&psmouse_smbus_mutex);
@@ -196,8 +196,8 @@ static int psmouse_smbus_create_companion(struct
device *dev, void *data)
     if (!adapter)
         return 0;

-    if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_HOST_NOTIFY))
-        return 0;
+    //if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_HOST_NOTIFY))
+    //    return 0;

     client = i2c_new_scanned_device(adapter, &smbdev->board,
                     addr_list, NULL);
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index ffad14280..2f476dce7 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1765,7 +1765,7 @@ static int synaptics_create_intertouch(struct
psmouse *psmouse,
     };
     const struct i2c_board_info intertouch_board = {
         I2C_BOARD_INFO("rmi4_smbus", 0x2c),
-        .flags = I2C_CLIENT_HOST_NOTIFY,
+        //.flags = I2C_CLIENT_HOST_NOTIFY,
     };

     return psmouse_smbus_init(psmouse, &intertouch_board,
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
index 2407ea43d..3eb7193b4 100644
--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -281,14 +281,17 @@ static int rmi_smb_probe(struct i2c_client *client,
         return -ENOMEM;
     }

+    //if (!i2c_check_functionality(client->adapter,
+    //                 I2C_FUNC_SMBUS_READ_BLOCK_DATA |
+    //                 I2C_FUNC_SMBUS_HOST_NOTIFY)) {
     if (!i2c_check_functionality(client->adapter,
-                     I2C_FUNC_SMBUS_READ_BLOCK_DATA |
-                     I2C_FUNC_SMBUS_HOST_NOTIFY)) {
+                     I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
         dev_err(&client->dev,
             "adapter does not support required functionality\n");
         return -ENODEV;
     }

+    client->irq = 7;
     if (client->irq <= 0) {
         dev_err(&client->dev, "no IRQ provided, giving up\n");
         return client->irq ? client->irq : -ENODEV;
Now i have working trackpoint. It's not reliable. Sometimes it's generating
keyboard events instead mouse events, sometimes starts working for cca 1 second
after first move and then stops (no IRQs are generated), sometimes dmesg
contains many "Failed to read irq" messages.

[    2.058579] psmouse serio1: synaptics: queried max coordinates: x
[..5678], y [..4694]
[    2.092853] psmouse serio1: synaptics: queried min coordinates: x
[1266..], y [1162..]
[    2.092855] psmouse serio1: synaptics: Trying to set up SMBus access
[    2.116391] rmi4_smbus 4-002c: registering SMbus-connected sensor
[    2.186473] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer:
Synaptics, product: TM3471-030, fw id: 3418235
[    2.226009] input: Synaptics TM3471-030 as /devices/rmi4-00/input/input54
[    2.239455] serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
[    2.347012] psmouse serio2: trackpoint: Elan TrackPoint firmware:
0x12, buttons: 3/3
[    2.388030] input: TPPS/2 Elan TrackPoint as
/devices/rmi4-00/rmi4-00.fn03/serio2/input/input55
[ 1507.883750] rmi4_physical rmi4-00: Failed to read irqs, code=-5
[ 3263.258033] rmi4_physical rmi4-00: Failed to read irqs, code=-5
[ 3263.258587] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to
write to F03 TX register (-5).
[ 3263.259036] rmi4_physical rmi4-00: Failed to read irqs, code=-6
[ 3263.259579] rmi4_physical rmi4-00: Failed to read irqs, code=-6
[ 3263.267027] rmi4_physical rmi4-00: Failed to read irqs, code=-5
[ 3263.267581] rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -5.
[ 3263.267582] rmi4_f01 rmi4-00.fn01: Suspend failed with code -5.


Changes needed to fix issues
============================

Address detection in piix4 is really broken for this machine. I don't know how
to fix this, without breaking detection on other machines.

I think, that piix4 should implement I2C_FUNC_SMBUS_HOST_NOTIFY like i2c-i801.
Or rmi4 can be reliably enabled without I2C_FUNC_SMBUS_HOST_NOTIFY, just using
irq?

If bus access is fixed, then should be LEN2073 whitelisted for SMBus access.


Files
=====

Kernel config - https://mireq.linuxos.sk/kernel/p14s_gen2_amd_kernel_config
ACPI tables - https://mireq.linuxos.sk/kernel/p14s_gen2_amd_acpi_tables.tar.xz
My really really dangerous changes -
https://mireq.linuxos.sk/kernel/p14s_gen2_amd_smbus.patch

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

From: Miroslav Bendík <hidden>
Date: 2022-01-05 17:57:30

Address detection does not work because cd6h/cd7h port io can be 
disabled, but
it's accessible using mmio. This patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/ 
with
modified AMD_PCI_SMBUS_REVISION_MMIO fixed base address detection.

Problem with RMI4 touchpad / trackpoint remains, because rmi4-smbus 
needs host
notify feature. I have tried implement this feature, without success. 
Interrupts
on IRQ 7 (SMBus) are generated only for block data transfers, but not for
trackpoint / touchpad move actions. I have looked at pinctrl_amd and it 
looks,
that activity is signaled using GPIO. This looks promising:

cat /sys/kernel/debug/pinctrl/AMDI0030:00/pingroups:

group: i2c0
pin 145 (GPIO_145)
pin 146 (GPIO_146)

group: i2c1
pin 147 (GPIO_147)
pin 148 (GPIO_148)

group: i2c2
pin 113 (GPIO_113)
pin 114 (GPIO_114)

group: i2c3
pin 19 (GPIO_19)
pin 20 (GPIO_20)

After loading psmouse with forced enabled intertouch pin 19/20 started
generating events.

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

From: Wolfram Sang <wsa@kernel.org>
Date: 2022-01-06 12:52:17

Hi Miroslav,
On Thinkpad P14s gen 2 with AMD (model 21A00003CK, BIOS R1MET43W - 1.13) SMBus
address detection don't work and trackpoint has slow rate (30 Hz) because can't
use SMBus. Email is divided to SMBus and trackpoint section, there are issues in
both modules.
Do you think this is this the same issue as described in
https://bugzilla.kernel.org/show_bug.cgi?id=214597?

Thank you for your detailed analysis!

   Wolfram

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

From: Wolfram Sang <wsa@kernel.org>
Date: 2022-01-06 12:57:46

Hi again,
Address detection does not work because cd6h/cd7h port io can be
disabled, but it's accessible using mmio. This patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/
with modified AMD_PCI_SMBUS_REVISION_MMIO fixed base address
detection.
Okay, this patch is stalled because Terry is waiting for review
comments. I'll mention the high priority.
Problem with RMI4 touchpad / trackpoint remains, because rmi4-smbus
needs host notify feature. I have tried implement this feature,
without success. Interrupts on IRQ 7 (SMBus) are generated only for
block data transfers, but not for trackpoint / touchpad move actions.
I have looked at pinctrl_amd and it looks, that activity is signaled
using GPIO. This looks promising:
Isn't the interrupt described in the ACPI tables?

All the best,

   Wolfram

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

From: Miroslav Bendík <hidden>
Date: 2022-01-06 17:54:17

Hello,
Do you think this is this the same issue as described in
 > https://bugzilla.kernel.org/show_bug.cgi?id=214597  <https://bugzilla.kernel.org/show_bug.cgi?id=214597>?

Probably not.
Isn't the interrupt described in the ACPI tables?
Probably not. I am just web developer, i am not 100% sure, but i have not seen
anything usable in ACPI tables:
https://mireq.linuxos.sk/kernel/p14s_gen2_amd_acpi_tables.tar.xz

Most important section with SMBus is here:
https://lore.kernel.org/all/CAPoEpV0ZSidL6aMXvB6LN1uS-3CUHS4ggT8RwFgmkzzCiYJ-XQ@mail.gmail.com/

This section looked promising:

Scope (_SB.I2CB)
{
     Device (TPNL)
     {
         Name (_HID, "XXXX0000")  // _HID: Hardware ID
         Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */)  // _CID: Compatible ID
         Name (_S0W, 0x03)  // _S0W: S0 Device Wake State
         Name (HID2, 0x00)
         Name (POIO, 0x00)
         Name (SBFB, ResourceTemplate ()
         {
             I2cSerialBusV2 (0x0000, ControllerInitiated, 0x00061A80,
                 AddressingMode7Bit, "\\_SB.I2CB",
                 0x00, ResourceConsumer, _Y0C, Exclusive,
                 )
         })
         Name (SBFG, ResourceTemplate ()
         {
             GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                 "\\_SB.GPIO", 0x00, ResourceConsumer, ,
                 )
                 {   // Pin list
                     0x0005
                 }
         })
         CreateWordField (SBFB, \_SB.I2CB.TPNL._Y0C._ADR, BADR)  // _ADR: Address
         CreateDWordField (SBFB, \_SB.I2CB.TPNL._Y0C._SPE, SPED)  // _SPE: Speed
         Name (ITML, Package (0x0A)
         {
             Package (0x07)
             {
                 0x04F3,
                 0x2A3B,
                 0x10,
                 0x01,
                 0x01,
                 "ELAN901C",
                 0x01
             },


but method _STA returned 0x0 (device not present). There is no activity on pin
5. My device has synaptics trackpoint/touchpad, not elantech.  I think, that
this section is for touchscreen (not on my device).

More infomations to GPIO:

Following command does nothing if psmouse is loaded without synaptics_intertouch:

gpiomon --num-events=1000 gpiochip0 19

After loading psmouse with intertouch it catches constantly cca 2000 changes/s.
There are some changes like two rising / falling edges directly behind each
other. I think, that clok is much faster, than gpiomon monitoring speed,
catching communication with this command would be useless.

I don't know why there is constant communication from trackpoint/touchpad to
GPIO 19/20. Maybe some notification mechanism, attention, maybe something which
stops after clearing some bit, i dont know. Schematic from Lenovo, documentation
or anything useful wold be great, but whithout this i am just guessing.

Pins 19/20 should be SCL/SDA of I2C3 (from coreboot, id don't know source of pin
description:
https://github.com/coreboot/coreboot/blob/cf39336ccfcc363162395bddf65113900aaf19fe/src/soc/amd/cezanne/include/soc/gpio.h#L152

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

From: Andrea Ippolito <hidden>
Date: 2022-01-06 18:27:43

Hello Miroslav,

forgive me if it's a dumb question, but would this also apply to Intel
platforms, or this kind of stuff chip maker specific?

I got an Intel Tiger Lake.

Thanks!
Andrea IPPOLITO

Il giorno gio 6 gen 2022 alle ore 16:03 Miroslav Bendík
[off-list ref] ha scritto:
Address detection does not work because cd6h/cd7h port io can be
disabled, but
it's accessible using mmio. This patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/
with
modified AMD_PCI_SMBUS_REVISION_MMIO fixed base address detection.

Problem with RMI4 touchpad / trackpoint remains, because rmi4-smbus
needs host
notify feature. I have tried implement this feature, without success.
Interrupts
on IRQ 7 (SMBus) are generated only for block data transfers, but not for
trackpoint / touchpad move actions. I have looked at pinctrl_amd and it
looks,
that activity is signaled using GPIO. This looks promising:

cat /sys/kernel/debug/pinctrl/AMDI0030:00/pingroups:

group: i2c0
pin 145 (GPIO_145)
pin 146 (GPIO_146)

group: i2c1
pin 147 (GPIO_147)
pin 148 (GPIO_148)

group: i2c2
pin 113 (GPIO_113)
pin 114 (GPIO_114)

group: i2c3
pin 19 (GPIO_19)
pin 20 (GPIO_20)

After loading psmouse with forced enabled intertouch pin 19/20 started
generating events.

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

From: Miroslav Bendík <hidden>
Date: 2022-01-07 05:41:56

Hello,
forgive me if it's a dumb question, but would this also apply to Intel
platforms, or this kind of stuff chip maker specific?
this is specific problem with SMBus without host notify function. I don't know
if new intel hardware has problem with host notify.

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

From: Miroslav Bendík <hidden>
Date: 2022-01-08 18:42:34

Summary of synaptics_intertouch problem on Thinkpad with Ryzen 5850U:

Problem with wrong base address is fixed using this patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/

Second problem is, that RMI4 driver don't work with i2c-piix4, because 
it needs
I2C_FUNC_SMBUS_HOST_NOTIFY. I have added I2C_FUNC_SMBUS_HOST_NOTIFY to
piix4_func and psmouse can be loaded with synaptics_intertouch=1 
parameter. Here
is output with rmi_core debug_flags=0xfffd - https://pastebin.com/xGRHyyXV

Synaptics is on address 0x2c (value 0x58/0x59 in SMBus register, bit 1 
is r/w).
Command i2cdetect -l can see i2c busses:

i2cdetect -l
i2c-3   i2c             AMDGPU DM i2c hw bus 1                  I2C adapter
i2c-10  smbus           SMBus PIIX4 adapter port 2 at 0b00 SMBus adapter
i2c-1   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-8   i2c             AMDGPU DM aux hw bus 3                  I2C adapter
i2c-6   i2c             AMDGPU DM aux hw bus 0                  I2C adapter
i2c-4   i2c             AMDGPU DM i2c hw bus 2                  I2C adapter
i2c-11  smbus           SMBus PIIX4 adapter port 1 at 0b20 SMBus adapter
i2c-2   i2c             AMDGPU DM i2c hw bus 0                  I2C adapter
i2c-0   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-9   smbus           SMBus PIIX4 adapter port 0 at 0b00 SMBus adapter
i2c-7   i2c             AMDGPU DM aux hw bus 2                  I2C adapter
i2c-5   i2c             AMDGPU DM i2c hw bus 3                  I2C adapter

Device is visible on address 0x2c (output when psmouse is loaded with
smbus_intertouch):

i2cdetect -q -y 11
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I can add this call

i2c_handle_smbus_host_notify(piix4_aux_adapter, 0x2c);

to end of piix4_transaction and i have working touchpad / trackpoint. I can
move, i can click and evhz reports rate 100Hz, which is much better than 
39 with
PS/2 protocol. I know, this is endless loop, which generates on my 
machine 2000
interrupts/s and it can break some features like sleep.

Current state is, that everything works with one exception - cursor moved
/ click interrupt. I don't know which interrupt / pin generates this event.

Now what i have tried:

Interrupt line can be retrieved using ACPI. More informations and links 
to full
ACPI tables are here:
https://lore.kernel.org/all/CAPoEpV0ZSidL6aMXvB6LN1uS-3CUHS4ggT8RwFgmkzzCiYJ-XQ@mail.gmail.com/

I have added this code to end of piix_probe:

retval = devm_request_irq(&dev->dev, dev->irq, piix4_isr, IRQF_SHARED, 
"piix4_smbus", piix4_aux_adapter);
if (!retval) {
     printk(KERN_INFO "smbus Using irq %d\n", dev->irq);
}
else {
     printk(KERN_INFO "smbus No irq %d\n", dev->irq);
}

PCI IRQ is set, because i have added it to PCI quirks (temporary hack).
Synaptics is connected to aux adaptor, i am registering irq wit aux adapter.
I have added InterruptEnable call (bit 0) in SMBUSx02 SMBusControl register
(register numbers are from AMD BKDG
- https://www.amd.com/en/support/tech-docs?keyword=bkdg):

unsigned short piix4_smba = 0xb20;
outb_p(0x01, (0x02 + piix4_smba));

Now i have tried to check SMBusStatus and SMBusSlaveStatus in interrupt 
handler,
but they are not usable. First register is cleared directly in transfer
function, which is called before interrupt handler and second is always 
zero. It
looks, that interrupt is triggered only after data transfer, but not for 
host
notification event from slave.

I have added some print statements, to see, what happended. This code 
dumps registers:

static void piix4_dump_registers(struct i2c_adapter *piix4_adapter, char 
*label)
{
     struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(piix4_adapter);
     unsigned short piix4_smba = adapdata->smba;
     int i;
     u8 d[16];

     for (i = 0; i < 16; ++i) {
         if (i == 2 || i == 7)
             d[i] = 0;
         else
             d[i] = inb_p(i + piix4_smba);
     }

     printk(KERN_INFO "smb registers: %s    %02x%02x ...);
}

There are problems with reading form registers 2 and 7. It breaks 
communication,
i don't know why.

Now this is interrupt handler:

static irqreturn_t piix4_isr(int irq, void *dev_id)
{
     struct i2c_adapter *piix4_adapter = (struct i2c_adapter *)dev_id;
     piix4_dump_registers(piix4_adapter, "isr              ");

     return IRQ_HANDLED;
}

I have added piix4_dump_register after transaction, but before clearing 
status.
Output is on this link: https://pastebin.com/4mLBk0U7

After last line there is no output from RMI4/SMBus. Only this line has 
set 0x0a
register (SMBusSlaveEvent) which looks like event from slave. This line is
generated after transaction, but not from interrupt handler. Interrupt 
is not
called for slave events.

Now i have tried to enable interrupts from slave events. I have added 
this code
to probe function (again, numeric addresses, but i can find numbers 
faster in
reference documentation):

outb_p(0x80, (0x02 + piix4_smba)); // Reset to  SMBusControl
outb_p(0x01, (0x02 + piix4_smba)); // InterruptEnable to SMBusControl
outb_p(inb_p(0x01 + piix4_smba) | 0x02, (0x01 + piix4_smba)); // 
SlaveInit to  SMBusSlaveStatus

outb_p(0x2c << 1, (0x04 + piix4_smba)); // write 0x2c address ?
outb_p(0xff, (0x0a + piix4_smba)); // enable all slave events 
onSMBusSlaveEvent
outb_p(0xff, (0x0b + piix4_smba)); // enable all slave events
outb_p(inb_p(0x08 + piix4_smba) | 0x01, (0x08 + piix4_smba)); // SlaveEnable
outb_p(inb_p(0x08 + piix4_smba) | 0x08, (0x08 + piix4_smba)); // 
SMBusAlertEnable
outb_p(inb_p(0x08 + piix4_smba) | 0x02, (0x08 + piix4_smba)); // 
SMBusShadow1EN
outb_p(inb_p(0x08 + piix4_smba) | 0x04, (0x08 + piix4_smba)); // 
SMBusShadow2EN

I have tried other combinations, but without success. This part of 
documentation
looks like description of SMBus host notify:

SMBusShadow1En. Read-write. Reset: 0. Enable the generation of an 
interrupt or
resume event upon an external SMBus master generating a transaction with an
address that matches the SMBus Shadow 1 register.
SlaveEnable. Read-write. Reset: 0. Enable the generation of an interrupt or
resume event upon an external SMBus master generating a transaction with an
address that matches the host controller slave port of 10h, a command 
field that
matches the SMBus slave control register, and a match of corresponding 
enabled
events.

I don't know how should i exactly interpret this part. I don't know what is
SMBus slave control register. It looks like this part is copied from PIIX4
documentation from intel
(https://www.intel.com/Assets/PDF/datasheet/290562.pdf), but without exact
description how matching works.

I have looked at other options how to retrieve interrupt, for example 
amd_pinctl
GPIO. This looked promising:

cat /sys/kernel/debug/pinctrl/AMDI0030\:00/pingroups
registered pin groups:
group: i2c0
pin 145 (GPIO_145)
pin 146 (GPIO_146)

group: i2c1
pin 147 (GPIO_147)
pin 148 (GPIO_148)

group: i2c2
pin 113 (GPIO_113)
pin 114 (GPIO_114)

group: i2c3
pin 19 (GPIO_19)
pin 20 (GPIO_20)

Pins 19/20 are normally idle, but after loading psmouse with intertouch, 
then
there is constant activity (i can capture cca 2000 evnets/s using gpiomon,
frequency is probably much higher). I don't know if this is usable, but 
looks,
that this is i2c line from synaptics. I have not found interrupt pin.

On this link is output of gpiomon --num-events=5000  gpiochip0 19 20:
https://pastebin.com/B9XamDZA

This is everything, that i know. It thin, that i have forgotten some trivial
call, to unmask interrupt, but really, i don't know what. With working
interrupt, enabling RMI4 over piix4-smbus should be trivial.

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

From: Wolfram Sang <wsa@kernel.org>
Date: 2022-01-11 12:35:51

Summary of synaptics_intertouch problem on Thinkpad with Ryzen 5850U:
A pity the threads are a bit mixed, but some more information about
previous attempts can be found in this thread:

https://lore.kernel.org/r/42c83ec8-bbac-85e2-9ab5-87e59a679f95@redhat.com
Problem with wrong base address is fixed using this patch:
https://lore.kernel.org/all/20210715221828.244536-1-Terry.Bowman@amd.com/
This patch is under discussion again.

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

From: Miroslav Bendík <hidden>
Date: 2022-02-12 17:42:15

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.

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

From: Mario Limonciello <mario.limonciello@amd.com>
Date: 2024-10-10 16:25:21

On 2/12/2022 11:42, Miroslav Bendík wrote:
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.
Sorry to bump such an old thread, but AFAIK you never came up with a 
good solution here.  I did want to point out that there was a very 
recent submission by Shyam (CC'ed) [1] that adds an ASF driver (which is 
an extension to PIIX4).  By default it's going to bind to an ACPI ID 
that isn't present on your system (present on newer systems only) but 
the hardware for ASF /should/ be present even on yours.

So I was going to suggest if you still are interested in this to play 
with that series and come up with a way to force using ASF (perhaps by a 
DMI match for your system) and see how that goes.

[1] 
https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/

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

From: Miroslav Bendík <hidden>
Date: 2024-10-13 17:20:49

On 10. 10. 2024 18:25, Mario Limonciello wrote:
On 2/12/2022 11:42, Miroslav Bendík wrote:
quoted
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.
Sorry to bump such an old thread, but AFAIK you never came up with a 
good solution here.  I did want to point out that there was a very 
recent submission by Shyam (CC'ed) [1] that adds an ASF driver (which 
is an extension to PIIX4).  By default it's going to bind to an ACPI 
ID that isn't present on your system (present on newer systems only) 
but the hardware for ASF /should/ be present even on yours.

So I was going to suggest if you still are interested in this to play 
with that series and come up with a way to force using ASF (perhaps by 
a DMI match for your system) and see how that goes.

[1] 
https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/
Hello.

Thanks for the update. It looks good as a separate driver. I had 
intended to split this driver, replace polling with interrupts, and 
convert all I/O calls to MMIO, similar to how a Windows driver operates. 
I paused the work because I needed documentation and fixes from other 
companies, and I resolved my issue using a different approach:

- I have not received a response from Synaptics.
- I have not received a response from Lenovo.
- I have fixed the original issue - 
https://patchwork.kernel.org/project/linux-input/patch/71d9dc66-9576-c26f-c9d9-129217f50255@gmail.com/#24848525
- Too many subsystems are affected, some of which are currently hardly 
fixable.

The biggest issue is interrupt support, which cannot be resolved with 
quirks alone.

My device has this DSDT ACPI entry:

  Name (_HID, "SMB0001")  // _HID: Hardware ID
  Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
  {
      IO (Decode16,
          0x0B20,             // Range Minimum
          0x0B20,             // Range Maximum
          0x20,               // Alignment
          0x20,               // Length
          )
      IRQ (Level, ActiveLow, Shared, )
          {7}
  })

This entry defines the IRQ number, trigger, and polarity. However, the 
kernel ignores this entry and only uses the "Interrupt Source Override" 
from the MADT table. Here are some potential solutions:

- Scan ACPI for interrupts and include them in overrides
   - Scanning might break or fix many drivers. This is a significant 
change that could affect numerous buggy BIOS ACPI implementations.

- Change the interrupt trigger and polarity on the fly in the ASF driver
   - The interrupt trigger cannot be changed with irq_set_type because 
it lacks an ioapic_ir_chip.irq_set_type implementation

- Implement a new quirk or hook to modify interrupts
   - This would involve extending the quirk system to allow changes to 
polarity/trigger before APIC initialization.

- Add the missing MADT table
   - Lenovo ignores this requirement.

Fixing this bug might break trackpoint support on ThinkPads, as the 
Synaptics firmware does not behave as described in the documentation.

Given the high potential for system instability with minimal gain, my 
requested feature may not be worth pursuing.

I can maybe help with testing this new ASF driver on older hardware 
without specific ACPI ID.

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

From: Hans de Goede <hidden>
Date: 2024-10-13 17:53:33

Hi,

On 13-Oct-24 7:20 PM, Miroslav Bendík wrote:
On 10. 10. 2024 18:25, Mario Limonciello wrote:
quoted
On 2/12/2022 11:42, Miroslav Bendík wrote:
quoted
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.
Sorry to bump such an old thread, but AFAIK you never came up with a good solution here.  I did want to point out that there was a very recent submission by Shyam (CC'ed) [1] that adds an ASF driver (which is an extension to PIIX4).  By default it's going to bind to an ACPI ID that isn't present on your system (present on newer systems only) but the hardware for ASF /should/ be present even on yours.

So I was going to suggest if you still are interested in this to play with that series and come up with a way to force using ASF (perhaps by a DMI match for your system) and see how that goes.

[1] https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/
Hello.

Thanks for the update. It looks good as a separate driver. I had intended to split this driver, replace polling with interrupts, and convert all I/O calls to MMIO, similar to how a Windows driver operates. I paused the work because I needed documentation and fixes from other companies, and I resolved my issue using a different approach:

- I have not received a response from Synaptics.
- I have not received a response from Lenovo.
- I have fixed the original issue - https://patchwork.kernel.org/project/linux-input/patch/71d9dc66-9576-c26f-c9d9-129217f50255@gmail.com/#24848525
- Too many subsystems are affected, some of which are currently hardly fixable.

The biggest issue is interrupt support, which cannot be resolved with quirks alone.

My device has this DSDT ACPI entry:

 Name (_HID, "SMB0001")  // _HID: Hardware ID
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
     IO (Decode16,
         0x0B20,             // Range Minimum
         0x0B20,             // Range Maximum
         0x20,               // Alignment
         0x20,               // Length
         )
     IRQ (Level, ActiveLow, Shared, )
         {7}
 })

This entry defines the IRQ number, trigger, and polarity. However, the kernel ignores this entry and only uses the "Interrupt Source Override" from the MADT table.
Note that we already have a quirk table for this because this hits more
interrupts in the legacy ISA interrupt range, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/resource.c#n659

note that the MADT table is already alway skipped on AMD systems,
but currently only for IRQs 1/12 which are the PS/2 kbd + mouse
IRQs.

Regards,

Hans

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

From: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: 2024-10-14 16:01:55


On 10/13/2024 23:23, Hans de Goede wrote:
Hi,

On 13-Oct-24 7:20 PM, Miroslav Bendík wrote:
quoted
On 10. 10. 2024 18:25, Mario Limonciello wrote:
quoted
On 2/12/2022 11:42, Miroslav Bendík wrote:
quoted
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.
Sorry to bump such an old thread, but AFAIK you never came up with a good solution here.  I did want to point out that there was a very recent submission by Shyam (CC'ed) [1] that adds an ASF driver (which is an extension to PIIX4).  By default it's going to bind to an ACPI ID that isn't present on your system (present on newer systems only) but the hardware for ASF /should/ be present even on yours.

So I was going to suggest if you still are interested in this to play with that series and come up with a way to force using ASF (perhaps by a DMI match for your system) and see how that goes.

[1] https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/
Hello.

Thanks for the update. It looks good as a separate driver. I had intended to split this driver, replace polling with interrupts, and convert all I/O calls to MMIO, similar to how a Windows driver operates. I paused the work because I needed documentation and fixes from other companies, and I resolved my issue using a different approach:

- I have not received a response from Synaptics.
- I have not received a response from Lenovo.
- I have fixed the original issue - https://patchwork.kernel.org/project/linux-input/patch/71d9dc66-9576-c26f-c9d9-129217f50255@gmail.com/#24848525
- Too many subsystems are affected, some of which are currently hardly fixable.

The biggest issue is interrupt support, which cannot be resolved with quirks alone.
Do you mean the interrupt support from SMBus controller which happens
via the piix4 driver?

Note that SMBus controller do not support interrupt and the same has
been documented in the datasheet:

D14F0x03C [Interrupt Line] (FCH::SMBUSPCI::IntLine)

15:8 InterruptPin: Interrupt Pin. Read. Reset: Fixed,00h.

ValidValues:


Value 			Description
-------------		-------------
00h 			This module does not generate interrupts.
FFh-01h			Interrupt pin.

Thanks,
Shyam
quoted
My device has this DSDT ACPI entry:

 Name (_HID, "SMB0001")  // _HID: Hardware ID
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
     IO (Decode16,
         0x0B20,             // Range Minimum
         0x0B20,             // Range Maximum
         0x20,               // Alignment
         0x20,               // Length
         )
     IRQ (Level, ActiveLow, Shared, )
         {7}
 })

This entry defines the IRQ number, trigger, and polarity. However, the kernel ignores this entry and only uses the "Interrupt Source Override" from the MADT table.
Note that we already have a quirk table for this because this hits more
interrupts in the legacy ISA interrupt range, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/resource.c#n659

note that the MADT table is already alway skipped on AMD systems,
but currently only for IRQs 1/12 which are the PS/2 kbd + mouse
IRQs.

Regards,

Hans

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

From: Miroslav Bendík <hidden>
Date: 2024-10-14 16:43:11

On 14. 10. 2024 18:01, Shyam Sundar S K wrote:
On 10/13/2024 23:23, Hans de Goede wrote:
quoted
Hi,

On 13-Oct-24 7:20 PM, Miroslav Bendík wrote:
quoted
On 10. 10. 2024 18:25, Mario Limonciello wrote:
quoted
On 2/12/2022 11:42, Miroslav Bendík wrote:
quoted
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.
Sorry to bump such an old thread, but AFAIK you never came up with a good solution here.  I did want to point out that there was a very recent submission by Shyam (CC'ed) [1] that adds an ASF driver (which is an extension to PIIX4).  By default it's going to bind to an ACPI ID that isn't present on your system (present on newer systems only) but the hardware for ASF /should/ be present even on yours.

So I was going to suggest if you still are interested in this to play with that series and come up with a way to force using ASF (perhaps by a DMI match for your system) and see how that goes.

[1] https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/
Hello.

Thanks for the update. It looks good as a separate driver. I had intended to split this driver, replace polling with interrupts, and convert all I/O calls to MMIO, similar to how a Windows driver operates. I paused the work because I needed documentation and fixes from other companies, and I resolved my issue using a different approach:

- I have not received a response from Synaptics.
- I have not received a response from Lenovo.
- I have fixed the original issue - https://patchwork.kernel.org/project/linux-input/patch/71d9dc66-9576-c26f-c9d9-129217f50255@gmail.com/#24848525
- Too many subsystems are affected, some of which are currently hardly fixable.

The biggest issue is interrupt support, which cannot be resolved with quirks alone.
Do you mean the interrupt support from SMBus controller which happens
via the piix4 driver?

Note that SMBus controller do not support interrupt and the same has
been documented in the datasheet:

D14F0x03C [Interrupt Line] (FCH::SMBUSPCI::IntLine)

15:8 InterruptPin: Interrupt Pin. Read. Reset: Fixed,00h.

ValidValues:


Value 			Description
-------------		-------------
00h 			This module does not generate interrupts.
FFh-01h			Interrupt pin.

Thanks,
Shyam
Hello,

i am using ASF documentation (48751 Rev 3.03 - February 19, 2015 BKDG 
for AMD Family 16h Models 00h-0Fh Processors - 
https://www.amd.com/en/search/documentation/hub.html#q=BKDG%2048751).

There is a ASFx0A ASFStatus with SlaveIntr bit. Pointing device on my 
machine triggers interrupt 7 and it can be cleared using ASF when i move 
cursor using touchpad or trackpoint. It's possible to implement and 
enable I2C_CLIENT_HOST_NOTIFY flag on this hardware.

Another interrupt bit Intr from ASFx00 HostStatus is 1 after transfer 
(interrupt 7 is triggered). Transfer can be implemented without timers 
and active waiting on HostBusy status (there is a loop in 
piix4_transaction).

With regards
Miroslav Bendík
quoted
quoted
My device has this DSDT ACPI entry:

  Name (_HID, "SMB0001")  // _HID: Hardware ID
  Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
  {
      IO (Decode16,
          0x0B20,             // Range Minimum
          0x0B20,             // Range Maximum
          0x20,               // Alignment
          0x20,               // Length
          )
      IRQ (Level, ActiveLow, Shared, )
          {7}
  })

This entry defines the IRQ number, trigger, and polarity. However, the kernel ignores this entry and only uses the "Interrupt Source Override" from the MADT table.
Note that we already have a quirk table for this because this hits more
interrupts in the legacy ISA interrupt range, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/resource.c#n659

note that the MADT table is already alway skipped on AMD systems,
but currently only for IRQs 1/12 which are the PS/2 kbd + mouse
IRQs.

Regards,

Hans

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

From: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: 2024-10-15 11:58:54


On 10/14/2024 22:13, Miroslav Bendík wrote:
On 14. 10. 2024 18:01, Shyam Sundar S K wrote:
quoted
On 10/13/2024 23:23, Hans de Goede wrote:
quoted
Hi,

On 13-Oct-24 7:20 PM, Miroslav Bendík wrote:
quoted
On 10. 10. 2024 18:25, Mario Limonciello wrote:
quoted
On 2/12/2022 11:42, Miroslav Bendík wrote:
quoted
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.
Sorry to bump such an old thread, but AFAIK you never came up
with a good solution here.  I did want to point out that there
was a very recent submission by Shyam (CC'ed) [1] that adds an
ASF driver (which is an extension to PIIX4).  By default it's
going to bind to an ACPI ID that isn't present on your system
(present on newer systems only) but the hardware for ASF /should/
be present even on yours.

So I was going to suggest if you still are interested in this to
play with that series and come up with a way to force using ASF
(perhaps by a DMI match for your system) and see how that goes.

[1]
https://lore.kernel.org/all/20240923080401.2167310-1-Shyam-sundar.S-k@amd.com/
Hello.

Thanks for the update. It looks good as a separate driver. I had
intended to split this driver, replace polling with interrupts,
and convert all I/O calls to MMIO, similar to how a Windows driver
operates. I paused the work because I needed documentation and
fixes from other companies, and I resolved my issue using a
different approach:

- I have not received a response from Synaptics.
- I have not received a response from Lenovo.
- I have fixed the original issue -
https://patchwork.kernel.org/project/linux-input/patch/71d9dc66-9576-c26f-c9d9-129217f50255@gmail.com/#24848525
- Too many subsystems are affected, some of which are currently
hardly fixable.

The biggest issue is interrupt support, which cannot be resolved
with quirks alone.
Do you mean the interrupt support from SMBus controller which happens
via the piix4 driver?

Note that SMBus controller do not support interrupt and the same has
been documented in the datasheet:

D14F0x03C [Interrupt Line] (FCH::SMBUSPCI::IntLine)

15:8 InterruptPin: Interrupt Pin. Read. Reset: Fixed,00h.

ValidValues:


Value             Description
-------------        -------------
00h             This module does not generate interrupts.
FFh-01h            Interrupt pin.

Thanks,
Shyam
Hello,

i am using ASF documentation (48751 Rev 3.03 - February 19, 2015 BKDG
for AMD Family 16h Models 00h-0Fh Processors -
https://www.amd.com/en/search/documentation/hub.html#q=BKDG%2048751).
Hi,

You are referring the right document.
There is a ASFx0A ASFStatus with SlaveIntr bit. Pointing device on my
machine triggers interrupt 7 and it can be cleared using ASF when i
move cursor using touchpad or trackpoint. It's possible to implement
and enable I2C_CLIENT_HOST_NOTIFY flag on this hardware.
if you want I2C_CLIENT_HOST_NOTIFY flag, then that has to come via a
software_node property and I don't think we have near future thoughts
about having this in BIOS.
Another interrupt bit Intr from ASFx00 HostStatus is 1 after transfer
(interrupt 7 is triggered). Transfer can be implemented without timers
and active waiting on HostBusy status (there is a loop in
piix4_transaction).
Yeah, but this is what is being documented in the ASF databook and we
have to look at the SMBHSTSTS, based on that the further ASF packets
are processed.

Thanks,
Shyam
With regards
Miroslav Bendík
quoted
quoted
quoted
My device has this DSDT ACPI entry:

  Name (_HID, "SMB0001")  // _HID: Hardware ID
  Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
  {
      IO (Decode16,
          0x0B20,             // Range Minimum
          0x0B20,             // Range Maximum
          0x20,               // Alignment
          0x20,               // Length
          )
      IRQ (Level, ActiveLow, Shared, )
          {7}
  })

This entry defines the IRQ number, trigger, and polarity. However,
the kernel ignores this entry and only uses the "Interrupt Source
Override" from the MADT table.
Note that we already have a quirk table for this because this hits
more
interrupts in the legacy ISA interrupt range, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/resource.c#n659

note that the MADT table is already alway skipped on AMD systems,
but currently only for IRQs 1/12 which are the PS/2 kbd + mouse
IRQs.

Regards,

Hans
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help