Gerd Knorr wrote:
(no, I took the easier way;)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.
That should be fixable without major trouble. Tried that?
I have no idea if my 'fix' might cause problems with other hardware which expects the placement of start/stop conditions just like they are. That's why we rewrote this stuff on our own: we have a specialized solution that does exactly what we want. Without influences on other drivers.
I have a stripped down and fixed bitbanging driver here, I needed to write one for PlainDigital's PCMCIA DVB card. Works fine.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.
Tried to fix the bit-bang driver? Or to write a replacement just for the bit-bang bus driver and still use the rest of the kernels i2c infrastructure?
there is not much code to share, take a look into dvb_i2c.[hc]. It's only device/bus handling, in the 2.5 implementation we could use the driverfs stuff for this.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.
i2c-old.c used to be pretty small to and did a pretty well job for bit-bang i2c busses (bttv was the main user of that one). These days I'm happy we have another abstraction layer. It allows the bttv (bit-bang) and saa7134 (other algorithm) drivers share i2c modules, tuner.c for example. Having two i2c implementations in the kernel ist evil because it makes code sharing harder.
Lowlevel i2c drivers can simply register to both infrastructures, look in the wrapper examples in Ralph's mail.
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.
bogomips kraxel ~/kernel/saa7134-0.2.0# wc -l saa7134-i2c.c 451 saa7134-i2c.c
And this isn't just the i2c algorithm code, this includes some funtions
to read & dump the eeprom, do a quick i2c scan etc.
(our driver includes this code, too;) Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
