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

[Ralph Metzler <rjkm@metzlerbros.de>]

Andrew de Quincey writes:
 > On Friday 10 Sep 2004 14:13, Andrew de Quincey wrote:
 > > 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. 

Yes, that is a problem.
In my drivers I use this only for the STV0299 and give it hints like
that the IQ lines are inversed or that OP1 is power control. But it is
harder to define something which works for all cards.
 

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

Why exactly can't they define their own ids?
This would only be a problem if they are for PCI cards so that they
show up in mixed environments. Are there such cards?
If they are only used in STBs there should not be a problem to 
even use just one id (or small id range if they need to use 
several different ones at the same time) for all of those binary 
frontend drivers.

Even with PCI cards there first would have to be two 
cards by different vendors with the same demodulator chip (or one on
the same address) but wired differently and with different binary
drivers. If they use the same one id reserved for binary drivers then
there might be a problem ...


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

Exactly.


Ralph