From: Florian Fainelli <f.fainelli@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stephen Warren <swarren@nvidia.com>,
Al Cooper <alcooperx@gmail.com>,
"open list:PIN CONTROL SUBSYSTEM" <linux-gpio@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume
Date: Thu, 29 Jun 2017 12:38:11 -0700 [thread overview]
Message-ID: <37d75c89-883f-1c58-23e8-7e0213935986@gmail.com> (raw)
In-Reply-To: <CACRpkdbGza+vYTSqBRPbUGGnUsuNQS-6oKkweSch5Pwpku=CEg@mail.gmail.com>
On 06/29/2017 02:17 AM, Linus Walleij wrote:
> Sorry for slowness...
>
> On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli <f.fainelli@gmail.com> 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
next prev parent reply other threads:[~2017-06-29 19:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 18:32 [PATCH fixes v3] pinctrl: Really force states during suspend/resume Florian Fainelli
2017-03-02 8:54 ` Andy Shevchenko
2017-03-02 22:19 ` Florian Fainelli
2017-03-14 10:16 ` Linus Walleij
2017-03-15 2:18 ` Florian Fainelli
2017-03-16 14:08 ` Linus Walleij
2017-06-21 21:23 ` Florian Fainelli
2017-06-29 9:17 ` Linus Walleij
2017-06-29 19:38 ` Florian Fainelli [this message]
2017-06-29 22:25 ` Linus Walleij
2018-02-19 17:25 ` Marc Zyngier
2018-02-19 18:03 ` Florian Fainelli
2018-02-19 18:57 ` Heiko Stuebner
2018-02-19 19:23 ` Marc Zyngier
2018-02-22 15:30 ` Linus Walleij
2018-02-22 18:11 ` Marc Zyngier
2018-02-19 19:11 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37d75c89-883f-1c58-23e8-7e0213935986@gmail.com \
--to=f.fainelli@gmail.com \
--cc=alcooperx@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=swarren@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).