Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306105

Re: [RFC PATCH] Add IPI entry for CPU UP

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH] Add IPI entry for CPU UP Zhaoyang Huang <zhaoyang.huang@linaro.org> - 2016-01-11 08:20 +0100
  Re: [RFC PATCH] Add IPI entry for CPU UP Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-11 11:00 +0100
    Re: [RFC PATCH] Add IPI entry for CPU UP Catalin Marinas <catalin.marinas@arm.com> - 2016-01-11 11:10 +0100
      Re: [RFC PATCH] Add IPI entry for CPU UP Mark Rutland <mark.rutland@arm.com> - 2016-01-11 12:10 +0100
        Re: [RFC PATCH] Add IPI entry for CPU UP Zhaoyang Huang <zhaoyang.huang@linaro.org> - 2016-01-11 12:30 +0100
          Re: [RFC PATCH] Add IPI entry for CPU UP Mark Rutland <mark.rutland@arm.com> - 2016-01-11 12:40 +0100
      RE: [RFC PATCH] Add IPI entry for CPU UP Zhaoyang Huang (黄朝阳)   <Zhaoyang.Huang@spreadtrum.com> - 2016-01-11 17:10 +0100

csiph-web