On Tue, 21 Sep 2004, David Brownell wrote: > Right. But for the moment, I think the focus is necessarily on > trying to make the current model be more usable.
> Wouldn't surprise me at all. But getting there by incremental improvements > isn't going to be straightforward. And locking is subsidiary to having a > usable/correct model. Here's a proposal for how the driver-model part of the PM subsystem should work; see what you think. Power-level states range from PM_SUSPEND_ON = 0 to PM_SUSPEND_MAX. PM_SUSPEND_ON means full power, anything higher implies some power reduction, and PM_SUSPEND_MAX means no power. Drivers are free to interpret the intermediate values as they please, subject to the restriction that power usage must be a non-increasing function of the state number. (PCI drivers would naturally map the levels to D0 - D3cold.) It's legal for a driver to make several values correspond to the same physical state, but the dev->power.power_state value is always the _nominal_ value of the state. Allowable state transitions include: increasing the state value (in a suspend call), and setting it back to 0 (resume always sets the power_state back to 0). The PM core guarantees that it will never invoke a suspend callback with a state argument <= the device's current value. It also guarantees that it will never create a situation in which a device's state value is < its pm_parent's value. When a driver's suspend() or resume() callback is invoked, it is not responsible for setting dev->power.power_state. The PM core will set the value appropriately if the callback returns 0. If a driver is asked to change the state to a higher value which it maps to the same physical state, then it need not do anything. The API should include calls to suspend or resume an individual device or the entire subtree below a device. Recursion is handled by the PM core; drivers need not consider it (although they may, provided they obey the rules for allowable state transitions -- but a driver won't know if the original request was for the device alone or its whole subtree). This leaves some unanswered questions. On some buses (such as PCI or USB), it's not possible to access a device whenever its state is higher than 0. So how can a driver increase the state, once it is positive? Conceivably this could cause a system-wide state-3 suspend to fail if some device were already say in state 1. Implementing this would require adding a children list_head to dev_pm_info. It would probably need additional integration with the rest of the PM subsystem, which I know nothing about. And of course I have ignored the locking issues. Apart from all this, what about the deadlock problems you were having with dpm_sem? I don't remember the details; did the deadlock occur because you wanted to register or unregister a device during a suspend or resume? In general that's probably not a good thing to do. Registering and unregistering cause hotplug events, but during system-wide suspend/resume all processes are supposed to be frozen. An alternative approach would be to call schedule_work() or use khubd to take whatever action is needed, after the resume has finished. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
