[PSCI DISCUSS] How to implement standby and suspend-to-ram by PSCI

[Hongbo Zhang]

> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, May 12, 2016 6:09 PM
> To: Hongbo Zhang <hongbo.zhang at nxp.com>; linux-pm at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla at arm.com>; Mark Rutland
> <mark.rutland at arm.com>; jszhang at marvell.com; Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com>; Frank Li <Frank.Li at freescale.com>; Marc Zyngier
> <marc.zyngier at arm.com>; Jan Kiszka <jan.kiszka at siemens.com>; Daniel
> Lezcano <daniel.lezcano at linaro.org>; Peng Fan <Peng.Fan at freescale.com>;
> Hans de Goede <hdegoede at redhat.com>; Chen-Yu Tsai <wens at csie.org>;
> Tom Warren <twarren at nvidia.com>; Vincent Guittot
> <vincent.guittot at linaro.org>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PSCI DISCUSS] How to implement standby and suspend-to-ram by
> PSCI
> 
> 
> 
> On 12/05/16 10:42, Hongbo Zhang wrote:
> > Hi Sudeep,
> >
> 
> [...]
> 
> >
> > Sleep state:
> > All cores are in WFI state,
> > Core cluster is in standby state, e.g. L2 cache is flushed then stops
> > snooping,
> > Only those modules which are required to wake up the device still have a
> > running clock, other device modules in chip are clock gated.
> >
> > Deep sleep state:
> > ARM cores and DDR controller are switched off,
> > DDR is in self-refresh mode,
> > VDD power to off domain IPs are removed, Only the blocks needed to
> > detect wake up and sequence the chip out of deep sleep are on.
> >
> > For the two states, except for the wake-up devices, all the other device
> > dirver's suspend callback needs to be called because those devices will
> > be clock or power gated off. So, the kernel suspend process (freeze
> > tasks, suspend devices etc) are needed for our sleep and deep sleep states.
> > In fact we've already implemented these two stated by legacy way, e.g.
> > mapping sleep state to STANDBY and deep sleep to MEM, both states are
> > implemented in one traditional .enter callback and can be indexed by a
> > 'state' parameter.
> >
> 
> Yes I understand that.
> 
> > While transferring to PSCI, we met the problem I mentioned.
> >
> > As to the freeze(suspend-to-idle), it is described as "a generic, pure
> > software, light-weight, system sleep state" in the Document, and the
> > fact is only acpi is using it,
> 
> No, it independent of ACPI. It can be used on any platform with CPUIdle
> support.
> 
> > what's more, I don't think it satisfy us
> > well, because the freeze_enter() is executed before
> > disable_nonboot_cpus() and syscore_suspend(), while the later two are
> > necessary for us.
> >
> 
> Care to explain ? With suspend-to-idle, wakeup latency is much lesser as
> the CPUs are not hotplugged out. I don't think it makes huge different
> with power on ARM platforms. So its is much better than standby which
> does CPU hotplugging IMO.
> 

Sorry for response late, I was investigating the possibility of implementing suspend-to-idle on our platform.
Our user manual says the core1 should enter wfi first and the core0 is the last core which is responsible for some cleanup such as triggering the clock gating off for non-wakeup devices.
If we use suspend-to-idle (no disable none boot cpu in this routine), which core enters idle last cannot be guaranteed, I don't know if core1 can do the cleanup instead, this cannot be confirmed from any document, so have to do a test later, this needs some time.

> > So it seems another 'state' parameter for SYSTEM_SUSPEND can settle this
> > problem, but it is lack in the spec.
> >
> 
> If you still think you can't make use of suspend-to-idle with added
> advantage of reduced wakeup latency, please send email with all the
> details to errata at arm.com as suggested in the PSCI specification.

Will consider this after my test I mention above, thanks for the info.

> 
> > There are diverse kinds of ARM SOC, and divers kind of peripheral
> > devices in each SOC, so even for the SYSTEM_SUSPEND, there may be
> > different states too(deeper or shallower states of each device, more or
> > less of devices are put to idle), the more the PSCI spec supports, the
> > better.
> >
> 
> With runtime PM, you can work out on the peripheral device PM directly,
> so I can't imagine how the diversity there adds to SYSTEM_SUSPEND
> complexity.

Our SoC isn't designed for mobile device, so the peripheral PM is quite rough, except for the wakeup devices, all the other devices can only be power or clock gated off by one operation at one time, they cannot be treated separately, so the runtime PM doesn't fit well.

> 
> --
> Regards,
> Sudeep