* [PATCH 0/3] Enable AK8963 conneted via INV6500 @ 2014-12-15 21:19 Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-15 21:19 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Srinivas Pandruvada Now we have i2c-mux for invensense mpu6050/mpu6500 is merged, this patchset enables sensors routed through this. In this series enabling AK8975/AK8963. This device is connected to main cpu i2c bus via invensense bypass mode enabled by i2c-mux. Srinivas Pandruvada (3): iio: imu: inv_mpu6050: ACPI enumeration iio: imu: inv_mpu6050: Added adapter class iio: ak8975: Added autodetect feature for ACPI drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 11 +++++++++- drivers/iio/magnetometer/ak8975.c | 35 ++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 1 deletion(-) -- 1.9.3 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration 2014-12-15 21:19 [PATCH 0/3] Enable AK8963 conneted via INV6500 Srinivas Pandruvada @ 2014-12-15 21:19 ` Srinivas Pandruvada 2014-12-26 12:39 ` Jonathan Cameron 2014-12-15 21:19 ` [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI Srinivas Pandruvada 2 siblings, 1 reply; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-15 21:19 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Srinivas Pandruvada Added changes so that the module can be enumerated via ACPI. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c index 6d2c115..f73e60b 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c @@ -24,6 +24,7 @@ #include <linux/spinlock.h> #include <linux/iio/iio.h> #include <linux/i2c-mux.h> +#include <linux/acpi.h> #include "inv_mpu_iio.h" /* @@ -875,6 +876,13 @@ static const struct i2c_device_id inv_mpu_id[] = { MODULE_DEVICE_TABLE(i2c, inv_mpu_id); +static const struct acpi_device_id inv_acpi_match[] = { + {"INVN6500", 0}, + { }, +}; + +MODULE_DEVICE_TABLE(acpi, inv_acpi_match); + static struct i2c_driver inv_mpu_driver = { .probe = inv_mpu_probe, .remove = inv_mpu_remove, @@ -883,6 +891,7 @@ static struct i2c_driver inv_mpu_driver = { .owner = THIS_MODULE, .name = "inv-mpu6050", .pm = INV_MPU6050_PMOPS, + .acpi_match_table = ACPI_PTR(inv_acpi_match), }, }; -- 1.9.3 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration 2014-12-15 21:19 ` [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada @ 2014-12-26 12:39 ` Jonathan Cameron 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Cameron @ 2014-12-26 12:39 UTC (permalink / raw) To: Srinivas Pandruvada; +Cc: linux-iio On 15/12/14 21:19, Srinivas Pandruvada wrote: > Added changes so that the module can be enumerated via ACPI. > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> As this one stands on it's own. Applied to the togreg branch of iio.git. Thanks Jonathan > --- > drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > index 6d2c115..f73e60b 100644 > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > @@ -24,6 +24,7 @@ > #include <linux/spinlock.h> > #include <linux/iio/iio.h> > #include <linux/i2c-mux.h> > +#include <linux/acpi.h> > #include "inv_mpu_iio.h" > > /* > @@ -875,6 +876,13 @@ static const struct i2c_device_id inv_mpu_id[] = { > > MODULE_DEVICE_TABLE(i2c, inv_mpu_id); > > +static const struct acpi_device_id inv_acpi_match[] = { > + {"INVN6500", 0}, > + { }, > +}; > + > +MODULE_DEVICE_TABLE(acpi, inv_acpi_match); > + > static struct i2c_driver inv_mpu_driver = { > .probe = inv_mpu_probe, > .remove = inv_mpu_remove, > @@ -883,6 +891,7 @@ static struct i2c_driver inv_mpu_driver = { > .owner = THIS_MODULE, > .name = "inv-mpu6050", > .pm = INV_MPU6050_PMOPS, > + .acpi_match_table = ACPI_PTR(inv_acpi_match), > }, > }; > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class 2014-12-15 21:19 [PATCH 0/3] Enable AK8963 conneted via INV6500 Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada @ 2014-12-15 21:19 ` Srinivas Pandruvada 2014-12-26 12:37 ` Jonathan Cameron 2014-12-15 21:19 ` [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI Srinivas Pandruvada 2 siblings, 1 reply; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-15 21:19 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Srinivas Pandruvada To use i2c auto detect to work we need to have a non zero class. The closest class is I2C_CLASS_HWMON, as it defined to be used with all hw monitoring drivers. Also this class is already used by some iio driver, hid drivers, led and misc drivers. So this is not new that this is used outside hwmon drivers. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c index f73e60b..4af2d24 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c @@ -813,7 +813,7 @@ static int inv_mpu_probe(struct i2c_client *client, st->mux_adapter = i2c_add_mux_adapter(client->adapter, &client->dev, indio_dev, - 0, 0, 0, + 0, 0, I2C_CLASS_HWMON, inv_mpu6050_select_bypass, inv_mpu6050_deselect_bypass); if (!st->mux_adapter) { -- 1.9.3 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class 2014-12-15 21:19 ` [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class Srinivas Pandruvada @ 2014-12-26 12:37 ` Jonathan Cameron 2014-12-31 10:25 ` Wolfram Sang 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Cameron @ 2014-12-26 12:37 UTC (permalink / raw) To: Srinivas Pandruvada; +Cc: linux-iio, Wolfram Sang On 15/12/14 21:19, Srinivas Pandruvada wrote: > To use i2c auto detect to work we need to have a non zero class. > The closest class is I2C_CLASS_HWMON, as it defined to be used > with all hw monitoring drivers. > > Also this class is already used by some iio driver, hid drivers, led > and misc drivers. So this is not new that this is used outside > hwmon drivers. > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Been meaning to sort this out for a while. We really shouldn't be camping on the HWMON class (nor should anyone else). Wolfram, do you mind new classes being added? > --- > drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > index f73e60b..4af2d24 100644 > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > @@ -813,7 +813,7 @@ static int inv_mpu_probe(struct i2c_client *client, > st->mux_adapter = i2c_add_mux_adapter(client->adapter, > &client->dev, > indio_dev, > - 0, 0, 0, > + 0, 0, I2C_CLASS_HWMON, > inv_mpu6050_select_bypass, > inv_mpu6050_deselect_bypass); > if (!st->mux_adapter) { > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class 2014-12-26 12:37 ` Jonathan Cameron @ 2014-12-31 10:25 ` Wolfram Sang 2015-01-01 12:27 ` Jonathan Cameron 2015-01-04 19:20 ` Jean Delvare 0 siblings, 2 replies; 29+ messages in thread From: Wolfram Sang @ 2014-12-31 10:25 UTC (permalink / raw) To: Jonathan Cameron, Jean Delvare; +Cc: Srinivas Pandruvada, linux-iio On Fri, Dec 26, 2014 at 12:37:36PM +0000, Jonathan Cameron wrote: > On 15/12/14 21:19, Srinivas Pandruvada wrote: > > To use i2c auto detect to work we need to have a non zero class. > > The closest class is I2C_CLASS_HWMON, as it defined to be used > > with all hw monitoring drivers. > > > > Also this class is already used by some iio driver, hid drivers, led > > and misc drivers. So this is not new that this is used outside > > hwmon drivers. > > > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > Been meaning to sort this out for a while. We really shouldn't be camping > on the HWMON class (nor should anyone else). > > Wolfram, do you mind new classes being added? In general, I wouldn't mind but I wonder if it makes sense here. DDC and SPD are very special I2C uses where access should be limited, so a seperate class makes sense IMO. HWMON has a specific name, but really became "everything what people could hook to their I2C bus" these days. So, if anything, we could think about renaming I2C_CLASS_HWMON to I2C_CLASS_STANDARD or something (or at least add a comment about that in i2c.h)? I'd think IIO devices fall into the default category. Please say if you think different. If we'd add the IIO class, most drivers will need patches to support IIO devices which would have worked otherwise, so this change should be justified. @Jean: Do you have anything to add? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class 2014-12-31 10:25 ` Wolfram Sang @ 2015-01-01 12:27 ` Jonathan Cameron 2015-01-04 19:20 ` Jean Delvare 1 sibling, 0 replies; 29+ messages in thread From: Jonathan Cameron @ 2015-01-01 12:27 UTC (permalink / raw) To: Wolfram Sang, Jean Delvare; +Cc: Srinivas Pandruvada, linux-iio On 31/12/14 10:25, Wolfram Sang wrote: > On Fri, Dec 26, 2014 at 12:37:36PM +0000, Jonathan Cameron wrote: >> On 15/12/14 21:19, Srinivas Pandruvada wrote: >>> To use i2c auto detect to work we need to have a non zero class. >>> The closest class is I2C_CLASS_HWMON, as it defined to be used >>> with all hw monitoring drivers. >>> >>> Also this class is already used by some iio driver, hid drivers, led >>> and misc drivers. So this is not new that this is used outside >>> hwmon drivers. >>> >>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> >> Been meaning to sort this out for a while. We really shouldn't be camping >> on the HWMON class (nor should anyone else). >> >> Wolfram, do you mind new classes being added? > > In general, I wouldn't mind but I wonder if it makes sense here. DDC and > SPD are very special I2C uses where access should be limited, so a > seperate class makes sense IMO. HWMON has a specific name, but really > became "everything what people could hook to their I2C bus" these days. > So, if anything, we could think about renaming I2C_CLASS_HWMON to > I2C_CLASS_STANDARD or something (or at least add a comment about that in > i2c.h)? I'd think IIO devices fall into the default category. Please say > if you think different. If we'd add the IIO class, most drivers will > need patches to support IIO devices which would have worked otherwise, > so this change should be justified. The I2C_CLASS_STANDARD option sounds sensible - though perhaps the comment would be quicker ;) > > @Jean: Do you have anything to add? > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class 2014-12-31 10:25 ` Wolfram Sang 2015-01-01 12:27 ` Jonathan Cameron @ 2015-01-04 19:20 ` Jean Delvare 1 sibling, 0 replies; 29+ messages in thread From: Jean Delvare @ 2015-01-04 19:20 UTC (permalink / raw) To: Wolfram Sang; +Cc: Jonathan Cameron, Srinivas Pandruvada, linux-iio Hi Wolfram, First of all, happy new year :-) On Wed, 31 Dec 2014 11:25:54 +0100, Wolfram Sang wrote: > On Fri, Dec 26, 2014 at 12:37:36PM +0000, Jonathan Cameron wrote: > > On 15/12/14 21:19, Srinivas Pandruvada wrote: > > > To use i2c auto detect to work we need to have a non zero class. > > > The closest class is I2C_CLASS_HWMON, as it defined to be used > > > with all hw monitoring drivers. > > > > > > Also this class is already used by some iio driver, hid drivers, led > > > and misc drivers. So this is not new that this is used outside > > > hwmon drivers. > > > > > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > Been meaning to sort this out for a while. We really shouldn't be camping > > on the HWMON class (nor should anyone else). This is correct, side effects could be quite bad. > > Wolfram, do you mind new classes being added? > > In general, I wouldn't mind but I wonder if it makes sense here. DDC and > SPD are very special I2C uses where access should be limited, so a > seperate class makes sense IMO. HWMON has a specific name, but really > became "everything what people could hook to their I2C bus" these days. HWMON is there mainly for historical reasons, which still hold due to the inability of PC hardware vendors to list which I2C devices are connected to the SMBus (although this is changing, ACPI could help to some degree now.) > So, if anything, we could think about renaming I2C_CLASS_HWMON to > I2C_CLASS_STANDARD or something (or at least add a comment about that in > i2c.h)? I'd think IIO devices fall into the default category. Please say > if you think different. If we'd add the IIO class, most drivers will > need patches to support IIO devices which would have worked otherwise, > so this change should be justified. > > @Jean: Do you have anything to add? I2C_CLASS_STANDARD sounds like a rather bad idea to me. But really I miss the background for the discussion so it's hard for me to make an educated comment. Please keep in mind that I2C_CLASS_* is not about which class I2C devices (or even device drivers) belong to. It is about which drivers should actively _probe_ for their devices on which I2C bus segments. This is, in general, a bad idea and should be avoided as much as possible, in favor of enumeration. I2C device probing is inefficient, unreliable and dangerous by nature. The reason why we still do it for DDC and SPD is because the range of addresses is very limited, and probing is somewhat part of the specification. The reason why we do it for HWMON is because enumeration does not exist at the hardware level on popular platforms. For everything else we have backed out (analog and digital TV, in particular.) So I am wondering, which platforms are using IIO drivers and do not support device enumeration at the firmware / device tree level? -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-15 21:19 [PATCH 0/3] Enable AK8963 conneted via INV6500 Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class Srinivas Pandruvada @ 2014-12-15 21:19 ` Srinivas Pandruvada [not found] ` <1418678363-22437-4-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> 2 siblings, 1 reply; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-15 21:19 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Srinivas Pandruvada Using i2c auto detect feature and auto device creation feature, enumerate ak8975 device, by checking their presence. This is needed because when this device sits behind an i2c mux, there is no way to define i2c mux in ACPI. This will enable ak8975 on windows based tablets/laptops running Linux when connected via a mux. Since DT model already can define an i2c mux and devices connected to it, this feature is only enabled for ACPI. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> --- drivers/iio/magnetometer/ak8975.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c index 0d10a4b..c3455bd 100644 --- a/drivers/iio/magnetometer/ak8975.c +++ b/drivers/iio/magnetometer/ak8975.c @@ -820,6 +820,36 @@ static const struct i2c_device_id ak8975_id[] = { MODULE_DEVICE_TABLE(i2c, ak8975_id); +#if defined(CONFIG_ACPI) +static int ak8975_detect(struct i2c_client *temp_client, + struct i2c_board_info *info) +{ + struct i2c_adapter *adapter; + int i, j; + int ret; + + /* autodetect only when we are behind a mux */ + adapter = i2c_parent_is_i2c_adapter(temp_client->adapter); + if (!adapter) + return -ENODEV; + + for (i = 0; i < AK_MAX_TYPE; ++i) { + ret = ak8975_who_i_am(temp_client, i); + if (ret >= 0) { + for (j = 0; j < ARRAY_SIZE(ak8975_id) - 1; ++j) { + if (i == (int)ak8975_id[j].driver_data) { + strlcpy(info->type, ak8975_id[j].name, + I2C_NAME_SIZE); + return 0; + } + } + } + } + + return -ENODEV; +} +#endif + static const struct of_device_id ak8975_of_match[] = { { .compatible = "asahi-kasei,ak8975", }, { .compatible = "ak8975", }, @@ -841,6 +871,11 @@ static struct i2c_driver ak8975_driver = { }, .probe = ak8975_probe, .id_table = ak8975_id, +#if defined(CONFIG_ACPI) + .class = I2C_CLASS_HWMON, + .address_list = I2C_ADDRS(0x0C, 0x0D, 0x0E, 0x0F), + .detect = ak8975_detect, +#endif }; module_i2c_driver(ak8975_driver); -- 1.9.3 ^ permalink raw reply related [flat|nested] 29+ messages in thread
[parent not found: <1418678363-22437-4-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-15 21:19 ` [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI Srinivas Pandruvada @ 2014-12-18 16:28 ` Lars-Peter Clausen 0 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 16:28 UTC (permalink / raw) To: Srinivas Pandruvada, jic23-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang Added I2C to Cc. On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > Using i2c auto detect feature and auto device creation feature, > enumerate ak8975 device, by checking their presence. > This is needed because when this device sits behind an i2c mux, there > is no way to define i2c mux in ACPI. This will enable ak8975 on > windows based tablets/laptops running Linux when connected via a mux. > Since DT model already can define an i2c mux and devices connected to > it, this feature is only enabled for ACPI. > This is quite a bit of a hack. Did they decide to not include the device in the ACPI description at all or is there a special id for INV6050+AK8975? How does Windows decide whether there is a device or not? > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > --- > drivers/iio/magnetometer/ak8975.c | 35 +++++++++++++++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c > index 0d10a4b..c3455bd 100644 > --- a/drivers/iio/magnetometer/ak8975.c > +++ b/drivers/iio/magnetometer/ak8975.c > @@ -820,6 +820,36 @@ static const struct i2c_device_id ak8975_id[] = { > > MODULE_DEVICE_TABLE(i2c, ak8975_id); > > +#if defined(CONFIG_ACPI) > +static int ak8975_detect(struct i2c_client *temp_client, > + struct i2c_board_info *info) > +{ > + struct i2c_adapter *adapter; > + int i, j; > + int ret; > + > + /* autodetect only when we are behind a mux */ > + adapter = i2c_parent_is_i2c_adapter(temp_client->adapter); > + if (!adapter) > + return -ENODEV; > + > + for (i = 0; i < AK_MAX_TYPE; ++i) { > + ret = ak8975_who_i_am(temp_client, i); > + if (ret >= 0) { > + for (j = 0; j < ARRAY_SIZE(ak8975_id) - 1; ++j) { > + if (i == (int)ak8975_id[j].driver_data) { > + strlcpy(info->type, ak8975_id[j].name, > + I2C_NAME_SIZE); > + return 0; > + } > + } > + } > + } > + > + return -ENODEV; > +} > +#endif > + > static const struct of_device_id ak8975_of_match[] = { > { .compatible = "asahi-kasei,ak8975", }, > { .compatible = "ak8975", }, > @@ -841,6 +871,11 @@ static struct i2c_driver ak8975_driver = { > }, > .probe = ak8975_probe, > .id_table = ak8975_id, > +#if defined(CONFIG_ACPI) > + .class = I2C_CLASS_HWMON, > + .address_list = I2C_ADDRS(0x0C, 0x0D, 0x0E, 0x0F), > + .detect = ak8975_detect, In contrast to the commit message this is always enabled if the kernel contains ACPI support, not if the device is a ACPI device. > +#endif > }; > module_i2c_driver(ak8975_driver); > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 16:28 ` Lars-Peter Clausen 0 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 16:28 UTC (permalink / raw) To: Srinivas Pandruvada, jic23; +Cc: linux-iio, linux-i2c, Wolfram Sang Added I2C to Cc. On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > Using i2c auto detect feature and auto device creation feature, > enumerate ak8975 device, by checking their presence. > This is needed because when this device sits behind an i2c mux, there > is no way to define i2c mux in ACPI. This will enable ak8975 on > windows based tablets/laptops running Linux when connected via a mux. > Since DT model already can define an i2c mux and devices connected to > it, this feature is only enabled for ACPI. > This is quite a bit of a hack. Did they decide to not include the device in the ACPI description at all or is there a special id for INV6050+AK8975? How does Windows decide whether there is a device or not? > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > --- > drivers/iio/magnetometer/ak8975.c | 35 +++++++++++++++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c > index 0d10a4b..c3455bd 100644 > --- a/drivers/iio/magnetometer/ak8975.c > +++ b/drivers/iio/magnetometer/ak8975.c > @@ -820,6 +820,36 @@ static const struct i2c_device_id ak8975_id[] = { > > MODULE_DEVICE_TABLE(i2c, ak8975_id); > > +#if defined(CONFIG_ACPI) > +static int ak8975_detect(struct i2c_client *temp_client, > + struct i2c_board_info *info) > +{ > + struct i2c_adapter *adapter; > + int i, j; > + int ret; > + > + /* autodetect only when we are behind a mux */ > + adapter = i2c_parent_is_i2c_adapter(temp_client->adapter); > + if (!adapter) > + return -ENODEV; > + > + for (i = 0; i < AK_MAX_TYPE; ++i) { > + ret = ak8975_who_i_am(temp_client, i); > + if (ret >= 0) { > + for (j = 0; j < ARRAY_SIZE(ak8975_id) - 1; ++j) { > + if (i == (int)ak8975_id[j].driver_data) { > + strlcpy(info->type, ak8975_id[j].name, > + I2C_NAME_SIZE); > + return 0; > + } > + } > + } > + } > + > + return -ENODEV; > +} > +#endif > + > static const struct of_device_id ak8975_of_match[] = { > { .compatible = "asahi-kasei,ak8975", }, > { .compatible = "ak8975", }, > @@ -841,6 +871,11 @@ static struct i2c_driver ak8975_driver = { > }, > .probe = ak8975_probe, > .id_table = ak8975_id, > +#if defined(CONFIG_ACPI) > + .class = I2C_CLASS_HWMON, > + .address_list = I2C_ADDRS(0x0C, 0x0D, 0x0E, 0x0F), > + .detect = ak8975_detect, In contrast to the commit message this is always enabled if the kernel contains ACPI support, not if the device is a ACPI device. > +#endif > }; > module_i2c_driver(ak8975_driver); > > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <549300A5.5080904-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 16:28 ` Lars-Peter Clausen @ 2014-12-18 16:52 ` Srinivas Pandruvada -1 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 16:52 UTC (permalink / raw) To: Lars-Peter Clausen Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > Added I2C to Cc. > > On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > > Using i2c auto detect feature and auto device creation feature, > > enumerate ak8975 device, by checking their presence. > > This is needed because when this device sits behind an i2c mux, there > > is no way to define i2c mux in ACPI. This will enable ak8975 on > > windows based tablets/laptops running Linux when connected via a mux. > > Since DT model already can define an i2c mux and devices connected to > > it, this feature is only enabled for ACPI. > > > > This is quite a bit of a hack. Why? Auto detect is standard feature of i2c devices. This is using standard auto detect feature provided by the framework. > Did they decide to not include the device in > the ACPI description at all or is there a special id for INV6050+AK8975? This device needs has one combined id. Windows has a singe driver processing both as a combo device. > > How does Windows decide whether there is a device or not? > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > --- > > drivers/iio/magnetometer/ak8975.c | 35 +++++++++++++++++++++++++++++++++++ > > 1 file changed, 35 insertions(+) > > > > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c > > index 0d10a4b..c3455bd 100644 > > --- a/drivers/iio/magnetometer/ak8975.c > > +++ b/drivers/iio/magnetometer/ak8975.c > > @@ -820,6 +820,36 @@ static const struct i2c_device_id ak8975_id[] = { > > > > MODULE_DEVICE_TABLE(i2c, ak8975_id); > > > > +#if defined(CONFIG_ACPI) > > +static int ak8975_detect(struct i2c_client *temp_client, > > + struct i2c_board_info *info) > > +{ > > + struct i2c_adapter *adapter; > > + int i, j; > > + int ret; > > + > > + /* autodetect only when we are behind a mux */ > > + adapter = i2c_parent_is_i2c_adapter(temp_client->adapter); > > + if (!adapter) > > + return -ENODEV; > > + > > + for (i = 0; i < AK_MAX_TYPE; ++i) { > > + ret = ak8975_who_i_am(temp_client, i); > > + if (ret >= 0) { > > + for (j = 0; j < ARRAY_SIZE(ak8975_id) - 1; ++j) { > > + if (i == (int)ak8975_id[j].driver_data) { > > + strlcpy(info->type, ak8975_id[j].name, > > + I2C_NAME_SIZE); > > + return 0; > > + } > > + } > > + } > > + } > > + > > + return -ENODEV; > > +} > > +#endif > > + > > static const struct of_device_id ak8975_of_match[] = { > > { .compatible = "asahi-kasei,ak8975", }, > > { .compatible = "ak8975", }, > > @@ -841,6 +871,11 @@ static struct i2c_driver ak8975_driver = { > > }, > > .probe = ak8975_probe, > > .id_table = ak8975_id, > > +#if defined(CONFIG_ACPI) > > + .class = I2C_CLASS_HWMON, > > + .address_list = I2C_ADDRS(0x0C, 0x0D, 0x0E, 0x0F), > > + .detect = ak8975_detect, > > In contrast to the commit message this is always enabled if the kernel > contains ACPI support, not if the device is a ACPI device. Yes. You don't enable ACPI if you don't need it. It will bring in lots of builtin code if someone did that. > > > +#endif > > }; > > module_i2c_driver(ak8975_driver); > > > > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 16:52 ` Srinivas Pandruvada 0 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 16:52 UTC (permalink / raw) To: Lars-Peter Clausen; +Cc: jic23, linux-iio, linux-i2c, Wolfram Sang On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > Added I2C to Cc. > > On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > > Using i2c auto detect feature and auto device creation feature, > > enumerate ak8975 device, by checking their presence. > > This is needed because when this device sits behind an i2c mux, there > > is no way to define i2c mux in ACPI. This will enable ak8975 on > > windows based tablets/laptops running Linux when connected via a mux. > > Since DT model already can define an i2c mux and devices connected to > > it, this feature is only enabled for ACPI. > > > > This is quite a bit of a hack. Why? Auto detect is standard feature of i2c devices. This is using standard auto detect feature provided by the framework. > Did they decide to not include the device in > the ACPI description at all or is there a special id for INV6050+AK8975? This device needs has one combined id. Windows has a singe driver processing both as a combo device. > > How does Windows decide whether there is a device or not? > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > > --- > > drivers/iio/magnetometer/ak8975.c | 35 +++++++++++++++++++++++++++++++++++ > > 1 file changed, 35 insertions(+) > > > > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c > > index 0d10a4b..c3455bd 100644 > > --- a/drivers/iio/magnetometer/ak8975.c > > +++ b/drivers/iio/magnetometer/ak8975.c > > @@ -820,6 +820,36 @@ static const struct i2c_device_id ak8975_id[] = { > > > > MODULE_DEVICE_TABLE(i2c, ak8975_id); > > > > +#if defined(CONFIG_ACPI) > > +static int ak8975_detect(struct i2c_client *temp_client, > > + struct i2c_board_info *info) > > +{ > > + struct i2c_adapter *adapter; > > + int i, j; > > + int ret; > > + > > + /* autodetect only when we are behind a mux */ > > + adapter = i2c_parent_is_i2c_adapter(temp_client->adapter); > > + if (!adapter) > > + return -ENODEV; > > + > > + for (i = 0; i < AK_MAX_TYPE; ++i) { > > + ret = ak8975_who_i_am(temp_client, i); > > + if (ret >= 0) { > > + for (j = 0; j < ARRAY_SIZE(ak8975_id) - 1; ++j) { > > + if (i == (int)ak8975_id[j].driver_data) { > > + strlcpy(info->type, ak8975_id[j].name, > > + I2C_NAME_SIZE); > > + return 0; > > + } > > + } > > + } > > + } > > + > > + return -ENODEV; > > +} > > +#endif > > + > > static const struct of_device_id ak8975_of_match[] = { > > { .compatible = "asahi-kasei,ak8975", }, > > { .compatible = "ak8975", }, > > @@ -841,6 +871,11 @@ static struct i2c_driver ak8975_driver = { > > }, > > .probe = ak8975_probe, > > .id_table = ak8975_id, > > +#if defined(CONFIG_ACPI) > > + .class = I2C_CLASS_HWMON, > > + .address_list = I2C_ADDRS(0x0C, 0x0D, 0x0E, 0x0F), > > + .detect = ak8975_detect, > > In contrast to the commit message this is always enabled if the kernel > contains ACPI support, not if the device is a ACPI device. Yes. You don't enable ACPI if you don't need it. It will bring in lots of builtin code if someone did that. > > > +#endif > > }; > > module_i2c_driver(ak8975_driver); > > > > > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1418921521.740.282.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 16:52 ` Srinivas Pandruvada @ 2014-12-18 17:05 ` Lars-Peter Clausen -1 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 17:05 UTC (permalink / raw) To: Srinivas Pandruvada Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >> Added I2C to Cc. >> >> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>> Using i2c auto detect feature and auto device creation feature, >>> enumerate ak8975 device, by checking their presence. >>> This is needed because when this device sits behind an i2c mux, there >>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>> windows based tablets/laptops running Linux when connected via a mux. >>> Since DT model already can define an i2c mux and devices connected to >>> it, this feature is only enabled for ACPI. >>> >> >> This is quite a bit of a hack. > Why? > Auto detect is standard feature of i2c devices. This is using standard > auto detect feature provided by the framework. Auto detect is ugly, slow and unreliable, it's kind of like the last straw if nothing else works. Autodetect will be executed for every adapter with every device that supports auto detection, so you want to keep the amount of devices that do auto detection to a minimum in order to avoid both false positives and reduce boot time. >> Did they decide to not include the device in >> the ACPI description at all or is there a special id for INV6050+AK8975? > This device needs has one combined id. Windows has a singe driver > processing both as a combo device. Ok, then use the combined id to instantiate INV6050+AK8975. - Lars ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 17:05 ` Lars-Peter Clausen 0 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 17:05 UTC (permalink / raw) To: Srinivas Pandruvada; +Cc: jic23, linux-iio, linux-i2c, Wolfram Sang On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >> Added I2C to Cc. >> >> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>> Using i2c auto detect feature and auto device creation feature, >>> enumerate ak8975 device, by checking their presence. >>> This is needed because when this device sits behind an i2c mux, there >>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>> windows based tablets/laptops running Linux when connected via a mux. >>> Since DT model already can define an i2c mux and devices connected to >>> it, this feature is only enabled for ACPI. >>> >> >> This is quite a bit of a hack. > Why? > Auto detect is standard feature of i2c devices. This is using standard > auto detect feature provided by the framework. Auto detect is ugly, slow and unreliable, it's kind of like the last straw if nothing else works. Autodetect will be executed for every adapter with every device that supports auto detection, so you want to keep the amount of devices that do auto detection to a minimum in order to avoid both false positives and reduce boot time. >> Did they decide to not include the device in >> the ACPI description at all or is there a special id for INV6050+AK8975? > This device needs has one combined id. Windows has a singe driver > processing both as a combo device. Ok, then use the combined id to instantiate INV6050+AK8975. - Lars ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <54930965.3030008-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 17:05 ` Lars-Peter Clausen @ 2014-12-18 17:30 ` Srinivas Pandruvada -1 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 17:30 UTC (permalink / raw) To: Lars-Peter Clausen Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: > On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > > On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > >> Added I2C to Cc. > >> > >> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > >>> Using i2c auto detect feature and auto device creation feature, > >>> enumerate ak8975 device, by checking their presence. > >>> This is needed because when this device sits behind an i2c mux, there > >>> is no way to define i2c mux in ACPI. This will enable ak8975 on > >>> windows based tablets/laptops running Linux when connected via a mux. > >>> Since DT model already can define an i2c mux and devices connected to > >>> it, this feature is only enabled for ACPI. > >>> > >> > >> This is quite a bit of a hack. > > Why? > > Auto detect is standard feature of i2c devices. This is using standard > > auto detect feature provided by the framework. > > Auto detect is ugly, slow and unreliable, it's kind of like the last straw > if nothing else works. That is true here. You can't enumerate this device by ACPI. As discussed before we created i2c mux in inv6050 so that we can use AK8975 in bypass mode. I added some API to create i2c device on this mux, which Wolfram didn't like. He wanted to enumerate using existing mechanisms. > > Autodetect will be executed for every adapter with every device that > supports auto detection, so you want to keep the amount of devices that do > auto detection to a minimum in order to avoid both false positives and > reduce boot time. > > > >> Did they decide to not include the device in > >> the ACPI description at all or is there a special id for INV6050+AK8975? > > This device needs has one combined id. Windows has a singe driver > > processing both as a combo device. > > Ok, then use the combined id to instantiate INV6050+AK8975. No. The i2c address address is already consumed by INV6050 driver (which is valid for INV6050 not AK8975). > > - Lars > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 17:30 ` Srinivas Pandruvada 0 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 17:30 UTC (permalink / raw) To: Lars-Peter Clausen; +Cc: jic23, linux-iio, linux-i2c, Wolfram Sang On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: > On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > > On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > >> Added I2C to Cc. > >> > >> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > >>> Using i2c auto detect feature and auto device creation feature, > >>> enumerate ak8975 device, by checking their presence. > >>> This is needed because when this device sits behind an i2c mux, there > >>> is no way to define i2c mux in ACPI. This will enable ak8975 on > >>> windows based tablets/laptops running Linux when connected via a mux. > >>> Since DT model already can define an i2c mux and devices connected to > >>> it, this feature is only enabled for ACPI. > >>> > >> > >> This is quite a bit of a hack. > > Why? > > Auto detect is standard feature of i2c devices. This is using standard > > auto detect feature provided by the framework. > > Auto detect is ugly, slow and unreliable, it's kind of like the last straw > if nothing else works. That is true here. You can't enumerate this device by ACPI. As discussed before we created i2c mux in inv6050 so that we can use AK8975 in bypass mode. I added some API to create i2c device on this mux, which Wolfram didn't like. He wanted to enumerate using existing mechanisms. > > Autodetect will be executed for every adapter with every device that > supports auto detection, so you want to keep the amount of devices that do > auto detection to a minimum in order to avoid both false positives and > reduce boot time. > > > >> Did they decide to not include the device in > >> the ACPI description at all or is there a special id for INV6050+AK8975? > > This device needs has one combined id. Windows has a singe driver > > processing both as a combo device. > > Ok, then use the combined id to instantiate INV6050+AK8975. No. The i2c address address is already consumed by INV6050 driver (which is valid for INV6050 not AK8975). > > - Lars > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1418923812.4459.8.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 17:30 ` Srinivas Pandruvada @ 2014-12-18 17:54 ` Lars-Peter Clausen -1 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 17:54 UTC (permalink / raw) To: Srinivas Pandruvada Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: >> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: >>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >>>> Added I2C to Cc. >>>> >>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>>>> Using i2c auto detect feature and auto device creation feature, >>>>> enumerate ak8975 device, by checking their presence. >>>>> This is needed because when this device sits behind an i2c mux, there >>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>>>> windows based tablets/laptops running Linux when connected via a mux. >>>>> Since DT model already can define an i2c mux and devices connected to >>>>> it, this feature is only enabled for ACPI. >>>>> >>>> >>>> This is quite a bit of a hack. >>> Why? >>> Auto detect is standard feature of i2c devices. This is using standard >>> auto detect feature provided by the framework. >> >> Auto detect is ugly, slow and unreliable, it's kind of like the last straw >> if nothing else works. > That is true here. You can't enumerate this device by ACPI. As discussed > before we created i2c mux in inv6050 so that we can use AK8975 in bypass > mode. I added some API to create i2c device on this mux, which Wolfram > didn't like. He wanted to enumerate using existing mechanisms. If there is only a single ACPI ID that says this is a INV6050 with a AK8975 attached then the way to handle this is to have a driver that binds to that id and creates both devices. - Lars ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 17:54 ` Lars-Peter Clausen 0 siblings, 0 replies; 29+ messages in thread From: Lars-Peter Clausen @ 2014-12-18 17:54 UTC (permalink / raw) To: Srinivas Pandruvada; +Cc: jic23, linux-iio, linux-i2c, Wolfram Sang On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: >> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: >>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >>>> Added I2C to Cc. >>>> >>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>>>> Using i2c auto detect feature and auto device creation feature, >>>>> enumerate ak8975 device, by checking their presence. >>>>> This is needed because when this device sits behind an i2c mux, there >>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>>>> windows based tablets/laptops running Linux when connected via a mux. >>>>> Since DT model already can define an i2c mux and devices connected to >>>>> it, this feature is only enabled for ACPI. >>>>> >>>> >>>> This is quite a bit of a hack. >>> Why? >>> Auto detect is standard feature of i2c devices. This is using standard >>> auto detect feature provided by the framework. >> >> Auto detect is ugly, slow and unreliable, it's kind of like the last straw >> if nothing else works. > That is true here. You can't enumerate this device by ACPI. As discussed > before we created i2c mux in inv6050 so that we can use AK8975 in bypass > mode. I added some API to create i2c device on this mux, which Wolfram > didn't like. He wanted to enumerate using existing mechanisms. If there is only a single ACPI ID that says this is a INV6050 with a AK8975 attached then the way to handle this is to have a driver that binds to that id and creates both devices. - Lars ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <549314C4.8090001-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 17:54 ` Lars-Peter Clausen @ 2014-12-18 18:00 ` Srinivas Pandruvada -1 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 18:00 UTC (permalink / raw) To: Lars-Peter Clausen Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On Thu, 2014-12-18 at 18:54 +0100, Lars-Peter Clausen wrote: > On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: > > On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: > >> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > >>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > >>>> Added I2C to Cc. > >>>> > >>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > >>>>> Using i2c auto detect feature and auto device creation feature, > >>>>> enumerate ak8975 device, by checking their presence. > >>>>> This is needed because when this device sits behind an i2c mux, there > >>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on > >>>>> windows based tablets/laptops running Linux when connected via a mux. > >>>>> Since DT model already can define an i2c mux and devices connected to > >>>>> it, this feature is only enabled for ACPI. > >>>>> > >>>> > >>>> This is quite a bit of a hack. > >>> Why? > >>> Auto detect is standard feature of i2c devices. This is using standard > >>> auto detect feature provided by the framework. > >> > >> Auto detect is ugly, slow and unreliable, it's kind of like the last straw > >> if nothing else works. > > That is true here. You can't enumerate this device by ACPI. As discussed > > before we created i2c mux in inv6050 so that we can use AK8975 in bypass > > mode. I added some API to create i2c device on this mux, which Wolfram > > didn't like. He wanted to enumerate using existing mechanisms. > > If there is only a single ACPI ID that says this is a INV6050 with a AK8975 > attached then the way to handle this is to have a driver that binds to that id > and creates both devices. Which address you will create device also adapter here is i2c mux created by inv6050? You don't know i2c address of AK8975. To know AK8975 i2c address, even ugly hack to parse propriety vendor ACPI data, which will change between to manufacturer. > > - Lars > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-18 18:00 ` Srinivas Pandruvada 0 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2014-12-18 18:00 UTC (permalink / raw) To: Lars-Peter Clausen; +Cc: jic23, linux-iio, linux-i2c, Wolfram Sang On Thu, 2014-12-18 at 18:54 +0100, Lars-Peter Clausen wrote: > On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: > > On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: > >> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: > >>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: > >>>> Added I2C to Cc. > >>>> > >>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: > >>>>> Using i2c auto detect feature and auto device creation feature, > >>>>> enumerate ak8975 device, by checking their presence. > >>>>> This is needed because when this device sits behind an i2c mux, there > >>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on > >>>>> windows based tablets/laptops running Linux when connected via a mux. > >>>>> Since DT model already can define an i2c mux and devices connected to > >>>>> it, this feature is only enabled for ACPI. > >>>>> > >>>> > >>>> This is quite a bit of a hack. > >>> Why? > >>> Auto detect is standard feature of i2c devices. This is using standard > >>> auto detect feature provided by the framework. > >> > >> Auto detect is ugly, slow and unreliable, it's kind of like the last straw > >> if nothing else works. > > That is true here. You can't enumerate this device by ACPI. As discussed > > before we created i2c mux in inv6050 so that we can use AK8975 in bypass > > mode. I added some API to create i2c device on this mux, which Wolfram > > didn't like. He wanted to enumerate using existing mechanisms. > > If there is only a single ACPI ID that says this is a INV6050 with a AK8975 > attached then the way to handle this is to have a driver that binds to that id > and creates both devices. Which address you will create device also adapter here is i2c mux created by inv6050? You don't know i2c address of AK8975. To know AK8975 i2c address, even ugly hack to parse propriety vendor ACPI data, which will change between to manufacturer. > > - Lars > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1418925641.4459.11.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-18 18:00 ` Srinivas Pandruvada @ 2014-12-26 11:53 ` Jonathan Cameron -1 siblings, 0 replies; 29+ messages in thread From: Jonathan Cameron @ 2014-12-26 11:53 UTC (permalink / raw) To: Srinivas Pandruvada, Lars-Peter Clausen Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang On 18/12/14 18:00, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 18:54 +0100, Lars-Peter Clausen wrote: >> On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: >>> On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: >>>> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: >>>>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >>>>>> Added I2C to Cc. >>>>>> >>>>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>>>>>> Using i2c auto detect feature and auto device creation feature, >>>>>>> enumerate ak8975 device, by checking their presence. >>>>>>> This is needed because when this device sits behind an i2c mux, there >>>>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>>>>>> windows based tablets/laptops running Linux when connected via a mux. >>>>>>> Since DT model already can define an i2c mux and devices connected to >>>>>>> it, this feature is only enabled for ACPI. >>>>>>> >>>>>> >>>>>> This is quite a bit of a hack. >>>>> Why? >>>>> Auto detect is standard feature of i2c devices. This is using standard >>>>> auto detect feature provided by the framework. >>>> >>>> Auto detect is ugly, slow and unreliable, it's kind of like the last straw >>>> if nothing else works. >>> That is true here. You can't enumerate this device by ACPI. As discussed >>> before we created i2c mux in inv6050 so that we can use AK8975 in bypass >>> mode. I added some API to create i2c device on this mux, which Wolfram >>> didn't like. He wanted to enumerate using existing mechanisms. >> >> If there is only a single ACPI ID that says this is a INV6050 with a AK8975 >> attached then the way to handle this is to have a driver that binds to that id >> and creates both devices. > Which address you will create device also adapter here is i2c mux > created by inv6050? You don't know i2c address of AK8975. To know AK8975 > i2c address, even ugly hack to parse propriety vendor ACPI data, which > will change between to manufacturer. > This is odd enough, that I'd like a wider range of views on it. Wolfram - was this the approach you had in mind? >> >> - Lars >> > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2014-12-26 11:53 ` Jonathan Cameron 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Cameron @ 2014-12-26 11:53 UTC (permalink / raw) To: Srinivas Pandruvada, Lars-Peter Clausen Cc: linux-iio, linux-i2c, Wolfram Sang On 18/12/14 18:00, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 18:54 +0100, Lars-Peter Clausen wrote: >> On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: >>> On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: >>>> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: >>>>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >>>>>> Added I2C to Cc. >>>>>> >>>>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>>>>>> Using i2c auto detect feature and auto device creation feature, >>>>>>> enumerate ak8975 device, by checking their presence. >>>>>>> This is needed because when this device sits behind an i2c mux, there >>>>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>>>>>> windows based tablets/laptops running Linux when connected via a mux. >>>>>>> Since DT model already can define an i2c mux and devices connected to >>>>>>> it, this feature is only enabled for ACPI. >>>>>>> >>>>>> >>>>>> This is quite a bit of a hack. >>>>> Why? >>>>> Auto detect is standard feature of i2c devices. This is using standard >>>>> auto detect feature provided by the framework. >>>> >>>> Auto detect is ugly, slow and unreliable, it's kind of like the last straw >>>> if nothing else works. >>> That is true here. You can't enumerate this device by ACPI. As discussed >>> before we created i2c mux in inv6050 so that we can use AK8975 in bypass >>> mode. I added some API to create i2c device on this mux, which Wolfram >>> didn't like. He wanted to enumerate using existing mechanisms. >> >> If there is only a single ACPI ID that says this is a INV6050 with a AK8975 >> attached then the way to handle this is to have a driver that binds to that id >> and creates both devices. > Which address you will create device also adapter here is i2c mux > created by inv6050? You don't know i2c address of AK8975. To know AK8975 > i2c address, even ugly hack to parse propriety vendor ACPI data, which > will change between to manufacturer. > This is odd enough, that I'd like a wider range of views on it. Wolfram - was this the approach you had in mind? >> >> - Lars >> > > ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <549D4C1F.6050907-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2014-12-26 11:53 ` Jonathan Cameron @ 2015-01-08 16:40 ` Wolfram Sang -1 siblings, 0 replies; 29+ messages in thread From: Wolfram Sang @ 2015-01-08 16:40 UTC (permalink / raw) To: Jonathan Cameron Cc: Srinivas Pandruvada, Lars-Peter Clausen, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 181 bytes --] > This is odd enough, that I'd like a wider range of views on it. > > Wolfram - was this the approach you had in mind? Sorry, too busy with other stuff at this moment :( [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2015-01-08 16:40 ` Wolfram Sang 0 siblings, 0 replies; 29+ messages in thread From: Wolfram Sang @ 2015-01-08 16:40 UTC (permalink / raw) To: Jonathan Cameron Cc: Srinivas Pandruvada, Lars-Peter Clausen, linux-iio, linux-i2c [-- Attachment #1: Type: text/plain, Size: 181 bytes --] > This is odd enough, that I'd like a wider range of views on it. > > Wolfram - was this the approach you had in mind? Sorry, too busy with other stuff at this moment :( [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI 2015-01-08 16:40 ` Wolfram Sang @ 2015-01-08 16:54 ` Srinivas Pandruvada -1 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2015-01-08 16:54 UTC (permalink / raw) To: Wolfram Sang Cc: Jonathan Cameron, Lars-Peter Clausen, linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA On Thu, 2015-01-08 at 17:40 +0100, Wolfram Sang wrote: > > This is odd enough, that I'd like a wider range of views on it. > > > > Wolfram - was this the approach you had in mind? > > Sorry, too busy with other stuff at this moment :( > I will find some other way without using auto detect feature. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI @ 2015-01-08 16:54 ` Srinivas Pandruvada 0 siblings, 0 replies; 29+ messages in thread From: Srinivas Pandruvada @ 2015-01-08 16:54 UTC (permalink / raw) To: Wolfram Sang; +Cc: Jonathan Cameron, Lars-Peter Clausen, linux-iio, linux-i2c On Thu, 2015-01-08 at 17:40 +0100, Wolfram Sang wrote: > > This is odd enough, that I'd like a wider range of views on it. > > > > Wolfram - was this the approach you had in mind? > > Sorry, too busy with other stuff at this moment :( > I will find some other way without using auto detect feature. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration @ 2014-03-11 21:04 Srinivas Pandruvada 2014-03-15 15:56 ` Jonathan Cameron 0 siblings, 1 reply; 29+ messages in thread From: Srinivas Pandruvada @ 2014-03-11 21:04 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Srinivas Pandruvada Added changes so that the module can be enumerated via ACPI. Also if there is no platform data available, it will use a default orientation data. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c index df7f1e1..4a76697 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c @@ -24,8 +24,16 @@ #include <linux/kfifo.h> #include <linux/spinlock.h> #include <linux/iio/iio.h> +#include <linux/acpi.h> #include "inv_mpu_iio.h" +/* Define some default platform data, if not supplied */ +static struct inv_mpu6050_platform_data inv_def_platform_data = { + .orientation = {-1, 0, 0, + 0, 1, 0, + 0, 0, -1 } +}; + /* * this is the gyro scale translated from dynamic range plus/minus * {250, 500, 1000, 2000} to rad/s @@ -662,6 +670,7 @@ static int inv_mpu_probe(struct i2c_client *client, struct inv_mpu6050_state *st; struct iio_dev *indio_dev; int result; + char *name; if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_I2C_BLOCK)) @@ -673,7 +682,10 @@ static int inv_mpu_probe(struct i2c_client *client, st = iio_priv(indio_dev); st->client = client; - st->plat_data = *(struct inv_mpu6050_platform_data + if (!dev_get_platdata(&client->dev)) + st->plat_data = inv_def_platform_data; + else + st->plat_data = *(struct inv_mpu6050_platform_data *)dev_get_platdata(&client->dev); /* power is turned on inside check chip type*/ result = inv_check_and_setup_chip(st, id); @@ -689,7 +701,14 @@ static int inv_mpu_probe(struct i2c_client *client, i2c_set_clientdata(client, indio_dev); indio_dev->dev.parent = &client->dev; - indio_dev->name = id->name; + if (id && id->name) + name = (char *)id->name; + else { + name = (char *)dev_name(&client->dev); + if (!name) + dev_err(&client->dev, "No iio dev name\n"); + } + indio_dev->name = name; indio_dev->channels = inv_mpu_channels; indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels); @@ -770,12 +789,19 @@ static const struct i2c_device_id inv_mpu_id[] = { MODULE_DEVICE_TABLE(i2c, inv_mpu_id); +static const struct acpi_device_id inv_acpi_match[] = { + {"INVN6500", 0}, + { }, +}; +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 = { .owner = THIS_MODULE, + .acpi_match_table = ACPI_PTR(inv_acpi_match), .name = "inv-mpu6050", .pm = INV_MPU6050_PMOPS, }, -- 1.7.11.7 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration 2014-03-11 21:04 [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada @ 2014-03-15 15:56 ` Jonathan Cameron 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Cameron @ 2014-03-15 15:56 UTC (permalink / raw) To: Srinivas Pandruvada; +Cc: linux-iio On 11/03/14 21:04, Srinivas Pandruvada wrote: > Added changes so that the module can be enumerated via ACPI. > Also if there is no platform data available, it will use a default > orientation data. > You add the mpu6500 to this driver? If so, that needs documenting etc. > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > --- > drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > index df7f1e1..4a76697 100644 > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c > @@ -24,8 +24,16 @@ > #include <linux/kfifo.h> > #include <linux/spinlock.h> > #include <linux/iio/iio.h> > +#include <linux/acpi.h> > #include "inv_mpu_iio.h" > > +/* Define some default platform data, if not supplied */ > +static struct inv_mpu6050_platform_data inv_def_platform_data = { > + .orientation = {-1, 0, 0, > + 0, 1, 0, > + 0, 0, -1 } > +}; > + > /* > * this is the gyro scale translated from dynamic range plus/minus > * {250, 500, 1000, 2000} to rad/s > @@ -662,6 +670,7 @@ static int inv_mpu_probe(struct i2c_client *client, > struct inv_mpu6050_state *st; > struct iio_dev *indio_dev; > int result; > + char *name; > > if (!i2c_check_functionality(client->adapter, > I2C_FUNC_SMBUS_I2C_BLOCK)) > @@ -673,7 +682,10 @@ static int inv_mpu_probe(struct i2c_client *client, > > st = iio_priv(indio_dev); > st->client = client; > - st->plat_data = *(struct inv_mpu6050_platform_data > + if (!dev_get_platdata(&client->dev)) > + st->plat_data = inv_def_platform_data; > + else > + st->plat_data = *(struct inv_mpu6050_platform_data > *)dev_get_platdata(&client->dev); > /* power is turned on inside check chip type*/ > result = inv_check_and_setup_chip(st, id); > @@ -689,7 +701,14 @@ static int inv_mpu_probe(struct i2c_client *client, > > i2c_set_clientdata(client, indio_dev); > indio_dev->dev.parent = &client->dev; > - indio_dev->name = id->name; > + if (id && id->name) As far as I know, there isn't a way for id->name to be null is there? > + name = (char *)id->name; > + else { > + name = (char *)dev_name(&client->dev); > + if (!name) > + dev_err(&client->dev, "No iio dev name\n"); If it's an error, then you out to return an error from here rather than carrying on. > + } > + indio_dev->name = name; > indio_dev->channels = inv_mpu_channels; > indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels); > > @@ -770,12 +789,19 @@ static const struct i2c_device_id inv_mpu_id[] = { > > MODULE_DEVICE_TABLE(i2c, inv_mpu_id); > > +static const struct acpi_device_id inv_acpi_match[] = { > + {"INVN6500", 0}, For i2c we have the second field as INV_MPU6050. Now I'll admit it doesn't seem to be used for anything, but it would be nice to be consistent. > + { }, > +}; > +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 = { > .owner = THIS_MODULE, > + .acpi_match_table = ACPI_PTR(inv_acpi_match), > .name = "inv-mpu6050", > .pm = INV_MPU6050_PMOPS, > }, > ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2015-01-08 16:54 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-15 21:19 [PATCH 0/3] Enable AK8963 conneted via INV6500 Srinivas Pandruvada 2014-12-15 21:19 ` [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada 2014-12-26 12:39 ` Jonathan Cameron 2014-12-15 21:19 ` [PATCH 2/3] iio: imu: inv_mpu6050: Added adapter class Srinivas Pandruvada 2014-12-26 12:37 ` Jonathan Cameron 2014-12-31 10:25 ` Wolfram Sang 2015-01-01 12:27 ` Jonathan Cameron 2015-01-04 19:20 ` Jean Delvare 2014-12-15 21:19 ` [PATCH 3/3] iio: ak8975: Added autodetect feature for ACPI Srinivas Pandruvada [not found] ` <1418678363-22437-4-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> 2014-12-18 16:28 ` Lars-Peter Clausen 2014-12-18 16:28 ` Lars-Peter Clausen [not found] ` <549300A5.5080904-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> 2014-12-18 16:52 ` Srinivas Pandruvada 2014-12-18 16:52 ` Srinivas Pandruvada [not found] ` <1418921521.740.282.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org> 2014-12-18 17:05 ` Lars-Peter Clausen 2014-12-18 17:05 ` Lars-Peter Clausen [not found] ` <54930965.3030008-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> 2014-12-18 17:30 ` Srinivas Pandruvada 2014-12-18 17:30 ` Srinivas Pandruvada [not found] ` <1418923812.4459.8.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org> 2014-12-18 17:54 ` Lars-Peter Clausen 2014-12-18 17:54 ` Lars-Peter Clausen [not found] ` <549314C4.8090001-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> 2014-12-18 18:00 ` Srinivas Pandruvada 2014-12-18 18:00 ` Srinivas Pandruvada [not found] ` <1418925641.4459.11.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org> 2014-12-26 11:53 ` Jonathan Cameron 2014-12-26 11:53 ` Jonathan Cameron [not found] ` <549D4C1F.6050907-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2015-01-08 16:40 ` Wolfram Sang 2015-01-08 16:40 ` Wolfram Sang 2015-01-08 16:54 ` Srinivas Pandruvada 2015-01-08 16:54 ` Srinivas Pandruvada -- strict thread matches above, loose matches on Subject: below -- 2014-03-11 21:04 [PATCH 1/3] iio: imu: inv_mpu6050: ACPI enumeration Srinivas Pandruvada 2014-03-15 15:56 ` Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.