On Fri, Jul 1, 2011 at 12:56 AM, Alan Cox <alan@xxxxxxxxxxxxxxx> wrote: > The slave devices all appear to be generic i2c interface hardware. I > don't see why they are separate special slave devices to your driver, > they should simply be i²c drivers so they can be used when those > devices are found without the mpu3050. Just to field this quickly, since I've been playing with the hardware involved. There are actually two different things handled by the "slave devices". The MPU-3050 (and some similar InvenSense parts) provide a secondary I2C bus. By default this is passed through to the I2C bus on which the 3050 is installed, but the MPU can also detach the extra bus and act as an I2C master on it. A slave device is connected on this extra bus, configured normally by the kernel, and then taken over by the MPU (which will periodically do a block read of a configured address). The second case of a slave device is simply some other device that the driver reads from, and passes the data to the MPU for processing. 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. The other note that may not have been made explicit yet is that the 3050 will happily provide unprocessed gyro and slave data without firmware loaded. The firmware sets up some additional processing capabilities of the chip, which are used by InvenSense's user-space products. Chris [Sorry about gmail. I'm on the road and hope it doesn't mangle things too badly.] -- 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
