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

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

> > 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).

I would prefer to use the kernel i2c API because it is there, is standard, and 
otherwise means duplication of code and lots of locking.

> 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).

The whole reason for starting this discussion was because an analog TV tuner 
was incorrectly thinking the cx22702 demodulator was actually an instance of 
itself because there isn't a way to reliably autodetect the tda9887 (I've 
checked the docs).

Having two separate buses will not solve this problem - if a card is both 
DIGITAL and ANALOGUE, then the situation above could still occur. Only then, 
we'll have two drivers trying to talk to the same i2c device at possibly the 
same time, only one of which will be the correct driver.

As far as I can see, the way to fix it properly is for all multimedia cards to 
specify exactly which i2c hardware they expect based on card-specific 
knowledge (eeprom/PCIIDs/etc), and not use autoprobing.