All the mail mirrored from lore.kernel.org
 help / color / mirror / code / Atom feed
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

  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.