Vignesh, On 10/07/15 08:09, Vignesh R wrote: > When system is under load and there is an i2c transaction running > following warning appears on the console: > > [ 730.003617] omap_i2c 48070000.i2c: controller timed out > [ 731.023643] omap_i2c 48070000.i2c: controller timed out > > This is because, the completion() call, which is done in bottom half of > the interrupt handler, happens after the timeout period(1s) has elapsed > for the wait_for_completion_timeout() in omap_i2c_xfer_msg(). The > interrupt is raised within a second but due to system load (or other > interrupts), the bottom half does not get scheduled within a second. > Hence even though the interrupt has happened within required time frame, > due to delayed scheduling of bottom half, spurious timeout errors are > reported on the console and i2c controller is reset. > > i2c timeout is a rare condition, hence increase timeout to 60s in order > to avoid reporting false timeout events under load. why not 5s instead of 60s? cheers, -roger > > Signed-off-by: Vignesh R <vigneshr@xxxxxx> > --- > > I reproduced this while running i2cdump in a loop and reading from flash > using dd command. > > drivers/i2c/busses/i2c-omap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index d1c22e3fdd14..fa7758f0302c 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -50,7 +50,7 @@ > #define OMAP_I2C_REV_ON_4430_PLUS 0x50400002 > > /* timeout waiting for the controller to respond */ > -#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) > +#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(60 * 1000)) > > /* timeout for pm runtime autosuspend */ > #define OMAP_I2C_PM_TIMEOUT 1000 /* ms */ > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
