Re: [PATCH 01/13] spi: add core support for controllers with offload capabilities

[David Jander <david@protonic.nl>]

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.