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