Web lists-archives.com

Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)




hermann pitton a écrit :
Hi Anders,

Am Freitag, den 15.05.2009, 11:18 +0200 schrieb Anders Eriksson:
Success!

I've tracked down the offending change. switch_addr takes on the wrong value
and setting the LNA fails. Here's a i2c dump:

saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c xfer: < 20 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 84 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 86 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 94 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 96 >
saa7133[0]: i2c xfer: < 96 00 >
saa7133[0]: i2c xfer: < 97 =01 =01 =00 =11 =01 =04 =01 =85 >
saa7133[0]: i2c xfer: < 96 1f >
saa7133[0]: i2c xfer: < 97 =89 >
tda8290_probe: tda8290 detected @ 1-004b
tuner' 1-004b: tda829x detected
tuner' 1-004b: Setting mode_mask to 0x0e
tuner' 1-004b: chip found @ 0x96 (saa7133[0])
tuner' 1-004b: tuner 0x4b: Tuner type absent
tuner' i2c attach [addr=0x4b,client=(tuner unset)]
tuner' 1-004b: Calling set_type_addr for type=54, addr=0xff, mode=0x04, config=0x01
tuner' 1-004b: set addr for type -1
tuner' 1-004b: defining GPIO callback
saa7133[0]: i2c xfer: < 96 1f >
saa7133[0]: i2c xfer: < 97 =89 >
tda8290_probe: tda8290 detected @ 1-004b
saa7133[0]: i2c xfer: < 96 2f >
saa7133[0]: i2c xfer: < 97 =00 >
saa7133[0]: i2c xfer: < 96 21 c0 >
saa7133[0]: i2c xfer: < c1 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < c3 =88 >
saa7133[0]: i2c xfer: < c5 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < c7 ERROR: NO_DEVICE
saa7133[0]: i2c xfer: < 96 21 00 >
tda829x 1-004b: setting tuner address to 61
saa7133[0]: i2c xfer: < 96 21 c0 >
saa7133[0]: i2c xfer: < c3 =08 >
tda827x: tda827x_attach:
tda827x: type set to Philips TDA827X
saa7133[0]: i2c xfer: < c3 =08 >
tda827x: tda827xa tuner found
tda827x: tda827x_init:
tda827x: tda827xa_sleep:
saa7133[0]: i2c xfer: < c2 30 90 >
saa7133[0]: i2c xfer: < 96 21 00 >
tda829x 1-004b: type set to tda8290+75a
saa7133[0]: i2c xfer: < 96 21 c0 >
saa7133[0]: i2c xfer: < c2 00 00 00 00 dc 05 8b 0c 04 20 ff 00 00 4b >
saa7133[0]: i2c xfer: < 96 21 00 >
saa7133[0]: i2c xfer: < 96 20 01 >
saa7133[0]: i2c xfer: < 96 30 6f >
tuner' 1-004b: type set to tda8290+75a
tuner' 1-004b: tv freq set to 400.00
tda829x 1-004b: setting tda829x to system xx
tda829x 1-004b: tda827xa config is 0x01
saa7133[0]: i2c xfer: < 96 01 00 >
saa7133[0]: i2c xfer: < 96 02 00 >
saa7133[0]: i2c xfer: < 96 00 00 >
saa7133[0]: i2c xfer: < 96 01 90 >
saa7133[0]: i2c xfer: < 96 28 14 >
saa7133[0]: i2c xfer: < 96 0f 88 >
saa7133[0]: i2c xfer: < 96 05 04 >
saa7133[0]: i2c xfer: < 96 0d 47 >
saa7133[0]: i2c xfer: < 96 21 c0 >
tda827x: setting tda827x to system xx
tda827x: setting LNA to high gain
saa7133[0]: i2c xfer: < 96 22 00 >
                        ^ This address is c2 in all kernels <= 5823b3a63c7661272ea7fef7635955e2a50d17eb


saa7133[0]: i2c xfer: < c2 00 32 f8 00 16 3b bb 1c 04 20 00 >
saa7133[0]: i2c xfer: < c2 90 ff e0 00 99 >
saa7133[0]: i2c xfer: < c2 a0 c0 >
saa7133[0]: i2c xfer: < c2 30 10 >
saa7133[0]: i2c xfer: < c3 =49 =a4 >
tda827x: AGC2 gain is: 10
^ The gain reported on good kernels is 3 Looking at the source, the switch_addr to use in the later kernels is somehow autodetected. How that's done, I've yet to fully understand, but somehow it comes up with the wrong address.

This patch (which obviously needs improvement) hardwires the address back to its original value, and works for 2.6.30-rc5.

diff --git a/drivers/media/common/tuners/tda8290.c b/drivers/media/common/tuners/tda8290.c
index 064d14c..498cc7b 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
dvb_attach(tda827x_attach, fe, priv->tda827x_addr,
                           priv->i2c_props.adap, &priv->cfg);
+               tuner_info("ANDERS: setting switch_addr. was 0x%02x, new 0x%02x\n",priv->cfg.switch_addr,priv->i2c_props.addr);
                priv->cfg.switch_addr = priv->i2c_props.addr;
+               priv->cfg.switch_addr = 0xc2 / 2;
+               tuner_info("ANDERS: new 0x%02x\n",priv->cfg.switch_addr);
+
        }
        if (fe->ops.tuner_ops.init)
                fe->ops.tuner_ops.init(fe);


Could you please help me out and shed some light on what the proper fix is for setting switch_addr?
Thanks,
/Anders


thanks a lot for all your time and energy you did spend on this.

I suggest we start collecting photographs of different LNA circuits on
the wiki.

For now, Tom offered his support already off list, I think we should
start about the question, if that early Hauppauge HVR 1110 has such an
LNA type one at all, since this caused to not look at it further, as it
seemed to be without problems.

Tom, I know you carefully worked on it, but can you reassure that this
LNA config one is really needed on your device?

Hello list,
you are talking about tuner_config = 1 for the hvr 1110, right ?
Changing this option doesn't affect the qualitie of the signal on tv
see http://forum.ubuntu-fr.org/viewtopic.php?pid=1472261
it 's an "old" discussion in french.
This option, as far as i remenber, was not provided by me ...

anyway with tuner debug=1 and .tuner_config=1 , i have no line with AGC or LNA on dmesg

I have somme glitchs with hvr1110 on dvb (not analogic tv) and many for one particular station call M6 (and i'm not the only one user, see previous post on ubuntu-fr.org, with short or long distance from tv relay) . Bug on 310i means potentially bug on hvr1110 as configuration on hvr 1110 was made from 310i

and sorry for bad english

Cheers,

thomas
Cheers,
Hermann



--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list