[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201117162340.43924-1-alexandru.ardelean@analog.com>
Date: Tue, 17 Nov 2020 18:23:28 +0200
From: Alexandru Ardelean <alexandru.ardelean@...log.com>
To: <linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC: <lars@...afoo.de>, <jic23@...nel.org>,
Alexandru Ardelean <alexandru.ardelean@...log.com>
Subject: [RFC PATCH 00/12] iio: core,buffer: add support for multiple IIO buffers per IIO device
Continuing from:
https://lore.kernel.org/linux-iio/20200517144023.6c5cb169@archlinux/
This is a V2 of the initial attempt in the discussion above.
But it did not occur to me that I should mark it as V2 when I generated
the patches.
I've only tested [so far] that the current IIO buffer mechnism still works.
And decided to show this sketch patchset.
This requires the ioctl() centralization mechanism, for which I sent a
fix earlier.
https://lore.kernel.org/linux-iio/CA+U=Dsqf3UgyM666Gg9EmehpWiucDx2P0bmsC9JR--JJDT_eWQ@mail.gmail.com/T/#t
https://lore.kernel.org/linux-iio/20201117095154.7189-1-alexandru.ardelean@analog.com/T/#u
The gist of this is that now, the first IIO buffer should work as
before, but all extra buffers should go through the anon inodes
mechanism.
I'd need to find a device or a way or a chip to test these extra buffers
stuff. But I'm confident that this current form should eventually work
with multiple IIO buffers per 1 IIO device and with anon inodes.
Maybe I'll take some of the patches in this set separately and send them
individually. The problem with patchsets like this that tackle changes
in a framework (like IIO) is that I become unsure after the 5th-7th patch,
that the approach is correct. And I get even more unsure after that.
I'll create some userspace code to test this a bit, but I thought I'd
send an RFC in the meantime.
Alexandru Ardelean (12):
iio: core: register chardev only if needed
iio: buffer: add back-ref from iio_buffer to iio_dev
iio: buffer: rework buffer & scan_elements dir creation
iio: buffer: add index to the first IIO buffer dir and symlink it back
iio: core: split __iio_device_attr_init() to init only the attr object
iio: buffer: re-route scan_elements via it's kobj_type
iio: buffer: re-route core buffer attributes via it's new kobj_type
iio: buffer: add helper to get the IIO device to which a buffer
belongs
iio: re-route all buffer attributes through new buffer kobj_type
iio: core: wrap iio device & buffer into struct for character devices
iio: buffer: introduce support for attaching more IIO buffers
iio: buffer: add ioctl() to support opening extra buffers for IIO
device
drivers/iio/accel/adxl372.c | 36 +-
drivers/iio/accel/bmc150-accel-core.c | 34 +-
drivers/iio/adc/at91-sama5d2_adc.c | 30 +-
.../buffer/industrialio-buffer-dmaengine.c | 13 +-
.../cros_ec_sensors/cros_ec_sensors_core.c | 30 +-
.../common/hid-sensors/hid-sensor-trigger.c | 32 +-
drivers/iio/iio_core.h | 11 +
drivers/iio/industrialio-buffer.c | 582 ++++++++++++++----
drivers/iio/industrialio-core.c | 117 ++--
include/linux/iio/buffer.h | 2 +
include/linux/iio/buffer_impl.h | 25 +-
include/linux/iio/iio-opaque.h | 6 +
include/linux/iio/iio.h | 2 +-
include/linux/iio/sysfs.h | 50 ++
include/uapi/linux/iio/buffer.h | 16 +
15 files changed, 735 insertions(+), 251 deletions(-)
create mode 100644 include/uapi/linux/iio/buffer.h
--
2.17.1
Powered by blists - more mailing lists