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

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Saturday 11 Sep 2004 20:23, 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.
>
> 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.

Sure, there were two suggestions, one for the i2c clashes, and one for 
configuring the frontends on a per-card basis. Links here:

http://www.linuxtv.org:81/mailinglists/linux-dvb/2004/09-2004/msg00246.html

http://www.linuxtv.org:81/mailinglists/linux-dvb/2004/09-2004/msg00257.html