On Tue, 7 Apr 2009, Rafael J. Wysocki wrote: > Well, in fact I wanted to know your opinion about this patch. :-) Clearly this patch isn't appropriate for regular desktop or laptop systems. I'm not so sure it's the best approach for embedded systems either. Part of the problem is the set of devices which would remain unsuspended: the device for which the flag is set plus everything below it in the device tree. This goes against the way the kernel has behaved up to now, which is that a device may not be suspended before all its children are suspended. In addition, the patch appears to ignore issues involving clock and voltage domains. These things often are not reflected directly in the structure of the device tree. At a more fundamental level, this change points out a real weakness in the way suspend is currently implemented. From the PM core's point of view, system suspend involves two main activities: Telling drivers to stop using their devices, and Turning off (or reducing) power to the devices. The PM framework does not treat these separately; a single suspend method call is used for both purposes. But more and more we are seeing that they should be, especially on non-ACPI systems. This patch is, in a roundabout way, an attempt to do so. Part of the problem is that people tend to think of "suspend" as meaning "suspend the system". However a much more flexible -- dare I say more valid? -- point of view is "suspend the CPUs and at the same time remove (or reduce) power for devices that will no longer need it". In other words, system suspend really is just a kind of runtime suspend, in which the devices being suspended are the CPUs and the sysdevs. Obviously this is an oversimplification, but I think it's a useful approach. Just think about it. Suppose every driver supported autosuspend. When a driver received a notification that the CPU was going to be suspended, it would know that its device wasn't going to need power (since the device can't do anything useful without the driver telling it what to do) and so it would automatically power the device down, while also arranging not to access the device any more. Thus the suspend method calls would really exist only to let drivers know that their code was going to stop running (since the CPU was about to stop all activity); the device-power management part would merely be a side effect. And then, of course, drivers on embedded systems would be smart enough to know that some of the devices _should_ remain powered up, because they could still be useful even when the CPU wasn't running. The only obstacle is letting the drivers know when their devices actually _are_ in use -- sometimes this is apparent only at the application level. So the patch should be rewritten. Change the name of the new attribute to something like "autonomous" or "in_use", and don't make the PM core skip devices when the attribute is set. Instead, change the relevant drivers. Their suspend methods should arrange for the driver to stop using the device, but if the attribute is set then the device should not be powered down. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
