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 [off-list ref] wrote:

quoted

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