On 8/7/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
> > >> I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They
> > >> have very simple tuning functions only. We should use both values. One part may be more restrictive
> > >> than the other one.
> > >
> > > Most demodulators don't have frequency ranges. They just take whatever the
> > > tuner gives them at a fixed intermediate frequency. It's really the tuner
> > > that has the frequency range.
>
> Agreed.
Though demodulators don't have frequency ranges, they do have
bandwidth's (not DVB-T bandwidth, i mean bandwidth for the loop, ie
loop bandwidth)
Currently none of our in tree drivers do calculate _any_ loop
bandwidth etc, but just blindly set up values based on predefined
values.
But not the same case anymore. We will have divers using these parameters.
> > > I think it would make more sense for the demodulator drivers to fill
> > > fe->ops.info.frequency_min|max using fe->ops.tuner_ops.info.frequency_min|max.
> > > A frontend driver that doesn't use a separate tuner driver (like DST) would
> > > set the fe->ops.info.frequency_min|max directly.
>
> Afaics the demod driver cannot fill fe->ops.info.frequency_min|max using
> fe->ops.tuner_ops.info.frequency_min|max, because the tuner driver will
> be attached _after_ the demod driver (see budget-av.c for example).
>
With new devices i have been doing calculations based on these, In
fact you can see it here:
with a silicon tuner:
267 static int stb6100_set_bandwidth(struct dvb_frontend *fe,
u32 bandwidth)
250 static int stb6100_get_bandwidth(struct dvb_frontend *fe,
u32 *bandwidth)
327 static int stb6100_set_frequency(struct dvb_frontend *fe,
u32 frequency)
296 static int stb6100_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
with a PLL (as of current), i have to use
1237 static int knc1_dvbs2_sd1878_pll_get_bandwidth(struct
dvb_frontend *fe, u32 *bandwidth)
1238 {
1239 /* FIXME ! need to calculate the bandwidth */
1240 *bandwidth = 60000000;
1241
1242 return 0;
1243 }
Now it can be that the tuner and the demodulator have fixed spectral
limits, but also that they can differ.
In the case that which it differs, we will need separate max/min for
both. In such a case it would be better to have them for internal
bound checks at run time.
> > The way I see it, the demod driver that doesn't have a separate tuner driver
> > should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because
> > otherwise those fields will be there anyway, just remaining empty. Those
> > structures are not pointers, and we should always be able to rely on their presence.
> >
> > There is no need for BOTH ops.info.frequency_min|max AND
> > ops.tuner_ops.info.frequency_min|max
>
> The following drivers set ops.tuner_ops.info.frequency_min|max:
> dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100.
>
> All other drivers use ops.info.frequency_min|max.
>
> What about this:
> dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if
> non-zero. Otherwise it would continue to use ops.info.frequency_min|max.
The idea what i was having was that individual demodulators can do
their own CUSTOM tuning algorithm.
111 /*
112 * * ALGO_HW: (Hardware Algorithm)
113 * ----------------------------------------------------------------
114 * Devices that support this algorithm, do everything in hardware
115 * and no software support is needed to handle them.
116 * Requesting these devices to LOCK is the only thing required,
117 * device is supposed to do everything in the hardware
118 *
119 * * ALGO_SW: (Software Algorithm)
120 * ----------------------------------------------------------------
121 * These are dumb devices, that require software to do everything
122 *
123 * * ALGO_CUSTOM: (Customizable Agorithm)
124 * ----------------------------------------------------------------
125 * Devices having this algorithm can be customized to have specific
126 * algorithms in the frontend driver, rather than simply doing a
127 * software zig-zag. In this case the zigzag maybe hardware assisted
128 * or it maybe completely done in hardware. In all cases, usage of
129 * this algorithm, in conjunction with the search and track
130 * callbacks utilizes the driver specific algorithm to be used.
131 *
132 * * ALGO_RECOVERY: (Recovery Algorithm)
133 * ----------------------------------------------------------------
134 * These devices has AUTO recovery capabilities from LOCK failure
135 */
136 enum dvbfe_algo {
137 DVBFE_ALGO_HW = (1 << 0),
138 DVBFE_ALGO_SW = (1 << 1),
139 DVBFE_ALGO_CUSTOM = (1 << 2),
140 DVBFE_ALGO_RECOVERY = (1 << 31)
141 };
It is some more way to go with that, the idea is partly implemented,
not completely.
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
