Messages in this thread | | | Date | Mon, 5 Apr 1999 09:48:12 +0200 (CEST) | From | Gerd Knorr <> | Subject | Re: i2c tuner initialization |
| |
On Mon, 5 Apr 1999, Michel LESPINASSE wrote:
> > Hello, > > 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)
post-install bttv modprobe -k tuner
> My understanding is that the interface with the i2c bus module goes like > this :
[ ... ]
> * It may introduce address clashes that could be avoided with a better > interface. Suppose I have two different i2c busses in my computer.
A driver can allways check the bus id.
> * 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.
You can have modules which are independent from the device which is the i2c bus master. For example video text chips, a character device for i2c access, ...)
> Do you think I should work on this ? Is there some advantages to the > current system that I do not see ?
It has one major design flaw: It can handle only simple bit-controllers. More clever i2c controllers (which can do complete bus-cycles in hardware for example) can't be handled.
See also: http://www.tk.uni-linz.ac.at/~simon/private/i2c/v4l/
Gerd
- 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/
| |