Alan, Thanks for taking the time to answer my questions. See inline for additional comments. On 06/11/2011 10:12 AM, Alan Stern wrote: > On Fri, 10 Jun 2011, Kenneth Heitke wrote: > >> Hi Rafael, >> >> Sorry if this question has been raised before. I actually have two >> questions here. These questions are related to PM runtime being >> disabled at runtime (i.e. call to pm_runtime_disable() ) >> >> If I call pm_runtime_enabled() to first determine if PM runtime is >> enabled followed conditionally by a call to pm_runtime_get_sync(), it >> would be possible for PM runtime to be disabled between these two calls >> and the get_sync() will fail. Is there any reason to even use the >> enabled() call? > > As a general rule, a device won't be enabled or disabled for runtime PM > unless its driver or subsystem enables or disables it. Since you > should already know what the driver and subsystem are doing, there > usually isn't any reason for using pm_runtime_enabled(). > >> My goal here was to use the enabled() call to determine >> if PM runtime was configured/enabled in the kernel and then to manage my >> resources, clocks etc, in a different way if PM runtime is not present. > > If runtime PM isn't present, why do you want to manage your clocks etc. > at all? The fact that it's not in the kernel means the system manager > doesn't care about power usage. I am trying to be backwards compatible. There is likely a period of time from when the runtime PM feature was added to when it was turned on by default. If the feature happens to be disabled, I think it makes sense for the driver to still do what it can to manage its resources. The power guys aren't going to let me off the hook that easily :) >> My second question then is what if PM runtime is enabled in the kernel >> and then gets disabled at runtime. What is the expected behavior for a >> driver? Should it fail all requests with EGAIN until PM runtime is >> enabled again? (in suspend state, PM runtime gets disable, new i/o >> request is made, power and clocks need to be turned on). > > It's up to the driver and the subsystem, since they are the entities > that are responsible for disabling runtime PM. If you think disabling > runtime PM will cause problems, then don't do it. I'm thinking about within runtime PM itself. I believe during system suspend, disable() followed by enable() can be called. If that happens, are there any scenarios that I need to be concerned about? Can my autosuspend timer just happen to fire during that window between disable and enable resulting in a failure to suspend? My driver is part of the i2c subsystem, do I know for a fact that disable() won't be used? > >> What about delayed autosuspend? I believe that if PM runtime is >> disabled while there is a delayed autosuspend pending, the suspend will >> fail without notification (clocks and power will be left on). > > That's right. > >> Will PM >> runtime still be in the idle state once PM runtime is re-enabled? > > The device will be in the same state as it was when it was disabled, > unless you explicitly call pm_runtime_set_active() or > pm_runtime_set_suspended(). > > Alan Stern > > thanks, Ken -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
