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

[Andreas Oberritter <obi@linuxtv.org>]

Hi,

Am Di, den 21.09.2004 schrieb Gerd Knorr um 15:51:
> 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.

Well, I dislike using "I2C commands" for the following reason: On
embedded STBs the I2C bus is usually not bound to a PCI/USB device like
in the PC world. You can use the in-kernel drivers for the MPC8xx and
IBM4xx platforms for example. With this API change (and also the
previous FE_REGISTER/UNREGISTER commands) you will have to patch these
I2C drivers in a way which will never be accepted by the kernel folks.
(e.g. #if defined(CONFIG_DBOX2) then make 8xx-i2c depend on dvb, include
the necessary headers and have a lot of knowledge about the 6 different
dbox2 frontends and their PLLs *inside* the generic mpc8xx i2c driver.)

Will support for non-PCI and non-USB devices be dropped?

Regards,
Andreas