OpenCloudOS-Kernel/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c

237 lines
5.7 KiB
C
Raw Normal View History

/*
* Copyright (C) 2012 Invensense, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <linux/acpi.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/i2c.h>
#include <linux/iio/iio.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include "inv_mpu_iio.h"
static const struct regmap_config inv_mpu_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
};
static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
{
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
struct iio_dev *indio_dev = i2c_mux_priv(muxc);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
int ret = 0;
/* Use the same mutex which was used everywhere to protect power-op */
mutex_lock(&indio_dev->mlock);
if (!st->powerup_count) {
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
ret = regmap_write(st->map, st->reg->pwr_mgmt_1, 0);
if (ret)
goto write_error;
usleep_range(INV_MPU6050_REG_UP_TIME_MIN,
INV_MPU6050_REG_UP_TIME_MAX);
}
if (!ret) {
st->powerup_count++;
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
ret = regmap_write(st->map, st->reg->int_pin_cfg,
INV_MPU6050_INT_PIN_CFG |
INV_MPU6050_BIT_BYPASS_EN);
}
write_error:
mutex_unlock(&indio_dev->mlock);
return ret;
}
static int inv_mpu6050_deselect_bypass(struct i2c_mux_core *muxc, u32 chan_id)
{
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
struct iio_dev *indio_dev = i2c_mux_priv(muxc);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
mutex_lock(&indio_dev->mlock);
/* It doesn't really mattter, if any of the calls fails */
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
regmap_write(st->map, st->reg->int_pin_cfg, INV_MPU6050_INT_PIN_CFG);
st->powerup_count--;
if (!st->powerup_count)
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock 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. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-05 04:15:31 +08:00
regmap_write(st->map, st->reg->pwr_mgmt_1,
INV_MPU6050_BIT_SLEEP);
mutex_unlock(&indio_dev->mlock);
return 0;
}
static const char *inv_mpu_match_acpi_device(struct device *dev,
enum inv_devices *chip_id)
{
const struct acpi_device_id *id;
id = acpi_match_device(dev->driver->acpi_match_table, dev);
if (!id)
return NULL;
*chip_id = (int)id->driver_data;
return dev_name(dev);
}
/**
* inv_mpu_probe() - probe function.
* @client: i2c client.
* @id: i2c device id.
*
* Returns 0 on success, a negative error code otherwise.
*/
static int inv_mpu_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct inv_mpu6050_state *st;
int result;
enum inv_devices chip_type;
struct regmap *regmap;
const char *name;
if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_I2C_BLOCK))
return -EOPNOTSUPP;
if (client->dev.of_node) {
chip_type = (enum inv_devices)
of_device_get_match_data(&client->dev);
name = client->name;
} else if (id) {
chip_type = (enum inv_devices)
id->driver_data;
name = id->name;
} else if (ACPI_HANDLE(&client->dev)) {
name = inv_mpu_match_acpi_device(&client->dev, &chip_type);
if (!name)
return -ENODEV;
} else {
return -ENOSYS;
}
regmap = devm_regmap_init_i2c(client, &inv_mpu_regmap_config);
if (IS_ERR(regmap)) {
dev_err(&client->dev, "Failed to register i2c regmap %d\n",
(int)PTR_ERR(regmap));
return PTR_ERR(regmap);
}
result = inv_mpu_core_probe(regmap, client->irq, name,
NULL, chip_type);
if (result < 0)
return result;
st = iio_priv(dev_get_drvdata(&client->dev));
st->muxc = i2c_mux_alloc(client->adapter, &client->dev,
1, 0, I2C_MUX_LOCKED | I2C_MUX_GATE,
inv_mpu6050_select_bypass,
inv_mpu6050_deselect_bypass);
if (!st->muxc) {
result = -ENOMEM;
goto out_unreg_device;
}
st->muxc->priv = dev_get_drvdata(&client->dev);
result = i2c_mux_add_adapter(st->muxc, 0, 0, 0);
if (result)
goto out_unreg_device;
result = inv_mpu_acpi_create_mux_client(client);
if (result)
goto out_del_mux;
return 0;
out_del_mux:
i2c_mux_del_adapters(st->muxc);
out_unreg_device:
inv_mpu_core_remove(&client->dev);
return result;
}
static int inv_mpu_remove(struct i2c_client *client)
{
struct iio_dev *indio_dev = i2c_get_clientdata(client);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
inv_mpu_acpi_delete_mux_client(client);
i2c_mux_del_adapters(st->muxc);
return inv_mpu_core_remove(&client->dev);
}
/*
* device id table is used to identify what device can be
* supported by this driver
*/
static const struct i2c_device_id inv_mpu_id[] = {
{"mpu6050", INV_MPU6050},
{"mpu6500", INV_MPU6500},
{"mpu9150", INV_MPU9150},
{"mpu9250", INV_MPU9250},
{"icm20608", INV_ICM20608},
{}
};
MODULE_DEVICE_TABLE(i2c, inv_mpu_id);
static const struct of_device_id inv_of_match[] = {
{
.compatible = "invensense,mpu6050",
.data = (void *)INV_MPU6050
},
{
.compatible = "invensense,mpu6500",
.data = (void *)INV_MPU6500
},
{
.compatible = "invensense,mpu9150",
.data = (void *)INV_MPU9150
},
{
.compatible = "invensense,mpu9250",
.data = (void *)INV_MPU9250
},
{
.compatible = "invensense,icm20608",
.data = (void *)INV_ICM20608
},
{ }
};
MODULE_DEVICE_TABLE(of, inv_of_match);
static const struct acpi_device_id inv_acpi_match[] = {
{"INVN6500", INV_MPU6500},
{ },
};
MODULE_DEVICE_TABLE(acpi, inv_acpi_match);
static struct i2c_driver inv_mpu_driver = {
.probe = inv_mpu_probe,
.remove = inv_mpu_remove,
.id_table = inv_mpu_id,
.driver = {
.of_match_table = inv_of_match,
.acpi_match_table = ACPI_PTR(inv_acpi_match),
.name = "inv-mpu6050-i2c",
.pm = &inv_mpu_pmops,
},
};
module_i2c_driver(inv_mpu_driver);
MODULE_AUTHOR("Invensense Corporation");
MODULE_DESCRIPTION("Invensense device MPU6050 driver");
MODULE_LICENSE("GPL");