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.
Matti Vaittinen [Thu, 28 Nov 2024 09:03:18 +0000 (11:03 +0200)]
iio: accel: kx022a: Support KX134-1211
The ROHM KX134-1211 has very similar register interface as KX132-1211
does. The main differencies are the content of the "Who am I"
identification register and different g-ranges. The KX132-1211 can
measure ranges from +/- 2g to +/-16g where the KX134-1211 supports
measuring ranges +/- 8g to +/- 64g.
Matti Vaittinen [Thu, 28 Nov 2024 09:03:02 +0000 (11:03 +0200)]
dt-bindings: iio: kx022a: Support KX134-1211
The ROHM KX134-1211 is very similar to KX132-1211. The main difference is
supported g-ranges. The KX132-1211 can measure ranges from +/- 2g to
+/-16g where the KX134-1211 supports measuring ranges +/- 8g to +/- 64g.
Matti Vaittinen [Thu, 28 Nov 2024 09:02:45 +0000 (11:02 +0200)]
iio: kx022a: Support ROHM KX134ACR-LBZ
The register interface of the ROHM KX134ACR-LBZ accelerometer is
almost identical to the KX132ACR-LBZ. The main difference between these
accelerometers is that the KX134ACR-LBZ supports different G-ranges. The
driver can model this by informing different scale to users. Also, the
content of the "who_am_I" register is different.
Matti Vaittinen [Thu, 28 Nov 2024 09:02:29 +0000 (11:02 +0200)]
dt-bindings: ROHM KX134ACR-LBZ
>From the software point of view, the KX134ACR-LBZ is almost identical to
the KX132ACR-LBZ. They, however, have different g ranges and ID register
values which makes them incompatible.
Add compatible and information for ROHM KX134ACR-LBZ accelerometer.
Matti Vaittinen [Thu, 28 Nov 2024 09:02:15 +0000 (11:02 +0200)]
iio: accel: kx022a: Support ICs with different G-ranges
The register interface of the ROHM KX134ACR-LBZ accelerometer is almost
identical to the KX132ACR-LBZ. Main difference between these
accelerometers is that the KX134ACR-LBZ supports G-ranges +/- 8, 16,
32 and 64G. All the other sensors supported by the kx022a driver can
measure +/- 2, 4, 8 and 16G.
Prepare supporting the KX134ACR-LBZ with different G-ranges by storing
a pointer to the scale tables in IC specific structure.
Matti Vaittinen [Thu, 28 Nov 2024 09:01:48 +0000 (11:01 +0200)]
iio: accel: kx022a: Use cleanup.h helpers
A few functions in KX022A need to use mutex for protecting the
enabling/disabling of the measurement while configurations are being
made. Some of the functions can be slightly simplified by using the
__cleanup based scoped mutexes, which allows dropping the goto based
unlocking at error path.
Han Xu [Fri, 15 Nov 2024 22:37:23 +0000 (17:37 -0500)]
iio: gyro: Add support for iam20380 sensor
Add support for the Invensense IAM20380 sensor to the MPU6050 driver. It is
similar to the IAM20680. But IAM20380 only supports gyro and WHOAMI
register data is difference.
Signed-off-by: Han Xu <han.xu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://patch.msgid.link/20241115-iam20380-v2-2-d8d9dc6891f5@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_dmaengine_buffer_setup_ext() function is public and should be
documented. Also, while touching this, fix the description of @dev in
related functions. @dev does not strictly have to be the parent of the
IIO device. It is only passed to dma_request_chan() so strictly
speaking, it can be any device that is a valid DMA channel consumer.
Cibil Pankiras [Thu, 14 Nov 2024 09:13:23 +0000 (10:13 +0100)]
iio: light: cm3232: Reset before reading HW ID
According to the datasheet, the chip requires a reset before any data
can be read. This commit moves the device identification logic to
occur after the reset to ensure proper initialization.
David Lechner [Wed, 13 Nov 2024 16:55:19 +0000 (10:55 -0600)]
iio: adc: ad4695: move dt-bindings header
Move the dt-bindings header file to the include/dt-bindings/iio/adc/
directory. ad4695 is an ADC driver, so it should be in the adc/
subdirectory for better organization. Previously, it was in the iio/
subdirectory.
Matti Vaittinen [Thu, 21 Nov 2024 13:05:38 +0000 (15:05 +0200)]
iio: bm1390: simplify using guard(mutex)
The BM1390 uses mutex for protecting the fifo read sequence. The clean-up
for a few of the functions can be slightly simplified by removing the
goto-based error handling/unlocking and by utilizing the guard(mutex)
scoped mutex handling instead.
Matti Vaittinen [Thu, 21 Nov 2024 13:05:19 +0000 (15:05 +0200)]
iio: bu27034: simplify using guard(mutex)
The BU27034 uses mutex for protecting the gain / time / scale changes.
The clean-up for a few of the functions can be slightly simplified by
removing the goto-based error handling/unlocking and by utilizing the
guard(mutex) scoped mutex handling instead.
Matti Vaittinen [Thu, 21 Nov 2024 08:19:50 +0000 (10:19 +0200)]
iio: accel: kx022a: Improve reset delay
All the sensors supported by kx022a driver seemed to require some delay
after software reset to be operational again. More or less a random
msleep(1) was added to cause the driver to go to sleep so the sensor has
time to become operational again.
Now we have official docuumentation available:
https://fscdn.rohm.com/kionix/en/document/AN010_KX022ACR-Z_Power-on_Procedure_E.pdf
https://fscdn.rohm.com/kionix/en/document/TN027-Power-On-Procedure.pdf
https://fscdn.rohm.com/kionix/en/document/AN011_KX134ACR-LBZ_Power-on_Procedure_E.pdf
stating the required time is 2 ms.
Due to the nature of the current msleep implementation, the msleep(1) is
likely to be sleeping more than 2ms already - but the value "1" is
misleading in case someone needs to optimize the start time and change
the msleep to a more accurate delay. Hence it is better for
"documentation" purposes to use value which actually reflects the
specified 2ms wait time.
Change the value of delay after software reset to match the
specifications and add links to the power-on procedure specifications.
David Lechner [Wed, 20 Nov 2024 21:33:32 +0000 (15:33 -0600)]
iio: dac ltc2632: drop driver remove function
Remove driver remove callback for the ltc2632 driver.
By making use of devm_iio_device_register(), we no longer need a driver
remove callback. Also since this was the last user of spi_get_drvdata(),
we can drop the call to spi_set_drvdata().
David Lechner [Wed, 20 Nov 2024 21:33:30 +0000 (15:33 -0600)]
iio: dac ad8801: drop driver remove function
Remove driver remove callback in the ad8801 driver.
By making use of devm_iio_device_register(), we no longer need a driver
remove callback. Also since this was the last user of spi_get_drvdata(),
we can drop the call to spi_set_drvdata().
David Lechner [Wed, 20 Nov 2024 21:33:26 +0000 (15:33 -0600)]
iio: dac: ad5686: use devm_regulator_get_enable_read_voltage()
Simplify the code by using devm_regulator_get_enable_read_voltage().
There is a small change in behavior. Before, all errors from
devm_regulator_get_optional() were ignored and assumed to mean that
the external reference supply was absent. Now, only -ENODEV is checked
and other errors will cause a failure to probe. So now, this will
catch errors, like using the wrong data type for the devicetree
property.
Han Xu [Fri, 15 Nov 2024 20:24:00 +0000 (15:24 -0500)]
iio: accel: fxls8962af: add fxls8967af support
fxls8967af is similar with fxls8962af, the only difference is the device id
change to 0x87.
Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20241115-fxls-v2-4-95f3df9228ed@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Haibo Chen [Fri, 15 Nov 2024 20:23:59 +0000 (15:23 -0500)]
iio: accel: fxls8962af: add fxls8974cf support
fxls8974cf is similar with fxls8962af, the only difference is the device id
change to 0x86.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Clark Wang <xiaoning.wang@nxp.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20241115-fxls-v2-3-95f3df9228ed@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add 'nxp,fxls8974cf' compatible for the FXLS8974CF sensor, falling back to
'nxp,fxls8962af' as the only difference is the ID.
Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20241115-fxls-v2-2-95f3df9228ed@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add 'nxp,fxls8967af' compatible for the FXLS8967AF sensor, falling back to
'nxp,fxls8962af' as the only difference is the ID.
Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20241115-fxls-v2-1-95f3df9228ed@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Guenter Roeck [Sat, 9 Nov 2024 14:54:30 +0000 (06:54 -0800)]
iio: imu: lsm6dsx: Use i3cdev_to_dev to get device pointer
I3C client drivers should not include linux/i3c/master.h. Use
i3cdev_to_dev() to get the device pointer from struct i3c_device
to be able to avoid that include.
Darius Berghe [Fri, 8 Nov 2024 12:58:14 +0000 (14:58 +0200)]
dt-bindings: iio: adis16480: add devices to adis16480
Add the adis16486, adis16487 and adis16489 Six Degrees
of Freedom Inertial Sensors to the list of compatible devices
of the adis16480 iio subsystem driver.
adis16486 is similar to adis16485, has the exact same channels
but acceleration and delta velocity scales are different.
adis16487 is fallback compatible with adis16485 and as a
consequence, dt-bindings list was updated to use oneOf.
adis16489 is similar to adis16488 but lacks the magnetometer
and has a different accelerometer scale.
projects / users / jedix / linux-maple.git / log