Re: runtime PM: common hooks for static and runtime PM

Alan Stern
2010-02-04T15:24:48Z

On Wed, 3 Feb 2010, Kevin Hilman wrote:

> Hello,
>
> I'm implementing runtime PM for the TI OMAP SoCs by overriding the
> platform_bus hooks. All is working well for runtime PM, but it's
> brought up a couple snags for static PM.
>
> Most of our drivers don't really need to distinguish between runtime
> PM and static PM as we can hit the same power states when idle as we
> can in suspend. Before switching to runtime PM we've been using the
> clock framework to do both runtime PM and static PM. The driver would
> disable its clocks & HW when idle and when going into suspend,
> typically using a common 'disable' function.
>
> In converting a test driver to runtime PM, I just converted this
> common disable function from a clock disable to a
> pm_runtime_put_sync() and the common enable function to do a
> pm_runtime_get_sync(). This all worked well for runtime PM, resulting
> in my platform_pm_runtime_* hooks being called where I can then
> disable/re-enable the clocks/HW etc. So far so good.
>
> However, I'm not able to use the common function in the static suspend
> path because dpm_prepare() does a pm_runtime_get_no_resume() which
> prevents any runtime PM transitions during suspend.
>
> I understand the motivation for this is probably to prevent runtime PM
> transitions during static suspend, and that makes sense. However, I'm
> wondering if there's some other way to handle my problem without
> having to have the driver have different paths for static and runtime
> PM.

The system PM methods could directly call the runtime_suspend and
runtime_resume methods (which presumably is where you actually disable
or enable the clocks etc.), instead of going indirectly through
pm_runtime_put_sync() and pm_runtime_get_sync().

Or alternatively, both sets of PM methods could call a single pair of
routines to handle the clocks etc.

Alan Stern