From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness
Date: Tue, 08 Mar 2011 20:58:20 -0800 [thread overview]
Message-ID: <4D7708EC.9020806@codeaurora.org> (raw)
In-Reply-To: <20110303102411.GB13179@n2100.arm.linux.org.uk>
On 03/03/2011 02:24 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 02, 2011 at 11:49:47PM -0800, Saravana Kannan wrote:
>>> I think you misunderstand what's going on. IO accesses are always ordered
>>> with respect to themselves. The barriers are there to ensure ordering
>>> between DMA coherent memory (normal non-cached memory) and IO accesses
>>> (device).
>>
>> Unfortunately this is not correct. The ARM spec doesn't guarantee that
>> all IO accesses should be ordered with respect to themselves. It only
>> requires that the ordering should be guaranteed at least within a 1KB
>> region.
>>
>> You can find this info in ARMv7 ARM spec[1] named
>> "DDI0406B_arm_architecture_reference_manual_errata_markup_8_0.pdf", on
>> page A3-45. There is a para that goes:
>>
>> "Accesses must arrive at any particular memory-mapped peripheral or
>> block of memory in program order, that is, A1 must arrive before A2.
>> There are no ordering restrictions about when accesses arrive at
>> different peripherals or blocks of memory, provided that the accesses
>> follow the general ordering rules given in this section."
>
> That is news to me. My DDI0406B does not have this paragraph, so it's
> something that ARM has sprung upon us without telling *anyone* about it.
> It's not unreasonable or even unexpected. That is exactly the same
> condition which applies on buses like PCI due to write posting on bridges
> downstream of the CPU, and issuing memory barriers will not help with
> that.
While the PCI stuff is true, as you say, it's not related to mb()s. The
mb()s matter to the point of getting the writes to the intended
"devices addresses" in the program order. What happens after that is a
separate issue.
So, going back to the discussion of mb()s and readl/writel (and
variations), I think we should no longer state the all IO accesses are
ordered wrt each other. Are we in agreement on this?
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-03-09 4:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-02 1:23 CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness Saravana Kannan
2011-03-02 8:23 ` Arnd Bergmann
2011-03-03 7:57 ` Saravana Kannan
2011-03-02 8:39 ` Russell King - ARM Linux
2011-03-03 7:49 ` Saravana Kannan
2011-03-03 10:11 ` Catalin Marinas
2011-03-09 4:37 ` Saravana Kannan
2011-03-03 10:24 ` Russell King - ARM Linux
2011-03-09 4:58 ` Saravana Kannan [this message]
2011-03-09 8:05 ` Russell King - ARM Linux
2011-03-09 9:32 ` Saravana Kannan
2011-03-09 9:38 ` 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=4D7708EC.9020806@codeaurora.org \
--to=skannan@codeaurora.org \
--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).