- 08 Jun, 2024 2 commits
-
-
Bruna Bispo authored
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.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Ramona Gradinariu authored
Add documentation for adis16480 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> Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240528142409.239187-7-ramona.gradinariu@analog.comSigned-off-by:
-
- 04 Jun, 2024 38 commits
-
-
Ramona Gradinariu authored
Add documentation for IIO interfacing tools describing the available tools which can be used to retrieve data from IIO sysfs. Reference this documentation in adis16475.rst Signed-off-by:
-
Ramona Gradinariu authored
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:
-
Ramona Gradinariu authored
Add ADIS16545/47 compatibles. Each newly added device has a different angular velocity/linear acceleration scale combination, as follows: Accel dynamic range: - 8g: ADIS16545 - 40g: ADIS16547 Gyro dynamic range: - 125 deg/sec: ADIS1545-1, ADIS16547-1 - 450 deg/sec: ADIS1545-2, ADIS16547-2 - 2000 deg/sec: ADIS1545-3, ADIS16547-3 Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Ramona Gradinariu authored
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 authored
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:
-
Ramona Gradinariu authored
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.comSigned-off-by:
-
Ramona Gradinariu authored
Add ADIS1657X family devices compatibles and specify the according maximum SPI baudrate. Similarly to other ADIS1650X devices, ADIS1657X supports sync-mode values [0,2]. Each newly added device has a different angular velocity/linear acceleration/ delta velocity scale combination, as follows: Accel dynamic range sensitivity: - 262144000 LSB/g: ADIS16575 - 52428800 LSB/g: ADIS16576, ADIS16577 Gyro dynamic range sensitivity: - 2621440 LSB/deg/sec: ADIS1575-2, ADIS1576-2, ADIS1577-2 - 655360 LSB/deg/sec: ADIS1575-3, ADIS1576-3, ADIS1577-3 Delta velocity sensitivity: - 2^15/100 LSB/m/sec: ADIS16575 - 2^15/125 LSB/m/sec: ADIS16576 - 2^15/400 LSB/m/sec: ADIS16577 Each ADIS1657X device supports FIFO usage and a sample-rate of 4.1KHz, meanwhile the already existing devices do not support FIFO usage and have a maximum sample-rate of 2.1KHz. Reviewed-by:
-
Ramona Gradinariu authored
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 authored
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:
-
Ramona Gradinariu authored
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:
-
Ramona Gradinariu authored
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:
-
Ramona Gradinariu authored
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:
-
Ramona Gradinariu authored
Add support for ADIS16501 device in already existing ADIS16475 driver. Reviewed-by:
-
Ramona Gradinariu authored
Add ADIS16501 compatible. Similarly to other ADIS1650X devices, ADIS16501 supports sync-mode values [0,2]. There are two differences between ADIS16501 and ADIS16477-2: - ADIS16501 does not support pulse sync mode - the delta velocity scale value is different Acked-by:
-
Julien Stephan authored
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 authored
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 authored
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 authored
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 authored
This gives the channel scan_type a named type so that it can be used to simplify code in later commits. Signed-off-by:
-
Julien Stephan authored
Add support for ad7380/1/2/3-4 parts which are 4 channels variants from ad7380/1/2/3 Signed-off-by:
-
Julien Stephan authored
Add compatible support for ad7380/1/3/4-4 parts which are 4 channels variants from ad7380/1/3/4 Signed-off-by:
-
Julien Stephan authored
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: -
David Lechner authored
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 authored
Adding AD7383 and AD7384 compatible parts that are pseudo-differential. Pseudo-differential require common mode voltage supplies, so add them conditionally Signed-off-by:
-
David Lechner authored
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:
-
David Lechner authored
This adds a binding specification for the Analog Devices Inc. AD7380 family of ADCs. Signed-off-by:
-
Nuno Sa authored
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 authored
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: 794ef0e5 ("iio: adc: adi-axi-adc: move to backend framework") Signed-off-by:
-
Dr. David Alan Gilbert authored
'adt7316_limit_regs' has never been used since the original commit 35f6b6b8 ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver"). The comment above it is a copy-and-paste from a different struct. Remove both the struct and the comment. Reviewed-by:
Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20240529160055.28489-1-linux@treblig.orgSigned-off-by:
-
Antoniu Miclaus authored
The driver has no clock provider implementation, therefore remove the include. Fixes: 63aaf6d0 ("iio: frequency: adrf6780: add support for ADRF6780") Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20240530092835.36892-1-antoniu.miclaus@analog.comSigned-off-by:
-
Denis Benato authored
bmi150-accel and bmi323-imu are declared in an almost identical way in the ACPI and in some devices such as the Asus RC71L the "ROTM" property can be found: parse and use the ACPI-defined mount-matrix. Co-developed-by:
Luke D. Jones <luke@ljones.dev> Co-developed-by:
Jonathan LoBue <jlobue10@gmail.com> Signed-off-by:
Denis Benato <benato.denis96@gmail.com> Link: https://lore.kernel.org/r/20240523174736.16692-2-benato.denis96@gmail.comSigned-off-by:
-
David Lechner authored
In the ad7944 driver, the ad7944_convert_and_acquire() had an unused `chan` parameter. This patch removes the parameter. Signed-off-by:
-
David Lechner authored
The Makefile for IIO ADC drivers is intended to be sorted alphabetically. I can be tricky to keep it sorted when adding new drivers when not all of the existing drivers are sorted. So let's sort everything now to make it easier to keep it sorted in the future. Signed-off-by:
-
Angelo Dureghello authored
Use same driver file name (ad3552r) for structure names used for all variants. Signed-off-by:
Angelo Dureghello <adureghello@baylibre.com> Reviewed-by:
-
Angelo Dureghello authored
After model data and num_hw_channles introduction, we have: ad3552r_desc, num_ch: used to keep channel number set in fdt, ad35xxr_model_data, num_hw_channels: for max channel checks, AD3552R_NUM_CH: just actually used to define the max array size on allocated arrays. Renaming AD3552R_NUM_CH to a more consistent name, as AD3552R_MAX_CH. Signed-off-by:
-
Angelo Dureghello authored
Add support for single-output DAC variants. Signed-off-by:
-
Angelo Dureghello authored
Add a "model data" structure to keep useful hardware-related information as from datasheet, avoiding id-based conditional choices later on. Removed id-based checks and filled model-specific structures with device specific features, In particular, num_hw_channels is introduced to keep the number of hardware implemented channels, since 1-channel versions of the DACs are added in this same patchset. Signed-off-by:
-
Angelo Dureghello authored
Add support for ad3541r and ad3551r single output variants. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
