Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: refactoring
> > > struct dvb_fe {
> > > struct fe_api *api;
> > > struct dvb_adapter *dvb;
> > > void *priv;
> > > };
>
> Issue: We need two void* in dvb_frontend.
>
> One for the demodulator to store its private state+config in. Another for the
> card driver to which the demodulator is attached to store something.
Yep, I was thinking that we might need that well while looking at ...
> /* PLL maintenance */
> int (*pll_init)(struct dvb_frontend* fe);
... these prototypes ;)
> My current prototyped XXX_attach() function is:
>
> extern int at76c651_attach(struct at76c651_config* config,
> struct dvb_frontend_ops* ops,
> struct dvb_adapter* dvb,
> void* adapter_data,
> struct dvb_frontend** fe);
Hmm, giving this I'm not fully sure it is a good idea to have the fe
(demod) drivers allocate struct dvb_frontend. Maybe we should do it
this way:
struct dvb_frontend {
/* general info */
struct dvb_frontent_info *info;
struct dvb_adapter *dvb;
#ifdef __linux__
struct device *dev; /* sysfs */
#endif
/* to be filled by the demod driver */
struct demod_ops *demod_ops;
void *demod_priv;
/* to be filled by the pll driver */
struct pll_ops *pll_ops;
void *pll_priv;
}
Then have the adapter driver allocate + free dvb_frontend and pass it
down to the *_attach function for filling in the missing informations.
Same goes for the pll stuff. If the dvb adapter driver implements that
directly -- fine, then it can just fill in the stuff itself. But the
pll stuff could also live in a separate module, where the adapter driver
calles some init function and passes in the dvb_frontend struct to get
the pll_* fields initialized.
Gerd
--
return -ENOSIG;
Home |
Main Index |
Thread Index