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

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

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.

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.