[Ksummit-discuss] [TECH TOPIC] PM dependencies

[Rafael J. Wysocki]

On Friday, May 23, 2014 10:32:24 AM Linus Walleij wrote:
> On Fri, May 23, 2014 at 2:39 AM, Kevin Hilman <khilman at linaro.org> wrote:
> 
> > Of course, for many "simple" platforms, runtime PM get/put just ends up
> > doing a clk_enable/disable, but on the platforms where runtime PM is
> > slightly more... um, "interesting"... just doing a clk enable/disable
> > won't do what you hope.
> 
> And drivers/base/power/clock_ops.c as invoked from
> drivers/sh/pm_runtime.c does exactly that simple thing using
> PM domains. Quite elegantly too, I'd say.

Well, thanks! :-)

> But now I get curious - can we define the "interesting PM" more
> generally, like get the details out? And I mean like for a few different
> platforms, I know OMAP with its hwmod is one such thing, but how
> much interesting stuff do we have out there that we know we must
> be able to handle?
> 
> Cc:ing in Peter De Schrijver who might have some interesting PM
> to tell us about :-)

I generally like to split PM into things that can be done by the driver
regardless of the underlying platform and things that are platform-dependent.
It generally is better to abstract the latter away from drivers in my opinion.

So if a given clock is guaranteed to be manageable in the same way on every
platform where the driver will ever run, that clock may be managed by the driver
itself.  However, if that clock is correlated with something else on one of
the platforms and the driver would need to take that into account, things
can get quite ugly relatively quickly.  And if one of those platforms is
ACPI, they are ugly right to start with. ;-)

Rafael