From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932744AbdBVP6r (ORCPT ); Wed, 22 Feb 2017 10:58:47 -0500 Received: from foss.arm.com ([217.140.101.70]:46162 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754190AbdBVP6f (ORCPT ); Wed, 22 Feb 2017 10:58:35 -0500 Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: "Rafael J. Wysocki" References: <1487622809-25127-1-git-send-email-geert+renesas@glider.be> <94167d3a-e005-3af0-d290-a1086684d570@arm.com> <3c8b3f2d-8604-f999-4208-a82f171b64f2@arm.com> <1975396.x0czmkNPOW@aspire.rjw.lan> <35840771-e16f-d6fe-3a89-1b3f51f4a8f3@arm.com> Cc: Sudeep Holla , Geert Uytterhoeven , "Rafael J. Wysocki" , Geert Uytterhoeven , Lorenzo Pieralisi , Mark Rutland , Lina Iyer , John Stultz , Thomas Gleixner , Len Brown , Pavel Machek , Rob Herring , Magnus Damm , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux-Renesas , Linux PM list , "linux-kernel@vger.kernel.org" From: Sudeep Holla Organization: ARM Message-ID: Date: Wed, 22 Feb 2017 15:24:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla 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 Message-ID: References: <1487622809-25127-1-git-send-email-geert+renesas@glider.be> <94167d3a-e005-3af0-d290-a1086684d570@arm.com> <3c8b3f2d-8604-f999-4208-a82f171b64f2@arm.com> <1975396.x0czmkNPOW@aspire.rjw.lan> <35840771-e16f-d6fe-3a89-1b3f51f4a8f3@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: "Rafael J. Wysocki" Cc: Mark Rutland , Len Brown , Lorenzo Pieralisi , Geert Uytterhoeven , "devicetree@vger.kernel.org" , Magnus Damm , Linux PM list , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Linux-Renesas , Rob Herring , Geert Uytterhoeven , "linux-arm-kernel@lists.infradead.org" , Pavel Machek , Sudeep Holla , John Stultz , Thomas Gleixner , Lina Iyer List-Id: devicetree@vger.kernel.org On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: "Rafael J. Wysocki" References: <1487622809-25127-1-git-send-email-geert+renesas@glider.be> <94167d3a-e005-3af0-d290-a1086684d570@arm.com> <3c8b3f2d-8604-f999-4208-a82f171b64f2@arm.com> <1975396.x0czmkNPOW@aspire.rjw.lan> <35840771-e16f-d6fe-3a89-1b3f51f4a8f3@arm.com> Cc: Sudeep Holla , Geert Uytterhoeven , "Rafael J. Wysocki" , Geert Uytterhoeven , Lorenzo Pieralisi , Mark Rutland , Lina Iyer , John Stultz , Thomas Gleixner , Len Brown , Pavel Machek , Rob Herring , Magnus Damm , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux-Renesas , Linux PM list , "linux-kernel@vger.kernel.org" From: Sudeep Holla Message-ID: Date: Wed, 22 Feb 2017 15:24:01 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: devicetree-owner@vger.kernel.org List-ID: On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: sudeep.holla@arm.com (Sudeep Holla) Date: Wed, 22 Feb 2017 15:24:01 +0000 Subject: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power In-Reply-To: References: <1487622809-25127-1-git-send-email-geert+renesas@glider.be> <94167d3a-e005-3af0-d290-a1086684d570@arm.com> <3c8b3f2d-8604-f999-4208-a82f171b64f2@arm.com> <1975396.x0czmkNPOW@aspire.rjw.lan> <35840771-e16f-d6fe-3a89-1b3f51f4a8f3@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 22/02/17 14:50, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla 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