On Mon, 10 Nov 2014, Ulf Hansson wrote: > > To me, this sounds like a good reason to avoid using > > force_runtime_suspend(). In fact, it sounds like a good reason to > > avoid relying on the runtime PM mechanism to handle non-runtime-PM > > things (like a system suspend callback). If CONFIG_PM_RUNTIME isn't > > enabled then the runtime PM stack simply should not be used. > > There are an important advantage of using the pm_runtime_force_suspend() here. > > For the driver to handle clock gating at system PM suspend, it first > needs to bring the device into full power, through > pm_runtime_get_sync(). Otherwise it's not safe to gate the clock, > since it may already be gated. That's fine, but it has nothing to do with pm_runtime_force_suspend(). Besides, if the real question is whether or not to gate the clock (or in other words, has the clock already been gated), why not just store a "clock_is_gated" flag somewhere? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
