On resume there can be a period of time after the
preceding serio_resume -> psmouse_deactivate call
where calls to rmi_smb_get_version fail with
-ENXIO.
The call path in rmi_smb_resume is rmi_smb_resume -> rmi_smb_reset ->
rmi_smb_enable_smbus_mode -> rmi_smb_get_version where
this failure would occur.
Adding a retry loop ensures that after rmi_smb_reset returns
the following rmi_driver_resume calls in rmi_smbus_resume can
succeed.
This behavior was seen on a Lenovo T440p machine that required
a delay of approximately 7-12ms.
The retry limit of 5 is chosen to be larger than
this observed delay.
With this patch the trimmed resume logs look similar to:
```
psmouse serio1: PM: calling serio_resume+0x0/0x8c @ 5399, parent: i8042
[5399] libps2:__ps2_command:316: psmouse serio1: f5 [] - 0/00000000 []
psmouse serio1: PM: serio_resume+0x0/0x8c returned 0 after 3259 usecs
...
rmi4_smbus 0-002c: PM: calling rmi_smb_resume ... @ 5454, parent: i2c-0
...
[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_smbus 0-002c: sleeping to retry getting the SMBus version number
...
rmi4_smbus 0-002c: PM: rmi_smb_resume ... returned 0 after 21351 usecs
```
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. 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.
drivers/input/rmi4/rmi_smbus.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
index 4bf0e1df6a4a..386e80ae141b 100644
--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -43,15 +43,26 @@ static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
{
struct i2c_client *client = rmi_smb->client;
int retval;
+ int tries = 0;
/* Check if for SMBus new version device by reading version byte. */
- retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
- if (retval < 0) {
- dev_err(&client->dev, "failed to get SMBus version number!\n");
- return retval;
- }
+ do {
+ if (tries > 0) {
+ dev_warn(&client->dev, "sleeping to retry getting the SMBus version number\n");
+ fsleep(5000);
+ }
+ retval = i2c_smbus_read_byte_data(client,
+ SMB_PROTOCOL_VERSION_ADDRESS);
+ if (retval >= 0)
+ return retval + 1;
- return retval + 1;
+ dev_err(&client->dev, "failed to get SMBus version number!\n");
+ /* On resume the read of the version can
+ * momentarily return -ENXIO.
+ * Retry to allow additional time for it to succeed.
+ */
+ } while (retval == -ENXIO && tries++ < 5);
+ return retval;
}
/* SMB block write - wrapper over ic2_smb_write_block */
--
2.40.1.606.ga4b1b128d6-goog
On Wed, May 10, 2023 at 07:27:22PM +0000, Jeffery Miller wrote:
> On resume there can be a period of time after the
> preceding serio_resume -> psmouse_deactivate call
> where calls to rmi_smb_get_version fail with
> -ENXIO.
>
> The call path in rmi_smb_resume is rmi_smb_resume -> rmi_smb_reset ->
> rmi_smb_enable_smbus_mode -> rmi_smb_get_version where
> this failure would occur.
>
> Adding a retry loop ensures that after rmi_smb_reset returns
> the following rmi_driver_resume calls in rmi_smbus_resume can
> succeed.
>
> This behavior was seen on a Lenovo T440p machine that required
> a delay of approximately 7-12ms.
> The retry limit of 5 is chosen to be larger than
> this observed delay.
>
> With this patch the trimmed resume logs look similar to:
> ```
> psmouse serio1: PM: calling serio_resume+0x0/0x8c @ 5399, parent: i8042
> [5399] libps2:__ps2_command:316: psmouse serio1: f5 [] - 0/00000000 []
> psmouse serio1: PM: serio_resume+0x0/0x8c returned 0 after 3259 usecs
> ...
> rmi4_smbus 0-002c: PM: calling rmi_smb_resume ... @ 5454, parent: i2c-0
> ...
> [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_smbus 0-002c: sleeping to retry getting the SMBus version number
> ...
> rmi4_smbus 0-002c: PM: rmi_smb_resume ... returned 0 after 21351 usecs
> ```
>
> 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.
I am not really fond of adding random repeats in the code base. Andrew,
do you know if the Synaptics device needs certain delay when switching
to SMbus mode?
Thanks.
--
Dmitry
On Wed, May 10, 2023 at 3:06 PM Dmitry Torokhov
<[email protected]> wrote:
>
>
> I am not really fond of adding random repeats in the code base. Andrew,
> do you know if the Synaptics device needs certain delay when switching
> to SMbus mode?
>
That's reasonable. It's true this is a sleep to workaround rmi_smbus'
expectation that
it is able to successfully read from the i801 i2c smbus addr 0x2c on resume
when it cannot.
I do not know why the i801 i2c addr 0x2c is not responding on resume.
Infrequently it won't respond on boot during the initial
psmouse_smbus_create_companion but that is less noticeable since
it will stay in ps/2 mode and just lack features.
I do know adding a sleep in-between the psmouse deactivate call
and rmi_smbus's attempts to read from the 0x2c addr allow it to
succeed on this machine. I do not know the details as to why however.
I can apply workarounds until the underlying issue can be
identified and properly resolved.
I can apply patches and provide any sort of debugging or extra information that
might be useful to anyone familiar with these devices.
The smbus controller in this particular machine is:
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset
Family SMBus Controller [8086:8c22] (rev 04)
Perhaps there's some way to detect when the addr is available later
and have it trigger a new probe similar to how psmouse_smbus_notifier
is triggered when the i801 bus becomes available?
Thank You,
Jeff
> From: Jeffery Miller <[email protected]>
> Sent: Friday, May 12, 2023 12:37
> To: Dmitry Torokhov <[email protected]>
> Cc: Andrew Duggan <[email protected]>; Jonathan Denose
> <[email protected]>; [email protected]; Lyude Paul
> <[email protected]>; [email protected];
> [email protected]; Andrew Duggan
> <[email protected]>; Jonathan Cameron
> <[email protected]>; Maximilian Luz
> <[email protected]>; Miguel Ojeda <[email protected]>; Uwe Kleine-
> König <[email protected]>; [email protected];
> [email protected]
> Subject: Re: [PATCH] Input: synaptics-rmi4 - retry reading SMBus version on
> resume
>
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
> On Wed, May 10, 2023 at 3:06 PM Dmitry Torokhov
> <[email protected]> wrote:
> >
> >
> > I am not really fond of adding random repeats in the code base.
> > Andrew, do you know if the Synaptics device needs certain delay when
> > switching to SMbus mode?
> >
> That's reasonable. It's true this is a sleep to workaround rmi_smbus'
> expectation that
> it is able to successfully read from the i801 i2c smbus addr 0x2c on resume
> when it cannot.
>
> I do not know why the i801 i2c addr 0x2c is not responding on resume.
> Infrequently it won't respond on boot during the initial
> psmouse_smbus_create_companion but that is less noticeable since it will
> stay in ps/2 mode and just lack features.
>
> I do know adding a sleep in-between the psmouse deactivate call and
> rmi_smbus's attempts to read from the 0x2c addr allow it to succeed on this
> machine. I do not know the details as to why however.
Our Windows driver does a 30 ms delay between sending the disable command and trying to communicate over SMBus. I don’t know specifically why this delay is needed, but this is how we handle this case.
>
> I can apply workarounds until the underlying issue can be identified and
> properly resolved.
>
> I can apply patches and provide any sort of debugging or extra information
> that might be useful to anyone familiar with these devices.
>
> The smbus controller in this particular machine is:
> 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family
> SMBus Controller [8086:8c22] (rev 04)
>
> Perhaps there's some way to detect when the addr is available later and have
> it trigger a new probe similar to how psmouse_smbus_notifier is triggered
> when the i801 bus becomes available?
>
> Thank You,
> Jeff
Andrew