* Re: mb86a20s and cx23885
[not found] <51054759.7050202@netscape.net>
@ 2013-01-27 16:16 ` Mauro Carvalho Chehab
2013-01-27 21:48 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-27 16:16 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> 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?
I never found any public datasheet for this device.
>
> 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.
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.
>
> 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?
Maybe a remote controller? Do you have a high-resolution picture of the
board?
Regards,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-01-27 16:16 ` mb86a20s and cx23885 Mauro Carvalho Chehab
@ 2013-01-27 21:48 ` Alfredo Jesús Delaiti
2013-01-27 21:52 ` Fwd: " Alfredo Jesús Delaiti
2013-01-28 10:23 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-01-27 21:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi
El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
> Em Sun, 27 Jan 2013 12:27:21 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> 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?
> I never found any public datasheet for this device.
Congratulations for driver you have made
>
>> 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.
> 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.
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
> 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
>
> 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.
>
>> 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?
> 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
Thank you very much
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Fwd: Re: mb86a20s and cx23885
2013-01-27 21:48 ` Alfredo Jesús Delaiti
@ 2013-01-27 21:52 ` Alfredo Jesús Delaiti
2013-01-28 10:23 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-01-27 21:52 UTC (permalink / raw)
To: linux-media
-------- Mensaje original --------
Hi
El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
> Em Sun, 27 Jan 2013 12:27:21 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> 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?
> I never found any public datasheet for this device.
Congratulations for driver you have made
>
>> 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.
> 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.
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
> 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
>
> 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.
>
>> 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?
> 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
Thank you very much
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-01-27 21:48 ` Alfredo Jesús Delaiti
2013-01-27 21:52 ` Fwd: " Alfredo Jesús Delaiti
@ 2013-01-28 10:23 ` Mauro Carvalho Chehab
2013-01-28 20:47 ` Alfredo Jesús Delaiti
1 sibling, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-28 10:23 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> Hi
>
> El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
> > Em Sun, 27 Jan 2013 12:27:21 -0300
> > Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> >
> >> 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?
> > I never found any public datasheet for this device.
>
> Congratulations for driver you have made
Thanks!
>
> >
> >> 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.
> > 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.
>
> 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
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:
> ;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.
>
>
>
> > 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
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.
> 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
I see your point. Yeah, both devices look similar.
> >
> > 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.
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.
> When I do notknow the pins of integrated circuits I can not measure the
> state of the GPIO.
> >
> >> 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?
> > 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.
> 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.
Regards,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-01-28 10:23 ` Mauro Carvalho Chehab
@ 2013-01-28 20:47 ` Alfredo Jesús Delaiti
2013-02-06 14:12 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-01-28 20:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi
El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
> Em Sun, 27 Jan 2013 18:48:57 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> Hi
>>
>> El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
>>> Em Sun, 27 Jan 2013 12:27:21 -0300
>>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>>
>>>> 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?
>>> I never found any public datasheet for this device.
>> Congratulations for driver you have made
> Thanks!
>>>> 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.
>>> 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.
>> 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
> 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:
>
>> ;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
>
> Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?
The exact value is 32.571MHz
>
> 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
>
> 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
>
> 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.
>
>>
>>
>>> 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
> 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.
>
>> 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
> I see your point. Yeah, both devices look similar.
>
>>> 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.
> 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.
>
>> When I do notknow the pins of integrated circuits I can not measure the
>> state of the GPIO.
>>>> 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?
>>> 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 ;)
OK.
>
> 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
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-01-28 20:47 ` Alfredo Jesús Delaiti
@ 2013-02-06 14:12 ` Alfredo Jesús Delaiti
2013-03-03 14:50 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-02-06 14:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi
El 28/01/13 17:47, Alfredo Jesús Delaiti escribió:
> Hi
> El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
>> Em Sun, 27 Jan 2013 18:48:57 -0300
>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>
>>> Hi
>>>
>>> El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
>>>> Em Sun, 27 Jan 2013 12:27:21 -0300
>>>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>>>
>>>>> 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?
>>>> I never found any public datasheet for this device.
>>> Congratulations for driver you have made
>> Thanks!
>>>>> 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.
>>>> 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.
>>> 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
>> 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:
>>
>>> ;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
>
>>
>> Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?
>
> The exact value is 32.571MHz
>
>>
>> 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
>
>>
>> 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
>
>>
>> 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
>>
>>
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?
>> 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.
>>
>>>
>>>
>>>> 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
>> 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.
>>
>>> 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
>> I see your point. Yeah, both devices look similar.
>>
>>>> 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.
>> 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.
>>
>>> When I do notknow the pins of integrated circuits I can not measure the
>>> state of the GPIO.
>>>>> 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?
>>>> 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
>>> 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.
>
>>
>> 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
>
>>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-02-06 14:12 ` Alfredo Jesús Delaiti
@ 2013-03-03 14:50 ` Alfredo Jesús Delaiti
2013-03-03 16:15 ` Mauro Carvalho Chehab
2013-03-03 16:40 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-03-03 14:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi Mauro and others from the list
El 06/02/13 11:12, Alfredo Jesús Delaiti escribió:
> Hi
>
> El 28/01/13 17:47, Alfredo Jesús Delaiti escribió:
>> Hi
>> El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
>>> Em Sun, 27 Jan 2013 18:48:57 -0300
>>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>>
>>>> Hi
>>>>
>>>> El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
>>>>> Em Sun, 27 Jan 2013 12:27:21 -0300
>>>>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>>>>
>>>>>> 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?
>>>>> I never found any public datasheet for this device.
>>>> Congratulations for driver you have made
>>> Thanks!
>>>>>> 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.
>>>>> 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.
>>>> 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
>>> 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:
>>>
>>>> ;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
>>
>>>
>>> Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?
>>
>> The exact value is 32.571MHz
>>
>>>
>>> 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
>>
>>>
>>> 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
>>
>>>
>>> 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.
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
1.1785 - b00100000 - 0x20 - 32
1.18967 - ACK
1.27531 - b00001001 - 0x09 - 9
1.28648 - ACK
1.37771 - b01110100 - 0x74 - 116
1.39074 - Stop
1.5192 - b00100000 - 0x20 - 32
1.52665 - ACK
1.61415 - b01010000 - 0x50 - 80
1.62346 - ACK
1.70351 - b11010001 - 0xd1 - 209
1.71468 - ACK
1.85618 - b00100000 - 0x20 - 32
1.86549 - ACK
1.9474 - b01010001 - 0x51 - 81
1.95858 - ACK
2.0498 - b00100100 - 0x24 - 36
2.06283 - Stop
2.18943 - b00100000 - 0x20 - 32
2.2006 - ACK
2.28066 - b00111001 - 0x39 - 57
2.29183 - ACK
2.37747 - b00000000 - 0x00 - 0
2.38864 - ACK
2.532 - b00100000 - 0x20 - 32
2.54131 - ACK
2.62509 - b00101000 - 0x28 - 40
2.6344 - ACK
2.72004 - b00101010 - 0x2a - 42
2.73121 - ACK
2.8727 - b00100000 - 0x20 - 32
2.88387 - ACK
2.96951 - b00101001 - 0x29 - 41
2.97882 - ACK
3.0626 - b00000000 - 0x00 - 0
3.07191 - ACK
3.21154 - b00100000 - 0x20 - 32
3.22271 - ACK
3.30835 - b00101010 - 0x2a - 42
3.31766 - ACK
3.40144 - b11111101 - 0xfd - 253
3.41261 - ACK
3.55224 - b00100000 - 0x20 - 32
3.56342 - ACK
3.64906 - b00101011 - 0x2b - 43
3.66023 - ACK
3.74028 - b11001000 - 0xc8 - 200
3.74959 - ACK
3.90039 - b00100000 - 0x20 - 32
3.90784 - ACK
3.99162 - b00111011 - 0x3b - 59
4.00093 - ACK
4.08471 - b00100001 - 0x21 - 33
4.09588 - ACK
4.23179 - b00100000 - 0x20 - 32
4.24296 - ACK
4.32674 - b00111100 - 0x3c - 60
4.33791 - ACK
4.42355 - b00111000 - 0x38 - 56
4.43472 - ACK
4.57435 - b00100000 - 0x20 - 32
4.58552 - ACK
4.66558 - b00101000 - 0x28 - 40
4.67489 - ACK
4.75867 - b00100000 - 0x20 - 32
4.76984 - ACK
4.90947 - b00100000 - 0x20 - 32
4.91878 - ACK
5.00256 - b00101001 - 0x29 - 41
5.01373 - ACK
5.09565 - b00111110 - 0x3e - 62
5.10309 - ACK
5.24086 - b00100000 - 0x20 - 32
5.25204 - ACK
5.33768 - b00101010 - 0x2a - 42
5.34885 - ACK
5.43263 - b11011110 - 0xde - 222
5.4438 - ACK
5.58529 - b00100000 - 0x20 - 32
5.59274 - ACK
5.68024 - b00101011 - 0x2b - 43
5.68955 - ACK
5.77147 - b01001101 - 0x4d - 77
5.78078 - ACK
5.92413 - b00100000 - 0x20 - 32
5.93158 - ACK
6.01536 - b00101000 - 0x28 - 40
6.02467 - ACK
6.10845 - b00100010 - 0x22 - 34
6.11776 - ACK
6.25925 - b00100000 - 0x20 - 32
6.27042 - ACK
6.3542 - b00101001 - 0x29 - 41
6.36537 - ACK
6.45101 - b00000000 - 0x00 - 0
6.46032 - ACK
6.60181 - b00100000 - 0x20 - 32
6.61112 - ACK
6.6949 - b00101010 - 0x2a - 42
6.70235 - ACK
6.78985 - b00011111 - 0x1f - 31
6.79916 - ACK
6.94252 - b00100000 - 0x20 - 32
6.95369 - ACK
7.0356 - b00101011 - 0x2b - 43
7.04678 - ACK
7.12497 - b11110000 - 0xf0 - 240
7.13428 - ACK
7.27391 - b00100000 - 0x20 - 32
7.28508 - ACK
7.367 - b00000001 - 0x01 - 1
7.37817 - ACK
7.46195 - b00001101 - 0x0d - 13
7.47312 - ACK
7.61089 - b00100000 - 0x20 - 32
7.62206 - ACK
7.70584 - b00000100 - 0x04 - 4
7.71701 - ACK
7.79893 - b00001000 - 0x08 - 8
7.8101 - ACK
7.94973 - b00100000 - 0x20 - 32
7.95718 - ACK
8.04096 - b00000101 - 0x05 - 5
8.05213 - ACK
8.13963 - b00000110 - 0x06 - 6
8.15452 - Stop
-----------------------------------------
_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
0.966191 - b10000011 - 0x83 - 131
0.975517 - ACK
1.1695 - b00100000 - 0x20 - 32
1.18069 - ACK
1.25903 - b01010001 - 0x51 - 81
1.26836 - ACK
1.36162 - b00100010 - 0x22 - 34
1.37095 - ACK
1.49778 - b00100000 - 0x20 - 32
1.50897 - ACK
1.58731 - b00111001 - 0x39 - 57
1.59851 - ACK
1.69363 - b00000000 - 0x00 - 0
1.70482 - ACK
1.84099 - b00100000 - 0x20 - 32
1.85218 - ACK
1.92865 - b00101000 - 0x28 - 40
1.93984 - ACK
2.0331 - b00101010 - 0x2a - 42
2.0443 - ACK
2.17859 - b00100000 - 0x20 - 32
2.18792 - ACK
2.26626 - b00101001 - 0x29 - 41
2.27745 - ACK
2.36885 - b00000000 - 0x00 - 0
2.37631 - ACK
2.50874 - b00100000 - 0x20 - 32
2.51993 - ACK
2.60014 - b00101010 - 0x2a - 42
2.61133 - ACK
2.70086 - b11111101 - 0xfd - 253
2.71205 - ACK
2.84448 - b00100000 - 0x20 - 32
2.85567 - ACK
2.93588 - b00101011 - 0x2b - 43
2.94707 - ACK
3.0366 - b11001000 - 0xc8 - 200
3.04779 - ACK
3.18209 - b00100000 - 0x20 - 32
3.19142 - ACK
3.27162 - b00111011 - 0x3b - 59
3.28281 - ACK
3.36861 - b00100001 - 0x21 - 33
3.37794 - ACK
3.51783 - b00100000 - 0x20 - 32
3.52902 - ACK
3.60736 - b00111100 - 0x3c - 60
3.61855 - ACK
3.70995 - b00111000 - 0x38 - 56
3.72114 - ACK
3.8573 - b00100000 - 0x20 - 32
3.86663 - ACK
3.94497 - b00101000 - 0x28 - 40
3.95616 - ACK
4.04756 - b00100000 - 0x20 - 32
4.05875 - ACK
4.19305 - b00100000 - 0x20 - 32
4.20424 - ACK
4.28444 - b00101001 - 0x29 - 41
4.31056 - ACK
4.39263 - b01111100 - 0x7c - 124
4.40382 - Stop
---------------------------------------
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.
Thank you very much in advance,
Alfredo
>>>
>>> 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?
>
>
>>> 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.
>>>
>>>>
>>>>
>>>>> 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
>>> 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.
>>>
>>>> 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
>>> I see your point. Yeah, both devices look similar.
>>>
>>>>> 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.
>>> 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.
>>>
>>>> When I do notknow the pins of integrated circuits I can not measure
>>>> the
>>>> state of the GPIO.
>>>>>> 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?
>>>>> 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
>
>
>>>> 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.
>>
>>>
>>> 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
>>
>>>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-03 14:50 ` Alfredo Jesús Delaiti
@ 2013-03-03 16:15 ` Mauro Carvalho Chehab
2013-03-04 23:09 ` Alfredo Jesús Delaiti
2013-03-03 16:40 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-03 16:15 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> 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.
> 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.
>
> 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.
>
> /*
> * 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'll take a look on it, and see what it is doing differently.
> 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?
> 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.
> 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
Funny that it doesn't write 01 to register 08 here.
I think that the this is to disable TS while resetting.
...
> _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.
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-03 14:50 ` Alfredo Jesús Delaiti
2013-03-03 16:15 ` Mauro Carvalho Chehab
@ 2013-03-03 16:40 ` Mauro Carvalho Chehab
2013-03-04 19:42 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-03 16:40 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> 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.
> { 0x09, 0x3a },
No idea what's here, but it seems a worth trial to change it.
> { 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.
> { 0x28, 0x20 },
> { 0x29, 0x3e },
> { 0x2a, 0xde },
> { 0x2b, 0x4d },
This doesn't matter anymore. It will be now be calculated based on the
frequency you use for IF at the tuner.
The above frequency is not 4MHz.
> { 0x08, 0x1e },
This looks weird. You probably got it wrong.
> { 0x80, 0xdf },
This also looks weird. I suspect that you also lost data here.
Regards,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-03 16:40 ` Mauro Carvalho Chehab
@ 2013-03-04 19:42 ` Mauro Carvalho Chehab
2013-03-05 0:00 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-04 19:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Alfredo Jesús Delaiti, linux-media
Em Sun, 3 Mar 2013 13:40:51 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Em Sun, 03 Mar 2013 11:50:25 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>
> > 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.
>
> > { 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.
> > { 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.
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.
Regards,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-03 16:15 ` Mauro Carvalho Chehab
@ 2013-03-04 23:09 ` Alfredo Jesús Delaiti
0 siblings, 0 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-03-04 23:09 UTC (permalink / raw)
To: Mauro Carvalho Chehab, linux-media
Hi Mauro and others
El 03/03/13 13:15, Mauro Carvalho Chehab escribió:
> Em Sun, 03 Mar 2013 11:50:25 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> 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.
>
>> 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,
Yes, logic analyzer "said":
Write to PCF8574 at address 0
and IC that not have name on TV card have the form and number of pin
that pcf8574
also EEPROM FM24C02
> and the order that they're
> initialized in Linux are different than on the original driver.
>> 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.
I tested all patches (those of yesterday and today), but it did not work.
I have not yet seen the changes with the logic analyzer.
>> /*
>> * 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'll take a look on it, and see what it is doing differently.
>
>> 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?
Not yet.
Below I put two different early (on Windows 7)
-----
0.178147 - Start
0.262532 - b00100001 - 0x21 - 33
0.271909 - ACK
0.356294 - b00010011 - 0x13 - 19
0.367545 - NACK
0.517564 - b00000000 - 0x00 - 0
0.528815 - ACK
0.613201 - b11100000 - 0xe0 - 224
0.622577 - ACK
0.703212 - b00011110 - 0x1e - 30
0.718214 - Stop
0.84573 - b00100000 - 0x20 - 32
0.856981 - ACK
0.941366 - b01110000 - 0x70 - 112
0.950743 - ACK
1.03888 - b11111111 - 0xff - 255
1.04825 - ACK
1.16077 - b00100000 - 0x20 - 32
1.17202 - ACK
1.25828 - b00001001 - 0x09 - 9
1.26766 - ACK
1.35017 - b00111010 - 0x3a - 58
1.36142 - ACK
1.50206 - b00100000 - 0x20 - 32
1.51331 - ACK
1.59957 - b01010000 - 0x50 - 80
1.61082 - ACK
1.79085 - Write to PCF8574 at address 0
1.79085 - b01000000 - 0x40 - 64
1.80022 - ACK
1.88461 - b10100010 - 0xa2 - 162
1.89398 - ACK
1.98024 - b01000100 - 0x44 - 68
1.99525 - Error
2.029 - Start
2.12089 - b00100000 - 0x20 - 32
2.13026 - ACK
2.21652 - b00111001 - 0x39 - 57
2.22778 - ACK
2.31216 - b00000000 - 0x00 - 0
2.32154 - ACK
2.46218 - b00100000 - 0x20 - 32
2.47343 - ACK
2.55782 - b00101000 - 0x28 - 40
2.56719 - ACK
2.6422 - b00101010 - 0x2a - 42
...
------------------------------------------------
0.176518 - Start
0.260132 - b00100001 - 0x21 - 33
0.271281 - ACK
0.356753 - b00010011 - 0x13 - 19
0.364185 - NACK
0.490535 - b00100000 - 0x20 - 32
0.501683 - ACK
0.585297 - b01110000 - 0x70 - 112
0.596446 - ACK
0.678202 - b00001111 - 0x0f - 15
0.68935 - ACK
0.8157 - b00100000 - 0x20 - 32
0.826848 - ACK
0.91232 - b01110000 - 0x70 - 112
0.921611 - ACK
1.00337 - b11111111 - 0xff - 255
1.01266 - ACK
1.14272 - b00100000 - 0x20 - 32
1.15201 - ACK
1.23563 - b00001001 - 0x09 - 9
1.24678 - ACK
1.32667 - b00111010 - 0x3a - 58
1.33782 - ACK
1.46789 - b00100000 - 0x20 - 32
1.47904 - ACK
1.57008 - b01010000 - 0x50 - 80
1.58123 - NACK
1.6667 - b10100010 - 0xa2 - 162
1.67599 - Stop
1.79305 - b00100000 - 0x20 - 32
1.8042 - ACK
1.89525 - b01010010 - 0x52 - 82
1.90454 - ACK
1.99187 - b01000100 - 0x44 - 68
2.00488 - Stop
2.12379 - b00100000 - 0x20 - 32
2.13494 - ACK
2.2167 - b00111001 - 0x39 - 57
2.22785 - ACK
2.30774 - b00000000 - 0x00 - 0
2.31889 - ACK
2.4471 - b00100000 - 0x20 - 32
2.45825 - ACK
2.54 - b00101000 - 0x28 - 40
2.55115 - ACK
2.63105 - b00101010 - 0x2a - 42
...
If I have observed that changes occur when any stop.
Below I put another example:
case 1:
...
3.12789 - b00100000 - 0x20 - 32
3.13914 - ACK
3.22352 - b00101010 - 0x2a - 42
3.2329 - ACK
3.31916 - b11111101 - 0xfd - 253
3.33041 - ACK
3.46918 - b00100000 - 0x20 - 32
3.48043 - ACK
3.56482 - b00101011 - 0x2b - 43
3.57232 - ACK
3.6567 - b11001000 - 0xc8 - 200
3.66608 - ACK
3.80485 - b00100000 - 0x20 - 32
3.81422 - ACK
3.90236 - b00111011 - 0x3b - 59
3.91173 - ACK
3.99612 - b00100001 - 0x21 - 33
4.00737 - ACK
4.14989 - b00100000 - 0x20 - 32
4.15926 - ACK
4.24177 - b00111100 - 0x3c - 60
4.25303 - ACK
4.33366 - b00111000 - 0x38 - 56
4.34491 - ACK
4.48931 - b00100000 - 0x20 - 32
4.49868 - ACK
4.57744 - b00101000 - 0x28 - 40
4.58869 - ACK
4.67308 - b00100000 - 0x20 - 32
4.68245 - ACK
4.8231 - b00100000 - 0x20 - 32
4.83435 - ACK
4.91498 - b00101001 - 0x29 - 41
4.92623 - ACK
5.0125 - b00111110 - 0x3e - 62
5.02 - ACK
5.15876 - b00100000 - 0x20 - 32
5.17001 - ACK
5.2544 - b00101010 - 0x2a - 42
5.2619 - ACK
5.34816 - b11011110 - 0xde - 222
...
Case 2:
...
3.103 - b00100000 - 0x20 - 32
3.11415 - ACK
3.19405 - b00101010 - 0x2a - 42
3.2052 - ACK
3.28695 - b11111101 - 0xfd - 253
3.2981 - ACK
3.42817 - b00100000 - 0x20 - 32
3.43932 - ACK
3.52107 - b00101011 - 0x2b - 43
3.53036 - ACK
3.61212 - b11001000 - 0xc8 - 200
3.62327 - ACK
3.75891 - b00100000 - 0x20 - 32
3.7682 - ACK
3.85367 - b01110110 - 0x76 - 118
3.86482 - ACK
3.94843 - b01000010 - 0x42 - 66
3.9633 - Stop
4.08407 - b00100000 - 0x20 - 32
4.09151 - ACK
4.17512 - b00111100 - 0x3c - 60
4.18627 - ACK
4.27174 - b00111000 - 0x38 - 56
4.28103 - ACK
4.40738 - b00100000 - 0x20 - 32
4.41853 - ACK
4.50214 - b00101000 - 0x28 - 40
4.51329 - ACK
4.59505 - b00100000 - 0x20 - 32
4.6062 - ACK
4.73255 - b00100000 - 0x20 - 32
4.74369 - ACK
4.82917 - b00101001 - 0x29 - 41
4.8366 - ACK
4.92207 - b00111110 - 0x3e - 62
4.93322 - ACK
5.06329 - b00100000 - 0x20 - 32
5.07258 - ACK
5.15619 - b00101010 - 0x2a - 42
5.16734 - ACK
5.24724 - b11011110 - 0xde - 222
...
>
>> 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.
>
>> 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
> Funny that it doesn't write 01 to register 08 here.
> I think that the this is to disable TS while resetting.
>
> ...
>
>> _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.
>
>> 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
I answer in the other letters the other questions
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-04 19:42 ` Mauro Carvalho Chehab
@ 2013-03-05 0:00 ` Alfredo Jesús Delaiti
2013-03-05 2:30 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-03-05 0:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi all
El 04/03/13 16:42, Mauro Carvalho Chehab escribió:
> Em Sun, 3 Mar 2013 13:40:51 -0300
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>
>> Em Sun, 03 Mar 2013 11:50:25 -0300
>> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>>
>>
>>> 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.
>>
>>> { 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
Before only got:
dtvdebug: frontend status: 0x00
dtvdebug: frontend status: 0x01
>>> { 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.
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-05 0:00 ` Alfredo Jesús Delaiti
@ 2013-03-05 2:30 ` Mauro Carvalho Chehab
2013-03-08 22:42 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-05 2:30 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Mon, 04 Mar 2013 21:00:17 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> Hi all
>
> El 04/03/13 16:42, Mauro Carvalho Chehab escribió:
> > Em Sun, 3 Mar 2013 13:40:51 -0300
> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> >
> >> Em Sun, 03 Mar 2013 11:50:25 -0300
> >> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> >>
> >>
> >>> 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.
> >>
> >>> { 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
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
> 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.
[1] http://git.linuxtv.org/v4l-utils.git/blob/192d27e53f09924e9ec3150ae146df86da178f02:/utils/dvb/dvbv5-scan.c
> >>> { 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.
> > 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
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().
> There are other 2 xtal of 16.000MHz and other of 28.636MHz.
> Xtal of mb86a20s is 32.571MHz.
That seems to be the standard xtal.
> 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
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-05 2:30 ` Mauro Carvalho Chehab
@ 2013-03-08 22:42 ` Alfredo Jesús Delaiti
2013-04-01 22:41 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-03-08 22:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi all
Sorry for late reply, it's because only I can do during my free time.
El 04/03/13 23:30, Mauro Carvalho Chehab escribió:
>> 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
I think I made something wrong, because I only get this:
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2089
[mb86a20s]mb86a20s_attach =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2117
[mb86a20s]mb86a20s_attach =_ "Frontend revision %d is unknown -
aborting.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1970
[mb86a20s]mb86a20s_read_status_and_stats =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:327
[mb86a20s]mb86a20s_read_status =_ "%s: Status = 0x%02x (state = %d)\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:381
[mb86a20s]mb86a20s_read_signal_strength =_ "%s: signal strength = %d (%d
< RF=%d < %d)\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:526
[mb86a20s]mb86a20s_reset_frontend_cache =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:653
[mb86a20s]mb86a20s_get_frontend =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:671
[mb86a20s]mb86a20s_get_frontend =_ "%s: getting data for layer %c.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:688
[mb86a20s]mb86a20s_get_frontend =_ "%s: modulation %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:694
[mb86a20s]mb86a20s_get_frontend =_ "%s: FEC %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:700
[mb86a20s]mb86a20s_get_frontend =_ "%s: interleaving %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:503
[mb86a20s]mb86a20s_get_segment_count =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:516
[mb86a20s]mb86a20s_get_segment_count =_ "%s: segments: %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:641
[mb86a20s]mb86a20s_layer_bitrate =_ "%s: layer %c bitrate: %d kbps;
counter = %d (0x%06x)\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1605
[mb86a20s]mb86a20s_get_stats =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1419
[mb86a20s]mb86a20s_get_main_CNR =_ "%s: CNR is not available yet.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1441
[mb86a20s]mb86a20s_get_main_CNR =_ "%s: CNR is %d.%03d dB (%d)\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1461
[mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1474
[mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ "%s: MER measures aren't
available yet.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1530
[mb86a20s]mb86a20s_get_blk_error_layer_CNR =_ "%s: CNR for layer %c is
%d.%03d dB (MER = %d).\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:829
[mb86a20s]mb86a20s_get_pre_ber =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:843
[mb86a20s]mb86a20s_get_pre_ber =_ "%s: preBER for layer %c is not
available yet.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:863
[mb86a20s]mb86a20s_get_pre_ber =_ "%s: bit error before Viterbi for
layer %c: %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:890
[mb86a20s]mb86a20s_get_pre_ber =_ "%s: bit count before Viterbi for
layer %c: %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:904
[mb86a20s]mb86a20s_get_pre_ber =_ "%s: updating layer %c preBER counter
to %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:963
[mb86a20s]mb86a20s_get_post_ber =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:977
[mb86a20s]mb86a20s_get_post_ber =_ "%s: post BER for layer %c is not
available yet.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:997
[mb86a20s]mb86a20s_get_post_ber =_ "%s: post bit error for layer %c:
%d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1018
[mb86a20s]mb86a20s_get_post_ber =_ "%s: post bit count for layer %c:
%d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1038
[mb86a20s]mb86a20s_get_post_ber =_ "%s: updating postBER counter on
layer %c to %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1090
[mb86a20s]mb86a20s_get_blk_error =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1108
[mb86a20s]mb86a20s_get_blk_error =_ "%s: block counts for layer %c
aren't available yet.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1128
[mb86a20s]mb86a20s_get_blk_error =_ "%s: block error for layer %c: %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1148
[mb86a20s]mb86a20s_get_blk_error =_ "%s: block count for layer %c: %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1169
[mb86a20s]mb86a20s_get_blk_error =_ "%s: updating PER counter on layer
%c to %d.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1560
[mb86a20s]mb86a20s_stats_not_ready =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1895
[mb86a20s]mb86a20s_set_frontend =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:764
[mb86a20s]mb86a20s_reset_counters =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2061
[mb86a20s]mb86a20s_tune =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1782
[mb86a20s]mb86a20s_initfe =_ "%s called.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1840
[mb86a20s]mb86a20s_initfe =_ "%s: fclk=%d, IF=%d, clock reg=0x%06llx\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1858
[mb86a20s]mb86a20s_initfe =_ "%s: IF=%d, IF reg=0x%06llx\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:1885
[mb86a20s]mb86a20s_initfe =_ "Initialization succeeded.\012"
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/mb86a20s.c:2076
[mb86a20s]mb86a20s_release =_ "%s called.\012"
I have read dynamic-debug-howto.txt and I put the beginning on "GRUB!"
the following:
dyndbg=mb86a20s or
dyndbg_query=mb86a20s or
mb86a20s.dyndbg="QUERY" or
dyndbg="QUERY"
But no change. Something I'm misinterpreting.
> 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
>
>
>> 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 get this:
alfredo@linux-puon:~> dvbv5-zap -I zap -c ~/channels.conf "Encuentro"
using demux '/dev/dvb/adapter0/demux0'
reading channels from file '/home/alfredo/channels.conf'
CODE_RATE_HP (36) command not found during store
CODE_RATE_LP (37) command not found during store
MODULATION (4) command not found during store
HIERARCHY (40) command not found during store
tuning to 521142857 Hz
video pid 272
audio pid 273
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 07 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 03 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
^C
not good.
> I think I asked it already, but eventually, it is just antenna.
My antenna have visual contact with tower of transmission, is only 2 km
away.
>
> 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().
>
>
I made the following tests:
rmmod cx23885
rmmod mb86a20s
modprobe cx23885
and see the traffic of i2c. I made it five times, and got this:
1rm= first rmmod-modprobe
2rm= second rmmod-modprobe
...
"ef (x119)" means that "ef" is repeated 119 times
"E.b.l." means Error byte lenght
1rm 2rm 3rm 4rm 5rm
a0 a0 a0 a0 a0
00 00 00 00 00
a1 a1 a1 a1 a1
08 08 08 08 08
00 00 00 00 00
18 30 18 18 18
03 06 03 03 03
00 00 00 00 00
00 00 00 00 00
03 06 03 03 03
ff fe ff ff ff
20 40 20 20 20
00 00 00 00 00
13 26 13 13 13
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
20 40 20 40 20
00 00 00 00 00
13 26 30 26 13
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
20 00 01 00 20
00 40 00 40 00
13 00 00 00 13
00 26 30 26 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
40 00 02 00 20
00 40 00 40 00
26 00 01 00 13
00 26 60 26 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
40 00 02 00 40
00 40 00 40 00
26 00 01 00 26
00 26 60 4c 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
80 00 02 80 80
00 40 00 00 00
4c 00 01 4c 4c
00 26 60 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 02 80 80
00 40 00 00 00
98 00 01 4c 4c
00 26 60 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 02 80 80
00 40 00 00 00
98 00 01 4c 4c
00 26 60 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 80 00
00 00 02 00 80
98 40 00 4c 00
00 00 01 00 4c
00 26 60 00 00
00 00 00 00 00
00 00 00 20 00
00 00 00 00 00
40 00 00 60 00
00 00 00 0c 20
c0 10 00 00 00
18 00 01 00 60
00 30 00 0d 0c
00 06 60 74 00
1a 00 00 30 00
e8 00 00 0c 0d
60 06 69 14 74
18 3a a0 00 30
60 18 80 38 0c
00 06 60 04 14
c0 0a 80 00 00
20 00 01 00 38
00 1c 80 80 04
02 04 40 00 00
00 00 00 4c 00
01 00 04 00 80
60 80 00 00 00
00 00 02 00 4c
00 4c c0 00 00
00 00 00 00 00
00 00 00 40 00
05 00 00 0c 00
00 00 00 14 00
60 00 0a 00 40
a0 40 00 11 0c
00 0c c0 00 14
88 14 40 00 00
00 00 00 20 11
00 11 10 b0 00
02 00 01 00 00
80 00 05 14 40
00 20 00 01 60
a0 b0 00 c4 00
0f 00 0f40 50 28
21 14 1e 09 03
80 01 Write to PCF8574 14 88
48 c4 40 30 a0
a0 50 24 0c 12
80 09 50 15 28
60 14 c0 00 60
a8 30 30 38 18
00 0c 54 04 2a
c0 15 00 00 00
20 00 e0 01 70
00 38 10 08 08
08 04 00 04 00
40 00 04 00 02
20 01 20 88 10
02 08 10 e0 10
47 04 01 00 01
00 00 26 00 23
00 88 80 01 80
00 e0 00 fd (x24) 00
0f 00 00 fb (x25) 00
ef (x119) 00 07 f9 (x41) 07
20 01 f7 (x46) ef (x27) f7 (x38)
00 fd (x48) ef (x7) E.b.l. ef (x81)
21 fb (x70) bf (x9) 20
13 20 7f (x37) 00
E.b.l. 21 ff (x20) 21
13 E.b.l. 17
E.b.l. start stop
20
00
21
17
stop
My question: Why I not get every time the same?
First supposition: There is noise. I placed an oscilloscope and the
noise level is below the i2c protocol standard.
Second supposition: The wrong takes logic analyzer waveform. No,the
waveform of the oscilloscope and logic analyzer are equal.
Someone can explain me why?
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-03-08 22:42 ` Alfredo Jesús Delaiti
@ 2013-04-01 22:41 ` Alfredo Jesús Delaiti
2013-07-15 19:30 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-04-01 22:41 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi all
After analyzing 15 samples (took me many days),I obtained the table
underneath.
{ 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 },
{ 0x04, 0x0f }, { 0x05, 0x32 },
{ 0x04, 0x0b }, { 0x05, 0x78 },
{ 0x04, 0x00 }, { 0x05, 0x00 },
{ 0x04, 0x01 }, { 0x05, 0x1e },
{ 0x04, 0x02 }, { 0x05, 0x07 },
{ 0x04, 0x03 }, { 0x05, 0xd0 },
{ 0x04, 0x09 }, { 0x05, 0x00 },
{ 0x04, 0x0a }, { 0x05, 0xff },
{ 0x04, 0x27 }, { 0x05, 0x00 },
{ 0x04, 0x28 }, { 0x05, 0x00 },
{ 0x04, 0x1e }, { 0x05, 0x00 },
{ 0x04, 0x29 }, { 0x05, 0x64 },
{ 0x04, 0x32 }, { 0x05, 0x64 },
{ 0x04, 0x14 }, { 0x05, 0x02 },
{ 0x04, 0x04 }, { 0x05, 0x00 },
{ 0x04, 0x05 }, { 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, 0xff },
{ 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 },
{ 0x50, 0xdf }, { 0x51, 0xff },
{ 0x50, 0xe0 }, { 0x51, 0x3f },
{ 0x50, 0xe1 }, { 0x51, 0xff },
{ 0x50, 0xb0 }, { 0x51, 0x07 },
{ 0x50, 0xb2 }, { 0x51, 0x3f },
{ 0x50, 0xb3 }, { 0x51, 0xff },
{ 0x50, 0xb4 }, { 0x51, 0x3f },
{ 0x50, 0xb5 }, { 0x51, 0xff },
{ 0x50, 0xb6 }, { 0x51, 0x3f },
{ 0x50, 0xb7 }, { 0x51, 0xff },
{ 0x50, 0x51 }, { 0x51, 0x04 },
{ 0x50, 0x50 }, { 0x51, 0x02 },
{ 0x45, 0x04 },
{ 0x48, 0x04 },
{ 0x50, 0xd5 }, { 0x51, 0x00 },
{ 0x50, 0xd6 }, { 0x51, 0x1f },
{ 0x50, 0xd2 }, { 0x51, 0x03 },
{ 0x50, 0xd7 }, { 0x51, 0x3f },
{ 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
{ 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
{ 0x04, 0x40 }, { 0x05, 0x00 },
{ 0x28, 0x00 }, { 0x2b, 0x08 },
{ 0x28, 0x05 }, { 0x2b, 0x00 },
{ 0x1c, 0x01 },
{ 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x1f },
{ 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
{ 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x12 },
{ 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x30 },
{ 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x37 },
{ 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
{ 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x09 },
{ 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x06 },
{ 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7b },
{ 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x76 },
{ 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7d },
{ 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x08 },
{ 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0b },
{ 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
{ 0x28, 0x14 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf2 },
{ 0x28, 0x15 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf3 },
{ 0x28, 0x16 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x05 },
{ 0x28, 0x17 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
{ 0x28, 0x18 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
{ 0x28, 0x19 }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xef },
{ 0x28, 0x1a }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xd8 },
{ 0x28, 0x1b }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xf1 },
{ 0x28, 0x1c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x3d },
{ 0x28, 0x1d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x94 },
{ 0x28, 0x1e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xba },
{ 0x50, 0x1e }, { 0x51, 0x5d },
{ 0x50, 0x22 }, { 0x51, 0x00 },
{ 0x50, 0x23 }, { 0x51, 0xc8 },
{ 0x50, 0x24 }, { 0x51, 0x00 },
{ 0x50, 0x25 }, { 0x51, 0xf0 },
{ 0x50, 0x26 }, { 0x51, 0x00 },
{ 0x50, 0x27 }, { 0x51, 0xc3 },
{ 0x50, 0x39 }, { 0x51, 0x02 },
It has very few changes from the one that comes with the controller, but
when trying to use it I get the following:
{ 0x70, 0x0f },
{ 0x70, 0xff },
{ 0x09, 0x3a },
{ 0x50, 0xd1 }, { 0x51, 0x22 },
{ 0x09, 0x3e }, /* This line is inserted alone. Initialize
the frontend? */
{ 0x39, 0x01 }, /* This line is inserted alone. Initialize
the frontend? */
{ 0x71, 0x00 }, /* This line is inserted alone. Initialize
the frontend? */
{ 0x28, 0x2a }, { 0x29, 0x5a }, { 0x2a, 0x6c }, { 0x2b, 0x63 },
/* This line is inserted alone. Adjust IF frequency to match tuner? */
{ 0x28, 0x20 }, { 0x29, 0x33 }, { 0x2a, 0xdf }, { 0x2b, 0xa9 },
/* This line is inserted alone. Adjust IF frequency to match tuner? */
{ 0x50, 0xd5 }, { 0x51, 0x00 }, /* This line is inserted
alone. Adjust IF frequency to match tuner? */
{ 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 },
...
For the rest I get the same thing on Windows. I have commented the line
that added "alone".
I get the following with dvbv5:
alfredo@dhcppc4:~> dvbv5-zap -I zap -c ~/channels.conf "Encuentro"
using demux '/dev/dvb/adapter0/demux0'
reading channels from file '/home/alfredo/channels.conf'
CODE_RATE_HP (36) command not found during store
CODE_RATE_LP (37) command not found during store
MODULATION (4) command not found during store
HIERARCHY (40) command not found during store
tuning to 521142857 Hz
video pid 272
audio pid 273
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
status 01 | signal 0000 | snr ffff | ber 00000000 | unc 0000ffff |
Wath means: CODE_RATE_HP (36) command not found during store;
CODE_RATE_LP (37) command not found during store; MODULATION (4) command
not found during store; HIERARCHY (40) command not found during store?
Any suggestions,
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-04-01 22:41 ` Alfredo Jesús Delaiti
@ 2013-07-15 19:30 ` Alfredo Jesús Delaiti
2013-07-15 20:30 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-15 19:30 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
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,
+ .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"
+#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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-15 19:30 ` Alfredo Jesús Delaiti
@ 2013-07-15 20:30 ` Mauro Carvalho Chehab
2013-07-17 13:54 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-07-15 20:30 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Mon, 15 Jul 2013 16:30:18 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> 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.
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.
>
> 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,
> + .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"
> +#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
Cheers,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-15 20:30 ` Mauro Carvalho Chehab
@ 2013-07-17 13:54 ` Alfredo Jesús Delaiti
2013-07-17 19:23 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-17 13:54 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi all
El 15/07/13 17:30, Mauro Carvalho Chehab escribió:
> Em Mon, 15 Jul 2013 16:30:18 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> 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.
> 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
>
> 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
>
> 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.
>
>> The changes I have applied to kernel 3.2 are:
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-17 13:54 ` Alfredo Jesús Delaiti
@ 2013-07-17 19:23 ` Mauro Carvalho Chehab
2013-07-19 3:38 ` Alfredo Jesús Delaiti
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-07-17 19:23 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Wed, 17 Jul 2013 10:54:19 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> Hi all
>
> El 15/07/13 17:30, Mauro Carvalho Chehab escribió:
> > Em Mon, 15 Jul 2013 16:30:18 -0300
> > Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> >
> >> 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.
> > 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
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.
> >
> > 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
>
>
> >
> > 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.
> >
> >> The changes I have applied to kernel 3.2 are:
> >
>
Cheers,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-17 19:23 ` Mauro Carvalho Chehab
@ 2013-07-19 3:38 ` Alfredo Jesús Delaiti
2013-07-21 13:50 ` Alfredo Jesús Delaiti
2013-07-27 17:55 ` Alfredo Jesús Delaiti
2 siblings, 0 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-19 3:38 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi all
El 17/07/13 16:23, Mauro Carvalho Chehab escribió:
>
> 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.
>
>
>
Thank you very much Mauro.
A very clear explanation. Without it I do not think I could do well.
When finished, I report back what I found
Again, thank you very much,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-17 19:23 ` Mauro Carvalho Chehab
2013-07-19 3:38 ` Alfredo Jesús Delaiti
@ 2013-07-21 13:50 ` Alfredo Jesús Delaiti
2013-07-23 20:58 ` Alfredo Jesús Delaiti
2013-07-27 17:55 ` Alfredo Jesús Delaiti
2 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-21 13:50 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi Mauro
It has given me the following error:
------------------------------------------------
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): f9e5451
[media] af9005-fe: convert set_fontend to use DVBv5 parameters
HEAD is now at f9e5451 [media] af9005-fe: convert set_fontend to use
DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect good
Bisecting: 22 revisions left to test after this (roughly 5 steps)
[8de8594a79ae43b08d115c94f09373f6c673f202] [media] dvb-core: be sure
that drivers won't use DVBv3 internally
alfredo@linux-puon:/usr/src/git/linux> make
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CHK kernel/config_data.h
CC fs/compat_ioctl.o
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to
incomplete type ‘struct dvb_frontend_event’
make[1]: *** [fs/compat_ioctl.o] Error 1
make: *** [fs] Error 2
alfredo@linux-puon:/usr/src/git/linux>
-----------------------------------------------
What should I do now?
I do not want experiment, since "bisect" is a very long process.
Thank you,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-21 13:50 ` Alfredo Jesús Delaiti
@ 2013-07-23 20:58 ` Alfredo Jesús Delaiti
2013-07-23 21:46 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-23 20:58 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi
As was a compilation error, I used git bisect skip. From what I've come up with something that I think is not what I'm looking for.
Is it advisable to do it again? and where you get an error trying to git bisect bad and see where it arrived and then git bisec good again.
what I got was:
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): a08d2c7 [media] pwc: Remove driver specific ioctls
HEAD is now at a08d2c7 [media] pwc: Remove driver specific ioctls
alfredo@linux-puon:/usr/src/git/linux> git bisect bad
Bisecting: 92 revisions left to test after this (roughly 7 steps)
[38e3d7ce41cff58bacebb2bcecf7d386c60b954b] [media] cx23885: Ensure the MPEG encoder height is configured from the norm
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): 38e3d7c [media] cx23885: Ensure the MPEG encoder height is configured from the norm
HEAD is now at 38e3d7c [media] cx23885: Ensure the MPEG encoder height is configured from the norm
alfredo@linux-puon:/usr/src/git/linux> git bisect bad
Bisecting: 45 revisions left to test after this (roughly 6 steps)
[f9e54512fd16379812bcff86d95d0a7d78028b20] [media] af9005-fe: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters
HEAD is now at f9e5451 [media] af9005-fe: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect good
Bisecting: 22 revisions left to test after this (roughly 5 steps)
[8de8594a79ae43b08d115c94f09373f6c673f202] [media] dvb-core: be sure that drivers won't use DVBv3 internally
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> make
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CHK kernel/config_data.h
CC fs/compat_ioctl.o
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: array type has incomplete element type
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: array type has incomplete element type
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1346:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: array type has incomplete element type
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
fs/compat_ioctl.c:1347:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’
make[1]: *** [fs/compat_ioctl.o] Error 1
make: *** [fs] Error 2
alfredo@linux-puon:/usr/src/git/linux>
alfredo@linux-puon:/usr/src/git/linux> git bisect skip
Bisecting: 22 revisions left to test after this (roughly 5 steps)
[a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb] [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): a7d44ba [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
HEAD is now at a7d44ba [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
alfredo@linux-puon:/usr/src/git/linux> git bisect bad
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[2827e1ff8692289a9767ab15be9671bb8df77f79] [media] tlg2300: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): 2827e1f [media] tlg2300: convert set_fontend to use DVBv5 parameters
HEAD is now at 2827e1f [media] tlg2300: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect bad
Bisecting: 4 revisions left to test after this (roughly 3 steps)
[4fa102d5cc5b412fa3bc7cc8c24e4d9052e4f693] [media] vp702x-fe: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): 4fa102d [media] vp702x-fe: convert set_fontend to use DVBv5 parameters
HEAD is now at 4fa102d [media] vp702x-fe: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[15115c17cb1a264a265d6d4769ae0397ed61e630] [media] siano: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): 15115c1 [media] siano: convert set_fontend to use DVBv5 parameters
HEAD is now at 15115c1 [media] siano: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f159451c12f47acec84d13028781e9a296dbdd7b] [media] ttusb-dec: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux>
...
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): f159451 [media] ttusb-dec: convert set_fontend to use DVBv5 parameters
HEAD is now at f159451 [media] ttusb-dec: convert set_fontend to use DVBv5 parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect good
2827e1ff8692289a9767ab15be9671bb8df77f79 is the first bad commit
commit 2827e1ff8692289a9767ab15be9671bb8df77f79
Author: Mauro Carvalho Chehab <mchehab .com>
Date: Mon Dec 26 16:40:17 2011 -0300
[media] tlg2300: convert set_fontend to use DVBv5 parameters
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab .com>
:040000 040000 c381a643177407f5231c472f7716e9b4acc858c6 0666c6a6ce8e18c474b8f33fa1d096929106617b M drivers
alfredo@linux-puon:/usr/src/git/linux>
Thanks in advance,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-23 20:58 ` Alfredo Jesús Delaiti
@ 2013-07-23 21:46 ` Alfredo Jesús Delaiti
0 siblings, 0 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-23 21:46 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi
I forgot, in this section I put "BAD" because not have picture or sound,
but if signal.
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): 2827e1f
[media] tlg2300: convert set_fontend to use DVBv5 parameters
HEAD is now at 2827e1f [media] tlg2300: convert set_fontend to use DVBv5
parameters
alfredo@linux-puon:/usr/src/git/linux> git bisect bad /*apear tunner,
but not tunner*/
Bisecting: 4 revisions left to test after this (roughly 3 steps)
[4fa102d5cc5b412fa3bc7cc8c24e4d9052e4f693] [media] vp702x-fe: convert
set_fontend to use DVBv5 parameters
Is there a way to return to after with bisect without compile all?
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-07-17 19:23 ` Mauro Carvalho Chehab
2013-07-19 3:38 ` Alfredo Jesús Delaiti
2013-07-21 13:50 ` Alfredo Jesús Delaiti
@ 2013-07-27 17:55 ` Alfredo Jesús Delaiti
[not found] ` <20130801090436.6dfa0f68@infradead.org>
2 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-07-27 17:55 UTC (permalink / raw)
To: linux-media; +Cc: Mauro Carvalho Chehab
Hi
El 17/07/13 16:23, Mauro Carvalho Chehab escribió:
>
> 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 --
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
--------
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 :) !
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
[not found] ` <20130801090436.6dfa0f68@infradead.org>
@ 2013-08-01 17:16 ` Alfredo Jesús Delaiti
2013-08-01 17:37 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-08-01 17:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
>>
>> 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
>> --------
>>
>>
>> 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
>
>
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
-----------------------------------------------------------------------
.../{ => }/media/dvb/frontends/mb86a20s.c | 332
++++++--------------
.../{ => }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ => }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ => }/media/video/cx23885/cx23885-video.c | 1 +
.../cx23885/{ => }/media/video/cx23885/cx23885.h | 1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* 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 },
- { 0x08, 0x01 },
- { 0x09, 0x3e },
- { 0x50, 0xd1 },
- { 0x51, 0x22 },
- { 0x39, 0x01 },
- { 0x71, 0x00 },
- { 0x28, 0x2a },
- { 0x29, 0x00 },
- { 0x2a, 0xff },
- { 0x2b, 0x80 },
- { 0x28, 0x20 },
- { 0x29, 0x33 },
- { 0x2a, 0xdf },
- { 0x2b, 0xa9 },
+ { 0x09, 0x3a },
+ { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x39, 0x00 },
+ { 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
- { 0x3c, 0x3a },
+ { 0x3c, 0x38 },
+ { 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+ { 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
- { 0x04, 0x08 },
- { 0x05, 0x05 },
- { 0x04, 0x0e },
- { 0x05, 0x00 },
- { 0x04, 0x0f },
- { 0x05, 0x14 },
- { 0x04, 0x0b },
- { 0x05, 0x8c },
- { 0x04, 0x00 },
- { 0x05, 0x00 },
- { 0x04, 0x01 },
- { 0x05, 0x07 },
- { 0x04, 0x02 },
- { 0x05, 0x0f },
- { 0x04, 0x03 },
- { 0x05, 0xa0 },
- { 0x04, 0x09 },
- { 0x05, 0x00 },
- { 0x04, 0x0a },
- { 0x05, 0xff },
- { 0x04, 0x27 },
- { 0x05, 0x64 },
- { 0x04, 0x28 },
- { 0x05, 0x00 },
- { 0x04, 0x1e },
- { 0x05, 0xff },
- { 0x04, 0x29 },
- { 0x05, 0x0a },
- { 0x04, 0x32 },
- { 0x05, 0x0a },
- { 0x04, 0x14 },
- { 0x05, 0x02 },
- { 0x04, 0x04 },
- { 0x05, 0x00 },
- { 0x04, 0x05 },
- { 0x05, 0x22 },
- { 0x04, 0x06 },
- { 0x05, 0x0e },
- { 0x04, 0x07 },
- { 0x05, 0xd8 },
- { 0x04, 0x12 },
- { 0x05, 0x00 },
- { 0x04, 0x13 },
- { 0x05, 0xff },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
+ { 0x04, 0x0e }, { 0x05, 0x00 },
+ { 0x04, 0x0f }, { 0x05, 0x32 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
+ { 0x04, 0x00 }, { 0x05, 0x00 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
+ { 0x04, 0x09 }, { 0x05, 0x00 },
+ { 0x04, 0x0a }, { 0x05, 0xff },
+ { 0x04, 0x27 }, { 0x05, 0x00 },
+ { 0x04, 0x28 }, { 0x05, 0x00 },
+ { 0x04, 0x1e }, { 0x05, 0x00 },
+ { 0x04, 0x29 }, { 0x05, 0x64 },
+ { 0x04, 0x32 }, { 0x05, 0x64 },
+ { 0x04, 0x14 }, { 0x05, 0x02 },
+ { 0x04, 0x04 }, { 0x05, 0x00 },
+ { 0x04, 0x05 }, { 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, 0xff },
- { 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 },
+ { 0x50, 0xa7 }, { 0x51, 0x00 },
+ { 0x50, 0xa8 }, { 0x51, 0xff },
+ { 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, 0x01 },
- { 0x50, 0xdd },
- { 0x51, 0xf4 },
- { 0x50, 0xde },
- { 0x51, 0x01 },
- { 0x50, 0xdf },
- { 0x51, 0xf4 },
- { 0x50, 0xe0 },
- { 0x51, 0x01 },
- { 0x50, 0xe1 },
- { 0x51, 0xf4 },
- { 0x50, 0xb0 },
- { 0x51, 0x07 },
- { 0x50, 0xb2 },
- { 0x51, 0xff },
- { 0x50, 0xb3 },
- { 0x51, 0xff },
- { 0x50, 0xb4 },
- { 0x51, 0xff },
- { 0x50, 0xb5 },
- { 0x51, 0xff },
- { 0x50, 0xb6 },
- { 0x51, 0xff },
- { 0x50, 0xb7 },
- { 0x51, 0xff },
- { 0x50, 0x50 },
- { 0x51, 0x02 },
- { 0x50, 0x51 },
- { 0x51, 0x04 },
+ { 0x50, 0xdc }, { 0x51, 0x3f },
+ { 0x50, 0xdd }, { 0x51, 0xff },
+ { 0x50, 0xde }, { 0x51, 0x3f },
+ { 0x50, 0xdf }, { 0x51, 0xff },
+ { 0x50, 0xe0 }, { 0x51, 0x3f },
+ { 0x50, 0xe1 }, { 0x51, 0xff },
+ { 0x50, 0xb0 }, { 0x51, 0x07 },
+ { 0x50, 0xb2 }, { 0x51, 0x3f },
+ { 0x50, 0xb3 }, { 0x51, 0xff },
+ { 0x50, 0xb4 }, { 0x51, 0x3f },
+ { 0x50, 0xb5 }, { 0x51, 0xff },
+ { 0x50, 0xb6 }, { 0x51, 0x3f },
+ { 0x50, 0xb7 }, { 0x51, 0xff },
+ { 0x50, 0x51 }, { 0x51, 0x04 },
+ { 0x50, 0x50 }, { 0x51, 0x02 },
{ 0x45, 0x04 },
{ 0x48, 0x04 },
- { 0x50, 0xd5 },
- { 0x51, 0x01 }, /* Serial */
- { 0x50, 0xd6 },
- { 0x51, 0x1f },
- { 0x50, 0xd2 },
- { 0x51, 0x03 },
- { 0x50, 0xd7 },
- { 0x51, 0x3f },
+ { 0x50, 0xd5 }, { 0x51, 0x00 },
+ { 0x50, 0xd6 }, { 0x51, 0x1f },
+ { 0x50, 0xd2 }, { 0x51, 0x03 },
+ { 0x50, 0xd7 }, { 0x51, 0x3f },
+ { 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
+ { 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
+ { 0x04, 0x40 },
+ { 0x05, 0x00 },
+ { 0x28, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x05 }, { 0x2b, 0x00 },
{ 0x1c, 0x01 },
- { 0x28, 0x06 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x03 },
- { 0x28, 0x07 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0d },
- { 0x28, 0x08 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x02 },
- { 0x28, 0x09 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x01 },
- { 0x28, 0x0a },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x21 },
- { 0x28, 0x0b },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x29 },
- { 0x28, 0x0c },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x16 },
- { 0x28, 0x0d },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x31 },
- { 0x28, 0x0e },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0e },
- { 0x28, 0x0f },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x4e },
- { 0x28, 0x10 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x46 },
- { 0x28, 0x11 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0f },
- { 0x28, 0x12 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x56 },
- { 0x28, 0x13 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x35 },
- { 0x28, 0x14 },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0xbe },
- { 0x28, 0x15 },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0x84 },
- { 0x28, 0x16 },
- { 0x29, 0x00 },
- { 0x2a, 0x03 },
- { 0x2b, 0xee },
- { 0x28, 0x17 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x98 },
- { 0x28, 0x18 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x9f },
- { 0x28, 0x19 },
- { 0x29, 0x00 },
- { 0x2a, 0x07 },
- { 0x2b, 0xb2 },
- { 0x28, 0x1a },
- { 0x29, 0x00 },
- { 0x2a, 0x06 },
- { 0x2b, 0xc2 },
- { 0x28, 0x1b },
- { 0x29, 0x00 },
- { 0x2a, 0x07 },
- { 0x2b, 0x4a },
- { 0x28, 0x1c },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0xbc },
- { 0x28, 0x1d },
- { 0x29, 0x00 },
- { 0x2a, 0x04 },
- { 0x2b, 0xba },
- { 0x28, 0x1e },
- { 0x29, 0x00 },
- { 0x2a, 0x06 },
- { 0x2b, 0x14 },
- { 0x50, 0x1e },
- { 0x51, 0x5d },
- { 0x50, 0x22 },
- { 0x51, 0x00 },
- { 0x50, 0x23 },
- { 0x51, 0xc8 },
- { 0x50, 0x24 },
- { 0x51, 0x00 },
- { 0x50, 0x25 },
- { 0x51, 0xf0 },
- { 0x50, 0x26 },
- { 0x51, 0x00 },
- { 0x50, 0x27 },
- { 0x51, 0xc3 },
- { 0x50, 0x39 },
- { 0x51, 0x02 },
- { 0x50, 0xd5 },
- { 0x51, 0x01 },
- { 0xd0, 0x00 },
+ { 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x1f },
+ { 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x30 },
+ { 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x37 },
+ { 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
+ { 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x09 },
+ { 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x06 },
+ { 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7b },
+ { 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x76 },
+ { 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7d },
+ { 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0b },
+ { 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
+ { 0x28, 0x14 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf2 },
+ { 0x28, 0x15 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf3 },
+ { 0x28, 0x16 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x05 },
+ { 0x28, 0x17 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
+ { 0x28, 0x18 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
+ { 0x28, 0x19 }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xef },
+ { 0x28, 0x1a }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xd8 },
+ { 0x28, 0x1b }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xf1 },
+ { 0x28, 0x1c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x3d },
+ { 0x28, 0x1d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x94 },
+ { 0x28, 0x1e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xba },
+ { 0x50, 0x1e }, { 0x51, 0x5d },
+ { 0x50, 0x22 }, { 0x51, 0x00 },
+ { 0x50, 0x23 }, { 0x51, 0xc8 },
+ { 0x50, 0x24 }, { 0x51, 0x00 },
+ { 0x50, 0x25 }, { 0x51, 0xf0 },
+ { 0x50, 0x26 }, { 0x51, 0x00 },
+ { 0x50, 0x27 }, { 0x51, 0xc3 },
+ { 0x50, 0x39 }, { 0x51, 0x02 },
};
static struct regdata mb86a20s_reset_reception[] = {
{ 0x70, 0xf0 },
{ 0x70, 0xff },
{ 0x08, 0x01 },
{ 0x08, 0x00 },
};
static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
u8 i2c_addr, int reg, int data)
{
u8 buf[] = { reg, data };
struct i2c_msg msg = {
.addr = i2c_addr, .flags = 0, .buf = buf, .len = 2
@@ -418,31 +280,31 @@ static int mb86a20s_read_signal_strength(struct
dvb_frontend *fe, u16 *strength)
u8 val;
dprintk("\n");
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
/* Does a binary search to get RF strength */
rf_max = 0xfff;
rf_min = 0;
do {
rf = (rf_max + rf_min) / 2;
mb86a20s_writereg(state, 0x04, 0x1f);
mb86a20s_writereg(state, 0x05, rf >> 8);
mb86a20s_writereg(state, 0x04, 0x20);
- mb86a20s_writereg(state, 0x04, rf);
+ mb86a20s_writereg(state, 0x05, rf);
val = mb86a20s_readreg(state, 0x02);
if (val & 0x08)
rf_min = (rf_max + rf_min) / 2;
else
rf_max = (rf_max + rf_min) / 2;
if (rf_max - rf_min < 4) {
*strength = (((rf_max + rf_min) / 2) * 65535) / 4095;
break;
}
} while (1);
dprintk("signal strength = %d\n", *strength);
if (fe->ops.i2c_gate_ctrl)
diff --git a/drivers/media/video/cx23885/cx23885-cards.c
b/drivers/media/video/cx23885/cx23885-cards.c
index c3cf089..41bafff 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -426,30 +426,61 @@ struct cx23885_board cx23885_boards[] = {
.vmux = CX25840_COMPOSITE2,
.amux = CX25840_AUDIO6,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE3,
.vmux = CX25840_COMPOSITE3,
.amux = CX25840_AUDIO7,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE4,
.vmux = CX25840_COMPOSITE4,
.amux = CX25840_AUDIO7,
.gpio0 = 0,
} },
},
+ [CX23885_BOARD_MYGICA_X8507] = {
+ .name = "Mygica X8507",
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x61,
+ .tuner_bus = 1,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb= CX23885_MPEG_DVB,
+ .input = {
+ {
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_COMPOSITE2,
+ .amux = CX25840_AUDIO8,
+ },
+ {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX25840_COMPOSITE8,
+ },
+ {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
+ CX25840_SVIDEO_CHROMA4,
+ },
+ {
+ .type = CX23885_VMUX_COMPONENT,
+ .vmux = CX25840_COMPONENT_ON |
+ CX25840_VIN1_CH1 |
+ CX25840_VIN6_CH2 |
+ CX25840_VIN7_CH3,
+ },
+ }
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
/* ------------------------------------------------------------------ */
/* PCI subsystem IDs */
struct cx23885_subid cx23885_subids[] = {
{
.subvendor = 0x0070,
.subdevice = 0x3400,
.card = CX23885_BOARD_UNKNOWN,
}, {
.subvendor = 0x0070,
.subdevice = 0x7600,
.card = CX23885_BOARD_HAUPPAUGE_HVR1800lp,
@@ -625,30 +656,34 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x14f1,
.subdevice = 0x8578,
.card = CX23885_BOARD_MYGICA_X8558PRO,
}, {
.subvendor = 0x107d,
.subdevice = 0x6f22,
.card = CX23885_BOARD_LEADTEK_WINFAST_PXTV1200,
}, {
.subvendor = 0x5654,
.subdevice = 0x2390,
.card = CX23885_BOARD_GOTVIEW_X5_3D_HYBRID,
}, {
.subvendor = 0x1b55,
.subdevice = 0xe2e4,
.card = CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF,
+ }, {
+ .subvendor = 0x14f1,
+ .subdevice = 0x8502,
+ .card = CX23885_BOARD_MYGICA_X8507,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
void cx23885_card_list(struct cx23885_dev *dev)
{
int i;
if (0 == dev->pci->subsystem_vendor &&
0 == dev->pci->subsystem_device) {
printk(KERN_INFO
"%s: Board has no valid PCIe Subsystem ID and can't\n"
"%s: be autodetected. Pass card=<n> insmod option\n"
"%s: to workaround that. Redirect complaints to the\n"
"%s: vendor of the TV card. Best regards,\n"
@@ -1056,30 +1091,31 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1255:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
/* GPIO-5 RF Control: 0 = RF1 Terrestrial, 1 = RF2 Cable */
/* GPIO-6 I2C Gate which can isolate the demod from the bus */
/* GPIO-9 Demod reset */
/* Put the parts into reset and back */
cx23885_gpio_enable(dev, GPIO_9 | GPIO_6 | GPIO_5, 1);
cx23885_gpio_set(dev, GPIO_9 | GPIO_6 | GPIO_5);
cx23885_gpio_clear(dev, GPIO_9);
mdelay(20);
cx23885_gpio_set(dev, GPIO_9);
break;
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+ case CX23885_BOARD_MYGICA_X8507:
/* GPIO-0 (0)Analog / (1)Digital TV */
/* GPIO-1 reset XC5000 */
/* GPIO-2 reset LGS8GL5 / LGS8G75 */
cx23885_gpio_enable(dev, GPIO_0 | GPIO_1 | GPIO_2, 1);
cx23885_gpio_clear(dev, GPIO_1 | GPIO_2);
mdelay(100);
cx23885_gpio_set(dev, GPIO_0 | GPIO_1 | GPIO_2);
mdelay(100);
break;
case CX23885_BOARD_MYGICA_X8558PRO:
/* GPIO-0 reset first ATBM8830 */
/* GPIO-1 reset second ATBM8830 */
cx23885_gpio_enable(dev, GPIO_0 | GPIO_1, 1);
cx23885_gpio_clear(dev, GPIO_0 | GPIO_1);
mdelay(100);
@@ -1393,30 +1429,31 @@ void cx23885_card_setup(struct cx23885_dev *dev)
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;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
ts1->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
ts2->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
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;
case CX23885_BOARD_MYGICA_X8558PRO:
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;
ts2->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
@@ -1456,30 +1493,31 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H_XC4000:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
case CX23885_BOARD_HAUPPAUGE_HVR1270:
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_MPX885:
+ case CX23885_BOARD_MYGICA_X8507:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
if (dev->sd_cx25840) {
dev->sd_cx25840->grp_id = CX23885_HW_AV_CORE;
v4l2_subdev_call(dev->sd_cx25840, core, load_fw);
}
break;
}
/* AUX-PLL 27MHz CLK */
switch (dev->board) {
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
netup_initialize(dev);
break;
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c
b/drivers/media/video/cx23885/cx23885-dvb.c
index bcb45be..46628e2 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -49,30 +49,31 @@
#include "stv0900.h"
#include "stv0900_reg.h"
#include "stv6110.h"
#include "lnbh24.h"
#include "cx24116.h"
#include "cimax2.h"
#include "lgs8gxx.h"
#include "netup-eeprom.h"
#include "netup-init.h"
#include "lgdt3305.h"
#include "atbm8830.h"
#include "ds3000.h"
#include "cx23885-f300.h"
#include "altera-ci.h"
#include "stv0367.h"
+#include "mb86a20s.h"
static unsigned int debug;
#define dprintk(level, fmt, arg...)\
do { if (debug >= level)\
printk(KERN_DEBUG "%s/0: " fmt, dev->name, ## arg);\
} while (0)
/* ------------------------------------------------------------------ */
static unsigned int alt_tuner;
module_param(alt_tuner, int, 0644);
MODULE_PARM_DESC(alt_tuner, "Enable alternate tuner configuration");
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -448,30 +449,41 @@ static struct stv6110_config
netup_stv6110_tunerconfig_b = {
.gain = 8, /* +16 dB - maximum gain */
};
static struct cx24116_config tbs_cx24116_config = {
.demod_address = 0x55,
};
static struct ds3000_config tevii_ds3000_config = {
.demod_address = 0x68,
};
static struct cx24116_config dvbworld_cx24116_config = {
.demod_address = 0x05,
};
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+ .demod_address = 0x10,
+ /*.is_serial = 0,*/
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+ .i2c_address = 0x61,
+ .if_khz = 4000,
+ /*.radio_input = XC5000_RADIO_FM1,*/
+};
+
static struct lgs8gxx_config mygica_x8506_lgs8gl5_config = {
.prod = LGS8GXX_PROD_LGS8GL5,
.demod_address = 0x19,
.serial_ts = 0,
.ts_clk_pol = 1,
.ts_clk_gated = 1,
.if_clk_freq = 30400, /* 30.4 MHz */
.if_freq = 5380, /* 5.38 MHz */
.if_neg_center = 1,
.ext_adc = 0,
.adc_signed = 0,
.if_neg_edge = 0,
};
static struct xc5000_config mygica_x8506_xc5000_config = {
@@ -488,30 +500,31 @@ static int cx23885_dvb_set_frontend(struct
dvb_frontend *fe,
switch (dev->board) {
case CX23885_BOARD_HAUPPAUGE_HVR1275:
switch (param->u.vsb.modulation) {
case VSB_8:
cx23885_gpio_clear(dev, GPIO_5);
break;
case QAM_64:
case QAM_256:
default:
cx23885_gpio_set(dev, GPIO_5);
break;
}
break;
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;
}
return 0;
}
static int cx23885_dvb_fe_ioctl_override(struct dvb_frontend *fe,
unsigned int cmd, void *parg,
unsigned int stage)
{
int err = 0;
switch (stage) {
case DVB_FE_IOCTL_PRE:
@@ -1004,30 +1017,43 @@ static int dvb_register(struct cx23885_tsport *port)
&netup_stv6110_tunerconfig_b,
&i2c_bus->i2c_adap)) {
if (!dvb_attach(lnbh24_attach,
fe0->dvb.frontend,
&i2c_bus->i2c_adap,
LNBH24_PCL | LNBH24_TTX,
LNBH24_TEN, 0x0a))
printk(KERN_ERR
"No LNBH24 found!\n");
}
}
break;
}
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;
case CX23885_BOARD_MYGICA_X8506:
i2c_bus = &dev->i2c_bus[0];
i2c_bus2 = &dev->i2c_bus[1];
fe0->dvb.frontend = dvb_attach(lgs8gxx_attach,
&mygica_x8506_lgs8gl5_config,
&i2c_bus->i2c_adap);
if (fe0->dvb.frontend != NULL) {
dvb_attach(xc5000_attach,
fe0->dvb.frontend,
&i2c_bus2->i2c_adap,
&mygica_x8506_xc5000_config);
}
break;
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
i2c_bus = &dev->i2c_bus[0];
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index e730b92..02bbf30 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -480,30 +480,31 @@ static int cx23885_flatiron_mux(struct cx23885_dev
*dev, int input)
cx23885_flatiron_dump(dev);
return 0;
}
static int cx23885_video_mux(struct cx23885_dev *dev, unsigned int input)
{
dprintk(1, "%s() video_mux: %d [vmux=%d, gpio=0x%x,0x%x,0x%x,0x%x]\n",
__func__,
input, INPUT(input)->vmux,
INPUT(input)->gpio0, INPUT(input)->gpio1,
INPUT(input)->gpio2, INPUT(input)->gpio3);
dev->input = input;
if (dev->board == CX23885_BOARD_MYGICA_X8506 ||
+ dev->board == CX23885_BOARD_MYGICA_X8507 ||
dev->board == CX23885_BOARD_MAGICPRO_PROHDTVE2) {
/* Select Analog TV */
if (INPUT(input)->type == CX23885_VMUX_TELEVISION)
cx23885_gpio_clear(dev, GPIO_0);
}
/* Tell the internal A/V decoder */
v4l2_subdev_call(dev->sd_cx25840, video, s_routing,
INPUT(input)->vmux, 0, 0);
if ((dev->board == CX23885_BOARD_HAUPPAUGE_HVR1800) ||
(dev->board == CX23885_BOARD_MPX885)) {
/* Configure audio routing */
v4l2_subdev_call(dev->sd_cx25840, audio, s_routing,
INPUT(input)->amux, 0, 0);
diff --git a/drivers/media/video/cx23885/cx23885.h
b/drivers/media/video/cx23885/cx23885.h
index b49036f..519f40d 100644
--- a/drivers/media/video/cx23885/cx23885.h
+++ b/drivers/media/video/cx23885/cx23885.h
@@ -75,30 +75,31 @@
#define CX23885_BOARD_HAUPPAUGE_HVR1270 18
#define CX23885_BOARD_HAUPPAUGE_HVR1275 19
#define CX23885_BOARD_HAUPPAUGE_HVR1255 20
#define CX23885_BOARD_HAUPPAUGE_HVR1210 21
#define CX23885_BOARD_MYGICA_X8506 22
#define CX23885_BOARD_MAGICPRO_PROHDTVE2 23
#define CX23885_BOARD_HAUPPAUGE_HVR1850 24
#define CX23885_BOARD_COMPRO_VIDEOMATE_E800 25
#define CX23885_BOARD_HAUPPAUGE_HVR1290 26
#define CX23885_BOARD_MYGICA_X8558PRO 27
#define CX23885_BOARD_LEADTEK_WINFAST_PXTV1200 28
#define CX23885_BOARD_GOTVIEW_X5_3D_HYBRID 29
#define CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF 30
#define CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H_XC4000 31
#define CX23885_BOARD_MPX885 32
+#define CX23885_BOARD_MYGICA_X8507 33
#define GPIO_0 0x00000001
#define GPIO_1 0x00000002
#define GPIO_2 0x00000004
#define GPIO_3 0x00000008
#define GPIO_4 0x00000010
#define GPIO_5 0x00000020
#define GPIO_6 0x00000040
#define GPIO_7 0x00000080
#define GPIO_8 0x00000100
#define GPIO_9 0x00000200
#define GPIO_10 0x00000400
#define GPIO_11 0x00000800
#define GPIO_12 0x00001000
#define GPIO_13 0x00002000
-----------------------------------------------------------------------
I think it is about this part of the patch ( [media] cx23885-dvb: Remove
a dirty hack that would require DVBv3 ) is that the fault occurs:
----------
static int cx23885_dvb_fe_ioctl_override(struct dvb_frontend *fe,
unsigned int cmd, void *parg,
unsigned int stage)
{
int err = 0;
switch (stage) {
case DVB_FE_IOCTL_PRE:
switch (cmd) {
case FE_SET_FRONTEND:
err = cx23885_dvb_set_frontend(fe,
(struct dvb_frontend_parameters *) parg);
break;
}
break;
------------
Because without it, I have not "signal"
I tried to see as it was replaced DVB_FE_IOCTL_PRE in LINUX DVBv5 API,
but did not see in http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html
Again, thank you very much.
Alfredo
^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-08-01 17:16 ` Alfredo Jesús Delaiti
@ 2013-08-01 17:37 ` Mauro Carvalho Chehab
2013-08-01 18:09 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-08-01 17:37 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> Hi
>
> El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
> >>
> >> 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
> >> --------
> >>
> >>
> >> 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
> >
> >
> Mauro thank you very much for your interest.
>
> I send the patch. 3.2 is on a kernel.
>
> -----------------------------------------------------------------------
>
> .../{ => }/media/dvb/frontends/mb86a20s.c | 332
> ++++++--------------
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
Cheers,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-08-01 17:37 ` Mauro Carvalho Chehab
@ 2013-08-01 18:09 ` Alfredo Jesús Delaiti
2013-08-01 18:48 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-08-01 18:09 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
Hi
El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
> Em Thu, 01 Aug 2013 14:16:32 -0300
> Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
>
>> Hi
>>
>> El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
>>>> 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
>>>> --------
>>>>
>>>>
>>>> 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
>>>
>>>
>> Mauro thank you very much for your interest.
>>
>> I send the patch. 3.2 is on a kernel.
>>
>> -----------------------------------------------------------------------
>>
>> .../{ => }/media/dvb/frontends/mb86a20s.c | 332
>> ++++++--------------
> Hmm... unfortunately, your emailer broke the patch. It made a total mess
> with whitespaces. Could you please resend it in a way that whitespaces
> won't be damaged? Otherwise, patch tool won't apply it.
>
> Cheers,
> Mauro
GRRRRRRRRR
I send attached, I hope it will not break this time.
Again, Thanks
Alfredo
[-- Attachment #2: X8507_Kernel3.2_OK.diff --]
[-- Type: text/x-patch, Size: 24118 bytes --]
.../{ => }/media/dvb/frontends/mb86a20s.c | 332 ++++++--------------
.../{ => }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ => }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ => }/media/video/cx23885/cx23885-video.c | 1 +
.../cx23885/{ => }/media/video/cx23885/cx23885.h | 1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* 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 },
- { 0x08, 0x01 },
- { 0x09, 0x3e },
- { 0x50, 0xd1 },
- { 0x51, 0x22 },
- { 0x39, 0x01 },
- { 0x71, 0x00 },
- { 0x28, 0x2a },
- { 0x29, 0x00 },
- { 0x2a, 0xff },
- { 0x2b, 0x80 },
- { 0x28, 0x20 },
- { 0x29, 0x33 },
- { 0x2a, 0xdf },
- { 0x2b, 0xa9 },
+ { 0x09, 0x3a },
+ { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x39, 0x00 },
+ { 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
- { 0x3c, 0x3a },
+ { 0x3c, 0x38 },
+ { 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+ { 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
- { 0x04, 0x08 },
- { 0x05, 0x05 },
- { 0x04, 0x0e },
- { 0x05, 0x00 },
- { 0x04, 0x0f },
- { 0x05, 0x14 },
- { 0x04, 0x0b },
- { 0x05, 0x8c },
- { 0x04, 0x00 },
- { 0x05, 0x00 },
- { 0x04, 0x01 },
- { 0x05, 0x07 },
- { 0x04, 0x02 },
- { 0x05, 0x0f },
- { 0x04, 0x03 },
- { 0x05, 0xa0 },
- { 0x04, 0x09 },
- { 0x05, 0x00 },
- { 0x04, 0x0a },
- { 0x05, 0xff },
- { 0x04, 0x27 },
- { 0x05, 0x64 },
- { 0x04, 0x28 },
- { 0x05, 0x00 },
- { 0x04, 0x1e },
- { 0x05, 0xff },
- { 0x04, 0x29 },
- { 0x05, 0x0a },
- { 0x04, 0x32 },
- { 0x05, 0x0a },
- { 0x04, 0x14 },
- { 0x05, 0x02 },
- { 0x04, 0x04 },
- { 0x05, 0x00 },
- { 0x04, 0x05 },
- { 0x05, 0x22 },
- { 0x04, 0x06 },
- { 0x05, 0x0e },
- { 0x04, 0x07 },
- { 0x05, 0xd8 },
- { 0x04, 0x12 },
- { 0x05, 0x00 },
- { 0x04, 0x13 },
- { 0x05, 0xff },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
+ { 0x04, 0x0e }, { 0x05, 0x00 },
+ { 0x04, 0x0f }, { 0x05, 0x32 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
+ { 0x04, 0x00 }, { 0x05, 0x00 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
+ { 0x04, 0x09 }, { 0x05, 0x00 },
+ { 0x04, 0x0a }, { 0x05, 0xff },
+ { 0x04, 0x27 }, { 0x05, 0x00 },
+ { 0x04, 0x28 }, { 0x05, 0x00 },
+ { 0x04, 0x1e }, { 0x05, 0x00 },
+ { 0x04, 0x29 }, { 0x05, 0x64 },
+ { 0x04, 0x32 }, { 0x05, 0x64 },
+ { 0x04, 0x14 }, { 0x05, 0x02 },
+ { 0x04, 0x04 }, { 0x05, 0x00 },
+ { 0x04, 0x05 }, { 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, 0xff },
- { 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 },
+ { 0x50, 0xa7 }, { 0x51, 0x00 },
+ { 0x50, 0xa8 }, { 0x51, 0xff },
+ { 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, 0x01 },
- { 0x50, 0xdd },
- { 0x51, 0xf4 },
- { 0x50, 0xde },
- { 0x51, 0x01 },
- { 0x50, 0xdf },
- { 0x51, 0xf4 },
- { 0x50, 0xe0 },
- { 0x51, 0x01 },
- { 0x50, 0xe1 },
- { 0x51, 0xf4 },
- { 0x50, 0xb0 },
- { 0x51, 0x07 },
- { 0x50, 0xb2 },
- { 0x51, 0xff },
- { 0x50, 0xb3 },
- { 0x51, 0xff },
- { 0x50, 0xb4 },
- { 0x51, 0xff },
- { 0x50, 0xb5 },
- { 0x51, 0xff },
- { 0x50, 0xb6 },
- { 0x51, 0xff },
- { 0x50, 0xb7 },
- { 0x51, 0xff },
- { 0x50, 0x50 },
- { 0x51, 0x02 },
- { 0x50, 0x51 },
- { 0x51, 0x04 },
+ { 0x50, 0xdc }, { 0x51, 0x3f },
+ { 0x50, 0xdd }, { 0x51, 0xff },
+ { 0x50, 0xde }, { 0x51, 0x3f },
+ { 0x50, 0xdf }, { 0x51, 0xff },
+ { 0x50, 0xe0 }, { 0x51, 0x3f },
+ { 0x50, 0xe1 }, { 0x51, 0xff },
+ { 0x50, 0xb0 }, { 0x51, 0x07 },
+ { 0x50, 0xb2 }, { 0x51, 0x3f },
+ { 0x50, 0xb3 }, { 0x51, 0xff },
+ { 0x50, 0xb4 }, { 0x51, 0x3f },
+ { 0x50, 0xb5 }, { 0x51, 0xff },
+ { 0x50, 0xb6 }, { 0x51, 0x3f },
+ { 0x50, 0xb7 }, { 0x51, 0xff },
+ { 0x50, 0x51 }, { 0x51, 0x04 },
+ { 0x50, 0x50 }, { 0x51, 0x02 },
{ 0x45, 0x04 },
{ 0x48, 0x04 },
- { 0x50, 0xd5 },
- { 0x51, 0x01 }, /* Serial */
- { 0x50, 0xd6 },
- { 0x51, 0x1f },
- { 0x50, 0xd2 },
- { 0x51, 0x03 },
- { 0x50, 0xd7 },
- { 0x51, 0x3f },
+ { 0x50, 0xd5 }, { 0x51, 0x00 },
+ { 0x50, 0xd6 }, { 0x51, 0x1f },
+ { 0x50, 0xd2 }, { 0x51, 0x03 },
+ { 0x50, 0xd7 }, { 0x51, 0x3f },
+ { 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
+ { 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
+ { 0x04, 0x40 },
+ { 0x05, 0x00 },
+ { 0x28, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x05 }, { 0x2b, 0x00 },
{ 0x1c, 0x01 },
- { 0x28, 0x06 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x03 },
- { 0x28, 0x07 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0d },
- { 0x28, 0x08 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x02 },
- { 0x28, 0x09 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x01 },
- { 0x28, 0x0a },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x21 },
- { 0x28, 0x0b },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x29 },
- { 0x28, 0x0c },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x16 },
- { 0x28, 0x0d },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x31 },
- { 0x28, 0x0e },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0e },
- { 0x28, 0x0f },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x4e },
- { 0x28, 0x10 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x46 },
- { 0x28, 0x11 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x0f },
- { 0x28, 0x12 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x56 },
- { 0x28, 0x13 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x35 },
- { 0x28, 0x14 },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0xbe },
- { 0x28, 0x15 },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0x84 },
- { 0x28, 0x16 },
- { 0x29, 0x00 },
- { 0x2a, 0x03 },
- { 0x2b, 0xee },
- { 0x28, 0x17 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x98 },
- { 0x28, 0x18 },
- { 0x29, 0x00 },
- { 0x2a, 0x00 },
- { 0x2b, 0x9f },
- { 0x28, 0x19 },
- { 0x29, 0x00 },
- { 0x2a, 0x07 },
- { 0x2b, 0xb2 },
- { 0x28, 0x1a },
- { 0x29, 0x00 },
- { 0x2a, 0x06 },
- { 0x2b, 0xc2 },
- { 0x28, 0x1b },
- { 0x29, 0x00 },
- { 0x2a, 0x07 },
- { 0x2b, 0x4a },
- { 0x28, 0x1c },
- { 0x29, 0x00 },
- { 0x2a, 0x01 },
- { 0x2b, 0xbc },
- { 0x28, 0x1d },
- { 0x29, 0x00 },
- { 0x2a, 0x04 },
- { 0x2b, 0xba },
- { 0x28, 0x1e },
- { 0x29, 0x00 },
- { 0x2a, 0x06 },
- { 0x2b, 0x14 },
- { 0x50, 0x1e },
- { 0x51, 0x5d },
- { 0x50, 0x22 },
- { 0x51, 0x00 },
- { 0x50, 0x23 },
- { 0x51, 0xc8 },
- { 0x50, 0x24 },
- { 0x51, 0x00 },
- { 0x50, 0x25 },
- { 0x51, 0xf0 },
- { 0x50, 0x26 },
- { 0x51, 0x00 },
- { 0x50, 0x27 },
- { 0x51, 0xc3 },
- { 0x50, 0x39 },
- { 0x51, 0x02 },
- { 0x50, 0xd5 },
- { 0x51, 0x01 },
- { 0xd0, 0x00 },
+ { 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x1f },
+ { 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x30 },
+ { 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x37 },
+ { 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
+ { 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x09 },
+ { 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x06 },
+ { 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7b },
+ { 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x76 },
+ { 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7d },
+ { 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0b },
+ { 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
+ { 0x28, 0x14 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf2 },
+ { 0x28, 0x15 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf3 },
+ { 0x28, 0x16 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x05 },
+ { 0x28, 0x17 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
+ { 0x28, 0x18 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
+ { 0x28, 0x19 }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xef },
+ { 0x28, 0x1a }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xd8 },
+ { 0x28, 0x1b }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xf1 },
+ { 0x28, 0x1c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x3d },
+ { 0x28, 0x1d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x94 },
+ { 0x28, 0x1e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xba },
+ { 0x50, 0x1e }, { 0x51, 0x5d },
+ { 0x50, 0x22 }, { 0x51, 0x00 },
+ { 0x50, 0x23 }, { 0x51, 0xc8 },
+ { 0x50, 0x24 }, { 0x51, 0x00 },
+ { 0x50, 0x25 }, { 0x51, 0xf0 },
+ { 0x50, 0x26 }, { 0x51, 0x00 },
+ { 0x50, 0x27 }, { 0x51, 0xc3 },
+ { 0x50, 0x39 }, { 0x51, 0x02 },
};
static struct regdata mb86a20s_reset_reception[] = {
{ 0x70, 0xf0 },
{ 0x70, 0xff },
{ 0x08, 0x01 },
{ 0x08, 0x00 },
};
static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
u8 i2c_addr, int reg, int data)
{
u8 buf[] = { reg, data };
struct i2c_msg msg = {
.addr = i2c_addr, .flags = 0, .buf = buf, .len = 2
@@ -418,31 +280,31 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
u8 val;
dprintk("\n");
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
/* Does a binary search to get RF strength */
rf_max = 0xfff;
rf_min = 0;
do {
rf = (rf_max + rf_min) / 2;
mb86a20s_writereg(state, 0x04, 0x1f);
mb86a20s_writereg(state, 0x05, rf >> 8);
mb86a20s_writereg(state, 0x04, 0x20);
- mb86a20s_writereg(state, 0x04, rf);
+ mb86a20s_writereg(state, 0x05, rf);
val = mb86a20s_readreg(state, 0x02);
if (val & 0x08)
rf_min = (rf_max + rf_min) / 2;
else
rf_max = (rf_max + rf_min) / 2;
if (rf_max - rf_min < 4) {
*strength = (((rf_max + rf_min) / 2) * 65535) / 4095;
break;
}
} while (1);
dprintk("signal strength = %d\n", *strength);
if (fe->ops.i2c_gate_ctrl)
diff --git a/drivers/media/video/cx23885/cx23885-cards.c b/drivers/media/video/cx23885/cx23885-cards.c
index c3cf089..41bafff 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -426,30 +426,61 @@ struct cx23885_board cx23885_boards[] = {
.vmux = CX25840_COMPOSITE2,
.amux = CX25840_AUDIO6,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE3,
.vmux = CX25840_COMPOSITE3,
.amux = CX25840_AUDIO7,
.gpio0 = 0,
}, {
.type = CX23885_VMUX_COMPOSITE4,
.vmux = CX25840_COMPOSITE4,
.amux = CX25840_AUDIO7,
.gpio0 = 0,
} },
},
+ [CX23885_BOARD_MYGICA_X8507] = {
+ .name = "Mygica X8507",
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x61,
+ .tuner_bus = 1,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb= CX23885_MPEG_DVB,
+ .input = {
+ {
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_COMPOSITE2,
+ .amux = CX25840_AUDIO8,
+ },
+ {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX25840_COMPOSITE8,
+ },
+ {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
+ CX25840_SVIDEO_CHROMA4,
+ },
+ {
+ .type = CX23885_VMUX_COMPONENT,
+ .vmux = CX25840_COMPONENT_ON |
+ CX25840_VIN1_CH1 |
+ CX25840_VIN6_CH2 |
+ CX25840_VIN7_CH3,
+ },
+ }
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
/* ------------------------------------------------------------------ */
/* PCI subsystem IDs */
struct cx23885_subid cx23885_subids[] = {
{
.subvendor = 0x0070,
.subdevice = 0x3400,
.card = CX23885_BOARD_UNKNOWN,
}, {
.subvendor = 0x0070,
.subdevice = 0x7600,
.card = CX23885_BOARD_HAUPPAUGE_HVR1800lp,
@@ -625,30 +656,34 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x14f1,
.subdevice = 0x8578,
.card = CX23885_BOARD_MYGICA_X8558PRO,
}, {
.subvendor = 0x107d,
.subdevice = 0x6f22,
.card = CX23885_BOARD_LEADTEK_WINFAST_PXTV1200,
}, {
.subvendor = 0x5654,
.subdevice = 0x2390,
.card = CX23885_BOARD_GOTVIEW_X5_3D_HYBRID,
}, {
.subvendor = 0x1b55,
.subdevice = 0xe2e4,
.card = CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF,
+ }, {
+ .subvendor = 0x14f1,
+ .subdevice = 0x8502,
+ .card = CX23885_BOARD_MYGICA_X8507,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
void cx23885_card_list(struct cx23885_dev *dev)
{
int i;
if (0 == dev->pci->subsystem_vendor &&
0 == dev->pci->subsystem_device) {
printk(KERN_INFO
"%s: Board has no valid PCIe Subsystem ID and can't\n"
"%s: be autodetected. Pass card=<n> insmod option\n"
"%s: to workaround that. Redirect complaints to the\n"
"%s: vendor of the TV card. Best regards,\n"
@@ -1056,30 +1091,31 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1255:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
/* GPIO-5 RF Control: 0 = RF1 Terrestrial, 1 = RF2 Cable */
/* GPIO-6 I2C Gate which can isolate the demod from the bus */
/* GPIO-9 Demod reset */
/* Put the parts into reset and back */
cx23885_gpio_enable(dev, GPIO_9 | GPIO_6 | GPIO_5, 1);
cx23885_gpio_set(dev, GPIO_9 | GPIO_6 | GPIO_5);
cx23885_gpio_clear(dev, GPIO_9);
mdelay(20);
cx23885_gpio_set(dev, GPIO_9);
break;
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+ case CX23885_BOARD_MYGICA_X8507:
/* GPIO-0 (0)Analog / (1)Digital TV */
/* GPIO-1 reset XC5000 */
/* GPIO-2 reset LGS8GL5 / LGS8G75 */
cx23885_gpio_enable(dev, GPIO_0 | GPIO_1 | GPIO_2, 1);
cx23885_gpio_clear(dev, GPIO_1 | GPIO_2);
mdelay(100);
cx23885_gpio_set(dev, GPIO_0 | GPIO_1 | GPIO_2);
mdelay(100);
break;
case CX23885_BOARD_MYGICA_X8558PRO:
/* GPIO-0 reset first ATBM8830 */
/* GPIO-1 reset second ATBM8830 */
cx23885_gpio_enable(dev, GPIO_0 | GPIO_1, 1);
cx23885_gpio_clear(dev, GPIO_0 | GPIO_1);
mdelay(100);
@@ -1393,30 +1429,31 @@ void cx23885_card_setup(struct cx23885_dev *dev)
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;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
ts1->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
ts2->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
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;
case CX23885_BOARD_MYGICA_X8558PRO:
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;
ts2->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
@@ -1456,30 +1493,31 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H_XC4000:
case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
case CX23885_BOARD_HAUPPAUGE_HVR1270:
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_MPX885:
+ case CX23885_BOARD_MYGICA_X8507:
dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
if (dev->sd_cx25840) {
dev->sd_cx25840->grp_id = CX23885_HW_AV_CORE;
v4l2_subdev_call(dev->sd_cx25840, core, load_fw);
}
break;
}
/* AUX-PLL 27MHz CLK */
switch (dev->board) {
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
netup_initialize(dev);
break;
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c
index bcb45be..46628e2 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -49,30 +49,31 @@
#include "stv0900.h"
#include "stv0900_reg.h"
#include "stv6110.h"
#include "lnbh24.h"
#include "cx24116.h"
#include "cimax2.h"
#include "lgs8gxx.h"
#include "netup-eeprom.h"
#include "netup-init.h"
#include "lgdt3305.h"
#include "atbm8830.h"
#include "ds3000.h"
#include "cx23885-f300.h"
#include "altera-ci.h"
#include "stv0367.h"
+#include "mb86a20s.h"
static unsigned int debug;
#define dprintk(level, fmt, arg...)\
do { if (debug >= level)\
printk(KERN_DEBUG "%s/0: " fmt, dev->name, ## arg);\
} while (0)
/* ------------------------------------------------------------------ */
static unsigned int alt_tuner;
module_param(alt_tuner, int, 0644);
MODULE_PARM_DESC(alt_tuner, "Enable alternate tuner configuration");
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -448,30 +449,41 @@ static struct stv6110_config netup_stv6110_tunerconfig_b = {
.gain = 8, /* +16 dB - maximum gain */
};
static struct cx24116_config tbs_cx24116_config = {
.demod_address = 0x55,
};
static struct ds3000_config tevii_ds3000_config = {
.demod_address = 0x68,
};
static struct cx24116_config dvbworld_cx24116_config = {
.demod_address = 0x05,
};
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+ .demod_address = 0x10,
+ /*.is_serial = 0,*/
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+ .i2c_address = 0x61,
+ .if_khz = 4000,
+ /*.radio_input = XC5000_RADIO_FM1,*/
+};
+
static struct lgs8gxx_config mygica_x8506_lgs8gl5_config = {
.prod = LGS8GXX_PROD_LGS8GL5,
.demod_address = 0x19,
.serial_ts = 0,
.ts_clk_pol = 1,
.ts_clk_gated = 1,
.if_clk_freq = 30400, /* 30.4 MHz */
.if_freq = 5380, /* 5.38 MHz */
.if_neg_center = 1,
.ext_adc = 0,
.adc_signed = 0,
.if_neg_edge = 0,
};
static struct xc5000_config mygica_x8506_xc5000_config = {
@@ -488,30 +500,31 @@ static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
switch (dev->board) {
case CX23885_BOARD_HAUPPAUGE_HVR1275:
switch (param->u.vsb.modulation) {
case VSB_8:
cx23885_gpio_clear(dev, GPIO_5);
break;
case QAM_64:
case QAM_256:
default:
cx23885_gpio_set(dev, GPIO_5);
break;
}
break;
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;
}
return 0;
}
static int cx23885_dvb_fe_ioctl_override(struct dvb_frontend *fe,
unsigned int cmd, void *parg,
unsigned int stage)
{
int err = 0;
switch (stage) {
case DVB_FE_IOCTL_PRE:
@@ -1004,30 +1017,43 @@ static int dvb_register(struct cx23885_tsport *port)
&netup_stv6110_tunerconfig_b,
&i2c_bus->i2c_adap)) {
if (!dvb_attach(lnbh24_attach,
fe0->dvb.frontend,
&i2c_bus->i2c_adap,
LNBH24_PCL | LNBH24_TTX,
LNBH24_TEN, 0x0a))
printk(KERN_ERR
"No LNBH24 found!\n");
}
}
break;
}
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;
case CX23885_BOARD_MYGICA_X8506:
i2c_bus = &dev->i2c_bus[0];
i2c_bus2 = &dev->i2c_bus[1];
fe0->dvb.frontend = dvb_attach(lgs8gxx_attach,
&mygica_x8506_lgs8gl5_config,
&i2c_bus->i2c_adap);
if (fe0->dvb.frontend != NULL) {
dvb_attach(xc5000_attach,
fe0->dvb.frontend,
&i2c_bus2->i2c_adap,
&mygica_x8506_xc5000_config);
}
break;
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
i2c_bus = &dev->i2c_bus[0];
diff --git a/drivers/media/video/cx23885/cx23885-video.c b/drivers/media/video/cx23885/cx23885-video.c
index e730b92..02bbf30 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -480,30 +480,31 @@ static int cx23885_flatiron_mux(struct cx23885_dev *dev, int input)
cx23885_flatiron_dump(dev);
return 0;
}
static int cx23885_video_mux(struct cx23885_dev *dev, unsigned int input)
{
dprintk(1, "%s() video_mux: %d [vmux=%d, gpio=0x%x,0x%x,0x%x,0x%x]\n",
__func__,
input, INPUT(input)->vmux,
INPUT(input)->gpio0, INPUT(input)->gpio1,
INPUT(input)->gpio2, INPUT(input)->gpio3);
dev->input = input;
if (dev->board == CX23885_BOARD_MYGICA_X8506 ||
+ dev->board == CX23885_BOARD_MYGICA_X8507 ||
dev->board == CX23885_BOARD_MAGICPRO_PROHDTVE2) {
/* Select Analog TV */
if (INPUT(input)->type == CX23885_VMUX_TELEVISION)
cx23885_gpio_clear(dev, GPIO_0);
}
/* Tell the internal A/V decoder */
v4l2_subdev_call(dev->sd_cx25840, video, s_routing,
INPUT(input)->vmux, 0, 0);
if ((dev->board == CX23885_BOARD_HAUPPAUGE_HVR1800) ||
(dev->board == CX23885_BOARD_MPX885)) {
/* Configure audio routing */
v4l2_subdev_call(dev->sd_cx25840, audio, s_routing,
INPUT(input)->amux, 0, 0);
diff --git a/drivers/media/video/cx23885/cx23885.h b/drivers/media/video/cx23885/cx23885.h
index b49036f..519f40d 100644
--- a/drivers/media/video/cx23885/cx23885.h
+++ b/drivers/media/video/cx23885/cx23885.h
@@ -75,30 +75,31 @@
#define CX23885_BOARD_HAUPPAUGE_HVR1270 18
#define CX23885_BOARD_HAUPPAUGE_HVR1275 19
#define CX23885_BOARD_HAUPPAUGE_HVR1255 20
#define CX23885_BOARD_HAUPPAUGE_HVR1210 21
#define CX23885_BOARD_MYGICA_X8506 22
#define CX23885_BOARD_MAGICPRO_PROHDTVE2 23
#define CX23885_BOARD_HAUPPAUGE_HVR1850 24
#define CX23885_BOARD_COMPRO_VIDEOMATE_E800 25
#define CX23885_BOARD_HAUPPAUGE_HVR1290 26
#define CX23885_BOARD_MYGICA_X8558PRO 27
#define CX23885_BOARD_LEADTEK_WINFAST_PXTV1200 28
#define CX23885_BOARD_GOTVIEW_X5_3D_HYBRID 29
#define CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF 30
#define CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H_XC4000 31
#define CX23885_BOARD_MPX885 32
+#define CX23885_BOARD_MYGICA_X8507 33
#define GPIO_0 0x00000001
#define GPIO_1 0x00000002
#define GPIO_2 0x00000004
#define GPIO_3 0x00000008
#define GPIO_4 0x00000010
#define GPIO_5 0x00000020
#define GPIO_6 0x00000040
#define GPIO_7 0x00000080
#define GPIO_8 0x00000100
#define GPIO_9 0x00000200
#define GPIO_10 0x00000400
#define GPIO_11 0x00000800
#define GPIO_12 0x00001000
#define GPIO_13 0x00002000
^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-08-01 18:09 ` Alfredo Jesús Delaiti
@ 2013-08-01 18:48 ` Mauro Carvalho Chehab
2013-08-02 3:18 ` Alfredo Jesús Delaiti
0 siblings, 1 reply; 29+ messages in thread
From: Mauro Carvalho Chehab @ 2013-08-01 18:48 UTC (permalink / raw)
To: Alfredo Jesús Delaiti; +Cc: linux-media
Em Thu, 01 Aug 2013 15:09:35 -0300
Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> Hi
>
> El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
> > Em Thu, 01 Aug 2013 14:16:32 -0300
> > Alfredo Jesús Delaiti <alfredodelaiti@netscape.net> escreveu:
> >
> >> Hi
> >>
> >> El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
> >>>> 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
> >>>> --------
> >>>>
> >>>>
> >>>> 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
> >>>
> >>>
> >> Mauro thank you very much for your interest.
> >>
> >> I send the patch. 3.2 is on a kernel.
> >>
> >> -----------------------------------------------------------------------
> >>
> >> .../{ => }/media/dvb/frontends/mb86a20s.c | 332
> >> ++++++--------------
> > Hmm... unfortunately, your emailer broke the patch. It made a total mess
> > with whitespaces. Could you please resend it in a way that whitespaces
> > won't be damaged? Otherwise, patch tool won't apply it.
> >
> > Cheers,
> > Mauro
>
> GRRRRRRRRR
>
> I send attached, I hope it will not break this time.
This time it arrived fine, thanks!
Btw, those changes at mb86a20s are required for it to work, or just alters
somewhat the tuning?
Regards,
Mauro
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: mb86a20s and cx23885
2013-08-01 18:48 ` Mauro Carvalho Chehab
@ 2013-08-02 3:18 ` Alfredo Jesús Delaiti
0 siblings, 0 replies; 29+ messages in thread
From: Alfredo Jesús Delaiti @ 2013-08-02 3:18 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Hi
El 01/08/13 15:48, Mauro Carvalho Chehab escribió:
> This time it arrived fine, thanks!
>
> Btw, those changes at mb86a20s are required for it to work, or just alters
> somewhat the tuning?
>
> Regards,
> Mauro
Without these changes do not work.
With the original controller I get: mb86a20s: mb86a20s_read_status: val = 9, status = 0x1f
but not video, not sound. That is the reason why I tested with kernel 3.2.
Those changes I got to sniff the i2c traffic under windows.
I have all traffic from i2c until obtaining image(I did it as the more repetitive than 10 samples).
If it helps something I put on the list.
Also I use "modprobe cx23885 debug = 3", but I saw nothing significant
Thanks,
Alfredo
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2013-08-02 3:19 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <51054759.7050202@netscape.net>
2013-01-27 16:16 ` mb86a20s and cx23885 Mauro Carvalho Chehab
2013-01-27 21:48 ` Alfredo Jesús Delaiti
2013-01-27 21:52 ` Fwd: " Alfredo Jesús Delaiti
2013-01-28 10:23 ` Mauro Carvalho Chehab
2013-01-28 20:47 ` Alfredo Jesús Delaiti
2013-02-06 14:12 ` Alfredo Jesús Delaiti
2013-03-03 14:50 ` Alfredo Jesús Delaiti
2013-03-03 16:15 ` Mauro Carvalho Chehab
2013-03-04 23:09 ` Alfredo Jesús Delaiti
2013-03-03 16:40 ` Mauro Carvalho Chehab
2013-03-04 19:42 ` Mauro Carvalho Chehab
2013-03-05 0:00 ` Alfredo Jesús Delaiti
2013-03-05 2:30 ` Mauro Carvalho Chehab
2013-03-08 22:42 ` Alfredo Jesús Delaiti
2013-04-01 22:41 ` Alfredo Jesús Delaiti
2013-07-15 19:30 ` Alfredo Jesús Delaiti
2013-07-15 20:30 ` Mauro Carvalho Chehab
2013-07-17 13:54 ` Alfredo Jesús Delaiti
2013-07-17 19:23 ` Mauro Carvalho Chehab
2013-07-19 3:38 ` Alfredo Jesús Delaiti
2013-07-21 13:50 ` Alfredo Jesús Delaiti
2013-07-23 20:58 ` Alfredo Jesús Delaiti
2013-07-23 21:46 ` Alfredo Jesús Delaiti
2013-07-27 17:55 ` Alfredo Jesús Delaiti
[not found] ` <20130801090436.6dfa0f68@infradead.org>
2013-08-01 17:16 ` Alfredo Jesús Delaiti
2013-08-01 17:37 ` Mauro Carvalho Chehab
2013-08-01 18:09 ` Alfredo Jesús Delaiti
2013-08-01 18:48 ` Mauro Carvalho Chehab
2013-08-02 3:18 ` Alfredo Jesús Delaiti
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.