History log of /linux-master/drivers/iio/chemical/bme680_i2c.c
Revision Date Author Comments
# 7cf15f42 15-May-2023 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

iio: Switch i2c drivers back to use .probe()

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230515205048.19561-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# 5aa37765 18-Nov-2022 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

iio: chemical: bme680_i2c: Convert to i2c's .probe_new()

.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221118224540.619276-77-uwe@kleine-koenig.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# 146b43d9 30-Jan-2022 Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio:chemical:bme680: Move exports to IIO_BME680 namespace

In order to avoid unnecessary pollution of the global symbol namespace
move the common/library functions into a specific namespace and import
that into the bus specific device drivers that use them.

For more information see https://lwn.net/Articles/760045/

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Himanshu Jha <himanshujha199640@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-17-jic23@kernel.org


# b73d21dc 05-May-2021 Guenter Roeck <linux@roeck-us.net>

iio: bme680_i2c: Remove acpi_device_id table

With CONFIG_ACPI=n and -Werror, 0-day reports:

drivers/iio/chemical/bme680_i2c.c:46:36: error:
'bme680_acpi_match' defined but not used

Apparently BME0680 is not a valid ACPI ID. Remove the ID.

Note the driver will still work with ACPI bindings that use the PRP0001
mechanism as that uses the of_device_id table instead.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# d612eb13 12-Mar-2021 Andy Shevchenko <andriy.shevchenko@linux.intel.com>

iio: chemical: bmp680: Drop unneeded explicit castings

In few places the unnecessary explicit castings are being used.
Drop them for good.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210312134349.3472-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# 73f3bc6d 06-Mar-2019 Mike Looijmans <mike.looijmans@topic.nl>

iio:chemical:bme680: Fix SPI read interface

The SPI interface implementation was completely broken.

When using the SPI interface, there are only 7 address bits, the upper bit
is controlled by a page select register. The core needs access to both
ranges, so implement register read/write for both regions. The regmap
paging functionality didn't agree with a register that needs to be read
and modified, so I implemented a custom paging algorithm.

This fixes that the device wouldn't even probe in SPI mode.

The SPI interface then isn't different from I2C, merged them into the core,
and the I2C/SPI named registers are no longer needed.

Implemented register value caching for the registers to reduce the I2C/SPI
data transfers considerably.

The calibration set reads as all zeroes until some undefined point in time,
and I couldn't determine what makes it valid. The datasheet mentions these
registers but does not provide any hints on when they become valid, and they
aren't even enumerated in the memory map. So check the calibration and
retry reading it from the device after each measurement until it provides
something valid.

Despite the size this is suitable for a stable backport given that
it seems the SPI support never worked.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor");
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# f7da8845 14-Jan-2019 Sebastien Bourdelin <sebastien.bourdelin@gmail.com>

iio: chemical: bme680: Add device-tree support

This commit allow the driver to work with device-tree.

Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@gmail.com>
Acked-by: Himanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


# 1b3bd859 26-Jul-2018 Himanshu Jha <himanshujha199640@gmail.com>

iio: chemical: Add support for Bosch BME680 sensor

Bosch BME680 is a 4-in-1 sensor with temperature, pressure, humidity
and gas sensing capability. It supports both I2C and SPI communication
protocol for effective data communication.

The device supports two modes:

1. Sleep mode
2. Forced mode

The measurements only takes place when forced mode is triggered and a
single TPHG cycle is performed by the sensor. The sensor automatically
goes to sleep after afterwards.

The device has various calibration constants/parameters programmed into
devices' non-volatile memory(NVM) during production and can't be altered
by the user. These constants are used in the compensation functions to
get the required compensated readings along with the raw data. The
compensation functions/algorithms are provided by Bosch Sensortec GmbH
via their API[1]. As these don't change during the measurement cycle,
therefore we read and store them at the probe. The default configs
supplied by Bosch are also set at probe.

0-day tested with build success.

GSoC-2018: https://summerofcode.withgoogle.com/projects/#6691473790074880
Mentor: Daniel Baluta
[1] https://github.com/BoschSensortec/BME680_driver
Datasheet:
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf

Note from Jonathan: The compensation functions are 'interesting' and
could do with a tidy up in future. However, they work so we can leave that
for another day.

Cc: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>