On Fri, Feb 05, 2010 at 10:41:40AM -0500, Alan Stern wrote: > On Fri, 5 Feb 2010, Mark Brown wrote: > > On Thu, Feb 04, 2010 at 10:24:48AM -0500, Alan Stern wrote: > > > On Wed, 3 Feb 2010, Kevin Hilman wrote: > > > > 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. > > One issue with avoiding the indirection is that they'll need to remember > > if the device is already suspended in order to avoid doing things like > > double disabling of clocks or regulators. Using the runtime PM calls > > would mean that the core would keep track of that for the driver. > As you have found out, that approach doesn't work. You need to figure > out some way of your own to avoid double disabling. The PM core can't > do it for you, because there may be devices that enter _different_ > power states for runtime suspend and system suspend. For the sake of > such devices the core _has_ to do double suspends. Right, but my point is that one reason for wanting to call into the runtime PM API during vanilla suspend is that the indirection buys you the reference counting. I wonder if it's worth the PM core providing an off the shelf suspend and resume via runtime PM implementation so drivers only need to assign function pointers? As Kevin says this is going to be *very* common for embedded drivers. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
