[linux-dvb] Re: CX88 i2c issue w/ DVB tuners

[Michael Hunold <hunold-ml@web.de>]

Hello,

On 11.09.2004 19:36, Andrew de Quincey wrote:
> > > IMO OSS frontends that are in the official kernel source should use the
> > > official kernel facilities though.
> > why are only closed-source driver writers free to use an elegant and
> > easy-to-use API? why should we stuck to an useless API just because it
> > is "OFFICIAL"?!?
> >
> > my definition of freedom is that everybody is free to choose the
> > simplest and technically most elegant way.
> >
> > All this p.c.-conformity and obedience makes me just sick. Let's end
> > this thread, everybody is free to write as elegant code as he likes.
> OK fair enough, _BUT WE STILL HAVE TO FIX THE PROBLEM_. 
> I've read your proposal, and yeah, it makes sense, is simple, and easily 
> doable. I've submitted my proposals, which I believe are likewise. Neither of 
> them involves any large code changes.
IMHO using kernel i2c is the right thing to do.

Not all i2c adapters have dedicated i2c hardware; bt8xx and cx88 need to 
use bitbanging, which is fully implemented in kernel i2c. With dvb i2c, 
the communication functions must be duplicated.

Some frontends need firmware. With kernel i2c, firmware uploading is 
easily done through firmware_class interface without much hassle. This 
was impossible with dvb i2c, because there was no device file when the 
frontend was not fully registered and with no device file, no firmware 
upload. Kernel i2c handles all this by itself with hotplug and 
firmware_class.

At the end, the dvb drivers and the frontend drivers all call a fairly 
small subset of the i2c subsystem. So far and with the hardware I have 
tested, there have been no problems with timing issues or similar.

When i2c adapters and i2c clients all have a .class entry, it will be 
possible to isolate dvb completely, ie. no more probes from other i2c 
drivers from other subsystems.

I wouldn't care when kernel i2c would be crappy code inside (which I 
thing it isn't) -- that's other people's playground, as long as I can 
use it.

> I don't really mind either way myself (although naturally I lean slightly 
> towards my suggestion). I'm only concerned that _something_ is done.
>
> We need to decide which to do. How? 
I'm sorry that I couldn't follow the current discussion closely, I was 
on a business trip.

As far as I understood, it would be a good thing to keep h/w specific 
code from the frontends, so we no longer need to do ugly i2c adapter 
name parsing, right?

So, when probing for frontends can be done without h/w specific 
informations, wouldn't it be possible to pass frontend specific 
informations (like you proposed) from the dvb adapter (which of course 
knows it's own type and which frontends might be soldered on which 
revision of which card is hardcoded in the driver, too) with the 
FE_REGISTER call?

It would be good if you could recapitulate your suggestions in a new thread.

CU
Michael.