From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] drivers: firmware: psci: add system suspend support
Date: Wed, 15 Jul 2015 10:34:08 +0800 [thread overview]
Message-ID: <20150715103408.07523347@xhacker> (raw)
In-Reply-To: <55A50C12.60901@arm.com>
Dear Sudeep,
On Tue, 14 Jul 2015 14:18:10 +0100
Sudeep Holla wrote:
> >>>>>> +
> >>>>>> +static void __init psci_init_system_suspend(void)
> >>>>>> +{
> >>>>>> + if (!IS_ENABLED(CONFIG_SUSPEND))
> >>>>>> + return;
> >>>>>> +
> >>>>>> + if (psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND)))
> >>>>>> + return;
> >>>>>
> >>>>> So this requires the firmware implements SYSTEM_SUSPEND which doesn't exist
> >>>>> until PSCI 1.0,
> >>>>
> >>>> Correct, if you need System to RAM in Linux on a platform with PSCI
> >>>> firmware, firmware *must implement* SYSTEM_SUSPEND.
> >>>>
> >>>>> and even in PSCI 1.0 SYSTEM_SUSPEND is optional,
> >>>>
> >>>> Optional here means, that you may chose to implement or not in the
> >>>> firmware. It doesn't mean we can implement S2R in Linux using other
> >>>> PSCI methods. SYSTEM_SUSPEND was added mainly to avoid since workarounds
> >>>> in the kernel.
> >>>>
> >>>>> we also want
> >>>>> suspend to ram feature on PSCI 0.2 or PSCI 1.0 w/o SYSTEM_SUSPEND,
> >>>>
> >>>> Why do you choose to have PSCIv1.0 w/o SYSTEM_SUSPEND when you need that
> >>>> feature in Linux. Is it just because we can manage with workarounds ?
> >>>> Sorry, that's not an option.
> >>>
> >>> The problem is the PSCI 1.0 SYSTEM_SUSPEND definition: we can't pass something
> >>> like stateid as in CPU_SUSPEND to firmware. The stateid is used to tell
> >>> firmware to go to different Sleep state, for example S2 or S3.
> >>>
> >>
> >> Can you elaborate on S2 here with an example ? You are using ACPI
> >> Sleep State definitions here which should not be mixed with PSCI.
> >
> > Yes, it's ACPI concept. Here "S2" can be the "S2" mentioned in PSCI 1.0 spec.
> >
> > PSCI 1.0 SPEC says:
> >
> > "While ACPI distinguishes between two system level suspend to RAM states,
> > S2 and S3, PSCI provides a single API. In practice, operating systems use
> > only one suspend to RAM state, so this is not seen as a limitation. Note
> > that this specification is using the state definitions of S2 and S3 provided
> > by ACPI, but does not limit use of this PSCI function to ACPI based systems.
> > Semantics such as those described for sleep states S2 and S3 are used in
> > non-ACPI based systems."
> >
>
> OK, though similar semantics may be used else where, we need to define
> the state similar to the way ACPI does it for x86 systems.
>
> > Here is an example:
> >
> > S3 is the state where All devices are suspended and power down, memory is
> > placed in self-refresh mode. Usually this is the suspend to ram state.
> >
>
> Agreed.
>
> > S2 is the state where devices except cpus are suspended and put in a
> > low-power state(not power off), if the deivce doesn't support lower power mode,
> > the device is left on. memory is placed in self-refresh mode. secondary CPUs
> > are powered off via. PSCI_CPU_OFF, boot cpu is put into WFI state and runs at
> > low freq.
> >
>
> Is this a standard state or custom tailored for some power optimization
> on particular system ? Anyway I am not sure if I quite understand the
This is customized state.
> exact definition of this state. When and how often do you use this
> use this state ?
Very often. When we want s2ram similar state but low-latency back transition,
we want to use this state.
>
> Have you looked at PM_SUSPEND_FREEZE state implemented in Linux ?
> For me this S2 you explained sounds similar to PM_SUSPEND_FREEZE state.
> In short, PM_SUSPEND_FREEZE = all the processes are frozen + all the
> devices are suspended + all the processors enter deepest idle state
> possible.
The S2 in my example is a bit different with freeze. It's looks more like
the S1 or standby in Documentation/power/states.txt. The biggest difference
with freeze is whether putting memory in self-refresh state or not.
>
> Though I don't understand why you need to power-off secondary cpus
> and stay in WFI on boot cpu as that would have increased latency
we want save more power, the increased latency is affordable.
> defeating the purpose of S2 state. Also why you are mixing DVFS here ?
> PSCI deals with just low power states and has nothing to do with DVFS.
It's not DVFS related, but to put the boot cpu in a low power state while
still keeping its power.
>
> Further IMO we can also achieve a low power state almost close to
> PM_SUSPEND_FREEZE having run-time PM for all the devices and cpuidle.
we want one more sleep state which saves more power than freeze.
Or let's change the question: how to implement "standby" or "s1" in
Documentation/power/states.txt with the help of PSCI? Seems the PSCI spec
expects "operating systems use only one suspend to RAM state", but this
is a limitation in the long run.
Thanks,
Jisheng
next prev parent reply other threads:[~2015-07-15 2:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 13:50 [PATCH 0/2] PSCI: system suspend support Sudeep Holla
2015-06-16 13:50 ` [PATCH 1/2] arm64: kernel: rename __cpu_suspend to keep it aligned with arm Sudeep Holla
2015-06-17 13:57 ` Lorenzo Pieralisi
2015-06-16 13:50 ` [PATCH 2/2] drivers: firmware: psci: add system suspend support Sudeep Holla
2015-06-17 15:08 ` Lorenzo Pieralisi
2015-06-17 15:41 ` Sudeep Holla
2015-06-18 14:41 ` [PATCH v2 0/3] PSCI: " Sudeep Holla
2015-06-18 14:41 ` [PATCH v2 1/3] arm64: kernel: rename __cpu_suspend to keep it aligned with arm Sudeep Holla
2015-06-18 14:55 ` Catalin Marinas
2015-06-18 15:08 ` Sudeep Holla
2015-06-19 13:50 ` Catalin Marinas
2015-06-18 14:41 ` [PATCH v2 2/3] drivers: firmware: psci: define more generic PSCI_FN_NATIVE macro Sudeep Holla
2015-09-14 13:17 ` Lorenzo Pieralisi
2015-09-14 13:21 ` Sudeep Holla
2015-06-18 14:41 ` [PATCH v2 3/3] drivers: firmware: psci: add system suspend support Sudeep Holla
2015-07-14 6:17 ` Jisheng Zhang
2015-07-14 9:14 ` Sudeep Holla
2015-07-14 9:50 ` Jisheng Zhang
2015-07-14 11:02 ` Sudeep Holla
2015-07-14 11:40 ` Jisheng Zhang
2015-07-14 13:18 ` Sudeep Holla
2015-07-15 2:34 ` Jisheng Zhang [this message]
2015-07-15 10:20 ` Sudeep Holla
2015-09-14 13:23 ` Lorenzo Pieralisi
2015-09-14 13:32 ` Sudeep Holla
2015-06-18 18:13 ` [PATCH v2 0/3] PSCI: " Ashwin Chaugule
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150715103408.07523347@xhacker \
--to=jszhang@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.