Re: [PATCH RFC v4 09/15] spi: axi-spi-engine: implement offload support
From: David Lechner
Date: Fri Oct 25 2024 - 12:36:08 EST
On 10/25/24 8:09 AM, Nuno Sá wrote:
> On Wed, 2024-10-23 at 15:59 -0500, David Lechner wrote:
>> Implement SPI offload support for the AXI SPI Engine. Currently, the
>> hardware only supports triggering offload transfers with a hardware
>> trigger so attempting to use an offload message in the regular SPI
>> message queue will fail. Also, only allows streaming rx data to an
>> external sink, so attempts to use a rx_buf in the offload message will
>> fail.
>>
>> Signed-off-by: David Lechner <dlechner@xxxxxxxxxxxx>
>> ---
>>
...
>> +static int spi_engine_offload_prepare(struct spi_message *msg)
>> +{
>> + struct spi_controller *host = msg->spi->controller;
>> + struct spi_engine *spi_engine = spi_controller_get_devdata(host);
>> + struct spi_engine_program *p = msg->opt_state;
>> + struct spi_engine_offload *priv = msg->offload->priv;
>> + struct spi_transfer *xfer;
>> + void __iomem *cmd_addr;
>> + void __iomem *sdo_addr;
>> + size_t tx_word_count = 0;
>> + unsigned int i;
>> +
>> + if (p->length > spi_engine->offload_ctrl_mem_size)
>> + return -EINVAL;
>> +
>> + /* count total number of tx words in message */
>> + list_for_each_entry(xfer, &msg->transfers, transfer_list) {
>> + if (!xfer->tx_buf)
>> + continue;
>> +
>> + if (xfer->bits_per_word <= 8)
>> + tx_word_count += xfer->len;
>> + else if (xfer->bits_per_word <= 16)
>> + tx_word_count += xfer->len / 2;
>> + else
>> + tx_word_count += xfer->len / 4;
>> + }
>> +
>> + if (tx_word_count > spi_engine->offload_sdo_mem_size)
>> + return -EINVAL;
>> +
>> + if (test_and_set_bit_lock(SPI_ENGINE_OFFLOAD_FLAG_PREPARED, &priv->flags))
>> + return -EBUSY;
>> +
>
> This is odd. Any special reason for using this with aquire - release semantics? Can
> optimize() and unoptimize() run concurrently? Because if they can this does not give
> us mutual exclusion and we really need to do what we're doing with kind of stuff :)
>
> - Nuno Sá
>
>
This looks like another leftover from an in-between revision that
didn't get fully cleaned up. I will reconsider what is need here.
But to answer the question, strictly speaking, there isn't anything
to prevent two concurrent calls spi_optimize_message() with different
messages but the same offload instance.