Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753179AbdF2TiV (ORCPT ); Thu, 29 Jun 2017 15:38:21 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:33595 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751591AbdF2TiP (ORCPT ); Thu, 29 Jun 2017 15:38:15 -0400 Subject: Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume To: Linus Walleij Cc: Andy Shevchenko , "linux-kernel@vger.kernel.org" , Stephen Warren , Al Cooper , "open list:PIN CONTROL SUBSYSTEM" , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" References: <20170301183257.6554-1-f.fainelli@gmail.com> <304fb86d-0862-992b-4563-61151b37d060@gmail.com> <18ca4418-8b62-a1c9-1282-0c468f2aefb2@gmail.com> <5e61618b-cfb0-ddff-3d87-bf512521e669@gmail.com> From: Florian Fainelli Message-ID: <37d75c89-883f-1c58-23e8-7e0213935986@gmail.com> Date: Thu, 29 Jun 2017 12:38:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3014 Lines: 82 On 06/29/2017 02:17 AM, Linus Walleij wrote: > Sorry for slowness... > > On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli wrote: >> On 03/16/2017 07:08 AM, Linus Walleij wrote: > >>> I guess then it is better to assume we will loose the state, or >>> push for more granular handling of S2/3 etc states in the >>> PM core (I guess these states comes from ACPI or similar). >> >> I expected to see pm_message_t reflect which state we were entering into >> (PM_SUSPEND_STANDBY vs. PM_SUSPEND_MEM), but that is not the case. > > Can we fix it? Yes, I proposed this and got no feedback so far: https://www.spinics.net/lists/arm-kernel/msg590135.html > >>> Alternatively develop the PM core. Is it really impossible for >>> PM hooks to know which state it went into/came from? >> >> I don't think I liked Rafael's suggestion of putting that kind of detail >> into the platform_suspend_ops routine as he seems to suggest here: >> >> https://www.spinics.net/lists/arm-kernel/msg587311.html > > He is suggesting: > >> The cleanest way would be to run that code from one of the platform >> suspend hooks that receive information on what sleep state is to be >> entered. > > But what I suggest is more the inverse: that it receive information > on what state it is coming from, rather than which state it is > going to. The same information is available and it won't change from one suspend cycle to resume, since in between these calls you are supposed to be... suspended. > > But I guess it would be logical that suspend() get to know what state > it is going to and resume() get to know which state it is coming from.> > So Rafael seem to be aligned with that idea. > >> and here is my response: >> >> https://www.spinics.net/lists/arm-kernel/msg589844.html > > So if it is not desireable to have every driver know which exact > state it came from like S3 this or S2 that and on this laptop > we have S2' which is slightly different and such mess (that you > predict IIUC) what we really need to know is pretty simple: > did the hardware loose its state or not? That information is inherently platform specific though, so on platforms where pinctrl-single is used, you won't necessarily know whether the state should be restored (conversely saved) so maybe that means we should have the possibility for a platform to define a wrapper around pinctrl-single whose purpose is to implement platform specific suspend/r/resume functions and just that really? Is there such a driver already that uses pinctrl-single more as a "library" than anything else? > > That is the information we want the PM core to provide to > the resume() callback, somehow. A simple bool is fine. > > Any platform specifics or simplifications pertaining to certain > states and whether S5 or S7 looses the context should not > be the concern of a driver, what it wants to know is simply > whether its device has been powered off and lost its hardware > context. > > Yours, > Linus Walleij > -- Florian