Hello,
i have encounter several I2C timeout issues on an AVNET picoZed Z7020 board when accessing an I2C device using a real-time kernel when booting the device.
I.e. at each 3-5 reboots an I2C timeout occurs and the I2C device must be restarted in order to get the I2C working again. However, restarting the I2C device is not feasible for us.
The problem happens also on non-real-time kernels but much less frequent, i.e. roughly at 1 of 100 reboots the error occurs.
The error which is reported is following:
cdns-i2c e0004000.ps7-i2c: timeout waiting on completionDuring the Linux boot (4.14.24), a program on the Linux system is started which transceives quite a large amount of data to the I2C device (but only max. 261 bytes at once over I2C).
I do not think that this is an HW issue since it works in a few times. However, I have tried to change the pullups for the I2C device from 1k to 2k without any success. (Next will be to increase the pullups to 4k.)
What I have figured out is that when the program (which transceives the I2C data during boot) on the Linux system is "interrupted" by another program (which has nothing to do with an I2C access at all, e.g. apache2) the timeout occurs.
The interruption takes place when waiting within the I2C cadence driver' cdns_i2c_process_msg() function I think which results that cdns_i2c_mrecv does not return any data within the given adap->timeout (1000ms / 250 jiffies).
[...] cdns_i2c_mrecv(id); [...] /* Wait for the signal of completion */ time_left = wait_for_completion_timeout(&id->xfer_done, adap->timeout); [...]
/* * Cadence I2C controller has a bug wherein it generates * invalid read transaction after HW timeout in master receiver mode. * HW timeout is not used by this driver and the interrupt is disabled. * But the feature itself cannot be disabled. Hence maximum value * is written to this register to reduce the chances of error. */
