On 01/01/2018 06:28 PM, Huacai Chen wrote:
Loongson's code is derived from octeon. So, I also don't know whether
mb() is really needed.
Huacai
On Sun, Dec 31, 2017 at 12:09 AM, Christoph Hellwig <hch@xxxxxx> wrote:
Hi David and others,
I've recently been refactoring the dma direct mapping and swiotlb
code, and one odd thing I noticed is that the octeon and loongson
swiotlb ops have mb() calls after basically all swiotlb calls.
None of that is explained in either the earlier octeon dma map
commits, nor the commit that added the octeon swiotlb support
(b93b2abce497873be97d765b848e0a955d29f200), and neither in the
loonsoon commit that apparently copy and pasted it
(1299b0e05e106f621fff1504df5251f2a678097e).
Can someone explain what these memory barrier are supposed to do?
It has been a while since I wrote that code. It is possible that the
barriers are redundant.
On OCTEON, we the primitive that accomplishes the DMA-Sync operation is
the MIPS "SYNC" instruction, which ensures that all stores are committed
to the coherency point (L2 Cache) before the DMA is initiated. The
mb(), is implemented as SYNC, so we use that instead of open coding the
'asm volatile("sync" ::: "memory);' in the SWIOTLB operations.
Does the SWIOTLB DMA mapping code chain to the underlying systems DMA
mapping? If so, the barriers there would be all that is necessary.
Does that make any sense?
David Daney
