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

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

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

I've no idea of the specifics, but he has always been very clear that it is 
not feasible to do this sort of thing with IDs - I'm not involved in any of 
the binary-only driver development, he is.

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

This wont work either unfortunately:

Firstly, multiple boards use the same PCI/I2C interface chips - the cx88 and 
SAA7146 are used by multiple different boards, each of which uses different 
tuners/demods. These drivers will all have the same i2c adapter id since they 
use the same underlying chip - theres no way to tell them apart without 
adding additional IDs.. which Holger doesn't like. (BTW, I'm guessing in 2.6 
the masking in the example you give above has been replace by a new "id" 
field in the i2c_adapter structure)

Secondly, I'm trying to remove the hardware-specific hacks in the frontends in 
favour of a more generic approach.