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.
> 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);
}
Regards,
Andreas
Attachment:
signature.asc
Description: This is a digitally signed message part