[linux-dvb] Re: NEWSTRUCT questions

[Holger Waechtler <holger@convergence.de>]

Gerd Knorr wrote:
>>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?

(no, I took the easier way;)

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.


>>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?

I have a stripped down and fixed bitbanging driver here, I needed to 
write one for PlainDigital's PCMCIA DVB card. Works fine.


>>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.

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.

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 listar@linuxtv.org with "unsubscribe linux-dvb" as subject.