mb86a20s and cx23885

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2 

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Quoted 32 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

	fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

Quoted 8 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Quoted 4 lines

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Maybe a remote controller? Do you have a high-resolution picture of the board?

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Quoted 32 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

	fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

Quoted 8 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Quoted 4 lines

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Maybe a remote controller? Do you have a high-resolution picture of the board?

Hi

Quoted 10 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 4 lines

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Congratulations for driver you have made

Quoted 44 lines

Quoted 33 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

Quoted 6 lines

	fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

If in this way, it does not work:

     case CX23885_BOARD_MYGICA_X8507:
         i2c_bus = &dev->i2c_bus[0];
         i2c_bus2 = &dev->i2c_bus[1];
         fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
             &mygica_x8507_mb86a20s_config,
             &i2c_bus->i2c_adap);
         if (fe0->dvb.frontend != NULL) {
             dvb_attach(xc5000_attach,
                 fe0->dvb.frontend,
                 &i2c_bus2->i2c_adap,
                 &mygica_x8507_xc5000_config);
         fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;

fe0->dvb.frontend->ops.tuner_ops.init(fe0->dvb.frontend);

I get:

...dmesg
...

[  964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[  964.105696] mb86a20s: mb86a20s_set_frontend:
[  964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters

From this:

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

Quoted 5 lines

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

I think I'm doing well

     case CX23885_BOARD_MYGICA_X8506:
     case CX23885_BOARD_MYGICA_X8507:
     case CX23885_BOARD_MAGICPRO_PROHDTVE2:
         /* Select Digital TV */
         cx23885_gpio_set(dev, GPIO_0);
         break;

X8508 and X8507 is the same card, just change the digital part.

The driver for windows says:

X8507 means X8502
_________________________________________________________________________________________
[X8502.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00 ;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values

HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00

HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x13, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
___________________________________________________________________________________

[X8506.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00 ;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00
HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
______________________________________________________________________________________

there is only change in:

HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00

and

HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00

Quoted 4 lines

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

I expected something like this:

From zl10353, page 12:

3.1.2
Tuner
The ZL10353 has a General Purpose Port that can be configured to provide a secondary 2-wire bus. See register
GPP_CTL address 0x8C.
Master control mode is selected by setting register SCAN_CTL (0x62) [b3] = 1.

From V4L driver, zl10353.c

static int zl10353_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)

{
     struct zl10353_state *state = fe->demodulator_priv;
     u8 val = 0x0a;

     if (state->config.disable_i2c_gate_ctrl) {
         /* No tuner attached to the internal I2C bus */
         /* If set enable I2C bridge, the main I2C bus stopped hardly */
         return 0;
     }

     if (enable)
         val |= 0x10;

     return zl10353_single_write(fe, 0x62, val);

Maybe I'm misunderstanding the code.

When I do notknow the pins of integrated circuits I can not measure the state of the GPIO.

Quoted 10 lines

Quoted 10 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Bus 2 (internal) always accesse to 0x88

Quoted 4 lines

Quoted 2 lines

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Maybe a remote controller? Do you have a high-resolution picture of the board?

Do not know if I can be the remote, but only does so under windows7 bus 0 accesses the address 0x66.
Under Windows XP does not access the bus 0 to address 0x66.

I have no photos in high resolution, but I can get a camera if it helps you to help me.

Here are photos in low resolution:

http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card

Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 13 lines

Hi

Quoted 10 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Congratulations for driver you have made

Thanks!

Quoted 64 lines

Quoted 42 lines

Quoted 31 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

Quoted 6 lines

	fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

If in this way, it does not work:

      case CX23885_BOARD_MYGICA_X8507:
          i2c_bus = &dev->i2c_bus[0];
          i2c_bus2 = &dev->i2c_bus[1];
          fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
              &mygica_x8507_mb86a20s_config,
              &i2c_bus->i2c_adap);
          if (fe0->dvb.frontend != NULL) {
              dvb_attach(xc5000_attach,
                  fe0->dvb.frontend,
                  &i2c_bus2->i2c_adap,
                  &mygica_x8507_xc5000_config);
          fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;

fe0->dvb.frontend->ops.tuner_ops.init(fe0->dvb.frontend);

Quoted 7 lines

I get:

...dmesg
...

[  964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[  964.105696] mb86a20s: mb86a20s_set_frontend:
[  964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters

It seems that the driver is able to talk with mb86a20s and read the status and version registers. If the xc5000 firmware got loaded, that means that there's no issue with I2C.

So, the issue is likely something else.

From this:

Quoted 2 lines

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

mb86a20s_config.is_serial should be false (default).

Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?

If the XTAL is the same and the device driver is set to parallel mode, then we'll need to investigate other setups that happen during init time.

There are a few places at the driver that you could play with. For example, on this register set:

	{ 0x09, 0x3e },

You could try, instead of 0x3e, 0x1e, 0x1a or 0x3a.

However, I recommend you to sniff the PCI traffic, in order to be sure about what this specific device does.

When I was writing the driver for mb86a20s, I used this technique to be sure about what it was needed to make one PCI card to work with it. What I did then was to patch kvm to force it to emulate all DMA transfers, writing a dump of all such transfers at the host kernel. Then, I ran some parsing scripts to get the mb86a20s and tuner initialization. I made the patches available at:

http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/pci_traffic

I documented what it was needed to sniff the traffic at:
http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/pci_traffic/README

The patches were made against the kvm version that were shipped with the latest Fedora version that were available in Oct, 2010 (likely Fedora 13). I'm not sure if they still apply on today's kvm.

As you may expect, emulating all DMA transfers on a PCIe device is slow. So, the VM may die or produce unexpected results. However, as the mb86a20s init happens before the beginning of the video stream, you'll very likely be able to get the needed dumps before the guest system crash.

Once you get the dumps, you'll need to parse them, in order to filter just the cx23885 I2C register reads/writes, and get only the data sent to mb86a20s.

You'll find some examples of such patches at:

	http://git.linuxtv.org/v4l-utils.git/tree/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib

In the case of the PCI device I was sniffing, I used this parser:

	http://git.linuxtv.org/v4l-utils.git/blob/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib/saa7134/parse_saa7134.pl

That produces something like:

write_i2c_addr(0x10, 3, { 0x70, 0x0f, 0x00});
write_i2c_addr(0x10, 3, { 0x70, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x08, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x09, 0x3e, 0x00});
write_i2c_addr(0x10, 3, { 0x50, 0xd1, 0x00});
write_i2c_addr(0x10, 3, { 0x51, 0x22, 0x00});
write_i2c_addr(0x10, 3, { 0x39, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x71, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x2a, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0x80, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x20, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x33, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xdf, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0xa9, 0x00});
write_i2c_addr(0x10, 3, { 0x3b, 0x21, 0x00});
write_i2c_addr(0x10, 3, { 0x3c, 0x3a, 0x00});
write_i2c_addr(0x10, 3, { 0x01, 0x0d, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x08, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x05, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x0e, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x00, 0x00});
...

By comparing it with the device init at mb86a20s, we can see if this particular device is doing something different and improve the driver to also handle your device.

Quoted 33 lines

Quoted 4 lines

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

I think I'm doing well

      case CX23885_BOARD_MYGICA_X8506:
      case CX23885_BOARD_MYGICA_X8507:
      case CX23885_BOARD_MAGICPRO_PROHDTVE2:
          /* Select Digital TV */
          cx23885_gpio_set(dev, GPIO_0);
          break;

X8508 and X8507 is the same card, just change the digital part.

The driver for windows says:

X8507 means X8502
_________________________________________________________________________________________
[X8502.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00

Quoted 8 lines

;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00

You need to double-check if all the above GPIO's are properly initialized.

Again, the PCI traffic dump can help you to confirm if you should either set or reset the above bits.

Quoted 43 lines

HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x13, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
___________________________________________________________________________________

[X8506.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00 ;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00
HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
______________________________________________________________________________________

Quoted 7 lines

there is only change in:

HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00

and

HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00

I see your point. Yeah, both devices look similar.

Quoted 34 lines

Quoted 3 lines

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

I expected something like this:

From zl10353, page 12:

3.1.2
Tuner
The ZL10353 has a General Purpose Port that can be configured to provide a secondary 2-wire bus. See register
GPP_CTL address 0x8C.
Master control mode is selected by setting register SCAN_CTL (0x62) [b3] = 1.

From V4L driver, zl10353.c

static int zl10353_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)

{
      struct zl10353_state *state = fe->demodulator_priv;
      u8 val = 0x0a;

      if (state->config.disable_i2c_gate_ctrl) {
          /* No tuner attached to the internal I2C bus */
          /* If set enable I2C bridge, the main I2C bus stopped hardly */
          return 0;
      }

      if (enable)
          val |= 0x10;

      return zl10353_single_write(fe, 0x62, val);

Quoted 1 line

Maybe I'm misunderstanding the code.

Yeah, but mb86a20s driver currently doesn't have any similar logic, as no devices I'm aware have the tuner connected to its I2C gate.

Quoted 13 lines

When I do notknow the pins of integrated circuits I can not measure the state of the GPIO.

Quoted 11 lines

Quoted 11 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Quoted 5 lines

Quoted 2 lines

Maybe a remote controller? Do you have a high-resolution picture of the board?

Do not know if I can be the remote, but only does so under windows7 bus 0 accesses the address 0x66.
Under Windows XP does not access the bus 0 to address 0x66.

Please notice that we prefer to use the 7-bits notation for I2C addresses, as this is the one used on the original Philips I2C datasheet. So, we call it as 0x33 ;)

Maybe you need to call a separate program for IR handling on Windows XP. At least, I've seen several WinXP setups that have a separate program to handle remotes.

Quoted 7 lines

I have no photos in high resolution, but I can get a camera if it helps you to help me.

Here are photos in low resolution:

http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card

I couldn't identify there the small chips on it. If this device has an I2C device for IR, it is likely one small microcontroller chip.

Hi

Quoted 97 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 13 lines

Hi

Quoted 10 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Congratulations for driver you have made

Thanks!

Quoted 64 lines

Quoted 42 lines

Quoted 31 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

Quoted 6 lines

    fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

If in this way, it does not work:

      case CX23885_BOARD_MYGICA_X8507:
          i2c_bus = &dev->i2c_bus[0];
          i2c_bus2 = &dev->i2c_bus[1];
          fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
              &mygica_x8507_mb86a20s_config,
              &i2c_bus->i2c_adap);
          if (fe0->dvb.frontend != NULL) {
              dvb_attach(xc5000_attach,
                  fe0->dvb.frontend,
                  &i2c_bus2->i2c_adap,
                  &mygica_x8507_xc5000_config);
          fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;

fe0->dvb.frontend->ops.tuner_ops.init(fe0->dvb.frontend);

Quoted 7 lines

I get:

...dmesg
...

[  964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[  964.105696] mb86a20s: mb86a20s_set_frontend:
[  964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters

It seems that the driver is able to talk with mb86a20s and read the status and version registers. If the xc5000 firmware got loaded, that means that there's no issue with I2C.

Quoted 7 lines

So, the issue is likely something else.

From this:

Quoted 2 lines

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

mb86a20s_config.is_serial should be false (default).

static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
    .demod_address = 0x10,
};

nothing of .is_serial

Quoted 2 lines

Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?

The exact value is 32.571MHz

Quoted 9 lines

If the XTAL is the same and the device driver is set to parallel mode, then we'll need to investigate other setups that happen during init time.

There are a few places at the driver that you could play with. For example, on this register set:

    { 0x09, 0x3e },

You could try, instead of 0x3e, 0x1e, 0x1a or 0x3a.

I tested with the three new values ​​and get nothing different

Quoted 3 lines

However, I recommend you to sniff the PCI traffic, in order to be sure about what this specific device does.

For this I need a little more time to study and apply. In a few days it I obtained commented

Quoted 34 lines

When I was writing the driver for mb86a20s, I used this technique to be sure about what it was needed to make one PCI card to work with it. What I did then was to patch kvm to force it to emulate all DMA transfers, writing a dump of all such transfers at the host kernel. Then, I ran some parsing scripts to get the mb86a20s and tuner initialization. I made the patches available at:

http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/pci_traffic

I documented what it was needed to sniff the traffic at:
http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/pci_traffic/README

The patches were made against the kvm version that were shipped with the latest Fedora version that were available in Oct, 2010 (likely Fedora 13). I'm not sure if they still apply on today's kvm.

As you may expect, emulating all DMA transfers on a PCIe device is slow. So, the VM may die or produce unexpected results. However, as the mb86a20s init happens before the beginning of the video stream, you'll very likely be able to get the needed dumps before the guest system crash.

Once you get the dumps, you'll need to parse them, in order to filter just the cx23885 I2C register reads/writes, and get only the data sent to mb86a20s.

You'll find some examples of such patches at:

    http://git.linuxtv.org/v4l-utils.git/tree/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib 

In the case of the PCI device I was sniffing, I used this parser:

    http://git.linuxtv.org/v4l-utils.git/blob/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib/saa7134/parse_saa7134.pl 

Quoted 180 lines

That produces something like:

write_i2c_addr(0x10, 3, { 0x70, 0x0f, 0x00});
write_i2c_addr(0x10, 3, { 0x70, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x08, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x09, 0x3e, 0x00});
write_i2c_addr(0x10, 3, { 0x50, 0xd1, 0x00});
write_i2c_addr(0x10, 3, { 0x51, 0x22, 0x00});
write_i2c_addr(0x10, 3, { 0x39, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x71, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x2a, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0x80, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x20, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x33, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xdf, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0xa9, 0x00});
write_i2c_addr(0x10, 3, { 0x3b, 0x21, 0x00});
write_i2c_addr(0x10, 3, { 0x3c, 0x3a, 0x00});
write_i2c_addr(0x10, 3, { 0x01, 0x0d, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x08, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x05, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x0e, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x00, 0x00});
...

By comparing it with the device init at mb86a20s, we can see if this particular device is doing something different and improve the driver to also handle your device.

Quoted 34 lines

Quoted 4 lines

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

I think I'm doing well

      case CX23885_BOARD_MYGICA_X8506:
      case CX23885_BOARD_MYGICA_X8507:
      case CX23885_BOARD_MAGICPRO_PROHDTVE2:
          /* Select Digital TV */
          cx23885_gpio_set(dev, GPIO_0);
          break;

X8508 and X8507 is the same card, just change the digital part.

The driver for windows says:

X8507 means X8502
_________________________________________________________________________________________

[X8502.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00

Quoted 8 lines

;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00

You need to double-check if all the above GPIO's are properly initialized.

Again, the PCI traffic dump can help you to confirm if you should either set or reset the above bits.

Quoted 45 lines

HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x13, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
___________________________________________________________________________________

[X8506.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00 ;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00
HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
______________________________________________________________________________________

Quoted 7 lines

there is only change in:

HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00

and

HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00

I see your point. Yeah, both devices look similar.

Quoted 35 lines

Quoted 3 lines

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

I expected something like this:

From zl10353, page 12:

3.1.2
Tuner
The ZL10353 has a General Purpose Port that can be configured to provide a secondary 2-wire bus. See register
GPP_CTL address 0x8C.
Master control mode is selected by setting register SCAN_CTL (0x62) [b3] = 1.

From V4L driver, zl10353.c

static int zl10353_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)

{
      struct zl10353_state *state = fe->demodulator_priv;
      u8 val = 0x0a;

      if (state->config.disable_i2c_gate_ctrl) {
          /* No tuner attached to the internal I2C bus */
          /* If set enable I2C bridge, the main I2C bus stopped 
hardly */
          return 0;
      }

      if (enable)
          val |= 0x10;

      return zl10353_single_write(fe, 0x62, val);

Quoted 1 line

Maybe I'm misunderstanding the code.

Yeah, but mb86a20s driver currently doesn't have any similar logic, as no devices I'm aware have the tuner connected to its I2C gate.

Quoted 9 lines

When I do notknow the pins of integrated circuits I can not measure the state of the GPIO.

Quoted 7 lines

Quoted 7 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 4 lines

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Maybe a remote controller? Do you have a high-resolution picture of the board?

Quoted 6 lines

Quoted 3 lines

Do not know if I can be the remote, but only does so under windows7 bus 0 accesses the address 0x66.
Under Windows XP does not access the bus 0 to address 0x66.

Please notice that we prefer to use the 7-bits notation for I2C addresses, as this is the one used on the original Philips I2C datasheet. So, we call it as 0x33 ;)

OK.

Quoted 4 lines

Maybe you need to call a separate program for IR handling on Windows XP. At least, I've seen several WinXP setups that have a separate program to handle remotes.

Yes, but uses different software on both Windows XP and 7

Quoted 10 lines

Quoted 8 lines

I have no photos in high resolution, but I can get a camera if it helps you to help me.

Here are photos in low resolution:

http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card

I couldn't identify there the small chips on it. If this device has an I2C device for IR, it is likely one small microcontroller chip.

In Linux did not need any extra configuration:
http://patchwork.linuxtv.org/patch/15412/

For now I owe it, I will upload higher resolution photos when I have a camera. With my eyes I fail to read the small chips, and that they still look okay.

Thank you very much.

Alfredo

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi

Quoted 162 lines · Alfredo Jesús Delaiti

Hi

Quoted 97 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 13 lines

Hi

Quoted 10 lines · Mauro Carvalho Chehab

Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

Hi all

I'm trying to run the digital part of the card MyGica X8507 and I need help on some issues.

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

Need data sheet of IC MB86A20S and no where to get it. Fujitsu People of Germany told me: "This is a very old product and not supported any more". Does anyone know where to get it?

I never found any public datasheet for this device.

Congratulations for driver you have made

Thanks!

Quoted 64 lines

Quoted 42 lines

Quoted 31 lines

linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1

...

[ 7011.618381] cx23885[0]: scan bus 0:

[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]

[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]

[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]

[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]

[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]

[ 7011.636438] cx23885[0]: scan bus 1:

[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2

[tuner/mt2131/tda8275/xc5000/xc3028]

[ 7011.654460] cx23885[0]: scan bus 2:

[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]

[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]

[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]

Quoted 8 lines

...

In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the tuner (xc5000). I understand that would have to be cancel the mb86a20s i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is not yet implemented in the controller of mb86a20s. The IC cx23885 is always who controls the tuner i2c bus.

Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't be calling it. So, IMO, the cleanest approach would simply to do:

Quoted 6 lines

    fe->dvb.frontend->ops.i2c_gate_ctrl = NULL;

after tuner attach, if the tuner or the bridge driver implements an i2c gate. I don't think xc5000 does. The mb86a20s also has its own i2c gate and gpio ports that might be used to control an external gate, but support for it is currently not implemented, as no known device uses it.

If in this way, it does not work:

      case CX23885_BOARD_MYGICA_X8507:
          i2c_bus = &dev->i2c_bus[0];
          i2c_bus2 = &dev->i2c_bus[1];
          fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
              &mygica_x8507_mb86a20s_config,
              &i2c_bus->i2c_adap);
          if (fe0->dvb.frontend != NULL) {
              dvb_attach(xc5000_attach,
                  fe0->dvb.frontend,
                  &i2c_bus2->i2c_adap,
                  &mygica_x8507_xc5000_config);
          fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;

fe0->dvb.frontend->ops.tuner_ops.init(fe0->dvb.frontend);

Quoted 7 lines

I get:

...dmesg
...

[  964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[  964.105696] mb86a20s: mb86a20s_set_frontend:
[  964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters

It seems that the driver is able to talk with mb86a20s and read the status and version registers. If the xc5000 firmware got loaded, that means that there's no issue with I2C.

Quoted 7 lines

So, the issue is likely something else.

From this:

Quoted 2 lines

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

mb86a20s_config.is_serial should be false (default).

static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
    .demod_address = 0x10,
};

nothing of .is_serial

Quoted 2 lines

Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?

The exact value is 32.571MHz

Quoted 9 lines

If the XTAL is the same and the device driver is set to parallel mode, then we'll need to investigate other setups that happen during init time.

There are a few places at the driver that you could play with. For example, on this register set:

    { 0x09, 0x3e },

You could try, instead of 0x3e, 0x1e, 0x1a or 0x3a.

I tested with the three new values ​​and get nothing different

Quoted 3 lines

However, I recommend you to sniff the PCI traffic, in order to be sure about what this specific device does.

For this I need a little more time to study and apply. In a few days it I obtained commented

Quoted 25 lines

When I was writing the driver for mb86a20s, I used this technique to be sure about what it was needed to make one PCI card to work with it. What I did then was to patch kvm to force it to emulate all DMA transfers, writing a dump of all such transfers at the host kernel. Then, I ran some parsing scripts to get the mb86a20s and tuner initialization. I made the patches available at:

http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/pci_traffic

I documented what it was needed to sniff the traffic at:
http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/pci_traffic/README

The patches were made against the kvm version that were shipped with the latest Fedora version that were available in Oct, 2010 (likely Fedora 13). I'm not sure if they still apply on today's kvm.

As you may expect, emulating all DMA transfers on a PCIe device is slow. So, the VM may die or produce unexpected results. However, as the mb86a20s init happens before the beginning of the video stream, you'll very likely be able to get the needed dumps before the guest system crash.

Once you get the dumps, you'll need to parse them, in order to filter just the cx23885 I2C register reads/writes, and get only the data sent to mb86a20s.

Quoted 9 lines

Quoted 9 lines

You'll find some examples of such patches at:
http://git.linuxtv.org/v4l-utils.git/tree/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib

In the case of the PCI device I was sniffing, I used this parser:
http://git.linuxtv.org/v4l-utils.git/blob/fd35e2fdc85fa6a9dcd45ce2dd7c322bcda6e93e:/contrib/saa7134/parse_saa7134.pl

I hope I have misunderstood, because otherwise I can not do it, because to use qemu-kvm is required hardware that supports IOMMU and mine does not support it (Phenom_1 and chipset 780G and SB700).

 # modprobe pci_stub
 # echo "14f1 8852" > /sys/bus/pci/drivers/pci-stub/new_id
 # echo "0000:02:00.0" > /sys/bus/pci/devices/0000:02:00.0/driver/unbind
 # echo "0000:02:00.0" > /sys/bus/pci/drivers/pci-stub/bind
# qemu-kvm -name "windows-7" -M pc-1.1 -m 2048 -vga cirrus -drive file=/var/lib/qemu/images/windows/hda.img -device pci-assign,host=02:00.0
Warning: default mac address being used, creating potential for address conflict
No IOMMU found.  Unable to assign device "(null)"
qemu-kvm: -device pci-assign,host=02:00.0: Device 'pci-assign' could not be initialized

Hardware that supports IOMMU is very new and limited.

Is there any other known way to do this?

Quoted 180 lines

Quoted 180 lines

That produces something like:

write_i2c_addr(0x10, 3, { 0x70, 0x0f, 0x00});
write_i2c_addr(0x10, 3, { 0x70, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x08, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x09, 0x3e, 0x00});
write_i2c_addr(0x10, 3, { 0x50, 0xd1, 0x00});
write_i2c_addr(0x10, 3, { 0x51, 0x22, 0x00});
write_i2c_addr(0x10, 3, { 0x39, 0x01, 0x00});
write_i2c_addr(0x10, 3, { 0x71, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x2a, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x00, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xff, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0x80, 0x00});
write_i2c_addr(0x10, 3, { 0x28, 0x20, 0x00});
write_i2c_addr(0x10, 3, { 0x29, 0x33, 0x00});
write_i2c_addr(0x10, 3, { 0x2a, 0xdf, 0x00});
write_i2c_addr(0x10, 3, { 0x2b, 0xa9, 0x00});
write_i2c_addr(0x10, 3, { 0x3b, 0x21, 0x00});
write_i2c_addr(0x10, 3, { 0x3c, 0x3a, 0x00});
write_i2c_addr(0x10, 3, { 0x01, 0x0d, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x08, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x05, 0x00});
write_i2c_addr(0x10, 3, { 0x04, 0x0e, 0x00});
write_i2c_addr(0x10, 3, { 0x05, 0x00, 0x00});
...

By comparing it with the device init at mb86a20s, we can see if this particular device is doing something different and improve the driver to also handle your device.

Quoted 34 lines

Quoted 4 lines

So, all you need is to attach both mb86a20s and xc5000 on it, and set the proper GPIO's.

I think I'm doing well

      case CX23885_BOARD_MYGICA_X8506:
      case CX23885_BOARD_MYGICA_X8507:
      case CX23885_BOARD_MAGICPRO_PROHDTVE2:
          /* Select Digital TV */
          cx23885_gpio_set(dev, GPIO_0);
          break;

X8508 and X8507 is the same card, just change the digital part.

The driver for windows says:

X8507 means X8502
_________________________________________________________________________________________

[X8502.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00

Quoted 8 lines

;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00

You need to double-check if all the above GPIO's are properly initialized.

Again, the PCI traffic dump can help you to confirm if you should either set or reset the above bits.

Quoted 45 lines

HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x13, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
___________________________________________________________________________________

[X8506.AddReg]

HKR,"DriverData","TunerModel",0x00010001, 0x03,0x00,0x00,0x00

;Enable TS capture and BDA filter registration HKR,"DriverData","Enable_BDA",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","DemodI2CAddress",0x00010001, 0x1E, 0x00, 0x00, 0x00 ; this registry keys for the FixNMI option which takes care of the BSODs in the
; ICH6/7 chipsets
HKR,"DriverData","FixNMIBit",0x00010001, 0x00,0x00,0x00,0x00 ;IR Support
HKR,"DriverData","EnableIR",0x00010001, 0x01, 0x00, 0x00, 0x00 ;NEC standard
HKR,"DriverData","IRStandard",0x00010001, 0x01, 0x00, 0x00, 0x00 ; GPIO Pin values
HKR,"DriverData","mode_select_gpio_bit", 0x00010001, 0x00, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_reset_gpio_bit", 0x00010001, 0x01, 0x00, 0x00, 0x00 HKR,"DriverData","demod_reset_gpio_bit", 0x00010001, 0x02, 0x00, 0x00, 0x00 HKR,"DriverData","tuner_sif_fm_gpio_bit",0x00010001, 0x03, 0x00, 0x00, 0x00 HKR,"DriverData","comp_select_gpio_bit", 0x00010001, 0xff, 0x00, 0x00, 0x00
HKR,"DriverData","comp_select_panel", 0x00010001, 0xff, 0x00, 0x00, 0x00

;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel HKR,"DriverData","DemodTransferMode",0x00010001, 0x01, 0x00, 0x00, 0x00

;BoardType Sonora353 = 0x03 HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00 HKR,"DriverData","VideoStandard",0x00010001, 0x10,0x00,0x00,0x00
______________________________________________________________________________________

Quoted 7 lines

there is only change in:

HKR,"DriverData","BDA_Demod_Tuner_type",0x00010001, 0x01, 0x00, 0x00, 0x00

and

HKR,"DriverData","BoardType",0x00010001, 0x0e, 0x00, 0x00, 0x00

I see your point. Yeah, both devices look similar.

Quoted 35 lines

Quoted 3 lines

It will call fe->ops.tuner_ops.set_params(fe) inside the set_frontend() fops logic, in order to tune the device, but this is the same thing as zl10353_set_parameters does.

I expected something like this:

From zl10353, page 12:

3.1.2
Tuner
The ZL10353 has a General Purpose Port that can be configured to provide a secondary 2-wire bus. See register
GPP_CTL address 0x8C.
Master control mode is selected by setting register SCAN_CTL (0x62) [b3] = 1.

From V4L driver, zl10353.c

static int zl10353_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)

{
      struct zl10353_state *state = fe->demodulator_priv;
      u8 val = 0x0a;

      if (state->config.disable_i2c_gate_ctrl) {
          /* No tuner attached to the internal I2C bus */
          /* If set enable I2C bridge, the main I2C bus stopped 
hardly */
          return 0;
      }

      if (enable)
          val |= 0x10;

      return zl10353_single_write(fe, 0x62, val);

Quoted 1 line

Maybe I'm misunderstanding the code.

Yeah, but mb86a20s driver currently doesn't have any similar logic, as no devices I'm aware have the tuner connected to its I2C gate.

Quoted 9 lines

When I do notknow the pins of integrated circuits I can not measure the state of the GPIO.

Quoted 7 lines

Quoted 7 lines

Please, could you tell me if I'm reasoning correctly?

Using RegSpy I see the bus 0 alternately accesses to addresses 0x20 and 0x66under Windows 7. In Windows XP only accessed to 0x20 and when the pc starts to 0xa0.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 4 lines

Bus 2 (internal) always accesse to 0x88

The bus 0 and 2 (internal) access to the address 0x66 (according modprobe cx23885 i2c_scan), What's there?

Maybe a remote controller? Do you have a high-resolution picture of the board?

Here I have placed a photo in high resolution:

http://linuxtv.org/wiki/index.php/File:MyGica_X8507_Hi_Resolution.jpg
http://linuxtv.org/wiki/index.php/File:MyGica_X8507_3648x2736.JPG

Again, thank you very much

Alfredo

Quoted 39 lines

Quoted 6 lines

Quoted 3 lines

Do not know if I can be the remote, but only does so under windows7 bus 0 accesses the address 0x66.
Under Windows XP does not access the bus 0 to address 0x66.

Please notice that we prefer to use the 7-bits notation for I2C addresses, as this is the one used on the original Philips I2C datasheet. So, we call it as 0x33 ;)

OK.

Quoted 4 lines

Maybe you need to call a separate program for IR handling on Windows XP. At least, I've seen several WinXP setups that have a separate program to handle remotes.

Yes, but uses different software on both Windows XP and 7

Quoted 10 lines

Quoted 8 lines

I have no photos in high resolution, but I can get a camera if it helps you to help me.

Here are photos in low resolution:

http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card

I couldn't identify there the small chips on it. If this device has an I2C device for IR, it is likely one small microcontroller chip.

In Linux did not need any extra configuration:
http://patchwork.linuxtv.org/patch/15412/

For now I owe it, I will upload higher resolution photos when I have a camera. With my eyes I fail to read the small chips, and that they still look okay.

Thank you very much.

Alfredo

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Mauro and others from the list

I searched for a plan B to get the data bus and after several alternative plans that were available to me was to do a logic analyzer
(http://tfla-01.berlios.de).

With the logic analyzer I could get the data transmitted by the I2C bus under Windows, but when I put this data in replacement of originals in mb86a20s.c and I try to run the Linux TV board, do not get the logic analyzer with the same sequence.

The new data replacement in mb86a20s

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

     { 0x70, 0x0f },
     { 0x70, 0xff },
     { 0x09, 0x3a },
     { 0x50, 0xd1 },
     { 0x51, 0x22 },
     { 0x39, 0x00 },
     { 0x28, 0x2a },
     { 0x29, 0x00 },
     { 0x2a, 0xfd },
     { 0x2b, 0xc8 },
     { 0x3b, 0x21 },
     { 0x3c, 0x38 },
     { 0x28, 0x20 },
     { 0x29, 0x3e },
     { 0x2a, 0xde },
     { 0x2b, 0x4d },
     { 0x28, 0x22 },
     { 0x29, 0x00 },
     { 0x2a, 0x1f },
     { 0x2b, 0xf0 },
     { 0x01, 0x0d },
     { 0x04, 0x08 },
     { 0x05, 0x03 },
     { 0x04, 0x0e },
     { 0x05, 0x00 },
     { 0x08, 0x1e },
     { 0x05, 0x32 },
     { 0x04, 0x0b },
     { 0x05, 0x78 },
     { 0x04, 0x00 },
     { 0x05, 0x00 },
     { 0x04, 0x01 },
     { 0x05, 0x1e },
     { 0x04, 0x02 },
     { 0x05, 0x07 },
     { 0x04, 0x03 },
     { 0x0a, 0xa0 },
     { 0x04, 0x09 },
     { 0x05, 0x00 },
     { 0x04, 0x0a },
     { 0x05, 0xff },
     { 0x04, 0x27 },
     { 0x05, 0x00 },
     { 0x08, 0x50 },
     { 0x05, 0x00 },
     { 0x04, 0x28 },
     { 0x05, 0x00 },
     { 0x04, 0x1e },
     { 0x05, 0x00 },
     { 0x04, 0x29 },
     { 0x05, 0x64 },
     { 0x04, 0x32 },
     { 0x05, 0x68 },
     { 0x04, 0x14 },
     { 0x05, 0x02 },
     { 0x04, 0x04 },
     { 0x05, 0x00 },
     { 0x08, 0x0a },
     { 0x05, 0x22 },
     { 0x04, 0x06 },
     { 0x05, 0x0e },
     { 0x04, 0x07 },
     { 0x05, 0xd8 },
     { 0x04, 0x12 },
     { 0x05, 0x00 },
     { 0x04, 0x13 },
     { 0x05, 0xff },
     { 0x52, 0x01 },
     { 0x50, 0xa7 },
     { 0x51, 0x00 },
     { 0x50, 0xa8 },
     { 0x51, 0xfe },
     { 0x50, 0xa9 },
     { 0x51, 0xff },
     { 0x50, 0xaa },
     { 0x51, 0x00 },
     { 0x50, 0xab },
     { 0x51, 0xff },
     { 0x50, 0xac },
     { 0x51, 0xff },
     { 0x50, 0xad },
     { 0x51, 0x00 },
     { 0x50, 0xae },
     { 0x51, 0xff },
     { 0x50, 0xaf },
     { 0x51, 0xff },
     { 0x5e, 0x07 },
     { 0x50, 0xdc },
     { 0x51, 0x3f },
     { 0x50, 0xdd },
     { 0x51, 0xff },
     { 0x50, 0xde },
     { 0x51, 0x3f },
     { 0x80, 0xdf },

So I conclude that there must be some logic that I'm not understanding. Could you indicate the meaning of the data in the table if there are any? or if I'm doing something wrong, what do I do wrong?

I have also observed that the data passing through the I2C bus are not always the same under Windows, there are some differences between them in parts.

Then I put a few fragments of what I get under Windows 7 and Linux. Not the entire I put because they are of a size of 200KiB.

_Under_Windows_7_

0.184315 - Start
0.268094 - b00100001 - 0x21 - 33
0.279265 - ACK
0.361182 - b00010011 - 0x13 - 19
0.372353 - NACK

0.511985 - b00100000 - 0x20 - 32
0.523156 - ACK
0.603211 - b01110000 - 0x70 - 112
0.614382 - ACK

0.698161 - b00001111 - 0x0f - 15
0.70747 - ACK
0.847102 - b00100000 - 0x20 - 32
0.858273 - ACK
0.938329 - b01110000 - 0x70 - 112
0.949499 - ACK
1.03514 - b11111111 - 0xff - 255
1.04445 - ACK

_Under_Linux_

0.268594 - Start
0.358125 - b00100000 - 0x20 - 32
0.367451 - ACK
0.447656 - b01110000 - 0x70 - 112
0.456982 - ACK
0.548379 - b11111111 - 0xff - 255
0.55957 - ACK
0.686406 - b00100000 - 0x20 - 32
0.697597 - ACK
0.781533 - b00001000 - 0x08 - 8
0.790859 - NACK
0.871064 - b00000001 - 0x01 - 1
0.882256 - ACK

In the next letter, if you let me, I'll cut the old text, because I guess we're back on topic and not too heavy (KB) message.

Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 4 lines

Hi Mauro and others from the list
I searched for a plan B to get the data bus and after several alternative plans that were available to me was to do a logic analyzer
(http://tfla-01.berlios.de).

Yeah, that should work too.

Quoted 4 lines

With the logic analyzer I could get the data transmitted by the I2C bus under Windows, but when I put this data in replacement of originals in mb86a20s.c and I try to run the Linux TV board, do not get the logic analyzer with the same sequence.

Well, there are other I2C devices on the bus,

and the order that they're
initialized in Linux are different than on the original driver.

Quoted 1 line

The new data replacement in mb86a20s

I just posted today a series of patches improving several things on mb86a20s and replacing its initialization table to one found on a newer driver. It also allows using different IF frequencies on the tuner side.

Perhaps this is enough to fix.

Quoted 101 lines

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

      { 0x70, 0x0f },
      { 0x70, 0xff },
      { 0x09, 0x3a },
      { 0x50, 0xd1 },
      { 0x51, 0x22 },
      { 0x39, 0x00 },
      { 0x28, 0x2a },
      { 0x29, 0x00 },
      { 0x2a, 0xfd },
      { 0x2b, 0xc8 },
      { 0x3b, 0x21 },
      { 0x3c, 0x38 },
      { 0x28, 0x20 },
      { 0x29, 0x3e },
      { 0x2a, 0xde },
      { 0x2b, 0x4d },
      { 0x28, 0x22 },
      { 0x29, 0x00 },
      { 0x2a, 0x1f },
      { 0x2b, 0xf0 },
      { 0x01, 0x0d },
      { 0x04, 0x08 },
      { 0x05, 0x03 },
      { 0x04, 0x0e },
      { 0x05, 0x00 },
      { 0x08, 0x1e },
      { 0x05, 0x32 },
      { 0x04, 0x0b },
      { 0x05, 0x78 },
      { 0x04, 0x00 },
      { 0x05, 0x00 },
      { 0x04, 0x01 },
      { 0x05, 0x1e },
      { 0x04, 0x02 },
      { 0x05, 0x07 },
      { 0x04, 0x03 },
      { 0x0a, 0xa0 },
      { 0x04, 0x09 },
      { 0x05, 0x00 },
      { 0x04, 0x0a },
      { 0x05, 0xff },
      { 0x04, 0x27 },
      { 0x05, 0x00 },
      { 0x08, 0x50 },
      { 0x05, 0x00 },
      { 0x04, 0x28 },
      { 0x05, 0x00 },
      { 0x04, 0x1e },
      { 0x05, 0x00 },
      { 0x04, 0x29 },
      { 0x05, 0x64 },
      { 0x04, 0x32 },
      { 0x05, 0x68 },
      { 0x04, 0x14 },
      { 0x05, 0x02 },
      { 0x04, 0x04 },
      { 0x05, 0x00 },
      { 0x08, 0x0a },
      { 0x05, 0x22 },
      { 0x04, 0x06 },
      { 0x05, 0x0e },
      { 0x04, 0x07 },
      { 0x05, 0xd8 },
      { 0x04, 0x12 },
      { 0x05, 0x00 },
      { 0x04, 0x13 },
      { 0x05, 0xff },
      { 0x52, 0x01 },
      { 0x50, 0xa7 },
      { 0x51, 0x00 },
      { 0x50, 0xa8 },
      { 0x51, 0xfe },
      { 0x50, 0xa9 },
      { 0x51, 0xff },
      { 0x50, 0xaa },
      { 0x51, 0x00 },
      { 0x50, 0xab },
      { 0x51, 0xff },
      { 0x50, 0xac },
      { 0x51, 0xff },
      { 0x50, 0xad },
      { 0x51, 0x00 },
      { 0x50, 0xae },
      { 0x51, 0xff },
      { 0x50, 0xaf },
      { 0x51, 0xff },
      { 0x5e, 0x07 },
      { 0x50, 0xdc },
      { 0x51, 0x3f },
      { 0x50, 0xdd },
      { 0x51, 0xff },
      { 0x50, 0xde },
      { 0x51, 0x3f },
      { 0x80, 0xdf },

Quoted 3 lines

So I conclude that there must be some logic that I'm not understanding. Could you indicate the meaning of the data in the table if there are any? or if I'm doing something wrong, what do I do wrong?

I'll take a look on it, and see what it is doing differently.

Quoted 3 lines

I have also observed that the data passing through the I2C bus are not always the same under Windows, there are some differences between them in parts.

Hmm... that's interesting. Did you map the changes?

Quoted 11 lines

Then I put a few fragments of what I get under Windows 7 and Linux. Not the entire I put because they are of a size of 200KiB.

_Under_Windows_7_

0.184315 - Start
0.268094 - b00100001 - 0x21 - 33
0.279265 - ACK
0.361182 - b00010011 - 0x13 - 19
0.372353 - NACK

This is a read.

Quoted 4 lines

0.511985 - b00100000 - 0x20 - 32
0.523156 - ACK
0.603211 - b01110000 - 0x70 - 112
0.614382 - ACK

Quoted 8 lines

0.698161 - b00001111 - 0x0f - 15
0.70747 - ACK
0.847102 - b00100000 - 0x20 - 32
0.858273 - ACK
0.938329 - b01110000 - 0x70 - 112
0.949499 - ACK
1.03514 - b11111111 - 0xff - 255
1.04445 - ACK

Funny that it doesn't write 01 to register 08 here. I think that the this is to disable TS while resetting.

...

Quoted 15 lines

_Under_Linux_

0.268594 - Start
0.358125 - b00100000 - 0x20 - 32
0.367451 - ACK
0.447656 - b01110000 - 0x70 - 112
0.456982 - ACK
0.548379 - b11111111 - 0xff - 255
0.55957 - ACK
0.686406 - b00100000 - 0x20 - 32
0.697597 - ACK
0.781533 - b00001000 - 0x08 - 8
0.790859 - NACK
0.871064 - b00000001 - 0x01 - 1
0.882256 - ACK

You're likely still using the old table.

Quoted 2 lines

In the next letter, if you let me, I'll cut the old text, because I guess we're back on topic and not too heavy (KB) message.

Sure. I always cut not commented parts of the messages I answer.

Cheers,
Mauro

The new data replacement in mb86a20s

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

     { 0x09, 0x3a },

     { 0x28, 0x2a },
     { 0x29, 0x00 },
     { 0x2a, 0xfd },
     { 0x2b, 0xc8 },

     { 0x28, 0x20 },
     { 0x29, 0x3e },
     { 0x2a, 0xde },
     { 0x2b, 0x4d },

     { 0x08, 0x1e },

     { 0x80, 0xdf },

Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

The new data replacement in mb86a20s

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

Please test first my mb86a20s patchset. If it doesn't work, we'll need to dig into the differences.

The better is to group these and reorder them to look like what's there at the driver, and send it like a diff. That would make a way easier to see what's different there.

Anyway, it follows my comments about a few things that came into my eyes.

Quoted 1 line

     { 0x09, 0x3a },

No idea what's here, but it seems a worth trial to change it.

Quoted 4 lines

     { 0x28, 0x2a },
     { 0x29, 0x00 },
     { 0x2a, 0xfd },
     { 0x2b, 0xc8 },

Hmm... the above may explain why it is not working. This is calculated from the XTAL frequency, and IF (if different than 4MHz).

Just changing it could fix the issue.

Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 18 lines

Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

The new data replacement in mb86a20s

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

Please test first my mb86a20s patchset. If it doesn't work, we'll need to dig into the differences.

The better is to group these and reorder them to look like what's there at the driver, and send it like a diff. That would make a way easier to see what's different there.

Quoted 4 lines

Anyway, it follows my comments about a few things that came into my eyes.

Quoted 1 line

      { 0x09, 0x3a },

No idea what's here, but it seems a worth trial to change it.

It controls inversion. I just pushed a patch that will let it handle both normal and inverted spectrum. The DVB core will automatically switch inversion during device tuning.

Quoted 4 lines

Quoted 4 lines

      { 0x28, 0x2a },
      { 0x29, 0x00 },
      { 0x2a, 0xfd },
      { 0x2b, 0xc8 },

Quoted 4 lines

Hmm... the above may explain why it is not working. This is calculated from the XTAL frequency, and IF (if different than 4MHz).

Just changing it could fix the issue.

I also added a patch that allows using a different XTAL frequency.

You can use the calculus there to convert from 0x00fdc8 into the XTAL frequency, if you have the IF set by xc5000.

Hi all

Quoted 21 lines · Mauro Carvalho Chehab

Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 18 lines

Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 7 lines

The new data replacement in mb86a20s

/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {

Please test first my mb86a20s patchset. If it doesn't work, we'll need to dig into the differences.

The better is to group these and reorder them to look like what's there at the driver, and send it like a diff. That would make a way easier to see what's different there.

Quoted 7 lines

Quoted 4 lines

Anyway, it follows my comments about a few things that came into my eyes.

Quoted 1 line

      { 0x09, 0x3a },

No idea what's here, but it seems a worth trial to change it.

It controls inversion. I just pushed a patch that will let it handle both normal and inverted spectrum. The DVB core will automatically switch inversion during device tuning.

I test, but not work.

Before the latest patches, obtained as follows, for example:

dmesg

[  397.076641] mb86a20s: mb86a20s_read_status:
[  397.077129] mb86a20s: mb86a20s_read_status: val = X, status = 0xXX

and now, I don't get anything. But if I use VLC I get this:

dtvdebug: frontend status: 0x00

dtvdebug: frontend status: 0x03

dtvdebug: frontend status: 0x07

dtvdebug: frontend status: 0x01

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

      { 0x28, 0x2a },
      { 0x29, 0x00 },
      { 0x2a, 0xfd },
      { 0x2b, 0xc8 },

Hmm... the above may explain why it is not working. This is calculated from the XTAL frequency, and IF (if different than 4MHz).

Quoted 5 lines

Quoted 1 line

Just changing it could fix the issue.

I also added a patch that allows using a different XTAL frequency.

You can use the calculus there to convert from 0x00fdc8 into the XTAL frequency, if you have the IF set by xc5000.

I don't have the IF. How I can know the intermediate frequency?

Xtal near of xc5000 is 32.000MHz. Perhaps 32/8=4 -->IF

There are other 2 xtal of 16.000MHz and other of 28.636MHz.

Xtal of mb86a20s is 32.571MHz.

In total there are 4 xtal.

With mb86a20s changes made, the logs (i2c traffic) obtained are different from those obtained with Windows

I have yet to thoroughly analyze 24 samples I took with the logic analyzer and try to see your logic. This is going to take some time.

Again thank you very much,

Alfredo

Quoted 7 lines

I test, but not work.

Before the latest patches, obtained as follows, for example:

dmesg

[  397.076641] mb86a20s: mb86a20s_read_status:
[  397.077129] mb86a20s: mb86a20s_read_status: val = X, status = 0xXX

I did a cleanup at the printk messages. Also, the debug ones now use dynamic_printk. That means that they're disabled by default. They can be enabled in runtime (and per-line). If you want to enable all messages, you can do:

To enable all debug messages on mb86a20s:
echo "file drivers/media/dvb-frontends/mb86a20s.c +p" > /sys/kernel/debug/dynamic_debug/control

To clean all debug messages
echo "-p" > /sys/kernel/debug/dynamic_debug/control

To enable just the *ber* or *BER* ones:

	for i in $(cat /sys/kernel/debug/dynamic_debug/control|grep mb86a20s.c|grep -i ber|cut -d' ' -f 1|cut -d: -f2); do
		echo "file drivers/media/dvb-frontends/mb86a20s.c line $i +p" > /sys/kernel/debug/dynamic_debug/control
	done

Quoted 10 lines

and now, I don't get anything. But if I use VLC I get this:

dtvdebug: frontend status: 0x00

dtvdebug: frontend status: 0x03

dtvdebug: frontend status: 0x07

dtvdebug: frontend status: 0x01

Ok, that means that it is trying to sync Viterbi. You're better served if you use dvbv5-scan[1], instead, as it will provide you more information (eventually CNR - if it can keep status = 0x07 for a while, or if you have a zap file:

$ dvbv5-zap -I zap  -c ~/isdb_channel.conf "globo 1seg"
using demux '/dev/dvb/adapter0/demux0'
reading channels from file '/home/mchehab/isdb_channel.conf'
tuning to 485142857 Hz
video pid 529
   dvb_set_pesfilter 529
audio pid 530
   dvb_set_pesfilter 530
RF     (0x01) Signal= 0.00%

RF     (0x01) Signal= 0.00%
RF     (0x01) Signal= 0.00%
Carrier(0x03) Signal= 0.00%
RF     (0x01) Signal= 0.00%
RF     (0x01) Signal= 0.00%
Lock   (0x1f) Quality= Poor Signal= 6.25% C/N= 15.57dB UCB= 96965 postBER= 0 preBER= 3.08x10^-3 PER= 1.00
	  Layer A: Quality= Poor C/N= 15.52dB UCB= 4064 postBER= 0 preBER= 3.08x10^-3 PER= 1.00
	  Layer B: C/N= 30.00dB

I think I asked it already, but eventually, it is just antenna.

The easiest way to discover is to enable the mb86a20s debug:

[ 1443.564782] i2c i2c-3: mb86a20s_initfe: fclk=32571428, IF=4000000, clock reg=0x00ff80
[ 1443.566781] i2c i2c-3: mb86a20s_initfe: IF=4000000, IF reg=0x3ee08f

The IF here come from the tuner, via ops.get_if_frequency().

Hi all

After some time trying to see what the problem is, I have found it is not come the RF signal.

I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-)
When I try to apply these changes to a 3.4 or later kernel does not tune plate.

Between 3.2 and 3.4 kernel there are several changes to the drivers:
CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune.

The changes I have applied to kernel 3.2 are:

In mb86a20s.c, I replaced the table "mb86a20s_init" for which I got from windows and linux last.
With the two works, although it seems better that I got from Windows, I have to experiment a bit more.
Also in "Does a binary search to get RF strength" I replaced 0x04 for 0x05.

On cx23885-card.c

         .name         = "Mygica X8507",
         .tuner_type     = TUNER_XC5000,
         .tuner_addr     = 0x61,
         .tuner_bus     = 1,
         .porta         = CX23885_ANALOG_VIDEO,

(quoted diff) +2 -0

+        .portb        = CX23885_MPEG_DVB,
         .input         = {
 
 
 
       case CX23885_BOARD_MYGICA_X8506:
     case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+    case CX23885_BOARD_MYGICA_X8507:
         ts1->gen_ctrl_val  = 0x5; /* Parallel */
         ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
         ts1->src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
         break;

On cx23885-dvb.c

  #include "stv0367.h"

(quoted diff) +23 -0

+#include "mb86a20s.h"
 
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+    .demod_address = 0x10,
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+    .i2c_address = 0x61,
+    .if_khz = 4000,
+};
 
     case CX23885_BOARD_MYGICA_X8506:
     case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+    case CX23885_BOARD_MYGICA_X8507:
         /* Select Digital TV */
         cx23885_gpio_set(dev, GPIO_0);
         break;
 
+    case CX23885_BOARD_MYGICA_X8507:
+        i2c_bus = &dev->i2c_bus[0];
+        i2c_bus2 = &dev->i2c_bus[1];
+        fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
+            &mygica_x8507_mb86a20s_config,
+            &i2c_bus->i2c_adap);
+        if (fe0->dvb.frontend != NULL) {
+            dvb_attach(xc5000_attach,
+                fe0->dvb.frontend,
+                &i2c_bus2->i2c_adap,
+                &mygica_x8507_xc5000_config);
+        }
+        break;

With kernel 3.4 or greater (I also tried with the latest drivers from git) "looking" i2c bus traffic of mb86a20s I get:

0x20 0x0a 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x07 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x04 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3f 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x1f 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x0f 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x07 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x03 0x20 0x02 0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x05 0x20 0x02 0x21 0x0a
0x20 0x0a 0x21 0x02

and the kernel 3.2 and windows

0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x03 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x01 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xff 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x7f 0x20 0x02 0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0xbf 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x9f 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x3c 0x40 0x04 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x87 0x20 0x02 0x21 0x02
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x83 0x20 0x02 0x21 0x0a
0x20 0x04 0x1f 0x20 0x05 0x00 0x20 0x04 0x20 0x20 0x05 0x85 0x20 0x02 0x21 0x02

Appear not arrived RF signal.

From my limited knowledge I can not understand which of the changes
between 3.2 and 3.4 kernel affect this.

As with kernel 3.2 works, discard configuration problems of: GPIO, signal strength, direction i2c bus and demodulator and intermediate frequency. I am right?

Any suggestions or help is very welcome.

Thanks in advance,

Alfredo

Em Mon, 15 Jul 2013 16:30:18 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 10 lines

Hi all

After some time trying to see what the problem is, I have found it is not come the RF signal.

I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-)
When I try to apply these changes to a 3.4 or later kernel does not tune plate.

Quoted 3 lines

Between 3.2 and 3.4 kernel there are several changes to the drivers:
CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune.

If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it.

You can do (using Linus git tree):

git checkout v3.4
git bisect bad
git checkout good v3.2

git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as "bad" or "good", until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions.

For more reference, you can take a look, for example, at:
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git

Regards,
Mauro

PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect.

Quoted 1 line

The changes I have applied to kernel 3.2 are:

Hi all

Quoted 13 lines · Mauro Carvalho Chehab

Em Mon, 15 Jul 2013 16:30:18 -0300
Alfredo Jesús Delaiti <[email protected]> escreveu:

Quoted 10 lines

Hi all

After some time trying to see what the problem is, I have found it is not come the RF signal.

I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-)
When I try to apply these changes to a 3.4 or later kernel does not tune plate.

Quoted 5 lines

Quoted 3 lines

Between 3.2 and 3.4 kernel there are several changes to the drivers:
CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune.

If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it.

Mauro Thanks for the suggestion.
This weekend I have some time and I'll study how to implement it.

I guess it's do something similar to:

~ $ git clone git://linuxtv.org/media_build.git
~ $ cd media_build
~/media_build $./build --main-git
~/media_build $ cd media
~/media $ gedit drivers/media/video/foo.c
~/media $ make -C ../v4l
~/media $ make -C ../ install
~/media $ make -C .. rmmod
~/media $ modprobe foo

Quoted 6 lines

You can do (using Linus git tree):

git checkout v3.4
git bisect bad
git checkout good v3.2

Where is the git tree of Linus in <git://git.kernel.org/> or
<git://linuxtv.org/>?

Thanks again,

Alfredo

Quoted 18 lines

git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as "bad" or "good", until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions.

For more reference, you can take a look, for example, at:
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git

Regards,
Mauro

PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect.

Quoted 1 line

The changes I have applied to kernel 3.2 are:

No. You'll need to clone the entire kernel tree (either Linus one or mine).

The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image.

That takes some machine time, but, after the first compilation, the subsequent compilations are faster.

I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel:
http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig

After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there.

In summary, what I suggest is:

	$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
	$ git checkout v3.2
	$ git bisect good
	$ diet-kconfig
	$ make menuconfig

select what is missed at media stuff

$ make && make modules install && make install & reboot

after reboot check if everything is ok

$ git bisect bad v3.4

repeat:

	$ make && make modules install && make install & reboot

it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items

test the kernel:
if OK:
$ git bisect good
if BAD:
$ git bisect bad
if git bisect answers that there are xxx bisects left, then goto repeat

After running the above, git bisect will put its fingers on the broken patch.

No. You'll need to clone the entire kernel tree (either Linus one or mine).

The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image.

That takes some machine time, but, after the first compilation, the subsequent compilations are faster.

I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel:
http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig

After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there.

In summary, what I suggest is:

	$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
	$ git checkout v3.2
	$ git bisect good
	$ diet-kconfig
	$ make menuconfig

select what is missed at media stuff

$ make && make modules install && make install & reboot

after reboot check if everything is ok

$ git bisect bad v3.4

repeat:

	$ make && make modules install && make install & reboot

it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items

test the kernel:
if OK:
$ git bisect good
if BAD:
$ git bisect bad
if git bisect answers that there are xxx bisects left, then goto repeat

After running the above, git bisect will put its fingers on the broken patch.

Cheers, Mauro --

Quoted 37 lines

I found the patch that affects the X8507 board is: commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb

--------
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros alfredo@linux-puon:/usr/src/git/linux> git bisect good a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb

Author: Mauro Carvalho Chehab <mchehab  redhat.com>
Date:   Mon Dec 26 20:48:54 2011 -0300

[media] cx23885-dvb: Remove a dirty hack that would require DVBv3

The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some configs.

Replace it by a change during the gate control. This will likely work, but requires testing. Anyway, the current way will break, as soon as we stop copying data for DVBv3 for pure DVBv5 calls.

Compile-tested only.

Cc Michael Krufky <mkrufky linuxtv.org>

Signed-off-by Mauro Carvalho Chehab <mchehab redhat.com>

:040000 040000 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
--------

Quoted 6 lines

I manually removed the patch, then the TV card works.

Unfortunately my lack of knowledge prevents me fix it.

I test new code with pleasure :) !

Hi Alfredo,

Please send me the patches you've made to make isdb-t work on it, and I'll try to address this issue.

Regards,
Mauro