* Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx> [171104 08:38]: > On Fri, Nov 03, 2017 at 10:33:53AM -0700, Tony Lindgren wrote: > > * Florian Fainelli <f.fainelli@xxxxxxxxx> [171103 17:04]: > > > On 11/03/2017 09:11 AM, Tony Lindgren wrote: > > > The pinctrl provider is losing its state, hence these two patches. > > > > OK > > > > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
