-----Original Message-----
From: Sudeep Holla [mailto:sudeep.holla at arm.com]
Sent: Thursday, May 12, 2016 6:09 PM
To: Hongbo Zhang <redacted>; linux-pm at vger.kernel.org
Cc: Sudeep Holla <redacted>; Mark Rutland
[off-list ref]; jszhang at marvell.com; Lorenzo Pieralisi
[off-list ref]; Frank Li [off-list ref]; Marc Zyngier
[off-list ref]; Jan Kiszka [off-list ref]; Daniel
Lezcano [off-list ref]; Peng Fan [off-list ref];
Hans de Goede [off-list ref]; Chen-Yu Tsai [off-list ref];
Tom Warren [off-list ref]; Vincent Guittot
[off-list ref]; 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:

quoted

Hi Sudeep,

[...]

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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