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

[Ralph Metzler <rjkm@metzlerbros.de>]

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

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

Ralph