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>
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.
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.
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.
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.
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.
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.
Andy Shevchenko [Thu, 24 Oct 2024 19:04:52 +0000 (22:04 +0300)]
iio: imu: inv_mpu6050: Replace strange way of checking type of enumeration
When device is enumerated via ACPI the respective device node is of
ACPI device type. Use that to check for ACPI enumeration, rather than
calling for full match which is O(n) vs. O(1) for the regular check.
Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-4-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Andy Shevchenko [Thu, 24 Oct 2024 19:04:51 +0000 (22:04 +0300)]
iio: adc: pac1934: Replace strange way of checking type of enumeration
When device is enumerated via ACPI the respective device node is of
ACPI device type. Use that to check for ACPI enumeration, rather than
calling for full match which is O(n) vs. O(1) for the regular check.
iio: adc: ad7606: add support for AD760{7,8,9} parts
The AD7607, AD7608 and AD7609 are some older parts of the AD7606 family.
They are hardware-only, meaning that they don't have any registers
accessible via SPI or Parallel interface.
They are more similar to the AD7605-4 part, which is supported by the
'ad7606' driver, and are configurable via GPIOs.
Like the AD7605-4 part, all 3 parts have 2 CONVST (Conversion Start) pins
(CONVST A and CONVST B). But in practice, these should be tied together to
make reading of samples easier via a serial line.
The AD7607 has an 14-bit resolution and AD7608 & AD7609 have an 18-bit
resolution. The main difference between the AD7608 & AD7609 is that the
AD7609 has a larger range (±10V & ±20V) vs the ±5V & ±10V ranges for AD7608.
However, unlike AD7605-4 part, these 3 parts have oversampling which is
configurable (like for the AD7606 in HW-mode) via GPIOs.
iio: adc: ad7606: rework scale-available to be static
The main driver for this change is the AD7607 part, which has a scale of
"1.220703" for the ±10V range. The AD7607 has a resolution of 14-bits.
So, just adding the scale-available list for that part would require some
quirks to handle just that scale value.
But to do it more neatly, the best approach is to rework the scale
available lists to have the same format as it is returned to userspace.
That way, we can also get rid of the allocation for the 'scale_avail_show'
array.
iio: adc: ad7606: use realbits for sign-extending in scan_direct
Currently the 'ad7606' driver supports parts with 18 and 16 bits
resolutions.
But when adding support for AD7607 (which has a 14-bit resolution) we
should check for the 'realbits' field, to be able to sign-extend correctly.
When the mutexes were reworked to guards, the caching of the
oversampling_ratio values was removed by accident.
The main effect of this change is that, after setting the
oversampling_ratio value, reading it back would result in the initial value
(of 1).
The value would get sent to the device correctly though.
Fixes 2956979dbd0d: ("iio: adc: ad7606: switch mutexes to guard")
Jonathan Cameron [Sun, 20 Oct 2024 18:07:20 +0000 (19:07 +0100)]
iio: accel: replace s64 __aligned(8) with aligned_s64
e4ca0e59c394 ("types: Complement the aligned types with signed 64-bit one")
introduced aligned_s64. Use it for all IIO accelerometer drivers.
Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/20241020180720.496327-1-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Emil Gedenryd [Thu, 3 Oct 2024 12:22:16 +0000 (14:22 +0200)]
dt-bindings: iio: light: opt3001: add compatible for opt3002
The opt3002 is a Light-to-Digital Sensor by TI with support for wide-range
spectrum light. It shares most properties with their opt3001 model with
the exception of having a wide spectral bandwidth, ranging from 300 nm
to 1000 nm.
Add support for AD7770, AD7771, AD7779 ADCs. The device is capable of
sending out data both on DOUT lines interface,as on the SDO line.
The driver currently implements only the SDO data streaming mode. SPI
communication is used alternatively for accessing registers and streaming
data. Register accesses are protected by crc8.
Documentation: ABI: added filter mode doc in sysfs-bus-iio
The filter mode / filter type property is used for ad4130
and ad7779 drivers, therefore the ABI doc file for ad4130
was removed, merging both of them in the sysfs-bus-iio.
Since one of the drivers is available from 6.1, the version
has been set to 6.1 for these attributes.
Add dt bindings for AD7779 8-channel, simultaneous sampling ADC
family with eight full Σ-Δ ADCs on chip and ultra-low input
current to allow direct sensor connection.
Guillaume Stols [Tue, 15 Oct 2024 13:56:21 +0000 (13:56 +0000)]
iio: adc: ad7606: Disable PWM usage for non backend version
Since the pwm was introduced before backend, there was a mock use, with
a GPIO emulation. Now that iio backend is introduced, the mock use can
be removed.
Guillaume Stols [Tue, 15 Oct 2024 13:56:20 +0000 (13:56 +0000)]
iio: adc: ad7606: Add iio-backend support
- Basic support for iio backend.
- Supports IIO_CHAN_INFO_SAMP_FREQ R/W.
- Only hardware mode is available, and that IIO_CHAN_INFO_RAW is not
supported if iio-backend mode is selected.
Guillaume Stols [Tue, 15 Oct 2024 13:56:19 +0000 (13:56 +0000)]
iio: adc: ad7606: Introduce num_adc_channels
This variable determines how many hardware channels has the chip,
oppositely to the num_channels that can contain more channels, e.g a
timestamp channel in our case. Introducing this variable avoids
decreasing the former num_channels variable when reading the ADC's
channels, and clarifies a bit the code.
Guillaume Stols [Tue, 15 Oct 2024 13:56:18 +0000 (13:56 +0000)]
iio: adc: ad7606: Add compatibility to fw_nodes
On the parallel version, the current implementation is only compatible
with id tables and won't work with fw_nodes, this commit intends to fix
it.
Doing so required to declare ad7606_chip_info structures in the .h file
so to make them accessible to all the driver files that can set a
pointer to the corresponding chip as the driver data.
Guillaume Stols [Tue, 15 Oct 2024 13:56:17 +0000 (13:56 +0000)]
iio: adc: ad7606: Add PWM support for conversion trigger
Until now, the conversion were triggered by setting high the GPIO
connected to the convst pin. This commit gives the possibility to
connect the convst pin to a PWM.
Connecting a PWM allows to have a better control on the samplerate,
but it must be handled with care, as it is completely decorrelated of
the driver's busy pin handling.
Hence it is not recommended to be used "as is" but must be exploited
in conjunction with IIO backend, and for now only a mock functionality
is enabled, i.e PWM never swings, but is used as a GPIO, i.e duty_cycle
== period equals high state, duty_cycle == 0 equals low state.
This mock functionality will be disabled after the IIO backend usecase
is introduced.
projects / thirdparty / linux.git / log
