[linux-dvb] or51132 QAM initialization problem

Michael Krufky mkrufky at m1k.net
Thu Aug 25 18:47:31 CEST 2005


Does Mac's patch below fix your problem?  Please let us know, as we will 
not commit this to cvs without knowing that it fixes the problem, first.

Your feedback is much appreciated... please help to make this better for 
everyone by reporting your experience with this patch.

-MiKE Krufky

Mac Michaels wrote:

>The fix is probably the same as I used on lgdt330x. There is 
>an optimization that keeps track of the frequency tuned by  
>the digital decoder. The digital driver does not set the 
>frequency if it has not changed since it was tuned. The 
>analog tuner driver knows nothing about the frequency saved 
>by the digital driver. When the frequency is set using the 
>video4linux code with tvtime, the hardware get changed but 
>the digital driver's state does not get updated. Switch 
>back to the same digital channel and the driver finds no 
>change in frequency so the tuner is not reset to the 
>digital frequency. The work around is to remove the check 
>and always set the tuner to the specified frequency.
>Attached is an untested patch:
>Signed-off-by Mac Michaels <wmichaels1 at earthlink.net>
>On Sunday 21 August 2005 10:09 am, Michael Krufky wrote:
>>Ilia Mirkin wrote:
>>>If I have the QAM firmware loaded, and then go to NTSC,
>>>locking onto a QAM station again does not work.
>>>However, if I load up a VSB station (thus loading the
>>>VSB firmware), then the lock is acquired. I can then go
>>>back and reload the QAM firmware and it locks fine.
>>>The sequence of events is as follows, in case the
>>>description above was unclear:
>>>azap -r qam_chan (locks)
>>>tvtime (viewing works)
>>>azap -r qam_chan (does not lock)
>>>azap -r vsb_chan (locks)
>>>azap -r qam_chan (locks)
>>I had the same exact problem using the original lgdt3302
>>driver (based on or51132) with DViCO FusionHDTV3 Gold-T. 
>>It is more likely that the problem is within the or51132
>>frontend driver, rather than in cx88-dvb, as this was the
>>case with lgdt3302. Maybe the problem in lgdt3302 came
>>from the original or51132 design?  Any ideas Mac?  Maybe
>>the same type of fix can be applied?  I have cc'd Kirk
>>Lapray, or51132 author.
>>Index: linux/drivers/media/dvb/frontends/or51132.c
>>RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/frontends/or51132.c,v
>>retrieving revision 1.5
>>diff -u -b -B -r1.5 or51132.c
>>--- linux/drivers/media/dvb/frontends/or51132.c	5 May 2005 20:39:05 -0000	1.5
>>+++ linux/drivers/media/dvb/frontends/or51132.c	22 Aug 2005 03:14:34 -0000
>>@@ -370,8 +370,6 @@
>> 		or51132_setmode(fe);
>> 	}
>>-	/* Change only if we are actually changing the channel */
>>-	if (state->current_frequency != param->frequency) {
>> 		dvb_pll_configure(state->config->pll_desc, buf,
>> 				  param->frequency, 0);
>> 		dprintk("set_parameters tuner bytes: 0x%02x 0x%02x "
>>@@ -385,7 +383,6 @@
>> 		/* Update current frequency */
>> 		state->current_frequency = param->frequency;
>>-	}
>> 	return 0;
>> }

More information about the linux-dvb mailing list