Re: [Ksummit-discuss] [TECH TOPIC] PM dependencies

[Kevin Hilman <khilman@linaro.org>]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, May 23, 2014 at 2:39 AM, Kevin Hilman <khilman@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.
>
> 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?

By "interesting", I was referring to some of the more complicated ones
we have, such as OMAP (though I suspect other SoCs are equally
complicated but just don't have their stuff documented and/or upstream
yet so we don't know.)

That being said, I think any SoC that requires more than a clk_enable()
to bring an IP block out of a low-power state, or clk_disable() to put
it into a low-power state qualifies as "interesting" because it can no
longer rely on the "simple" clock_ops.c you refer to above.

Stated differently, for most SoCs, fine-grained PM is a lot more than
just clock management.  As soon as you have to do more than manage
clocks, the generic clock_ops.c isn't good enough and you need your own
PM domain (or use genpd.)

Kevin