Comment 3 for bug 836062

Devin: On earlier kernels the tveeprom only seemed to fail on warm reboots. However, since about 2.6.35-ish it's almost always failed - although there has been the odd cold or warm reboot that has seen it working.

It's been on my list of kernel bugs to fix for some time but I've only just got around to tackling it.

I believe it will affect all three devices for two reasons:

1) I've examined masses of similar reports where tveeprom fails in this way and these devices are almost always being used
2) I've been delving into the code quite extensively and these three models are treated the same way in the cx88xx code. E.g: drivers/media/video/cx88/cx88-i2c.c:166

  dprintk(1, "i2c register ok\n");
  switch( core->boardnr ) {
   int result = 0;
   case CX88_BOARD_HAUPPAUGE_HVR1300:
   case CX88_BOARD_HAUPPAUGE_HVR3000:
   case CX88_BOARD_HAUPPAUGE_HVR4000:
    printk("%s: i2c init: enabling analog demod on HVR1300/3000/4000 tuner\n",
     core->name);

I'm investigating this code in particular since it doesn't check for an error code in the return from i2c_transfer(). I'm currently building a mainline tip with the following patch to check:

diff --git a/drivers/media/video/cx88/cx88-i2c.c b/drivers/media/video/cx88/cx88-i2c.c
index a1fe0ab..5f56320 100644
--- a/drivers/media/video/cx88/cx88-i2c.c
+++ b/drivers/media/video/cx88/cx88-i2c.c
@@ -165,12 +165,16 @@ int cx88_i2c_init(struct cx88_core *core, struct pci_dev *pci)

                dprintk(1, "i2c register ok\n");
                switch( core->boardnr ) {
+ int result = 0;
                        case CX88_BOARD_HAUPPAUGE_HVR1300:
                        case CX88_BOARD_HAUPPAUGE_HVR3000:
                        case CX88_BOARD_HAUPPAUGE_HVR4000:
                                printk("%s: i2c init: enabling analog demod on HVR1300/3000/4000 tuner\n",
                                        core->name);
- i2c_transfer(core->i2c_client.adapter, &tuner_msg, 1);
+ result = i2c_transfer(core->i2c_client.adapter, &tuner_msg, 1);
+ if (result != 1) {
+ printk(KERN_ERR "%s: i2c init: failed, error=%d\n", core->name, result);
+ }
                                break;
                        default:
                                break;

This i2c transfer is unique to these three models and preceeds the standard call to tveeprom_read() in cx880cards.c::cx88_card_setup(). That function does a i2c_master_send() which fails and reports the error:

 if (err != 1) {
  tveeprom_info("Huh, no eeprom present (err=%d)?\n", err);
  return -1;
 }

My suspicion is that the earlier i2c_transfer() either fails or causes the device to be unavailable at this point - I want to check for -EAGAIN or -EBUSY responses from i2c on these in case a greater delay or retry would be appropriate.

Gunni: Thanks for the references. The code you reference only patches the HVR-1300 code-path, but the same timing delay can be applied to the HVR-3000/4000 code-path. My feeling has always been that this is a timing issue, so maybe that will solve it. Hopefully my tracing can help explain it. If those patches solve the issue, I wonder why they've not made it into the mainline v4l-dvb tree in over a year?