HVR-4000 driver problems - i2c error

Hi,

I've got a HVR-4000, but I have now some very strange problems.
I have Debian Leeny with 2.6.25-2 kernel and multiproto from Igor Lipianin hg running at Athlon64 X2 2700+ and Asus M2N-DVI mobo.
Whole multiproto tree compiled without any problem.

- when starting system I got this message:

[   24.658572] tda9887 0-0043: i2c i/o error: rc == -121 (should be 4)
[   24.659047] tuner-simple 0-0061: i2c i/o error: rc == -121 (should be 4)
[   23.609971] tda9887 0-0043: i2c i/o error: rc == -121 (should be 4)

- the firmware is loaded into the card at first time the card is opened - it is okay?

[  917.660620] cx24116_firmware_ondemand: Waiting for firmware upload 
(dvb-fe-cx24116.fw)...
[  917.703010] cx24116_firmware_ondemand: Waiting for firmware upload(2)...
[  922.703870] cx24116_load_firmware: FW version 1.22.82.0
[  922.703889] cx24116_firmware_ondemand: Firmware upload complete

The result is that only for some channels it is possible to get lock with szap2. VDR is hanging (or starting) when trying to tune to initial channel, even when this channel is set to channel at which is szap2 successfull. I'm not able to say criteria which channels are possible to lock.

Any hints are appreciated.

Quoted 7 lines · Ales Jurik

Hi,

I've got a HVR-4000, but I have now some very strange problems. I have Debian Leeny with 2.6.25-2 kernel and multiproto from Igor Lipianin hg running at Athlon64 X2 2700+ and Asus M2N-DVI mobo. Whole multiproto tree compiled without any problem.

Quoted 6 lines

- when starting system I got this message:

[   24.658572] tda9887 0-0043: i2c i/o error: rc == -121 (should be 4)
[   24.659047] tuner-simple 0-0061: i2c i/o error: rc == -121 (should be

4) [ 23.609971] tda9887 0-0043: i2c i/o error: rc == -121 (should be 4)

I fixed an issue with cx88 sometime ago where a value of 0 (taken from the cards struct) was being written to the GPIO register, resulting in the same i2c issues.

It looks a lot like this.

- Steve

Quoted 9 lines

- the firmware is loaded into the card at first time the card is opened - it is okay?

[  917.660620] cx24116_firmware_ondemand: Waiting for firmware upload
(dvb-fe-cx24116.fw)...
[  917.703010] cx24116_firmware_ondemand: Waiting for firmware upload(2)...
[  922.703870] cx24116_load_firmware: FW version 1.22.82.0
[  922.703889] cx24116_firmware_ondemand: Firmware upload complete

Quoted 6 lines

The result is that only for some channels it is possible to get lock with szap2. VDR is hanging (or starting) when trying to tune to initial channel, even when this channel is set to channel at which is szap2 successfull. I'm not able to say criteria which channels are possible to lock.

Any hints are appreciated.

I fixed an issue with cx88 sometime ago where a value of 0 (taken from the cards struct) was being written to the GPIO register, resulting in the same i2c issues.

It looks a lot like this.

- Steve

Quoted 1 line

Quoted 1 line

tune to:

Quoted 1 line

Quoted 1 line

tune to:

Quoted 21 lines

Quoted 19 lines

- the firmware is loaded into the card at first time the card is opened - it
is okay?

[  917.660620] cx24116_firmware_ondemand: Waiting for firmware upload
(dvb-fe-cx24116.fw)...
[  917.703010] cx24116_firmware_ondemand: Waiting for firmware 
upload(2)...
[  922.703870] cx24116_load_firmware: FW version 1.22.82.0
[  922.703889] cx24116_firmware_ondemand: Firmware upload complete

The result is that only for some channels it is possible to get lock with
szap2. VDR is hanging (or starting) when trying to tune to initial channel,
even when this channel is set to channel at which is szap2 successfull. I'm
not able to say criteria which channels are possible to lock.

Quoted 1 line

Any hints are appreciated.

Quoted 7 lines

I fixed an issue with cx88 sometime ago where a value of 0 (taken from the cards struct) was being written to the GPIO register, resulting in the same i2c issues.

