I am currently looking at the way the tuner is initialized in the bttv
driver (from pristine 2.2.5 kernel sources) and I'm getting confused.
Basically, it all started when I wondered if I could get the tuner module
to be autoloaded by kmod (and I still dont manage to do this)
My understanding is that the interface with the i2c bus module goes like
this :
* the i2c device drivers register themselves with the i2c module, saying
what kind of i2c devices they can drive and the range of addresses where
these devices can be expected.
* the bttv driver registers its i2c bus to the i2c module, which then
probes it for the devices whose drivers that have been registered.
* when one device is found on one of the registered busses with an address
that corresponds to one of the registered drivers, the bus owner can be
informed via a callback routine that a device has been attached.
The i2c code uses this method to decouple the bus owners from the drivers.
This is extremely generic, however I think it may have a few problems :
* It makes autoloading of modules a very unnatural operation. With this
registering interface, bus owners will not know if a device is absent from
the i2c bus or if it was just that his module was not loaded and
registered with the i2c module. The only solution that I can see is for
the bus owners to call request_module before registering
* It may introduce address clashes that could be avoided with a better
interface. Suppose I have two different i2c busses in my computer. Each of
these busses are connected to one or more devices, but there is a device A
on the bus 1 and a device B on the bus 2 that have the same address. These
devices are different from each other and they use different drivers named
DA and DB. With the current system, this would be a problem : DA and DB
will register themselves with the i2c module, then the owner of bus 1 will
register itself. The i2c code will see that there is a device on bus 1,
but it will not be able to know if this is a device of type A or type B !
This address clash problem is disturbing, because the i2c code is
otherwise extremely generic. I think a different interface with the i2c
module would be more logical :
* a bus owner registers himself with the i2c module
* the bus owner explicitly probes for the types of devices that he expects
to find on its i2c bus. For example, the bttv bus owner would probe for
tuner and msp3400 devices, because this is what he expects and he wouldnt
know how to use other devices if they were present anyway. This probing
would go like this : instead of waiting for the callback attach_inform
(bus, driver_id) to be called, the bus owner would directly call a
function i2c_probe_device (bus, driver_id) and this function would return
a boolean indicating if a device of this type was found on this bus.
This would avoid the address clash problem, because the i2c code now knows
about which type of device is expected by the bus owner so he can tell
that the device on bus 1 is of type A and the device on bus 2 is of type
B.
This would also make the auto-loading problem much easier - if the bus
owner probes for a device that is handled by a driver that is not loaded
yet, i2c_probe_device could call request_module.
Do you think I should work on this ? Is there some advantages to the
current system that I do not see ?
--
Michel "Walken" LESPINASSE - Development Engineer at Wind River Systems
walken@wrs.com - http://www.via.ecp.fr/~walken/
Microsoft has a Y2K problem. It's called Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/