All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
Date: Thu, 6 Feb 2014 11:57:39 +0000	[thread overview]
Message-ID: <20140206115739.GP26035@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20140206115430.GN29446@arm.com>

On Thu, Feb 06, 2014 at 11:54:30AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 11:51:21AM +0000, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 11:45:59AM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > > > index 341c6016812d..03fe5ef3f2fe 100644
> > > > --- a/drivers/irqchip/irq-gic.c
> > > > +++ b/drivers/irqchip/irq-gic.c
> > > > @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > >  	/*
> > > >  	 * Ensure that stores to Normal memory are visible to the
> > > >  	 * other CPUs before issuing the IPI.
> > > > +	 *
> > > > +	 * This always happens on GIC0.
> > > >  	 */
> > > > -	dsb();
> > > > -
> > > > -	/* this always happens on GIC0 */
> > > > -	writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > > +	writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > 
> > > That's heavier than a dsb() since with outer caches on ARM we also get
> > > an outer_sync() call.
> > 
> > Yes, which I think we actually need in this case, since we're trying to make
> > normal writes visible to a CPU before a device write hits the GIC.
> 
> If they are all in the inner shareable domain and with the caches
> enabled, we don't need to flush the outer cache (as in the PL310 case
> which is common to all CPUs; other saner outer caches propagate the
> barrier ;). The outer_sync is needed when the memory accesses are
> non-cacheable and we need to drain both the CPU write-buffer and the
> PL310 one.
> 
> For our case here, we only need to ensure the visibility of writes on a
> CPU to another but assuming SMP and caches enabled, so DSB is enough.

Hmm, but we *do* use this for boot and need to ensure that any mailboxes are
visible. Maybe we have enough cacheflushing/barriers for that already, but
I'm really uncomfortable making this a simple dsb(ishst).

Will

  reply	other threads:[~2014-02-06 11:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 11:30 [PATCH 1/6] arm64: barriers: allow dsb macro to take option parameter Will Deacon
2014-02-06 11:30 ` [PATCH 2/6] arm64: barriers: make use of barrier options with explicit barriers Will Deacon
2014-02-06 11:41   ` Catalin Marinas
2014-02-06 11:45     ` Will Deacon
2014-02-06 11:49       ` Catalin Marinas
2014-02-06 11:52         ` Will Deacon
2014-02-06 11:30 ` [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed Will Deacon
2014-02-06 11:39   ` Marc Zyngier
2014-02-06 11:45   ` Catalin Marinas
2014-02-06 11:51     ` Will Deacon
2014-02-06 11:54       ` Catalin Marinas
2014-02-06 11:57         ` Will Deacon [this message]
2014-02-06 12:00           ` Catalin Marinas
2014-02-06 12:13             ` Will Deacon
2014-02-06 12:23               ` Catalin Marinas
2014-02-06 13:26                 ` Will Deacon
2014-02-06 15:20                   ` Catalin Marinas
2014-02-07 11:23                     ` Will Deacon
2014-02-07 12:57                       ` Catalin Marinas
2014-02-14 16:30                       ` Will Deacon
2014-02-14 16:48                         ` Catalin Marinas
2014-02-14 17:18                           ` Rob Herring
2014-02-06 11:30 ` [PATCH 4/6] iommu/arm-smmu: provide option to dsb macro when publishing tables Will Deacon
2014-02-06 11:51   ` Catalin Marinas
2014-02-06 11:30 ` [PATCH 5/6] arm64: barriers: wire up new barrier options Will Deacon
2014-02-06 11:55   ` Catalin Marinas
2014-02-06 11:30 ` [PATCH 6/6] arm64: barriers: use barrier() instead of smp_mb() when !SMP Will Deacon
2014-02-06 11:56   ` Catalin Marinas
2014-02-06 11:39 ` [PATCH 1/6] arm64: barriers: allow dsb macro to take option parameter Catalin Marinas

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=20140206115739.GP26035@mudshark.cambridge.arm.com \
    --to=will.deacon@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.