| Message ID | 1388832951-11195-7-git-send-email-m.chehab@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.chehab@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Sun, 05 Jan 2014 11:51:44 +0100 Frank Schäfer <fschaefer.oss@googlemail.com> escreveu: > 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.chehab@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). A driver returning -ENODEV should really have a log explaining what happened with the device. Anyway, see changeset 19/22. This is part of a changeset that cleanups the I2C return code and printk mess. After changeset 19/22, the timeout messages will be displayed only if debug is enabled, and it will return the proper error code for I2C I/O errors, as described at I2C Documentation/. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Sun, 05 Jan 2014 11:51:44 +0100 Frank Schäfer <fschaefer.oss@googlemail.com> escreveu: > 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 In time, I'll update the description. I'll work on the xc2028 driver to fix it. It seems better than applying a hack there. I prefer to not remove the code that puts it in power down mode, as some em28xx devices are known to have power heat problems. So, keeping xc3028 energized can reduce a lot its lifetime on such devices. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; /*
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. For now, instead of just returning -ENODEV, output an error message to help debug what's happening. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> --- drivers/media/usb/em28xx/em28xx-i2c.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)