All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Lina Iyer <lina.iyer@linaro.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Rob Herring <robh+dt@kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 18:27:59 +0000	[thread overview]
Message-ID: <94167d3a-e005-3af0-d290-a1086684d570@arm.com> (raw)
In-Reply-To: <81df65a9-d2f1-26df-a977-5265feba25a3@arm.com>



On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Len Brown <len.brown@intel.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Pavel Machek <pavel@ucw.cz>, Sudeep Holla <sudeep.holla@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Lina Iyer <lina.iyer@linaro.org>
Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 18:27:59 +0000	[thread overview]
Message-ID: <94167d3a-e005-3af0-d290-a1086684d570@arm.com> (raw)
In-Reply-To: <81df65a9-d2f1-26df-a977-5265feba25a3@arm.com>



On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power
Date: Tue, 21 Feb 2017 18:27:59 +0000	[thread overview]
Message-ID: <94167d3a-e005-3af0-d290-a1086684d570@arm.com> (raw)
In-Reply-To: <81df65a9-d2f1-26df-a977-5265feba25a3@arm.com>



On 21/02/17 17:51, Sudeep Holla wrote:
> 
> 
> On 21/02/17 17:34, Geert Uytterhoeven wrote:

[...]

>>
>> The SoC can wake-up. It's just not guaranteed that it can wake-up using
>> the wakeup-source configured from Linux. Which wakeup-sources are available
>> depends on the actual PSCI implementation.  It's not specified by the PSCI
>> specification.
>>
>>> Just botching whatever shallow state you can enter on a particular SoC
>>> into standard "mem" state sounds *horrible* to me.
>>
>> That's more or less what /sys/power/mem_sleep does, though.
>>
> 
> OK, I will go through that in detail.
> 

OK, I went through the patch and the main intention is was added.
So I will begin by summarizing my understanding:

A new suspend interface(/sys/power/mem_sleep) is added to allow the
"mem" string in /sys/power/state to represent multiple things that can
be selected.

Before:
A. echo freeze > /sys/power/state ---> Enters s2idle
B. echo mem > /sys/power/state ---> Enters s2r(a.k.a now deep mem sleep)

After:
1. echo freeze > /sys/power/state ---> Enters s2idle still same
2. echo s2idle > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2idle
3. echo deep > /sys/power/mem_sleep
   echo mem > /sys/power/state ---> Also enter s2r(same as [B] above)

Please note I have carefully dropped standby/shallow as we will not
support that state on ARM64 platforms(refer previous discussions for the
same)

Now IIUC, you need 2 above. So, since this new interface allow mem to
mean "s2idle", we need to fix the core to register default suspend_ops
to achieve what you need. And since I now better understand you problem,
you get extra NACK for this series ;)

-- 
Regards,
Sudeep

  reply	other threads:[~2017-02-21 18:28 UTC|newest]

