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:
> 
> >Manu Abraham wrote:
> >  
> >
> >>On 8/6/07, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote:
> >>    
> >>
> >>>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 ???
> >>>      
> >>>
> >>Ideally, what's provided by the demod and not the tuner max/min. The
> >>tuners max/min should be checked by the demod on setting params.
> >>
> >>The upper/lower limits in the demodulator drivers, came from the
> >>concept of a frontend as a whole. Independant bounds do not make sense
> >>(except internally -- It is the demod driver that which sets
> >>parameters for the tuner. The external world doesn't need to know
> >>what's the limit of the tuner, but only of the frontend as a whole).
> >>
> >>Ideally, the demodulator should just demodulate only. There are some
> >>cases, there are some cases which are not.
> >>    
> >>
> >
> >Ok, I'm trying to put all pieces together:
> >There might be cases where demod and tuner have different limits.
> >
> >So FE_GET_INFO and dvb_frontend_check_parameters() should use the
> >'smallest common bandwidth':
> >
> >freq_min = max(fe->ops.info.frequency_min, fe->ops.tuner_ops.info.frequency_min);
> >
> >if (fe->ops.info.frequency_max == 0)
> >	freq_max = fe->ops.tuner_ops.info.frequency_max;
> >else if (fe->ops.tuner_ops.info.frequency_max == 0)
> >	freq_max = fe->ops.info.frequency_max;
> >else
> >	freq_max = min(fe->ops.info.frequency_max, fe->ops.tuner_ops.info.frequency_max);
> >
> >if (freq_min == 0 || freq_max == 0)
> >	printk(KERN_WARNING "frequency limits undefined - please fix the driver\n");
> >
> >Conclusions:
> >- A tuner-only driver must set fe->ops.tuner_ops.info.
> >- Monolithic drivers must set fe->ops.tuner_ops.info or fe->ops.info
> >  (or both).
> >  
> >
> I apologize for my delayed response -- I had to leave town unexpectedly.

No problem.

> The above is OK with me.  As I understand it, we cannot remove 
> fe->ops.info.frequency_max|min because it is part of the userspace API.  
> I wasn't thinking about that fact when I wrote my last email in this 
> thread.  We should keep this in mind, for whenever the time comes that 
> we do have to break API compat.

Basically, the internal data structures don't have to be the same as the
external API data structures. The GET_INFO ioctl might collect its data
from anywhere...

I think we should postpone cleaning-up the frontend data until
multiproto has been merged. It will add more compatibility stuff,
so it might be worth cleaning up these things afterwards.

For now I have committed Hartmut's patch and the fix above.

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