mb() calls in octeon / loongson swiotlb dma_map_ops

mb() calls in octeon / loongson swiotlb dma_map_ops

[Christoph Hellwig]

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?

Re: mb() calls in octeon / loongson swiotlb dma_map_ops

[Huacai Chen]

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@lst.de> 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?
>

Re: mb() calls in octeon / loongson swiotlb dma_map_ops

[David Daney]

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@lst.de> 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


> 

Re: mb() calls in octeon / loongson swiotlb dma_map_ops

[Christoph Hellwig]

On Thu, Jan 04, 2018 at 05:21:17PM -0800, David Daney wrote:
> 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.

Ok.  And given that apparently octeon only uses swiotlb ops that's where
they were fitted in, instead of dma_cache_wback.

> Does the SWIOTLB DMA mapping code chain to the underlying systems DMA 
> mapping?  If so, the barriers there would be all that is necessary.

It doesn't.  But it also seems the underlying mips_default_dma_map_ops
ops is using entirely different interface for cache writeback before
dma.