[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>
Showing
Please register or sign in to comment