Vasileios Amoiridis [Sat, 2 Nov 2024 13:13:08 +0000 (14:13 +0100)]
iio: chemical: bme680: Add support for preheat current
Add functionality to inject a specified amount of current to the heating
plate before the start of the gas measurement to allow the sensor to reach
faster to the requested temperature.
Vasileios Amoiridis [Sat, 2 Nov 2024 13:13:07 +0000 (14:13 +0100)]
iio: chemical: bme680: Add triggered buffer support
Add triggered buffer and soft timestamp support. The available scan mask
enables all the channels of the sensor in order to follow the operation of
the sensor. The sensor basically starts to capture from all channels
as long as it enters into FORCED mode.
The bulk read, reads a total of 15 registers from the sensor, 0x1D..0x2B.
Even though some of those registers are not reported in the register map
of the device, this is how the BME680 Sensor API [1] proposes to do it.
This allows to have one bulk read instead of multiple ones.
Vasileios Amoiridis [Sat, 2 Nov 2024 13:13:06 +0000 (14:13 +0100)]
iio: chemical: bme680: Add SCALE and RAW channels
Add SCALE,RAW channels to the device. Even though PROCESSED should be
kept for backwards compatibility add comment to avoid using it if the
value is not actually reported in IIO values.
Refactorize the set_mode() function to use an external enum that
describes the possible modes of the BME680 device instead of using
true/false variables for selecting SLEEPING/FORCED mode.
David Lechner [Fri, 1 Nov 2024 22:17:10 +0000 (17:17 -0500)]
iio: events: make IIO_EVENT_CODE macro private
Make IIO_EVENT_CODE "private" by adding a leading underscore.
There are no more users of this macro in the kernel so we can make it
"private" and encourage developers to use the specialized versions of
the macro instead.
Julien Stephan [Mon, 28 Oct 2024 16:38:12 +0000 (17:38 +0100)]
iio: adc: ad7280a: use IIO_DIFF_EVENT_CODE macro helper
The IIO_DIFF_EVENT_CODE macro helper was introduced to provide a more
specific alternative to the generic IIO_EVENT_CODE macro for handling
differential channels. This commit updates the code to use
IIO_DIFF_EVENT_CODE for better clarity and maintainability.
However, the current implementation incorrectly sets both chan1 and
chan2 to 0. To maintain compatibility and avoid breaking existing
user space applications, this behavior is preserved for now.
Julien Stephan [Mon, 28 Oct 2024 16:38:11 +0000 (17:38 +0100)]
iio: events.h: add event identifier macros for differential channel
Currently, there are 3 helper macros in iio/events.h to create event
identifiers:
- IIO_EVENT_CODE : create generic event identifier for differential and non
differential channels
- IIO_MOD_EVENT_CODE : create event identifier for modified (non
differential) channels
- IIO_UNMOD_EVENT_CODE : create event identifier for unmodified (non
differential) channels
For differential channels, drivers are expected to use IIO_EVENT_CODE.
However, only one driver in drivers/iio currently uses it correctly,
leading to inconsistent event identifiers for differential channels that
don’t match the intended attributes (such as max1363.c that supports
differential channels, but only uses IIO_UNMOD_EVENT_CODE).
To prevent such issues in future drivers, a new helper macro,
IIO_DIFF_EVENT_CODE, is introduced to specifically create event identifiers
for differential channels. Only one helper is needed for differential
channels since they cannot have modifiers.
Additionally, the descriptions for IIO_MOD_EVENT_CODE and
IIO_UNMOD_EVENT_CODE have been updated to clarify that they are intended
for non-differential channels,
Neil Armstrong [Wed, 30 Oct 2024 15:30:24 +0000 (16:30 +0100)]
iio: magnetometer: add Allegro MicroSystems ALS31300 3-D Linear Hall Effect driver
The Allegro MicroSystems ALS31300 is a 3-D Linear Hall Effect Sensor
mainly used for 3D head-on motion sensing applications.
The device is configured over I2C, and as part of the Sensor data the
temperature core is also provided.
While the device provides an IRQ gpio, it depends on a configuration
programmed into the internal EEPROM, thus only the default mode is
supported and buffered input via trigger is also supported to allow
streaming values with the same sensing timestamp.
The device can be configured with different sensitivities in factory,
but the sensitivity value used to calculate value into the Gauss
unit is not available from registers, thus the sensitivity is provided
by the compatible/device-id string which is based on the part number
as described in the datasheet page 2.
Neil Armstrong [Wed, 30 Oct 2024 15:30:23 +0000 (16:30 +0100)]
dt-bindings: iio: magnetometer: document the Allegro MicroSystems ALS31300 3-D Linear Hall Effect Sensor
Document the bindings for the Allegro MicroSystems ALS31300 3-D Linear
Hall Effect Sensor controller by an I2C interface, mainly used in 3D
head-on motion sensing applications.
The device can be configured with different sensitivities in factory,
but the sensitivity value used to calculate value into the Gauss unit
is not available from registers, thus the sensitivity is provided by
the compatible/device-id string which is based on the part number as
described in the datasheet page 2.
Julien Stephan [Thu, 31 Oct 2024 15:27:03 +0000 (16:27 +0100)]
iio: accel: mma9551: use bool for event state
Since the write_event_config callback now uses a bool for the state
parameter, update the signature of the function it calls accordingly,
and use a bool array for event_enabled.
Julien Stephan [Thu, 31 Oct 2024 15:27:02 +0000 (16:27 +0100)]
iio: fix write_event_config signature
write_event_config callback use an int for state, but it is actually a
boolean. iio_ev_state_store is actually using kstrtobool to check user
input, then gives the converted boolean value to write_event_config.
Fix signature and update all iio drivers to use the new signature.
This patch has been partially written using coccinelle with the
following script:
make coccicheck MODE=patch COCCI=iio-bool.cocci M=drivers/iio
Unfortunately, this script didn't match all files:
* all write_event_config callbacks using iio_device_claim_direct_scoped
were not detected and not patched.
* all files that do not assign and declare the write_event_config
callback in the same file.
iio.h was also manually updated.
The patch was build tested using allmodconfig config.
Julien Stephan [Thu, 31 Oct 2024 15:27:01 +0000 (16:27 +0100)]
iio: light: adux1020: write_event_config: use local variable for interrupt value
state parameter is currently an int, but it is actually a boolean.
iio_ev_state_store is actually using kstrtobool to check user input,
then gives the converted boolean value to write_event_config. The code
in adux1020_write_event_config re-uses state parameter to store an
integer value. To prepare for updating the write_event_config signature
to use a boolean for state, introduce a new local int variable.
Ricardo Ribalda [Fri, 1 Nov 2024 07:46:30 +0000 (07:46 +0000)]
iio: hid-sensors-prox: Make proximity channel indexed
We are going to introduce more proximity channels. Make proximity a
indexed channel now, in a simple patch, so the change can be easily
bisected if there are any issues.
Ricardo Ribalda [Fri, 1 Nov 2024 07:46:27 +0000 (07:46 +0000)]
iio: hid-sensors: Add proximity and attention IDs
The HID Usage Table at https://usb.org/sites/default/files/hut1_5.pdf
reserves:
- 0x4b2 for Human Proximity Range
Distance between a human and the computer. Default unit of
measure is meters;
https://www.usb.org/sites/default/files/hutrr39b_0.pdf
- 0x4bd for Human Attention Detected
Human-Presence sensors detect the presence of humans in the sensor’s
field-of-view using diverse and evolving technologies. Some presence
sensors are implemented with low resolution video cameras, which can
additionally track a subject’s attention (i.e. if the
user is ‘looking’ at the system with the integrated sensor).
A Human-Presence sensor, providing a Host with the user’s attention
state, allows the Host to optimize its behavior. For example, to
brighten/dim the system display, based on the user’s attention to the
system (potentially prolonging battery life). Default unit is
true/false;
https://www.usb.org/sites/default/files/hutrr107-humanpresenceattention_1.pdf
Javier Carrasco [Wed, 30 Oct 2024 23:09:58 +0000 (00:09 +0100)]
iio: light: veml6070: add support for integration time
The integration time of the veml6070 depends on an external resistor
(called Rset in the datasheet) and the value configured in the IT
field of the command register, whose supported values are 1/2x, 1x,
2x and 4x.
Axel Haslam [Thu, 31 Oct 2024 07:17:46 +0000 (08:17 +0100)]
iio: dac: ad5791: Use devm_iio_device_register
Use devm_iio_device_register to automatically free the iio device.
since this is the last remaining resource that was not automatically
freed, we can drop the ".remove" callback.
Suggested-by: David Lechner <dlechner@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Link: https://patch.msgid.link/20241031071746.848694-7-ahaslam@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Axel Haslam [Thu, 31 Oct 2024 07:17:45 +0000 (08:17 +0100)]
iio: dac: ad5791: Use devm_regulator_get_enable_read_voltage
Simplify probe by using of the devm_regulator_get_enable_read_voltage.
Suggested-by: David Lechner <dlechner@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Link: https://patch.msgid.link/20241031071746.848694-6-ahaslam@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Axel Haslam [Thu, 31 Oct 2024 07:17:44 +0000 (08:17 +0100)]
iio: dac: ad5791: Add reset, clr and ldac gpios
The ad7591 has reset, clr and ldac gpios. For the DAC to output data
continuously written to the data register the state of these gpios needs
to be set by the driver.
Add these gpios to the driver making them optional in case they are fixed
on the pcb.
Axel Haslam [Thu, 31 Oct 2024 07:17:43 +0000 (08:17 +0100)]
iio: dac: ad5791: Include chip_info in device match tables
Include a chip info struct in device SPI and device OF match tables to
provide channel definitions for each particular ADC model and drop
device enum.
Suggested-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Link: https://patch.msgid.link/20241031071746.848694-4-ahaslam@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Axel Haslam [Thu, 31 Oct 2024 07:17:42 +0000 (08:17 +0100)]
dt-bindings: iio: dac: ad5791: Add required voltage supplies
Vcc, iovcc, vrefp, and vrefn are needed for the DAC to work.
Add them as required bindings for ad5791.
Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Link: https://patch.msgid.link/20241031071746.848694-3-ahaslam@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Depending on board layout, the ad57xx may need control of reset, clear,
and ldac pins by the host driver. Add optional bindings for these gpios.
Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Link: https://patch.msgid.link/20241031071746.848694-2-ahaslam@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Angelo Dureghello [Mon, 28 Oct 2024 21:45:34 +0000 (22:45 +0100)]
iio: dac: ad3552r: add high-speed platform driver
Add High Speed ad3552r platform driver.
The ad3552r DAC is controlled by a custom (fpga-based) DAC IP
through the current AXI backend, or similar alternative IIO backend.
Compared to the existing driver (ad3552r.c), that is a simple SPI
driver, this driver is coupled with a DAC IIO backend that finally
controls the ad3552r by a fpga-based "QSPI+DDR" interface, to reach
maximum transfer rate of 33MUPS using dma stream capabilities.
All commands involving QSPI bus read/write are delegated to the backend
through the provided APIs for bus read/write.
Angelo Dureghello [Mon, 28 Oct 2024 21:45:32 +0000 (22:45 +0100)]
iio: dac: ad3552r: changes to use FIELD_PREP
Changes to use FIELD_PREP, so that driver-specific ad3552r_field_prep
is removed. Variables (arrays) that was used to call ad3552r_field_prep
are removed too.
Angelo Dureghello [Mon, 28 Oct 2024 21:45:31 +0000 (22:45 +0100)]
iio: dac: adi-axi-dac: extend features
Extend AXI-DAC backend with new features required to interface
to the ad3552r DAC. Mainly, a new compatible string is added to
support the ad3552r-axi DAC IP, very similar to the generic DAC
IP but with some customizations to work with the ad3552r.
Then, a series of generic functions has been added to match with
ad3552r needs. Function names has been kept generic as much as
possible, to allow re-utilization from other frontend drivers.
Angelo Dureghello [Mon, 28 Oct 2024 21:45:30 +0000 (22:45 +0100)]
iio: backend: extend features
Extend backend features with new calls needed later on this
patchset from axi version of ad3552r.
The follwoing calls are added:
iio_backend_ddr_enable()
enable ddr bus transfer
iio_backend_ddr_disable()
disable ddr bus transfer
iio_backend_data_stream_enable()
enable data stream over bus interface
iio_backend_data_stream_disable()
disable data stream over bus interface
iio_backend_data_transfer_addr()
define the target register address where the DAC sample
will be written.
Add a new compatible and related bindigns for the fpga-based
"ad3552r" AXI IP core, a variant of the generic AXI DAC IP.
The AXI "ad3552r" IP is a very similar HDL (fpga) variant of the
generic AXI "DAC" IP, intended to control ad3552r and similar chips,
mainly to reach high speed transfer rates using a QSPI DDR
(dobule-data-rate) interface.
The ad3552r device is defined as a child of the AXI DAC, that in
this case is acting as an SPI controller.
Note, #io-backend is present because it is possible (in theory anyway)
to use a separate controller for the control path than that used
for the datapath.
Angelo Dureghello [Mon, 28 Oct 2024 21:45:28 +0000 (22:45 +0100)]
dt-bindings: iio: dac: ad3552r: add iio backend support
There is a version of AXI DAC IP block (for FPGAs) that provides
a physical QSPI bus for AD3552R and similar chips, so supporting
spi-controller functionalities.
For this case, the binding is modified to include some additional
properties.
Vasileios Amoiridis [Wed, 30 Oct 2024 23:54:24 +0000 (00:54 +0100)]
iio: chemical: bme680: use s16 variable for temp value to avoid casting
Use local s16 variable for the temperature channel to avoid casting it
later before passing it to the bme680_read_temp() function. This way,
possible endianness and initialization issues are avoided.
Andy Shevchenko [Wed, 30 Oct 2024 16:19:19 +0000 (18:19 +0200)]
iio: adc: pac1921: Check for error code from devm_mutex_init() call
Even if it's not critical, the avoidance of checking the error code
from devm_mutex_init() call today diminishes the point of using devm
variant of it. Tomorrow it may even leak something. Add the missed
check.
Andy Shevchenko [Wed, 30 Oct 2024 16:19:18 +0000 (18:19 +0200)]
iio: adc: ad4000: Check for error code from devm_mutex_init() call
Even if it's not critical, the avoidance of checking the error code
from devm_mutex_init() call today diminishes the point of using devm
variant of it. Tomorrow it may even leak something. Add the missed
check.
Justin Weiss [Sun, 27 Oct 2024 17:20:25 +0000 (10:20 -0700)]
iio: imu: bmi270: Add support for BMI260
Adds support for the Bosch BMI260 6-axis IMU to the Bosch BMI270
driver. Setup and operation is nearly identical to the Bosch BMI270,
but has a different chip ID and requires different firmware.
Firmware is requested and loaded from userspace.
Adds ACPI ID BMI0160, used by several devices including the GPD Win
Mini, Aya Neo AIR Pro, and OXP Mini Pro.
GPD Win Mini:
Device (BMI2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BMI0160") // _HID: Hardware ID
Name (_CID, "BMI0160") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0068, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CB",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveLow, Exclusive, PullDefault, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x008B
}
})
Return (RBUF) /* \_SB_.I2CB.BMI2._CRS.RBUF */
}
...
}
Justin Weiss [Sun, 27 Oct 2024 17:20:24 +0000 (10:20 -0700)]
dt-bindings: iio: imu: bmi270: Add Bosch BMI260
The BMI260's register map, configuration, and capabilities are nearly
identical to the BMI270, but the devices have different chip IDs and
require different initialization firmware.
Remove the IIO specific scaling measurement units from the read functions
and add them inside the ->read_raw() function to keep the read_*() generic.
This way they can be used in other parts of the driver.
Javier Carrasco [Wed, 23 Oct 2024 18:59:59 +0000 (20:59 +0200)]
iio: light: add support for veml3235
The Vishay veml3235 is a low-power ambient light sensor with I2C
interface. It provides a minimum detectable intensity of
0.0021 lx/cnt, configurable integration time and gain, and an additional
white channel to distinguish between different light sources.
Javier Carrasco [Wed, 23 Oct 2024 18:59:58 +0000 (20:59 +0200)]
dt-bindings: iio: light: veml6030: add veml3235
The veml3235 is another Vishay ambient light sensor that shares similar
properties with the other sensors covered by this bindings. In this
case, only the compatible, reg, and vdd-supply properties are required,
and the device does not have an interrupt line, like the already
supported veml7700.
Andy Shevchenko [Thu, 24 Oct 2024 19:05:12 +0000 (22:05 +0300)]
iio: light: ltr501: Add LTER0303 to the supported devices
It has been found that the (non-vendor issued) ACPI ID for Lite-On
LTR303 is present in Microsoft catalog. Add it to the list of the
supported devices.
Andy Shevchenko [Thu, 24 Oct 2024 19:05:11 +0000 (22:05 +0300)]
iio: light: ltr501: Drop most likely fake ACPI IDs
The commits in question do not proove that ACPI IDs exist.
Quite likely it was a cargo cult addition while doing that
for DT-based enumeration. Drop most likely fake ACPI IDs.
The to be removed IDs has been checked against the following resources:
1) DuckDuckGo
2) Google
3) MS catalog: https://www.catalog.update.microsoft.com/Search.aspx
This gives no useful results in regard to DSDT, moreover, the official
vendor ID in the registry for Lite-On is LCI.
Andy Shevchenko [Thu, 24 Oct 2024 19:05:10 +0000 (22:05 +0300)]
iio: light: isl29018: drop ACPI_PTR() and CONFIG_ACPI guards
The complexity of config guards needed for ACPI_PTR() is not worthwhile
for the small amount of saved data. This example was doing it correctly
but I am proposing dropping this so as to reduce chance of cut and paste
where it is done wrong. Also drop now unneeded linux/acpi.h include and
added linux/mod_devicetable.h for struct acpi_device_id definition.
Andy Shevchenko [Thu, 24 Oct 2024 19:05:05 +0000 (22:05 +0300)]
iio: accel: kxcjk-1013: drop ACPI_PTR() and move ID out of CONFIG_ACPI guards
The complexity of config guards needed for ACPI_PTR() is not worthwhile
for the small amount of saved data. This example was doing it correctly
but I am proposing dropping this so as to reduce chance of cut and paste
where it is done wrong. Also added linux/mod_devicetable.h for
struct acpi_device_id definition.
Andy Shevchenko [Thu, 24 Oct 2024 19:05:03 +0000 (22:05 +0300)]
iio: accel: kxcjk-1013: Get rid of enum kx_chipset
Instead of using enum, out of which only a couple of values
are being actually used, make a comparisons against pointer
to the respective chip_info structures.
Andy Shevchenko [Thu, 24 Oct 2024 19:04:57 +0000 (22:04 +0300)]
iio: accel: kxcjk-1013: Switch from CONFIG_PM guards to pm_ptr() etc
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Andy Shevchenko [Thu, 24 Oct 2024 19:04:56 +0000 (22:04 +0300)]
iio: accel: kxcjk-1013: Revert "Add support for KX022-1020"
The mentioned change effectively broke the ODR startup timeouts
settungs for KX023-1025 case. Let's revert it for now and see
how we can handle it with the better approach after switching
the driver to use data structure instead of enum.
projects / users / jedix / linux-maple.git / log