Received-SPF: pass (google.com: domain of linux-kernel+bounces-23287-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <501bb280c6bd7dcb49929e7dbd242807b828e7de.camel@gmail.com>
Subject: Re: [PATCH 04/13] spi: dt-bindings: adi,axi-spi-engine: add offload
 bindings
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: Rob Herring <robh@kernel.org>, David Lechner <dlechner@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>, Jonathan Cameron <jic23@kernel.org>, 
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley
 <conor+dt@kernel.org>, Michael Hennerich <michael.hennerich@analog.com>,
 Nuno =?ISO-8859-1?Q?S=E1?= <nuno.sa@analog.com>,  Frank Rowand
 <frowand.list@gmail.com>, Thierry Reding <thierry.reding@gmail.com>, Uwe
 =?ISO-8859-1?Q?Kleine-K=F6nig?= <u.kleine-koenig@pengutronix.de>, Jonathan
 Corbet <corbet@lwn.net>,  linux-spi@vger.kernel.org,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org, 
 linux-doc@vger.kernel.org, linux-pwm@vger.kernel.org, 
 linux-kernel@vger.kernel.org
Date: Thu, 11 Jan 2024 10:07:38 +0100
In-Reply-To: <20240110231456.GB2854345-robh@kernel.org>
References: 
	<20240109-axi-spi-engine-series-3-v1-0-e42c6a986580@baylibre.com>
	 <20240109-axi-spi-engine-series-3-v1-4-e42c6a986580@baylibre.com>
	 <20240110231456.GB2854345-robh@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-01-10 at 17:14 -0600, Rob Herring wrote:
> On Wed, Jan 10, 2024 at 01:49:45PM -0600, David Lechner wrote:
> > The ADI AXI SPI Engine driver supports offloading SPI transfers to
> > hardware. This is essentially a feature that allows recording an
> > arbitrary sequence of SPI transfers and then playing them back with
> > no CPU intervention via a hardware trigger.
> >=20
> > This adds the bindings for this feature. Each SPI Engine instance
> > can have from 0 to 32 offload instances. Each offload instance has a
> > trigger input and a data stream output. As an example, this could be
> > used with an ADC SPI peripheral. In this case the trigger is connected
> > to a PWM/clock to determine the sampling rate for the ADC and the outpu=
t
> > stream is connected to a DMA channel to pipe the sample data to memory.
> >=20
> > SPI peripherals act as consumers of the offload instances. Typically,
> > one SPI peripheral will be connected to one offload instance. But to
> > make the bindings future-proof, the property is an array.
>=20
> Is there some sort of arbitration between multiple offload engines on=20
> the same chip select? If not, I don't see how it would work.
>=20
> I think this whole thing could be simplified down to just 3=20
> SPI controller properties: pwms, dmas, and adi,offload-cs-map. Each=20
> property is has entries equal the number of offload engines. The last=20
> one maps an offload engine to a SPI chip-select.
>=20

I think the whole reason why the offload is being treated as a node + platf=
orm
device is to have these properties (or other possible properties depending =
on
the trigger and data capture being used) in it and so respect the HW
configuration.

While that is conceptually correct I feel that this is bringing a lot of ex=
tra
complexity. The end consumer of the offload core (which is a property/featu=
re of
the spi cotroller) are obviously the peripheral devices that in our usecase=
s are
converters and hence IIO devices. So those are the ones consuming all the d=
ata.
I saw Mark already giving some pointers and speaking about having a way to
support the triggers (being it pwm, clock, gpio, etc...) directly in the sp=
i
framework and I think that would be nice. For the dmas, I think it would be=
 more
complicated. While we can setup the dma transfer directly in the spi contro=
ller,
we would need a mechanism to transfer each block of data (periodically) as =
soon
as we have it to the peripheral device. In case of IIO, that would then hav=
e to
connect to IIO DMA buffers so the data can be consumed in userspace and tha=
t
would be the tricky part I believe.

What we have been doing out of tree is to control the trigger and dmas in t=
he
peripheral device even if that does not really directly respect the HW setu=
p (as
these are properties of the offload core). Hence, we can just allocate an I=
IO
DMA buffer, enable the offload message with the messages we want and data c=
an be
directly transferred to userspace (without any intervention of the peripher=
al
driver) using the IIO interfaces for it.

To sum it up, I think having the trigger being handled by the spi framework=
 or
even have it as an IIO generic trigger would be simple. To have the dma
transfers in the spi controller would be more complex but anything is possi=
ble,
I guess :).

- Nuno S=C3=A1
>=20
>=20