3e26d9f08f
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>
117 lines
3.4 KiB
Plaintext
117 lines
3.4 KiB
Plaintext
# 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
|