[linux-dvb] Re: Tuning problems with the refactored drivers

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Monday 18 Oct 2004 09:00, Holger Waechtler wrote:
> Andrew de Quincey wrote:
> >On Monday 18 Oct 2004 08:41, Holger Waechtler wrote:
> >>Andrew de Quincey wrote:
> >>>>First it tuned pretty badly. (Only 30 channels or so found) but after
> >>>>that I added the mdelay(200)
> >>>>command to line 116 of ves1820.c method ves1820_setup_reg0 and it
> >>>>started to tune channels very well.
> >>>>Now it can even find channels from out national tv channel! So maybe
> >>>> the mdelay-line should also be added in the
> >>>>CVS? (mdelay(50) got removed when you removed that hack)
> >>>>
> >>>>   ves1820_writereg(state, 0x00, reg0 & 0xfe);
> >>>>   ves1820_writereg(state, 0x00, reg0 | 0x01);
> >>>>   mdelay(200);                                                      //
> >>>>this is the new line!
> >>>
> >>>Does setting the dvb_override_tune_delay parameter to 200 have the same
> >>>effect as doing this? Its just that there is a mechanism defined for
> >>>solving exactly this problem which I would prefer to use rather than
> >>>putting an mdelay in the frontend itself.
> >>
> >>If I remember correctly this delay was only required for a few
> >>particular demods, thus the demod driver should be the better place...
> >
> >Hmm - it sounds exactly like the sort of thing I added the
> > get_tune_settings call for - it lets the frontend specify a particular
> > delay to use for a set of parameters. It turns out quite a few frontends
> > need this sort of thing.
>
> the problem is that some demods (and even some more sophisticated PLLs)
> require delays between writing two particular registers (usually in
> order to wait until new clocks, a new loop gain, whatever... settles
> down and the circuitry works stable again), don't know if it makes much
> sense to build an infrastructure for this -- sometimes these delays have
> even to be placed just inbetween consecutive register writes/reads. But
> I have to admit that I don't remember for sure if the ves1820/tda10021
> required it before or after the clearbit write...

Urgh, yeah I see. I think this infrastructure made sense with the 
pre-refactoring code, but maybe it is due for an overhaul now.

> >You're right that it is debatable that that should be done by the frontend
> >itself though. However, get_tune_settings also allows the frontend to
> > specify other things - the max_drift and the frequency step_size - I
> > think I thought the min_delay fitted alongside those well at the time.
>
> Since today only a few frontends need these workarounds it may be an
> option to remove the housekeeping thread from dvb_frontend.c and
> implement this (also the _AUTO software fallbacks) in the demod driver
> with delayed work queues scheduled from the set_parameter call, the
> dvb-core library would only provide some common helper functions and a
> state machine which cycles through the parameter values not which can
> not get automatically detected.

I think I'll leave it as is for the moment - I'd like to get the refactoring 
branch moved into HEAD sometime... but once that is done, lets revisit this.

> just an idea... all new drivers seem to disable the frontend thread
> logic anyways...

Not sure what you mean - do you mean drivers in the OSS CVS (if so I don't see 
how they can)... or is this closed source drivers?