Thread overview: 145+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 20:33 [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven
2017-02-20 20:33 ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 1/6] alarmtimer: Postpone wake-up source registration until really available Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 2/6] PM / Wakeup: Add wakeup_source_available() Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:42   ` Sudeep Holla
2017-02-21 10:42     ` Sudeep Holla
2017-02-21 16:23     ` Geert Uytterhoeven
2017-02-21 16:23       ` Geert Uytterhoeven
2017-02-21 16:23       ` Geert Uytterhoeven
2017-02-21 16:51       ` Sudeep Holla
2017-02-21 16:51         ` Sudeep Holla
2017-02-21 16:51         ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 11:14     ` Sudeep Holla
2017-02-21 11:14       ` Sudeep Holla
2017-02-21 11:14       ` Sudeep Holla
2017-02-21 16:32       ` Geert Uytterhoeven
2017-02-21 16:32         ` Geert Uytterhoeven
2017-02-21 16:32         ` Geert Uytterhoeven
2017-02-21 17:20         ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 17:20           ` Mark Rutland
2017-02-21 18:06           ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:06             ` Geert Uytterhoeven
2017-02-21 18:18             ` Mark Rutland
2017-02-21 18:18               ` Mark Rutland
2017-02-21 18:18               ` Mark Rutland
2017-02-21 18:23               ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 18:23                 ` Geert Uytterhoeven
2017-02-21 17:22         ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-21 17:22           ` Sudeep Holla
2017-02-22 13:47           ` Geert Uytterhoeven
2017-02-22 13:47             ` Geert Uytterhoeven
2017-02-22 13:47             ` Geert Uytterhoeven
2017-02-22 14:35             ` Sudeep Holla
2017-02-22 14:35               ` Sudeep Holla
2017-02-22 14:35               ` Sudeep Holla
2017-02-20 20:33 ` [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:50   ` Sudeep Holla
2017-02-21 10:50     ` Sudeep Holla
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:49       ` Sudeep Holla
2017-02-21 16:49         ` Sudeep Holla
2017-02-21 16:49         ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 11:07     ` Pavel Machek
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 16:36       ` Geert Uytterhoeven
2017-02-21 17:54     ` Mark Rutland
2017-02-21 17:54       ` Mark Rutland
2017-02-21 17:48   ` Mark Rutland
2017-02-21 17:48     ` Mark Rutland
2017-02-22 14:05     ` Geert Uytterhoeven
2017-02-22 14:05       ` Geert Uytterhoeven
2017-02-22 14:05       ` Geert Uytterhoeven
2017-02-22 14:57       ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-22 14:57         ` Rafael J. Wysocki
2017-02-20 20:33 ` [PATCH/RFC 5/6] arm64: dts: r8a7795: Fix non-PMIC wake-up sources Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 6/6] arm64: dts: r8a7796: " Geert Uytterhoeven
2017-02-20 20:33   ` Geert Uytterhoeven
2017-02-21 10:38 ` [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Sudeep Holla
2017-02-21 10:38   ` Sudeep Holla
2017-02-21 16:21   ` Geert Uytterhoeven
2017-02-21 16:21     ` Geert Uytterhoeven
2017-02-21 16:21     ` Geert Uytterhoeven
2017-02-21 16:45     ` Sudeep Holla
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 16:45       ` Sudeep Holla
2017-02-21 17:34       ` Geert Uytterhoeven
2017-02-21 17:34         ` Geert Uytterhoeven
2017-02-21 17:34         ` Geert Uytterhoeven
2017-02-21 17:51         ` Sudeep Holla
2017-02-21 17:51           ` Sudeep Holla
2017-02-21 17:51           ` Sudeep Holla
2017-02-21 18:27           ` Sudeep Holla [this message]
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:27             ` Sudeep Holla
2017-02-21 18:45             ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-21 18:45               ` Sudeep Holla
2017-02-22  1:14               ` Rafael J. Wysocki
2017-02-22  1:14                 ` Rafael J. Wysocki
2017-02-22  1:14                 ` Rafael J. Wysocki
2017-02-22 11:03                 ` Sudeep Holla
2017-02-22 11:03                   ` Sudeep Holla
2017-02-22 11:03                   ` Sudeep Holla
2017-02-22 13:38                   ` Geert Uytterhoeven
2017-02-22 13:38                     ` Geert Uytterhoeven
2017-02-22 13:38                     ` Geert Uytterhoeven
2017-02-22 14:32                     ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:32                       ` Sudeep Holla
2017-02-22 14:50                       ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 14:50                         ` Rafael J. Wysocki
2017-02-22 15:24                         ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-22 15:24                           ` Sudeep Holla
2017-02-23 15:26                       ` Geert Uytterhoeven
2017-02-23 15:26                         ` Geert Uytterhoeven
2017-02-23 15:26                         ` Geert Uytterhoeven
2017-02-23 15:34                         ` Geert Uytterhoeven
2017-02-23 15:34                           ` Geert Uytterhoeven
2017-02-23 15:34                           ` Geert Uytterhoeven
2017-02-23 15:58                           ` Sudeep Holla
2017-02-23 15:58                             ` Sudeep Holla
2017-02-23 15:58                             ` Sudeep Holla
2017-02-23 15:53                         ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-23 15:53                           ` Sudeep Holla
2017-02-22 13:14                 ` Geert Uytterhoeven
2017-02-22 13:14                   ` Geert Uytterhoeven
2017-02-22 13:14                   ` Geert Uytterhoeven
2017-02-22 14:31                   ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki
2017-02-22 14:31                     ` Rafael J. Wysocki

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=94167d3a-e005-3af0-d290-a1086684d570@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=john.stultz@linaro.org \
    --cc=len.brown@intel.com \
    --cc=lina.iyer@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    /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.