From: Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org>
To: devicetree@vger.kernel.org, linux-iio@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Olivier Moysan <olivier.moysan@foss.st.com>
Subject: [PATCH v2 0/8] iio: add new backend framework
Date: Fri, 08 Dec 2023 16:14:07 +0100 [thread overview]
Message-ID: <20231208-dev-iio-backend-v2-0-5450951895e1@analog.com> (raw)
This series depends on [1] and it only build on top of it. The point is
to already speed up the reviewing of the framework. That obviously means
that all those pacthes were dropped in v2.
v1:
https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
Changes in v2:
- Patch 1-2 and 5
* new patches.
- Patch 6:
* Fixed some docs failures;
* Fixed a legacy 'conv' name in one of the function parameters;
* Added .request_buffer() and .free_buffer() ops;
* Refactored the helper macros;
* Added Olivier as Reviewer.
- Patch 7:
* Use new devm_iio_backend_request_buffer().
- Patch 8:
* Implement new .request_buffer() and .free_buffer() ops;
Also would like to mention that in v2 I'm experimenting in having the
DMA on the backend device (as discussed with David in v1). Does not look
to bad but as I said before, I'm not seeing a big issue if we end up
having the buffer allocation in the frontend.
For the bindings folks:
I'm introducing a new io-backends property in the ad9467 bindings but I'm
not sure this is the way to do it. Ideally that new property become a
generic schema and I'm guessing I should send a PULL to?
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/iio/iio-consumer.yaml
(Jonathan, if you think that's not the right place, shout now :))
I'm also deprecating 'adi,adc-dev' as it is not relevant anymore. In the
driver code, we are actually breaking ABI but I'm taking a more
conservative approach in the bindings. Ideally I would also remove it in
the bindings :).
As requested here we have a small diagram that illustrated on e typical
usage of the new framework:
-------------------------------------------------------
------------------ | ----------- ------------ ------- FPGA |
| ADC |------------------------| | AXI ADC |---------| DMA CORE |------| RAM | |
| (Frontend/IIO) | Serial Data (eg: LVDS) | |(backend)|---------| |------| | |
| |------------------------| ----------- ------------ ------- |
------------------ -------------------------------------------------------
The above is highly focused on ADI usecases. But one can see the idea...
The frontend is the real converter and is the one registering and
handling all the IIO interfaces. Such a device can then connect to a
backend device for further services/configurations. In the above
example, the backend device is an high speed core capable of handling
the high sample rate of these ADCs so that it can push that data further
in the pipeline (typically a DMA core) so the user can process the
samples with minimal losses.
Jonathan, I was also tempted in including the diagram in the source
file. Would that be a good idea?
[1]: https://lore.kernel.org/linux-iio/20231207-iio-backend-prep-v2-0-a4a33bc4d70e@analog.com
---
Nuno Sa (7):
dt-bindings: adc: ad9467: document io-backend property
dt-bindings: adc: axi-adc: deprecate 'adi,adc-dev'
driver: core: allow modifying device_links flags
iio: buffer-dmaengine: export buffer alloc and free functions
iio: add the IIO backend framework
iio: adc: ad9467: convert to backend framework
iio: adc: adi-axi-adc: move to backend framework
Olivier Moysan (1):
of: property: add device link support for io-backends
.../devicetree/bindings/iio/adc/adi,ad9467.yaml | 5 +
.../devicetree/bindings/iio/adc/adi,axi-adc.yaml | 4 +-
MAINTAINERS | 8 +
drivers/base/core.c | 14 +-
drivers/iio/Kconfig | 5 +
drivers/iio/Makefile | 1 +
drivers/iio/adc/Kconfig | 3 +-
drivers/iio/adc/ad9467.c | 242 +++++++------
drivers/iio/adc/adi-axi-adc.c | 379 +++++---------------
drivers/iio/buffer/industrialio-buffer-dmaengine.c | 6 +-
drivers/iio/industrialio-backend.c | 386 +++++++++++++++++++++
drivers/of/property.c | 2 +
include/linux/iio/adc/adi-axi-adc.h | 68 ----
include/linux/iio/backend.h | 68 ++++
include/linux/iio/buffer-dmaengine.h | 4 +-
15 files changed, 727 insertions(+), 468 deletions(-)
---
base-commit: 330c0f834ccbdbe6a89da475cb1c56893f3a8363
change-id: 20231120-dev-iio-backend-d14b473a1d9f
--
Thanks!
- Nuno Sá
next reply other threads:[~2023-12-08 15:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 15:14 Nuno Sa via B4 Relay [this message]
2023-12-08 15:14 ` [PATCH v2 1/8] dt-bindings: adc: ad9467: document io-backend property Nuno Sa via B4 Relay
2023-12-08 17:40 ` Krzysztof Kozlowski
2023-12-09 14:35 ` Nuno Sá
2023-12-08 15:14 ` [PATCH v2 2/8] dt-bindings: adc: axi-adc: deprecate 'adi,adc-dev' Nuno Sa via B4 Relay
2023-12-08 17:39 ` Krzysztof Kozlowski
2023-12-09 14:40 ` Nuno Sá
2023-12-08 15:14 ` [PATCH v2 3/8] driver: core: allow modifying device_links flags Nuno Sa via B4 Relay
2023-12-10 14:22 ` Jonathan Cameron
2023-12-08 15:14 ` [PATCH v2 4/8] of: property: add device link support for io-backends Nuno Sa via B4 Relay
2023-12-08 15:14 ` [PATCH v2 5/8] iio: buffer-dmaengine: export buffer alloc and free functions Nuno Sa via B4 Relay
2023-12-10 14:24 ` Jonathan Cameron
2023-12-11 9:36 ` Nuno Sá
2023-12-08 15:14 ` [PATCH v2 6/8] iio: add the IIO backend framework Nuno Sa via B4 Relay
2023-12-10 14:28 ` Jonathan Cameron
2023-12-08 15:14 ` [PATCH v2 7/8] iio: adc: ad9467: convert to " Nuno Sa via B4 Relay
2023-12-08 15:14 ` [PATCH v2 8/8] iio: adc: adi-axi-adc: move " Nuno Sa via B4 Relay
2023-12-08 15:30 ` [PATCH v2 0/8] iio: add new " Conor Dooley
2023-12-09 14:32 ` Nuno Sá
2023-12-10 14:04 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231208-dev-iio-backend-v2-0-5450951895e1@analog.com \
--to=devnull+nuno.sa.analog.com@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).