All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Derek Basehore <dbasehore@chromium.org>,
	linux-kernel@vger.kernel.org, Soby.Mathew@arm.com,
	sudeep.holla@arm.com, devicetree@vger.kernel.org,
	robh+dt@kernel.org, mark.rutland@arm.com,
	linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com,
	tglx@linutronix.de
Subject: Re: [PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume
Date: Wed, 7 Feb 2018 15:22:02 -0800	[thread overview]
Message-ID: <20180207232201.GB106856@ban.mtv.corp.google.com> (raw)
In-Reply-To: <8276f426-e4a0-c400-9f87-31be3d6b1733@arm.com>

Hi Marc,

I'm really not an expert on this, so take my observations with a large
grain of salt:

On Wed, Feb 07, 2018 at 08:46:42AM +0000, Marc Zyngier wrote:
> On 07/02/18 01:41, Derek Basehore wrote:
> > This adds functionality to resend the MAPC command to an ITS node on
> > resume. If the ITS is powered down during suspend and the collections
> > are not backed by memory, the ITS will lose that state. This just sets
> > up the known state for the collections after the ITS is restored.
> > 
> > This is enabled via the reset-on-suspend flag in the DTS for an ITS
> > that has a non-zero number of collections stored in it.
> > 
> > Signed-off-by: Derek Basehore <dbasehore@chromium.org>
> > ---
> >  drivers/irqchip/irq-gic-v3-its.c   | 80 ++++++++++++++++++++------------------
> >  include/linux/irqchip/arm-gic-v3.h |  1 +
> >  2 files changed, 43 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index 5e63635e2a7b..dd6cd6e68ed0 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -1942,52 +1942,53 @@ static void its_cpu_init_lpis(void)
> >  	dsb(sy);
> >  }
> >  
> > -static void its_cpu_init_collection(void)
> > +static void its_cpu_init_collection(struct its_node *its)

...

> > @@ -3127,6 +3128,9 @@ static void its_restore_enable(void)
> >  			its_write_baser(its, baser, baser->val);
> >  		}
> >  		writel_relaxed(its->ctlr_save, base + GITS_CTLR);
> > +
> > +		if (GITS_TYPER_HWCOLLCNT(gic_read_typer(base + GITS_TYPER)) > 0)
> > +			its_cpu_init_collection(its);
> 
> This isn't correct. Think of a system where half the collections are in
> HW, and the other half memory based (nothing in the spec forbids this).
> You must evaluate the CID of each collection and replay the MAPC *only*
> if it falls into the range [0..HCC-1]. The memory-based collections are
> already mapped, and remapping an already mapped collection requires
> extra care (see MAPC and the UNPREDICTABLE behaviour when V=1), so don't
> go there.

IIUC, this is only run on CPU0 (it's in syscore resume), so implicitly,
CID is 0. Thus, the current condition is already doing what you ask:

	HCC > 0 == CID

which is equivalent to:

	HCC - 1 >= CID

Or should we really double check what CPU we're running on?

Brian

  reply	other threads:[~2018-02-07 23:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07  1:41 [PATCH v5 0/5] GICv3 Save and Restore Derek Basehore
2018-02-07  1:41 ` Derek Basehore
2018-02-07  1:41 ` [PATCH v5 1/4] cpu_pm: add syscore_suspend error handling Derek Basehore
2018-02-07  8:57   ` Marc Zyngier
2018-02-07  8:57     ` Marc Zyngier
2018-02-07 22:01     ` Brian Norris
2018-02-07 22:10       ` Marc Zyngier
2018-02-07  1:41 ` [PATCH v5 2/4] irqchip/gic-v3-its: add ability to save/restore ITS state Derek Basehore
2018-02-07  9:18   ` Marc Zyngier
2018-02-07  1:41 ` [PATCH v5 3/4] DT/arm,gic-v3-its: add reset-on-suspend property Derek Basehore
2018-02-07  9:21   ` Marc Zyngier
2018-02-08  2:59     ` dbasehore .
2018-02-08  2:59       ` dbasehore .
2018-02-07  1:41 ` [PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume Derek Basehore
2018-02-07  8:46   ` Marc Zyngier
2018-02-07 23:22     ` Brian Norris [this message]
2018-02-08  0:00       ` dbasehore .
2018-02-08  9:08         ` Marc Zyngier
2018-02-08  9:08           ` Marc Zyngier

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=20180207232201.GB106856@ban.mtv.corp.google.com \
    --to=briannorris@chromium.org \
    --cc=Soby.Mathew@arm.com \
    --cc=dbasehore@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    /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.