From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power Date: Wed, 29 Nov 2017 09:02:47 -0800 Message-ID: <20171129170247.GI28152@atomide.com> References: <20171102231551.16220-1-f.fainelli@gmail.com> <20171102231551.16220-3-f.fainelli@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij Cc: Florian Fainelli , linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , Charles Keepax , Charles Keepax , Stephen Warren , Andy Shevchenko , Al Cooper , bcm-kernel-feedback-list List-Id: devicetree@vger.kernel.org * Linus Walleij [171129 13:03]: > On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli 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 > > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html