lkml.org 
[lkml]   [2024]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/13] spi: add core support for controllers with offload capabilities

Hi Mark, David,

Thanks for CC'ing me. Been reading the discussion so far.

On Thu, 11 Jan 2024 21:49:53 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Thu, Jan 11, 2024 at 03:32:54PM -0600, David Lechner wrote:
> > On Thu, Jan 11, 2024 at 2:54 PM David Lechner <dlechner@baylibre.com> wrote:
>
> > > > (CCed) a while back when he was doing all the work he did on optimising
> > > > the core for uncontended uses, the thinking there was to have a
> > > > spi_prepare_message() (or similar) API that drivers could call and then
> > > > reuse the same transfer repeatedly, and even without any interface for
> > > > 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 weren'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 case
> > > > 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=3tuBu89n6eyJ082EETkwtNbzZDFZYTHbVVg@mail.gmail.com/T/#u
>
> Oh, yes - sorry, I'd misremembered which optimisation effort it was
> associated with. Apologies.

Yes. It was Martin Sperl who proposed this on a Rpi. I mentioned something
similar toward the end of my 2nd email reply in that thread [1]. That might
have triggered the confusion.
As for my interests, I am all for devising ways to make the SPI subsystem more
suitable for optimized high-performance use-cases. In that regard, I think
re-usable messages (spi_prepare_message()) can be useful. More capable
hardware can enable very powerful use-cases for SPI, and it would be cool if
the spi subsystem had the needed infrastructure to support those. As for
hardware-triggers, I still need to wrap my head around how to have a
universally usable API that works nice for the first use-case that comes along
and also doesn't screw up the next use-case that might follow. Keep me posted.

[1] https://lore.kernel.org/linux-spi/20220513144645.2d16475c@erd992/

Best regards,

--
David Jander
Protonic Holland.

\
 
 \ /
  Last update: 2024-01-12 10:06    [W:0.111 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site