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

2009-05-18 Thread tomloh...@gmail.com

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 on it, but can you reassure that this
LNA config one is really needed on your device?

  
  


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

2009-05-18 Thread hermann pitton
Hi,

[snip]
 
  From: Benoit Istin beis...@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 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)

2009-05-18 Thread hermann pitton

Am Dienstag, den 19.05.2009, 01:04 +0200 schrieb hermann pitton:
 Hi,
 
 [snip]
  
   From: Benoit Istin beis...@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 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)

2009-05-18 Thread Devin Heitmueller
On Mon, May 18, 2009 at 10:45 PM, hermann pitton
hermann-pit...@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

-- 
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)

2009-05-18 Thread 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.

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)

2009-05-17 Thread 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 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 

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

2009-05-17 Thread Anders Eriksson

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)

2009-05-17 Thread hermann pitton
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 

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

2009-05-16 Thread 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?

/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)

2009-05-16 Thread hermann pitton
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)

2009-05-15 Thread hermann pitton
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: