On Thu, 6 Sep 2007, Mauro Carvalho Chehab wrote: > > > The limits are comming from the tda10046 info. I think the correct thing > > > to do here is to not have the tda1004x driver define frequency limits, as > > > it's the tuner that has the limits. > > > > Nak. You must not remove these limits unless you make sure > > that all tuner drivers which might be attached to this demod > > have non-zero frequency limits. So the incorrect limits should be left there? That isn't right either. > IMO, the better would be not to initialize frequency ranges at the > demods (since this is tuner stuff). At least for many demods, the frequency range supported is determined by the tuner. One could have a chip that combines the demod and tuner functions, or a system where the demod is somehow involved in tuning and has some limit. But that is not the case here. > If you are afraid of having a tuner driver with improper values, add a > check can be added, at dvb frontend core, to use the maximum allowed > frequency range, if frequency_max is not defined. The better, however, > is to fix the tuner drivers without frequency limits. This would be easy to do. There is already a function, dvb_frontend_get_frequeny_limits(), that does this. It prints a warning message if neither the demod nor the tuner define a limit. In this case, it returns zero for the max frequency, so any attempt to tune with a driver broken like this will fail. It could easily return ULONG_MAX in this case, so tuning would work but there would still be the warning message. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
