[linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

Michael Krufky mkrufky at linuxtv.org
Sun Aug 19 00:25:40 CEST 2007

For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules.

This allows for a single module to be used by both the v4l2 tuner interface via the tuner.ko i2c_client driver, and directly by the dvb subsystem's tuning system.

This refactoring process has zero impact to the way that v4l and dvb functions.

I have completed phase one of the refactoring process, and now it is ready for testing and review.


A brief description of the individual changesets follows:

- tuner: kill i2c_client interface to tuner sub-drivers

This changeset removes the i2c_client interface between tuner.ko and the tuner sub-drivers.

The i2c_client interface to tuner.ko, itself, remains the same as it has been -- this is only an internal change that affects the interaction between tuner.ko and the hardware-specific code.

Some helper functions and macros were added in this changeset, in order to ease the conversion process, without causing headaches or breakage. (see tuner-i2c.c)  We can remove these extra structs and helper functions after the refactoring process is complete.

- hybrid tuner refactoring core changes, phase 1

This changeset contains the more interesting work, where tuner-core is altered to support attachment of dvb_frontend style tuner modules.  An additional method "set_analog_params" was added to struct dvb_tuner_ops, so as to avoid altering the DVB subsystem userspace API headers.  This change does not create any dependency of the DVB subsystem on V4L, nor does it create any dependency of the V4L subsystem on DVB.

- tda8290: convert from tuner sub-driver into dvb_frontend module
- mt20xx: convert from tuner sub-driver into dvb_frontend module
- tea5761: convert from tuner sub-driver into dvb_frontend module
- tea5767: convert from tuner sub-driver into dvb_frontend module
- tuner-simple: convert from tuner sub-driver into dvb_frontend module

These changesets handle the conversions of the individual tuner sub-drivers into dvb_frontend style tuner modules.

- tuner: alter Makefile to produce separate modules

This changeset makes the changes to the build system, required for building the tuner sub-drivers as separate modules, and the ability to deselect undesired tuner sub-drivers via Kconfig.


What comes next?

After phase 1 of hybrid tuner refactoring is merged into the master branch, there is no change to the behavior of the drivers, apart from the fact that users will now have the ability to deselect undesired tuner sub-drivers via Kconfig.

I have the following changes planned for hybrid tuner refactoring, phases 2, 3 and 4:

- analog if demodulator refactoring

In this step, an internal api for analog IF demods will be created, allowing us to refactor the tda9887 module, and also to handle tda8290 separately from the tda8275 and tda8275a tuners.

- tda8290 refactoring

In addition to the analog if demodulator refactoring, duplicated code for the tda8275 and tda8275a tuners between tda8290.ko and tda827x.ko shall be consolidated.  In addition, support for the tda8295 and tda18271 devices will be added.

- tuner-simple refactoring

Tuner-simple will be cleaned up to take on more of an object-oriented approach, and duplicated code for certain tuners present in both tuner-simple and dvb-pll shall be consolidated.

- miscellaneous work and additional cleanups

mt20xx shall be cleaned up to properly handle tuning requests from the DVB subsystem, rather that going through tuner.ko -- this is a very small change, but I decided to wait on this until after phase 1 is merged into master.

Support for new hybrid tuner hardware will now be _much_ easier to develop and add into the v4l-dvb codebase.


I'd like to thank all of the people that have looked this over thus far, whom have given suggestions on how I can make this better and easier to review.

If there are any other questions, comments or concerns, I would love to hear them.  Please don't be shy -- feel free to let me know if you like or dislike this approach.  I'd like to have this merged as soon as possible, so that I may continue to work on the items mentioned about in the "What comes next?" section.

Now, it's time to go out and party!  I will be able to respond to any comments tomorrow afternoon.


Michael Krufky

More information about the linux-dvb mailing list