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

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 21.09.2004 14:09, Holger Waechtler wrote:
> what again was the intention of this patch?
The intention was to remove the probe function from the stv0299 driver 
and let the dvb driver (ie. dvb-ttpci) tell the frontend driver if that 
particular frontend can be on the i2c bus and if it really is, provide 
programming details like low-level pll functions.

> well... this leads all the ideas of the early mails in this thread ad 
> absurdum: you introduce another strong interdependency á la kernel-i2c 
> id's between dvb-core and the lowlevel driver code, make it impossible 
> to write independent and robust standalone drivers without touching the 
> core too.
I didn't want to waste a lot of time separating the stuff, so the 
easiest way was to export the ID for now.

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);
};

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.

> not to mention that all the recent patchsets have much more '+' than 
> minus signs... our code gets more and more bloated without adding any 
> new functionality or improving readability.
I didn't want to remove the probe_tuner() function in order to maintain 
backward compatiblity.

Additionally, I think "adding new functionality" and "total number of 
lines" don't work well together.

> Holger
CU
Michael.