Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state
From: Linus Walleij <hidden>
Date: 2017-11-29 13:06:37
Also in:
linux-gpio, lkml
On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli [off-list ref] 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 <redacted>
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?
quoted hunk ↗ jump to hunk
@@ -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