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

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

On Friday 10 Sep 2004 14:13, 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).
>
> 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.

However, we _do_ still need to be able to tell the frontends board-specific 
parameters. We cannot rely on the i2c adapter name, so we still need a 
mechanism to do this. I'd suggest adding a new frontend internal IOCTL which 
the board drivers call when their frontends are detected to tell the frontend 
what settings to use.

As for what this IOCTL would contain - I think we'll never manage to get a 
generic way of specifing all the different parameters a frontend would need - 
we'd probably need a union of seperate structures, one per frontend driver. 
Its not just init tables - some frontends need different code paths in 
several places. 

We can't have an ID per card because of the issue you pointed out with binary 
drivers.

The simplest way is just to adapt the current behaviour of parsing board 
strings - the new ioctl would just send the board name (".e.g TT/Hauppauge 
USB Nova-T") at the frontend instance, and it would choose the correct 
parameter set. However, this has the disadvantage that the frontends are 
cluttered up with board-specific code.