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

[Kenneth Aafløy <lists@kenneth.aafloy.net>]

On Friday 10 September 2004 16:26, Andrew de Quincey wrote:
> On Friday 10 Sep 2004 15:14, Ralph Metzler wrote:
> > 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.
>
> I was just assuming the IDs would be bad from Holgers POV. However, passing
> an ID is the same concept as passing a string really - the frontends are
> still cluttered. The advantage of a string is that it doesn't need to be
> defined in a kernel include file somewhere.

Well, the reason for using strings for identification of the adapter is really 
nice, but also ugly. I can't see the point Holger makes about binary adapter 
ID though, as lkml will act as a registrar of the iDs, in that what is not 
yet in mainline kernel has not been aprooved, and would be considered 
experimental. Any other ID defined in any later version of the linux kernel 
would be considered stable, and usable in a binary driver, as long as the 
binary driver maker (however narrow minded) updates it's drivers within a 
reasonable timeframe. A frontend driver not made after specification for a 
future pci (or other) hosting device can not be assumed to work with it 
anyhow.


> Holger, I assume that would preclude using a structure per-frontend device
> to pass arguments - that would mean changes to the kernel include files as
> well...
>
> Yuck. So as far as I can see, the choices for the "SET_TYPE" ioctl are:
> 1) Use a string to pass the hardware name and the frontend has board
> specific code in them.

Not an option, this will never get through to mainline, or ?:)

> 2) Define an opaque structure (e.g. a length field + byte array) for
> passing initialisation information to frontends. The OSS frontends would
> then have a structure for each frontend defined in the kernel includes that
> defines their byte array. Binary drivers would just send the byte array,
> and would not have to define its contents anywhere.

Maybe I'm missing the point in this conversation, but why is this even needed? 
The frontend will receive through the bitmask of the i2c adapter, every piece 
of information it could ever want:

The adapter registers with a class of I2C_ALGO_DVB | I2C_DRIVERID_{ADAPTER}.

The frontend driver will then check that the adapter->id matches the 
I2C_ALGO_DVB mask, if not return.
Further it will setup it's internals based on the I2C_DRIVERID_{ADAPTER}, 
which will determine wiering and other dissimilarities.
Optionally a frontend could also accept other I2C_ALGO_x masks to support 
other board types, and reconfigure accordingly...

Kenneth