On 05/02/15 13:32, Mark Rutland wrote:
On Thu, Feb 05, 2015 at 01:28:32PM +0000, Sudeep Holla wrote:
On 04/02/15 16:10, Mark Rutland wrote:
Hi Sudeep,
On Wed, Jan 21, 2015 at 11:35:54AM +0000, Sudeep Holla wrote:
ARM based platforms implement unique ways to enter system suspend
(i.e. Suspend to RAM). The mechanism and the parameters defining the
system state vary on a per-platform basis forcing the OS to handle it
in very platform specific way.
Since ARM 32-bit systems had machine specific code, no attempts to
standardize are being made as it provides easy way to implement suspend
operations in a platform specific manner. However, this approach not
only makes maintainance more difficult as the number of platforms
supported increases but also not feasible for ARM64.
This DT binding aims at standardizing the system suspend for ARM
platforms. ARM64 platforms mandates entry-method property in DT for
this system suspend node.
On system implementing PSCI as an enable-method to enter system suspend,
the PSCI CPU suspend method is used on versions upto v0.2 and requires
the power_state parameter to be passed to the PSCI CPU suspend function.
This parameter is platform specific, therefore must be provided by
firmware to the OS in order to enable proper call sequence.
This ARM system suspend DT bindings rely on a property
(i.e. arm,psci-suspend-param) in the PSCI DT bindings that describes
how the PSCI CPU suspend power_state parameter should be defined in DT.
A short while ago (after this posting), the PSCI 1.0 spec [1] was
released, featuring the new (optional) SYSTEM_SUSPEND mechanism intended
for suspend to RAM. This has a standard ID, and its presence can be
detected via the new standard PSCI_FEATURES call.
The fundamental mechanism is identical. We would hot unplug all but one
CPU, and from this remaining CPU we would make a SYSTEM_SUSPEND call.
The major differences are that SYSTEM_SUSPEND can be detected via
PSCI_FEATURES, and doesn't need a state parameter.
Given that the only mandatory addition in PSCI 1.0 over PSCI 0.2 is the
PSCI_FEATURES call (used to detect the presence of SYSTEM_SUSPEND), I do
not believe that implementing this should be a signficant overhead
compared to implementing the CPU_SUSPEND based approach with PSCI 0.2.
So I'd very much prefer that we require a minimal PSCI 1.0 with
SYSTEM_SUSPEND rather than extending CPU_SUSPEND in this manner. Is
anyone attempting to implement suspend to RAM with PSCI 0.1?
I too prefer have PSCI v1.0 for SYSTEM SUSPEND support, which eliminates
the need for this binding. But the question is: are silicon vendors
ready to upgrade their firmware to PSCI v1.0 for system system feature
especially since it's one of the fundamental feature needed in Android
systems.
Sure. That's the question I'd like to know the answer to.
Right, I too hope to get response here.
If they're bringing up PSCIv0.2 now, the delta to PSCIv0.1 is not large.
That's true.
If they already have an implementation baked, then that's a different
scenario.
Regardless, what constitutes a wakeup device is a fundamental question
IIUC individual devices can expose if they are wake-up capable. E.g.
RTC can be wakeup capable and if it's enabled(sysfs entry exists, I did
use it to test on Juno), it's interrupt is kept unmasked in suspend path
while other devices keep their interrupts masked(can be both at GIC and
source).
to answer, along with what in the system (e.g. peripherals) the kernel
must save/restore the state of.
Ideally individual drivers need to take care of saving and restoring
their state. However there will be always exceptions :)
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
