From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] pstore-ram: use write-combine mappings
Date: Tue, 16 Apr 2013 07:58:27 -0500 [thread overview]
Message-ID: <516D4AF3.5060205@gmail.com> (raw)
In-Reply-To: <20130416084418.GA30756@mudshark.cambridge.arm.com>
On 04/16/2013 03:44 AM, Will Deacon wrote:
> On Tue, Apr 16, 2013 at 01:43:09AM +0100, Colin Cross wrote:
>> On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring <robherring2@gmail.com> wrote:
>>> Exclusive accesses still have further restrictions. From section 3.4.5:
>>>
>>> ? It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be
>>> performed to a memory region
>>> with the Device or Strongly-ordered memory attribute. Unless the
>>> implementation documentation explicitly
>>> states that LDREX and STREX operations to a memory region with the
>>> Device or Strongly-ordered attribute are
>>> permitted, the effect of such operations is UNPREDICTABLE.
>>>
>>>
>>> Given that it is implementation defined, I don't see how Linux can rely
>>> on that behavior.
>>
>> I see, the problem is that while noncached and writecombined appear to
>> be similar mappings, noncached is mapped in PRRR to strongly-ordered,
>> while writecombined is mapped to unbufferable normal memory.
>>
>> I think adding a wmb() to persistent_ram_write is going to be
>> expensive on cpus with outer caches like the L2X0, where wmb() will
>> result in a spinlock. Is there a real SoC where this doesn't work?
>
> A real SoC where exclusives don't work to memory not mapped as normal? Take
> your pick...
This patch doesn't actually fix problems for me. Exclusives to DDR work
for any memory type for me as the DDR controller has an exclusive
monitor. It takes write-thru cache mapping to get internal RAM to work.
Rob
next prev parent reply other threads:[~2013-04-16 12:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 3:08 [RFC PATCH 1/3] pstore-ram: use write-combine mappings Rob Herring
2013-04-10 3:08 ` [RFC PATCH 2/3] pstore ram: remove the power of buffer size limitation Rob Herring
2013-04-10 3:08 ` [RFC PATCH 3/3] pstore/ram: avoid atomic accesses for ioremapped regions Rob Herring
2013-04-10 4:10 ` Colin Cross
2013-04-10 15:55 ` Rob Herring
2013-04-10 3:53 ` [RFC PATCH 1/3] pstore-ram: use write-combine mappings Colin Cross
2013-04-10 13:30 ` Rob Herring
2013-04-15 22:21 ` Colin Cross
2013-04-15 23:59 ` Rob Herring
2013-04-16 0:43 ` Colin Cross
2013-04-16 8:44 ` Will Deacon
2013-04-16 12:58 ` Rob Herring [this message]
2013-04-16 13:48 ` Catalin Marinas
2013-04-19 9:54 ` 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=516D4AF3.5060205@gmail.com \
--to=robherring2@gmail.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).