Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Am Dienstag, den 19.05.2009, 05:28 +0200 schrieb hermann pitton: > Hi Devin, > > [snip] > > > > That said, Kernel Labs is about as responsible for fixing the problem > > as you are. ;-) > > tell me more stories. > > But OK, heads up then I hope. Devin, just one more note that you don't get me wrong. I try to help for what I still can remember. The Pinnacle 310i design was against the Philips reference design and you can find comments from Hartmut about that. So, since this still causes problems through the driver iterations, don't tell me that I'm equally responsible for fixing that. Without any NDAs and any such device. Got me? Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi Devin, [snip] > > That said, Kernel Labs is about as responsible for fixing the problem > as you are. ;-) tell me more stories. But OK, heads up then I hope. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
On Mon, May 18, 2009 at 10:45 PM, hermann pitton wrote: > Guys, > > please. > > It looks like this still can go on for some while. > > I don't have the time and have zero income from all of this. > > Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do > confirm that this bug is assigned to them? (PCTV and Hauppauge) > > Or do you prefer to have it further drifting over the lists and call > Hartmut and me for it? > > Cheers, > Hermann Hello Hermann, I believe it makes sense for me to clarify this point: Kernel Labs is not affiliated with Hauppauge or PCTV in any way. We have not received any money from either company for Linux support for their products. One of Kernel Lab's long-term goals is indeed to find a way to provide some form of commercial support for devices such as this. It is probably fair to say that the three of us tend to focus on products by those vendors because of easy access to sample hardware, not because of any commercial arrangement. That said, Kernel Labs is about as responsible for fixing the problem as you are. ;-) Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Am Dienstag, den 19.05.2009, 01:04 +0200 schrieb hermann pitton: > Hi, > > [snip] > > > > > > From: Benoit Istin > > > > > > There are several months my hvr1110 stop working. > > > This is very simple to fix, for my card revision at least, by setting a > > > missing field to the hauppauge_hvr_1110_config. > > > > > Hello > > > > I see, > > what i don't remember is, when searching for good parameters for this > > card (1110), AGC and Co was not necessary... > > > > correct me if i'm wrong : > > > > patch from Anders impacts cards with .tuner_config=1 > > what i can do : > > > > step 1 : > > see if we really need .tuner_config = 1 on hvr_1110_config otherwise > > change to .tuner_config = 0 > > > > step 2 : > > if needed, apply the patch from Anders and look if it's better or not > > both on analogic and dvb > > > > step 3 : report this results > > > > > > others ideas ? > > Seems I can't find any details about Benoit's eventually different card > version in the mail archives. > > If it turns out we have revisions with LNA and without, we might try to > provide a separate entry for the LNA version. Usually on Hauppauge cards > we find means doing so. > > > PS : i need times because my multimedia box is on production and i > > prefer test this on another pc, you know : why change when all is good ? > > Thanks for your time and no need for hurry. > > If you keep your old media modules folder, you just can put it back in > place later again and "depmod -a" and you are done. Do "make rmmod" and > delete the new media modules folder previously and you should be 100% > back. > ( Guys, please. It looks like this still can go on for some while. I don't have the time and have zero income from all of this. Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do confirm that this bug is assigned to them? (PCTV and Hauppauge) Or do you prefer to have it further drifting over the lists and call Hartmut and me for it? Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi, [snip] > > > > From: Benoit Istin > > > > There are several months my hvr1110 stop working. > > This is very simple to fix, for my card revision at least, by setting a > > missing field to the hauppauge_hvr_1110_config. > > > Hello > > I see, > what i don't remember is, when searching for good parameters for this > card (1110), AGC and Co was not necessary... > > correct me if i'm wrong : > > patch from Anders impacts cards with .tuner_config=1 > what i can do : > > step 1 : > see if we really need .tuner_config = 1 on hvr_1110_config otherwise > change to .tuner_config = 0 > > step 2 : > if needed, apply the patch from Anders and look if it's better or not > both on analogic and dvb > > step 3 : report this results > > > others ideas ? Seems I can't find any details about Benoit's eventually different card version in the mail archives. If it turns out we have revisions with LNA and without, we might try to provide a separate entry for the LNA version. Usually on Hauppauge cards we find means doing so. > PS : i need times because my multimedia box is on production and i > prefer test this on another pc, you know : why change when all is good ? Thanks for your time and no need for hurry. If you keep your old media modules folder, you just can put it back in place later again and "depmod -a" and you are done. Do "make rmmod" and delete the new media modules folder previously and you should be 100% back. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
hermann pitton a écrit :
Hi,
Am Sonntag, den 17.05.2009, 15:52 +0200 schrieb tomloh...@gmail.com:
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 o
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi,
Am Sonntag, den 17.05.2009, 15:52 +0200 schrieb tomloh...@gmail.com:
> 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
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
tomloh...@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): and...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi, Am Samstag, den 16.05.2009, 16:02 +0200 schrieb Anders Eriksson: > hermann-pit...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
hermann-pit...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
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
Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134/2.6.26 regression, noisy output
An update:
>hermann-pit...@arcor.de said:
>> hmm, the idea eventually was, to download these two snapshots, or make the
>> last few changes manually on the first and try on 2.6.25.
>>
>> Then we might know, if the problem is already visible within Hartmut's latest
>> fix attempts or even more and other stuff is involved.
I wrote:
>I see. I'll dig myself into hand applying those patches. It seems quite some
>stuff changed between 2.6.25 and what those patches assumes. Let's see what I
>dig up.
Dragging the following patch along,
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 6fde042..938bdf5 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5249,7 +5249,7 @@ static int saa7134_tda8290_callback(struct saa7134_dev
*dev,
int saa7134_tuner_callback(void *priv, int command, int arg)
{
struct i2c_algo_bit_data *i2c_algo = priv;
- struct saa7134_dev *dev = i2c_algo->data;
+ struct saa7134_dev *dev = priv;
switch (dev->tuner_type) {
case TUNER_PHILIPS_TDA8290:
.. I could actually bisect my way to the offending commit. And of course, it's
the one you suspected: git 7bff4b4d3ad2b9ff42b4087f409076035af1d165.
I'm right now applying that commit piece by piece, to isolate the offending
change (Some changes are just rearrangements, others may change the way hw is
touched). I'll keep you posted.
-Anders
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134/2.6.26 regression, noisy output
hermann-pit...@arcor.de said: > hmm, the idea eventually was, to download these two snapshots, or make the > last few changes manually on the first and try on 2.6.25. > > Then we might know, if the problem is already visible within Hartmut's latest > fix attempts or even more and other stuff is involved. I see. I'll dig myself into hand applying those patches. It seems quite some stuff changed between 2.6.25 and what those patches assumes. Let's see what I dig up. BR, -Anders -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134/2.6.26 regression, noisy output
Hi,
Am Montag, den 04.05.2009, 21:52 +0200 schrieb Anders Eriksson:
>
> Hi hermann,
>
> hermann-pit...@arcor.de said:
> > There is no way to detect which sort of such a LNA circuitry is employed.
> > Just try and error and pray. Also no further documentation for the changing
> > code itself and only some comments by Hartmut on the lists.
> >
> > In case config = 1 gpio0 of the tda827x is involved, on others a gpio pin of
> > the saa7134 and some registers.
> >
> > It was already broken when tuner callback stuff for XCeive tuners was
> > introduced and firmware loading for those.
> >
> > Guess the problem is to get the gpio change to the tda827x through.
> >
> > Hartmut came up with this fix that time you get with "hg export 7393".
> > (attached)
> >
> > I did not even have any such a LNA device at this time, but might be
> > interesting if this snapshot really works for you. Still have only one type
> > 2
> > device now.
> >
> > If I look through hg log > hg.log, the only somehow related later change by
> > Hartmut was this one. (link points to Hartmut's repo)
> >
> > http://linuxtv.org/hg/~hhackmann/v4l-dvb/rev/779169257208
> >
> > And last entry is that compile warning fix on top for int mask not removed
> > at
> > once. Should all be only saa7134 gpio related.
>
> I had a look at the diff you attached, and it made me a bit confuse. Most
> (all?) of it seem to be already applied in later kernels (>2.6.26), and they
> all fail on me.
hmm, the idea eventually was, to download these two snapshots, or make
the last few changes manually on the first and try on 2.6.25.
Then we might know, if the problem is already visible within Hartmut's
latest fix attempts or even more and other stuff is involved.
"make rmmod" and save the original modules media folder.
Then "make" and "make install" and you get a new one.
The same way you can restore your old working media folder by putting it
back in place and "depmod -a".
You can click on top of the site on bz2 or gz to get such a snapshot.
http://linuxtv.org/hg/v4l-dvb/rev/49ba58715fe0
> however, looking through the diff, I sumbled on the dprink's and I started to
> enable them on all modules I thought relevant. Here's a diff between the last
> -good and first-bad commit. The salient differences I can see is the "AGC2
> gain"
> and the "setting GPIO22 to vsync 0". I have no clue what they mean, but my
> next step is to see if I can kill these differences.
>
> Is thee anything else in there which you find note worthy?
-saa7133[0]/core: setting GPIO22 to vsync 0
This saa7133 GPIO22 setting is related to LNA configuration.
The code has changed, doesn't print the above anymore and became a tuner
callback. Maybe related.
> Rgds,
> /Anders
> PS What is the tda829x doing? I see some differences there too.
It is the analog demodulator within the saa7131e, controls the i2c gate
to the tda8275a silicon tuner and gpio0 on it is involved in type 1 LNA
control, according the comments. (details under NDA i don't have)
>
> $ diff -u dmesg_2.6.25-03{6,7}*
> --- dmesg_2.6.25-03622-g1fe873692009-05-04 21:32:37.0 +0200
> +++ dmesg_2.6.25-03774-g99e09ea 2009-05-04 21:37:06.0 +0200
> @@ -42,14 +42,13 @@
> tda829x 1-004b: tda827xa config is 0x01
> tda827x: setting tda827x to system xx
> tda827x: setting LNA to high gain
> -saa7133[0]/core: setting GPIO22 to vsync 0
> -tda827x: AGC2 gain is: 3
> +tda827x: AGC2 gain is: 10
> tda829x 1-004b: tda8290 not locked, no signal?
> tda829x 1-004b: tda8290 not locked, no signal?
> tda829x 1-004b: tda8290 not locked, no signal?
> -tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 0, lock: 0
> -tda829x 1-004b: adjust gain, step 2. Agc: 131, lock: 0
> -tda829x 1-004b: adjust gain, step 3. Agc: 44
> +tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 1, lock: 0
> +tda829x 1-004b: adjust gain, step 2. Agc: 255, lock: 0
> +tda829x 1-004b: adjust gain, step 3. Agc: 235
> tuner' 1-004b: saa7133[0] tuner' I2C addr 0x96 with type 54 used for 0x0e
> saa7133[0]/core: hwinit2
> tuner' 1-004b: switching to v4l2
> @@ -58,8 +57,7 @@
> tda829x 1-004b: tda827xa config is 0x01
> tda827x: setting tda827x to system B
> tda827x: setting LNA to high gain
> -saa7133[0]/core: setting GPIO22 to vsync 0
> -tda827x: AGC2 gain is: 3
> +tda827x: AGC2 gain is: 10
> tda829x 1-004b: tda8290 not locked, no signal?
[snip]
Cheers,
Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134/2.6.26 regression, noisy output
Hi hermann,
hermann-pit...@arcor.de said:
> There is no way to detect which sort of such a LNA circuitry is employed.
> Just try and error and pray. Also no further documentation for the changing
> code itself and only some comments by Hartmut on the lists.
>
> In case config = 1 gpio0 of the tda827x is involved, on others a gpio pin of
> the saa7134 and some registers.
>
> It was already broken when tuner callback stuff for XCeive tuners was
> introduced and firmware loading for those.
>
> Guess the problem is to get the gpio change to the tda827x through.
>
> Hartmut came up with this fix that time you get with "hg export 7393".
> (attached)
>
> I did not even have any such a LNA device at this time, but might be
> interesting if this snapshot really works for you. Still have only one type 2
> device now.
>
> If I look through hg log > hg.log, the only somehow related later change by
> Hartmut was this one. (link points to Hartmut's repo)
>
> http://linuxtv.org/hg/~hhackmann/v4l-dvb/rev/779169257208
>
> And last entry is that compile warning fix on top for int mask not removed at
> once. Should all be only saa7134 gpio related.
I had a look at the diff you attached, and it made me a bit confuse. Most
(all?) of it seem to be already applied in later kernels (>2.6.26), and they
all fail on me.
however, looking through the diff, I sumbled on the dprink's and I started to
enable them on all modules I thought relevant. Here's a diff between the last
-good and first-bad commit. The salient differences I can see is the "AGC2 gain"
and the "setting GPIO22 to vsync 0". I have no clue what they mean, but my
next step is to see if I can kill these differences.
Is thee anything else in there which you find note worthy?
Rgds,
/Anders
PS What is the tda829x doing? I see some differences there too.
$ diff -u dmesg_2.6.25-03{6,7}*
--- dmesg_2.6.25-03622-g1fe873692009-05-04 21:32:37.0 +0200
+++ dmesg_2.6.25-03774-g99e09ea 2009-05-04 21:37:06.0 +0200
@@ -42,14 +42,13 @@
tda829x 1-004b: tda827xa config is 0x01
tda827x: setting tda827x to system xx
tda827x: setting LNA to high gain
-saa7133[0]/core: setting GPIO22 to vsync 0
-tda827x: AGC2 gain is: 3
+tda827x: AGC2 gain is: 10
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
-tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 0, lock: 0
-tda829x 1-004b: adjust gain, step 2. Agc: 131, lock: 0
-tda829x 1-004b: adjust gain, step 3. Agc: 44
+tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 1, lock: 0
+tda829x 1-004b: adjust gain, step 2. Agc: 255, lock: 0
+tda829x 1-004b: adjust gain, step 3. Agc: 235
tuner' 1-004b: saa7133[0] tuner' I2C addr 0x96 with type 54 used for 0x0e
saa7133[0]/core: hwinit2
tuner' 1-004b: switching to v4l2
@@ -58,8 +57,7 @@
tda829x 1-004b: tda827xa config is 0x01
tda827x: setting tda827x to system B
tda827x: setting LNA to high gain
-saa7133[0]/core: setting GPIO22 to vsync 0
-tda827x: AGC2 gain is: 3
+tda827x: AGC2 gain is: 10
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
@@ -68,14 +66,13 @@
tda829x 1-004b: tda827xa config is 0x01
tda827x: setting tda827x to system B
tda827x: setting LNA to high gain
-saa7133[0]/core: setting GPIO22 to vsync 0
-tda827x: AGC2 gain is: 3
+tda827x: AGC2 gain is: 10
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: adjust gain, step 1. Agc: 136, ADC stat: 40, lock: 0
-tda829x 1-004b: adjust gain, step 2. Agc: 0, lock: 0
-tda829x 1-004b: adjust gain, step 3. Agc: 248
+tda829x 1-004b: adjust gain, step 2. Agc: 126, lock: 0
+tda829x 1-004b: adjust gain, step 3. Agc: 35
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
saa7133[0]: registered device radio0
@@ -90,15 +87,19 @@
DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
tda827x: setting tda827x to system B
tda827x: setting LNA to high gain
-saa7133[0]/core: setting GPIO22 to vsync 0
tda1004x: setting up plls for 48MHz sampling clock
-tda827x: AGC2 gain is: 3
+tda827x: AGC2 gain is: 10
+tda1004x: found firmware revision 20 -- ok
+tda827x: tda827xa tuner found
+tda827x: tda827xa_sleep:
+saa7134 ALSA driver for DMA sound loaded
+saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 21 registered as card -1
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: tda8290 not locked, no signal?
tda829x 1-004b: adjust gain, step 1. Agc: 0, ADC stat: 1, lock: 0
-tda829x 1-004b: adjust gain, step 2. Agc: 255, lock: 0
-tda829x 1-004b: adjust gain, step 3. Agc: 202
+tda829x 1-004b: adjust gain, step 2. Agc: 128, lock: 0
+tda829x 1-004b: adjust gain, step 3. Agc: 128
tuner' 1-004b: Cmd TUNER_SET_STANDBY accepted for analog TV
tuner' 1
Re: saa7134/2.6.26 regression, noisy output
Hi Anders,
Am Sonntag, den 03.05.2009, 09:56 +0200 schrieb Anders Eriksson:
> Hi all,
>
> I've got a
> saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i
> [card=101,autodetected]
>
> In all kernels later than 2.6.25 there is a significant layer of noise added
> to
> the video output. I've tried to bisect the problem, and it was introduced
> somewhere between 1fe8736955515f5075bef05c366b2d145d29cd44 (good) and
> 99e09eac25f752b25f65392da7bd747b77040fea (bad). Unfortunately, all commits
> between those two either don't compile, or oops in the v4l subsystem.
>
> I've tried the latest 30-rc and the problem is still there. Any idea how to
> proceed for here? I can provide screenshots on request.
>
> Here's the relevant chunk from demsg on 2.6.25:
> Linux video capture interface: v2.00
> saa7130/34: v4l2 driver version 0.2.14 loaded
> saa7133[0]: found at :03:06.0, rev: 209, irq: 21, latency: 64, mmio:
> 0xfdeff000
> saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i
> [card=101,autodetected]
> saa7133[0]: board init: gpio is 600c000
> saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
> saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 36 5b e2 ff ff
> saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2
> saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 04 50 de 7d
> saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 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
> tuner' 1-004b: chip found @ 0x96 (saa7133[0])
> tda8290 1-004b: setting tuner address to 61
> tda8290 1-004b: type set to tda8290+75a
> saa7133[0]: registered device video0 [v4l2]
> saa7133[0]: registered device vbi0
> saa7133[0]: registered device radio0
> saa7134 ALSA driver for DMA sound loaded
> saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 21 registered as card -1
> DVB: registering new adapter (saa7133[0])
> DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
> tda1004x: setting up plls for 48MHz sampling clock
> tda1004x: found firmware revision 20 -- ok
>
can confirm that such a regression on this card was already reported.
Hartmut, who added also support for this board, mentioned that it might
be caused be a failing configuration of the extra LowNoiseAmplifier it
has.
We know three types of LNAs so far which have different requirements to
be configured. Your card uses type one, for the others are no problems
reported and I saw Mike added recently some new cards with type three.
However, there is just one more card sharing that type_one configuration
with yours, the first version of the HVR-1110, and still no reports from
that one in that direction.
You should try to set the LNA config to type 0, no LNA, also on 2.6.25 I
guess, to see if it might be related.
In saa7134-cards.c for analog it is tuner_config.
[SAA7134_BOARD_PINNACLE_PCTV_310i] = {
.name = "Pinnacle PCTV 310i",
.audio_clock= 0x00187de7,
.tuner_type = TUNER_PHILIPS_TDA8290,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.tuner_config = 1,
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x00020,
.inputs = {{
In current saa7134-dvb.c you change tda827x_cfg_1 to tda827x_cfg_0.
case SAA7134_BOARD_PINNACLE_PCTV_310i:
if (configure_tda827x_fe(dev, &pinnacle_pctv_310i_config,
&tda827x_cfg_1) < 0)
goto dettach_frontend;
break;
On older kernels it is also tuner_config there within
pinnacle_pctv_310i_config.
Unfortunately Gerd is not active anymore since several years on v4l-dvb
and we should not molest him with later added stuff.
Cheers,
Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7134/2.6.26 regression, noisy output
Hi all, I've got a saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] In all kernels later than 2.6.25 there is a significant layer of noise added to the video output. I've tried to bisect the problem, and it was introduced somewhere between 1fe8736955515f5075bef05c366b2d145d29cd44 (good) and 99e09eac25f752b25f65392da7bd747b77040fea (bad). Unfortunately, all commits between those two either don't compile, or oops in the v4l subsystem. I've tried the latest 30-rc and the problem is still there. Any idea how to proceed for here? I can provide screenshots on request. Here's the relevant chunk from demsg on 2.6.25: Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded saa7133[0]: found at :03:06.0, rev: 209, irq: 21, latency: 64, mmio: 0xfdeff000 saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[0]: board init: gpio is 600c000 saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 36 5b e2 ff ff saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 04 50 de 7d saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 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 tuner' 1-004b: chip found @ 0x96 (saa7133[0]) tda8290 1-004b: setting tuner address to 61 tda8290 1-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7134 ALSA driver for DMA sound loaded saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 21 registered as card -1 DVB: registering new adapter (saa7133[0]) DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision 20 -- ok All help appreciated, -Anders -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
