[linux-dvb] Re: [rfc/patch] pll handling and cx22702 update

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

Hmm, on reviewing some of the tuners and further consideration, I've come up 
with the following:

enum dvb_tuner_mode {
 DVB_PLL_SCAN,
 DVB_PLL_LOCK,
};

struct dvb_tuner_ops {
  int (*read)(void* card_data, int device, u8* buf, int size);
  int (*write)(void* card_data, int device, u8* buf, int size);

 void* card_data;
};

struct dvb_tuner_desc {

 char *name;
 int buf_size;
 int (*init) (struct dvb_tuner_ops* ops);
 int (*suspend) (struct dvb_tuner_ops* ops);
 int (*set) (struct dvb_tuner_ops* ops, struct dvb_frontend_parameters * 
params, dvb_tuner_mode mode);
};

Firstly, the tuner is more than just the PLL. Some of them have more than one 
device which must be programmed... e.g. the TDM1316L has the MC44bc374c chip 
which must be disabled for proper functionality. This is a tuner-specific 
detail and not a card-specific one - it is inside the tinbox.

Now, I DID like extracting the frequency ranges etc from the code, but it just 
isn't flexible enough - it restricts us to the dumbest possible tuning 
functionality - we can make it a lot smarter... e.g. the above also allows 
the two standard operation modes - SCAN and LOCK. Admittedly we don't support 
this elsewhere right now, but we _should_ to get the best performance. Other 
tuners also have more sophisticated code, reading back the PLL lock status to 
avoid unnecessarily long msleeps().

dvb_tuner_ops is made up by the card driver to asbtract the tuner code away 
from the hardware specifics. card_data is a pointer to some internal 
card-specific structure. We unfortunately cannot just supply an 
i2c_adapter+i2c_address because writing to a tuner is a card specific 
operation - some of them need to twiddle things on the demods to do so.

The "int device" parameter to the read()/write() functions is for devices like 
the TDM1316L which have more than one device - e.g. device 0 would be the PLL 
and device 1 the MC44BC374. Most would just use device 0 however.