On Mon, 2007-03-19 at 23:44 +0800, Alan Stern wrote:> On Mon, 19 Mar 2007, Shaohua Li wrote:> > > Runtime device power management or dynamic device power management> > (dpm).> >> > Why dpm:> > 1. put an idle device into low power state to save power> > 2. speed up S3/S4. In resume time, we could resume devices only> as> > the devices are used. In suspend time, we could skip> suspended> > devices. (suspend/resume a device equals to change device> state)> >> > Basically we need device driver support, a kernel framework and a> policy> > (determine when to change a device’s power state).> > A lot of development along these lines has already been going on in> the> USB subsystem. It isn't complete yet, but a lot of the ideas you> raise> have already been implemented.Ok, I'll look at the USB implementation. On the other hand, I thinkthere should be a generic framework for all bus types. > > 4. policy position. The idea is policy resides on userspace.> Dpm> > framework exports device’s busy timestamp, state info,> > dependence setting to userspace. According to the info,> policy> > suspends a device in specific time. Resuming a device is> > directly done by dpm framework in kernel.> > In USB, we export the idle-time delay value (device is autosuspended> when it has been idle longer than this) and an administrative> power-level> atttribute: on, auto, or suspend. When set to "on" the device will> not> autosuspend; when set to "auto" the device will autosuspend and> autoresume> according to the delay setting; when set to "suspend" the device will> be> suspended and will not autoresume.Doing suspend in the driver level isn't flexible. See in the case 'closeconsole if keyboard/mouse hasn't input', it's hard to do in a driver. Thanks,Shaohua_______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
