On Saturday, September 04, 2010, Alan Stern wrote: > 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.) That's correct, but people are considering using PM QoS for this purpose. > 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 fine, but I think there are situations in which las_busy/suspend_delay are simply not useful. > 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. That depends on what you mean by "automatic suspending". To me, "automatic suspend" means exactly "suspend after certain period of inactivity", but there are other situations in which runtime PM is applicable (eg. the "cable not present" case). > In view of these thoughts, do you have any suggestions for the names of > the new functions? Well, I guess we first need to clarify the terminology. :-) 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
