Hi Gerd, (I knew this question would arise;)
Gerd Knorr wrote:
just because if it's (for our purposes) unnecessairy complexity. Most i2c adapter drivers are inconsistent about their probing timeouts, about when to set start/stop/restart conditions etc.What exactly is the point of having two different i2c layers? Why don't you simply use the linux i2c layer for everything?
The Matrox is a good worst-case example, because of it's buggy probing timeouts it takes up to 4 minutes to initialize the DVB driver. Not to easy to explain to users that their Matrox driver which worked flawlessy all the time should cause problems which their new DVB card.
Another example is the bitbanging algorithm implementation, it's setting stop conditions in a way that some frontend demodulators (namely the stv0299) with i2c bridge onchip close it too early. This caused many problems in communication with the PLL behind this bridge.
Just take a look on our 'dvb i2c' driver. It's not more than only about 300 lines of code, only a fraction of the almost 1500 lines of the Linux i2c core. It could get even less when we use the driver/bus infrastructure of the 2.5 kernel.
And it's ways simpler to implement lowlevel drivers, just because we don't need all the features provided by the Linux i2c core. A complete driver a STB with 2 onchip i2c adapters we have internally needs only about 500 lines of code, much less than the common combination of algorithm/lowlevel driver.
This opens up another question: Is there a required module load order? Frist fe's then adapters or the other way round? Or no required order at all?module loading should work in any order (unless symbol dependences force some specific ordering).
modprobe should resolve this. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
