diff mbox

[RFC,3/3] iio: imu: bme680: Add ACPI support

Message ID 1529562877-9357-4-git-send-email-himanshujha199640@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Himanshu Jha June 21, 2018, 6:34 a.m. UTC 
Add support to probe the bme680 sensor on the i2c bus using
ACPI.

Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
 drivers/iio/imu/bme680/bme680_core.c | 15 +++++++++++++++
 drivers/iio/imu/bme680/bme680_i2c.c  |  6 ++++++
 2 files changed, 21 insertions(+)

Comments

Jonathan Cameron June 22, 2018, 1:44 p.m. UTC | #1 
On Thu, 21 Jun 2018 12:04:37 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> Add support to probe the bme680 sensor on the i2c bus using
> ACPI.
> 
> Cc: Daniel Baluta <daniel.baluta@gmail.com>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>

This looks fine.  Do we know for sure that they use that ACPI
ID?  For these sorts of devices, it's fairly common to have entirely
random ids presented.   Also, I'm a little curious to know, what
ACPI based device has one of these?

Jonathan

> ---
>  drivers/iio/imu/bme680/bme680_core.c | 15 +++++++++++++++
>  drivers/iio/imu/bme680/bme680_i2c.c  |  6 ++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/iio/imu/bme680/bme680_core.c b/drivers/iio/imu/bme680/bme680_core.c
> index 05712de..a891b1f 100644
> --- a/drivers/iio/imu/bme680/bme680_core.c
> +++ b/drivers/iio/imu/bme680/bme680_core.c
> @@ -3,6 +3,7 @@
>   *
>   * IIO core driver - I2C & SPI bus support
>   */
> +#include <linux/acpi.h>
>  #include <linux/iio/iio.h>
>  #include <linux/module.h>
>  #include <linux/regmap.h>
> @@ -445,6 +446,17 @@ static int bme680_chip_init(struct bme680_data *data, bool use_spi)
>  	return 0;
>  }
>  
> +static const char *bme680_match_acpi_device(struct device *dev)
> +{
> +	const struct acpi_device_id *id;
> +
> +	id = acpi_match_device(dev->driver->acpi_match_table, dev);
> +	if (!id)
> +		return NULL;
> +
> +	return dev_name(dev);
> +}
> +
>  static const struct bme680_chip_info bme680_chip_info = {
>  	.oversampling_temp_avail = bme680_oversampling_avail,
>  	.num_oversampling_temp_avail = ARRAY_SIZE(bme680_oversampling_avail),
> @@ -480,6 +492,9 @@ int bme680_core_probe(struct device *dev, struct regmap *regmap,
>  	if (ret < 0)
>  		return ret;
>  
> +	if (!name && ACPI_HANDLE(dev))
> +		name = bme680_match_acpi_device(dev);
> +
>  	indio_dev->dev.parent = dev;
>  	indio_dev->name = name;
>  	indio_dev->channels = bme680_channels;
> diff --git a/drivers/iio/imu/bme680/bme680_i2c.c b/drivers/iio/imu/bme680/bme680_i2c.c
> index 1c8223e..2807085 100644
> --- a/drivers/iio/imu/bme680/bme680_i2c.c
> +++ b/drivers/iio/imu/bme680/bme680_i2c.c
> @@ -3,6 +3,7 @@
>   *	- 0x76 if SDO is pulled to GND
>   *	- 0x77 if SDO is pulled to VDDIO
>   */
> +#include <linux/acpi.h>
>  #include <linux/i2c.h>
>  #include <linux/module.h>
>  #include <linux/regmap.h>
> @@ -41,6 +42,11 @@ static const struct i2c_device_id bme680_i2c_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, bme680_i2c_id);
>  
> +static const struct acpi_device_id bme680_acpi_match[] = {
> +	{"BME0680", 0},
> +	{},
> +};
> +
>  static struct i2c_driver bme680_i2c_driver = {
>  	.driver = {
>  		.name = "bme680_i2c",


--
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
Daniel Baluta June 25, 2018, 7:40 a.m. UTC | #2 
On Fri, Jun 22, 2018 at 4:44 PM, Jonathan Cameron
<jonathan.cameron@huawei.com> wrote:
> On Thu, 21 Jun 2018 12:04:37 +0530
> Himanshu Jha <himanshujha199640@gmail.com> wrote:
>
>> Add support to probe the bme680 sensor on the i2c bus using
>> ACPI.
>>
>> Cc: Daniel Baluta <daniel.baluta@gmail.com>
>> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
>
> This looks fine.  Do we know for sure that they use that ACPI
> ID?  For these sorts of devices, it's fairly common to have entirely
> random ids presented.   Also, I'm a little curious to know, what
> ACPI based device has one of these?

Hi Jonathan,

I am not aware of any ACPI device using our chosen ID. We just
picked BME0680 based on previous drivers from Bosch.

It is useful to enumerate the sensor via ACPI because our
qemu testing setup uses ACPI.

thanks,
Daniel.
--
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
Jonathan Cameron June 25, 2018, 10:06 a.m. UTC | #3 
On 25 June 2018 08:40:08 BST, Daniel Baluta <daniel.baluta@gmail.com> wrote:
>On Fri, Jun 22, 2018 at 4:44 PM, Jonathan Cameron
><jonathan.cameron@huawei.com> wrote:
>> On Thu, 21 Jun 2018 12:04:37 +0530
>> Himanshu Jha <himanshujha199640@gmail.com> wrote:
>>
>>> Add support to probe the bme680 sensor on the i2c bus using
>>> ACPI.
>>>
>>> Cc: Daniel Baluta <daniel.baluta@gmail.com>
>>> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
>>
>> This looks fine.  Do we know for sure that they use that ACPI
>> ID?  For these sorts of devices, it's fairly common to have entirely
>> random ids presented.   Also, I'm a little curious to know, what
>> ACPI based device has one of these?
>
>Hi Jonathan,
>
>I am not aware of any ACPI device using our chosen ID. We just
>picked BME0680 based on previous drivers from Bosch.
>
>It is useful to enumerate the sensor via ACPI because our
>qemu testing setup uses ACPI.

Cool. Any docs on that setup?  Would be useful blog post if easy to do.

J
>
>thanks,
>Daniel.
>--
>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
Daniel Baluta June 29, 2018, 1:02 p.m. UTC | #4 
On Mon, Jun 25, 2018 at 1:06 PM, Jonathan Cameron
<jic23@jic23.retrosnub.co.uk> wrote:
>
>
> On 25 June 2018 08:40:08 BST, Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>On Fri, Jun 22, 2018 at 4:44 PM, Jonathan Cameron
>><jonathan.cameron@huawei.com> wrote:
>>> On Thu, 21 Jun 2018 12:04:37 +0530
>>> Himanshu Jha <himanshujha199640@gmail.com> wrote:
>>>
>>>> Add support to probe the bme680 sensor on the i2c bus using
>>>> ACPI.
>>>>
>>>> Cc: Daniel Baluta <daniel.baluta@gmail.com>
>>>> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
>>>
>>> This looks fine.  Do we know for sure that they use that ACPI
>>> ID?  For these sorts of devices, it's fairly common to have entirely
>>> random ids presented.   Also, I'm a little curious to know, what
>>> ACPI based device has one of these?
>>
>>Hi Jonathan,
>>
>>I am not aware of any ACPI device using our chosen ID. We just
>>picked BME0680 based on previous drivers from Bosch.
>>
>>It is useful to enumerate the sensor via ACPI because our
>>qemu testing setup uses ACPI.
>
> Cool. Any docs on that setup?  Would be useful blog post if easy to do.

We have multiple iterations of our setup, depending on the project.

Generic description that we use at University can be found here:

https://linux-kernel-labs.github.io/master/labs/vm.html

Scripts are here:

https://github.com/linux-kernel-labs/linux/tree/master/tools/labs/qemu

For IIO we use DLN2 (USB-I2C/SPI) adapter and we pass
-acpitable file=description.aml to qemu.


thanks,
Daniel.
--
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
Jonathan Cameron June 30, 2018, 5:48 p.m. UTC | #5 
On Fri, 29 Jun 2018 16:02:36 +0300
Daniel Baluta <daniel.baluta@gmail.com> wrote:

> On Mon, Jun 25, 2018 at 1:06 PM, Jonathan Cameron
> <jic23@jic23.retrosnub.co.uk> wrote:
> >
> >
> > On 25 June 2018 08:40:08 BST, Daniel Baluta <daniel.baluta@gmail.com> wrote:  
> >>On Fri, Jun 22, 2018 at 4:44 PM, Jonathan Cameron
> >><jonathan.cameron@huawei.com> wrote:  
> >>> On Thu, 21 Jun 2018 12:04:37 +0530
> >>> Himanshu Jha <himanshujha199640@gmail.com> wrote:
> >>>  
> >>>> Add support to probe the bme680 sensor on the i2c bus using
> >>>> ACPI.
> >>>>
> >>>> Cc: Daniel Baluta <daniel.baluta@gmail.com>
> >>>> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>  
> >>>
> >>> This looks fine.  Do we know for sure that they use that ACPI
> >>> ID?  For these sorts of devices, it's fairly common to have entirely
> >>> random ids presented.   Also, I'm a little curious to know, what
> >>> ACPI based device has one of these?  
> >>
> >>Hi Jonathan,
> >>
> >>I am not aware of any ACPI device using our chosen ID. We just
> >>picked BME0680 based on previous drivers from Bosch.
> >>
> >>It is useful to enumerate the sensor via ACPI because our
> >>qemu testing setup uses ACPI.  
> >
> > Cool. Any docs on that setup?  Would be useful blog post if easy to do.  
> 
> We have multiple iterations of our setup, depending on the project.
> 
> Generic description that we use at University can be found here:
> 
> https://linux-kernel-labs.github.io/master/labs/vm.html
> 
> Scripts are here:
> 
> https://github.com/linux-kernel-labs/linux/tree/master/tools/labs/qemu
> 
> For IIO we use DLN2 (USB-I2C/SPI) adapter and we pass
> -acpitable file=description.aml to qemu.
> 
Cool. I just got around to getting one of these last week as
it seemed a useful tool to have!

Thanks - will have a play with this when I get some time.

Jonathan
> 
> thanks,
> Daniel.

--
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
diff mbox

Patch

diff --git a/drivers/iio/imu/bme680/bme680_core.c b/drivers/iio/imu/bme680/bme680_core.c
index 05712de..a891b1f 100644
--- a/drivers/iio/imu/bme680/bme680_core.c
+++ b/drivers/iio/imu/bme680/bme680_core.c
@@ -3,6 +3,7 @@ 
  *
  * IIO core driver - I2C & SPI bus support
  */
+#include <linux/acpi.h>
 #include <linux/iio/iio.h>
 #include <linux/module.h>
 #include <linux/regmap.h>
@@ -445,6 +446,17 @@  static int bme680_chip_init(struct bme680_data *data, bool use_spi)
 	return 0;
 }
 
+static const char *bme680_match_acpi_device(struct device *dev)
+{
+	const struct acpi_device_id *id;
+
+	id = acpi_match_device(dev->driver->acpi_match_table, dev);
+	if (!id)
+		return NULL;
+
+	return dev_name(dev);
+}
+
 static const struct bme680_chip_info bme680_chip_info = {
 	.oversampling_temp_avail = bme680_oversampling_avail,
 	.num_oversampling_temp_avail = ARRAY_SIZE(bme680_oversampling_avail),
@@ -480,6 +492,9 @@  int bme680_core_probe(struct device *dev, struct regmap *regmap,
 	if (ret < 0)
 		return ret;
 
+	if (!name && ACPI_HANDLE(dev))
+		name = bme680_match_acpi_device(dev);
+
 	indio_dev->dev.parent = dev;
 	indio_dev->name = name;
 	indio_dev->channels = bme680_channels;
diff --git a/drivers/iio/imu/bme680/bme680_i2c.c b/drivers/iio/imu/bme680/bme680_i2c.c
index 1c8223e..2807085 100644
--- a/drivers/iio/imu/bme680/bme680_i2c.c
+++ b/drivers/iio/imu/bme680/bme680_i2c.c
@@ -3,6 +3,7 @@ 
  *	- 0x76 if SDO is pulled to GND
  *	- 0x77 if SDO is pulled to VDDIO
  */
+#include <linux/acpi.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
 #include <linux/regmap.h>
@@ -41,6 +42,11 @@  static const struct i2c_device_id bme680_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, bme680_i2c_id);
 
+static const struct acpi_device_id bme680_acpi_match[] = {
+	{"BME0680", 0},
+	{},
+};
+
 static struct i2c_driver bme680_i2c_driver = {
 	.driver = {
 		.name = "bme680_i2c",