It looks a lot like this.

- Steve

I am trying to get the dvb-t tuner working with my hvr-4000 (dvb-s is working fine) and have tried both the latest S2 repository and the latest version of liplianins multiproto repository with 2.6.26 kernels.

It seems that S2 repository does not yet support DVB-T at all, am I correct? At least the "options cx88-dvb frontend=1" option in /etc/modprope.conf prevents adapters to be created at all under /dev/dvb. Without that option adapter is created but it can only be used for scanning dvb-s.

WIth liplianinis multiproto version the selection between DVB-S and DVB-T works by using the "options cx88-dvb frontend=1" but I am seeing the i2c
errors described below.

Could you have any URL and changeset tag to patch in some repository where this I2C thing has been fixed?

The ~stoth/hg/s2 has no DVB-T support on the HVR4000 yet. Those patches will appear very shortly in ~stoth/hg/s2-mfe.

Quoted 6 lines

WIth liplianinis multiproto version the selection between DVB-S and DVB-T works by using the "options cx88-dvb frontend=1" but I am seeing the i2c errors described below.

Could you have any URL and changeset tag to patch in some repository where this I2C thing has been fixed?

I'm speculating that your issue is the same issue I fixed sometime ago (2-3 months in the master repo). I'd suggest you wait for the
~ stoth/hg/s2-mfe patches to appear later tonight and test again.

That tree (and ~stoth/hg/s2 for that matter) have the i2c fix I'm referring to.

Quoted 2 lines

The ~stoth/hg/s2 has no DVB-T support on the HVR4000 yet. Those patches will appear very shortly in ~stoth/hg/s2-mfe.

Thanks,

I build and installed drivers from s2-mfe branch and now atleast the dvb-t and dvb-s scan were working both for hvr-1300 and hvr-4000. With hvr-4000, the scan worked with
"./scan -a 1 -f 1 "... parameters.

Quoted 10 lines

Quoted 9 lines

WIth liplianinis multiproto version the selection between DVB-S and
DVB-T
works by using the "options cx88-dvb frontend=1" but I am seeing the
i2c
errors described below.

Could you have any URL and changeset tag to patch in some repository
where
this I2C thing has been fixed?

Quoted 6 lines

I'm speculating that your issue is the same issue I fixed sometime ago (2-3 months in the master repo). I'd suggest you wait for the ~ stoth/hg/s2-mfe patches to appear later tonight and test again.

That tree (and ~stoth/hg/s2 for that matter) have the i2c fix I'm referring to.

I tried to find the fix by checking from the log your commits for cx88 couple of months ago and could not find the one you were referring. Then I remembered that in 2.6.25 kernel, similar errors for HVR-1300 could be fixed by defining the radio information for the board structure.

So I tried the same trick also for hvr-4000, and that made dvb-t working without I2C errors also for HVR4000. ( with liplianis version of multiproto tree.)

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +4 -0

@@ -1480,6 +1480,10 @@
         }},
         /* fixme: Add radio support */
         .mpeg           = CX88_MPEG_DVB,
+        .radio = {
+            .type   = CX88_RADIO,
+            .gpio0    = 0xe780,
+        },
     },
     [CX88_BOARD_HAUPPAUGE_HVR4000LITE] = {
         .name           = "Hauppauge WinTV-HVR4000(Lite) DVB-S/S2",

In S2 and S2-mfe, the dvb-t worked even without radio data defined for hvr-4000.

Other non-API related changes that I could found between multiproto and s2 trees for CX88 were pretty small. Is this udelay really needed?

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +4 -2

@@ -2594,8 +2598,9 @@
         break;
     case CX88_BOARD_HAUPPAUGE_HVR3000: /* ? */
     case CX88_BOARD_HAUPPAUGE_HVR4000:
-        /* Init GPIO for DVB-S/S2/Analog */
-        cx_write(MO_GP0_IO,core->board.input[0].gpio0);
+        /* Init GPIO */
+        cx_write(MO_GP0_IO, core->board.input[0].gpio0);
+        udelay(1000);
         break;
 
     case CX88_BOARD_PROLINK_PV_8000GT:

@@ -2939,6 +2944,7 @@
         cx88_card_list(core, pci);
     }
 
