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

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

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.

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.

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.