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

[Holger Waechtler <holger@qanu.de>]

Kenneth Aafløy wrote:
> On Sunday 12 September 2004 16:48, Andrew de Quincey wrote:
>
> > On Sunday 12 Sep 2004 15:35, Kenneth Aafløy wrote:
> >
> > > On Sunday 12 September 2004 16:23, Andrew de Quincey wrote:
> > >
> > > > > > Not registering to the i2c core and calling the i2c read/write
> > > > > > functions directly solves this. You just need to check that the card
> > > > > > mutex is hold by the read/write functions.
> > > > > So you're suggesting using the i2c_adapter structure, but not
> > > > > registering it with the kernel? Gah, I wish I'd understood thats what
> > > > > you meant two days ago!
> > > > Will this not cause problems with devices like the cx88 though - cards
> > > > using it can have other non-DVB i2c drivers which are registered with the
> > > > kernel i2c. I doubt they will work particularly well if they were given
> > > > an "unofficial" i2c_adapter.
> > > >
> > > > In that case, it would have to be registered, in which case autoprobing
> > > > is still a problem, hence why I am trying to fix autoprobing.
> > > I still don't see why this can't be solved in the dvb-drivers. The adapter
> > > itself can reject i2c-devices known to conflict with frontends in it's
> > > client_register function, or reject i2c-devices known not to exists on a
> > > particular adapter, hmm?
> > >
> > > This is the problem, right, or am I still far out? :)
> > Hmm yeah, but then the adapters have to know more than they should about other 
> > i2c devices in the system. And for things like the cx88 which can have dvb, 
> > video, tuner devices etc etc, you'd probably end up with complex ifs.  Also, 
> > as more i2c devices are implemented, more will clash in future, which will 
> > break things for a bit.
> >
> > I just prefer a generic way of just saying "don't probe - I'll choose myself". 
> > Then the problem goes away.
>
> But basically the code for "don't probe - I'll choose myself" could be put in
> client_register..
>
> Also we should have a client class for frontends, so that we can filter out all
> non-frontend i2c devices for cluttering with the i2c bus where at least it's
> known that no other i2c devices exists.
>
> static int client_register(struct i2c_client *client)
> {
>         struct saa7146_dev *dev = (struct saa7146_dev*)i2c_get_adapdata(client->adapter);
>         struct av7110 *av7110 = (struct av7110*)dev->ext_priv;
>
>         /* fixme: check for "type" (ie. frontend type) */
>  // TODO: #if (LINUX_VERSION_CODE < KERNEL_VERSION(x,x,x))
>  if ( !(client->driver->class & I2C_CLASS_DVB_FRONTEND) )
>   return -ENODEV;
>
>         if (client->driver->command)
>                 return client->driver->command(client, FE_REGISTER, av7110->dvb_adapter);
>         return 0;
> }
>
> hmm?
You always have EEPROMs on the bus, sometimes also video muxes, LNB 
switches, audio routers, uCs that decode IR signals. It's probably not a 
good idea to filter them out. Not to talk about mixed-analog-digital 
cards like the saa7146-based Siemens-DVB-C.

Holger