On Sat, 4 Sep 2010, Rafael J. Wysocki wrote: > > After thinking about this some more, I have decided this may not be so > > bad. There could be two suspend_delay values stored, a primary and an > > alternate, along with a flag telling the PM core which value to use. > > The sysfs interface would always update the primary delay and > > subsystems would be responsible for updating the alternate. (In the > > SCSI case, the primary value would be the "medium present" delay and > > the alternate would be for "medium not present".) The subsystem would > > set the "use_alternate_delay" flag as desired. A subsystem could even > > maintain more than one alternate delay value; all it would have to do > > is tell the PM core when it wanted to replace the current alternate > > delay with a different value. > > > > It makes sense to treat the primary delay specially, since many or most > > devices will never need any others. But this way we can allow for that > > possibility. > > Well, as I said in the previous message, the suspend delay value provided by > user space should be preserved. > > Apart from this, I think that if there's a good use case, there can be more > suspend delay fields. Yeah; medium-present vs. medium-not-present seems like a pretty good use case to me. > > Back on the topic of USB interfaces... Rather than having a flag to > > mean "use the parent's delay", I think a different approach would work > > better. The real issue with interfaces is that they are only logical > > sub-devices; they can't be power-managed separately from their parent. > > Indeed, the runtime_suspend and runtime_resume callbacks for interfaces > > always return 0 immediately without doing anything, and the > > runtime_idle callback always calls pm_runtime_suspend. > > > > So why not tell the PM core about this behavior? Let's put a > > "no_callbacks" flag in dev_pm_info. When this flag is set the core > > won't bother invoking the runtime callbacks; it can always assume > > success. More importantly, an asynchronous request may never need to > > use the workqueue: > > > > __pm_request_idle can directly call __pm_request_suspend. > > > > If the device's state is ACTIVE then __pm_request_suspend > > can switch the state directly to SUSPENDED. > > > > If the device's state is SUSPENDED and the parent's state > > is ACTIVE then __pm_request_resume can switch the device > > directly to ACTIVE. (If the parent isn't ACTIVE then we > > need to proceed as we do now.) > > > > With those shortcuts added there won't be any need to use delayed > > autosuspend for interfaces. I don't know if any other subsystems would > > want to use the no_callbacks flag, but it's possible. > > > > What do you think? > > It seems it would be nice if PM runtime specific files in sysfs were not > created for these things, then. Would that be possible with the new flag? I think so. Ideally this flag would be specified before the device is registered. But even if it gets changed later, the routine that changes it could create or remove the runtime-specific attribute files. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
