On Tue, 2007-03-20 at 22:58 +0800, Alan Stern wrote: > On Tue, 20 Mar 2007, Shaohua Li wrote: > > > > 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 think > > there should be a generic framework for all bus types. > > I agree, but only to the extent that the concepts can usefully be > shared. > What works for USB might very well not work for a different > subsystem. > > My approach has been first to get something that does work in one > subsystem, and then to see about moving it into other subsystems or > the PM > core. I haven't finished the first step yet. :-) So it may be a > little > premature to try defining a full-blown dynamic power management > solution > that can apply to everything. This makes sense. > > Doing suspend in the driver level isn't flexible. See in the case > 'close > > console if keyboard/mouse hasn't input', it's hard to do in a > driver. > > I'm a little confused by this. If you want to suspend a device, > surely > you have to ask the device's driver to do the actual work? > > Maybe you mean that the _decision_ to suspend a device sometimes must > be > made by code other than the device's driver. Yep. > I agree; nothing I said > before was meant to rule out such things. In fact, USB already > contains > several instances where non-driver code decides to suspend a device. > For > example, when a device's file in the usbfs filesystem is closed, the > filesystem code attempts to suspend the device. This is another question. Should we make decision in kernel layer? Thanks, Shaohua _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
