[linux-dvb] Re: NEWSTRUCT questions

[Gerd Knorr <kraxel@bytesex.org>]

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

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

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

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

> >module loading should work in any order (unless symbol dependences
> >force some specific ordering).
> 
> modprobe should resolve this.

Yes, but if there are no symbol dependences the load order shouldn't
make a difference.  Example: bttv.o and tuner.o can be loaded in any
order as they are linked indirectly through the i2c layer only.  Both
load orders (bttv first and tuner first) work.

  Gerd

-- 
You can't please everybody.  And usually if you _try_ to please
everybody, the end result is one big mess.
				-- Linus Torvalds, 2002-04-20


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.