| Age | Commit message (Collapse) | Author |
|---|
|
Add another attribute which is the integration time. Report available
integration time settings, support read of integration time currently
configured in hardware, and support configuration of integration time
into hardware.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240715183120.143417-5-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Make use of the new static table of scale values and expose available
scale values via sysfs attribute of the IIO device.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240715183120.143417-4-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Move scale values into a static table, perform look up of those
scale values in noa1305_scale() simply by using the integration
time register content as an index, because the integration time
register content directly maps to the table values.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240715183120.143417-3-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Make noa1305_measure() behave similar to noa1305_scale(), make it
assign the 'val' output variable on success and return IIO_VAL_INT.
This further simplifies noa1305_read_raw() and allows removal of
ret variable altogether.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240715183120.143417-2-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The only channel this hardware supports is IIO_LIGHT, if the channel
is anything else, exit right away. The 'ret' variable is now always
only assigned by noa1305_measure(), do not initialize it anymore.
Update function parameter indent. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240715183120.143417-1-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add compatible for the KX022-1020 accelerometer [1] using the
KX022-1023 [2] register map as both have an identical i2c interface.
[1]: https://kionixfs.azureedge.net/en/datasheet/KX022-1020%20Specifications%20Rev%2012.0.pdf
[2]: https://kionixfs.azureedge.net/en/datasheet/KX023-1025%20Specifications%20Rev%2012.0.pdf
Signed-off-by: Rayyan Ansari <rayyan@ansari.sh>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patch.msgid.link/20240714173431.54332-3-rayyan@ansari.sh
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Document the KX022-1020 accelerometer, which has the same register
layout as the KX023-1025 and so can use the same driver.
Signed-off-by: Rayyan Ansari <rayyan@ansari.sh>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240714173431.54332-2-rayyan@ansari.sh
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This makes use of the new devm_regulator_get_enable_read_voltage()
helper function to reduce boilerplate code in the MCP3911 ADC driver.
The error message is slightly changed since there are fewer error
return paths.
An extra parameter is added to the config callback to avoid adding
state that is not used outside of the probe() function.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Link: https://patch.msgid.link/20240712-iio-regulator-refactor-round-3-v1-6-835017bae43d@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
By using devm_iio_device_register(), we can drop the remove() callback
in the mcp4922 driver. We can also remove spi_set_drvdata() since there
are no more callers of spi_get_drvdata(). Also use dev_err_probe()
while we are at it.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240712-iio-regulator-refactor-round-3-v1-4-835017bae43d@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This makes use of the new devm_regulator_get_enable_read_voltage()
helper function to reduce boilerplate code in the MCP4922 DAC driver.
The error message is slightly different because there is only one error
return path now.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240712-iio-regulator-refactor-round-3-v1-3-835017bae43d@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This makes use of the new devm_regulator_get_enable_read_voltage()
helper function to reduce boilerplate code in the MCP4728 DAC driver.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240712-iio-regulator-refactor-round-3-v1-2-835017bae43d@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
To prepare for using a function that returns a non-error value, rename
the variable 'err' to 'ret' in the probe function.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240712-iio-regulator-refactor-round-3-v1-1-835017bae43d@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Sort headers in alphabetical order
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240711211558.106327-4-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
According to the datasheet, both pressure and temperature can go up to
oversampling x32. With this option, the maximum measurement time is not
80ms (this is for press x32 and temp x2), but it is 130ms nominal
(calculated from table 3.9.2) and since most of the maximum values
are around +15%, it is configured to 150ms.
Fixes: 8d329309184d ("iio: pressure: bmp280: Add support for BMP380 sensor family")
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240711211558.106327-3-vassilisamir@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Up to now, the BMP280 device is using the regmap of the BME280 which
has registers that exist only in the BME280 device.
Fixes: 14e8015f8569 ("iio: pressure: bmp280: split driver in logical parts")
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240711211558.106327-2-vassilisamir@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The Analog Devices Inc. AD4695 (and similar chips) are complex ADCs that
will benefit from a detailed driver documentation.
This documents the current features supported by the driver.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This is a new driver for Analog Devices Inc. AD4695 and similar ADCs.
The initial driver supports initializing the chip including configuring
all possible LDO and reference voltage sources as well as any possible
voltage input channel wiring configuration.
Only the 4-wire SPI wiring mode where the CNV pin is tied to the CS pin
is supported at this time. And reading sample data from the ADC can only
be done in direct mode for now.
Co-developed-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20240711-iio-adc-ad4695-v4-2-c31621113b57@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add device tree bindings for AD4695 and similar ADCs.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240711-iio-adc-ad4695-v4-0-c31621113b57@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The variable uHz already has the type u64 and casting it to u64 is
unnecessary. Remove the redundant type cast.
Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
Link: https://patch.msgid.link/20240711134502.168484-1-thorsten.blum@toblux.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
LTC2664 4 channel, 12-/16-Bit Voltage Output SoftSpan DAC
LTC2672 5 channel, 12-/16-Bit Current Output Softspan DAC
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Co-developed-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20240718051834.32270-7-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add documentation for ltc2672.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Co-developed-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://patch.msgid.link/20240718051834.32270-6-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add documentation for ltc2664.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Co-developed-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://patch.msgid.link/20240718051834.32270-5-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Introduce a generalized DAC binding that can be used by DACs that have
similar properties adding output-range-microamp and output-range-microvolt.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://patch.msgid.link/20240718051834.32270-4-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add a new powerdown mode for DACs with 42kohm resistor to GND.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://patch.msgid.link/20240718051834.32270-3-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Introduces a more generalized ABI documentation for DAC. Instead of
having separate ABI files for each DAC, we now have a single ABI file
that covers the common sysfs interface for all DAC.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
https://patch.msgid.link/20240718051834.32270-2-kimseer.paller@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
For APIs that have a return value, -EOPNOTSUPP is returned in case the
backend does not support the functionality. However, for APIs that do
not have a return value we are left in silence. Hence, at least print a
debug message in case the callback is not implemented by the backend.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20240709-dev-iio-backend-add-debugfs-v1-2-fb4b8f2373c7@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Indio_dev was not being used in iio_backend_extend_chan_spec() so remove
it.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20240709-dev-iio-backend-add-debugfs-v1-1-fb4b8f2373c7@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This adds a new page to document how to use the ad7380 ADC driver.
Credit: this docs is based on ad7944 docs.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://patch.msgid.link/20240709-ad7380-add-docs-v1-1-458ced3dfcc5@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add documentation for adxl380 driver which describes the driver
device files and shows how the user may use the ABI for various
scenarios (configuration, measurement, etc.).
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://patch.msgid.link/20240708104114.29894-3-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ADXL380/ADXL382 is a low noise density, low power, 3-axis
accelerometer with selectable measurement ranges. The ADXL380 supports
the +/-4 g, +/-8 g, and +/-16 g ranges, and the ADXL382 supports
+/-15 g, +/-30 g and +/-60 g ranges.
The ADXL380/ADXL382 offers industry leading noise, enabling precision
applications with minimal calibration. The low noise, and low power
ADXL380/ADXL382 enables accurate measurement in an environment with
high vibration, heart sounds and audio.
In addition to its low power consumption, the ADXL380/ADXL382 has many
features to enable true system level performance. These include a
built-in micropower temperature sensor, single / double / triple tap
detection and a state machine to prevent a false triggering. In
addition, the ADXL380/ADXL382 has provisions for external control of
the sampling time and/or an external clock.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://patch.msgid.link/20240708104114.29894-2-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add dt-bindings for ADXL380/ADLX382 low noise density, low
power, 3-axis accelerometer with selectable measurement ranges.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://patch.msgid.link/20240708104114.29894-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
BMP2xx, BME280, BMP3xx, and BMP5xx use continuous buffers for their
temperature, pressure and humidity readings. This facilitates the
use of burst/bulk reads in order to acquire data faster. The
approach is different from the one used in oneshot captures.
BMP085 & BMP1xx devices use a completely different measurement
process that is well defined and is used in their buffer_handler().
Suggested-by: Angel Iglesias <ang.iglesiasg@gmail.com>
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://lore.kernel.org/r/20240512230524.53990-6-vassilisamir@gmail.com
Link: https://patch.msgid.link/20240628171726.124852-4-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add extra IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_RAW channels in order
to be able to calculate the processed value with standard userspace
IIO tools. Can be used for triggered buffers as well.
Even though it is not a good design choice to have SCALE, RAW and
PROCESSED together, the PROCESSED channel is kept for ABI compatibility.
While at it, separate BMPxxx and BMExxx device channels since BME
supports also humidity measurements.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://lore.kernel.org/r/20240512230524.53990-5-vassilisamir@gmail.com
Link: https://patch.msgid.link/20240628171726.124852-3-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add the coefficients for the IIO standard units and the IIO value
inside the chip_info structure.
Move the calculations for the IIO unit compatibility from inside the
read_{temp,press,humid}() functions and move them to the general
read_raw() function.
In this way, all the data for the calculation of the value are
located in the chip_info structure of the respective sensor.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Acked-by: Adam Rizkalla <ajarizzo@gmail.com>
Link: https://patch.msgid.link/20240628171726.124852-2-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add LiteOn LTR-308 support into LTR-F216A kernel driver.
The two devices seem to have almost identical register map, except that
the LTR-308 does not have three CLEAR_DATA registers, which are unused
by this driver. Furthermore, LTR-308 and LTR-F216A use different lux
calculation constants, 0.6 and 0.45 respectively. Both differences are
handled using chip info data.
https://optoelectronics.liteon.com/upload/download/DS86-2016-0027/LTR-308ALS_Final_%20DS_V1%201.pdf
https://optoelectronics.liteon.com/upload/download/DS86-2019-0016/LTR-F216A_Final_DS_V1.4.PDF
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20240708114227.18283-2-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Document LiteOn LTR-308 support in LTR-F216A bindings.
The two devices seem to have almost identical register map, except that
the LTR-308 does not have three CLEAR_DATA registers, which are unused
by this driver. Furthermore, LTR-308 and LTR-F216A use different lux
calculation constants, 0.6 and 0.45 respectively.
https://optoelectronics.liteon.com/upload/download/DS86-2016-0027/LTR-308ALS_Final_%20DS_V1%201.pdf
https://optoelectronics.liteon.com/upload/download/DS86-2019-0016/LTR-F216A_Final_DS_V1.4.PDF
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240708114227.18283-1-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ROHM BU27034 light sensor has two data channels for measuring
different frequencies of light. The result from these channels is
combined into Lux value while the raw channel values are reported via
intensity channels.
Both of the intensity channels have adjustable gain setting which
impacts the scale of the raw channels. Eg, doubling the gain will double
the values read from the raw channels, which halves the scale value. The
integration time can also be set for the sensor. This does also have an
impact to the scale of the intensity channels because increasing the
integration time will also increase the values reported via the raw
channels.
Impact of integration time to the scale and the fact that the scale value
does not start from '1', can make it hard for a human reader to compute the
gain values based on the scale.
Add read-only HARDWAREGAIN to help debugging.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/ec349847cc994f3bd632e99b408a31e7c70581d0.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. The lux computation based on the data from a BU27034ANUC is
different from the computation for the data from an old BU27034NUC.
Fix the lux computation.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/b7bea76b54b28eb354dc523771a0e0a8b6f26095.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. The BU27034ANUC does not support all the gains or all the
integration times that were supported on BU27034NUC.
Srop unsupported times and gains
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/19f8cca2b5498fbfea6e657b7b9c90b78516866a.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. The BU27034ANUC does not have the data2 channel.
Drop the data2 channel.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/6f261d4499e9c0e161279717261cc9a20764a6bd.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. These senors aren't compatible from the software point of view.
According to ROHM, the BU27034NUC was never mass-produced. Hence dropping
the BU27034NUC support and using this driver to support BU27034ANUC
should not be a problem to users. We however need to ensure than people
who use old kernel with the old BU27034NUC driver don't get the old
driver probed for the new sensor.
Prepare to use the BU27034NUC driver to support the new BU27034ANUC and
change the compatible to prevent probing the old driver with the new
sensor.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/ed8b963b0cd3a84c06a494c79969a136d5abcf92.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The BU27034NUC was cancelled before it entered mass production. It was
replaced by a new variant BU27034ANUC (note, added 'A'). The new
variant gained a few significant changes, like removal of the 3.rd data
channel and dropping some of the gain settings. This means that, from
software point of view these ICs are incompatible. Lux calculation based
on the data from the sensors needs to be done differently, and on the
BU27034ANUC the channel 3 data is missing. Also, the gain setting
differencies matter.
Unfortunately, the identification register was not changed so there is no
safe way for the software to distinguish the variants.
According to the ROHM HQ engineers, the old BU27034NUC should not be
encountered in the wild. Hence it makes sense to remove the support for
the old BU27034NUC and add support for the new BU27034ANUC. Change the
compatible in order to not load the incompatible old driver for new sensor
(or, if someone had the old sensor, the new driver for it).
Drop the compatible for old sensor which should not be in the wild and
add a new compatible for the new model with accurate model suffix
'anuc'. Rename the file to match the new compatible.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/c39f9c67b3c07a27d7a13109c7b69cff9cfd2b9b.1720176341.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The reading of the pressure and humidity value, requires an update of the
t_fine variable which happens by reading the temperature value.
So the bme680_read_{press/humid}() functions of the above sensors are
internally calling the equivalent bme680_read_temp() function in order to
update the t_fine value. By just looking at the code this relation is a
bit hidden and is not easy to understand why those channels are not
independent.
This commit tries to clear these thing a bit by splitting the
bme680_{read/compensate}_{temp/press/humid}() to the following:
i. bme680_read_{temp/press/humid}_adc(): read the raw value from the
sensor.
ii. bme680_calc_t_fine(): calculate the t_fine variable.
iii. bme680_get_t_fine(): get the t_fine variable.
iv. bme680_compensate_{temp/press/humid}(): compensate the adc values and
return the calculated value.
v. bme680_read_{temp/press/humid}(): combine calls of the aforementioned
functions to return the requested value.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-16-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Whenever the sensor is set to forced mode, a TPHG cycle is triggered and
the values of temperature, pressure, humidity and gas become ready to be
read.
The setup of the forced mode to trigger measurements was located inside
the read_{temp/gas}() functions. This was not posing a functional problem
since read_{humid/press}() are internally calling read_temp() so the
forced mode is set through this call.
This is not very clear and it is kind of hidden that regardless of the
measurement, the setup of the forced mode needs to happen before any
measurement.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-15-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
There is no need to explicitly configure the gas measurement registers
every time a gas measurement takes place. These are initial configurations
which are written in the beginning and they are not changed throughout
the lifetime of the driver.
If in the future, the device starts to support multiple configuration
profiles with variable heater duration and heater temperature, then they
could become members of the ->read_avail().
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-14-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
There are multiple cases in the probe function that dev_err_probe() fits
the needs, so use it.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-13-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Modify the startup procedure to reflect the procedure of the Bosch BME68x
Sensor API. The initial readings and configuration of the sensor need to
happen in the following order:
1) Read calibration data [1,2]
2) Chip general configuration [3]
3) Gas configuration [4]
After the chip configuration it is necessary to ensure that the sensor is
in sleeping mode, in order to apply the gas configuration settings [5].
Also, after the soft reset, it is advised to wait for 5ms [6].
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L162 # [1]
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L44 # [2]
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L53 # [3]
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L60 # [4]
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L640 # [5]
Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L294 # [6]
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-12-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
In the majority of the error checks after a regmap_{read,write}()
operation the following coding style is used:
ret = regmap_{read,write}(data->regmap, ...);
if (ret < 0) {
dev_err(dev, ...);
return ret;
}
In this particular case it was different so change it for consistency.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-11-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Move the buffers that are used in order to read data from the device in
the union which handles all the device read/write buffers. Also create
defines for the number of bytes that are being read from the device and
don't use magic numbers.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-10-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Move the IIO device allocation before the actual initialization of the
chip to be more consistent with most IIO drivers and also to have the
ability to use any driver specific data for the chip initialization.
While at it, fix also a misaligned line.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://patch.msgid.link/20240609233826.330516-9-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
