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

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

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.

Isn't a client-type field the same as the clients testing the adapter type 
field to check that it meets what they expect?