All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] ARM: cache: remove redundant dsb instruction from v7_coherent_user_range
Date: Fri, 9 May 2014 17:16:09 +0100	[thread overview]
Message-ID: <20140509161609.GM7950@arm.com> (raw)
In-Reply-To: <1399044255-20435-3-git-send-email-will.deacon@arm.com>

On Fri, May 02, 2014 at 04:24:09PM +0100, Will Deacon wrote:
> v7_coherent_user_range takes a virtual address range, cleans the D-side
> to PoU and then invalidates the I-side so that subsequent instruction
> fetches can see any new data written to the range in question.
> 
> Since cache maintenance by MVA is architected to execute in program
> order with respect to other cache maintenance operations specifying
> the same virtual address, we do not require a barrier between the
> D-side clean and the I-side invalidation.
> 
> This patch removes the redundant dsb.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm/mm/cache-v7.S | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index 615c99e38ba1..b040d3ca20ac 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -282,7 +282,6 @@ ENTRY(v7_coherent_user_range)
>  	add	r12, r12, r2
>  	cmp	r12, r1
>  	blo	1b
> -	dsb	ishst
>  	icache_line_size r2, r3
>  	sub	r3, r2, #1
>  	bic	r12, r0, r3

The original implementation follows the ARMv7 ARM example for self
modifying code which has a DSB. I agree with you that the section B2.2.9
(ARMv7 ARM - Ordering of cache and branch predictor maintenance
operations) states that ops by MVA would be ordered with each-other.

Time for clarification higher up? ;)

-- 
Catalin

  reply	other threads:[~2014-05-09 16:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 15:24 [PATCH 0/8] ARM/arm64 Barrier cleanups and fixes for 3.16 Will Deacon
2014-05-02 15:24 ` [PATCH 1/8] ARM: cacheflush: use -st dsb option for ensuring completion Will Deacon
2014-05-02 15:24 ` [PATCH 2/8] ARM: cache: remove redundant dsb instruction from v7_coherent_user_range Will Deacon
2014-05-09 16:16   ` Catalin Marinas [this message]
2014-05-09 18:25     ` Will Deacon
2014-05-02 15:24 ` [PATCH 3/8] arm64: barriers: make use of barrier options with explicit barriers Will Deacon
2014-05-02 15:24 ` [PATCH 4/8] arm64: barriers: wire up new barrier options Will Deacon
2014-05-02 15:24 ` [PATCH 5/8] arm64: barriers: use barrier() instead of smp_mb() when !SMP Will Deacon
2014-05-02 15:24 ` [PATCH 6/8] arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag Will Deacon
2014-05-02 15:24 ` [PATCH 7/8] arm64: kvm: use inner-shareable barriers for inner-shareable maintenance Will Deacon
2014-05-02 15:24 ` [PATCH 8/8] arm64: mm: " Will Deacon

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=20140509161609.GM7950@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.