linux-yocto/drivers/iio/Kconfig
Paul Cercueil 3e26d9f08f iio: core: Add new DMABUF interface infrastructure
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>
2024-06-30 11:29:17 +01:00

3.4 KiB

SPDX-License-Identifier: GPL-2.0-only

Industrial I/O subsystem configuration

menuconfig IIO tristate "Industrial I/O support" help The industrial I/O subsystem provides a unified framework for drivers for many different types of embedded sensors using a number of different physical interfaces (i2c, spi, etc).

if IIO

config IIO_BUFFER bool "Enable buffer support within IIO" select DMA_SHARED_BUFFER help Provide core support for various buffer based data acquisition methods.

if IIO_BUFFER source "drivers/iio/buffer/Kconfig" endif # IIO_BUFFER

config IIO_CONFIGFS tristate "Enable IIO configuration via configfs" select CONFIGFS_FS help This allows configuring various IIO bits through configfs (e.g. software triggers). For more info see Documentation/iio/iio_configfs.rst.

config IIO_GTS_HELPER tristate

config IIO_TRIGGER bool "Enable triggered sampling support" help Provides IIO core support for triggers. Currently these are used to initialize capture of samples to push into buffers. The triggers are effectively a 'capture data now' interrupt.

config IIO_CONSUMERS_PER_TRIGGER int "Maximum number of consumers per trigger" depends on IIO_TRIGGER default "2" help This value controls the maximum number of consumers that a given trigger may handle. Default is 2.

config IIO_SW_DEVICE tristate "Enable software IIO device support" select IIO_CONFIGFS help Provides IIO core support for software devices. A software device can be created via configfs or directly by a driver using the API provided.

config IIO_SW_TRIGGER tristate "Enable software triggers support" select IIO_CONFIGFS help Provides IIO core support for software triggers. A software trigger can be created via configfs or directly by a driver using the API provided.

config IIO_TRIGGERED_EVENT tristate "Enable triggered events support" select IIO_TRIGGER help Provides helper functions for setting up triggered events.

config IIO_BACKEND tristate help Framework to handle complex IIO aggregate devices. The typical architecture that can make use of this framework is to have one device as the frontend device which can be "linked" against one or multiple backend devices. The framework then makes it easy to get and control such backend devices.

source "drivers/iio/accel/Kconfig" source "drivers/iio/adc/Kconfig" source "drivers/iio/addac/Kconfig" source "drivers/iio/afe/Kconfig" source "drivers/iio/amplifiers/Kconfig" source "drivers/iio/cdc/Kconfig" source "drivers/iio/chemical/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/dac/Kconfig" source "drivers/iio/dummy/Kconfig" source "drivers/iio/filter/Kconfig" source "drivers/iio/frequency/Kconfig" source "drivers/iio/gyro/Kconfig" source "drivers/iio/health/Kconfig" source "drivers/iio/humidity/Kconfig" source "drivers/iio/imu/Kconfig" source "drivers/iio/light/Kconfig" source "drivers/iio/magnetometer/Kconfig" source "drivers/iio/multiplexer/Kconfig" source "drivers/iio/orientation/Kconfig" source "drivers/iio/test/Kconfig" if IIO_TRIGGER source "drivers/iio/trigger/Kconfig" endif #IIO_TRIGGER source "drivers/iio/position/Kconfig" source "drivers/iio/potentiometer/Kconfig" source "drivers/iio/potentiostat/Kconfig" source "drivers/iio/pressure/Kconfig" source "drivers/iio/proximity/Kconfig" source "drivers/iio/resolver/Kconfig" source "drivers/iio/temperature/Kconfig"

endif # IIO