[linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

Michael Krufky mkrufky at linuxtv.org
Mon Aug 6 23:31:19 CEST 2007

Oliver Endriss wrote:
> Michael Krufky wrote:
>> Trent Piepho wrote:
>>> On Mon, 6 Aug 2007, e9hack wrote:
>>>> Michael Krufky schrieb:
>>>>> Now I'm beginning to have doubts about Oliver's original patch:
>>>>> dvb_frontend: Range check of frequency and symbol rate
>>>>> http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
>>>>> Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead of
>>>>> fe->ops.info.frequency_min|max ???
>>>> 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.
>>> 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).
>> 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.

That's fine with me... except I just don't see why we shouldn't just have the
demod drivers that have the integrated tuning functionality just fill
tuner_ops.info.frequency_max|min anyway.  The point is, the structures will be
present regardless of whether any tuner_ops are actually filled.  This is an
opportunity to remove the frequency_min|max from the demod ops.info structure,
as we all agree that it is inappropriate there anyhow.  If we do this, then we
will have a standard across the board.


More information about the linux-dvb mailing list