* 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