+    memset(&core->board, 0, sizeof(core->board));
     memcpy(&core->board, &cx88_boards[core->boardnr], 
 sizeof(core->board));
 

     info_printk(core, "subsystem: %04x:%04x, board: %s [card=%d,%s]\n",

Those did not help

Quoted 9 lines · Mika Laitio

Quoted 2 lines

The ~stoth/hg/s2 has no DVB-T support on the HVR4000 yet. Those patches will appear very shortly in ~stoth/hg/s2-mfe.

Thanks,

I build and installed drivers from s2-mfe branch and now atleast the dvb-t and dvb-s scan were working both for hvr-1300 and hvr-4000. With hvr-4000, the scan worked with
"./scan -a 1 -f 1 "... parameters.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

WIth liplianinis multiproto version the selection between DVB-S and
DVB-T
works by using the "options cx88-dvb frontend=1" but I am seeing the
i2c
errors described below.

Quoted 20 lines

Quoted 10 lines

Quoted 3 lines

Could you have any URL and changeset tag to patch in some repository
where
this I2C thing has been fixed?

I'm speculating that your issue is the same issue I fixed sometime ago (2-3 months in the master repo). I'd suggest you wait for the ~ stoth/hg/s2-mfe patches to appear later tonight and test again.

That tree (and ~stoth/hg/s2 for that matter) have the i2c fix I'm referring to.

I tried to find the fix by checking from the log your commits for cx88 couple of months ago and could not find the one you were referring. Then I remembered that in 2.6.25 kernel, similar errors for HVR-1300 could be fixed by defining the radio information for the board structure.

So I tried the same trick also for hvr-4000, and that made dvb-t working without I2C errors also for HVR4000. ( with liplianis version of multiproto tree.)

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 line 1486

Quoted 10 lines

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +4 -0

@@ -1480,6 +1480,10 @@
         }},
         /* fixme: Add radio support */
         .mpeg           = CX88_MPEG_DVB,
+        .radio = {
+            .type   = CX88_RADIO,
+            .gpio0    = 0xe780,
+        },

Quoted 6 lines

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +0 -0

     [CX88_BOARD_HAUPPAUGE_HVR4000LITE] = {
         .name           = "Hauppauge WinTV-HVR4000(Lite) DVB-S/S2",
 

In S2 and S2-mfe, the dvb-t worked even without radio data defined for hvr-4000.

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 line 2599

Quoted 6 lines

Other non-API related changes that I could found between multiproto and s2 trees for CX88 were pretty small. Is this udelay really needed?

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +0 -0

@@ -2594,8 +2598,9 @@
         break;
     case CX88_BOARD_HAUPPAUGE_HVR3000: /* ? */

Quoted 19 lines

cx88-cards.c 2008-09-24 10:44:15.000000000 +0300 renamed from cx88-cards.c_old 2008-09-25 00:51:18.000000000 +0300 +4 -2

     case CX88_BOARD_HAUPPAUGE_HVR4000:
-        /* Init GPIO for DVB-S/S2/Analog */
-        cx_write(MO_GP0_IO,core->board.input[0].gpio0);
+        /* Init GPIO */
+        cx_write(MO_GP0_IO, core->board.input[0].gpio0);
+        udelay(1000);
         break;
 
     case CX88_BOARD_PROLINK_PV_8000GT:

@@ -2939,6 +2944,7 @@
         cx88_card_list(core, pci);
     }
 
+    memset(&core->board, 0, sizeof(core->board));
     memcpy(&core->board, &cx88_boards[core->boardnr], 
 sizeof(core->board));
 

     info_printk(core, "subsystem: %04x:%04x, board: %s [card=%d,%s]\n",

Quoted 1 line

Those did not help

Thanks.

I'm going to rebase the s2-mfe tree from master (containing the s2api). Darron also has a i2c related fix (which isn't perfect) but does address an issue like this.

I'll rebase and push both of those patches into ~stoth/s2-mfe, if you can retest after this then that would be useful.

Watch for changes to this tree tonight, it may help.