From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932832AbdBVObx (ORCPT ); Wed, 22 Feb 2017 09:31:53 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33239 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932731AbdBVObf (ORCPT ); Wed, 22 Feb 2017 09:31:35 -0500 MIME-Version: 1.0 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> From: "Rafael J. Wysocki" Date: Wed, 22 Feb 2017 15:31:31 +0100 X-Google-Sender-Auth: kbpepHHkQpRKp_RduflHKlAlgqM Message-ID: Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Sudeep Holla , 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki wrote: >> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: >>> On 21/02/17 18:27, Sudeep Holla wrote: >>> > On 21/02/17 17:51, Sudeep Holla wrote: >>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote: >>> >>> 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. >>> >>> 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? > > Indeed. And I have no problem with handling wake-up sources from Linux, > as Linux knows how to handle them. > >> 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. > > OK. So it's not guaranteed that it will actually work... No, it is not. Enabling generation of wakeup signals at a device doesn't guarantee that the interrupt (or GPIO etc) controller will be functional when those signals reach it, for example. There actually is no way to guarantee that in general. In the ACPI land, for example, devices may be able to wake up the system from S3, but not from S4 or S5, and you can't say "I want that device to wake up the system from S4", because that may be physically impossible to achieve. >> 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. > > So that's PSCI on arm64? > But the PSCI specification doesn't handle that. In theory, that should be some code that knows how the platform is configured and can set up things to work as expected. That's why we have all of the platform hooks, syscore operations etc (of course, all of that is not needed for suspend to idle, because it is entered via the idle path and wakeup signals for wakeup devices should be handled then). Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power Date: Wed, 22 Feb 2017 15:31:31 +0100 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Sudeep Holla , Geert Uytterhoeven , Lorenzo Pieralisi , Mark Rutland , Lina Iyer , John Stultz , Thomas Gleixner , Len Brown , Pavel Machek , Rob Herring , Magnus Damm , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Linux-Renesas , Linux PM list , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki wrote: >> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: >>> On 21/02/17 18:27, Sudeep Holla wrote: >>> > On 21/02/17 17:51, Sudeep Holla wrote: >>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote: >>> >>> 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. >>> >>> 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? > > Indeed. And I have no problem with handling wake-up sources from Linux, > as Linux knows how to handle them. > >> 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. > > OK. So it's not guaranteed that it will actually work... No, it is not. Enabling generation of wakeup signals at a device doesn't guarantee that the interrupt (or GPIO etc) controller will be functional when those signals reach it, for example. There actually is no way to guarantee that in general. In the ACPI land, for example, devices may be able to wake up the system from S3, but not from S4 or S5, and you can't say "I want that device to wake up the system from S4", because that may be physically impossible to achieve. >> 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. > > So that's PSCI on arm64? > But the PSCI specification doesn't handle that. In theory, that should be some code that knows how the platform is configured and can set up things to work as expected. That's why we have all of the platform hooks, syscore operations etc (of course, all of that is not needed for suspend to idle, because it is entered via the idle path and wakeup signals for wakeup devices should be handled then). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: MIME-Version: 1.0 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> From: "Rafael J. Wysocki" Date: Wed, 22 Feb 2017 15:31:31 +0100 Message-ID: Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: Geert Uytterhoeven Cc: "Rafael J. Wysocki" , Sudeep Holla , 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki wrote: >> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: >>> On 21/02/17 18:27, Sudeep Holla wrote: >>> > On 21/02/17 17:51, Sudeep Holla wrote: >>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote: >>> >>> 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. >>> >>> 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? > > Indeed. And I have no problem with handling wake-up sources from Linux, > as Linux knows how to handle them. > >> 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. > > OK. So it's not guaranteed that it will actually work... No, it is not. Enabling generation of wakeup signals at a device doesn't guarantee that the interrupt (or GPIO etc) controller will be functional when those signals reach it, for example. There actually is no way to guarantee that in general. In the ACPI land, for example, devices may be able to wake up the system from S3, but not from S4 or S5, and you can't say "I want that device to wake up the system from S4", because that may be physically impossible to achieve. >> 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. > > So that's PSCI on arm64? > But the PSCI specification doesn't handle that. In theory, that should be some code that knows how the platform is configured and can set up things to work as expected. That's why we have all of the platform hooks, syscore operations etc (of course, all of that is not needed for suspend to idle, because it is entered via the idle path and wakeup signals for wakeup devices should be handled then). Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 From: rafael@kernel.org (Rafael J. Wysocki) Date: Wed, 22 Feb 2017 15:31:31 +0100 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> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki wrote: >> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: >>> On 21/02/17 18:27, Sudeep Holla wrote: >>> > On 21/02/17 17:51, Sudeep Holla wrote: >>> >> On 21/02/17 17:34, Geert Uytterhoeven wrote: >>> >>> 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. >>> >>> 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? > > Indeed. And I have no problem with handling wake-up sources from Linux, > as Linux knows how to handle them. > >> 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. > > OK. So it's not guaranteed that it will actually work... No, it is not. Enabling generation of wakeup signals at a device doesn't guarantee that the interrupt (or GPIO etc) controller will be functional when those signals reach it, for example. There actually is no way to guarantee that in general. In the ACPI land, for example, devices may be able to wake up the system from S3, but not from S4 or S5, and you can't say "I want that device to wake up the system from S4", because that may be physically impossible to achieve. >> 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. > > So that's PSCI on arm64? > But the PSCI specification doesn't handle that. In theory, that should be some code that knows how the platform is configured and can set up things to work as expected. That's why we have all of the platform hooks, syscore operations etc (of course, all of that is not needed for suspend to idle, because it is entered via the idle path and wakeup signals for wakeup devices should be handled then). Thanks, Rafael