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

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

On Sunday 12 Sep 2004 13:00, Holger Waechtler wrote:
> Ralph Metzler wrote:
> > Holger Waechtler writes:
> >  > > 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.
> >
> > This does not have anything to do with the problem at hand.
> > I see nowhere in the description of your API how you pass
> > card specific information more elegantly. You will also either have to
> > write extra code in the card driver and only use lower level functions
> > through your API or you will have to somehow pass information to the
> > frontend driver which tells it what to do in which case or a
> > combiantion of both.
> > The real question is to decide how to do this exactly. What I2C API is
> > used does not really matter that much.
> >
> > I also wrote before that the only reason to use the kernel I2C API is to
> > use existing code for other non-DVB devices and to prevent having
> > duplicate code or additional locking in this case. If somebody does
> > not need existing I2C drivers or rewrites those he needs with
> > this new API, that's fine.
>
> yes. I would avoid touching any working code -- the latest changes did
> enough harm. It's time to get things as stable again as they were some
> months ago and only apply slight bugfixes in the soon future.
>
> But by no means a new-written driver should get forced to use the
> kernel-i2c stuff, this would only increase the risk of new clashes like
> the one we had now.

Ah I see. See, what I'm trying to do (with the i2c stuff) is fix the i2c bus 
in general so that clashes are not possible. I agree that just using i2c_xfer 
directly and not registering i2c drivers solves the issues with clashing DVB 
frontend drivers. However, it still leaves all the other i2c drivers in the 
system free to stomp all over us (e.g. the tda9887 as I mentioned). I'm 
attempting to fix _that_ behaviour with my i2c stuff. As it means changing 
the i2c core code, changes to *THAT* have to "fit in" with what will be 
acceptable to the core i2c developers, no matter how annoying doing so may be 
as it is someone else's project.


The second issue is to decide how to improve things for the future. I don't 
care what bus architecture people use. Your proprosal provides similar 
features to mine in that board drivers can tailor frontends as they wish. In 
fact, as yours automatically supports non-i2c buses it is obviously more 
flexible than mine. I like flexibility. Therefore, I prefer _your_ proposal 
for this.