All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
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 14:19:53 +0100	[thread overview]
Message-ID: <20131217131951.GA2329@ulmo.nvidia.com> (raw)
In-Reply-To: <20131217125832.GU4360@n2100.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

On Tue, Dec 17, 2013 at 12:58:32PM +0000, Russell King - ARM Linux wrote:
> 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.

None of the ARM ARM versions that I have seem to have page A3-148. Which
version should I be looking at? Not that I'm in any way doubting what
you're saying, I'd just like to make sure to have the correct reference
to look at in the future.

> 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.

This means at least every ARM SoC would behave that way. Since this
driver doesn't have an explicit dependency on ARM I assume it could
eventually be used on a different architecture. Even more so since
there's Freescale in the name.

> 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.

Interesting indeed. Perhaps implementation defined in this case means
that an implementation would have to adjust the size of a memory mapped
peripheral or block of memory accordingly, depending on the largest
block within the SoC.

I suppose, though, that if the architecture doesn't give any guarantees
about it, we can't safely assume that the implementation will.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv7 1/4] pwm: Add Freescale FTM PWM driver support
Date: Tue, 17 Dec 2013 14:19:53 +0100	[thread overview]
Message-ID: <20131217131951.GA2329@ulmo.nvidia.com> (raw)
In-Reply-To: <20131217125832.GU4360@n2100.arm.linux.org.uk>

On Tue, Dec 17, 2013 at 12:58:32PM +0000, Russell King - ARM Linux wrote:
> 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.

None of the ARM ARM versions that I have seem to have page A3-148. Which
version should I be looking at? Not that I'm in any way doubting what
you're saying, I'd just like to make sure to have the correct reference
to look at in the future.

> 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.

This means at least every ARM SoC would behave that way. Since this
driver doesn't have an explicit dependency on ARM I assume it could
eventually be used on a different architecture. Even more so since
there's Freescale in the name.

> 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.

Interesting indeed. Perhaps implementation defined in this case means
that an implementation would have to adjust the size of a memory mapped
peripheral or block of memory accordingly, depending on the largest
block within the SoC.

I suppose, though, that if the architecture doesn't give any guarantees
about it, we can't safely assume that the implementation will.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131217/5b351e0f/attachment.sig>

  reply	other threads:[~2013-12-17 13:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13  8:57 [PATCHv7 0/4] Add Freescale FTM PWM driver Xiubo Li
2013-12-13  8:57 ` Xiubo Li
2013-12-13  8:57 ` 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-13  8:57     ` Xiubo Li
2013-12-13  8:57     ` Xiubo Li
2013-12-17 11:10     ` Thierry Reding
2013-12-17 11:10       ` Thierry Reding
2013-12-17 11:51       ` Russell King - ARM Linux
2013-12-17 11:51         ` Russell King - ARM Linux
2013-12-17 12:00         ` Tomasz Figa
2013-12-17 12:00           ` Tomasz Figa
2013-12-17 12:45           ` Thierry Reding
2013-12-17 12:45             ` Thierry Reding
2013-12-17 12:45             ` Thierry Reding
2013-12-17 12:54             ` Tomasz Figa
2013-12-17 12:54               ` Tomasz Figa
2013-12-17 13:04               ` Russell King - ARM Linux
2013-12-17 13:04                 ` Russell King - ARM Linux
2013-12-17 13:08                 ` Tomasz Figa
2013-12-17 13:08                   ` Tomasz Figa
2013-12-17 13:22                 ` Thierry Reding
2013-12-17 13:22                   ` Thierry Reding
2013-12-18  9:43                 ` Li.Xiubo
2013-12-18  9:43                   ` Li.Xiubo
2013-12-18  9:43                   ` Li.Xiubo at freescale.com
2013-12-18  6:28             ` Li.Xiubo
2013-12-18  6:28               ` Li.Xiubo
2013-12-18  6:28               ` Li.Xiubo at freescale.com
2013-12-17 12:24         ` Thierry Reding
2013-12-17 12:24           ` Thierry Reding
2013-12-17 12:58           ` Russell King - ARM Linux
2013-12-17 12:58             ` Russell King - ARM Linux
2013-12-17 13:19             ` Thierry Reding [this message]
2013-12-17 13:19               ` Thierry Reding
2013-12-18  3:34       ` Li.Xiubo
2013-12-18  3:34         ` Li.Xiubo at freescale.com
2013-12-13  8:57 ` [PATCHv7 2/4] ARM: dts: Add Freescale FTM PWM node for VF610 Xiubo Li
2013-12-13  8:57   ` Xiubo Li
2013-12-13  8:57   ` 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   ` Xiubo Li
2013-12-13  8:57   ` Xiubo Li
2013-12-13  8:57 ` [PATCHv7 4/4] Documentation: Add device tree bindings for Freescale FTM PWM Xiubo Li
2013-12-13  8:57   ` Xiubo Li
2013-12-13  8:57   ` 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=20131217131951.GA2329@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --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=linux@arm.linux.org.uk \
    --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=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 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.