Add a driver to support reading the Auxiliary ADC IP found in the
MediaTek MT6357, MT6358 and MT6359 Power Management ICs, featuring
a different register layout, configuration reset and ADC reading
sequence from the other already supported MediaTek SoC or PMIC
(aux)ADC HW.
This driver provides multiple ADC channels for system monitoring,
such as battery voltage, PMIC temperature, PMIC-internal voltage
regulators temperature, and others.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20240604123008.327424-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Label all the channels using names from the reference manual. Some of
the "control" channels are duplicates of other channels. The reference
manual describes it like:
> The AMS register set includes several measurement registers that are
> written to by the PS SYSMON unit using the single-channel mode
> (sequencer off). These voltage measurements are performed using the
> unipolar sampling circuit with a 0 to 3V range and do not have alarms
> or minimum/maximum registers.
So I think these really are measuring the same voltages but in a
different location. In which case, sharing labels makes sense to me.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://patch.msgid.link/20240620204842.817237-1-sean.anderson@linux.dev
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
spi: add devm_spi_optimize_message() helper
Helper from David Lechner <dlechner@baylibre.com>:
In the IIO subsystem, we are finding that it is common to call
spi_optimize_message() during driver probe since the SPI message
doesn't change for the lifetime of the driver. This patch adds a
devm_spi_optimize_message() helper to simplify this common pattern.
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is converted
to an array of DMA addresses + lengths, which is then passed to
dmaengine_prep_slave_dma_array().
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Co-developed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20240620122726.41232-6-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this interface to share DMABUF
objects between several interfaces, allowing it to transfer data in a
zero-copy fashion, for instance between IIO and the USB stack.
The userspace application can also memory-map the DMABUF objects, and
access the sample data directly. The advantage of doing this vs. the
read() interface is that it avoids an extra copy of the data between the
kernel and userspace. This is particularly userful for high-speed
devices which produce several megabytes or even gigabytes of data per
second.
As part of the interface, 3 new IOCTLs have been added:
IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
Attach the DMABUF object identified by the given file descriptor to the
buffer.
IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
Detach the DMABUF object identified by the given file descriptor from
the buffer. Note that closing the IIO buffer's file descriptor will
automatically detach all previously attached DMABUF objects.
IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
Request a data transfer to/from the given DMABUF object. Its file
descriptor, as well as the transfer size and flags are provided in the
"iio_dmabuf" structure.
These three IOCTLs have to be performed on the IIO buffer's file
descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Co-developed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://patch.msgid.link/20240620122726.41232-4-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This makes use of the new devm_regulator_get_enable_read_voltage()
function to reduce boilerplate code.
Error messages have changed slightly since there are now fewer places
where we print an error. The rest of the logic of selecting which
supply to use as the reference voltage remains the same.
Also 1000 is replaced by MILLI in a few places for consistency.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20240624124941.113010-2-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add labels from IIO channels to our channels. This allows userspace to
display more meaningful names instead of "in0" or "temp5".
Although lm-sensors gracefully handles errors when reading channel
labels, the ABI says the label attribute
> Should only be created if the driver has hints about what this voltage
> channel is being used for, and user-space doesn't.
Therefore, we test to see if the channel has a label before
creating the attribute.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20240624174601.1527244-3-sean.anderson@linux.dev
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
LIS2DS12 is an accelerometer by STMicroelectronics. It is identifiable by
its WhoAmI value 0x43.
Its register interface is not compatible with existing parts. For example:
- The full-scale values are present in register 0x20, in bits 2 and 3
(mask 0x0c). Most other supported sensors have the register address set
to 0x21, 0x23, 0x24, or 0x25. There is one sensor setting though
(bearing WhoAmI 0x3b) which has it's address set to 0x20, but the mask is
set to 0x20, not 0x0c.
- The full-scale values 2G, 4G, 8G, and 16G correspond to the register
values 0x00, 0x02, 0x03, 0x01 respectively. None of the sensor settings
have the value 0x01 associated with 16G.
Add the compatible string without any fallback.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://patch.msgid.link/20240622123520.39253-2-kauschluss@disroot.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADS1119 is a precision, 16-bit, analog-to-digital converter (ADC)
that features two differential or four single-ended inputs through a
flexible input multiplexer (MUX), rail-to-rail input
buffers, a programmable gain stage, a voltage reference, and an
oscillator.
Apart from normal single conversion, the driver also supports
continuous conversion mode using a triggered buffer. However, in this
mode only one channel can be scanned at a time.
Datasheet: https://www.ti.com/lit/gpn/ads1119
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20240617183905.4685-1-francesco@dolcini.it
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
