On Fri, Jul 19, 2013 at 9:03 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 07/19/2013 04:29 AM, Grygorii Strashko wrote: >> First of all, I'd like to mention that these patches do *not* connect >> pinctrl to PM runtime, so until driver will call pinctrl_select_state() >> or pinctrl_pm_select_*() there will be no pins state changes. > > Isn't the whole point of the pinctrl_pm_select*() APIs to eventually be > called automatically by the runtime PM core, Nah I had no such complete ambitions, just factoring around. There are examples, such as deactivating a TTY from userspace, that should result in the pins going to sleep while it may have nothing to do with runtime PM. > so that we don't need to > write code to do this in every single driver, just like we moved the > call to pinctrl_select_state(default) into the device core so that we > didn't have to make every device do that manually? I am pretty convinced that if this dynamic muxing stuff shall be implemented, it should be a pinctrl subsystem intrinsic optimization detail and should not be exposed to the outside with all these extra functions at all. It looks overly complicated to me. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
