[linux-dvb] Re: Suggestion for DVB frontend configuration API

[Holger Waechtler <holger@qanu.de>]

Andrew de Quincey wrote:
> Hi, this is a suggestion for how to configure a frontend for a specific 
> hardware device. I'm using the tda1004x as an example. This does not attempt 
> to solve the issues with clashing i2c devices.
>
>
> Add two new frontend ioctls: 
> The first is FE_CONFIGURE. This is called by the card-specific driver to set 
> hardware-specific values. It takes the following structure:
>
> struct dvb_frontend_configuration {
>  int size;
>  unsigned char version;
>  unsigned char data[1];
> };
>
> The size field gives the total size of the structure. Version is to permit 
> changes to the fe-specific structure to be tracked. The data field is 
> variable size and contains frontend-specific information.
>
> Each frontend device then has a frontend-specific structure mapped on top of 
> this. For the tda1004x, it would be something like:
>
> #define TDA1004X_STRUCT_VERSION 0
> #define TDA1004X_TUNER_TD1344 0
> #define TDA1004X_TUNER_TD1316 1
>
> struct dvb_frontend_configuration_tda1004x {
>  int size;
>  unsigned char version;
>  unsigned char demod_address;
>  unsigned char tuner_type;
>  unsigned char tuner_address;
>  unsigned char inversion;
> };
>
> "demod_address" tells it the i2c address of the demodulator. This won't be 
> used initially as the detection will still be based on auto-probing the i2c 
> bus. When/if we switch to explicitly requesting frontend drivers, this will 
> be used.
>
> It is not necessary to tell it the demodulator type as this can be reliably 
> autodetected. 
> "tuner_type" will tell the frontend driver what tuner it should use. 
> "tuner_address" is obvious.
>
>  "inversion" tells the hardware to invert the signal or not (e.g. tda10045 on 
> TTPCI hardware requires this OFF - tda10046 on TTUSB hardware requires this 
> ON).
>
> These frontend structures can be defined in the DVB kernel headers somewhere 
> for OSS frontends. For binary-only drivers/frontends, they can be left opaque 
> - the driver core will just pass the dvb_frontend_configuration data about.
>
>
> The other ioctl is FE_IDENTIFY. This takes a structure as follows:
>
> struct dvb_frontend_type {
>  char name[100];
> };
>
> The frontend fills out "name" with its name.. e.g. "tda10046".
>
> With the current autodetection-based i2c support, a card driver performs its 
> normal setup, including creating an i2c adapter, and letting the kernel 
> auto-probe it for devices. It then goes through the list of its frontends, 
> calls FE_IDENTIFY to identify them, and then calls FE_CONFIGURE to set them 
> up as appropriate. 
> From my reading of it, this is similar to Holger's frontend library idea, only 
> leaving the i2c-based frontends using the kernel i2c support. I've tried to 
> keep it so that there are minimal changes to the existing API, and that 
> binary drivers are supported without kernel modifications. We should also be 
> able to turn the current card specfic frontend hacks into generalised code.
>
> Anyway, this is just a first stab at resolving this issue. Let me know what 
> you think.
>
>
>
>
> I'm still thinking about the clash issue. When the card driver is "performing 
> its normal setup" as I said above, I think we'll have to do something along 
> the lines of requesting frontend drivers by name - which means for frontends 
> using the kernel's i2c support (which I personally would prefer to use), we 
> will somehow have to disable autoprobing when the i2c bus is created. As for 
> how we limit _other_ i2c devices from randomly popping up - this all needs 
> more thought.

http://www.linuxtv.org:81/mailinglists/linux-dvb/2004/09-2004/msg00216.html 
would resolve both issues the easy way. No need for new ioctls, no need 
for API extensions, just solve your problem in a couple of lines of code 
and then go out and enjoy the last days of summer.

Holger