Am 04.01.2014 11:55, schrieb Mauro Carvalho Chehab: > changeset 45f04e82d035 added a logic to check if em28xx got > a timeout on an I2C transfer. > > That patch started to produce a series of errors that is present > with HVR-950, like: > > [ 4032.218656] xc2028 19-0061: Error on line 1299: -19 > > However, as there are several places where -ENODEV is produced, > there's no way to know what's happening. > > So, let's add a printk to report what error condition was reached: > > [ 4032.218652] em2882/3 #0: I2C transfer timeout on writing to addr 0xc2 > [ 4032.218656] xc2028 19-0061: Error on line 1299: -19 > > Interesting enough, when connected to an USB3 port, the number of > errors increase: > > [ 4249.941375] em2882/3 #0: I2C transfer timeout on writing to addr 0xb8 > [ 4249.941378] tvp5150 19-005c: i2c i/o error: rc == -19 (should be 2) > [ 4250.023854] em2882/3 #0: I2C transfer timeout on writing to addr 0xc2 > [ 4250.023857] xc2028 19-0061: Error on line 1299: -19 > > Due to that, I suspect that the logic in the driver is wrong: instead > of just returning an error if 0x10 is returned, it should be waiting for > a while and read the I2C status register again. > > However, more tests are needed. The patch description isn't up-to-date. It turned out that the bug is in the xc2028 driver.
See http://www.spinics.net/lists/linux-media/msg71107.html > > For now, instead of just returning -ENODEV, output an error message > to help debug what's happening. > > Signed-off-by: Mauro Carvalho Chehab <m.che...@samsung.com> > --- > drivers/media/usb/em28xx/em28xx-i2c.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c > b/drivers/media/usb/em28xx/em28xx-i2c.c > index c4ff9739a7ae..9e6a11d01858 100644 > --- a/drivers/media/usb/em28xx/em28xx-i2c.c > +++ b/drivers/media/usb/em28xx/em28xx-i2c.c > @@ -80,6 +80,7 @@ static int em2800_i2c_send_bytes(struct em28xx *dev, u8 > addr, u8 *buf, u16 len) > if (ret == 0x80 + len - 1) { > return len; > } else if (ret == 0x94 + len - 1) { > + em28xx_warn("R05 returned 0x%02x: I2C timeout", ret); > return -ENODEV; > } else if (ret < 0) { > em28xx_warn("failed to get i2c transfer status from > bridge register (error=%i)\n", > @@ -123,6 +124,7 @@ static int em2800_i2c_recv_bytes(struct em28xx *dev, u8 > addr, u8 *buf, u16 len) > if (ret == 0x84 + len - 1) { > break; > } else if (ret == 0x94 + len - 1) { > + em28xx_warn("R05 returned 0x%02x: I2C timeout", ret); > return -ENODEV; > } else if (ret < 0) { > em28xx_warn("failed to get i2c transfer status from > bridge register (error=%i)\n", > @@ -198,6 +200,7 @@ static int em28xx_i2c_send_bytes(struct em28xx *dev, u16 > addr, u8 *buf, > if (ret == 0) { /* success */ > return len; > } else if (ret == 0x10) { > + em28xx_warn("I2C transfer timeout on writing to addr > 0x%02x", addr); > return -ENODEV; > } else if (ret < 0) { > em28xx_warn("failed to read i2c transfer status from > bridge (error=%i)\n", > @@ -255,6 +258,7 @@ static int em28xx_i2c_recv_bytes(struct em28xx *dev, u16 > addr, u8 *buf, u16 len) > } > if (ret > 0) { > if (ret == 0x10) { > + em28xx_warn("I2C transfer timeout on read from addr > 0x%02x", addr); > return -ENODEV; > } else { > em28xx_warn("unknown i2c error (status=%i)\n", ret); > @@ -316,8 +320,10 @@ static int em25xx_bus_B_send_bytes(struct em28xx *dev, > u16 addr, u8 *buf, > */ > if (!ret) > return len; > - else if (ret > 0) > + else if (ret > 0) { > + em28xx_warn("Bus B R08 returned 0x%02x: I2C timeout", ret); > return -ENODEV; > + } > > return ret; > /* > @@ -367,8 +373,10 @@ static int em25xx_bus_B_recv_bytes(struct em28xx *dev, > u16 addr, u8 *buf, > */ > if (!ret) > return len; > - else if (ret > 0) > + else if (ret > 0) { > + em28xx_warn("Bus B R08 returned 0x%02x: I2C timeout", ret); > return -ENODEV; > + } > > return ret; > /* NACK. This will spam the system log on i2c device probing (especially with sensors). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
