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