From 0cdba07bb23cdd3e0d64357ec3d983e6b75e541f Mon Sep 17 00:00:00 2001 From: Dave Airlie Date: Tue, 5 May 2009 08:39:24 +0200 Subject: i2c-algo-bit: Fix timeout test When fetching DDC using i2c algo bit, we were often seeing timeouts before getting valid EDID on a retry. The VESA spec states 2ms is the DDC timeout, so when this translates into 1 jiffie and we are close to the end of the time period, it could return with a timeout less than 2ms. Change this code to use time_after instead of time_after_eq. Signed-off-by: Dave Airlie Signed-off-by: Jean Delvare --- drivers/i2c/algos/i2c-algo-bit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/i2c/algos') diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c index d420cc5f5633..e25e13980af3 100644 --- a/drivers/i2c/algos/i2c-algo-bit.c +++ b/drivers/i2c/algos/i2c-algo-bit.c @@ -104,7 +104,7 @@ static int sclhi(struct i2c_algo_bit_data *adap) * chips may hold it low ("clock stretching") while they * are processing data internally. */ - if (time_after_eq(jiffies, start + adap->timeout)) + if (time_after(jiffies, start + adap->timeout)) return -ETIMEDOUT; cond_resched(); } -- cgit v1.2.3 From 2196d1cf4afab93fb64c2e5b417096e49b661612 Mon Sep 17 00:00:00 2001 From: Enrik Berkhan Date: Tue, 5 May 2009 08:39:25 +0200 Subject: i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30) Currently, the i2c-algo-pca driver does nothing if the chip enters state 0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been received). Thus, the i2c bus connected to the controller gets stuck afterwards. I have seen this kind of error on a custom board in certain load situations most probably caused by interference or noise. A possible reaction is to let the controller generate a STOP condition. This is documented in the PCA9564 data sheet (2006-09-01) and the same is done for other NACK states as well. Further, state 0x38 isn't handled completely, either. Try to do another START in this case like the data sheet says. As this couldn't be tested, I've added a comment to try to reset the chip if the START doesn't help as suggested by Wolfram Sang. Signed-off-by: Enrik Berkhan Reviewed-by: Wolfram Sang Signed-off-by: Jean Delvare --- drivers/i2c/algos/i2c-algo-pca.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'drivers/i2c/algos') diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c index 6318f7ddc1d4..78d42aae0089 100644 --- a/drivers/i2c/algos/i2c-algo-pca.c +++ b/drivers/i2c/algos/i2c-algo-pca.c @@ -287,10 +287,21 @@ static int pca_xfer(struct i2c_adapter *i2c_adap, case 0x30: /* Data byte in I2CDAT has been transmitted; NOT ACK has been received */ DEB2("NOT ACK received after data byte\n"); + pca_stop(adap); goto out; case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */ DEB2("Arbitration lost\n"); + /* + * The PCA9564 data sheet (2006-09-01) says "A + * START condition will be transmitted when the + * bus becomes free (STOP or SCL and SDA high)" + * when the STA bit is set (p. 11). + * + * In case this won't work, try pca_reset() + * instead. + */ + pca_start(adap); goto out; case 0x58: /* Data byte has been received; NOT ACK has been returned */ -- cgit v1.2.3