On Thu, 11 Jun 2009, Rafael J. Wysocki wrote: > The point here is what the core is supposed to do. Does it need to handle > this at all or leave it to the bus type and driver? > > After reconsidering it for a while I think that we should define what > "suspended" is supposed to mean from the core point of view. And my opinion > is that it should mean "device doesn't communicate with the CPUs and RAM due > to power management". That need not be power management of the device itself, > but such that leads to the device not doing I/O. > > Under this definition all devices behind an inactive link are suspended, > because they can't do any I/O. Which appears to makes sense, because their > drivers have to be notified before the link is suspended and the link has to be > turned on for the devices to be able to communicate with the CPU and RAM. > > If this definition is adopted, then it's quite clear that the device can only > be suspended if all of its children are suspended and it's always necessary > to resume the parent of a device in order to resume the device itself. Okay, I'll agree to that. It should be made clear that a device which is "suspended" according to this definition is not necessarily in a low-power state. For example, before powering down the link to a disk drive you might want the drive's suspend method to flush the drive's cache, but it wouldn't have to spin the drive down. (But this example leaves open the question of how we would go about spinning down the disk. Submitting a 15-minute (or whatever) delayed autosuspend request wouldn't work; the request wouldn't be accepted because the disk is already suspended as far as the PM core is concerned. The disk's driver would have to implement its own spin-down delayed_work.) > > > > I haven't checked the details of the code yet. More later... > > > > One more thought... The autosuspend and autoresume callbacks need to > > be mutually exclusive with probe and remove. So somehow the driver > > core will need to block runtime PM calls. > > That's correct and I'm going to take care of this. > > > It might also be nice to make sure that the driver core autoresumes a > > device before probing it and autosuspends a device (after some > > reasonable delay) after unbinding its driver. > > Agreed. This is another case where a usage counter comes in handy. The driver core resumes the device and increments the counter -- thus preventing any unwanted autosuspends -- before making the probe and remove calls. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
