Re: mb86a20s and cx23885

[Alfredo Jesús Delaiti <alfredodelaiti@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html