On 2021-09-09 08:07, Christoph Hellwig wrote:
Andreas - while I've got your attention: I've been looking into fully converting sparc32 to the generic DMA code. Do you have any documentation for the Leon cache handling in dma_make_coherent, and more importantly how that applies to the dma coherent handling? I could see how a flush might be required for the streaming DMA mappings, that is mapping normal cached memory for I/O. But for the coherent allocations which can be accessed from the device and the cpu without another DMA mapping call this seems really strange.
As long as the area passed to arch_dma_free is mapped by arch_dma_allocate, I don't see why the call to dma_make_coherent in arch_dma_free should be needed. I am not sure if there are any current (or historical paths) where we nevertheless have a cacheable mapping when we reach arch_dma_free (or the historical pci32_free_coherent). The usual case for LEON systems is that cache snooping on the CPU side invalidates cache lines matching DMA that the CPU sees on the bus. Under the assumption that DMA accesses are seen on the processor bus, this is the reason for only flushing if snooping is not enabled in dma_make_coherent. -- Andreas Larsson
