On Tuesday, November 7, 2017 5:00:06 PM CET Tony Lindgren wrote:

* Florian Fainelli [off-list ref] [171104 17:21]:

quoted

On 11/04/2017 05:25 AM, Rafael J. Wysocki wrote:

quoted

On Friday, November 3, 2017 6:33:53 PM CET Tony Lindgren wrote:

quoted

* Florian Fainelli [off-list ref] [171103 17:04]:

quoted

On 11/03/2017 09:11 AM, Tony Lindgren wrote:
The pinctrl provider is losing its state, hence these two patches.

OK

quoted

quoted

Anyways, the context lost flag should be managed in the PM core for
the device, so adding linux-pm and Rafael to Cc.

I don't think it's that simple but sure, why not.

Just having bool context_lost in struct dev_pm_info would probably
be enough to allow drivers to deal with it. This flag could then
be set for a device by power domain related code that knows if
context got lost.

Something like: if the driver sees "context_lost" set, it should restore
the context to the device from memory?

That is what is being proposed here, except that the actual mechanism
where this matters needs to be in the core pinctrl code, otherwise the
state (context) is not restored due to a check that attempts not to
(re)apply a previous state.

quoted

But the it would also need to save the context beforehand, so why not to
restore it unconditionally on resume?

That's what my original attempts did here:

https://patchwork.kernel.org/patch/9598969/

but Linus rightfully requested this to be done differently, hence this
attempt now to solve it in a slightly more flexible way based on DT
properties.

For runtime PM, restoring the state constantly is unnecessary and not
good for battery life. The logic can be just:

1. Device driver runtime PM suspend saves the state when needed

2. Device driver runtime PM resume checks if context_lost was set by
   the bus or power domain code

3. If context was lost, device driver restores the state, or in some
   cases may need re-run the driver register init related parts
   to bring the driver back up, then clears the context_lost flag

How about something like the following patch? So far only compile
tested with CONFIG_PM enabled. If that looks like the way to go,
I'll test it properly and add some comments for the functions and
post a proper patch :)

Honestly, I'm not sure.

I'd rather have a context_lost flag to start with and see how/if
drivers will use that before adding any common infra for handling
this.

Thanks,
Rafael