linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: Query: Multiple Mappings to Mem and ARMV6+
Date: Thu, 16 Feb 2012 17:48:13 +0000	[thread overview]
Message-ID: <20120216174813.GE9151@arm.com> (raw)
In-Reply-To: <CAOh2x=nUPb-CcyJBmZ2wv=tsNzi=r3F16NynsbChXD=q5hSGiw@mail.gmail.com>

On Thu, Feb 16, 2012 at 05:37:02PM +0000, viresh kumar wrote:
> On Thu, Feb 16, 2012 at 9:15 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > To summarise, if you mix Normal with Device or SO memory, you only get
> > the guarantees of the Normal memory (e.g. early write acknowledgement,
> > write buffer gathering, speculative accesses), so it's not recommended.
> > If you mix Normal Cacheable with Normal Non-cacheable, you need to make
> > sure that the cacheable mapping does not have any dirty cache lines that
> > could be evicted. Additionally, if you read the buffer through the
> > cacheable mapping later, you need to invalidate it first in case cache
> > lines have been speculatively fetched. The ARM ARM definition however
> > guarantees that accesses through the Non-cacheable mapping does not hit
> > any cache lines (brought in via the Cacheable mapping).
> 
> I don't know if i understood correctly the earlier mails over the list, but with
> speculative writes to Normal Cacheable Memory (Low Mem), we can still
> enter an undefined state if we have separate kind of mapping as we have in
> dma_alloc_*() and low mem.
> 
> Or
> 
> Who is responsible here to take care of cleaning and invalidate cached low
> mem mappings in case of speculative writes?

The DMA API implementation on ARM takes care of the cache cleaning and
invalidating.

BTW, I would say cache evictions rather than speculative writes as the
latter is something else and ARM processors don't do it (only
speculative reads).

-- 
Catalin

  reply	other threads:[~2012-02-16 17:48 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 [this message]
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

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=20120216174813.GE9151@arm.com \
    --to=catalin.marinas@arm.com \
    --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).