Jean-Christophe PLAGNIOL-VILLARD schrieb:
On 16:50 Fri 04 Jul , Jens Gehrlein wrote:
On fast CPUs the time between two chip queries can become too short to issue clear start and stop conditions. The bus seems to be blocked. This cannot be compensated by just waiting for completed byte transfer. The patch introduces polling of the bus busy bit in the I2C controller's status register before the next bus access is possible.
Signed-off-by: Jens Gehrlein sew_s@tqs.de
drivers/i2c/mxc_i2c.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index a218329..6f9306f 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -115,6 +115,16 @@ static int rx_byte(void) int i2c_probe(uchar chip) { int ret;
- int timeout = 100000;
Could you explain why 100000?
/* Check if bus is busy before probing next chip */
while ((__REG16(I2C_BASE + I2SR) & I2SR_IBB) && --timeout)
udelay(1);if (timeout == 0) {
printf ("\nerror: bus blocked\n");return -1;}
__REG16(I2C_BASE + I2CR) = 0; /* Reset module */ __REG16(I2C_BASE + I2CR) = I2CR_IEN;
You are right. 100 ms is too high, although it should be irrelevant for a U-Boot command. Measurement showed, that some 100 microseconds would be enough. Do you agree if I set the timeout value to 1 ms? Other proposals?
Kind regards, Jens