On Thu, Feb 18, 2016 at 05:53:14PM +0200, Daniel Baluta wrote: > From: Adriana Reus <adriana.reus@xxxxxxxxx> > > This deadlock occurs if the accel/gyro and the sensor on the auxiliary > I2C (in my setup it's an ak8975) are working at the same time. > > Scenario: > > T1 T2 > ==== ==== > inv_mpu6050_read_fifo aux sensor op (eg. ak8975_read_raw) > | | > mutex_lock(&indio_dev->mlock) i2c_transfer > | | > i2c transaction i2c adapter lock > | | > i2c adapter lock i2c_mux_master_xfer > | > inv_mpu6050_select_bypass > | > mutex_lock(&indio_dev->mlock) > > When we operate on an mpu sensor the order of locking is mpu lock > followed by the i2c adapter lock. However, when we operate the auxiliary > sensor the order of locking is the other way around. > > In order to avoid this enable the bypass mux bit once in the beginning > and remove the select/deselect_bypass functions. > > This patch moves the bypass enabling in a separate function > that is called once at probe and removes the functionality from > inv_mpu_select/deselect_bypass. > > Another advantage of this approach is that power-wise the mpu chip isn't > powered up at each auxiliary sensor i2c transaction so if only the > compass is used this would be more power efficient. I think the comments (power must be enabled on select) rendered this solution not acceptable. What about using mutex_trylock in inv_mpu6050_select_bypass() and returning -EAGAIN if the lock is already held?
Attachment:
signature.asc
Description: PGP signature
