[Ksummit-discuss] [TECH TOPIC] PM dependencies

Peter De Schrijver pdeschrijver at nvidia.com
Mon May 26 14:30:35 UTC 2014


On Fri, May 23, 2014 at 10:32:24AM +0200, 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.
> 
> 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 :-)
> 

On Tegra to powergate a domain you have to:

1) wait until all outstanding memory accesses by DMA clients in the domain have finished and assert the reset of the DMA clients. This is because DMA to/from memory goes via a seperate path compared to control MMIO (register accesses).
2) assert reset of the modules in the domain
3) disable the clocks of the modules in the domain
4) enable clamps
5) turn off power

to powerungate a domain you basically have to do:

1) enable power
2) enable all clocks of the modules in the domain
3) unclamp the domain
4) deassert reset (this is why the clocks have to be on, otherwise the reset signals wouldn't propagate)
6) deassert reset of the DMA clients
5) disable all module clocks again

My guess is that OMAP does most of this sequencing in hw (probably done by the PRCM). Also I guess that OMAP doesn't need the special handling of the DMA clients as both control MMIO and DMA goes via the same interconnect.

Cheers,

Peter.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


More information about the Ksummit-discuss mailing list