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.

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.

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.

-- 
Regards,
Sudeep