tcpci gets error -110 in tcpci_probe on regmap_raw_write

[dmitry_sidorenkov]

board a custom board based on im8qm with 6Gb ram
Android 12.1
kernel 5.15.52

Board can't pass probe of usb-c ptn5110 device which is used for Android adb after shut down and turn on in 2 seconds by SW1 button.
The issue log:
[ 5.463252][ T10] tcpci: probe of 4-0051 failed with error -110

[dmitry_sidorenkov]

After adding a delay 10s less then 2 times(added usleep_range(6000000, 8000000)) and it didn't help and tcpci was not initialized with the next logs.
So perhaps there is something in kernel code that holds SDA low, but it may be related to HW differences but it is also related to kernel code.

[    4.232884][   T10] i2c i2c-3: LPI2C adapter registered
[    4.238689][   T10] imx-lpi2c 5a800000.i2c: use pio mode
[    4.244360][   T10] i2c 4-0051: Fixing up cyclic dependency with 5b130000.usb
[    5.258471][   T10] tcpci 4-0051: Failed to regmap_raw_write (-ETIMEDOUT), attempt:1
[    5.266221][   T10] tcpci 4-0051: Wait the next attempt for 10s
[   14.278486][   T10] tcpci 4-0051: Failed to regmap_raw_write (-ETIMEDOUT), attempt:2
[   14.286236][   T10] tcpci 4-0051: Wait the next attempt for 10s
[   22.290515][   T10] tcpci: probe of 4-0051 failed with error -110
[   22.296819][   T10] i2c i2c-4: LPI2C adapter registered

[dmitry_sidorenkov]

But returning EPROBE_DEFER helps, so it means the issue is related to the drivers init order

err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, &val, sizeof(u16));
if (err < 0)
return -EPROBE_DEFER;

[Zhiming_Liu]

Hi @dmitry_sidorenkov 

Does this issue occurs only after adb shutdown->turn on? You can't see it during normal bootup, right?

[dmitry_sidorenkov]

yes, it does, on reboot it doesn't happen.

[Zhiming_Liu]

From the software side, the i2c communication is timeout. So you may need check the hardware waveforms when use adb shutdown.

[dmitry_sidorenkov]

For what state of board should I check i2c waveforms?
Do you mean that i2c isn't not ready when tcpci goes probe()?

[Zhiming_Liu]

For what state of board should I check i2c waveforms?

-->Check all pins status about ptn5110 

Yes, the  -110 means timeout when use regmap framework, so it can't communicate with soc.

[dmitry_sidorenkov]

I disabled the second i2c connected device cs43l21 and noticed a strange behavior about i2c.
Tested with oscilloscope:
- General case: in a cold boot case there is some work on i2c on u-boot stage and kernel probe drivers stage.
- Issue case: there is no i2c actions on u-boot stage and on kernel probe drivers stage.
Also attached a plain from logic analyzer when the ptn5110 is single on i2c
Also if there would the the second i2c device (cs43l21) then it could work fine somehow.
The issue is that SDA is kept down for about 10 seconds

 

 

[Zhiming_Liu]

Hi @dmitry_sidorenkov 

From the oscilloscope test result, the i2c bus SDA stuck in LOW, which we call it has been locked up.

There are two ways to avoid such issue:

1. Connect slave device which has RESET pin(ptn5110 not, but cs43l21 has)

2.Send nine clock pluse when SDA stuck in LOW

Reference: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

[dmitry_sidorenkov]

I've added related pins to enable a recovery feature

&i2c0 {
...
pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c0>;
pinctrl-1 = <&pinctrl_i2c0_gpio>;
scl-gpios = <&lsio_gpio2 2 GPIO_ACTIVE_HIGH>;
sda-gpios = <&lsio_gpio2 3 GPIO_ACTIVE_HIGH>;
...
}
pinctrl_i2c0: i2c0grp {
fsl,pins = <
IMX8QM_HDMI_TX0_TS_SCL_DMA_I2C0_SCL 0x06000021
IMX8QM_HDMI_TX0_TS_SDA_DMA_I2C0_SDA 0x06000021
>;
};
pinctrl_i2c0_gpio: i2c1grp-gpio {
fsl,pins = <
IMX8QM_HDMI_TX0_TS_SCL_LSIO_GPIO2_IO02 0x06000020
IMX8QM_HDMI_TX0_TS_SDA_LSIO_GPIO2_IO03 0x06000020
>;
};

It has caused getting two new lines in logs during the failing line

 /* Disable chip interrupts before requesting irq */
err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, &val,
sizeof(u16));

 new logs are:

[ 4.775545][ T8] i2c i2c-4: SCL is stuck low, exit recovery
[ 5.283545][ T8] i2c i2c-4: SCL is stuck low, exit recovery

But actually a real SCL level is high for all time, see the previously attached image.

I think as a some workaround I can add usleep_range(1000000, 12000000); into a probing of tcpci device.

[Zhiming_Liu]

Hi @dmitry_sidorenkov 

Have you tested it on MEK? Please provide test steps and share the log difference you found.

[dmitry_sidorenkov]

can't reproduce it on mek, but mek works differently i.e. it doesn't turn off power supplies, fan when kernel causes power off

[Zhiming_Liu]

Can you share your schematic with private message?