On Saturday, September 04, 2010, Alan Stern wrote: > On Sat, 4 Sep 2010, Rafael J. Wysocki wrote: > > > I think suspend_delay shouldn't be modified in any case, because it's what > > user space provided us with and it has the right to expect that we won't change > > that value. There may be an additional "current suspend delay" field used for > > temporary storage. > > > > Then, pm_autosuspend(dev, delay) may simply compare its delay argument with > > suspend_delay (that can only be changed by user space) and use the greater > > value to initialize the "current suspend delay" field. > > > > Would that make sense? > > I prefer the scheme presented in the later email, where there are > primary and alternate suspend delays, both set by userspace and not > changed or overridden by the driver. > > > > In the current patch, suspend_delay can't be overridden. It can only > > > be ignored (when use_suspend_delay isn't set). > > > > I used wrong words, sorry. I wanted to say that pm_schedule_suspend() in its > > current form may be useful too, even if one's going to use pm_autosuspend() > > in general. Namely, pm_schedule_suspend() means "suspend 'delay' ms from > > now and ignore last_busy", which may be useful in some cases. > > That's not how I'd like it to work. When the use_suspend_delay flag is > set, there should be no way around it. The PM core _will_ enforce this > minimum idle time before allowing runtime suspends. If you want to > ignore last_busy then you have to call > pm_runtime_dont_use_suspend_delay (to be renamed > pm_dont_use_autosuspend or something like that). The driver can't > easily choose to ignore suspend_delay on a one-time basis. I don't see a valid reason for this restriction. Moreover, I'm anticipating situations where it will be inconvenient. Consider an Ethernet adapter. It's driver may very well want to use autosuspending, but if the network cable is detached from the device, it makes sense to suspend it without taking last_busy and friends into consideration. Thanks, Rafael -- 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
