There are several issues with the function that implements writing to
the filter_low_pass_3db_frequency property:
- The sinc3 factor should be 0.272 not 0.262 (this is fixed for the
reading side in the previous patch).
- For freq > 1 the if condition is always true so the sinc4 filter is
hardly ever chosen.
- In the nearly always taken if branch the filter is set to sinc3, but
the frequency is set for sinc4. (And vice versa in the else branch.)
This is broken enough to justify the claim that there isn't any serious
user. Also it it counter-intuitive that setting the 3db frequency
modifies the sample frequency and the filter type.
So drop the ability to write that property.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/20250317115247.3735016-7-u.kleine-koenig@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
FPGA HDL projects can include a PWM generator in addition to SPI-Engine.
The PWM IP is used to trigger SPI-Engine offload modules that in turn set
SPI-Engine to execute transfers to poll data from the ADC. That allows data
to be read at the maximum sample rates. Also, it is possible to set a
specific sample rate by setting the proper PWM duty cycle and related state
parameters, thus allowing an adjustable ADC sample rate when a PWM (offload
trigger) is used in combination with SPI-Engine.
Add support for SPI offload.
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/386ce043a0e3fc9e8ff71f17aef8de128ce5869e.1743110188.git.marcelo.schmitt@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM BD79702 is similar to the BD79703, except that it has only 4
channels whereas BD79703 has 6 channels. The channel 'addresses' of the
first two channels (used to identify the channel when data is read over
SPI) are same for both ICs. The next two channels of the BD79702 have
same addresses as the last two channels of the BD79703. This means the
BD79702 channel addresses do not follow the channel numbers with a
constant offset. Thus, we need to specify the addresses separately,
instead of directly deriving them from the channel number with a
constant offset.
It's worth noting that the data-sheet describes the BD79702 as a device
having channels 1,2,5 and 6. The driver however represents channels
0,1,2,3 to the users - with no gaps in the numbering - which may be more
familiar view for the application software.
Support ROHM BD79702 DAC.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/0ba243a63115dd4af03ebf9656c65b8c259a3e34.1743576022.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The BD79700 and BD79701 look like almost exact subsets of the BD79703.
The BD79703 contains 6 channels (channels 0 to 5). The BD79700 provides
only 2 channels, matching the BD79703 channels 0 and 1. The BD79701
provides 3 channels (matching BD79703 channels 0, 1, and 2).
Furthermore, the BD79700 and BD79701 do not have separate VFS pin but
use VCC for the full-scale voltage.
Suopport these ICs using the BD79703 driver.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/845aa45974f6fb81c83046368a24a0674e9a8b0e.1743576022.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM BD79703 needs to identify a channel which we are reading from
in the SPI transfers. This can be seen as an address for the device.
For the bd79703 the address is nicely aligned with the channel number,
so the driver uses the channel ID for the SPI transfers. This, however,
does not need to be the case. The iio_chan_spec has a separate 'address'
field, which we can populate directly with this information.
This helps adding new ICs like the ROHM BD79702 where the channel ID is
different from this address to be handled by this driver, so we don't
need to have separate, IC specific mapping for channel numbers <=>
addresses.
Make the 'address' field in the iio_chan_spec to contain the SPI protocol
address for the channel, and use this value in the transfers.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/e53cb4120d16a3c678e1f391b600af630d6767ce.1743576022.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These new functions allow sparse to find failures to release
direct mode reducing chances of bugs over the claim_direct_mode()
functions that are deprecated.
This case triggered a false positive from sparse, resolved by
factoring out the code that includes the claim and release of
direct mode.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250309170633.1347476-19-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These new functions allow sparse to find failures to release
direct mode reducing chances of bugs over the claim_direct_mode()
functions that are deprecated.
To simplify the code whilst making the change (and avoid potential false
positives from sparse), split the enabling and disabling of thresholds
into separate functions. This could have been done in two steps
by splitting the functions first, but would have meant rewriting
the enable function twice.
Cc: Astrid Rost <astrid.rost@axis.com>
Tested-by: Per-Daniel Olsson <perdaniel.olsson@axis.com>
Reviewed-by: Per-Daniel Olsson <perdaniel.olsson@axis.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250309170633.1347476-18-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warning:
drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c:39:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/Z9lE6IVDeC5lnChN@kspp
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.
So, with these changes, fix the following warning:
drivers/iio/proximity/cros_ec_mkbp_proximity.c:63:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/Z9lEYdPPIyiRGm36@kspp
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Refactor the ad7606 drivers to dynamically allocate the channel info.
The channel info was getting a bit unwieldy. In some cases, the
indio_dev->channels field was getting assigned up to 3 different times,
each in a different function, making it difficult to see where the info
was coming from. This problem stems from the number of permutations of
the channel array needed to support various modes of operation and data
buses. We already have 4 per chip (hardware mode, software mode, AXI ADC
backend and AXI ADC backend with software mode) and we intend to add two
more per chip when adding SPI offload support.
To make it easier to read and maintain, move all of the channel setup
to a single function that dynamically allocates and fills in the channel
info.
Additionally, this lets us remove some hacks where we had to compute an
offset due to the fact that sometimes there was a soft timestamp channel
at the start of the array. Now the timestamp channel is always at the
end of the array as is typical in other drivers.
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250318-iio-adc-ad7606-improvements-v2-9-4b605427774c@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
