On Fri, 1 Jul 2011 15:41:50 +0100, Alan Cox wrote: > > Just to field this quickly, since I've been playing with the hardware > > (Ditto) > > > Part of the reason I got started on the KXTF9 driver was to try and > > understand how a normal kernel driver could cope with the "here and > > gone again" behavior of being on the MPU's secondary bus. > > It's a hot pluggable bus - no different to an i2c bus on a hot pluggable > device. > > I would guess however that if you knew the device was going to be used for > the mpu3050 only you'd not add the "slave" devices in your platform data > in the first place as well so they didn't bounce in and out and you'd > probably teach the mpu3050 code to not create the bus if it was then > going to destroy it again a moment later. I didn't look in the code in details, but I see no reason to destroy buses. This is a standard multi-master case, where a given I2C bus segment can be driven by two masters. If both the host I2C controller and the MPU3050 master are fully I2C compliant, it should be no problem to let both coexist. If you really need to handle mutual exclusion (e.g. the MPU3050 implementation forces you to do so), you can leverage the i2c multiplexing support for this, which is available since kernel 2.6.36. See drivers/i2c/muxes/pca9541.c for an example implementation. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
