- 04 Jun, 2024 40 commits
-
-
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:
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.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
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:
Conor Dooley <conor.dooley@microchip.com> Signed-off-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:
-
Angelo Dureghello authored
The adi,gain-scaling-p/n values are an inverted log2, so initial naming was set correctly, but the driver uses just adi,gain-scaling-p/n, and if fdt is created accordingly with the fdt bindings documentation, driver fails the probe. Observing that: - the Linux driver is the only consumer, - there are no upstreamed dts nodes related to ad3552r, the fix to the documentation side is preferred and less-risk. Fixes: b0a96c5f ("dt-bindings: iio: dac: Add adi,ad3552r.yaml") Signed-off-by:
-
Nuno Sa authored
Using tabs and maintaining the start of the variables aligned is a pain and may lead to lot's of unrelated changes when adding new members. Hence, let's change things now and just have a simple space. Signed-off-by:
-
Nuno Sa authored
Make sure we use a DMA safe buffer (IIO_DMA_MINALIGN) for all the spi transfers. Only relevant for writes since for reads spi_write_then_read() is used which does not require DMA safe buffers. Also note that for consistency, ad9467_spi_read() is also taking struct ad9467_state as a parameter (even if not really needed). Fixes: ad679712 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by:
-
Barnabás Czémán authored
Add support for more stk3311 variants like stk3311-a and stk3311-s34, they are register compatible but they have different chip ids. Signed-off-by:
Barnabás Czémán <trabarni@gmail.com> Link: https://lore.kernel.org/r/20240521-stk3311-v1-3-07a4966b355a@gmail.comSigned-off-by:
-
Barnabás Czémán authored
Modify chip id check for support easier additions for compatible variants. Signed-off-by:
-
Barnabás Czémán authored
Relax failure to match ID to a warning rather than probe fail. This add abilty to use other compatible variants when chip id is not defined in the driver. Signed-off-by:
-
Dr. David Alan Gilbert authored
'bu27034_result' is unused since the original commit e52afbd6 ("iio: light: ROHM BU27034 Ambient Light Sensor"). Remove it. Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/20240522230457.478156-4-linux@treblig.orgSigned-off-by:
-
Dr. David Alan Gilbert authored
'samp_rate_mapping' has been unused since the original commit 0fb528c8 ("iio: adc: adding support for PAC193x"). Remove it. Signed-off-by:
-
Dr. David Alan Gilbert authored
'bmi088_scale_info' has been unused since the original commit c19ae6be ("iio: accel: Add support for the Bosch-Sensortec BMI088"). Remove it. Signed-off-by:
-
Alisa-Dariana Roman authored
Unlike the other AD719Xs, AD7194 has configurable channels. The user can dynamically configure them in the devicetree. Add sigma_delta_info member to chip_info structure. Since AD7194 is the only chip that has no channel sequencer, num_slots should remain undefined. Also modify config AD7192 description for better scaling. Signed-off-by:
Alisa-Dariana Roman <alisa.roman@analog.com> Link: https://lore.kernel.org/r/20240514120222.56488-7-alisa.roman@analog.comSigned-off-by:
-
Alisa-Dariana Roman authored
Unlike the other AD719Xs, AD7194 has configurable channels. The user can dynamically configure them in the devicetree. Also add an example for AD7194 devicetree. Signed-off-by:
-
Alisa-Dariana Roman authored
Devices that have both single-ended channels and differential channels cause a bit of confusion when the channels are configured in the devicetree. Clarify difference between these two types of channels for such devices by adding single-channel property alongside diff-channels. They should be mutually exclusive. Devices that have only single-ended channels can still use reg property to reference a channel like before. Suggested-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
