Michael Krufky wrote: > Oliver Endriss wrote: > > >Manu Abraham wrote: > > > > > >>On 8/6/07, Michael Krufky <[EMAIL PROTECTED]> 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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
