WARNING: This has been a year long debate. I am posting this RFC in an effort
to finally reach some resolution. Please do not respond to this RFC unless you
have something useful to contribute. If the contents of your reply diverges
from the original intention of this RFC, please change the subject line.
Please read the entire email before jumping to any conclusions of the poster's
intent. Please also remember that this is about the code, and not about
personalities - let's try to keep it clean and productive.
---
The Xceive xc3028 ic is a piece of silicon that can tune multiple television and
radio standards, both analog and digital. We would all like to see a driver for
this tuner merged into the kernel, in one form or another, hopefully sooner
rather than later.
Problem: The current video4linux and DVB subsystems each have their own
completely separate implementations of the tuning function. In the current
state, in order for a multi-standard tuner such as the xc3028 to be fully
supported, it must do one of the following:
option #1: Two separate drivers would be written for the device, one for analog
mode, using the v4l2 subsystem's i2c_client interface, the other driver for
digital mode, using the DVB subsystem's dvb_frontend* dvb_attach() method.
downside: There is a strong likelihood of repeated code, which nobody likes. The
idea of two separate drivers for a single device is sickening to most developers,
not to mention the double-work involved in maintaining it.
option #2: A single driver would be written for the device, containing
interfaces to each subsystem's tuning method.
downside: There is potential for creating dependencies on unwanted parts from
each subsystem. For example, this may cause a dvb-only device to depend on the
v4l2 subsystem's tuner module, along with all of its dependencies... likewise,
this could cause an analog-only device to depend on dvb-core. Although these
dependencies are likely to be present anyway in hybrid device drivers, the tuner
driver itself should not be the cause of the cross-dependencies. If care is
taken to prevent this from occurring, this isn't such a bad option.
HOWEVER:
With the current code, using either of the above options, we are still stuck with
two interfaces to drive a single device. This is generally a no-no, but it is
the situation that we are stuck with for now, until things get changed around.
Another device in a similar situation is the tda8275a. Using option #1, the
analog tuning functionality of this ic is found within v4l2's tuner.ko module,
while the DVB tuning functionality is contained in DVB's tda827x.ko . This device
uses entirely different tuning code for analog vs digital modes. The downside of
code repetition does not apply in this specific case, although it would be better
to have this functionality consolidated into a single tuner driver.
---
IMPORTANT NOTE:
The v4l2 subsystem's tuner.ko module uses the i2c_client interface to probe the
i2c bus, in order to autodetect the tuner present. This method is forbidden for
use with the DVB subsystem, as it has been known to cause irreversible damage to
parts used in DVB devices. For this reason, dvb-core can never be used with the
v4l2 subsystem's tuner.ko module.
PERSPECTIVE:
There are two problems that need attention right now:
Problem #1: We need a driver for the xc3028 tuner, that can be properly
merged into the kernel.
Problem #2: We need a new system for handling tuners, preferably something
independent of either v4l and dvb subsystems. This new tuning
system should allow for a single driver to be written, that will
support both analog and digital tuning modes.
I can't speak for everybody, but I think it is quite apparent that both of these
problems exist. However, these two problems are separate issues, and should be
dealt with separately.
Markus Rechberger has written a device driver for the xc3028 tuner, using the
i2c_client interface. This driver does everything he needs it to do in order to
support both analog and digital modes in his em2880 device driver. Unfortunately,
however, his xc3028 driver cannot be used by the DVB subsystem due to its usage
of the i2c_client interface. It should also be noted that his changes to the
v4l2 subsystem's tuner-core break all non-xceive tuners, but Markus is aware of
that problem and intends to fix it.
I have written a separate module, based on Markus' work, that provides dvb-only
functionality of the xc3028 tuner, using the dvb_frontend* dvb_attach() method.
I created this module in an effort to enable support for various dvb-only
devices that would otherwise not be able to attach an xc3028 tuner module, due
to the usage of the i2c_client method. This module is only available in an
external patch, located at [ http://linuxtv.org/~mkrufky/xc-bluebird.patch ]
Usage of Markus' xc3028-tuner module, in conjunction with my xc3028-fe module
satisfies option #1 above. Unfortunately, however, due to the complexities of
the xc3028 ic, ( requires firmware download each time a different standard is used,
and various other reasons ) using both of these modules does result in a large
amount of repeated code and potential bugs. To merge both modules, in my opinion,
would set a horrible president, and is unacceptable.
A better solution for the xc3028 would be something along the lines of option #2,
where we would abstract out the i2c_client and dvb_frontend interfaces, while
having the xc3028 core code independent of either subsystem. The subsystem
interfaces would access the xc3028 driver's internal interface, such that the
single driver can support both interfaces, and we would not have repeated code.
Please keep in mind that the above recommendation is a SHORT TERM SOLUTION, which
will allow us to merge xc3028 support into the kernel with the current system,
while allowing us time to work on the independent tuning system in the meanwhile.
The way I see it, first the xc3028 should be implemented in a method not very
different from the other tuners in the kernel. The option above would allow this
to happen. After merging the xc3028 driver, users will be able to use xc3028-based
devices in conjunction with any other v4l/dvb device, regardless of which tuner is
used, without having to worry about whether or not the drivers will play nice
together -- it will all Just Work (tm).
Meanwhile, at this point, we will have the opportunity for further discussions about
how we can create a separate tuning system independent of the v4l and dvb subsystems.
Markus has made an attempt to abstract out the interfaces in his driver, but it
requires changes to be made to dvb-core, which will conflict with the pending merge
of Manu Abraham's multiproto tree, along with pending work from Steven Toth, which
depends on the multiproto changes.