On Fri, 3 Sep 2010, Alan Stern wrote: > 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. There is a related issue of naming. I'm not sure that calling all this stuff "autosuspend" is a good choice. There's nothing "auto" about the changes added here. If a device is to be put in low power, the subsystem or driver still must call an appropriate pm_runtime_* function. What these changes add is the ability to _delay_ suspends so that the device remains idle for some minimum time. This is an important aspect of runtime PM, which I plan to discuss in the documentation file. In brief, switching between low power and full power requires time and energy. It shouldn't be done unless there's likely to be a net benefit. This means a device shouldn't be runtime-suspended unless there's good reason to think it will remain in low power for a reasonably long time. In practice we use the heuristic that a device which has been idle for some period is likely to remain idle for a while. (There's also a notion of an "energy break-even" time.) Until now, a subsystem or driver wanting to do this has had to handle all the details on its own: keeping track of when the device was last used, computing how long the device should remain idle, allowing the user to set the idle-delay value, and so on. The patch merely moves all these pesky details into the PM core. That's why I think using "autosuspend" in the name isn't so good. This stuff is centered around the idea of implementing delays, not automatically suspending. In view of these thoughts, do you have any suggestions for the names of the new functions? 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
