public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Zhaoyang Huang <zhaoyang.huang@linaro.org>
Cc: "Zhaoyang Huang (黄朝阳)" <Zhaoyang.Huang@spreadtrum.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>
Subject: Re: [RFC PATCH] Add IPI entry for CPU UP
Date: Mon, 11 Jan 2016 11:37:57 +0000	[thread overview]
Message-ID: <20160111113756.GJ6499@leverpostej> (raw)
In-Reply-To: <CAN2waFtHDYB2f80+pv+K82L+Kx=ObETnfW_TXQggNywnRcnEnw@mail.gmail.com>

On Mon, Jan 11, 2016 at 07:21:32PM +0800, Zhaoyang Huang wrote:
> On 11 January 2016 at 19:03, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Jan 11, 2016 at 10:55:08AM +0000, Zhaoyang Huang (黄朝阳) wrote:
> >> In fact, this patch is related to the counterpart of the PSCI code in
> >> kernel world which you mentioned before. In SPRD's SOC, we have to
> >> implement a way of "wakeup" the core in powerdown state, which is to
> >> launch a IPI to the dest core.
> >
> > This is not required with PSCI, which abstracts the wakeup and power
> > management behind the CPU_ON call.
> >
> > The kernel should only have to issue a CPU_ON call, and the firmware
> > should do the right thing behind the scenes (e.g. enabling power to the
> > core, sending an IPI if necessary).
> >
> > If the kernel needs to do anything other than issue a CPU_ON call, this
> > is not PSCI.
> >
> >> The reason why we can not accessing power related register to light on
> >> the core is the state machine of the PMU will not be safe for this
> >> scenario.
> >
> > I'm not sure I understand.
> >
> > Which software agent (kernel? firmware?) cannot access this PMU
> > register, and why?
> >
> > What is the problem with the PMU state machine?
> >
> With regarding to the cpu down, we use a so called "auto power down"
> mode, which have the PMU power down the core after it detect WFI
> status(in fact, it is the same method for cpu suspend for our SOC). By
> using this kind of method of power down, we have to use the method
> which I mentioned above for power on.

Even if you need an IPI to bring the CPU back online, I don't see why
this needs to be in the kernel. That can (and must) be done in the
firmware, hidden behind the PSCI interface.

The logical flow should be:

  CPU x: Kernel calls PSCI CPU_OFF
  CPU x: PSCI FW puts core in "auto power down" mode
  CPU x: PSCI FW issues a WFI
  CPU x: offline

  CPU y: Kernel calls PSCI CPU_ON for CPU x
  CPU y: PSCI FW sets up power controller
  CPU y: PSCI FW issues IPI to CPU x
  CPU y: PSCI FW waits for CPU x to come online

  CPU x: comes online
  CPU y: Returns to kernel

  CPU x: initialised by FW
  CPU x: enters kernel at provided entry point

Note that from the kernel's PoV, it only needs to call CPU_ON and
CPU_OFF.

> In fact, we have ever used another method of on/off, which have NOT
> the issue of launch IPI(we call it as force shutdown). But it has some
> stability problem for cpu on(PC will run out of range. ASIC engineers
> ask us to switch to auto mode to solve it)

I don't think this is relevant. See above.

I assume that the core is only placed in "auto power down" mode in the
firmware immediately before the WFI (i.e. a WFI in the kernel will not
trigger a power down spuriously)?

Thanks,
Mark.

      reply	other threads:[~2016-01-11 11:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11  7:10 [RFC PATCH] Add IPI entry for CPU UP Zhaoyang Huang
2016-01-11  9:59 ` Lorenzo Pieralisi
2016-01-11 10:06   ` Catalin Marinas
2016-01-11 10:55     ` Zhaoyang Huang (黄朝阳)
2016-01-11 11:03       ` Mark Rutland
2016-01-11 11:21         ` Zhaoyang Huang
2016-01-11 11:37           ` Mark Rutland [this message]

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=20160111113756.GJ6499@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Zhaoyang.Huang@spreadtrum.com \
    --cc=catalin.marinas@arm.com \
    --cc=hanjun.guo@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    --cc=zhaoyang.huang@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox