From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932477AbdBVNOw (ORCPT ); Wed, 22 Feb 2017 08:14:52 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:33485 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932211AbdBVNOo (ORCPT ); Wed, 22 Feb 2017 08:14:44 -0500 MIME-Version: 1.0 In-Reply-To: <1975396.x0czmkNPOW@aspire.rjw.lan> 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: Geert Uytterhoeven Date: Wed, 22 Feb 2017 14:14:42 +0100 X-Google-Sender-Auth: RrQ2SIK0DdM4HILHVpkZx3pGDEc Message-ID: Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: "Rafael J. Wysocki" Cc: 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 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... > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds