Received-SPF: pass (google.com: domain of linux-kernel+bounces-23293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <4c15f3f2d54363698d13a9c5b50a82684e143afd.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: David Lechner <dlechner@baylibre.com>, Rob Herring <robh@kernel.org>
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:14:16 +0100
In-Reply-To: <CAMknhBGwb+9Eo5ghG+Zk3BpMuMZfQxAAwGEGUMspcJzHzKWyXA@mail.gmail.com>
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>
	 <CAMknhBGwb+9Eo5ghG+Zk3BpMuMZfQxAAwGEGUMspcJzHzKWyXA@mail.gmail.com>
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 18:06 -0600, David Lechner wrote:
> On Wed, Jan 10, 2024 at 5:15=E2=80=AFPM Rob Herring <robh@kernel.org> wro=
te:
> >=20
> > 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 connecte=
d
> > > to a PWM/clock to determine the sampling rate for the ADC and the out=
put
> > > stream is connected to a DMA channel to pipe the sample data to memor=
y.
> > >=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
> > the same chip select? If not, I don't see how it would work.
>=20
> There is only one SPI engine driving the SPI controller, so if two
> offloads are triggered at the same time, they will be executed
> serially.
>=20
> >=20
> > I think this whole thing could be simplified down to just 3
> > SPI controller properties: pwms, dmas, and adi,offload-cs-map. Each
> > property is has entries equal the number of offload engines. The last
> > one maps an offload engine to a SPI chip-select.
>=20
> Offloads could be connected to virtually anything, not just pwms and
> dmas, so making pwms and dmas controller properties doesn't seem right
> to me. What if we have one that uses a gpio trigger or clock trigger?
> Or what if we have one where the output goes to a DSP instead of DMA?
> This is why I made offload@ nodes with a compatible property - to
> describe what is actually connected to each offload instance since it
> could be an unlimited range of different things.
>=20

Yeah, again, that is conceptually correct but I'm just not sure if the extr=
a
complexity pays off. The peripheral device connected to the offload should =
know
what trigger + data path it has. So I don't really think that horrible to h=
ave
the properties in the peripheral device. And there's not much that boilerpl=
ate
code anyways (at least in ADI usecases). And, as already said, for the trig=
gers
we might be able to have something generic but for the dmas (or whatever el=
se)
would be more tricky. In IIO case, setting up an IIO DMA buffer, is one API=
 call
- so not much repetition in it...

- Nuno S=C3=A1
>=20