From: Christoph Hellwig <hch@lst.de>
To: David Daney <ddaney@caviumnetworks.com>
Cc: "Huacai Chen" <chenhc@lemote.com>,
"Christoph Hellwig" <hch@lst.de>,
"David Daney" <ddaney@cavium.com>,
"Hongliang Tao" <taohl@lemote.com>, "Hua Yan" <yanh@lemote.com>,
"Alex Smith" <alex.smith@imgtec.com>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Linux MIPS Mailing List" <linux-mips@linux-mips.org>
Subject: Re: mb() calls in octeon / loongson swiotlb dma_map_ops
Date: Tue, 9 Jan 2018 19:31:03 +0100 [thread overview]
Message-ID: <20180109183103.GA13983@lst.de> (raw)
In-Reply-To: <0fa48a91-6987-85e8-49fc-d39c5461be1e@caviumnetworks.com>
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.
prev parent reply other threads:[~2018-01-09 18:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-30 16:09 mb() calls in octeon / loongson swiotlb dma_map_ops Christoph Hellwig
2018-01-02 2:28 ` Huacai Chen
2018-01-05 1:21 ` David Daney
2018-01-09 18:31 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180109183103.GA13983@lst.de \
--to=hch@lst.de \
--cc=alex.smith@imgtec.com \
--cc=chenhc@lemote.com \
--cc=ddaney@cavium.com \
--cc=ddaney@caviumnetworks.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=taohl@lemote.com \
--cc=yanh@lemote.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox