Lothar Rubusch [Sat, 28 Dec 2024 23:29:49 +0000 (23:29 +0000)]
iio: accel: adxl345: complete the list of defines
Having interrupts events and FIFO available allows to evaluate the
sensor events. Cover the list of interrupt based sensor events. Keep
them in the header file for readability.
Lothar Rubusch [Sat, 28 Dec 2024 23:29:48 +0000 (23:29 +0000)]
iio: accel: adxl345: add FIFO with watermark events
Add a basic setup for FIFO with configurable watermark. Add a handler
for watermark interrupt events and extend the channel for the
scan_index needed for the iio channel. The sensor is configurable to use
a FIFO_BYPASSED mode or a FIFO_STREAM mode. For the FIFO_STREAM mode now
a watermark can be configured, or disabled by setting 0. Further features
require a working FIFO setup.
Lothar Rubusch [Sat, 28 Dec 2024 23:29:47 +0000 (23:29 +0000)]
iio: accel: adxl345: initialize FIFO delay value for SPI
Add the possibility to delay FIFO access when SPI is used. According to
the datasheet this is needed for the adxl345. When initialization
happens over SPI the need for delay is to be signalized, and the delay
will be used.
Lothar Rubusch [Sat, 28 Dec 2024 23:29:46 +0000 (23:29 +0000)]
iio: accel: adxl345: introduce interrupt handling
Add the possibility to claim an interrupt. Init the state structure
with an interrupt line obtained from the DT. The adxl345 can use
two different interrupt lines for event handling. Only one is used.
Javier Carrasco [Mon, 30 Dec 2024 15:13:53 +0000 (16:13 +0100)]
iio: light: veml3235: fix scale to conform to ABI
The current scale is not ABI-compliant as it is just the sensor gain
instead of the value that acts as a multiplier to be applied to the raw
value (there is no offset).
Use the iio-gts helpers to obtain the proper scale values according to
the gain and integration time to match the resolution tables from the
datasheet. When at it, use 'scale' instead of 'gain' consistently for
the get/set functions to avoid misunderstandings.
Fixes: c5a23f80c164 ("iio: light: add support for veml3235") Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20241230-veml3235_scale-v3-2-48a5795e2f64@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Javier Carrasco [Mon, 30 Dec 2024 15:13:52 +0000 (16:13 +0100)]
iio: gts-helper: add helpers to ease searches of gain_sel and new_gain
This helper functions reduce the burden in the drivers that want to
fetch a gain and time selector for a given scale or a new optimal gain.
The former is currently achieved by calling
iio_gts_find_gain_sel_for_scale_using_time() for the current time
selector, and then iterating over the rest of time selectors if the
gain selector was not found.
The latter requires a combination of multiple iio-gts helpers to find
the new gain, look for an optimal gain if there was no exact match, and
set a minimum gain if the optimal gain is not in the range of available
gains.
Provide simpler workflows by means of functions that address common
patterns in the users of the iio-gts helpers.
Javier Carrasco [Tue, 24 Dec 2024 10:59:02 +0000 (11:59 +0100)]
iio: light: veml3235: extend regmap to add cache
The configuration and ID registers are not volatile and are not affected
by read operations (i.e. not precious), making them suitable to be
cached in order to reduce the number of accesses to the device.
Add interrupt-names INT1 and INT2 for the two interrupt lines of the
sensor.
When one of the two interrupt lines is connected, the interrupt as its
interrupt-name, need to be declared in the devicetree. The driver then
configures the sensor to indicate its events on either INT1 or INT2.
If no interrupt is configured, then no interrupt-name should be
configured, and vice versa. In this case the sensor runs in FIFO BYPASS
mode. This allows sensor measurements, but none of the sensor events.
Simply check the max_register value to decide whether
MESON_SAR_ADC_REG11 is present on the current IP revision. This allows
dropping two additional bool fields from struct meson_sar_adc_param
which previously had to be manually kept in sync. No functional changes
intended.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:11 +0000 (18:29 +0000)]
iio: adc: rockchip: correct alignment of timestamp
I assume this device is only used on architectures where a 8 byte
integer type is always 8 byte aligned. However, I would prefer IIO
drivers to never make that assumption as the code gets copied into
new drivers which are not so tightly couple to one driver and those
can run on architectures that align these types to only 4 bytes in which
case this structure may be 4 byte to small leading to a buffer overrun.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:09 +0000 (18:29 +0000)]
iio: imu: inv_icm42600: switch timestamp type from int64_t __aligned(8) to aligned_s64
The vast majority of IIO drivers use aligned_s64 for the type of the
timestamp field. It is not a bug to use int64_t and until this series
iio_push_to_buffers_with_timestamp() took and int64_t timestamp, it
is inconsistent. This change is to remove that inconsistency and
ensure there is one obvious choice for future drivers.
Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241215182912.481706-19-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 15 Dec 2024 18:29:08 +0000 (18:29 +0000)]
iio: chemical: scd4x: switch timestamp type from int64_t __aligned(8) to aligned_s64
The vast majority of IIO drivers use aligned_s64 for the type of the
timestamp field. It is not a bug to use int64_t and until this series
iio_push_to_buffers_with_timestamp() took and int64_t timestamp, it
is inconsistent. This change is to remove that inconsistency and
ensure there is one obvious choice for future drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:07 +0000 (18:29 +0000)]
iio: adc: ti-lmp92064: Switch timestamp type from int64_t __aligned(8) to aligned_s64
The vast majority of IIO drivers use aligned_s64 for the type of the
timestamp field. It is not a bug to use int64_t and until this series
iio_push_to_buffers_with_timestamp() took and int64_t timestamp, it
is inconsistent. This change is to remove that inconsistency and
ensure there is one obvious choice for future drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:05 +0000 (18:29 +0000)]
iio: accel: bma220: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:04 +0000 (18:29 +0000)]
iio: adc: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:03 +0000 (18:29 +0000)]
iio: chemical: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:02 +0000 (18:29 +0000)]
iio: gyro: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:01 +0000 (18:29 +0000)]
iio: humidity: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:29:00 +0000 (18:29 +0000)]
iio: imu: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:59 +0000 (18:28 +0000)]
iio: light: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Acked-By: Matti Vaittinen <mazziesaccount@gmail.com> #For bu27034, rpr0521 Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241215182912.481706-9-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 15 Dec 2024 18:28:58 +0000 (18:28 +0000)]
iio: magnetometer: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:57 +0000 (18:28 +0000)]
iio: pressure: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Acked-By: Matti Vaittinen <mazziesaccount@gmail.com> #for the BD1390 Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241215182912.481706-7-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan Cameron [Sun, 15 Dec 2024 18:28:56 +0000 (18:28 +0000)]
iio: proximity: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:55 +0000 (18:28 +0000)]
iio: resolver: ad2s1210: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:54 +0000 (18:28 +0000)]
iio: temperature: tmp006: Use aligned_s64 instead of open coding alignment.
Use this new type to both slightly simplify the code and avoid
confusing static analysis tools. Mostly this series is about consistency
to avoid this code pattern getting copied into more drivers.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:53 +0000 (18:28 +0000)]
io: adc: ina2xx-adc: Fix sign and use aligned_s64 for timestamp.
Whilst it doesn't actually make any difference because the code
that fills this field doesn't care, timestamps are all signed.
Use the new aligned_s64 instead of open coding alignment to avoid
confusing static analyzers and give slightly cleaner code.
Jonathan Cameron [Sun, 15 Dec 2024 18:28:52 +0000 (18:28 +0000)]
iio: adc: ad7944: Fix sign and use aligned_s64 for timestamp.
Whilst it doesn't actually make any difference because the code
that fills this field doesn't care, timestamps are all signed.
Use the new aligned_s64 instead of open coding alignment to avoid
confusing static analyzers and give slightly cleaner code.
Fabrice Gasnier [Fri, 20 Dec 2024 09:59:21 +0000 (10:59 +0100)]
iio: trigger: stm32-timer: add support for stm32mp25
Add support for STM32MP25 SoC. Use newly introduced compatible to handle
this new HW variant. Add TIM20 trigger definitions that can be used by
the stm32 analog-to-digital converter. Use compatible data to identify
it.
As the counter framework is now superseding the deprecated IIO counter
interface (IIO_COUNT), don't support it. Only register IIO trigger
devices for ADC usage. So, make the valids_table a cfg option.
Configuration information is now prioritized from the firmware file.
If the firmware file is missing or fails to parse, the driver falls
back to using the default configuration list for writing the settings.
The ROHM BD79703 is a 6 channel digital to analog converter.
Based on the data-sheet examples the hardware would support setting the
DAC word without changing the actual output. The data-sheet is not too
specific on how the enabling the output of new voltage set by DAC
should be done - hence this is not implemented by the driver.
The BD79703 would also support two specific "PULL_DOWN" modes. These
aren't currently supported by the driver either.
Add a very basic support for controlling the channel outputs one-by-one.
Thomas Weißschuh [Sun, 15 Dec 2024 15:21:24 +0000 (16:21 +0100)]
iio: imu: bno055: constify 'struct bin_attribute'
The sysfs core now allows instances of 'struct bin_attribute' to be
moved into read-only memory. Make use of that to protect them against
accidental or malicious modifications.
Vasileios Amoiridis [Sat, 14 Dec 2024 19:14:21 +0000 (20:14 +0100)]
iio: core: mark scan_timestamp as __private
Since there are no more direct accesses to the indio_dev->scan_timestamp
value, it can be marked as __private and use the macro ACCESS_PRIVATE()
in order to access it. Like this, static checkers will be able to inform
in case someone tries to either write to the value, or read its value
directly.
Vasileios Amoiridis [Sat, 14 Dec 2024 19:14:20 +0000 (20:14 +0100)]
iio: common: ssp_sensors: drop conditional optimization for simplicity
Drop conditional in favor of always calculating the timestamp value.
This simplifies the code and allows to drop usage of internal private
variable "scan_timestamp" of the struct iio_dev.
Vasileios Amoiridis [Sat, 14 Dec 2024 19:14:19 +0000 (20:14 +0100)]
iio: adc: max1363: Use a small fixed size buffer to replace dynamic allocation
Drop the recurrent allocation of the data buffer from the trigger
handler and put it in the iio_priv(). This way, the maximum amount of
channels is always allocated in favor of simpler code and drop
of usage of the internal private variable "scan_timestamp" of the
struct iio_dev.
Vasileios Amoiridis [Sat, 14 Dec 2024 19:14:18 +0000 (20:14 +0100)]
iio: adc: dln2-adc: zero full struct instead of just the padding
Drop a minor optimization of zeroing the padding between data and
timestamp and zero the whole structure. This is done in favor of
simpler code, and in order to drop the usage of the internal private
variable "scan_timestamp" of the struct iio_dev.
David Lechner [Mon, 16 Dec 2024 21:44:03 +0000 (15:44 -0600)]
iio: dac: ad7293: enable power before reset
Change the order of regulator enable and reset so that power supplies
are turned on before touching the reset line. Generally, chips should
have the VDRIVE supply enabled before applying voltage on any pins.
While we are at it, remove the voltage level checks. If the power
supplies are not supplying the correct voltage, this is a hardware
design problem, not a software problem.
David Lechner [Mon, 16 Dec 2024 23:29:36 +0000 (17:29 -0600)]
iio: ABI: use Y consistently as channel number
Change X to Y when referring to channel number in the ABI documentation.
There were only a few cases using X (and one using Z). By far, most
documented attributes are using Y for the channel number placeholder.
For consistency, we should follow the same convention throughout.
Lothar Rubusch [Fri, 13 Dec 2024 21:19:03 +0000 (21:19 +0000)]
iio: accel: adxl345: add function to switch measuring mode
Replace the powerup / powerdown functions by a generic function to put
the sensor in STANDBY, or MEASURE mode. When configuring the FIFO for
several features of the accelerometer, it is recommended to put
measuring in STANDBY mode.
Guillaume Ranquet [Mon, 2 Dec 2024 10:09:52 +0000 (11:09 +0100)]
iio: adc: ad7173: add calibration support
The ad7173 family of chips has up to four calibration modes.
Internal zero scale: removes ADC core offset errors.
Internal full scale: removes ADC core gain errors.
System zero scale: reduces offset error to the order of channel noise.
System full scale: reduces gain error to the order of channel noise.
All voltage channels will undergo an internal zero/full scale
calibration at bootup.
System zero/full scale can be done after bootup using the newly created
iio interface 'sys_calibration' and 'sys_calibration_mode'
Marcelo Schmitt [Mon, 2 Dec 2024 14:08:30 +0000 (11:08 -0300)]
iio: adc: ad4000: Add support for PulSAR devices
The ADI PulSAR series of single-channel devices comprises differential and
pseudo-differential ADCs that don't require any input data from the host
controller. By not requiring a data input line, PulSAR devices can operate
with a 3-wire only data bus in some setups.
The AD4000 series and the single-channel PulSAR series of devices have
similar SPI transfer specifications and wiring configurations.
Single-channel PulSAR devices are slower than AD4000 and don't have a
configuration register. That taken into account, single-channel PulSARs can
be supported by the ad4000 driver without any increase in code complexity.
Extend the AD4000 driver to also support single-channel PulSAR devices.
Marcelo Schmitt [Mon, 2 Dec 2024 14:08:13 +0000 (11:08 -0300)]
iio: adc: ad4000: Use device specific timing for SPI transfers
The SPI transfers for AD4020, AD4021, and AD4022 have slightly different
timing specifications. Use device specific timing constraints to set SPI
transfer parameters. While tweaking time constraints, remove time related
defines including unused AD4000_TQUIET1_NS.
Marcelo Schmitt [Mon, 2 Dec 2024 14:07:56 +0000 (11:07 -0300)]
iio: adc: ad4000: Add timestamp channel
The ADC data is pushed to the IIO buffer along with timestamp but no
timestamp channel was provided to retried the time data.
Add a timestamp channel to provide sample capture time.
Marcelo Schmitt [Mon, 2 Dec 2024 14:07:38 +0000 (11:07 -0300)]
dt-bindings: iio: adc: adi,ad4000: Add PulSAR
Extend the AD4000 series device tree documentation to also describe
PulSAR devices.
The single-channel series of PulSAR devices is similar to the AD4000 series
except PulSAR devices sample at slower rates and don't have a
configuration register. Because PulSAR devices don't have a configuration
register, they don't support all features of AD4000 devices and thus fewer
interfaces are provided to user space. Also, while AD4000 may have their
SDI pin connected to SPI host MOSI line, PulSAR SDI pin is never connected
to MOSI.
Some devices within the PulSAR series are just faster versions of others.
>From fastest to slowest, AD7980, AD7988-5, AD7686, AD7685, and AD7988-1 are
all 16-bit pseudo-differential pin-for-pin compatible ADCs. Devices that
only vary on the sample rate are documented with a common fallback
compatible.
Matteo Martelli [Mon, 2 Dec 2024 15:11:07 +0000 (16:11 +0100)]
iio: consumers: ensure read buffers for labels and ext_info are page aligned
Attributes of iio providers are exposed via sysfs. Typically, providers
pass attribute values to the iio core, which handles formatting and
printing to sysfs. However, some attributes, such as labels or extended
info, are directly formatted and printed to sysfs by provider drivers
using sysfs_emit() and sysfs_emit_at(). These helpers assume the read
buffer, allocated by sysfs fop, is page-aligned. When these attributes
are accessed by consumer drivers, the read buffer is allocated by the
consumer and may not be page-aligned, leading to failures in the
provider's callback that utilizes sysfs_emit*.
Add a check to ensure that read buffers for labels and external info
attributes are page-aligned. Update the prototype documentation as well.
Vasileios Amoiridis [Mon, 2 Dec 2024 18:19:07 +0000 (19:19 +0100)]
iio: pressure: bmp280: Make time vars intuitive and move to fsleep
Move sleep functions to the new fsleep() implementation. While at it,
add time unit abbreviation as a suffix of time describing variables to
make them more intuitive.
Lothar Rubusch [Thu, 5 Dec 2024 17:13:35 +0000 (17:13 +0000)]
iio: accel: adxl345: rename variable data to st
Rename the locally used variable data to st. The st refers to "state",
representing the internal state of the driver object. Further it
prepares the usage of an internal data pointer needed for the
implementation of the sensor features.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:40 +0000 (18:28 +0100)]
iio: adc: ad_sigma_delta: Check for previous ready signals
It can happen if a previous conversion was aborted the ADC pulls down
the R̅D̅Y̅ line but the event wasn't handled before. In that case enabling
the irq might immediately fire (depending on the irq controller
capabilities) and even with a rdy-gpio isn't identified as an unrelated
one.
To cure that problem check for a pending event before the measurement is
started and clear it if needed.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:39 +0000 (18:28 +0100)]
iio: adc: ad_sigma_delta: Store information about reset sequence length
The various chips can be reset using a sequence of SPI transfers with
MOSI = 1. The length of such a sequence varies from chip to chip. Store
that length in struct ad_sigma_delta_info and replace the respective
parameter to ad_sd_reset() with it.
Note the ad7192 used to pass 48 as length but the documentation
specifies 40 as the required length. Assuming the latter is right.
(Using a too long sequence doesn't hurt apart from using a longer spi
transfer than necessary, so this is no relevant fix.)
The motivation for storing this information is that this is useful to
clear a pending R̅D̅Y̅ signal in the next change.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:38 +0000 (18:28 +0100)]
iio: adc: ad_sigma_delta: Fix a race condition
The ad_sigma_delta driver helper uses irq_disable_nosync(). With that
one it is possible that the irq handler still runs after the
irq_disable_nosync() function call returns. Also to properly synchronize
irq disabling in the different threads proper locking is needed and
because it's unclear if the irq handler's irq_disable_nosync() call
comes first or the one in the enabler's error path, all code locations
that disable the irq must check for .irq_dis first to ensure there is
exactly one disable call per enable call.
So add a spinlock to the struct ad_sigma_delta and use it to synchronize
irq enabling and disabling. Also only act in the irq handler if the irq
is still enabled.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:37 +0000 (18:28 +0100)]
iio: adc: ad_sigma_delta: Handle CS assertion as intended in ad_sd_read_reg_raw()
When struct ad_sigma_delta::keep_cs_asserted was introduced only
register writing was adapted to honor this new flag. Also respect it
when reading a register.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:36 +0000 (18:28 +0100)]
iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO
Some of the ADCs by Analog signal their irq condition on the MISO line.
So typically that line is connected to an SPI controller and a GPIO. The
GPIO is used as input and the respective interrupt is enabled when the
last SPI transfer is completed.
Depending on the GPIO controller the toggling MISO line might make the
interrupt pending even while it's masked. In that case the irq handler
is called immediately after irq_enable() and so before the device
actually pulls that line low which results in non-sense values being
reported to the upper layers.
The only way to find out if the line was actually pulled low is to read
the GPIO. (There is a flag in AD7124's status register that also signals
if an interrupt was asserted, but reading that register toggles the MISO
line and so might trigger another spurious interrupt.)
Add the possibility to specify an interrupt GPIO in the machine
description in addition to the plain interrupt. This GPIO is used then
to check if the irq line is actually active in the irq handler.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:35 +0000 (18:28 +0100)]
dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line
For the AD7124 chip and some of its cousins the logical irq line (R̅D̅Y̅)
is physically on the same pin as the spi MISO output (DOUT) and so
reading a register might trigger an interrupt. For correct operation
it's critical that the actual state of the pin can be read to judge if
an interrupt event is a real one or just a spurious one triggered by
toggling the line in its MISO mode.
Allow specification of an "rdy-gpios" property that references a GPIO
that can be used for that purpose. While this is typically the same GPIO
also used (implicitly) as interrupt source, it is still supposed that
the interrupt is specified as before and usual.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:34 +0000 (18:28 +0100)]
iio: adc: ad7124: Refuse invalid input specifiers
The ad7124-4 has 8 analog inputs; the input select values 8 to 15 are
reserved and not to be used. These are fine for ad7124-8. For both
ad7124-4 and ad7124-8 values bigger than 15 are internal channels that
might appear as inputs in the channels specified in the device
description according to the description of commit f1794fd7bdf7 ("iio:
adc: ad7124: Remove input number limitation"), values bigger than 31
don't fit into the respective register bit field and the driver masked
them to smaller values.
Check for these invalid input specifiers and fail to probe if one is
found.
Uwe Kleine-König [Fri, 6 Dec 2024 17:28:33 +0000 (18:28 +0100)]
iio: adc: ad7124: Don't create more channels than the driver can handle
The ad7124-4 and ad7124-8 both support 16 channel registers and assigns
each channel defined in dt statically such a register. While the driver
could be a bit more clever about this, it currently isn't and specifying
more than 16 channels yields broken behaviour. So just refuse to bind in
this situation.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:35 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Add support for Renesas RZ/G3S
Add ADC support for the Renesas RZ/G3S SoC. The key features of this IP
include:
- 9 channels, with one dedicated to reading the temperature reported by the
Thermal Sensor Unit (TSU)
- A different default ADCMP value, which is written to the ADM3 register.
- Different default sampling rates
- ADM3.ADSMP field is 8 bits wide
- ADINT.INTEN field is 11 bits wide
Document the ADC IP available on the RZ/G3S SoC. The ADC IP on the RZ/G3S
differs slightly from the one found on the RZ/G2L. The identified
differences are as follows:
- different number of channels (one being used for temperature conversion);
consequently, various registers differ; the temperature channel
support was not available for the RZ/G2L variant; the #io-channel-cells
property was added to be able to request the temperature channel from
the thermal driver
- different default sampling periods
- the RZ/G3S variant lacks the ADVIC register.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:33 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Add suspend/resume support
The Renesas RZ/G3S SoC features a power-saving mode where power to most of
the SoC components is turned off, including the ADC IP.
Suspend/resume support has been added to the rzg2l_adc driver to restore
functionality after resuming from this power-saving mode. During suspend,
the ADC resets are asserted, and the ADC is powered down. On resume, the
ADC resets are de-asserted, the hardware is re-initialized, and the ADC
power is restored using the runtime PM APIs.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:32 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Add support for channel 8
The ADC on the Renesas RZ/G3S SoC includes an additional channel (channel
8) dedicated to reading temperature values from the Thermal Sensor Unit
(TSU). There is a direct in-SoC connection between the ADC and TSU IPs.
To read the temperature reported by the TSU, a different sampling rate
(compared to channels 0-7) must be configured in the ADM3 register.
The rzg2l_adc driver has been updated to support reading the TSU
temperature.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:31 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Prepare for the addition of RZ/G3S support
The ADC IP available on the RZ/G3S differs slightly from the one found on
the RZ/G2L. The identified differences are as follows:
- different number of channels (one being used for temperature conversion);
consequently, various registers differ
- different default sampling periods
- the RZ/G3S variant lacks the ADVIC register.
To accommodate these differences, the rzg2l_adc driver has been updated by
introducing the struct rzg2l_adc_hw_params, which encapsulates the
hardware-specific differences between the IP variants. A pointer to an
object of type struct rzg2l_adc_hw_params is embedded in
struct rzg2l_adc_data.
Additionally, the completion member of struct rzg2l_adc_data was relocated
to avoid potential padding, if any.
The code has been adjusted to utilize hardware-specific parameters stored
in the new structure instead of relying on plain macros.
The check of chan->channel in rzg2l_adc_read_raw() function, against the
driver specific mask was removed as the subsystem should have already
been done this before reaching the rzg2l_adc_read_raw() function. Along
with it the local variable ch was dropped as chan->channel could be used
instead.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:30 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Enable runtime PM autosuspend support
Enable runtime PM autosuspend support for the rzg2l_adc driver. With this
change, consecutive conversion requests will no longer cause the device to
be runtime-enabled/disabled after each request. Instead, the device will
transition based on the delay configured by the user.
This approach reduces the frequency of hardware register access during
runtime PM suspend/resume cycles, thereby saving CPU cycles.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:28 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Use read_poll_timeout()
Replace the driver-specific implementation with the read_poll_timeout()
function. This change simplifies the code and improves maintainability by
leveraging the standardized helper.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:27 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Switch to RUNTIME_PM_OPS() and pm_ptr()
The use of SET_RUNTIME_PM_OPS() is now deprecated and requires
__maybe_unused annotations to avoid warnings about unused functions.
Switching to RUNTIME_PM_OPS() and pm_ptr() eliminates the need for such
annotations because the compiler can directly reference the runtime PM
functions, thereby suppressing the warnings. As a result, the
__maybe_unused markings can be removed.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:26 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Simplify the runtime PM code
All Renesas SoCs using the rzg2l_adc driver manage ADC clocks through PM
domains. Calling pm_runtime_{resume_and_get, put_sync}() implicitly sets
the state of the clocks. As a result, the code in the rzg2l_adc driver that
explicitly manages ADC clocks can be removed, leading to simpler and
cleaner implementation.
Additionally, replace the use of rzg2l_adc_set_power() with direct PM
runtime API calls to further simplify and clean up the code.
Claudiu Beznea [Fri, 6 Dec 2024 11:13:25 +0000 (13:13 +0200)]
iio: adc: rzg2l_adc: Use devres helpers to request pre-deasserted reset controls
Starting with commit d872bed85036 ("reset: Add devres helpers to request
pre-deasserted reset controls"), devres helpers are available to simplify
the process of requesting pre-deasserted reset controls. Update the
rzg2l_adc driver to utilize these helpers, reducing complexity in this
way.
Matti Vaittinen [Fri, 6 Dec 2024 09:26:42 +0000 (11:26 +0200)]
iio: kx022a: document new chip_info structure members
The kx022a driver supports a few different HW variants. A chip-info
structure is used to describe sensor specific details. Support for
sensors with different measurement g-ranges was added recently,
introducing sensor specific scale arrays.
The members of the chip-info structure have been documented using
kerneldoc. The newly added members omitted the documentation. It is nice
to have all the entries documented for the sake of the consistency.
Furthermore, the scale table format may not be self explatonary, nor how
the amount of scales is informed.
Add documentation to scale table entries to maintain consistency and to
make it more obvious how the scales should be represented.
Suggested-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Link: https://patch.msgid.link/Z1LDUj-naUdGSM6n@mva-rohm Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
17366 1454 16 18836 4994 drivers/iio/proximity/aw96103.o
After:
=====
text data bss dec hex filename
17526 1294 16 18836 4994 drivers/iio/proximity/aw96103.o
Javier Carrasco [Sun, 24 Nov 2024 18:59:06 +0000 (19:59 +0100)]
iio: light: veml6030: add support for triggered buffer
All devices supported by this driver (currently veml6030, veml6035
and veml7700) have two 16-bit channels, and can profit for the same
configuration to support data access via triggered buffers.
The measurements are stored in two 16-bit consecutive registers
(addresses 0x04 and 0x05) as little endian, unsigned data.
projects / users / jedix / linux-maple.git / log