From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Locke Subject: Re: [RFC] PowerOP Take 3, sysfs UI core 2/5 Date: Tue, 1 Aug 2006 03:45:45 -0700 Message-ID: References: <200607241149.01700.david-b@pacbell.net> <083b1ba275390c298727816bc51f21b4@nomadgs.com> <200607261755.25808.david-b@pacbell.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <200607261755.25808.david-b@pacbell.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: David Brownell Cc: patrick.mochel@intel.com, Pavel Machek , linux-pm@lists.osdl.org, sampsa.fabritius@nokia.com, linux@dominikbrodowski.net List-Id: linux-pm@vger.kernel.org On Jul 26, 2006, at 5:55 PM, David Brownell wrote: > On Wednesday 26 July 2006 12:44 am, Matthew Locke wrote: >> >> On Jul 24, 2006, at 11:48 AM, David Brownell wrote: >> >>> So I was glad to see it split out as fully optional... although from >>> what I >>> see, the internal models in the code have derived from this sysfs >>> model, so >>> I'd argue those need to change too. >> >> Is there something specific in the internal model that are you >> referring to? > > I touched on some of the issues in earlier emails to Eugeny. > > One is that the struct declaration seems too monolithic to > handle board-specific differences well. Related to that is the > way things are just packaged as a set/struct of numbers, rather > than a set of objects/components with internal rules/models > (which might be individually reusable, e.g. "SOC X"). > > Maybe another way to think of it is that this sysfs stuff defines > some structural notions that seem to be artifacts of one style > for creating operating points ... and I'd be more comfortable > deriving those structural notions by addressing requirements of > specific board families (not just SOCs!). And _then_ coming up > with a sysfs model to suit. > Got it. I'll let Eugeny respond on this one. > >>> It'd be lots better to just have named operating points that get >>> selected just >>> the /sys/power/state file selects the, erm, "sleep point". >> >> I've tried to fit sleep into the operating point concept before but >> sleep always ends up being a special case. The code has to check to >> see if the selected operating the "sleep point" and call the suspend >> function. I think tying in sleep to the op point concept needs more >> discussion and probably should be handled separately until we get >> further along with power op. > > I'm comfortable with discussing sleep point separately from operating > points, so long as everyone understands how fuzzy a line that is. In > a system with dedicated asymmetric CPUs for example, is "this cpu is > asleep and that one is running" a sleep state? Or an operating point? > Ditto with hardware components that may be running or not, and don't > get to brag about some fancy instruction set. :) It is very fuzzy. If we can make it fit without forcing it, I think = it would be a very nice way to define the various sleep points = supported on the SoC's. > > In fact, I find it maybe easier to think of "run states" and "sleep > states", where a "run state" would include a collection of specific > operating points and some mechanism to select some operating point > to activate. I don't think that notion of "operating point" is what > you are talking about here with PowerOP, though... PowerOP is the definition of the operating point and the interface to = set one. I actually think the same way as you describe. There are run = states and sleep states. As the system changes "states" it will go = to an operating point. We are not including the state changing or = definition with PowerOp just the mechanism to list and select the = points. A component(s) of top of PowerOP would decide which operating = points belong to a run state and when to change. Examples of this could = be as simple as /sys/power/state, a more complex cpufreq = governor/policy or something new. > > >> btw, we are in complete agreement about using named points. This = >> first >> set of patches is meant to introduce the operating point concept into >> the kernel without requiring massive changes to cpufreq. This layer >> extends the bottom part of cpufreq to enable the control of multiple >> parameters beyond just cpu frequency and voltage across architectures. > > I guess I haven't read the patches enough to see how it extends that. > > >> Currently, cpufreq does not use named operating points so we need to >> make sure cpufreq can use the power op API and continue to function. >> This topic also ties into our other email discussion on creating op >> points and names are assigned to op points. > > Hmm, I'll be watching to see how that works out. I keep thinking that > in the big picture, a "governor" type component may not map well to > choosing operating points ... though a given component might well use > such a mechanism internally. > > - Dave >