On Tue, 16 Mar 2010, Kevin Hilman wrote: > 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. If the platform bus manages the clocks from within its runtime-PM routines, then it ought to provide a similar service from within its system-PM routines. You could do it by calling the bus's runtime-PM routines indirectly through the method pointers (as you do now), or by calling the runtime-PM routines directly, or by making the runtime-PM routines and the system-PM routines both call a separate common function responsible for managing the clocks. Each of these approaches is acceptable, assuming it doesn't mess up any of the other platform drivers in your system. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
