Am Mittwoch, den 28.01.2009, 00:23 -0200 schrieb Mauro Carvalho Chehab: > 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. > The first i2c bus master should be always first. On PCI this will be the bridge and nothing else. I hate to say it, but it was a PITA to argue against the "frontend" stuff, which until today has no realistic concept for that and confuses a lot on that side. To see high tones on every smallest intention to do something better about it, made it the most frustrating stuff I have seen so far. Cheers, Hermann -- 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
