On Thu, Sep 6, 2012 at 2:28 PM, Tomasz Figa <t.f...@samsung.com> wrote: > Thanks for your comments. > > On Thursday 06 of September 2012 16:36:08 Thomas Abraham wrote: >> > This patch shows the problem of the need to explicitly migrate all >> > drivers to pinctrl. >> > >> > Maybe we should consider extending the pinctrl subsystem to set the >> > default state automatically before binding a driver to a device, at >> > least in case of DT-based platforms? >> >> The pinctrl driver allows for activating default pin configuration >> when the pinctrl driver loads. This is referred to as "hogging". > > What I suggested is that such default configuration would be applied just > before binding a driver, i.e. when it's almost sure that the device will be > actually used and the configuration will be needed.
In that case the pinctrl driver can poke down a default register configuration, but just like Stephen remarks I do not see the point either. Hogs should work just fine? > Of course such functionality would not have to be obligatory. For example, > we could add new property, like pinctrl-set-default, to point in device > tree that this device should have its pinctrl state set up automatically. This doesn't have a semantic difference to a default hog AFAICT. >> 1. After a suspend and resume cycle, the pin configuration registers >> may be reset to default values. Hence, during resume, the pin >> configuration has be redone. > > In my opinion it should be saved and restored by pinctrl driver (as it was > done in case of GPIO subsystem previously). This is one way to do it. I see Stephen has the same idea. Another way is actually to go to the default state from the default state. Or from any state to itself rather. Currently pinctrl_select_state_locked() contains this: if (p->state == state) return 0; If we just add pinctrl_select_state_force() excluding that clause we can force re-poking of the state at any time. Compare regulator_force_disable() and similar. Maybe this is actually more helpful? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html