All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	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>,
	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: Wed, 22 Feb 2017 15:24:01 +0000	[thread overview]
Message-ID: <ecc87d46-6a77-3c8f-d67e-974d20b8a603@arm.com> (raw)
In-Reply-To: <CAJZ5v0iheYM-qj8=bO3NZhoM5=8+TikYhm23EZV72HxNxUXDsg@mail.gmail.com>



On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.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>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Pavel Machek <pavel@ucw.cz>, Sudeep Holla <sudeep.holla@arm.com>,
	John Stultz <john.stultz@linaro.org>,
	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: Wed, 22 Feb 2017 15:24:01 +0000	[thread overview]
Message-ID: <ecc87d46-6a77-3c8f-d67e-974d20b8a603@arm.com> (raw)
In-Reply-To: <CAJZ5v0iheYM-qj8=bO3NZhoM5=8+TikYhm23EZV72HxNxUXDsg@mail.gmail.com>



On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID
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 15:24:01 +0000	[thread overview]
Message-ID: <ecc87d46-6a77-3c8f-d67e-974d20b8a603@arm.com> (raw)
In-Reply-To: <CAJZ5v0iheYM-qj8=bO3NZhoM5=8+TikYhm23EZV72HxNxUXDsg@mail.gmail.com>



On 22/02/17 14:50, Rafael J. Wysocki wrote:
> On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]

>>
>> OK, I thought I had told this before. What do you mean by PSCI system
>> suspend can't wakeup from the configured wakeup source. You just said
>> above that you can wake up from the switch.
>>
>> Just enabling the wakeup sources in Linux doesn't mean you can enter
>> system suspend anytime. You must enter only the state from which you can
>> resume. And in your case if you can't wakeup from WLAN or wakeup source
>> you have configured then simply don't enter system suspend.
> 
> Well, not quite.
> 
> The sysfs wakeup setting for devices only means whether or not to
> enable the generation of wakeup signals for them while suspending.  It
> allows to *prevent* devices from waking up the system, but it doesn't
> guarantee that they will actually wake up if enabled.
> 
> Now, the platform doesn't decide on the sleep state it will go to on
> the basis of what devices have been enabled to wake up the system.
> The states ("shallow", "deep") have to be defined upfront, including
> what devices can wake up from the "shallow" and what devices can wake
> up from the "deep" states (these lists need not be the same).  [As I
> said before, the assumption is that all of them will be able to wake
> up the system from suspend-to-idle.]
> 
> So, if user space triggers a transition to the "shallow" state, say,
> it will be possible to wake up the system from it by devices that (a)
> can wake it up from the "shallow" state as defined for the given
> platform and (b) have been enabled to wake up the system via sysfs.
> 
> Conversely, if you have a system power state such that only a subset
> of devices can wake up from it, it needs to be defined as either
> "shallow" or "deep" and the list of possible wakeup sources is part of
> that definition.

Completely agreed.

And yes the current assumption is that the set of wake-up source in DT
applies to the suspend-to-idle case and may/may not from the deeper
s2ram state.

Sorry if I conveyed something else in my emails. I was mostly referring
to the patch set and the way it's hacking up. I still fail to understand
what Geert is doing different in his "shallow" state that "s2idle" can't
achieve that state. So my comments were more aligned to that when I made
the above comment.

-- 
Regards,
Sudeep

  reply	other threads:[~2017-02-22 15:58 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
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 [this message]
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=ecc87d46-6a77-3c8f-d67e-974d20b8a603@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=rafael@kernel.org \
    --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.