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