On Fri, Jul 6, 2012 at 1:40 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Em 05-07-2012 14:37, Bert Massop escreveu: >> On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari <crope@xxxxxx> wrote: >>> >>> On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote: >>>> >>>> Implement API support to return AFC frequency shift, as this device >>>> supports it. The only other driver that implements it is tda9887, >>>> and the frequency there is reported in Hz. So, use Hz also for this >>>> tuner. >>> >>> >>> What is AFC and why it is needed? >>> >> >> AFC is short for Automatic Frequency Control, by which a tuner >> automatically fine-tunes the frequency for the best reception, >> compensating for small offsets and oscillator frequency drift. >> This is however done automatically on the tuner, so its configuration >> is read-only. Aside from being a "nice to know" statistic, getting >> hold of the AFC frequency shift does as far as I know not have any >> practical uses related to properly operating the tuner. > > AFC might be useful on a few situations. For example, my CATV operator > still broadcasts some channels in both analog and digital. If you have really have hardware that does AFC "Automatic Frequency Control", then you shouldn't be exposing this value to userspace. It should be held in the driver alone. Technically, hardware that do not have AFC alone should expose this value to userspace, so that applications can control the dumb piece of hardware, that doesn't lock to Fc aka "Center frequency". All decent tuners do lock onto the center of the step size in any given case, these days. When the driver knows the offset, it needs to compute the offset and sum it to the resultant, so that get_frequency() retrieves the recomputed value. Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
