summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2024-06-13iio: temperature: mcp9600: add threshold events supportDimitri Fedrau
The device has four programmable temperature alert outputs which can be used to monitor hot or cold-junction temperatures and detect falling and rising temperatures. It supports up to 255 degree celsius programmable hysteresis. Each alert can be individually configured by setting following options in the associated alert configuration register: - monitor hot or cold junction temperature - monitor rising or falling temperature - set comparator or interrupt mode - set output polarity - enable alert This patch binds alert outputs to iio events: - alert1: hot junction, rising temperature - alert2: hot junction, falling temperature - alert3: cold junction, rising temperature - alert4: cold junction, falling temperature All outputs are set in comparator mode and polarity depends on interrupt configuration. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20240604133639.959682-1-dima.fedrau@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: light: driver for Vishay VEML6040Arthur Becker
Implements driver for the Vishay VEML6040 rgbw light sensor. Included functionality: setting the integration time and reading the raw values for the four channels Not yet implemented: setting the measurements to 'Manual Force Mode' (Auto measurements off, and adding a measurement trigger) Datasheet: https://www.vishay.com/docs/84276/veml6040.pdf Signed-off-by: Arthur Becker <arthur.becker@sentec.com> Link: https://lore.kernel.org/r/20240604-veml6040-v4-1-5a4d59597874@sentec.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: dac: adi-axi-dac: add platform dependenciesNuno Sa
Being this device a soft core, it's only supported on some/specific platforms. Hence add proper dependencies for the supported platforms. Also add COMPILE_TEST to increase the build coverage. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240604-dev-axi-dac-kconfig-v1-1-99ccd03938d1@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: adi-axi-adc: add platform dependenciesNuno Sa
Being this device a soft core, it's only supported on some/specific platforms. Hence add proper dependencies for the supported platforms. Also add COMPILE_TEST to increase the build coverage. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240604-dev-axi-adc-kconfig-v1-1-cfb725606b8e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: imu: inv_icm42600: add register caching in the regmapJean-Baptiste Maneyrol
Register caching is improving bus access a lot because of the register window bank setting. Previously, bank register was set for every register access. Now with caching, it happens only when changing bank which is very infrequent. Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20240607081039.789079-1-inv.git-commit@tdk.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: mcp3564: drop redundant open-coded spi_get_device_match_data()Krzysztof Kozlowski
The driver calls spi_get_device_match_data() and on its failure calls again parts of it: spi_get_device_id() and getting driver data. This is entirely redundant, because it is part of spi_get_device_match_data(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-8-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: dac: max5522: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-7-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: addac: ad74413r: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-6-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: ti-tsc2046: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-5-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: ti-ads131e08: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-4-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: max11205: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-3-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: accel: adxl355: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-2-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: accel: adxl313: simplify with spi_get_device_match_data()Krzysztof Kozlowski
Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240606-spi-match-data-v1-1-320b291ee1fe@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: humidity: si7020: add heater supportAntoni Pokusinski
This patch adds support for the integrated on-chip heater that is present on all the devices supported by this driver (si7020, si7021, si7013, th6). In order to configure the heater, the driver interacts with the following device registers: * User Register - the 2nd bit of this register is a "Heater Enable bit" (0 means that the heater is off, 1 means that it's on). * Heater Register - this register is present only on the si70xx devices and controls the current flowing through the heater. The 4 lower bits of this register can be assigned values from 0x0 to 0xF. Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com> Link: https://lore.kernel.org/r/20240607141029.51744-1-apokusinski@o2.pl Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: add missing MODULE_DESCRIPTION() macrosJeff Johnson
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/adc/ingenic-adc.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/adc/xilinx-ams.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/buffer/kfifo_buf.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240607-md-drivers-iic-v1-1-9f9db6246083@quicinc.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: event: use sizeof(*pointer) instead of sizeof(type)Erick Archer
It is preferred to use sizeof(*pointer) instead of sizeof(type) due to the type of the variable can change and one needs not change the former (unlike the latter). At the same time refactor the NULL comparison. This patch has no effect on runtime behavior. Signed-off-by: Erick Archer <erick.archer@outlook.com> Link: https://lore.kernel.org/r/AS8PR02MB7237D024459C314CECE72EAF8BFE2@AS8PR02MB7237.eurprd02.prod.outlook.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: axp20x_adc: Add support for AXP192Aidan MacDonald
The AXP192 is identical to the AXP20x, except for the addition of two more GPIO ADC channels. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: adc: ti-adc161s626: make use of iio_device_claim_direct_scoped()Gustavo Ueti Fukunaga
Make use of iio_device_claim_direct_scoped() to make error handling more natural and simplify code. Co-developed-by: Caio Dantas Simão Ugêda <caiodantas@usp.br> Signed-off-by: Caio Dantas Simão Ugêda <caiodantas@usp.br> Signed-off-by: Gustavo Ueti Fukunaga <gustavofukunaga@usp.br> Link: https://lore.kernel.org/r/20240527091942.53616-1-gustavofukunaga@usp.br Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13iio: accel: mma7660: add mount-matrix supportVal Packett
Allow using the mount-matrix device tree property to align the accelerometer relative to the whole device. Signed-off-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/20240527080043.2709-1-val@packett.cool Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-13driver: iio: add missing checks on iio_info's callback accessJulien Stephan
Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]--- Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://lore.kernel.org/r/20240530-iio-core-fix-segfault-v3-1-8b7cd2a03773@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: chemical: bme680: Fix sensor data read operationVasileios Amoiridis
A read operation is happening as follows: a) Set sensor to forced mode b) Sensor measures values and update data registers and sleeps again c) Read data registers In the current implementation the read operation happens immediately after the sensor is set to forced mode so the sensor does not have the time to update properly the registers. This leads to the following 2 problems: 1) The first ever value which is read by the register is always wrong 2) Every read operation, puts the register into forced mode and reads the data that were calculated in the previous conversion. This behaviour was tested in 2 ways: 1) The internal meas_status_0 register was read before and after every read operation in order to verify that the data were ready even before the register was set to forced mode and also to check that after the forced mode was set the new data were not yet ready. 2) Physically changing the temperature and measuring the temperature This commit adds the waiting time in between the set of the forced mode and the read of the data. The function is taken from the Bosch BME68x Sensor API [1]. [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L490 Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Link: https://lore.kernel.org/r/20240606212313.207550-5-vassilisamir@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: chemical: bme680: Fix overflows in compensate() functionsVasileios Amoiridis
There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/ Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Link: https://lore.kernel.org/r/20240606212313.207550-4-vassilisamir@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: chemical: bme680: Fix calibration data variableVasileios Amoiridis
According to the BME68x Sensor API [1], the h6 calibration data variable should be an unsigned integer of size 8. [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L789 Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Link: https://lore.kernel.org/r/20240606212313.207550-3-vassilisamir@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: chemical: bme680: Fix pressure value outputVasileios Amoiridis
The IIO standard units are measured in kPa while the driver is using hPa. Apart from checking the userspace value itself, it is mentioned also in the Bosch API [1] that the pressure value is in Pascal. [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L742 Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Link: https://lore.kernel.org/r/20240606212313.207550-2-vassilisamir@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: humidity: hdc3020: fix hysteresis representationDimitri Fedrau
According to the ABI docs hysteresis values are represented as offsets to threshold values. Current implementation represents hysteresis values as absolute values which is wrong. Nevertheless the device stores them as absolute values and the datasheet refers to them as clear thresholds. Fix the reading and writing of hysteresis values by including thresholds into calculations. Hysteresis values that result in threshold clear values that are out of limits will be truncated. To check that the threshold clear values are correct, registers are read out using i2ctransfer and the corresponding temperature and relative humidity thresholds are calculated using the formulas in the datasheet. Fixes: 3ad0e7e5f0cb ("iio: humidity: hdc3020: add threshold events support") Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240605192136.38146-1-dima.fedrau@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-09iio: dac: fix ad9739a random config compile errorKe Sun
WARNING: unmet direct dependencies detected for REGMAP_SPI Depends on [n]: SPI [=n] Selected by [m]: - AD9739A [=m] && IIO [=m] && (SPI [=n] || COMPILE_TEST [=y]) ... ERROR: modpost: "spi_write_then_read" [drivers/base/regmap/regmap-spi.ko] undefined! ERROR: modpost: "spi_async" [drivers/base/regmap/regmap-spi.ko] undefined! ERROR: modpost: "spi_sync" [drivers/base/regmap/regmap-spi.ko] undefined! ERROR: modpost: "__spi_register_driver" [drivers/iio/dac/ad9739a.ko] undefined! Fixes: e77603d5468b ("iio: dac: support the ad9739a RF DAC") Reported-by: k2ci <kernel-bot@kylinos.cn> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404250156.2PQRWmex-lkp@intel.com/ Signed-off-by: Ke Sun <sunke@kylinos.cn> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240609030847.2869455-1-sunke@kylinos.cn Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-08iio: accel: fxls8962af: select IIO_BUFFER & IIO_KFIFO_BUFAlexander Sverdlin
Provide missing symbols to the module: ERROR: modpost: iio_push_to_buffers [drivers/iio/accel/fxls8962af-core.ko] undefined! ERROR: modpost: devm_iio_kfifo_buffer_setup_ext [drivers/iio/accel/fxls8962af-core.ko] undefined! Cc: stable@vger.kernel.org Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20240605203810.2908980-2-alexander.sverdlin@siemens.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-08iio: adc: ad7266: Fix variable checking bugFernando Yang
The ret variable was not checked after iio_device_release_direct_mode(), which could possibly cause errors Fixes: c70df20e3159 ("iio: adc: ad7266: claim direct mode during sensor read") Signed-off-by: Fernando Yang <hagisf@usp.br> Link: https://lore.kernel.org/r/20240603180757.8560-1-hagisf@usp.br Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-08iio: xilinx-ams: Don't include ams_ctrl_channels in scan_maskSean Anderson
ams_enable_channel_sequence constructs a "scan_mask" for all the PS and PL channels. This works out fine, since scan_index for these channels is less than 64. However, it also includes the ams_ctrl_channels, where scan_index is greater than 64, triggering undefined behavior. Since we don't need these channels anyway, just exclude them. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://lore.kernel.org/r/20240311162800.11074-1-sean.anderson@linux.dev Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-08iio: chemical: ams-iaq-core: clean up codestyle warningBruna Bispo
This fixes a checkpatch warning by changing the struct attribute from __attribute__((__packed__)) to __packed. Signed-off-by: Bruna Bispo <blbispo1@gmail.com> Link: https://lore.kernel.org/r/20240528143816.13409-1-blbispo1@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adis16480: add support for adis16545/7 familiesRamona Gradinariu
The ADIS16545 and ADIS16547 are a complete inertial system that includes a triaxis gyroscope and a triaxis accelerometer. The serial peripheral interface (SPI) and register structure provide a simple interface for data collection and configuration control. These devices are similar to the ones already supported in the driver, with changes in the scales, timings and the max spi speed in burst mode. Also, they support delta angle and delta velocity readings in burst mode, for which support was added in the trigger handler. Co-developed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240528142409.239187-5-ramona.gradinariu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: imu: adis16480.c: Add delta angle and delta velocity channelsRamona Gradinariu
Add support for delta angle and delta velocity raw readings to adis16480 driver. The following devices do not support delta readings in burst mode: ADIS16375, ADIS16480, ADIS16485, ADIS16488, ADIS16490, ADIS16495-1, ADIS16495-2, ADIS16495-3, ADIS16497-1, ADIS16497-2, ADIS16497-3, thus they cannot be retrieved via the buffer interface. For these devices, the delta measurements are retrieved by performing normal register readings and are made available through the raw attributes of the specific channels. Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240528142409.239187-3-ramona.gradinariu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adis16480: make the burst_max_speed configurableRamona Gradinariu
With this, we can pass the maxixum spi burst speed to the 'ADIS16480_DATA()' macro. This is in preparation to support new devices that have a different speed than the one used so far. Co-developed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240528142409.239187-2-ramona.gradinariu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04drivers: iio: imu: Add support for adis1657x familyRamona Gradinariu
Add support for ADIS1657X family devices in already exiting ADIS16475 driver. Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-10-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: imu: adis16475: Re-define ADIS16475_DATARamona Gradinariu
Re-define ADIS16475_DATA such that it takes _burst_max_len, _burst_max_speed_hz and _has_fifo as parameters. Also, do a preparatory rename operation for ADIS16475_BURST32_MAX_DATA to ADIS16475_BURST32_MAX_DATA_NO_TS32 to be able to differentiate in the future between devices which are using 16-bit or 32-bit timestamp size in burst mode. Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-8-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: imu: adis_trigger: Allow level interrupts for FIFO readingsRamona Gradinariu
Currently, adis library allows configuration only for edge interrupts, needed for data ready sampling. This patch removes the restriction for level interrupts for devices which have FIFO support. Furthermore, in case of devices which have FIFO support, devm_request_threaded_irq is used for interrupt allocation, to avoid flooding the processor with the FIFO watermark level interrupt, which is active until enough data has been read from the FIFO. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-7-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04drivers: iio: imu: adis16475: generic computation for sample rateRamona Gradinariu
Currently adis16475 supports a sample rate between 1900 and 2100 Hz. This patch changes the setting of sample rate from hardcoded values to a generic computation based on the internal clock frequency. This is a preparatory patch for adding support for adis1657x family devices which allow sample rates between 3900 and 4100 Hz. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-6-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: imu: adis16475: Create push single sample APIRamona Gradinariu
Create push single sample API reposnsible for pushing a single sample into the buffer. This is a preparation patch for FIFO support where more than one sample has to be pushed in the trigger handler. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-5-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: imu: adis_buffer: Add buffer setup API with buffer attributesRamona Gradinariu
Add new API called devm_adis_setup_buffer_and_trigger_with_attrs() which also takes buffer attributes as a parameter. Rewrite devm_adis_setup_buffer_and_trigger() implementation such that it calls devm_adis_setup_buffer_and_trigger_with_attrs() with buffer attributes parameter NULL Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-4-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04drivers: iio: imu: Add support for ADIS16501Ramona Gradinariu
Add support for ADIS16501 device in already existing ADIS16475 driver. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com> Link: https://lore.kernel.org/r/20240527142618.275897-3-ramona.bolboaca13@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: add oversampling supportJulien Stephan
ad7380x(-4) parts are able to do oversampling to increase accuracy. This chips supports a normal oversampling mode and a rolling mode and also allows enabling and disabling extra resolution bits when oversampling is enabled. We have intentionally left out the rolling mode for now as there is not a compelling use case for it. User can process a captured data buffer to get the same effect. We are also currently not supporting changing the oversampling mode independently of the resolution bits. The resolution boost feature can only be enabled when oversampling is enabled and oversampling is not as useful without the resolution boost. So for now we consider the features tightly coupled. When oversampling is enabled, the resolution boost is enabled and when oversampling is disabled, the resolution boost is disabled. Since the resolution boost feature causes 16-bit chips to now have 18-bit data which means the storagebits has to change from 16 to 32 bits, we use the new ext_scan_type feature to allow changing the scan_type at runtime based on if the resolution boost is enabled or not. SPI message optimization has to be moved since now some of the xfer parameters change based on the resolution boost mode. A few neighboring comments are also fixed up while we are touching this code. Signed-off-by: Julien Stephan <jstephan@baylibre.com> Co-developed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-5-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: use spi_optimize_message()David Lechner
This changes the AD7380 to use spi_optimize_message() to optimize buffered reads. This changes both direct reads and buffered reads to use the same spi_message. This has some (welcome) side effects. The first is that in buffered reads, the timestamp will now correspond to the same sample rather than the previous sample. The second is that direct reads now use the same SPI bus speed as buffered reads. This reduces CPU usage of the IRQ thread from around 25% to around 20% when sampling at 10 kHz on a ZedBoard. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-4-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: add support for multiple scan types per channelDavid Lechner
This adds new fields to the iio_channel structure to support multiple scan types per channel. This is useful for devices that support multiple resolution modes or other modes that require different data formats of the raw data. To make use of this, drivers need to implement the new callback get_current_scan_type() to resolve the scan type for a given channel based on the current state of the driver. There is a new scan_type_ext field in the iio_channel structure that should be used to store the scan types for any channel that has more than one. There is also a new flag has_ext_scan_type that acts as a type discriminator for the scan_type/ext_scan_type union. A union is used so that we don't grow the size of the iio_channel structure and also makes it clear that scan_type and ext_scan_type are mutually exclusive. The buffer code is the only code in the IIO core code that is using the scan_type field. This patch updates the buffer code to use the new iio_channel_validate_scan_type() function to ensure it is returning the correct scan type for the current state of the device when reading the sysfs attributes. The buffer validation code is also update to validate any additional scan types that are set in the scan_type_ext field. Part of that code is refactored to a new function to avoid duplication. Some userspace tools may need to be updated to re-read the scan type after writing any other attribute. During testing, we noticed that we had to restart iiod to get it to re-read the scan type after enabling oversampling on the ad7380 driver. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-3-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: buffer: use struct iio_scan_type to simplify codeDavid Lechner
By using struct iio_scan_type, we can simplify the code by removing lots of duplicate pointer dereferences. This make the code a bit easier to read. This also prepares for a future where channels may have more than one scan_type. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-2-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: add support for ad738x-4 4 channels variantsJulien Stephan
Add support for ad7380/1/2/3-4 parts which are 4 channels variants from ad7380/1/2/3 Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://lore.kernel.org/r/20240528-adding-new-ad738x-driver-v7-7-4cd70a4c12c8@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: prepare for parts with more channelsJulien Stephan
The current driver supports only parts with 2 channels. In order to prepare the support of new compatible ADCs with more channels, this commit: - defines MAX_NUM_CHANNEL to specify the maximum number of channels currently supported by the driver - adds available_scan_mask member in ad7380_chip_info structure - fixes spi xfer struct len depending on number of channels - fixes scan_data.raw buffer size to handle more channels - adds a timing specifications structure in ad7380_chip_info structure Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://lore.kernel.org/r/20240528-adding-new-ad738x-driver-v7-5-4cd70a4c12c8@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: add support for pseudo-differential partsDavid Lechner
Add support for AD7383, AD7384 pseudo-differential compatible parts. Pseudo differential parts require common mode voltage supplies so add the support for them and add the support of IIO_CHAN_INFO_OFFSET to retrieve the offset Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://lore.kernel.org/r/20240528-adding-new-ad738x-driver-v7-4-4cd70a4c12c8@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: ad7380: new driver for AD7380 ADCsDavid Lechner
This adds a new driver for the AD7380 family ADCs. The driver currently implements basic support for the AD7380, AD7381, 2-channel differential ADCs. Support for additional single-ended, pseudo-differential and 4-channel chips that use the same register map as well as additional features of the chip will be added in future patches. [Julien Stephan: fix rx/tx buffer for regmap access] [Julien Stephan: fix scale issue] [Julien Stephan: use the new iio_device_claim_direct_scoped instead of iio_device_claim_direct_mode] Co-developed-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Stefan Popa <stefan.popa@analog.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> [Julien Stephan: add datasheet links of supported parts] Signed-off-by: Julien Stephan <jstephan@baylibre.com> Link: https://lore.kernel.org/r/20240528-adding-new-ad738x-driver-v7-2-4cd70a4c12c8@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: adi-axi-adc: make sure DRP is locked on enableNuno Sa
When enabling the core, make sure DRP (Dynamic Reconfiguration Port) is locked. Most of the designs don't really use it but we still get the lock bit set. So let's do it all the time so the code is generic. While at it reduce the timeout time to 1 microsecond as it seems to be enough and goes in line with what we have on the similar DAC core (adi-axi-dac). Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240531-dev-axi-adc-drp-v3-2-e3fa79447c67@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-06-04iio: adc: adi-axi-adc: don't allow concurrent enable/disable callsNuno Sa
Add proper mutex guards as we should not be able to disable the core in the middle of enabling it. Note there's no need to rush in backporting this as the only user of the backend does not do anything crazy.. Fixes: 794ef0e57854 ("iio: adc: adi-axi-adc: move to backend framework") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240531-dev-axi-adc-drp-v3-1-e3fa79447c67@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>