david singleton wrote: > Greg, > perhaps I need to back up a bit. I wasn't submitting these patches > for inclusion into Linux. I was presenting them to the people > discussing > how power management might evolve in Linux. > > This patch is just a toy prototype to use as a strawman to discuss > how power management infrastructures in Linux might evolve to be more: > > a) unified > From high level POV I can read this patch set as an approach to design a glue for suspend/resume management and frequency changes management in the system but I can hardly get from the code and supplied documentation how the patch set addresses the following issues in question towards Linux power management unification. The ideal goal of ongoing efforts is to design a unified power management framework which allows to build power management for systems of different types (desktops, embedded, etc) on top of the framework, customizing power management of a target system with help of plugins implementation on framework layers. I'd like to refer to the ongoing discussion on this list based on the patches I sent out a week ago and ask for comments on how your patch set addresses: 1) embedded system needs in question including but not limited to: - runtime operating points creation from userspace - standardization of API to control clock and voltage domains - integration with dynamic clock(and voltage) management (clock/voltage framework) 2) interface (kernel as well as userspace(sysfs)) for the rest of power parameters except cpu voltage and frequency 3) per platform nature of an operating point rather than per a pm control layer (cpufreq for ex.): - you have cpu freq and voltage defined in common code while it's still possible that on a certain platform one would not be interested in control of these parameters - it's cpufreq driver which allocates memory for operating points in your patches. I should not duplicating the code if I'm implementing another pm control layer instance (policy manager) which is actually a plugin for pm framework and can share operating points - most probably all operating points [at least] of the same type ( sleeping or frequency) would have the same transition call back and since this it seems transition callback might be platform specific thing - assuming several instances on pm control layer (several policy managers) what would be the code which is responsible for accessing hardware to handle a certain policy manager decision? With the current approach you would need to duplicate code of pre/transition/finish routines per a pm control layer instance 4) you introduced second sysfs interface for cpufreq and have not removed original one. Do you expect cpufreq sysfs interface to be changed from original one? Thanks, Eugeny > and > b) simplified for both kernel and user space. > > The Documentation/powerop.txt included in the powerop-core.patch > tries to describe what the patch is attempting to do and how it works. > > David > > > On Jul 28, 2006, at 5:45 PM, Greg KH wrote: > > >> On Fri, Jul 28, 2006 at 05:38:11PM -0700, david singleton wrote: >> >>> On Jul 28, 2006, at 4:38 PM, Greg KH wrote: >>> >>> >>>> On Fri, Jul 28, 2006 at 03:31:41PM -0700, david singleton wrote: >>>> >>>>> Here is a patch that implements a version of the PowerOp concept. >>>>> >>>> Any chance of breaking this up into logical patches that do one thing >>>> at >>>> a time so it can be reviewed better? >>>> >>>> thanks, >>>> >>>> greg k-h >>>> >>>> >>> Here's powerop-core.patch, powerop-cpufreq.patch and >>> powerop-x86-centrino.patch. >>> >> Um, no, that's not how kernel patches are submitted. How about one per >> email, with a description of what they do, inline so we can quote them >> in a message (and actually read them in the original message...) >> >> See patches posted here by others as examples of what is expected, and >> see Documentation/SubmittingPatches for more details. >> >> thanks, >> >> greg k-h >> > > _______________________________________________ > linux-pm mailing list > linux-pm at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm > >