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. Of course, the driver can always call pm_schedule_suspend with a delay value that's _longer_ than suspend_delay. That's okay; the PM core will use the larger of its delay argument and suspend_delay. The whole point is that suspend_delay represents a minimum; it prevents devices from "bouncing" too quickly between full power and low power. 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
