From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Query: Multiple Mappings to Mem and ARMV6+
Date: Mon, 20 Feb 2012 17:57:23 +0000 [thread overview]
Message-ID: <20120220175723.GJ26840@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAOh2x=nqancNQ1sHpcPFMm+rcPGYEPZ5-YvKeOo6N_TE+fOjTw@mail.gmail.com>
On Mon, Feb 20, 2012 at 09:48:56AM -0800, viresh kumar wrote:
> On Feb 20, 2012 4:31 PM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:
> >
> > On 16 February 2012 18:14, viresh kumar <viresh.linux@gmail.com> wrote:
> > > On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
> > > <catalin.marinas@arm.com> wrote:
> > >> The DMA API implementation on ARM takes care of the cache cleaning and
> > >> invalidating.
> > >
> > > I believe that this is the reason why we have cache re-invalidation
> > > (we invalidated
> > > it in dma_map_*() earlier) in dma_unmap_*() calls for ARMv6+ for
> > > DMA_FROM_DEVICE.
> > > Am i Correct?
> >
> > Yes.
> >
>
> But why isn't keeping only the second one sufficient? Why don't we remove
> it from dma_map_* routines?
Please don't think for a moment that anyone likes the idea of having to
walk over the cache twice for every DMA operation. We don't. But I can
assure you that it's very very necessary.
The first run through the affected cache lines on dma_map_*() is there
to get rid of any cache lines for the buffer which may be marked 'dirty'.
A dirty cache line can be evicted (written back) to memory at _any_ time.
If this occurs while the DMA controller is reading data from a device,
the results depend on the order which the particular cache line is written
by the DMA controller, and by the cache line eviction.
If the cache line eviction happens after the DMA controller has written,
the DMA'd data will be overwritten by old stale data.
So, we must get rid of these dirty cache lines. We can do that either
by cleaning the cache lines or invalidating them. We chose to invalidate
them because it makes very little difference.
For the case where the DMA controller needs to read from memory, we
obviously have to ensure that all data is pushed out of the cache for it
to be visible to the DMA controller. For this case, merely cleaning the
cache is sufficient.
The second run through the affected cache lines is to prevent speculative
prefetches occuring while the DMA controller is on operation, which could
result in old data (before the DMA controller has written its data) being
read by the CPU, resulting again in old stale data.
I hope it's now clear why we need to run over the buffer twice.
prev parent reply other threads:[~2012-02-20 17:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-16 16:41 Query: Multiple Mappings to Mem and ARMV6+ viresh kumar
2012-02-16 17:15 ` Catalin Marinas
2012-02-16 17:22 ` Russell King - ARM Linux
2012-02-16 17:29 ` Catalin Marinas
2012-02-16 17:36 ` Russell King - ARM Linux
2012-02-16 17:37 ` viresh kumar
2012-02-16 17:48 ` Catalin Marinas
2012-02-16 18:14 ` viresh kumar
2012-02-20 11:00 ` Catalin Marinas
[not found] ` <CAOh2x=nqancNQ1sHpcPFMm+rcPGYEPZ5-YvKeOo6N_TE+fOjTw@mail.gmail.com>
2012-02-20 17:57 ` Russell King - ARM Linux [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=20120220175723.GJ26840@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).