| Message ID | 1242600174.3750.29.camel@pc07.localdom.local (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
hermann pitton a écrit : > Hi, > > Am Sonntag, den 17.05.2009, 15:52 +0200 schrieb tomlohave@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 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. >> > > hmm, strange, since we got a different report too. > > >> This option, as far as i remenber, was not provided by me ... >> > > Thomas, thanks for reply. Looking closer now you are right. > It came not in over you, but Mike picked it up from Benoit. > > hg export 6746 > # HG changeset patch > # User Michael Krufky <mkrufky@linuxtv.org> > # Date 1197003604 18000 > # Node ID f43a48e8bf53bf6a83953e15631fd1f5049a34f0 > # Parent dd0e14aaa659375bfa4356d85ff7bf6308b9baa8 > saa7134-dvb: fix tuning for WinTV HVR-1110 > > From: Benoit Istin <beistin@gmail.com> > > 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 ? 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 ? > Signed-off-by: Benoit Istin <beistin@gmail.com> > Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> > > diff -r dd0e14aaa659 -r f43a48e8bf53 linux/drivers/media/video/saa7134/saa7134-dvb.c > --- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu Dec 06 22:33:08 2007 -0500 > +++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Fri Dec 07 00:00:04 2007 -0500 > @@ -662,6 +662,7 @@ > .if_freq = TDA10046_FREQ_045, > .i2c_gate = 0x4b, > .tuner_address = 0x61, > + .tuner_config = 1, > .request_firmware = philips_tda1004x_request_firmware > }; > > I must have noticed that it is still missing for analog then. > http://linuxtv.org/hg/v4l-dvb/annotate/b227949c41ad/linux/drivers/media/video/saa7134/saa7134-cards.c > > >> anyway with tuner debug=1 and .tuner_config=1 , i have no line with AGC >> or LNA on dmesg >> > > Anders already gave the debug options he does set. > > yes an i have many lines with AGC on my logs >> 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 >> > > sorry for mine too. > better than me :) > On some cards LNA config 1 seems to make a difference and on others not > or is it only because already broken? Maybe we have different card > versions too, but you provided initial support for it and your report of > course still counts. > > Under normal conditions you should expect that such cards are working > without any glitches. If your reception overall is on some limit, it is > somehow normal that one transponder starts to fail at first more > visible, if you have some glitches on the others already. > > The sensitivity is not fully linear over the whole spectrum. I see this > on other tuners too, but the flaw there starts on different frequencies. > > The antenna has of course an important role too and all sorts of RF > amplifiers involved. The other case is also often reported from other > cards already. It might happen, if close to the transmitter, that one > might need an attenuator. > > Maybe try Anders' patch on recent. > > Cheers, > Hermann > > > > Cheers, Thomas -- 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, [snip] > > > > From: Benoit Istin <beistin@gmail.com> > > > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 19.05.2009, 01:04 +0200 schrieb hermann pitton: > Hi, > > [snip] > > > > > > From: Benoit Istin <beistin@gmail.com> > > > > > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 18, 2009 at 10:45 PM, hermann pitton <hermann-pitton@arcor.de> 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
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -r dd0e14aaa659 -r f43a48e8bf53 linux/drivers/media/video/saa7134/saa7134-dvb.c --- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu Dec 06 22:33:08 2007 -0500 +++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Fri Dec 07 00:00:04 2007 -0500 @@ -662,6 +662,7 @@ .if_freq = TDA10046_FREQ_045, .i2c_gate = 0x4b, .tuner_address = 0x61, + .tuner_config = 1, .request_firmware = philips_tda1004x_request_firmware };