There is a period of time between the psmouse deactivate and the
ability to communicate with the SMBus companion. Insert a
sleep after the deactivate to account for the delay and ensure
the SMBus companion is responsive.
Attempting to read from the SMBus companion too quickly was causing
the touchpad on machines with an i801_smbus companion to stop working
after a sleep/resume cycle.
On resume the rmi4_smbus would fail with errors reading the SMBus version
number:
```
[5454] i2c_i801:i801_check_post:414: i801_smbus 0000:00:1f.3: No response
smbus_result: i2c-0 a=02c f=0000 c=fd BYTE_DATA rd res=-6
rmi4_smbus 0-002c: failed to get SMBus version number!
...
rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6.
rmi4_f01 rmi4-00.fn01: Resume failed with code -6.
rmi4_physical rmi4-00: Failed to suspend functions: -6
rmi4_smbus 0-002c: Failed to resume device: -6
```
In this case the rmi_smb_get_version fails with -ENXIO if it happens too
soon after the preceding serio_resume -> psmouse_deactivate call.
On boot this issue could cause the touchpad to stay in the limited PS/2
mode. This only reproduced in 1 in 10 boots on the Lenovo T440p.
Failures in the log on boot would show up as:
```
psmouse serio1: synaptics: Trying to set up SMBus access
[122] i2c_i801:i801_check_post:437: i801_smbus 0000:00:1f.3: No response
psmouse serio1: synaptics: SMbus companion is not ready yet
```
Experimentation on the Lenovo T440p showed that a delay of 7-12ms on
resume allowed the companion to respond.
The 30ms delay in this patch was chosen based on the linux-input message:
Link: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@BYAPR03MB4757.namprd03.prod.outlook.com/
Signed-off-by: Jeffery Miller <[email protected]>
---
Early boot dmesg include:
```
rmi4_smbus 0-002c: registering SMbus-connected sensor
rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2722-001, fw id: 0
```
The resume order looks correct. The `psmouse serio1` resume returns
before the rmi_smb_resume is called showing the patch from
https://lore.kernel.org/all/[email protected]/
is applied and working for that ordering.
I attempted to try to rule out some interaction between the concurrent
input resume calls for other i8042 devices.
Adding a 7ms delay after psmouse_deactivate which is called in the
preceding psmouse serio1 serio_resume function also allows
this version call to succeed.
If the rmi_smb_probe device_disable_async_suspend patch is applied
it will also avoid this issue on resume. However the time between
the psmouse_deactivate call for serio_resume and rmi_smb_resume
was over 60ms on my test machine. This would naturally be long
enough to avoid this particular delay.
Changes in v4:
- Moved the delay out of rmi4_smbus to psmouse_smbus based on review
comments. This also fixes an issue at boot time.
Changes in v3:
- Tagged mail message Link to resolve checkpatch warning.
Changes in v2:
- Changed to a single retry of 30ms based on previous feedback.
drivers/input/mouse/psmouse-smbus.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/input/mouse/psmouse-smbus.c b/drivers/input/mouse/psmouse-smbus.c
index 2a2459b1b4f2..7b13de979908 100644
--- a/drivers/input/mouse/psmouse-smbus.c
+++ b/drivers/input/mouse/psmouse-smbus.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/libps2.h>
@@ -118,13 +119,18 @@ static psmouse_ret_t psmouse_smbus_process_byte(struct psmouse *psmouse)
return PSMOUSE_FULL_PACKET;
}
-static int psmouse_smbus_reconnect(struct psmouse *psmouse)
+static void psmouse_activate_smbus_mode(struct psmouse_smbus_dev *smbdev)
{
- struct psmouse_smbus_dev *smbdev = psmouse->private;
-
- if (smbdev->need_deactivate)
- psmouse_deactivate(psmouse);
+ if (smbdev->need_deactivate) {
+ psmouse_deactivate(smbdev->psmouse);
+ /* Give the device time to switch into SMBus mode */
+ msleep(30);
+ }
+}
+static int psmouse_smbus_reconnect(struct psmouse *psmouse)
+{
+ psmouse_activate_smbus_mode(psmouse->private);
return 0;
}
@@ -257,8 +263,7 @@ int psmouse_smbus_init(struct psmouse *psmouse,
}
}
- if (need_deactivate)
- psmouse_deactivate(psmouse);
+ psmouse_activate_smbus_mode(smbdev);
psmouse->private = smbdev;
psmouse->protocol_handler = psmouse_smbus_process_byte;
--
2.41.0.487.g6d72f3e995-goog
On Wed, Jul 26, 2023 at 02:52:48AM +0000, Jeffery Miller wrote:
> There is a period of time between the psmouse deactivate and the
> ability to communicate with the SMBus companion. Insert a
> sleep after the deactivate to account for the delay and ensure
> the SMBus companion is responsive.
>
> Attempting to read from the SMBus companion too quickly was causing
> the touchpad on machines with an i801_smbus companion to stop working
> after a sleep/resume cycle.
>
> On resume the rmi4_smbus would fail with errors reading the SMBus version
> number:
> ```
> [5454] i2c_i801:i801_check_post:414: i801_smbus 0000:00:1f.3: No response
> smbus_result: i2c-0 a=02c f=0000 c=fd BYTE_DATA rd res=-6
> rmi4_smbus 0-002c: failed to get SMBus version number!
> ...
> rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6.
> rmi4_f01 rmi4-00.fn01: Resume failed with code -6.
> rmi4_physical rmi4-00: Failed to suspend functions: -6
> rmi4_smbus 0-002c: Failed to resume device: -6
> ```
> In this case the rmi_smb_get_version fails with -ENXIO if it happens too
> soon after the preceding serio_resume -> psmouse_deactivate call.
>
> On boot this issue could cause the touchpad to stay in the limited PS/2
> mode. This only reproduced in 1 in 10 boots on the Lenovo T440p.
> Failures in the log on boot would show up as:
> ```
> psmouse serio1: synaptics: Trying to set up SMBus access
> [122] i2c_i801:i801_check_post:437: i801_smbus 0000:00:1f.3: No response
> psmouse serio1: synaptics: SMbus companion is not ready yet
> ```
>
> Experimentation on the Lenovo T440p showed that a delay of 7-12ms on
> resume allowed the companion to respond.
>
> The 30ms delay in this patch was chosen based on the linux-input message:
> Link: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@BYAPR03MB4757.namprd03.prod.outlook.com/
>
> Signed-off-by: Jeffery Miller <[email protected]>
Applied, thank you.
--
Dmitry