On Mon, 10 Jul 2006, Michael Krufky wrote: > This was sent to the wrong mailing list... it should have gone to the > video4linux list. I'm not going to bother adding cc's , since we > already seem to have this issue resolved, for the most part. I think solving it properly might end up being somewhat harder. > > That code is clearly trying to set the Aux byte to 0x20, which is its > > default value after power on reset. What it really is doing is just > > writing random values into the tuner control registers, which doesn't > > matter because they will just get overwritten when the tuner is used. It > > may or may not actually set the aux byte, depending on what happens to be > > in buffer[2]. > > 0x20 for analog, 0x50 for digital. Ahh, so there is code in the dvb version of the tuner driver that changes the AGC take-over point to a different value? I wonder if this should be done to the other ATSC/NTSC tuners with TAU603x chips, of which there are many. The code in the V4L tuner driver does not do what it needs to, as it is only called when the tuner is first detected. After loading or using the dvb device (depending on when the dvb code sets the AB) the AB will be left at 0x50. The V4L tuner will not change it back when the device is opened or the channel is changed. The real problem is that there are two different tuner drivers, both controlling the same tuner, and they don't know anything about each other. A real solution would have to address this fundamental design flaw of V4L + DVB: two drivers for the same hardware stepping on each other's toes. Still, a stop-gap fix can be made now. The tuner needs to program the AB either: 1) When the V4L device is opened 2) Every time the tuner is programmed 1 would be more efficient, but won't handle the case of using both the V4L and DVB devices at the same time. This is possible, but doesn't actually work so well, or make much sense. So I don't see that as much of a problem. 2 might well be easier to impliment. > I didnt test this yet, but I'm not crazy about that "0xdf" value .... > iirc, based on my usb sniffs, we might be better with 0x9f -- I think > that's what the usb windows driver sends, but I have to double check. I used the power on reset defaults to come up with 0xdf. First off, these bits must be set: 1x011xxx The first 1 specifies this is the control byte (CB) and the 011 specifies that the AB will follow. The datasheet says the default value for the CB is: 11001xx1 This sets the charge pump current to high, and turns off the tuning amplifier. Fill in the defaults for the initial 'x' bits, and get: 11011xx1 The remaining 'x' set the reference divider, I guess there is no default. The linux drivers all use a divider of 64, which is '11', so we get: 11011111 or 0xdf The only change 0x9f would make is to set the CP bit to 0, which would select charge pump current of 50 uA instead of the default of 250 uA. It doesn't matter much really, the CB is always re-written when something is tuned. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
