[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240309175402.22de577d@jic23-huawei>
Date: Sat, 9 Mar 2024 17:54:02 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
<conor+dt@...nel.org>, Michael Hennerich <michael.hennerich@...log.com>,
Nuno Sá <nuno.sa@...log.com>, Frank Rowand
<frowand.list@...il.com>, Thierry Reding <thierry.reding@...il.com>, Uwe
Kleine-König <u.kleine-koenig@...gutronix.de>, Jonathan
Corbet <corbet@....net>, linux-spi@...r.kernel.org,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org,
linux-kernel@...r.kernel.org, David Jander <david@...tonic.nl>
Subject: Re: [PATCH 01/13] spi: add core support for controllers with
offload capabilities
On Mon, 4 Mar 2024 17:21:21 -0600
David Lechner <dlechner@...libre.com> wrote:
> On Wed, Jan 10, 2024 at 3:36 PM Mark Brown <broonie@...nel.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 capture
> > > data from ADCs at high rates (MSPS) with a stable sample period.
> >
> > > Most of the implementation is controller-specific and will be handled 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 bits
> > 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.
> >
>
> ...
>
> >
> > The bit where messages are initiated by hardware is a step beyond that,
> > I think we need a bit more API for connecting up the triggers and we
> > also need to have something handling what happens with normal operation
> > of the device while these triggers are enabled. I think it could be
> > useful to split this bit out since there's a lot more to work out there
> > in terms of interfaces.
>
> Now that we have addressed the pre-cooking messages bit [1] I'm coming
> back to the hardware trigger bit. Since the hardware trigger part
> hasn't been discussed in the past, it's not so clear to me what is
> being requested here (also see specific questions below).
>
> [1]: https://lore.kernel.org/linux-spi/20240219-mainline-spi-precook-message-v2-0-4a762c6701b9@baylibre.com/T/#t
Mark took the spi patches so we don't need to do anything complex next
cycle. Just need the IIO driver with these additions as by the time we hit
rc1 all the dependencies will be available.
Rest were questions for Mark I think.
Powered by blists - more mailing lists