linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 22 Feb 2017 11:03:22 +0000	[thread overview]
Message-ID: <35840771-e16f-d6fe-3a89-1b3f51f4a8f3@arm.com> (raw)
In-Reply-To: <1975396.x0czmkNPOW@aspire.rjw.lan>



On 22/02/17 01:14, Rafael J. Wysocki wrote:
> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote:

[...]

>>
>> I take this back, you have everything you need in place, nothing needs
>> to be done. I just checked again. If I don't register PSCI suspend_ops,
>> I still get mem in /sys/power/state with s2idle in /sys/power/mem_sleep
>> which is exactly what we need. Again we don't support standby/shallow
>> state on ARM64/PSCI.
> 
> Except for one thing which may or may not be a concern here.
> 
> Suspend to idle should only go into states in which all of the available wakeup
> devices work.  If there are devices that cannot wake you up from a given state,
> this isn't "idle" any more, is it?
> 

True. In this Renasas platform, since the platform doesn't have PSCI
system suspend, we can only support s2idle and not s2ram. In this case
we don't ask platform to enter some system state whereas we suspend all
the devices(leaving wakeup capable devices active) and ask platform to
enter deepest idle state on all the CPUs. I still don't understand the
issue Geert is facing.

Geert, so far you have failed to explain what's different from the new
state you are adding and the existing s2idle.

> As for the device wakeup disable/enable interface, it is for controlling
> whether or not a given device should be allowed to generate wakeup signals at
> all.
> 
> The information on what states a given device can wake up the system from is
> platform-specific and generally would need to be taken into consideration at
> the platform level.
> 

Exactly, that's what I am trying to convince Geert ;)

-- 
Regards,
Sudeep

  reply	other threads:[~2017-02-22 11:03 UTC|newest]

Thread overview: 48+ 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 ` [PATCH/RFC 1/6] alarmtimer: Postpone wake-up source registration until really available Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 2/6] PM / Wakeup: Add wakeup_source_available() Geert Uytterhoeven
2017-02-20 20:33 ` [PATCH/RFC 3/6] drivers: firmware: psci: Implement shallow suspend mode Geert Uytterhoeven
2017-02-21 10:42   ` Sudeep Holla
2017-02-21 16:23     ` Geert Uytterhoeven
2017-02-21 16:51       ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 11:14     ` Sudeep Holla
2017-02-21 16:32       ` Geert Uytterhoeven
2017-02-21 17:20         ` Mark Rutland
2017-02-21 18:06           ` Geert Uytterhoeven
2017-02-21 18:18             ` Mark Rutland
2017-02-21 18:23               ` Geert Uytterhoeven
2017-02-21 17:22         ` Sudeep Holla
2017-02-22 13:47           ` Geert Uytterhoeven
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-21 10:50   ` Sudeep Holla
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 16:49       ` Sudeep Holla
2017-02-21 11:07   ` Pavel Machek
2017-02-21 16:36     ` Geert Uytterhoeven
2017-02-21 17:54     ` Mark Rutland
2017-02-21 17:48   ` Mark Rutland
2017-02-22 14:05     ` Geert Uytterhoeven
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 ` [PATCH/RFC 6/6] arm64: dts: r8a7796: " 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 16:21   ` Geert Uytterhoeven
2017-02-21 16:45     ` Sudeep Holla
2017-02-21 17:34       ` Geert Uytterhoeven
2017-02-21 17:51         ` Sudeep Holla
2017-02-21 18:27           ` Sudeep Holla
2017-02-21 18:45             ` Sudeep Holla
2017-02-22  1:14               ` Rafael J. Wysocki
2017-02-22 11:03                 ` Sudeep Holla [this message]
2017-02-22 13:38                   ` Geert Uytterhoeven
2017-02-22 14:32                     ` Sudeep Holla
2017-02-22 14:50                       ` Rafael J. Wysocki
2017-02-22 15:24                         ` Sudeep Holla
2017-02-23 15:26                       ` Geert Uytterhoeven
2017-02-23 15:34                         ` Geert Uytterhoeven
2017-02-23 15:58                           ` Sudeep Holla
2017-02-23 15:53                         ` Sudeep Holla
2017-02-22 13:14                 ` Geert Uytterhoeven
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=35840771-e16f-d6fe-3a89-1b3f51f4a8f3@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.
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).