On Aug 1, 2006, at 3:09 AM, Matthew Locke wrote: > > On Jul 31, 2006, at 5:59 PM, david singleton wrote: > >> >> On Jul 30, 2006, at 4:02 AM, Vitaly Wool wrote: >> >>> David, >>> >>> On 7/30/06, david singleton <dsingleton at mvista.com> wrote: >>> >>>> That's one of the simple parts of the concept. There aren't any >>>> runtime operating >>>> point creation. It's one of the things I like best about cpufreq, >>>> the >>>> frequency >>>> and voltages are taken from the hardware vendor data sheet and >>>> validated. >>>> >>>> The user just gets to use the operating points supported by the >>>> system, >>>> not >>>> choose the frequency or voltage to transition to. >>>> >>>> By just presenting the supported operating points to the user it >>>> removes the >>>> need for new APIs. The user just reads the supported operating >>>> points >>>> and decides the best use of the supported operating points. >>> >>> I see this approach as fundamentally wrong at least because it will >>> produce very long and hard to manage lists of operating points. >>> Suppose you have 20 hardware vendor approved core CPU frequency >>> values, 3 possible voltage values and 10 approved DSP CPU frequency >>> values (which are derived from the other PLL). Not too impossible is >>> that almost all combinations are available which makes is almost 600 >>> operating points. I find it absolutely unreal that anyone enters all >>> that stuff without mistakes; managing those lists/searching thru them >>> will take significant time which will slow down the state >>> transitions; >>> and, finally, it's gonna increase the kernel footprint quite a bit. >> >> Actually in practice there aren't that many supported operating >> points, even on the hardware you and I are familiar with. I've yet >> to construct a case where there are more than 16 to 20 >> operating points. > > Its not the number of operating points driving the need for run time > creation. Please read the thread that took place early last week on > this topic. Start from my post here: > http://lists.osdl.org/pipermail/linux-pm/2006-July/003065.html and read > backwards. > > Its really the embedded device development and silicon vendor model > driving it. Run time creation is required and enabling run time > creation doesn't prevent some architectures/board ports from hard > coding their points. > >> >> And the Linux device model allows the system to be set at >> a particular operating point and then suspending the LCD >> or unused USB if so desired. So the combination flexibility >> is still available. >> >> If there were 600 supported operating points that would be a >> very good reason to use PowerOp. I'm not sure I'd want >> the user passing all the frequencies, voltages, clock >> divisor and clock multiplier for all those operating points. > > Well, no one is suggesting a user define and install that info. > Operating point creation will be done by someone who understands the > system (system designer) regardless of the method used to get the > operating points in the kernel. > >> >> List manipulation takes place at compile time and list traversal >> is simple. If a powerop were to become a kobject management >> and traversal would still be simple. >> >> The foot print actually shrinks if you take into account all the >> class, policy and governor code that wouldn't be needed if >> all supported states were simple operating points. >> >>> >>> It looks to me that the concept that the kernel can implement >>> rules/restrictions for operating points but shouldn't define them >>> with >>> possible exception for the most essential ones far better suits both >>> embedded and non-embedded use cases. >> >> CPUFREQ shows that it can, and I believe should, define the operating >> points the system supports. CPUFREQ does NOT let the user pass >> frequency or voltage values into the kernel. It shows the hardware >> vendor certified and validated frequencies and voltages. >> >> I really like that concept. It simplifies things greatly. >> >>> >>>>> 2) interface (kernel as well as userspace(sysfs)) for the rest of >>>> power >>>>> parameters except cpu voltage and frequency >>>> >>>> >>>> The /sys/power/supported_states file shows the supported operating >>>> points >>>> and their parameters. >>>> >>>> The platform specific information is hidden through the md_data >>>> pointer, >>>> which in the case of embedded systems with complex clocking schemes, >>>> contains the clock divisor and multiplier information that the >>>> system >>>> needs >>>> to perform frequency and voltage scaling and clock manipulation. >>>> >>>> The machine dependent portion of a centrino operating point >>>> is only the perfctl msr bits for each frequency/voltage. For >>>> a system with 5 power domains and various clocks the >>>> machine dependent portion contains the whole array >>>> of information for the different power domains and their clocks. >>> >>> Basically I don't see too much sense in your definition of >>> PM_FREQ_CHANGE and PM_VOLT_CHANGE. The latter one just isn't used >>> anywhere although the voltage differs between the operating points >>> for >>> your centrino example. And it's quite a common thing when frequency >>> and voltage are changed within the same transition; so those either >>> should be bitfields or something like PM_STATE_CHANGE. >> >> >> The example patch isn't provided to show how it should be implemented. >> >> I've added a separate PowerOp state of PM_VOLT_CHANGE for >> hardware that may be changing states by changing a voltage rather >> than having the voltage changed as a side effect of changing the >> frequency explicitly. >> >>> >>>>> >>>>> 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 >>>> >>>> Correct, but on all of the hardware with which I'm familiar cpu >>>> frequency >>>> and voltage are common components to power management. >>> >>> I do agree, but there might be different voltages and different CPU >>> frequencies within the same SoC, so it will mean that you separate, >>> say, two CPU frequencies between common code and SoC-specific code. >>> Maybe it's still the way to go, but it makes things quite complicated >>> to understand from scratch. >>> >> >> After digging through all the PM, CPUFREQ and Dynamic Power >> Management >> code it became apparent that when they get down to touching hardware >> they are just dealing with an operating point. And they all change >> from >> one opeating point to another in the same manner. >> >> Once you view all the states a system can be in as an operating point, >> wether >> its a suspend or frequency change, things get much simpler. > > >> And >> >> David >> >> _______________________________________________ >> linux-pm mailing list >> linux-pm at lists.osdl.org >> https://lists.osdl.org/mailman/listinfo/linux-pm >> > > _______________________________________________ > linux-pm mailing list > linux-pm at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm >
