There is a UCD90320(TI) connected t1042 by i2c on our board. And t1042 accesses it by pmbus protocol. Sometimes we found t1042 tied SCL low more than 35ms. And this issue is very easy to reproduce this by running "echo 1 > /sys/bus/pci/rescan".
Attachment is i2c access waveform. SCL tied low more than 35ms before t1042 issue i2c stop. Linux kernel version is 4.14.
Does rescanning pcie device freeze t1042 a little while? Any other conditions would freeze t1042? thanks.
Please share below:
1. Frequency of operation of I2C
2. Do system have more than one device on bus?
3. does this scenario happen during single rescan command or this command is issued multiple time back to back?
Hi yiping,
Answer your questions:
1. I2C frequency is 100KHz.
2. There are more than 10 i2c slave devices connected by i2c switch(TCA9548A) on bus1.
3. rescan command is issued multiple time back to back.
Thanks for the response.
From the waveform shared it looks that i2c transaction resume automatically after 35ms.
1. Does i2C resume without any intervention?
2. Does this scenario is with all the other devices connected on the MUX or only with the specific device?
3. Please check erratum A-006037 if I2CCR[MEN] bit is toggled?
4. DO customer observe any functional issue with this?
Hi Yiping,
Yes. i2c transaction resume after 35ms because card rebooted.
1. It resumes by card reboot.
2. All devices connected on the MUX.
3. I don't think it's the similar issue with A-006037. This issue happens on almost all cards. i2c transaction is successful even SCL low 35ms on most of cards. But some cards rebooted after SCL low 35ms.
4. It causes specific card reboot.
Few more clarifications: