On Wed, 2004-01-28 at 15:58, Andrew de Quincey wrote:
Actually on second thoughts, it seems a bit nasty to have the frontend code
split up into several places. Another method might be to modify the FE_INIT
ioctl to take an int parameter describing what kind of frontend configuration
is required for the hardware it is attached to... e.g. FE_CONFIG_TT for for
TechnoTrend style cards and so on.
Defining an id for every single board is a mess IMHO.
Yes - that was one of the decisions why we don't use the kernel i2c code
- this API would require us to touch the main kernel i2c API files again
and again when we add a new driver because we need to add our new id
there...This also means parameters which are hardware specific at runtime can be
implemented (e.g. for TT TDA10046H, it is necessary to invert the sense of
the fe_params->inversion setting).
For now you can define the needed bits in your drivers private data
according to the detected combination of demod and pll.
Or how about:
void invert_inversion(struct dvb_frontend_parameters *p)
{
if (p->inversion < INVERSION_AUTO)
p->inversion = !p->inversion;
}
int before(struct dvb_frontend *frontend, unsigned int cmd, void *arg)
{
struct my_frontend_priv *foo = frontend->before_after_data;
switch (cmd) {
case FE_GET_FRONTEND:
case FE_SET_FRONTEND:
if (foo->rev == FOO_REV_1_3)
invert_inversion(arg);
break;
}
return -EOPNOTSUPP;
}
int some_init(void)
{
struct my_frontend_priv *priv = some_alloc(FOO_REV_1_3);
struct dvb_adapter *adap = get_some_adap();
return dvb_add_frontend_ioctls(adap, cb, cb, priv);
}
Or you set up a config struct at initialisation time (parse the
i2c->adapter->name string to find out the board or box where the
frontend is located) and pass it to the frontend private data pointer.
In most cases a pointer to a static config struct should be sufficient,
or you use the bitfield as Andreas suggested...