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:29:28 +0000 [thread overview]
Message-ID: <20120216172928.GD9151@arm.com> (raw)
In-Reply-To: <20120216172242.GH27825@n2100.arm.linux.org.uk>
On Thu, Feb 16, 2012 at 05:22:42PM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 16, 2012 at 05:15:20PM +0000, Catalin Marinas wrote:
> > On Thu, Feb 16, 2012 at 04:41:02PM +0000, viresh kumar wrote:
> > > Sorry for starting the long old thread again, but i have to start it as i
> > > was a bit confused. :(
> > >
> > > We know that we can't have multiple mappings with different attributes
> > > to the same physical memory on ARMv6+ machines due to speculative
> > > prefetch.
> > >
> > > So, we have following kind of mappings in kernel now (please correct me
> > > if i am wrong):
> > > - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
> > > - ioremap() - blocked on Low Mem, so that we don't create Device type mapping
> > > to same mem
> > > - dma_alloc_coherent() and others:
> > > - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
> > > (i.e. Non cacheable - Non Bufferable)
> > > - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
> > > Bufferable mapping
> > > - Maybe some other too...
> > >
> > > I have a doubt with the last mapping mentioned above. We have two
> > > mappings possibly to the same physical memory, with different
> > > attributes: One is Cacheable and other one is not.
> > >
> > > Is this allowed by ARM? Because the patch in which Russell blocked
> > > ioremap on Low Mem, he clearly mentioned that these attributes are
> > > also important and they should be same.
> >
> > Section A3.5.7 in the latest ARM ARM (revC) clarifies the mismatched
>
> There's a new version?
Rev C has been available for a while. I thought you got it already:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html
It contains the LPAE and virtualisation extensions.
--
Catalin
next prev parent reply other threads:[~2012-02-16 17:29 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 [this message]
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
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=20120216172928.GD9151@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.