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 >
