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