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

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

On Friday 10 Sep 2004 14:56, Ralph Metzler wrote:
> Andrew de Quincey writes:
>  > On Friday 10 Sep 2004 13:10, Ralph Metzler wrote:
>  > > Holger Waechtler writes:
>  > >  > Andrew de Quincey wrote:
>  > >  > > Yeah, that sounds good. So effectively the frontend drivers will
>  > >  > > cease to be kernel i2c devices. However, we'll still use the
>  > >  > > kernel i2c for the adapter's i2c buses if need be, so no one can
>  > >  > > complain we're duplicating stuff again. That makes sense - theres
>  > >  > > no point really in making the frontends generic devices usable by
>  > >  > > non-DVB code.
>  > >  > >
>  > >  > > How will we prevent things like that tda9887 tuner from taking
>  > >  > > over our addresses on the bus accidentally if our bus is marked
>  > >  > > as ANALOGUE and DIGITAL? We should probably claim addresses on
>  > >  > > the bus that we use - but it all depends on what order things are
>  > >  > > loaded in.
>  > >  >
>  > >  > I would not claim any addresses, why should we? Even registration
>  > >  > to the kernel i2c API is optional (and only introduces delays and
>  > >  > the risk of accidentally attached devices from other subsystems).
>  > >  >
>  > >  > The generic i2c_read/write() implementations in the card drivers
>  > >  > should allow writes to all addresses. If not we should fix them,
>  > >  > we're maintaining them anyway. We also need to ensure they are
>  > >  > correctly locking on the low level because we don't rely on the i2c
>  > >  > layer locking mechanism anymore (but last time I checked most
>  > >  > drivers implemented correct semaphores, so this should not really
>  > >  > be a problem).
>  > >  >
>  > >  > If properly done both systems can existence peacefully in
>  > >  > coexistence and concurrent accesses are allowed (like it was the
>  > >  > case for the dvb_i2c_bus code).
>  >
>  > Sorry! hit the wrong key before.
>  >
>  > > And what exactly are the advantages of having these two systems for
>  > > similar things again?
>  > > You will again have a lot of code duplication with only minimal
>  > > differences depending on the card type and necessary fixes
>  > > (like the locking) to make it work with existing structures if
>  > > you happen to need other i2c clients.
>  >
>  > yeah, I don't like having multiple i2c implementations hitting the same
>  > bus. Thats why I would prefer to use the kernel i2c implementation where
>  > possible, since it handles locking and bitbanging (if necessary) for us.
>  >
>  > > Getting rid of wrong attaches is easily done by introducing a
>  > > client type field as I described before or just by getting an id range
>  > > reserved in i2c-id.h as it is already done for sensors and V4L2 common
>  > > components (is the latter used yet?).
>  >
>  > We can't have an id per frontend - from what Holger described about the
>  > binary-only firmwares.
>
> Completely closed drivers could still use their own thin I2C layers or
> other means (see below).
>
> I see how what Holger describes would make things a little bit
> easier for pure DVB drivers if you want to use existing
> i2c clients you get added complexity.
>
> But I can see how one could use such a really thin layer and
> alternatively either put a generic i2c kernel client registration
> layer above it or use it directly with a DVB driver if the latter
> really does not need anything else.

Yeah, I agree. 

IMO OSS frontends that are in the official kernel source should use the 
official kernel facilities though.

>  > Isn't a client-type field the same as the clients testing the adapter
>  > type field to check that it meets what they expect?
>
> Testing the adapter type in the client allows the client to prevent
> attaching to non-DVB adapters but the adapter might still get attach
> callbacks from unwanted other clients or from DVB frontends it
> does not know.
>
> If the client would have a type of DVB demodulator or would be in the id
> range of DVB demodulators the adapter also could always attach and
> register it as a frontend, even if it does not know this specific one.
> Configuration of specific frontend subtypes could still be handled by
> SET_TYPE calls or even config table upload calls.
>
> You could also add your own secret GET_TYPE calls where the frontend
> tells the adapter what kind it is if you really do not want one
> id per frontend for those binary-only drivers.

I get you - I seem to be heading to the same place you are.