On Monday, November 12, 2012 11:32:26 AM Alan Stern wrote: > On Mon, 12 Nov 2012, Huang Ying wrote: > > > > > Is it absolute necessary to call pm_runtime_set_suspended? If the > > > > device is disabled, the transition to SUSPENDED state will not be > > > > triggered even if the device is ACTIVE. > > > > > > It's not absolutely necessary to do this, but we ought to because it > > > will allow the device's parent to be suspended. If we leave the device > > > in the ACTIVE state then the parent can't be suspended, even when the > > > device is disabled. > > > > I think this is the hard part of the issue. Now "disabled" and > > SUSPENDED state is managed by hand. IMHO, if we changed > > pm_runtime_allow() as you said, we need to change the rule too. Maybe > > something as follow: > > > > - remove pm_runtime_set_suspended/pm_runtime_set_active > > We can't remove them entirely. They are needed for situations where > the device's physical state is different from what the PM core thinks; > they tell the PM core what the actual state is. > > > - in pm_runtime_disable/pm_runtime_allow, put device into SUSPENDED > > state if runtime PM is not forbidden. > > That doesn't make sense. Runtime PM is never forbidden after > pm_runtime_allow is called; that's its purpose. > > > - in pm_runtime_forbid/pm_runtime_enable, put device into ACTIVE state. > > Why should pm_runtime_enable put the device into the ACTIVE state? > > No, I think a better approach is simply to say that the device will > never be allowed to be in the SUSPENDED state if runtime PM is > forbidden. We already enforce this when the device is enabled for > runtime PM, so we would have to start enforcing it when the device is > disabled.
Sorry for the delay, I needed to take care of some ACPI changes urgently. (Without reading the rest of the thread yet) I think that would be a reasonable approach. > This means: > > pm_runtime_set_suspended should fail if dev->power.runtime_auto > is clear. > > pm_runtime_forbid should call pm_runtime_set_active if > dev->power.disable_depth > 0. (This would run into a problem > if the parent is suspended and disabled. Maybe > pm_runtime_forbid should fail when this happens.) > > Finally, we probably should make a third change even though it isn't > strictly necessary: > > pm_runtime_allow should call pm_runtime_set_suspended if > dev->power.disable_depth > 0. > > Rafael, what do you think? As I said, sounds reasonable. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
