Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Proposal for new frontend architecture



Michael Hunold <hunold-ml@web.de> writes:

> Of course dvb_stv0299 should look more like this:
> 
> struct dvb_stv0299 {
> /* set by the client */
>    struct dvb_fe_identifier id; /* must be first */
>    int (*stv0299_writereg (struct i2c_adapter *i2c, u8 reg, u8 data)
> /* set by the adapter */
>    int (*pll_set_tv_freq) (struct i2c_adapter *i2c, u32 freq, int
> ftype, int srate);
>    int (*set_symbolrate) (struct i2c_adapter *i2c, u32 srate);

Hmm, I don't like the idea of function pointers in there that much.
Once we have the adapter->command() infrastructure we can simply use
that directly, i.e. have ->command(SET_{RATE|PLL}) additionaly to
->command(GET_INFO).

I'd also prefeare to simply have multiple (maybe reusable? don't know
that much fe drivers yet ...) GET_whatever commands instead of
creating a struct for every frontend.  cx22702 for example could just
call ->command(FE_GET_PLL_TYPE) + ->command(FE_GET_MIN_FREQ) to get
the info it needs.

> Then the necessary inittables can be put into the dvb adapter and
> stv0299_writereg() can be used to initialize the
> device. Alternatively, the inittables can be exported through struct
> dvb_stv0299, too.

I'd export the tables instead and let all stv0299 stuff inside the
stv0299 module.

  Gerd

-- 
return -ENOSIG;




Home | Main Index | Thread Index