- 03 Aug, 2024 31 commits
-
-
Julien Stephan authored
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.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Antoniu Miclaus authored
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.comSigned-off-by:
-
Antoniu Miclaus authored
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:
-
Antoniu Miclaus authored
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:
-
Vasileios Amoiridis authored
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.comSigned-off-by:
-
Vasileios Amoiridis authored
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 authored
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:Adam Rizkalla <ajarizzo@gmail.com> Link: https://patch.msgid.link/20240628171726.124852-2-vassilisamir@gmail.comSigned-off-by:
-
Marek Vasut authored
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.PDFSigned-off-by:
Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20240708114227.18283-2-marex@denx.deSigned-off-by:
-
Marek Vasut authored
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.PDFSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240708114227.18283-1-marex@denx.deSigned-off-by:
-
Matti Vaittinen authored
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.comSigned-off-by:
-
Matti Vaittinen authored
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 authored
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 authored
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 authored
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 authored
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:
-
Vasileios Amoiridis authored
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 authored
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 authored
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 authored
There are multiple cases in the probe function that dev_err_probe() fits the needs, so use it. Signed-off-by:
-
Vasileios Amoiridis authored
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 authored
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 authored
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 authored
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 authored
Calibration data are located in contiguous-ish registers inside the chip. For that reason we can use bulk reads as is done as well in the BME68x Sensor API [1]. The arrays that are used for reading the data out of the sensor are located inside DMA safe buffer. Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L1769 # [1] Signed-off-by:
-
Vasileios Amoiridis authored
The LSB of the gas register was read first to check if the following check was correct and then the MSB+LSB were read together. Simplify this by reading together the MSB+LSB immediately. Signed-off-by:
-
Vasileios Amoiridis authored
Sort headers in alphabetical order and split the iio specific functions with a blank line Signed-off-by:
-
Vasileios Amoiridis authored
The ACPI ID table was removed with the following 2 commits: Commit b73d21dc ("iio: bme680_i2c: Remove acpi_device_id table") Commit f0e4057e ("iio: bme680_spi: Remove acpi_device_id table") Remove the remaining ACPI related stuff to this driver since they are not directly used. Signed-off-by:
-
Vasileios Amoiridis authored
Delete any redundant casts in the code and use unsigned integers for the raw adc values. Signed-off-by:
-
Vasileios Amoiridis authored
Fix a define typo that instead of BME680_... it is saying BM6880_... Signed-off-by:
-
Vasileios Amoiridis authored
Add mutexes in the {read/write}_raw() functions of the device to guard the read/write of data from/to the device. This is necessary because for any operation other than temperature, multiple reads need to take place from the device. Even though regmap has a locking by itself, it won't protect us from multiple applications trying to read at the same time temperature and pressure since the pressure reading includes an internal temperature reading and there is nothing to ensure that this temperature+pressure reading will happen sequentially without any other operation interfering in the meantime. Fixes: 1b3bd859 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: -
Antoniu Miclaus authored
Fix description of the filter_mode_available attribute by pointing to the correct name of the attribute that can be written with valid values. Fixes: bf92d87d ("iio:filter:admv8818: Add sysfs ABI documentation") Signed-off-by:
-
- 29 Jul, 2024 9 commits
-
-
Yasin Lee authored
A SAR sensor from NanjingTianyihexin Electronics Ltd. The device has the following entry points: Usual frequency: - sampling_frequency Instant reading of current values for different sensors: - in_proximity0_raw - in_proximity1_raw - in_proximity2_raw - in_proximity3_raw - in_proximity4_raw and associated events in events/ Signed-off-by:
Yasin Lee <yasin.lee.x@gmail.com> Link: https://patch.msgid.link/20240702-add-tyhx-hx9023s-sensor-driver-v9-3-c030f1801d9b@gmail.comSigned-off-by:
-
Yasin Lee authored
A capacitive proximity sensor Reviewed-by:
-
Yasin Lee authored
Add vendor prefix for NanjingTianyihexin Electronics Ltd. http://www.tianyihexin.comAcked-by:
-
Chen Ni authored
Add check for the return value of spi_setup() and return the error if it fails in order to catch the error. Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20240705084250.3006527-1-nichen@iscas.ac.cnSigned-off-by:
-
Guillaume Stols authored
Switching to guard simplifies the code and avoids to take care to unlock the mutex in case of premature return. Signed-off-by:
Guillaume Stols <gstols@baylibre.com> Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Signed-off-by:
-
Guillaume Stols authored
The binding's documentation specifies that "As the line is active low, it should be marked GPIO_ACTIVE_LOW". However, in the driver, it was handled the opposite way. This commit sets the driver's behaviour in sync with the documentation Fixes: 722407a4 ("staging:iio:ad7606: Use GPIO descriptor API") Signed-off-by:
-
Guillaume Stols authored
gpiod_set_array_value was misused here: the implementation relied on the assumption that an unsigned long was required for each gpio, while the function expects a bit array stored in "as much unsigned long as needed for storing one bit per GPIO", i.e it is using a bit field. This leaded to incorrect parameter passed to gpiod_set_array_value, that would set 1 value instead of 3. It also prevents to select the software mode correctly for the AD7606B. Fixes: d2a415c8 ("iio: adc: ad7606: Add support for AD7606B ADC") Fixes: 41f71e5e ("staging: iio: adc: ad7606: Use find_closest() macro") Signed-off-by:
-
Guillaume Stols authored
Since the driver supports several parts that present differences in their layout and behaviour, it is necessary to describe the differences from one chip to another. Reviewed-by:
-
Guillaume Stols authored
Example uses adi,ad7606-8 as compatible, but adi,sw-mode is not available for it. So remove this property from example. Acked-by:
-
