On Tue, 3 May 2005, Adam Belay wrote: > Hi all, > > I've been putting together some documentation for my proposed power > management changes. In some areas it may be different or more detailed > than what I originally posted. I look forward to any comments or > suggestions. > > Thanks, > Adam I think there are some good ideas here, but you've taken the development much too far for something that's still in the "early proposal" stages. Also it seems much more elaborate than we really need, and it includes distinctions that aren't necessary. Let me try to summarize quickly the high points as I see them. You've defined power devices and power domains, where a power domain is really just a power device that can act as a parent to other power devices. In other words there's no significant difference between devices and domains -- there's just leaves and interior nodes in a power tree. You said explicitly that power devices may or may not coincide with struct devices in the driver model. Why do you want to do this? Why not insist that power devices _are_ struct devices? It would make many things a lot easier and allow much more code sharing plus reduction of memory usage. (Kobjects aren't cheap, especially for embedded systems.) You've got power resources totally outside the power tree. This seems like a very good way to handle oddball configurations and other things that don't fit the generic model. It takes advantage of the fact that most power constraints can be represented in terms of a device tree even though some of them can't. You've got both power drivers and policy managers. Why separate the two? Won't a real implementation have to keep them closely interconnected anyway? Or have I misunderstood? For that matter, what sort of policy options can the kernel offer to userspace? I'm not aware of many possibilities: System power transitions can be thought of as policy changes. Individual devices or subsystems can be powered down either immediately or after some inactivity timeout. Devices may or may not be set to resume on demand. Anything else? This list in itself doesn't require much in the way of policy management. Alan Stern
