On Thu, Mar 20, 2025 at 03:35:36PM +0100, Petr Tesarik wrote: > CC'ing Robin Murphy, because there seem to be some doubts about DMA API > efficiency. Or possibly just documentation, the number of memory types we have to deal with and disjoint interfaces makes all this stuff pretty miserable. > > > The whole goal there is to try to avoid triggering another copy to do > > > the DMA so just reverting rather than replacing with some other > > > construct that achieves the same goal doesn't seem great. I think > > > possibly we should just not do the copy at all any more and trust the > > > core to DTRT with any buffers that are passed in, I think we've got > > > enough stuff in the core though I can't remember if it'll copy with > > > things allocated on the stack well. I'd need to page the status back > > > in. > No, I'm afraid kernel stack addresses (and many other types of > addresses) cannot be used for DMA: > https://docs.kernel.org/core-api/dma-api-howto.html#what-memory-is-dma-able Right, that's what I thought. Part of what spi_write_then_read() is doing is taking the edge off that particular sharp edge for users, on the off chance that the controller wants to DMA. > > From what I found, there are two scenarios that may depend on > > GFP_DMA today: > > a) a performance optimization where allocating from GFP_DMA avoids > > the swiotlb bounce buffering. This would be the normal case on > > any 64-bit machine with more than 4GB of RAM and an SPI > > controller with a 32-bit DMA mask. > I must be missing something. How is a memcpy() in spi_write_then_read() > faster than a memcpy() by swiotlb? spi_write_then_read() is just a convenience API, a good proportion of users will be using spi_sync() directly. > I still believe the SPI subsystem should not try to be clever. The > DMA API already avoids unnecessary copying as much as possible. It's not particularly trying to be clever here?
Attachment:
signature.asc
Description: PGP signature
