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

[Holger Waechtler <holger@qanu.de>]

Michael Hunold wrote:
> 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.
we don't talk about dvb_i2c but about removing the braindead autoprobing 
infrastructure based on the i2c_client crap and replace it by simple 
direct calls from the card driver.

Basically the frontend ioctl and registration call moves to the card 
driver and this one then directly calls a i2c_transfer() function (no 
matter if a card-specific or the i2c-kernel one) with the card's adap 
pointer.

See 
http://www.linuxtv.org:81/mailinglists/linux-dvb/2004/09-2004/msg00216.html 
for a reference.

> Some frontends need firmware. With kernel i2c, firmware uploading is 
> easily done through firmware_class interface without much hassle.
Thanks to Marko Kothala we have a sysfs/udev interface for every DVB 
subdevice. See dvbdev.c.


> 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.
wrong, each frontend device has an attached sysfs device node.

But it does not matters anyway since we were not talking about the 
dvb_i2c code.

The firmware argument for i2c is just void, we had trivial firmware 
loaders implemented before and if we would rely on i2c for firmware 
loading at all we would have a serious problem for demuxes and MPEG 
decoders: I don't know any which has an i2c interface.


> 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.
But you still rely on a bloated subsystem and don't have any support for 
non-i2c chipsets.

Both approaches are not acceptable in embedded environments.


> I wouldn't care when kernel i2c would be crappy code inside (which I 
> thing it isn't)
:) (it is - really: I've rarely seen anything broken-by-concept like 
this. And I've rarely seen anybody fighting like a pitbull for such a 
stupid concept.)

Remember: i2c is a trivial protocol: two wires only and ususally 
controlled by 3-8 registers on the host controller. Really nothing to 
write tens of thousands of lines of code around it.


> -- that's other people's playground, as long as I can 
> use it.
That's exactly our problem. It does not works reliably in our usecase, 
just grep for i2c and firmware-related problems in your linux-dvb inbox 
before and after the big kernel-i2c move. The number of bug-reports, 
problems discussions how to solve them and proposals for 'workarounds' 
raised by a factor ways larger than ten.

Holger