[linux-dvb] Re: A/V dropouts in dvb-kernel driver

[Oliver Endriss <o.endriss@gmx.de>]

On Samstag, 11. September 2004 16:04, Klaus Schmidinger wrote:
> Klaus Schmidinger wrote:
> > 
> > I've tracked down the problem somewhat more and found that
> > in ves1x93.c, in case 'FE_READ_STATUS', the 'sync' value
> > sometimes has somewhat strange values. Mostly, when it's
> > wrong, one of the lower two bits is 0 (sometimes even both),
> > so this would indicate that there _is_ VITERBI _and_ SYNC,
> > but no SIGNAL or CARRIER (which clearly can't be, because without
> > signal or carrier there can't be anything else).

Strange. I have several rev 1.3 boards running with the latest dvb-kernel
CVS driver. Never had this kind of problem.

> > As a workaround (since the actual problem apparently is inside the
> > VES1893 chip) I have added the following code, which re-reads the
> > 'sync' value in case it doesn't make sense:
> > 
> > --- linux/drivers/media/dvb/frontends/ves1x93.c  2004-08-25 21:27:08.000000000 +0200
> > +++ linux/drivers/media/dvb/frontends/ves1x93.c  2004-09-11 15:03:09.000000000 +0200
> > @@ -452,6 +452,11 @@
> >         {
> >                 fe_status_t *status = arg;
> >                 u8 sync = ves1x93_readreg (i2c, 0x0e);
> > +               int maxtry = 10; // just for safety - let's not get stuck here
> > +               while ((sync & 0x03) != 0x03 && (sync & 0x0c) && maxtry--) {
> > +                       msleep(10);
> > +                       sync = ves1x93_readreg (i2c, 0x0e);
> > +                }
> > 
> >                 *status = 0;
> > 
> > 
> > With this modification the dropouts are gone on my system.
> > Maybe somebody more familiar with the driver internals could comment
> > on this. Does it make sense?
> > Since it is in a hardware specific source file, it shouldn't have
> > any side effects on other hardware.
> > 
> > Maybe it should be even enhanced so that any 'sync' value that doesn't
> > have its '1' bits contiguously set starting at the lowest bit will be
> > considered faulty.
> 
> Ok, I've tried that now, but it didn't work as expected.
> So the above code still appears to be a good fix.

I see no problem adding this code to the driver as it will be executed
only if the frontend has lost lock.
(Or thinks it has lost lock. ;-)

Please add a comment *why* this workaround has been added.
Otherwise, it might be removed again if somebody tries to 'optimize' the
driver. ;-)

Oliver

-- 
--------------------------------------------------------
VDR Remote Plugin available at
http://endriss.escape.bei.t-online.de/vdr/
--------------------------------------------------------