From: David Lechner <dlechner@baylibre.com>
To: "Mark Brown" <broonie@kernel.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Nuno Sá" <nuno.sa@analog.com>
Cc: David Lechner <dlechner@baylibre.com>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Lars-Peter Clausen <lars@metafoo.de>,
David Jander <david@protonic.nl>,
Martin Sperl <kernel@martin.sperl.org>,
linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: [PATCH RFC v2 2/8] spi: add basic support for SPI offloading
Date: Fri, 10 May 2024 19:44:25 -0500 [thread overview]
Message-ID: <20240510-dlech-mainline-spi-engine-offload-2-v2-2-8707a870c435@baylibre.com> (raw)
In-Reply-To: <20240510-dlech-mainline-spi-engine-offload-2-v2-0-8707a870c435@baylibre.com>
SPI offloading is a feature that allows the SPI controller to perform
complex transfers without CPU intervention. This is useful, e.g. for
high-speed data acquisition.
This patch adds the basic infrastructure to support SPI offloading. It
introduces new callbacks that are to be implemented by controllers with
offload capabilities.
On SPI device probe, the standard spi-offloads devicetree property is
parsed and passed to the controller driver to reserve the resources
requested by the peripheral via the map_channel() callback.
The peripheral driver can then use spi_offload_prepare() to load a SPI
message into the offload hardware.
If the controller supports it, this message can then be passed to the
SPI message queue as if it was a normal message. Future patches will
will also implement a way to use a hardware trigger to start the message
transfers rather than going through the message queue.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
v2 changes:
This is a rework of "spi: add core support for controllers with offload
capabilities" from v1.
The spi_offload_get() function that Nuno didn't like is gone. Instead,
there is now a mapping callback that uses the new generic devicetree
binding to request resources automatically when a SPI device is probed.
The spi_offload_enable/disable() functions for dealing with hardware
triggers are deferred to a separate patch.
This leaves adding spi_offload_prepare/unprepare() which have been
reworked to be a bit more robust.
In the previous review, Mark suggested that these functions should not
be separate from the spi_[un]optimize() functions. I understand the
reasoning behind that. However, it seems like there are two different
kinds of things going on here. Currently, spi_optimize() only performs
operations on the message data structures and doesn't poke any hardware.
This makes it free to be use by any peripheral without worrying about
tying up any hardware resources while the message is "optimized". On the
other hand, spi_offload_prepare() is poking hardware, so we need to be
more careful about how it is used. And in these cases, we need a way to
specify exactly which hardware resources it should use, which it is
currently doing with the extra ID parameter.
---
drivers/spi/spi.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/spi/spi.h | 57 +++++++++++++++++++++++++++
2 files changed, 157 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 289feccca376..54b814cea54c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2477,6 +2477,28 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
of_spi_parse_dt_cs_delay(nc, &spi->cs_hold, "spi-cs-hold-delay-ns");
of_spi_parse_dt_cs_delay(nc, &spi->cs_inactive, "spi-cs-inactive-delay-ns");
+ /* Offloads */
+ rc = of_property_count_u32_elems(nc, "spi-offloads");
+ if (rc > 0) {
+ int num_ch = rc;
+
+ if (!ctlr->offload_ops) {
+ dev_err(&ctlr->dev, "SPI controller doesn't support offloading\n");
+ return -EINVAL;
+ }
+
+ for (idx = 0; idx < num_ch; idx++) {
+ of_property_read_u32_index(nc, "spi-offloads", idx, &value);
+
+ rc = ctlr->offload_ops->map_channel(spi, idx, value);
+ if (rc) {
+ dev_err(&ctlr->dev, "Failed to map offload channel %d: %d\n",
+ value, rc);
+ return rc;
+ }
+ }
+ }
+
return 0;
}
@@ -3231,6 +3253,11 @@ static int spi_controller_check_ops(struct spi_controller *ctlr)
}
}
+ if (ctlr->offload_ops && !(ctlr->offload_ops->map_channel &&
+ ctlr->offload_ops->prepare &&
+ ctlr->offload_ops->unprepare))
+ return -EINVAL;
+
return 0;
}
@@ -4708,6 +4735,79 @@ int spi_write_then_read(struct spi_device *spi,
}
EXPORT_SYMBOL_GPL(spi_write_then_read);
+/**
+ * spi_offload_prepare - prepare offload hardware for a transfer
+ * @spi: The spi device to use for the transfers.
+ * @id: Unique identifier for SPI device with more than one offload.
+ * @msg: The SPI message to use for the offload operation.
+ *
+ * Requests an offload instance with the specified ID and programs it with the
+ * provided message.
+ *
+ * The message must not be pre-optimized (do not call spi_optimize_message() on
+ * the message).
+ *
+ * Calls must be balanced with spi_offload_unprepare().
+ *
+ * Return: 0 on success, else a negative error code.
+ */
+int spi_offload_prepare(struct spi_device *spi, unsigned int id,
+ struct spi_message *msg)
+{
+ struct spi_controller *ctlr = spi->controller;
+ int ret;
+
+ if (!ctlr->offload_ops)
+ return -EOPNOTSUPP;
+
+ msg->offload = true;
+
+ ret = spi_optimize_message(spi, msg);
+ if (ret)
+ return ret;
+
+ mutex_lock(&ctlr->io_mutex);
+ ret = ctlr->offload_ops->prepare(spi, id, msg);
+ mutex_unlock(&ctlr->io_mutex);
+
+ if (ret) {
+ spi_unoptimize_message(msg);
+ msg->offload = false;
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(spi_offload_prepare);
+
+/**
+ * spi_offload_unprepare - releases any resources used by spi_offload_prepare()
+ * @spi: The same SPI device passed to spi_offload_prepare()
+ * @id: The same ID device passed to spi_offload_prepare()
+ * @msg: The same SPI message passed to spi_offload_prepare()
+ *
+ * Callers must ensure that the offload is no longer in use before calling this
+ * function, e.g. no in-progress transfers.
+ */
+void spi_offload_unprepare(struct spi_device *spi, unsigned int id,
+ struct spi_message *msg)
+{
+ struct spi_controller *ctlr = spi->controller;
+
+ if (!ctlr->offload_ops)
+ return;
+
+ mutex_lock(&ctlr->io_mutex);
+ ctlr->offload_ops->unprepare(spi, id);
+ mutex_unlock(&ctlr->io_mutex);
+
+ msg->offload = false;
+ msg->offload_state = NULL;
+
+ spi_unoptimize_message(msg);
+}
+EXPORT_SYMBOL_GPL(spi_offload_unprepare);
+
/*-------------------------------------------------------------------------*/
#if IS_ENABLED(CONFIG_OF_DYNAMIC)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index e8e1e798924f..a8fc16c6bf37 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -31,6 +31,7 @@ struct spi_transfer;
struct spi_controller_mem_ops;
struct spi_controller_mem_caps;
struct spi_message;
+struct spi_controller_offload_ops;
/*
* INTERFACES between SPI master-side drivers and SPI slave protocol handlers,
@@ -500,6 +501,7 @@ extern struct spi_device *spi_new_ancillary_device(struct spi_device *spi, u8 ch
* This field is optional and should only be implemented if the
* controller has native support for memory like operations.
* @mem_caps: controller capabilities for the handling of memory operations.
+ * @offload_ops: operations for controllers with offload support.
* @unprepare_message: undo any work done by prepare_message().
* @slave_abort: abort the ongoing transfer request on an SPI slave controller
* @target_abort: abort the ongoing transfer request on an SPI target controller
@@ -745,6 +747,9 @@ struct spi_controller {
const struct spi_controller_mem_ops *mem_ops;
const struct spi_controller_mem_caps *mem_caps;
+ /* Operations for controllers with offload support. */
+ const struct spi_controller_offload_ops *offload_ops;
+
/* GPIO chip select */
struct gpio_desc **cs_gpiods;
bool use_gpio_descriptors;
@@ -1114,6 +1119,7 @@ struct spi_transfer {
* @pre_optimized: peripheral driver pre-optimized the message
* @optimized: the message is in the optimized state
* @prepared: spi_prepare_message was called for the this message
+ * @offload: message is to be used with offload hardware
* @status: zero for success, else negative errno
* @complete: called to report transaction completions
* @context: the argument to complete() when it's called
@@ -1123,6 +1129,7 @@ struct spi_transfer {
* @queue: for use by whichever driver currently owns the message
* @state: for use by whichever driver currently owns the message
* @opt_state: for use by whichever driver currently owns the message
+ * @offload_state: for use by whichever driver currently owns the message
* @resources: for resource management when the SPI message is processed
*
* A @spi_message is used to execute an atomic sequence of data transfers,
@@ -1151,6 +1158,8 @@ struct spi_message {
/* spi_prepare_message() was called for this message */
bool prepared;
+ /* spi_offload_prepare() was called on this message */
+ bool offload;
/*
* REVISIT: we might want a flag affecting the behavior of the
@@ -1183,6 +1192,11 @@ struct spi_message {
* __spi_optimize_message() and __spi_unoptimize_message().
*/
void *opt_state;
+ /*
+ * Optional state for use by controller driver between calls to
+ * offload_ops->prepare() and offload_ops->unprepare().
+ */
+ void *offload_state;
/* List of spi_res resources when the SPI message is processed */
struct list_head resources;
@@ -1546,6 +1560,49 @@ static inline ssize_t spi_w8r16be(struct spi_device *spi, u8 cmd)
/*---------------------------------------------------------------------------*/
+/*
+ * Offloading support.
+ *
+ * Some SPI controllers support offloading of SPI transfers. Essentially,
+ * this allows the SPI controller to record SPI transfers and then play them
+ * back later in one go via a single trigger.
+ */
+
+/**
+ * struct spi_controller_offload_ops - callbacks for offload support
+ *
+ * Drivers for hardware with offload support need to implement all of these
+ * callbacks.
+ */
+struct spi_controller_offload_ops {
+ /**
+ * @map_channel: Callback to reserve an offload instance for the given
+ * SPI device. If a SPI device requires more than one instance, then
+ * @id is used to differentiate between them. Channels must be unmapped
+ * in the struct spi_controller::cleanup() callback.
+ */
+ int (*map_channel)(struct spi_device *spi, unsigned int id,
+ unsigned int channel);
+ /**
+ * @prepare: Callback to prepare the offload for the given SPI message.
+ * @msg and any of its members (including any xfer->tx_buf) is not
+ * guaranteed to be valid beyond the lifetime of this call.
+ */
+ int (*prepare)(struct spi_device *spi, unsigned int id,
+ struct spi_message *msg);
+ /**
+ * @unprepare: Callback to release any resources used by prepare().
+ */
+ void (*unprepare)(struct spi_device *spi, unsigned int id);
+};
+
+extern int spi_offload_prepare(struct spi_device *spi, unsigned int id,
+ struct spi_message *msg);
+extern void spi_offload_unprepare(struct spi_device *spi, unsigned int id,
+ struct spi_message *msg);
+
+/*---------------------------------------------------------------------------*/
+
/*
* INTERFACE between board init code and SPI infrastructure.
*
--
2.43.2
next prev parent reply other threads:[~2024-05-11 0:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 0:44 [PATCH RFC v2 0/8] spi: axi-spi-engine: add offload support David Lechner
2024-05-11 0:44 ` [PATCH RFC v2 1/8] spi: dt-bindings: spi-peripheral-props: add spi-offloads property David Lechner
2024-05-13 16:46 ` Conor Dooley
2024-05-13 17:06 ` David Lechner
2024-05-14 18:46 ` Conor Dooley
2024-05-14 22:56 ` David Lechner
2024-05-16 21:32 ` Conor Dooley
2024-05-17 16:51 ` David Lechner
2024-05-19 12:53 ` Conor Dooley
2024-05-21 14:54 ` David Lechner
2024-05-22 18:24 ` Conor Dooley
2024-05-11 0:44 ` David Lechner [this message]
2024-05-21 11:57 ` [PATCH RFC v2 2/8] spi: add basic support for SPI offloading Nuno Sá
2024-05-11 0:44 ` [PATCH RFC v2 3/8] spi: add support for hardware triggered offload David Lechner
2024-05-11 16:51 ` Jonathan Cameron
2024-05-11 0:44 ` [PATCH RFC v2 4/8] spi: add offload xfer flags David Lechner
2024-05-11 0:44 ` [PATCH RFC v2 5/8] spi: dt-bindings: axi-spi-engine: document spi-offloads David Lechner
2024-05-11 0:44 ` [PATCH RFC v2 6/8] spi: axi-spi-engine: add offload support David Lechner
2024-05-21 12:31 ` Nuno Sá
2024-05-21 14:28 ` David Lechner
2024-05-22 12:08 ` Nuno Sá
2024-05-11 0:44 ` [PATCH RFC v2 7/8] dt-bindings: iio: adc: adi,ad7944: add SPI offload properties David Lechner
2024-05-11 0:44 ` [PATCH RFC v2 8/8] iio: adc: ad7944: add support for SPI offload David Lechner
2024-05-11 16:58 ` Jonathan Cameron
2024-05-11 18:41 ` David Lechner
2024-05-12 11:52 ` Jonathan Cameron
2024-05-13 15:15 ` David Lechner
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=20240510-dlech-mainline-spi-engine-offload-2-v2-2-8707a870c435@baylibre.com \
--to=dlechner@baylibre.com \
--cc=Michael.Hennerich@analog.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=david@protonic.nl \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=kernel@martin.sperl.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@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 read-only IMAP folder(s) and NNTP newsgroup(s).