lkml.org 
[lkml]   [2017]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH fixes v3] pinctrl: Really force states during suspend/resume
From
Date
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

\
 
 \ /
  Last update: 2017-06-29 21:38    [W:0.052 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site