David Lechner [Thu, 11 Jul 2024 19:15:42 +0000 (14:15 -0500)]
iio: adc: ad4695: Add driver for AD4695 and similar ADCs
This is a new driver for Analog Devices Inc. AD4695 and similar ADCs.
The initial driver supports initializing the chip including configuring
all possible LDO and reference voltage sources as well as any possible
voltage input channel wiring configuration.
Only the 4-wire SPI wiring mode where the CNV pin is tied to the CS pin
is supported at this time. And reading sample data from the ADC can only
be done in direct mode for now.
Co-developed-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240711-iio-adc-ad4695-v4-2-c31621113b57@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduces a more generalized ABI documentation for DAC. Instead of
having separate ABI files for each DAC, we now have a single ABI file
that covers the common sysfs interface for all DAC.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
https://patch.msgid.link/20240718051834.32270-2-kimseer.paller@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Nuno Sa [Tue, 9 Jul 2024 11:14:29 +0000 (13:14 +0200)]
iio: backend: print message in case op is not implemented
For APIs that have a return value, -EOPNOTSUPP is returned in case the
backend does not support the functionality. However, for APIs that do
not have a return value we are left in silence. Hence, at least print a
debug message in case the callback is not implemented by the backend.
Add documentation for adxl380 driver which describes the driver
device files and shows how the user may use the ABI for various
scenarios (configuration, measurement, etc.).
The ADXL380/ADXL382 is a low noise density, low power, 3-axis
accelerometer with selectable measurement ranges. The ADXL380 supports
the +/-4 g, +/-8 g, and +/-16 g ranges, and the ADXL382 supports
+/-15 g, +/-30 g and +/-60 g ranges.
The ADXL380/ADXL382 offers industry leading noise, enabling precision
applications with minimal calibration. The low noise, and low power
ADXL380/ADXL382 enables accurate measurement in an environment with
high vibration, heart sounds and audio.
In addition to its low power consumption, the ADXL380/ADXL382 has many
features to enable true system level performance. These include a
built-in micropower temperature sensor, single / double / triple tap
detection and a state machine to prevent a false triggering. In
addition, the ADXL380/ADXL382 has provisions for external control of
the sampling time and/or an external clock.
iio: pressure: bmp280: Add triggered buffer support
BMP2xx, BME280, BMP3xx, and BMP5xx use continuous buffers for their
temperature, pressure and humidity readings. This facilitates the
use of burst/bulk reads in order to acquire data faster. The
approach is different from the one used in oneshot captures.
BMP085 & BMP1xx devices use a completely different measurement
process that is well defined and is used in their buffer_handler().
iio: pressure: bmp280: Add SCALE, RAW values in channels and refactorize them
Add extra IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_RAW channels in order
to be able to calculate the processed value with standard userspace
IIO tools. Can be used for triggered buffers as well.
Even though it is not a good design choice to have SCALE, RAW and
PROCESSED together, the PROCESSED channel is kept for ABI compatibility.
While at it, separate BMPxxx and BMExxx device channels since BME
supports also humidity measurements.
Add the coefficients for the IIO standard units and the IIO value
inside the chip_info structure.
Move the calculations for the IIO unit compatibility from inside the
read_{temp,press,humid}() functions and move them to the general
read_raw() function.
In this way, all the data for the calculation of the value are
located in the chip_info structure of the respective sensor.
Marek Vasut [Mon, 8 Jul 2024 11:41:18 +0000 (13:41 +0200)]
iio: light: ltrf216a: Add LTR-308 support
Add LiteOn LTR-308 support into LTR-F216A kernel driver.
The two devices seem to have almost identical register map, except that
the LTR-308 does not have three CLEAR_DATA registers, which are unused
by this driver. Furthermore, LTR-308 and LTR-F216A use different lux
calculation constants, 0.6 and 0.45 respectively. Both differences are
handled using chip info data.
Marek Vasut [Mon, 8 Jul 2024 11:41:17 +0000 (13:41 +0200)]
dt-bindings: iio: light: ltrf216a: Document LTR-308 support
Document LiteOn LTR-308 support in LTR-F216A bindings.
The two devices seem to have almost identical register map, except that
the LTR-308 does not have three CLEAR_DATA registers, which are unused
by this driver. Furthermore, LTR-308 and LTR-F216A use different lux
calculation constants, 0.6 and 0.45 respectively.
Matti Vaittinen [Fri, 5 Jul 2024 10:55:49 +0000 (13:55 +0300)]
iio: bu27034: Add a read only HARDWAREGAIN
The ROHM BU27034 light sensor has two data channels for measuring
different frequencies of light. The result from these channels is
combined into Lux value while the raw channel values are reported via
intensity channels.
Both of the intensity channels have adjustable gain setting which
impacts the scale of the raw channels. Eg, doubling the gain will double
the values read from the raw channels, which halves the scale value. The
integration time can also be set for the sensor. This does also have an
impact to the scale of the intensity channels because increasing the
integration time will also increase the values reported via the raw
channels.
Impact of integration time to the scale and the fact that the scale value
does not start from '1', can make it hard for a human reader to compute the
gain values based on the scale.
Matti Vaittinen [Fri, 5 Jul 2024 10:55:34 +0000 (13:55 +0300)]
bu27034: ROHM BU27034ANUC correct lux calculation
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. The lux computation based on the data from a BU27034ANUC is
different from the computation for the data from an old BU27034NUC.
Matti Vaittinen [Fri, 5 Jul 2024 10:55:19 +0000 (13:55 +0300)]
bu27034: ROHM BU27034ANUC correct gains and times
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. The BU27034ANUC does not support all the gains or all the
integration times that were supported on BU27034NUC.
Matti Vaittinen [Fri, 5 Jul 2024 10:54:47 +0000 (13:54 +0300)]
bu27034: ROHM BU27034NUC to BU27034ANUC
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this
sensor. These senors aren't compatible from the software point of view.
According to ROHM, the BU27034NUC was never mass-produced. Hence dropping
the BU27034NUC support and using this driver to support BU27034ANUC
should not be a problem to users. We however need to ensure than people
who use old kernel with the old BU27034NUC driver don't get the old
driver probed for the new sensor.
Prepare to use the BU27034NUC driver to support the new BU27034ANUC and
change the compatible to prevent probing the old driver with the new
sensor.
Matti Vaittinen [Fri, 5 Jul 2024 10:54:12 +0000 (13:54 +0300)]
dt-bindings: iio: BU27034 => BU27034ANUC
The BU27034NUC was cancelled before it entered mass production. It was
replaced by a new variant BU27034ANUC (note, added 'A'). The new
variant gained a few significant changes, like removal of the 3.rd data
channel and dropping some of the gain settings. This means that, from
software point of view these ICs are incompatible. Lux calculation based
on the data from the sensors needs to be done differently, and on the
BU27034ANUC the channel 3 data is missing. Also, the gain setting
differencies matter.
Unfortunately, the identification register was not changed so there is no
safe way for the software to distinguish the variants.
According to the ROHM HQ engineers, the old BU27034NUC should not be
encountered in the wild. Hence it makes sense to remove the support for
the old BU27034NUC and add support for the new BU27034ANUC. Change the
compatible in order to not load the incompatible old driver for new sensor
(or, if someone had the old sensor, the new driver for it).
Drop the compatible for old sensor which should not be in the wild and
add a new compatible for the new model with accurate model suffix
'anuc'. Rename the file to match the new compatible.
The reading of the pressure and humidity value, requires an update of the
t_fine variable which happens by reading the temperature value.
So the bme680_read_{press/humid}() functions of the above sensors are
internally calling the equivalent bme680_read_temp() function in order to
update the t_fine value. By just looking at the code this relation is a
bit hidden and is not easy to understand why those channels are not
independent.
This commit tries to clear these thing a bit by splitting the
bme680_{read/compensate}_{temp/press/humid}() to the following:
i. bme680_read_{temp/press/humid}_adc(): read the raw value from the
sensor.
ii. bme680_calc_t_fine(): calculate the t_fine variable.
iii. bme680_get_t_fine(): get the t_fine variable.
iv. bme680_compensate_{temp/press/humid}(): compensate the adc values and
return the calculated value.
v. bme680_read_{temp/press/humid}(): combine calls of the aforementioned
functions to return the requested value.
iio: chemical: bme680: Move forced mode setup in ->read_raw()
Whenever the sensor is set to forced mode, a TPHG cycle is triggered and
the values of temperature, pressure, humidity and gas become ready to be
read.
The setup of the forced mode to trigger measurements was located inside
the read_{temp/gas}() functions. This was not posing a functional problem
since read_{humid/press}() are internally calling read_temp() so the
forced mode is set through this call.
This is not very clear and it is kind of hidden that regardless of the
measurement, the setup of the forced mode needs to happen before any
measurement.
iio: chemical: bme680: Remove redundant gas configuration
There is no need to explicitly configure the gas measurement registers
every time a gas measurement takes place. These are initial configurations
which are written in the beginning and they are not changed throughout
the lifetime of the driver.
If in the future, the device starts to support multiple configuration
profiles with variable heater duration and heater temperature, then they
could become members of the ->read_avail().
Modify the startup procedure to reflect the procedure of the Bosch BME68x
Sensor API. The initial readings and configuration of the sensor need to
happen in the following order:
1) Read calibration data [1,2]
2) Chip general configuration [3]
3) Gas configuration [4]
After the chip configuration it is necessary to ensure that the sensor is
in sleeping mode, in order to apply the gas configuration settings [5].
Also, after the soft reset, it is advised to wait for 5ms [6].
iio: chemical: bme680: Add read buffers in read/write buffer union
Move the buffers that are used in order to read data from the device in
the union which handles all the device read/write buffers. Also create
defines for the number of bytes that are being read from the device and
don't use magic numbers.
iio: chemical: bme680: Allocate IIO device before chip initialization
Move the IIO device allocation before the actual initialization of the
chip to be more consistent with most IIO drivers and also to have the
ability to use any driver specific data for the chip initialization.
iio: chemical: bme680: Use bulk reads for calibration data
Calibration data are located in contiguous-ish registers inside the chip.
For that reason we can use bulk reads as is done as well in the BME68x
Sensor API [1].
The arrays that are used for reading the data out of the sensor
are located inside DMA safe buffer.
The LSB of the gas register was read first to check if the following
check was correct and then the MSB+LSB were read together. Simplify this
by reading together the MSB+LSB immediately.
The ACPI ID table was removed with the following 2 commits:
Commit b73d21dccf68 ("iio: bme680_i2c: Remove acpi_device_id table")
Commit f0e4057e97c1 ("iio: bme680_spi: Remove acpi_device_id table")
Remove the remaining ACPI related stuff to this driver since they are
not directly used.
iio: chemical: bme680: Fix read/write ops to device by adding mutexes
Add mutexes in the {read/write}_raw() functions of the device to guard the
read/write of data from/to the device. This is necessary because for any
operation other than temperature, multiple reads need to take place from
the device. Even though regmap has a locking by itself, it won't protect us
from multiple applications trying to read at the same time temperature and
pressure since the pressure reading includes an internal temperature
reading and there is nothing to ensure that this temperature+pressure
reading will happen sequentially without any other operation interfering
in the meantime.
Yasin Lee [Tue, 2 Jul 2024 14:12:34 +0000 (22:12 +0800)]
iio: proximity: Add driver support for TYHX's HX9023S capacitive proximity sensor
A SAR sensor from NanjingTianyihexin Electronics Ltd.
The device has the following entry points:
Usual frequency:
- sampling_frequency
Instant reading of current values for different sensors:
- in_proximity0_raw
- in_proximity1_raw
- in_proximity2_raw
- in_proximity3_raw
- in_proximity4_raw
and associated events in events/
iio: adc: ad7606: fix standby gpio state to match the documentation
The binding's documentation specifies that "As the line is active low, it
should be marked GPIO_ACTIVE_LOW". However, in the driver, it was handled
the opposite way. This commit sets the driver's behaviour in sync with the
documentation
Fixes: 722407a4e8c0 ("staging:iio:ad7606: Use GPIO descriptor API") Signed-off-by: Guillaume Stols <gstols@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
gpiod_set_array_value was misused here: the implementation relied on the
assumption that an unsigned long was required for each gpio, while the
function expects a bit array stored in "as much unsigned long as needed
for storing one bit per GPIO", i.e it is using a bit field.
This leaded to incorrect parameter passed to gpiod_set_array_value, that
would set 1 value instead of 3.
It also prevents to select the software mode correctly for the AD7606B.
Fixes: d2a415c86c6b ("iio: adc: ad7606: Add support for AD7606B ADC") Fixes: 41f71e5e7daf ("staging: iio: adc: ad7606: Use find_closest() macro") Signed-off-by: Guillaume Stols <gstols@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Since the driver supports several parts that present differences in
their layout and behaviour, it is necessary to describe the differences
from one chip to another.
Nuno Sa [Thu, 4 Jul 2024 09:25:25 +0000 (11:25 +0200)]
iio: adc: ad9467: support new parts
Add support for new devices:
* Analog Devices AD9652 16-bit 310 MSPS ADC;
* Analog Devices AD9643 14-Bit, 170/210/250 MSPS ADC;
* Analog Devices AD9649 14-bit 20/40/65/80 MSPS ADC.
Nuno Sa [Thu, 4 Jul 2024 09:25:24 +0000 (11:25 +0200)]
dt-bindings: adc: ad9467: support new parts
Add support for new devices:
* Analog Devices AD9652 16-bit 310 MSPS ADC;
* Analog Devices AD9643 14-Bit, 170/210/250 MSPS ADC;
* Analog Devices AD9649 14-bit 20/40/65/80 MSPS ADC.
Note all these parts have subtle differences in their programming model
(different scales, number of channels, etc..) so fallbacks are not
possible.
Nuno Sa [Thu, 4 Jul 2024 09:25:23 +0000 (11:25 +0200)]
iio: adc: ad9467: don't allow reading vref if not available
If there's only one possible scale, there's no way to change the Vref
select in the device so avoid reading the register in ad9467_get_scale().
In this case, it makes no sense to provide the .read_available()
callback nor allowing for writing the scale attribute.
Note this is in preparation for supporting a new device that only has
one possible scale.
Nuno Sa [Thu, 4 Jul 2024 09:25:22 +0000 (11:25 +0200)]
iio: adc: ad9467: add new chip_info variables
Add new variables to the per chip info structure:
* test_points: Number of valid test points for calibration;
* has_dco_invert: Supports inverting DCO (Data clock output) polarity;
* dco_en: Specicic mask to enable DCO delays.
This is in preparation for supporting new parts with subtle differences
in how to configure the hardware.
Note that with the new test_points variable, we also add a new
calib_map_size to 'struct ad9467_state' so we know our map size
depending on how many test points we have and if we can run the
calibration in the inverted state or not.
Nuno Sa [Thu, 4 Jul 2024 09:25:21 +0000 (11:25 +0200)]
iio: adc: ad9467: support multiple channels calibration
The calibration process mixes the support for calibrating multiple
channels with only having one channel. Some paths do have 'num_channels'
into account while others don't.
As of now, the driver only supports devices with one channel so the
above is not really a problem. That said, we'll add support for devices
with more than one channel, hence let's properly make the calibration
process to work with it.
Javier Carrasco [Wed, 3 Jul 2024 21:04:53 +0000 (23:04 +0200)]
iio: pressure: bmp280: Constify struct regmap_bus
`bmp280_regmap_bus` and `bmp380_regmap_bus` are conditionally assigned
to `bmp_regmap_bus`, which is only used to pass the struct as a
read-only member.
Add the const modifier to the structs and the pointer to move the data
to a read-only section.
Nuno Sa [Tue, 2 Jul 2024 16:02:52 +0000 (18:02 +0200)]
iio: imu: adis16480: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:51 +0000 (18:02 +0200)]
iio: imu: adis16475: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:50 +0000 (18:02 +0200)]
iio: adc: at91_adc: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:49 +0000 (18:02 +0200)]
iio: adc: ad_sigma_delta: use new '.masklength' accessors
Make use of iio_get_masklength) and iio_for_each_active_channel() to
access '.masklength' so it can be annotated as __private when there
are no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:45 +0000 (18:02 +0200)]
iio: accel: stk8ba50: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:44 +0000 (18:02 +0200)]
iio: accel: stk8312: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:43 +0000 (18:02 +0200)]
iio: accel: sca3300: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:42 +0000 (18:02 +0200)]
iio: accel: msa311: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:41 +0000 (18:02 +0200)]
iio: accel: fxls8962af-core: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there
are no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:39 +0000 (18:02 +0200)]
iio: accel: bmc150-accel-core: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:38 +0000 (18:02 +0200)]
iio: accel: bma180: make use of iio_for_each_active_channel()
Use iio_for_each_active_channel() to iterate over active channels
accessing '.masklength' so it can be annotated as __private when there are
no more direct users of it.
Nuno Sa [Tue, 2 Jul 2024 16:02:33 +0000 (18:02 +0200)]
iio: core: add accessors 'masklength'
'masklength' is supposed to be an IIO private member. However, drivers
(often in trigger handlers) need to access it to iterate over the
enabled channels for example (there are other reasons). Hence, a couple
of new accessors are being added:
* iio_for_each_active_channel() - Iterates over the active channels;
* iio_get_masklength() - Get length of the channels mask.
The goal of these new accessors is to annotate 'masklength' as private
as soon as all drivers accessing it are converted to use the new
helpers.
Merge tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Fix RPM package build error caused by an incorrect locale setup
- Mark modules.weakdep as ghost in RPM package
- Fix the odd combination of -S and -c in stack protector scripts,
which is an error with the latest Clang
* tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: Fix '-S -c' in x86 stack protector scripts
kbuild: rpm-pkg: ghost modules.weakdep file
kbuild: rpm-pkg: Fix C locale setup
minmax: simplify and clarify min_t()/max_t() implementation
This simplifies the min_t() and max_t() macros by no longer making them
work in the context of a C constant expression.
That means that you can no longer use them for static initializers or
for array sizes in type definitions, but there were only a couple of
such uses, and all of them were converted (famous last words) to use
MIN_T/MAX_T instead.
Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant
expressions in VM code") added the simpler MIN_T/MAX_T macros in order
to avoid some excessive expansion from the rather complicated regular
min/max macros.
The complexity of those macros stems from two issues:
(a) trying to use them in situations that require a C constant
expression (in static initializers and for array sizes)
(b) the type sanity checking
and MIN_T/MAX_T avoids both of these issues.
Now, in the whole (long) discussion about all this, it was pointed out
that the whole type sanity checking is entirely unnecessary for
min_t/max_t which get a fixed type that the comparison is done in.
But that still leaves min_t/max_t unnecessarily complicated due to
worries about the C constant expression case.
However, it turns out that there really aren't very many cases that use
min_t/max_t for this, and we can just force-convert those.
This does exactly that.
Which in turn will then allow for much simpler implementations of
min_t()/max_t(). All the usual "macros in all upper case will evaluate
the arguments multiple times" rules apply.
We should do all the same things for the regular min/max() vs MIN/MAX()
cases, but that has the added complexity of various drivers defining
their own local versions of MIN/MAX, so that needs another level of
fixes first.
projects / linux / log