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

[Holger Waechtler <holger@qanu.de>]

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

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

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

Holger