linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/2] Documentation: arm: define DT bindings for system suspend
Date: Wed, 21 Jan 2015 21:35:07 +0800	[thread overview]
Message-ID: <20150121213507.695b871b@xhacker> (raw)
In-Reply-To: <20150121212139.1cdc3fd5@xhacker>

Dear Sudeep,

On Wed, 21 Jan 2015 05:21:39 -0800
Jisheng Zhang <jszhang@marvell.com> wrote:

> Dear Sudeep,
> 
> On Wed, 21 Jan 2015 03:35:54 -0800
> Sudeep Holla <sudeep.holla@arm.com> 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.
> > 
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/psci.txt     | 11 +++
> >  .../devicetree/bindings/arm/system-suspend.txt     | 93
> > ++++++++++++++++++++++ 2 files changed, 104 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/arm/system-suspend.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/psci.txt
> > b/Documentation/devicetree/bindings/arm/psci.txt index
> > 5aa40ede0e99..bd3977a2a333 100644 ---
> > a/Documentation/devicetree/bindings/arm/psci.txt +++
> > b/Documentation/devicetree/bindings/arm/psci.txt @@ -61,6 +61,14 @@ Device
> > tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
> > Definition: power_state parameter to pass to the PSCI suspend call.
> >  
> > +PSCI v0.2 and earlier versions don't have explicit operation for system
> > +suspend. However, one can implement system suspend using CPU_SUSPEND by
> > +ensuring every other core except the one executing the CPU_SUSPEND call
> > +has called into PSCI through a CPU_OFF call.
> 
> If users explicitly hot-unplug other cores when system load is low to save
> power, then we want to suspend at some point, how does the firmware know
> this case?

Sorry for confusion. I mean 

If users explicitly hot-unplug other cores when system load is low to save
power, then at some point cpuidle want to suspend the cluster, how does the
distinguish this case with suspend the system to ram.

> 
> In my private tree, I extend the PSCI spec to tell firmware we want to
> suspend the system.

I extend the PSCI suspend function to help firmware distinguish suspend system
to ram and other suspend cores/clusters.

> 
> Thanks,
> Jisheng
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2015-01-21 13:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 11:35 [PATCH RFC 0/2] ARM: DT: add bindings for system suspend Sudeep Holla
2015-01-21 11:35 ` [PATCH RFC 1/2] Documentation: arm: define DT " Sudeep Holla
2015-01-21 13:21   ` Jisheng Zhang
2015-01-21 13:35     ` Jisheng Zhang [this message]
2015-01-21 13:56       ` Lorenzo Pieralisi
2015-01-22  4:33         ` Jisheng Zhang
2015-01-22  6:29           ` Jisheng Zhang
2015-01-22 11:59             ` Lorenzo Pieralisi
2015-01-22 12:09               ` Jisheng Zhang
2015-02-04 16:10   ` Mark Rutland
2015-02-05 13:28     ` Sudeep Holla
2015-02-05 13:32       ` Mark Rutland
2015-02-05 13:49         ` Sudeep Holla
2015-01-21 11:35 ` [PATCH RFC 2/2] ARM64: psci: implement system suspend using PSCI v0.2 CPU SUSPEND Sudeep Holla
2015-01-22  6:18   ` Leo Yan
2015-01-22 12:08     ` Lorenzo Pieralisi
2015-01-22 14:34       ` Leo Yan
2015-01-23 10:58         ` Mark Rutland

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=20150121213507.695b871b@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).