Allow DMA buffer disassociation to prevent memory duplication

[almindor]

Motivations

I will be using esp32-c6 for this example since that's how I found out about this.

Right now, using DMA buffers with SPI requires passing them into the SpiDma struct in order to obtain a SpiBus/SpiDevice capable handle, using .with_buffers(). This means that drivers, such as display drivers (e.g. mipidsi) cannot buffer their draw operations directly into the DMA tx buffer, but need to essentially duplicate buffers and do an unnecessary copy.

Solution

If SpiDma itself was an implementor of SpiBus such that it was aware of the buffer descriptors and metadata but would not hold the actual &mut [u8] buffer pointer, it'd allow drivers to obtain access to that buffer directly and avoid the copy and additional buffer allocation.

Alternatives

It might be possible to "expose" the internalized buffer reference but that would require locking which is probably more expensive than the copy in this case.

Additional context

Manual reimplementation of Spi does allow this usage pattern.

[Dominaezzz]

To summarize, you're basically asking for something in between SpiDma and SpiDmaBus.

• SpiDma - base driver
• SpiDmaBus - SpiDma + descriptors + perfectly aligned/located buffer
• <the thing you want> - SpiDma + descriptors (no buffer)

This is basically what SpiDma looked like before #1785 .

Some kind of wrapper would work.

struct MySpiWrapper {
    spi_dma: SpiDma,
    descriptors: &'static mut [DmaDescriptor],
}

(Here's an example of someone doing the same thing but for a different peripheral)

By going this route, you sacrifice the chunking that SpiDmaBus does for you and the "it just works" nature of it, but in exchange you get the zero copy DMA.

[almindor]

By going this route, you sacrifice the chunking that SpiDmaBus does for you and the "it just works" nature of it, but in exchange you get the zero copy DMA.

Exactly, which is the main pain point for doing something like screen rendering, especially considering RAM constrained setups where you can "just" fit the framebuffer into RAM, but not much more. It's not just about 0 copy, it's also about deduplicating memory use.

[Frostie314159]

I second this, since it could provide a real performance improvement for my use case. I tried emulating the behavior with SpiDma, but it's pretty ugly.

In esp-wifi-hal we also use DMA, since the Wi-Fi peripheral requires it, and for TX we pin a DMA descriptor with the users buffer on the stack and start the transmission. Perhaps something similar could be done for SPI. (If what we're doing in the Wi-Fi driver is unsound, please LMK, since this is based on reverse engineering and I'm not that knowledgeable about the DMA peripheral.)