On Sun, 25 Jan 2009 18:35:17 -0500
CityK <cityk@xxxxxxxxxx> wrote:
> hermann pitton wrote:
> > Am Sonntag, den 25.01.2009, 13:49 -0800 schrieb Trent Piepho:
> >
> >> On Sun, 25 Jan 2009, CityK wrote:
> >>
> >>> Hans Verkuil wrote:
> >>>
> >>> this still begs Han's question: "how do you manage to make analog TV
> >>> work if the tda9887 isn't found? That's rather peculiar." I don't have
> >>> an answer for that. The tuner-simple module, however, seems to be able to drive/provide that functionality sufficiently enough.
> >>>
> >> The tda9887 is a simple device with just three registers. If they are set
> >> to the right value when the driver loads, which wouldn't be unexpected,
> >> then it isn't necessary to actually do anything to the chip. If you had a
> >> multistandard tuner (and had access to broadcasts in multiple standards!)
> >> then I expect switching standards wouldn't work without the tda9887 driver.
> >> Verifying both TV and radio tuning works is probably the most realistic way
> >> to check.
> >>
> >
> > For radio you need a tda9887 and working i2c for what i can know.
> >
> > Also after a cold boot the tda988x is not in a usable state for any tv
> > standard yet, it needs to be set by i2c first.
> >
> > But for NTSC, and only NTSC, one pin can be strapped, IIRC, and then it
> > works without any i2c programming needed. Guess it is a tda9885 here.
> >
> >
>
> Looks like that this is the case, as described by Trent, that is
> occurring. Herman, is there any difference between the tda9885 and
> tda887, as I'm pretty sure this is the tda9887 package outlined on page
> 52 of the tda9887 datasheet.
>
> Alas, as being exposed to just NTSC broadcasts, not able to test on the
> multistandard ;)
>
> As for the FM radio, I know that some have mentioned the possibility for
> that with this device, but I don't think anyone ever has succeeded (not
> surprising given the i2c situation) and so the assumption was made,
> rightly or wrongly, that it is not present. I would be amused if FM
> radio support could be realised for the device.
>
> >>>> saa7133[1]: i2c xfer: < c2 30 90 >
> >>>> saa7134[3]: i2c xfer: < c2 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 9c 60 >
> >>>> saa7134[3]: i2c xfer: < c2 0b dc 86 54 >
> >>>>
> >>>> Exactly here, when the buffers are sent the second time the tda9887
> >>>> becomes the first time visible on the bus. According to Hartmut the
> >>>> modification of buffer[3] from 0x60 to 0x54 is that hidden switch,
> >>>> IIRC.
> >>>>
> >>>>
> >>> I believe Mauro is correct in regards to the tda9887 in that, within the
> >>> Philips TUV1236D NIM, it is behind the Nxt2004's i2c gate. After
> >>> re-reading what Michael mentioned previously:
> >>>
> >> Address 0xc2 is the PLL, not the NXT2004. Why would the PLL control an I2C
> >> gate on the nxt2004? I think what I said before about a gpio line on the
> >> PLL being used to hold the analog demod in reset when not in use is more
> >> likely to be correct.
I've seen i2c switches on a few different places:
on bridge driver gpio's;
on demod's gpio's;
on tda9887 gpio's;
on tuner/PLL gpio's.
In the case of tuner/PLL gpio's, you'll see some i2c switch magic inside tuner-core, like this one:
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
I'm not sure what would be the better way to address all those kind of i2c
switches. Maybe we should add a field at device struct specifying what i2c
device contains the i2c bridge, in order to initialize it first.
Cheers,
Mauro
--
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
