summaryrefslogtreecommitdiff
path: root/drivers/iio/imu/inv_mpu6050/Makefile
diff options
context:
space:
mode:
authorSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>2015-01-31 01:25:45 +0300
committerJonathan Cameron <jic23@kernel.org>2015-02-25 15:02:59 +0300
commita35c5d1aa96aa6cc70e91786cbe9be4db23f8f4a (patch)
tree61615139eb7c11836fedbde7d0a06ee8172b1548 /drivers/iio/imu/inv_mpu6050/Makefile
parent9820d88332095bc4b5ef67799e149472fcb9aa40 (diff)
downloadlinux-a35c5d1aa96aa6cc70e91786cbe9be4db23f8f4a.tar.xz
iio: imu: inv_mpu6050: Create mux clients for ACPI
This is a follow up patches after adding i2c mux adapter for bypass mode. Potentially many different types of sensor can be attached to INVMPU6XXX device, which can be connected to main cpu i2c bus in bypass mode. Why do we need this? The system ACPI table entry will consist of only one device for INV6XXX, assuming that this driver will handle all connected sensors. That is not true for the Linux driver. There are bunch of IIO drivers for each sensors, hence we created a mux on this device. So to load these additional drivers, we need to create i2c devices for them in this driver using this mux adapter. There are multiple options: 1. Use the auto detect feature, this needs a new i2c class for the adapter as the existing HWMON class is not acceptable. Also the autodetect has overhead of executing detect method for each matching class of adapters. This is a simple implementation. This option was previously submitted with not a happy feedback. 2. Option is use ACPI magic and parse the configuration data. What we need to create a i2c device at a minimum is address and a name. Address can be obtained for secondary device in more or less in a standard way from using _CRS element. But there is no name. To get name we need to process proprietary vendor data. Not having name is not fun, as you have to create device using the device name of INVN6XXXX, respecting driver duplicate name space restriction. Also each client driver needs to have this name in the id table. Since multiple driver can be loaded, the driver should be able to detect its presence and gracefully exit for the other client driver to take it over. So we use two step process: - Use DMI to id platform and parse propritery data. This is not uncommon for many x86 platform specific driver. We will get both name and address. The change created necessary infrastructure to add more properitery vendor data parsing. - If DMI match fails, then create device on INV6XXX-client (we can't create with same name as INV6XXX as it will cause duplicate name and driver model will reject.) With this each client sensor driver which needs to get attached via INV6XXXX, need this name in the id table and detect the physical presence of sensor in probe and exit if not found. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Diffstat (limited to 'drivers/iio/imu/inv_mpu6050/Makefile')
-rw-r--r--drivers/iio/imu/inv_mpu6050/Makefile2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/iio/imu/inv_mpu6050/Makefile b/drivers/iio/imu/inv_mpu6050/Makefile
index 3a677c778afb..f566f6a7b3a9 100644
--- a/drivers/iio/imu/inv_mpu6050/Makefile
+++ b/drivers/iio/imu/inv_mpu6050/Makefile
@@ -3,4 +3,4 @@
#
obj-$(CONFIG_INV_MPU6050_IIO) += inv-mpu6050.o
-inv-mpu6050-objs := inv_mpu_core.o inv_mpu_ring.o inv_mpu_trigger.o
+inv-mpu6050-objs := inv_mpu_core.o inv_mpu_ring.o inv_mpu_trigger.o inv_mpu_acpi.o