Hi,
On 21.09.2004 15:49, Holger Waechtler wrote:
Andrews struct bus_i2c with the read and write functions is just the
same as i2c_transfer(). The current frontends are i2c devices,
period. So using your words it's bloat and unnecessary because the
code is already there. (That the existing code is stupid in your eyes
is another question).
?!?
You stated more than once that kernel i2c doesn't work in your eyes.
As I already explained in another mail, introducing a functional
dependency between the frontend drivers and the dvb adapters is a
no-no. The dvb-ttpci driver would pull in nearly all existing
frontend drivers with no benefit.
nope. Each special card driver handles exactly one PCI
chipset/frontend combination without and if(card_type==XXX) and
switch/case statements. Please read the proposed code and the
surrounding mails.
MAKE_EXTENSION_PCI(fs_1_5, 0x110a, 0xffff),
MAKE_EXTENSION_PCI(fs_1_5, 0x110a, 0x0000),
MAKE_EXTENSION_PCI(fs_1_3, 0x13c2, 0x0000),
MAKE_EXTENSION_PCI(unkwn0, 0x13c2, 0x1002),
MAKE_EXTENSION_PCI(tt_1_6, 0x13c2, 0x0001),
MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0002),
MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0003),
MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0004),
MAKE_EXTENSION_PCI(tt_1_6, 0x13c2, 0x0006),
MAKE_EXTENSION_PCI(tt_t, 0x13c2, 0x0008),
MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x1102),
MAKE_EXTENSION_PCI(unkwn1, 0xffc2, 0x0000),
MAKE_EXTENSION_PCI(unkwn2, 0x00a1, 0x00a1),
MAKE_EXTENSION_PCI(nexus, 0x00a1, 0xa1a0),
MAKE_EXTENSION_PCI(dvboc11,0x13c2, 0x000a),
There are currently 15 different cards handled by dvb-ttpci. If you
split that up and distinguish by different frontends as well you'll
easily get 20 different drivers.
Hmm, pci hotplugging will take care that the necessary driver will be
loaded. If there are more drivers because of different frontends, then
probing will do the rest.
This would involve big code restructions, so if this is really desired,
then it should probably be done in V4.
I'm currently just trying to get V3 in 2.6 as good-working as possible,
without wasting too much time.
If I remember correctly they all followed the easy rule: keep it
simple, simplify existing code and throw away bloated code. Break API
boundaries where they don't make sense and introduce new ones where
they stabilize your system. Seperate the one-code-for-all-module into
smaller ones that each suit a particular well-defined and easily
testable task.
The V3 API has undeniable design problems. I have a very nice living
besides hacking Linux kernel, so my motivation is limited in this field
regarding V3. 8-)