Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > 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(). > [Revisiting this thread again... with a slightly different problem] In my case, the driver's runtime_suspend and runtime_resume hooks are not where the clocks are managed. The actual hardware enable/disable is done in the bus-level runtime PM hooks, in this case platform_bus. So having the system PM methods directly call the drivers runtime PM methods doesn't help. In fact, because we handle the hardware at the bus level, most drivers can live without any runtime PM methods, and simply use get/put. I've worked around this temporarily by calling the bus->pm->runtime_suspend() and ->runtime_resume() methods from the system PM methods, but am curious if that is an acceptable solution. Kevin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
