From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Xiubo Li <Li.Xiubo@freescale.com>,
mark.rutland@arm.com, s.hauer@pengutronix.de,
galak@codeaurora.org, swarren@wwwdotorg.org, t.figa@samsung.com,
grant.likely@linaro.org, matt.porter@linaro.org, rob@landley.net,
tomasz.figa@gmail.com, ian.campbell@citrix.com,
pawel.moll@arm.com, rob.herring@calxeda.com,
linux-arm-kernel@lists.infradead.org, linux-pwm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, Alison Wang <b18965@freescale.com>,
Jingchang Lu <b35083@freescale.com>
Subject: Re: [PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support
Date: Tue, 17 Dec 2013 12:58:32 +0000 [thread overview]
Message-ID: <20131217125832.GU4360@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20131217122431.GA17210@ulmo.nvidia.com>
On Tue, Dec 17, 2013 at 01:24:33PM +0100, Thierry Reding wrote:
> On Tue, Dec 17, 2013 at 11:51:36AM +0000, Russell King - ARM Linux wrote:
> > Same comments here - what memory operations is the wmb() trying to
> > serialise? Does this PWM driver somehow end up doing DMA?
>
> Not that I can see. But if my understanding is correct, not using the
> barriers would allow the compiler and CPU to reorder accesses, and by
> that cause the register accesses to potentially happen in the wrong
> order.
The compiler won't reorder them, but the CPU may if it meets certain
criteria. The architecture guarantees that accesses to device memory
within a (minimum of) 1KB block will be ordered.
The ARM ARM is slightly ambiguous in how this is applied - in one
place it says that "Accesses must arrive at any particular memory-mapped
peripheral or block of memory in program order" and another part it
says "The size of a memory mapped peripheral, or a block of memory,
is IMPLEMENTATION DEFINED, but is not smaller than 1KByte. Note
This implies that the maximum memory-mapped peripheral size for which
the architecture guarantees order for all implementations is 1KB." See
page A3-148.
What this means (to me at least) is that on any SoC, the architecture
guarantees that accesses _within_ a 1KB device memory block will always
be ordered, but two accesses outside of a 1KB block _to the same device_
is implementation defined whether it is ordered or not.
The interesting point here though is that the "note" contradicts the
first definition if you have (eg) AMBA Primecell peripherals which are
generally 4KB in size, since if the architecture only guarantees 1KB,
then accesses _may_ _not_ arrive at one primecell in program order.
Hence, the note is a direct contradiction of the first definition.
next prev parent reply other threads:[~2013-12-17 12:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 8:57 [PATCHv7 0/4] Add Freescale FTM PWM driver Xiubo Li
[not found] ` <1386925027-16288-1-git-send-email-Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2013-12-13 8:57 ` [PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support Xiubo Li
2013-12-17 11:10 ` Thierry Reding
2013-12-17 11:51 ` Russell King - ARM Linux
2013-12-17 12:00 ` Tomasz Figa
2013-12-17 12:45 ` Thierry Reding
2013-12-17 12:54 ` Tomasz Figa
2013-12-17 13:04 ` Russell King - ARM Linux
2013-12-17 13:08 ` Tomasz Figa
2013-12-17 13:22 ` Thierry Reding
2013-12-18 9:43 ` Li.Xiubo
2013-12-18 6:28 ` Li.Xiubo
2013-12-17 12:24 ` Thierry Reding
2013-12-17 12:58 ` Russell King - ARM Linux [this message]
2013-12-17 13:19 ` Thierry Reding
2013-12-18 3:34 ` Li.Xiubo
2013-12-13 8:57 ` [PATCHv7 2/4] ARM: dts: Add Freescale FTM PWM node for VF610 Xiubo Li
2013-12-13 8:57 ` [PATCHv7 3/4] ARM: dts: Enables FTM PWM device for Vybrid VF610 TOWER board Xiubo Li
2013-12-13 8:57 ` [PATCHv7 4/4] Documentation: Add device tree bindings for Freescale FTM PWM Xiubo Li
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=20131217125832.GU4360@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Li.Xiubo@freescale.com \
--cc=b18965@freescale.com \
--cc=b35083@freescale.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matt.porter@linaro.org \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=s.hauer@pengutronix.de \
--cc=swarren@wwwdotorg.org \
--cc=t.figa@samsung.com \
--cc=thierry.reding@gmail.com \
--cc=tomasz.figa@gmail.com \
/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).