public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Mark Brown" <broonie@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>,
	"Uwe Kleine-König" <ukleinek@kernel.org>,
	"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,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v5 08/16] spi: axi-spi-engine: implement offload support
Date: Sun, 24 Nov 2024 17:02:12 +0000	[thread overview]
Message-ID: <20241124170212.21442c3e@jic23-huawei> (raw)
In-Reply-To: <20241115-dlech-mainline-spi-engine-offload-2-v5-8-bea815bd5ea5@baylibre.com>

On Fri, 15 Nov 2024 14:18:47 -0600
David Lechner <dlechner@baylibre.com> 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@baylibre.com>

Locally this patch is fine, but it has made me wonder if the allocation
strategy for priv makes sense. It's not wrong, but perhaps more complex
than it needs to be.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


> diff --git a/drivers/spi/spi-axi-spi-engine.c b/drivers/spi/spi-axi-spi-engine.c
> index 9386ddc4714e..172a9f1f1ead 100644
> --- a/drivers/spi/spi-axi-spi-engine.c
> +++ b/drivers/spi/spi-axi-spi-engine.c



>  static void spi_engine_release_hw(void *p)
>  {
>  	struct spi_engine *spi_engine = p;
> @@ -675,8 +921,7 @@ static int spi_engine_probe(struct platform_device *pdev)
>  	struct spi_engine *spi_engine;
>  	struct spi_controller *host;
>  	unsigned int version;
> -	int irq;
> -	int ret;
> +	int irq, ret;
>  
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq < 0)
> @@ -691,6 +936,46 @@ static int spi_engine_probe(struct platform_device *pdev)
>  	spin_lock_init(&spi_engine->lock);
>  	init_completion(&spi_engine->msg_complete);
>  
> +	/*
> +	 * REVISIT: for now, all SPI Engines only have one offload. In the
> +	 * future, this should be read from a memory mapped register to
> +	 * determine the number of offloads enabled at HDL compile time. For
> +	 * now, we can tell if an offload is present if there is a trigger
> +	 * source wired up to it.
> +	 */
> +	if (device_property_present(&pdev->dev, "trigger-sources")) {
> +		struct spi_engine_offload *priv;
> +
> +		spi_engine->offload =
> +			devm_spi_offload_alloc(&pdev->dev,
> +					       sizeof(struct spi_engine_offload));
> +		if (IS_ERR(spi_engine->offload))
> +			return PTR_ERR(spi_engine->offload);
> +
> +		priv = spi_engine->offload->priv;

With the separate allocations of offlaod and priv back in patch 1 this
all feels more complex than it should be.  Maybe we should just alloate
priv here and set it up via spi_engine->offload->priv = ...
Other elements of spi_engine->offloads have to be set directly here
for it to work so setting priv as well seems sensible.

 
> +		priv->spi_engine = spi_engine;
> +		priv->offload_num = 0;
> +
> +		spi_engine->offload->ops = &spi_engine_offload_ops;
> +		spi_engine->offload_caps = SPI_OFFLOAD_CAP_TRIGGER;
> +
> +		if (device_property_match_string(&pdev->dev, "dma-names", "offload0-rx") >= 0) {
> +			spi_engine->offload_caps |= SPI_OFFLOAD_CAP_RX_STREAM_DMA;
> +			spi_engine->offload->xfer_flags |= SPI_OFFLOAD_XFER_RX_STREAM;
> +		}
> +
> +		if (device_property_match_string(&pdev->dev, "dma-names", "offload0-tx") >= 0) {
> +			spi_engine->offload_caps |= SPI_OFFLOAD_CAP_TX_STREAM_DMA;
> +			spi_engine->offload->xfer_flags |= SPI_OFFLOAD_XFER_TX_STREAM;
> +		} else {
> +			/*
> +			 * HDL compile option to enable TX DMA stream also disables
> +			 * the SDO memory, so can't do both at the same time.
> +			 */
> +			spi_engine->offload_caps |= SPI_OFFLOAD_CAP_TX_STATIC_DATA;
> +		}
> +	}
> +

  reply	other threads:[~2024-11-24 17:02 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 20:18 [PATCH v5 00/16] spi: axi-spi-engine: add offload support David Lechner
2024-11-15 20:18 ` [PATCH v5 01/16] spi: add basic support for SPI offloading David Lechner
2024-11-24 16:32   ` Jonathan Cameron
2024-11-24 18:01     ` David Lechner
2024-11-25 21:29       ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 02/16] spi: offload: add support for hardware triggers David Lechner
2024-11-24 16:40   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 03/16] spi: dt-bindings: add trigger-source.yaml David Lechner
2024-11-19 16:44   ` Rob Herring
2024-11-15 20:18 ` [PATCH v5 04/16] spi: dt-bindings: add PWM SPI offload trigger David Lechner
2024-11-19 16:37   ` Rob Herring
2024-11-15 20:18 ` [PATCH v5 05/16] spi: offload-trigger: add PWM trigger driver David Lechner
2024-11-24 16:44   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 06/16] spi: add offload TX/RX streaming APIs David Lechner
2024-11-24 16:50   ` Jonathan Cameron
2024-11-24 17:54     ` David Lechner
2024-11-25 21:30       ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 07/16] spi: dt-bindings: axi-spi-engine: add SPI offload properties David Lechner
2024-11-19 16:56   ` Rob Herring
2024-11-19 17:02     ` David Lechner
2024-11-15 20:18 ` [PATCH v5 08/16] spi: axi-spi-engine: implement offload support David Lechner
2024-11-24 17:02   ` Jonathan Cameron [this message]
2024-11-15 20:18 ` [PATCH v5 09/16] iio: buffer-dmaengine: document iio_dmaengine_buffer_setup_ext David Lechner
2024-11-24 17:04   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 10/16] iio: buffer-dmaengine: add devm_iio_dmaengine_buffer_setup_ext2() David Lechner
2024-11-24 17:16   ` Jonathan Cameron
2024-12-06 21:36     ` David Lechner
2024-12-06 22:04       ` David Lechner
2024-12-08 18:32         ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 11/16] iio: adc: ad7944: don't use storagebits for sizing David Lechner
2024-11-15 20:18 ` [PATCH v5 12/16] iio: adc: ad7944: add support for SPI offload David Lechner
2024-11-24 17:24   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 13/16] doc: iio: ad7944: describe offload support David Lechner
2024-11-24 17:25   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 14/16] dt-bindings: iio: adc: adi,ad4695: add SPI offload properties David Lechner
2024-11-19 16:58   ` Rob Herring
2024-11-15 20:18 ` [PATCH v5 15/16] iio: adc: ad4695: Add support for SPI offload David Lechner
2024-11-24 17:35   ` Jonathan Cameron
2024-11-15 20:18 ` [PATCH v5 16/16] doc: iio: ad4695: add SPI offload support David Lechner
2024-11-24 17:38   ` Jonathan Cameron
2024-11-24 18:09     ` 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=20241124170212.21442c3e@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=david@protonic.nl \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --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-pwm@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=ukleinek@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