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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
