> On 2006-03-15, Mark M. Hoffman wrote:> > Wow, that's a huge delay. One alternative would be for i2c slaves to> > behave more like USB and do the probing asynchronous to driver load;> > i.e. 'modprobe w83627hf' returns before the chip is actually recognized> > and attached.> * Jean Delvare <khali@linux-fr.org> [2006-03-15 10:01:47 +0100]:> You mean that the i2c subsystem would finally be rewritten from scratch> to comply with the driver model? I'm waiting for your patches :)

Heh, 'spose I asked for that.

> > OTOH, that brings up all the related problems. E.g., you could no longer> > expect this simple fragment of a RC script to work...> >> > modprobe i2c-sis96x> > modprobe asb100> > sensors -s> > I guess we would have to use hotplug instead then.> > > Short of fixing all that... one has to accept that (1) i2c bus probing> > is slow, and (2) some i2c busses themselves are not reliably> > detectable...> > Things can be improved still. The busses which cannot be reliably> detected could test themselves, and discard themselves if they find they> don't work. This is much the spirit of the bit_test parameter of the> i2c-algo-bit module; it could be made the default. i2c-algo-pca could be> added a similar option.> > Also, the i2c subsystem is currently relying on general probing for> almost everything. Whenever you load an i2c chip driver, it'll probe> all the i2c busses for supported chips. We tried to limit the probing> area by introducing the concept of "classes", and we now only probe> the busses which share a class with the i2c chip driver. Not all drivers> have been modified to take benefit of that class check though, and the> i2c core doesn't enforce it at the moment; it is all based on drivers> cooperation. So there is room for improvement here.> > Last, sometimes you know exactly where the chip is, yet the i2c core> doesn't offer a way to skip the probing step and attach the driver> directly to the device. I'm working on a way to do that, and hope to> have something ready to show soon. This should speed up the driver load> quite a bit.

Here's a start: why does i2c-parport[-light] have a default adapter type?Loading it with the default could be considered an accident by definition.It takes ~6 seconds to load all of kernel/drivers/hwmon/*.ko on a test boxhere with i2c-parport-light present (but without any adapter hardware).With this patch, that drops to ~1 second.

---

This patch forces the user to specify what type of adapter is present whenloading i2c-parport or i2c-parport-light. If none is specified, the driverinit simply fails - instead of assuming adapter type 0.

This alleviates the sometimes lengthy boot time delays which can be causedby accidentally building one of these into a kernel along with several i2cslave drivers that have lengthy probe routines (e.g. hwmon drivers).