[PATCH] dvb: documentation update

[PATCH] dvb: documentation update

Start of a big DVB update.

The reasons for revamping the DVB frontend architecture:

Just as analog TV cards, DVB cards need some sort of tuner to tune to the
desired frequency of the digital transponder.  Tuning alone doesn't give you a
digital DVB datastream, however, you need a demodulator as well.  The
combination of tuner and demodulator is called frontend in the DVB world.
Tuner and demodulator are both accessed via the serial i2c bus on all DVB
cards out there.  So, technically a frontend consists of two i2c helper
chipsets.

In former times when there was only a handful of different DVB cards, the
frontend was encapsulated in one tin box.  Some people had the idea that there
should be one "frontend driver" instead of dedicated tuner and demodulator
drivers.  A bad idea.

As time went on, different manufacturers used the same tuner and demodulator
combination, but used a different wiring for the tuner or did other technical
changes.  The only possibility to support different cards with one combined
frontend driver was to add hardware dependent tuner code inside the generic
i2c frontend drivers.  Yuck.

So there was a need for communication between the i2c frontend driver and the
hardware depenedent driver, for example to exchange initialization code for
the tuner.  Unfortunately, the i2c infrastructure is one way, from the i2c
client to the i2c adapter using a non-typesafe ioctl() like interface, which
is ugly by itself.  Greg K-H and others refused the idea to add an iotctl()
like interface from the i2c adapter to the i2c client and instead proposed to
use a typesafe interface instead.  We all agreed with that.

The existing i2c infrastructure heavily depends on the probing facility, ie.
clients probe for their existence on i2c busses.  This is dumb for most i2c
busses out there that sit on dedicated hardware.  A DVB card is uniquely
identified with pci or usb subvendor and subsystem ids, so on that particular
bus we exactly *know* which kinds of i2c helper chipsets sit on there.

Up to now this wasn't a problem, because we could fix all conflicts manually
until half a year ago.  By that date, we found two different DVB designs which
used different demodulators that unfortunately use the same i2c address and
which cannot be distinguished by hardware tricks (ie.  different number of
registers, some fixed hw dependent register,...)

Getting a usable DVB card depended on the load order of the modules, because
the i2c core probed the demodulator drivers one after another and the first
one won the race.  Compiling all drivers statically into the kernel resulted
in non-working cards.

Our solution is as follows: we agreed to keep the basic underlying kernel i2c
infrastructure, but we decided not to register our bussed and chipsets to the
kernel i2c "probing" infrastructure.  Instead, we killed the tuner parts of
the frontend drivers and put them into the dedicated hardware drivers (this is
were they technically belong, they are highly hardware dependent) and we
changed the frontend drivers to pure demodulator drivers (which are hardware
independend).  There is now a type-safe functional dependency between the
drivers and the demodulator drivers, the drivers explicitely ask the
demodulator drivers to attach to their i2c bus.  The only negative aspect of
that approach is that for some hardware there are now more dependencies to
demodulator drivers than needed, ie.  a small amount of memory is wasted.

This patch:

- [DVB] cards.txt: added the USB devices to the card-list
- [DVB] README.dibusb: follow changes in dibusb-driver

Signed-off-by: Michael Hunold <hunold@linuxtv.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>