Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

[Tony Lindgren <tony@xxxxxxxxxxx>]

* Linus Walleij <linus.walleij@xxxxxxxxxx> [171129 13:03]:
> On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote:
> 
> > Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose
> > their register contents when entering their lower power state. In such a
> > case, the pinctrl-single driver that is used will not be able to restore
> > the power states without telling the core about it and having
> > pinctrl_select_state() check for that.
> >
> > This patch adds a new optional boolean property that Device Tree can
> > define in order to obtain exactly that and having the core pinctrl code
> > take that into account.
> >
> > Signed-off-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
> 
> Florian, I'm really sorry for losing track of this patch set, it's
> important stuff and I see why systems are dependent on something
> like this.
> 
> Tony: can you look at this from a pinctrl-single point of view?
> This is the intended consumer: pinctrl-single users that lose the
> hardware state over suspend/resume.
> 
> How do you see this working with other pinctrl-single users?

Hmm well typically a device driver that loses it's context just does
save and restore of the registers in runtime PM suspend/resume
as needed. In this case it would mean duplicating the state for
potentially for hundreds of registers.. So using the existing
state in the pinctrl subsystem totally makes sense for the pins.

Florian do you have other reasons why this should be done in the
pinctrl framework instead of the driver? Might be worth describing
the reasoning in the patch descriptions :)

So as long as the pinctrl framework state is used to restore the
state by the pinctrl driver instead of the pinctrl consumer drivers,
I don't have issues with this patchset. So probably just improving
the patch messages a bit should do it.

FYI, on omaps, the PRCM hardware saves and restores the pinctrl
state so this has not been so far an issue.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html