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