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.
I still can't see the point of your argumentation, what exactly is the
advantage over the trivial implementation proposals Andrew posted?