Message ID | 20090515091827.864A12C4167@tippex.mynet.homeunix.org (mailing list archive) |
---|---|
State | RFC |
Headers | show |
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? Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hermann-pitton@arcor.de said: > thanks a lot for all your time and energy you did spend on this My pleasure. Especially since I start to see some progress! > I suggest we start collecting photographs of different LNA circuits on the > wiki. Do you want me to open up the case and take some photos of the board? Any particular circuit I should look for? > 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. Well, this is a Pinnacle 310i, not a Hauppauge. At least acording to the box it came in! Are we talking about two different cards here? /Anders -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Am Samstag, den 16.05.2009, 16:02 +0200 schrieb Anders Eriksson: > hermann-pitton@arcor.de said: > > thanks a lot for all your time and energy you did spend on this > My pleasure. Especially since I start to see some progress! > > > I suggest we start collecting photographs of different LNA circuits on the > > wiki. > Do you want me to open up the case and take some photos of the board? Any > particular circuit I should look for? > > > 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. > Well, this is a Pinnacle 310i, not a Hauppauge. At least acording to the box > it came in! Are we talking about two different cards here? well, the point is that Hauppauge bought Pinnacle recently concerning capture cards, but hat is Europe for now. The 310i and HVR 1110 are the only cards using config one for LNA support. I can provide a photograph for LNA config type two on a Ausus OEM 3in1. Don't use any brute force. On recent cards it is easy to remove the upper tuner shielding, but on early cards, the 310i is likely such a one, the shielding was completely soldered. Then better stay away! Please have some patience. I have Steven and Mike in CC, but allow them to have lots of time. Else we must start some better hacking attempts again later. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tomlohave@gmail.com said: > Hello list, > you are talking about tuner_config = 1 for the hvr 1110, right ? No. We're talking about the switch_addr variable. This variable is not changeable with module parameters. > 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 You only get this output if you enable debugging. Here's what i have (gentoo): anders@tv /etc/modprobe.d $ grep '' saa7134 saa7134_alsa tda827x tda8290 tuner saa7134:options saa7134 disable_ir=1 alsa=1 core_debug=1 i2c_debug=1 saa7134:#options saa7134 alsa=1 saa7134_alsa:options saa7134_alsa debug=1 tda827x:options tda827x debug=1 tda8290:options tda8290 debug=1 tuner:options tuner debug=1 If you adjust your module options similarly, you'll get more info in dmesg. If you're ok with patching kernel source, could you try the patch I sent? > 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 I've never tried my 310i on digital (dvb-t), so I'm afraid I cannot help you there. I use it on analogue cable tv. -Anders -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);