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

[Holger Waechtler <holger@qanu.de>]

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).
>
> And what exactly are the advantages of having these two systems for
> similar things again?
significantly simplifying the code, making it readable, maintainable and 
robust against accidental changes when adjusting values for a particular 
board.

Holger