Re: [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Krufky wrote:
> 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.

That's fine if we agree that we have to touch most frontend drivers.

If we choose to do that, we should remove ops.info.frequency_min|max,
i.e. remove 'struct dvb_frontend_info' from 'struct frontend_ops' and
add something like 'struct dvb_demod_info' instead.

We must not modify 'struct dvb_frontend_info' because it is an API data
structure.

Afaics 'frequency_stepsize' can be substituted by 'frequency_step',
but what should we do with 'frequency_tolerance'?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------


_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux