From: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> In the lack of a better spec, let's assume the timeout values compatible with SMBus spec: http://smbus.org/specs/smbus110.pdf at chapter 8 - Electrical Characteristics of SMBus devices Ok, SMBus is a subset of I2C, and not all devices will be following it, but the timeout value before this patch was not even following the spec. So, while we don't have a better guess for it, use 35 + 1 ms as the timeout. Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> --- drivers/media/usb/em28xx/em28xx.h | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h index db47c2236ca4..9af19332b0f1 100644 --- a/drivers/media/usb/em28xx/em28xx.h +++ b/drivers/media/usb/em28xx/em28xx.h @@ -183,8 +183,21 @@ #define EM28XX_INTERLACED_DEFAULT 1 -/* time in msecs to wait for i2c xfers to finish */ -#define EM2800_I2C_XFER_TIMEOUT 20 +/* + * Time in msecs to wait for i2c xfers to finish. + * 35ms is the maximum time a SMBUS device could wait when + * clock stretching is used. As the transfer itself will take + * some time to happen, set it to 35 ms. + * + * Ok, I2C doesn't specify any limit. So, eventually, we may need + * to increase this timeout. + * + * FIXME: this assumes that an I2C message is not longer than 1ms. + * This is actually dependent on the I2C bus speed, although most + * devices use a 100kHz clock. So, this assumtion is true most of + * the time. + */ +#define EM2800_I2C_XFER_TIMEOUT 36 /* time in msecs to wait for AC97 xfers to finish */ #define EM2800_AC97_XFER_TIMEOUT 100 -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
