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 3/8] spi: add support for hardware triggered offload
Date: Fri, 10 May 2024 19:44:26 -0500 [thread overview]
Message-ID: <20240510-dlech-mainline-spi-engine-offload-2-v2-3-8707a870c435@baylibre.com> (raw)
In-Reply-To: <20240510-dlech-mainline-spi-engine-offload-2-v2-0-8707a870c435@baylibre.com>
This extends the SPI framework to support hardware triggered offloading.
This allows an arbitrary hardware trigger to be used to start a SPI
transfer that was previously set up with spi_offload_prepare().
Since the hardware trigger can happen at any time, this means the SPI
bus must be reserved for exclusive use as long as the hardware trigger
is enabled. Since a hardware trigger could be enabled indefinitely,
we can't use the existing spi_bus_lock() and spi_bus_unlock() functions,
otherwise this could cause deadlocks. So we introduce a new flag so that
any attempt to lock or use the bus will fail with -EBUSY as long as the
hardware trigger is enabled.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
v2 changes:
This is split out from "spi: add core support for controllers with
offload capabilities".
Mark suggested that the standard SPI APIs should be aware that the
hardware trigger is enabled. So I've added some locking for this. Nuno
suggested that this might be overly strict though, and that we should
let each individual controller driver decide what to do. For our use
case though, I think we generally are going to have a single peripheral
on the SPI bus, so this seems like a reasonable starting place anyway.
TODO: Currently, spi_bus_lock() always returns 0, so none of the callers
check the return value. All callers will need to be updated first before
this can be merged.
---
drivers/spi/spi.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++--
include/linux/spi/spi.h | 17 +++++++++
2 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 54b814cea54c..9ad7b04c26a6 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -4427,7 +4427,7 @@ int spi_async(struct spi_device *spi, struct spi_message *message)
spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
- if (ctlr->bus_lock_flag)
+ if (ctlr->bus_lock_flag || ctlr->offload_hw_trigger_enabled)
ret = -EBUSY;
else
ret = __spi_async(spi, message);
@@ -4572,6 +4572,12 @@ int spi_sync(struct spi_device *spi, struct spi_message *message)
int ret;
mutex_lock(&spi->controller->bus_lock_mutex);
+
+ if (spi->controller->offload_hw_trigger_enabled) {
+ mutex_unlock(&spi->controller->bus_lock_mutex);
+ return -EBUSY;
+ }
+
ret = __spi_sync(spi, message);
mutex_unlock(&spi->controller->bus_lock_mutex);
@@ -4614,7 +4620,7 @@ EXPORT_SYMBOL_GPL(spi_sync_locked);
* exclusive access is over. Data transfer must be done by spi_sync_locked
* and spi_async_locked calls when the SPI bus lock is held.
*
- * Return: always zero.
+ * Return: 0 on success, -EBUSY if the bus is reserved by offload hardware.
*/
int spi_bus_lock(struct spi_controller *ctlr)
{
@@ -4622,6 +4628,11 @@ int spi_bus_lock(struct spi_controller *ctlr)
mutex_lock(&ctlr->bus_lock_mutex);
+ if (ctlr->offload_hw_trigger_enabled) {
+ mutex_unlock(&ctlr->bus_lock_mutex);
+ return -EBUSY;
+ }
+
spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
ctlr->bus_lock_flag = 1;
spin_unlock_irqrestore(&ctlr->bus_lock_spinlock, flags);
@@ -4808,6 +4819,83 @@ void spi_offload_unprepare(struct spi_device *spi, unsigned int id,
}
EXPORT_SYMBOL_GPL(spi_offload_unprepare);
+/**
+ * spi_offload_hw_trigger_enable - enables hardware trigger for offload
+ * @spi: The spi device to use for the transfers.
+ * @id: Unique identifier for SPI device with more than one offload.
+ *
+ * There must be a prepared offload instance with the specified ID (i.e.
+ * spi_offload_prepare() was called with the same ID). This will also reserve
+ * the bus for exclusive use by the offload instance until the hardware trigger
+ * is disabled. Any other attempts to send a transfer or lock the bus will fail
+ * with -EBUSY during this time.
+ *
+ * Calls must be balanced with spi_offload_hw_trigger_disable().
+ *
+ * Context: can sleep
+ * Return: 0 on success, else a negative error code.
+ */
+int spi_offload_hw_trigger_enable(struct spi_device *spi, unsigned int id)
+{
+ struct spi_controller *ctlr = spi->controller;
+ unsigned long flags;
+ int ret;
+
+ if (!ctlr->offload_ops || !ctlr->offload_ops->hw_trigger_enable)
+ return -EOPNOTSUPP;
+
+ mutex_lock(&ctlr->bus_lock_mutex);
+
+ if (ctlr->offload_hw_trigger_enabled) {
+ mutex_unlock(&ctlr->bus_lock_mutex);
+ return -EBUSY;
+ }
+
+ spin_lock_irqsave(&ctlr->bus_lock_spinlock, flags);
+ ctlr->offload_hw_trigger_enabled = true;
+ spin_unlock_irqrestore(&ctlr->bus_lock_spinlock, flags);
+
+ /* TODO: how to wait for empty message queue? */
+
+ mutex_lock(&ctlr->io_mutex);
+ ret = ctlr->offload_ops->hw_trigger_enable(spi, id);
+ mutex_unlock(&ctlr->io_mutex);
+
+ if (ret) {
+ ctlr->offload_hw_trigger_enabled = false;
+ mutex_unlock(&ctlr->bus_lock_mutex);
+ return ret;
+ }
+
+ mutex_unlock(&ctlr->bus_lock_mutex);
+
+ return 0;
+}
+
+/**
+ * spi_offload_hw_trigger_disable - disables hardware trigger for offload
+ * @spi: The same SPI device passed to spi_offload_hw_trigger_enable()
+ * @id: The same ID device passed to spi_offload_hw_trigger_enable()
+ *
+ * Disables the hardware trigger for the offload instance with the specified ID
+ * and releases the bus for use by other clients.
+ *
+ * Context: can sleep
+ */
+void spi_offload_hw_trigger_disable(struct spi_device *spi, unsigned int id)
+{
+ struct spi_controller *ctlr = spi->controller;
+
+ if (!ctlr->offload_ops || !ctlr->offload_ops->hw_trigger_disable)
+ return;
+
+ mutex_lock(&ctlr->io_mutex);
+ ctlr->offload_ops->hw_trigger_disable(spi, id);
+ mutex_unlock(&ctlr->io_mutex);
+
+ ctlr->offload_hw_trigger_enabled = false;
+}
+
/*-------------------------------------------------------------------------*/
#if IS_ENABLED(CONFIG_OF_DYNAMIC)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index a8fc16c6bf37..ec8d875d31ff 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -632,6 +632,9 @@ struct spi_controller {
/* Flag indicating that the SPI bus is locked for exclusive use */
bool bus_lock_flag;
+ /* Flag indicating the bus is reserved for use by hardware trigger */
+ bool offload_hw_trigger_enabled;
+
/*
* Setup mode and clock, etc (SPI driver may call many times).
*
@@ -1594,12 +1597,26 @@ struct spi_controller_offload_ops {
* @unprepare: Callback to release any resources used by prepare().
*/
void (*unprepare)(struct spi_device *spi, unsigned int id);
+
+ /**
+ * @hw_trigger_enable: Callback to enable the hardware trigger for the
+ * given offload instance.
+ */
+
+ int (*hw_trigger_enable)(struct spi_device *spi, unsigned int id);
+ /**
+ * @hw_trigger_disable: Callback to disable the hardware trigger for the
+ * given offload instance.
+ */
+ void (*hw_trigger_disable)(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);
+extern int spi_offload_hw_trigger_enable(struct spi_device *spi, unsigned int id);
+extern void spi_offload_hw_trigger_disable(struct spi_device *spi, unsigned int id);
/*---------------------------------------------------------------------------*/
--
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 ` [PATCH RFC v2 2/8] spi: add basic support for SPI offloading David Lechner
2024-05-21 11:57 ` Nuno Sá
2024-05-11 0:44 ` David Lechner [this message]
2024-05-11 16:51 ` [PATCH RFC v2 3/8] spi: add support for hardware triggered offload 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-3-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).