On Tue, Sep 25, 2012 at 1:43 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Tue, Sep 25, 2012 at 02:24:23PM +0300, Peter Ujfalusi wrote:
For this to work it would be ideal to use the pm_runtime as a centralized place to handle clocks, pinctrl, etc... But again, what to do with the cases when this is not needed (the pinctrl part for the devices)?
It's also not massively clear to me that generic pm_runtime code is a good place to put all this stuff - it's too coarse grained for a lot of things.
I tend to agree. If you think of things like the clock handling in drivers/base/power/clock_ops.c that shmobile is relying upon. This is just not working with our platforms because different drivers need different semantics.
In ux500 drivers we use *specific* (as opposed to generic) runtime PM code to e.g. get some hysteresis before a drivers clock and pins (etc) are put to sleep. Pure driver business.
So these are runtime suspend/resume calls in the driver itself.
Devices that can be wake sources are an example here, if they are doing that then turning them completely off may break functionality but you can still turn some of the device (possibly a varying selection depending on usage) off. For simple cases it works well and it'd be good to have it but you end up back into ignoring errors...
Our ux500 "sleep" state on the pins will put them into the apropriate wakeup mode where applicable. Since this may vary across boards it's even machine-specific.
Configuring wakeup sources when going to a state named "sleep" seems intuitive to me atleast.
Then we have this (currently unused) "idle" state, which is intended as a power-saving state without going to sleep. So this is for the case when the system needs to be relaxed on power but not yet put to sleep. On some systems and for some drivers this state and the "sleep" state will likely be the same, but I'm just philosophizing here.
These are just defined as strings in include/linux/pinctrl/pinctrl-state.h with some kind of semantics.
The pinctrl handle can be moved into any state at any time, it's not like it's a state machine or something, so the subsystems and drivers need to know what they are doing.
Yours, Linus Walleij