[linux-dvb] Suggestion for DVB frontend configuration API

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

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.