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

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

On Sunday 12 Sep 2004 15:03, Holger Waechtler wrote:
> Andrew de Quincey wrote:
> > 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).
>
> Not registering to the i2c core and calling the i2c read/write functions
> directly solves this. You just need to check that the card mutex is hold
> by the read/write functions.

So you're suggesting using the i2c_adapter structure, but not registering it 
with the kernel? Gah, I wish I'd understood thats what you meant two days 
ago!