From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753856AbdBUQpd (ORCPT ); Tue, 21 Feb 2017 11:45:33 -0500 Received: from foss.arm.com ([217.140.101.70]:34638 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbdBUQpY (ORCPT ); Tue, 21 Feb 2017 11:45:24 -0500 Subject: Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power To: Geert Uytterhoeven References: <1487622809-25127-1-git-send-email-geert+renesas@glider.be> <69ab75a1-2e04-19e2-d1ad-12ca1cfc7625@arm.com> Cc: Sudeep Holla , Geert Uytterhoeven , Lorenzo Pieralisi , Mark Rutland , Lina Iyer , John Stultz , Thomas Gleixner , "Rafael J . Wysocki" , 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: <445b2f49-5d15-30af-a431-1c4edcd049a4@arm.com> Date: Tue, 21 Feb 2017 16:45:13 +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 Hi Geert, On 21/02/17 16:21, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Tue, Feb 21, 2017 at 11:38 AM, Sudeep Holla wrote: >> On 20/02/17 20:33, Geert Uytterhoeven wrote: >>> This patch series adds support for using non-PMIC wake-up sources on the >>> Renesas R-Car Gen3 (H3 or M3-W) Salvator-X development boards. >>> >>> Nothing in the PSCI specification requires the SoC to remain powered and >>> to support wake-up sources when suspended using SYSTEM_SUSPEND. >>> If the firmware implements the PSCI SYSTEM_SUSPEND operation by cutting >>> power to the SoC, the only possibly wake-up sources are thus the ones >>> connected to the PMIC. >> >> OK, but I don't see any issue with that. That's exactly how it works on > > How do you use other wake-up sources, like wake on LAN, UART or GPIO? > >>From wakeup source configuration/management perspective, s2ram and s2idle are exactly same. >> ARM Juno platform. The SoC is powered down. > > Good to hear this is not limited to Renesas platforms, so there's a common > problem to solve. > No, there's no problem to solve. Firmware should enter deepest sleep state in the system with SYSTEM_SUSPEND from which it can wakeup of course. >>> To allow other wake-up sources, this patch series documents and adds >>> support for an "arm,psci-system-suspend-is-power-down" DT property, so >> >> NACK, you don't need any such properties. > > If this is true for all PSCI platforms, there's indeed no need for such a > property, and drivers/firmware/psci.c should default to this case. > Cool. >>> Linux uses a different suspend method when other wake-up sources (e.g. >>> wake on LAN, UART or GPIO) are enabled. Hence the user no longer has to >>> manually restrict "mem" suspend to "s2idle" or "shallow" states using: >> >> Have you explored suspend-to-idle instead ? It looks like thats exactly >> what you are doing in this patch set. You also get low latency for free >> as it just enters the deepest idle state on all CPUs instead of >> hotplugging out all the secondaries. > > Yes, cfr. "s2idle" above. > The user can specify to use "s2idle" manually: > > $ echo s2idle > /sys/power/mem_sleep # or "shallow" > This looks like custom file for me. IIUC, the standard sysfs file for the system PM state is: /sys/power/state 1. s2ram: $ echo mem > /sys/power/state 2. s2idle $ echo freeze > /sys/power/state > However, how to handle this automatically, e.g. by a distro? As above > On most other platforms, userspace can just do e.g. > > ethtool -s eth0 wol g > That should work. > to enable wake-on-LAN, and suspend to the deepest supported state using: > > echo mem > /sys/power/state > This will work only if PSCI SYSTEM_SUPEND is implemented. If the SoC can't wakeup if it's powered down, then it should not use that state to implement SYSTEM_SUSPEND in PSCI firmware or just return the SYSTEM_SUSPEND feature is not implemented in which case "freeze" is the next available state to enter. Just botching whatever shallow state you can enter on a particular SoC into standard "mem" state sounds *horrible* to me. > On systems where PSCI SYSTEM_SUSPEND powers down the SoC, userspace must > make sure to configure to use "s2idle" (or "shallow) instead, else the > configured wake-up sources won't work. That's perfect. I was worried that user-space is not doing that. So to summarize, PSCI firmware either: 1. enters a sane and resumable state in SYSTEM_SUSPEND api or 2. just don't implement SYSTEM_SYSTEM. Use the cpuidle+s2idle framework in Linux to enter the deepest idle state. You literally need no extra work to enter this "freeze" state if the CPU_SUSPEND in PSCI can enter the deepest idle state you want to enter in this "s2idle" you are referring so far. Just start with: $ cat /sys/power/state and you should see "freeze" there, if not that's the first thing to check provided the platform has cpuidle working. Hope this helps. -- Regards, Sudeep