On Thu, Jan 11, 2024 at 3:32 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > On Thu, Jan 11, 2024 at 2:54 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > > > On Wed, Jan 10, 2024 at 3:36 PM Mark Brown <broonie@xxxxxxxxxx> 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. > > > > > > 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 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@xxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxx/
