From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state Date: Wed, 29 Nov 2017 14:06:34 +0100 Message-ID: References: <20171102231551.16220-1-f.fainelli@gmail.com> <20171102231551.16220-2-f.fainelli@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20171102231551.16220-2-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Florian Fainelli , ext Tony Lindgren Cc: 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 On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli wrote: > It may happen that a device needs to force applying a state, e.g: > because it only defines one state of pin states (default) but loses > power/register contents when entering low power modes. Add a > pinctrl_dev::flags bitmask to help describe future quirks and define > PINCTRL_FLG_FORCE_STATE as such a settable flag. > > Signed-off-by: Florian Fainelli So if I understand correctly, the state is lost across suspend/resume, correct? Or are we even talking runtime PM runtime_suspend and runtime_resume here? > @@ -1197,9 +1197,21 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) > { > struct pinctrl_setting *setting, *setting2; > struct pinctrl_state *old_state = p->state; > + bool force = false; > int ret; > > - if (p->state == state) > + if (p->state) { > + list_for_each_entry(setting, &p->state->settings, node) { > + if (setting->pctldev->flags & PINCTRL_FLG_FORCE_STATE) > + force = true; > + } > + } > + > + /* Some controllers may want to force this operation when they define > + * only one set of functions and lose power state, e.g: pinctrl-single > + * with its pinctrl-single,low-power-state-loss property. > + */ > + if (p->state == state && !force) > return 0; So the idea is we go and change the state even if we are in the right state already, I understand that much. But how is pinctrl_select_state() being called in the first place under these circumstances? If this comes from the resume() callback in .pm of the device driver, would not the same thing be achived if you just set some mock "sleep" state in suspend()? It could even have exactly the same settings as the "default" state, as long as it is another state, the register will be reprogrammed. See further include/linux/pinctrl/pinctrl-state.h Yours, Linus Walleij -- 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