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>
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>
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>
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 <adureghello@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240522150141.1776196-6-adureghello@baylibre.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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 <adureghello@baylibre.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240522150141.1776196-4-adureghello@baylibre.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: b0a96c5f59 ("dt-bindings: iio: dac: Add adi,ad3552r.yaml")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240522150141.1776196-2-adureghello@baylibre.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: ad67971202 ("iio: adc: ad9467: add support AD9467 ADC")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240522-dev-ad9467-dma-v2-1-a37bec463632@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: Alisa-Dariana Roman <alisa.roman@analog.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240514120222.56488-5-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace custom attribute filter_low_pass_3db_frequency_available with
standard attribute.
Store the available values in ad7192_state struct.
The function that used to compute those values replaced by
ad7192_update_filter_freq_avail().
Function ad7192_show_filter_avail() is no longer needed.
Note that the initial available values are hardcoded.
Also moved the mutex lock and unlock in order to protect the whole
switch statement since each branch modifies the state of the device.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
Link: https://lore.kernel.org/r/20240514120222.56488-2-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For BMP18x, BMP28x, BME280, BMP38x the reading of the pressure
value requires an update of the t_fine variable which happens
through reading the temperature value.
So all the bmpxxx_read_press() functions of the above sensors
are internally calling the equivalent bmpxxx_read_temp() function
in order to update the t_fine value. By just looking at the code
this functionality is a bit hidden and is not easy to understand
why those channels are not independent.
This commit tries to clear these things a bit by splitting the
bmpxxx_{read/compensate}_{temp/press/humid}() to the following:
i. bmpxxx_read_{temp/press/humid}_adc(): read the raw value from
the sensor.
ii. bmpxx_calc_t_fine(): calculate the t_fine variable.
iii. bmpxxx_get_t_fine(): get the t_fine variable.
iv. bmpxxx_compensate_{temp/press/humid}(): compensate the adc
values and return the calculated value.
v. bmpxxx_read_{temp/press/humid}(): combine calls of the
aforementioned functions to return the requested value.
Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://lore.kernel.org/r/20240512230524.53990-2-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The bmp180_measure() function essentially waits for the end of the
current conversion in order to read the values from the sensors. The
name bmp180_measure() could be misinterpreted because it could be
translated as "measure sensor values" even though it was probably
trying to say "measure time for eoc". Give a more intuitive name
to this function to be less confusing.
Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
Link: https://lore.kernel.org/r/20240429190046.24252-5-vassilisamir@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_gts helpers build available times and scales tables based on the
times and gains arrays given from the driver. The driver should be able
to list all valid register values so that conversion from register valu
to correct gain/time works for all supported register values.
It might be more convenient for drivers to list these times and gains in
the order where they're listed in the data-sheet than ascending order.
However, for user who requests the supported scales / times it is more
convenient to get the results in asscending order. Also, listing
duplicated values is not meaning for the user.
Hence the GTS heler should do sorting and deduplication of the scales
and times when it builds the tables listing the available times/scales.
Note, currently duplicated gain values aren't handled by GTS-helpers.
Unsort the gain and time arrays in the test code, and add duplicates to
time array in order to test the sorting and deduplicating works.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/365cc6de3c17a457db738f5fdf8dd3bd6f50d5f2.1714480171.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The sorting in iio_gts_build_avail_time_table is not working as intended.
It could result in an out-of-bounds access when the time is zero.
Here are more details:
1. When the gts->itime_table[i].time_us is zero, e.g., the time
sequence is `3, 0, 1`, the inner for-loop will not terminate and do
out-of-bound writes. This is because once `times[j] > new`, the value
`new` will be added in the current position and the `times[j]` will be
moved to `j+1` position, which makes the if-condition always hold.
Meanwhile, idx will be added one, making the loop keep running without
termination and out-of-bound write.
2. If none of the gts->itime_table[i].time_us is zero, the elements
will just be copied without being sorted as described in the comment
"Sort times from all tables to one and remove duplicates".
For more details, please refer to
https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.
Reported-by: Chenyuan Yang <chenyuan0y@gmail.com>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: 38416c28e1 ("iio: light: Add gain-time-scale helpers")
Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com>
Co-developed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/d501ade8c1f7b202d34c6404eda423489cab1df5.1714480171.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
