Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Tuning problems with the refactored drivers
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.
Home |
Main Index |
Thread Index