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

[Gerd Knorr <kraxel@bytesex.org>]

> >   * let the frontend pull config information from the driver, i.e.
> >     instead of a i2c_driver->command(SET_FOO) we'll use
> >     i2c_adapter->command(GET_FOO).  Main difference is that the pull
> >     approach allows the frontend driver to fetch config info in the
> >     i2c_driver->adapter_attach() callback, _before_ doing the actual
> >     probing and device registering.
> >
> >   * allows the frontend ask the driver for certain stuff like setting
> >     the PLL.
> 
> Interesting idea - so that would let us say things like "probe on this couple 
> of addresses, but NOT this one".... as well as supplying extra configuration.

Exactly.

> Hmmmm... could this be a way to restrict which devices are allowed on the bus 
> as well?

Partly, the drivers have to play nice for that, you can't _force_ them
not to probe.

Right now the initialization goes this way (using my bttv+tuner as example):

 (1) tuner	registers itself via i2c_add_driver().

 (2) i2c-core	calls i2c_driver->attach_adapter(), i.e. tuner_probe(),
		for every i2c adapter (no matter whenever they already
		there when tuner.c registeres or appear later on).

 (3) tuner	tuner_probe() looks what kind of adapter it is by checking
		the .class field, when it is a analog TV card it calls
		i2c_probe().

 (4) i2c-core	i2c_probe() scans the given addresses on the i2c bus,
		calling back for every hardware it has found.

 (5) tuner	the tuner_attach() callback does the actual
		initialization and device registration.

 (6) i2c-core	informs the adapter driver (i.e. bttv) that there is a
		new device registered on the bus.

 (7) bttv	informs the tuner driver via ->command(TUNER_SET_TYPE)
		which exact tuner type is on the board.

Having a callback in i2c_adapter like the i2c_driver already has (be it
named command() or get_info() or whatever) allows us to do several stuff
much earlier in the initialization path:

tuner_probe() can fetch informations.  If the bttv driver knows the card
in question hasn't a analog tuner in the first place (tuner_type ==
TUNER_ABSENT) it can just return and not call i2c_probe().  For the dvb
frontends that would be even more useful as there are several ones
instead of one single module for all tuners.  It's also possible to
fetch config info in either tuner_probe (i2c bus addresses for example)
or tuner_attach (any stuff needed to setup the device).  And probably
more useful stuff.

One quirk with this is that there is a chicken-and-egg issue with cards
which have config info in a i2c-connected eeprom chip.  Current bttv
solves that by doing the TUNER_SET_TYPE thingy in two different places,
once in the callback mentioned above and once after reading the eeprom
to make sure it works with any module load order.  One fix for that I
can think of is to separate adapter registering and bus scan, i.e.
have something like

	i2c_add_adapter_noprobe();
	/* bttv can read the eeprom here */
	i2c_adapter_probe_drivers();

Additional benefit is that i2c adapters can bypass autoprobe altogether
by simply not calling i2c_adapter_probe_drivers() ;)

Comments?

  Gerd

-- 
return -ENOSIG;