Re: [PATCH RFC v3 2/9] spi: add basic support for SPI offloading
From: Jonathan Cameron <jic23@kernel.org>
Date: 2024-08-03 09:58:16
Also in:
linux-iio, linux-spi, lkml
On Tue, 30 Jul 2024 14:35:09 -0500 David Lechner [off-list ref] wrote:
On 7/27/24 8:15 AM, Jonathan Cameron wrote:quoted
On Mon, 22 Jul 2024 16:57:09 -0500 David Lechner [off-list ref] wrote:quoted
quoted
+/** + * spi_offload_prepare - prepare offload hardware for a transfer + * @spi: The spi device to use for the transfers. + * @id: Function ID if SPI device uses more than one offload or NULL. + * @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, const char *id, + struct spi_message *msg) +{ + struct spi_controller *ctlr = spi->controller; + int ret; + + if (!ctlr->offload_ops) + return -EOPNOTSUPP; + + msg->offload = true;I'd set this later perhaps as...If we move it, then we would have to create a new function to call instead of spi_optimize_message() so that the controller driver can know that this is an offload message and not a regular message since they will need to be handled differently during the optimization phase.
Ah. I'd missed that.
quoted
quoted
+ + ret = spi_optimize_message(spi, msg); + if (ret)It otherwise needs clearing here so it doesn't have side effects if an error occurs.
Then it needs clearing here I think.
quoted
quoted
+ 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);