On Jul 30, 2006, at 4:02 AM, Vitaly Wool wrote:

David,

On 7/30/06, david singleton [off-list ref] wrote:

quoted

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.

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.

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.

quoted

quoted

2) interface (kernel as well as userspace(sysfs)) for the rest of 

power

quoted

   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.

quoted

quoted

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