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. Regards, Mike _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
