Received-SPF: pass (google.com: domain of linux-kernel+bounces-25022-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240109-axi-spi-engine-series-3-v1-0-e42c6a986580@baylibre.com>
 <20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com>
 <2c74aad9-3cb9-4222-8072-e72120c2658e@sirena.org.uk> <CAMknhBGMRed9vDrDAuPJ5DnEe6MyHzd0VBebp5OaLX2Q+AyhMQ@mail.gmail.com>
 <CAMknhBE-1Khe9J-n5WQnH=mFnN0ukiq7=F-SEOU6J-2_u-R0bw@mail.gmail.com>
In-Reply-To: <CAMknhBE-1Khe9J-n5WQnH=mFnN0ukiq7=F-SEOU6J-2_u-R0bw@mail.gmail.com>
From: David Lechner <dlechner@baylibre.com>
Date: Fri, 12 Jan 2024 14:09:11 -0600
Message-ID: <CAMknhBGzOFnMnpt7B8iHd9VwWA-_zFVdiswDUAheovrHXyAv=Q@mail.gmail.com>
Subject: Re: [PATCH 01/13] spi: add core support for controllers with offload capabilities
To: Mark Brown <broonie@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>, Rob Herring <robh+dt@kernel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, 
	Michael Hennerich <michael.hennerich@analog.com>, =?UTF-8?B?TnVubyBTw6E=?= <nuno.sa@analog.com>, 
	Frank Rowand <frowand.list@gmail.com>, Thierry Reding <thierry.reding@gmail.com>, 
	=?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= <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, 
	David Jander <david@protonic.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 11, 2024 at 3:32=E2=80=AFPM David Lechner <dlechner@baylibre.co=
m> wrote:
>
> On Thu, Jan 11, 2024 at 2:54=E2=80=AFPM David Lechner <dlechner@baylibre.=
com> wrote:
> >
> > On Wed, Jan 10, 2024 at 3:36=E2=80=AFPM Mark Brown <broonie@kernel.org>=
 wrote:
> > >
> > > On Wed, Jan 10, 2024 at 01:49:42PM -0600, David Lechner wrote:
> > > > This adds a feature for specialized SPI controllers that can record
> > > > a series of SPI transfers, including tx data, cs assertions, delays=
,
> > > > etc. and then play them back using a hardware trigger without CPU
> > > > intervention.
> > >
> > > > The intended use case for this is with the AXI SPI Engine to captur=
e
> > > > data from ADCs at high rates (MSPS) with a stable sample period.
> > >
> > > > Most of the implementation is controller-specific and will be handl=
ed by
> > > > drivers that implement the offload_ops callbacks. The API follows a
> > > > prepare/enable pattern that should be familiar to users of the clk
> > > > subsystem.
> > >
> > > This is a lot to do in one go, and I think it's a bit too off on the
> > > side and unintegrated with the core.  There's two very high level bit=
s
> > > here, there's the pre-cooking a message for offloading to be executed=
 by
> > > a hardware engine and there's the bit where that's triggered by some
> > > hardwar event rather than by software.
> > >
> > > There was a bunch of discussion of the former case with David Jander
> >
> > I found [1] which appears to be the conversation you are referring to.
> > Is that all or is there more that I missed?
> >
> > [1]: https://lore.kernel.org/linux-spi/20220512163445.6dcca126@erd992/
> >
> > > (CCed) a while back when he was doing all the work he did on optimisi=
ng
> > > the core for uncontended uses, the thinking there was to have a
> > > spi_prepare_message() (or similar) API that drivers could call and th=
en
> > > reuse the same transfer repeatedly, and even without any interface fo=
r
> > > client drivers it's likely that we'd be able to take advantage of it =
in
> > > the core for multi-transfer messages.  I'd be surprised if there were=
n't
> > > wins when the message goes over the DMA copybreak size.  A much wider
> > > range of hardware would be able to do this bit, for example David's c=
ase
> > > was a Raspberry Pi using the DMA controller to write into the SPI
>
> For those, following along, it looks like the RPi business was
> actually a 2013 discussion with Martin Sperl [2]. Both this and [1]
> discuss proposed spi_prepare_message() APIs.
>
> [2]: https://lore.kernel.org/linux-spi/CACRpkdb4mn_Hxg=3D3tuBu89n6eyJ082E=
ETkwtNbzZDFZYTHbVVg@mail.gmail.com/T/#u

I found one more. A patch from Martin with the basic proposed API but
not much in the way of implementation. It looks like this is where the
idea fizzled out.

https://lore.kernel.org/linux-spi/0C7D5B1E-E561-4F52-BEA8-572EB0CA26A6@mart=
in.sperl.org/