* Charles Keepax [off-list ref] [171104 08:38]:

On Fri, Nov 03, 2017 at 10:33:53AM -0700, 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.

Anybody got better ideas?

Should the provider driver not know its state will be lost since
will have had its PM ops called, and it should be aware of the
state it was in. So doesn't it just need to restore that state on
resume? Feels a bit like we are over complicating this here.
Apologies if I am missing some here.

Well any driver can lose context depending on the hardare, this
could be both the pinctrl provider and the pinctrl consumer drivers :)

If your pinctrl provider driver knows when it lost context and
knows when to restore it, then no generic code is needed
necessarily for your use case.

But as the drivers themselves are not aware themselves when they
lost context without checking that all registers are initialized
properly, I think we need something generic for tracking the context
lost. Typically it's the power domain hardware that knows when
context was lost.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html