From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] drivers: firmware: psci: add system suspend support
Date: Wed, 15 Jul 2015 11:20:27 +0100 [thread overview]
Message-ID: <55A633EB.2000609@arm.com> (raw)
In-Reply-To: <20150715103408.07523347@xhacker>
Hi Jisheng,
On 15/07/15 03:34, Jisheng Zhang wrote:
> Dear Sudeep,
>
> On Tue, 14 Jul 2015 14:18:10 +0100
> Sudeep Holla wrote:
[...]
>>
>> 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.
>
OK, but I do have concern as you mention that you leave certain device
on, what if that device initiate some DMA operation which might not be
possible when DDR is in self-refresh mode. IMO this is highly 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.
>
I don't understand this. You want secondaries hot-plugged out which is
quite expensive yet you mention this is low-latency. That could be
possible as you leave last CPU in WFI but again highly customized 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.
>
OK I am still struggling to map these(S1/S2) to ARM systems as they
designed and map well for x86 systems. Since the idle states on include
state where CPU power is lost, I wonder if the state you are explaining
provides any more power save compared to system freeze.
>>
>> 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.
>
Which clearly contradicts what you said above.
>> 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.
>
If there's nothing for CPU to do, some CPUFreq governors(e.g.
interactive) will ensure lowest OPP is chosen so you need not do
anything extra I believe.
>>
>> 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.
>
Do you have any power/latency number that indicates freeze is not that
power efficient ? Also I imagine you S2 state has higher latency as you
are doing CPU hot-plug.
> 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.
>
OK, this one I leave it for you to take up discussion in PSCI forum with
justification(power/latency numbers to prove an extra system state is
really worthy)
Regards,
Sudeep
next prev parent reply other threads:[~2015-07-15 10:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 13:50 [PATCH 0/2] PSCI: " 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
2015-07-15 10:20 ` Sudeep Holla [this message]
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=55A633EB.2000609@arm.com \
--to=sudeep.holla@arm.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.
Code repositories for project(s) associated with this inbox:
https://80x24.org/mirrors/git.git
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.