Re: PowerOp Design and working patch

david singleton
2006-07-30T04:43:12Z

On Jul 29, 2006, at 12:07 PM, Eugeny S. Mints wrote:

> 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.

That's the point of powerop. The system designer implements
the operating points that best take advantage of the hardware on the
platform.

Powerop just does it in a simple and straight forward manner. All
the supported states a system can be in are operating points. Once
the different states can be expressed as operating points they
can be transitioned from one state to another simply
through the name of the operating point.

>
> 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)

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.

>
> 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.

>
> 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.

The point the example is trying to make is that the different power
management infrastructures can be unified and simplified.

> - 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

The cpufreq driver doesn't allocate any memory for any powerop
operating points. I leave the cpufreq driver alone. I make powerop
operating points that mirror the cpufreq table and link them
into the other supported operating points of the system.

I've purposely left the cpufreq code unchanged.

> - 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

The prepare_transition, transition, and finish transistion are all
platform dependent. That's why they are function pointers
in the powerop struct.

Each platform would define its own functions and different types
of operating points might have different functions. The powerop struct
has the correct prepare_trransition, transition, finish_transition
routines for the
specific platform and operating point.

> - 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?

I'm sorrry, I don't understand that question.

> With the current approach you
> would need to duplicate code of pre/transition/finish
> routines per a pm control layer instance

If I understand correctly, you wouldn't. For the centrino example I
used
the different frequency operating points all share the same prepare,
transition, and
finish routines.

> 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?

No. I've left the cpufreq code and interfaces alone for my example.
The resultant example can perform the same cpu frequency scaling
operations through
either interface.

David
>
> 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@lists.osdl.org
>> https://lists.osdl.org/mailman/listinfo/linux-pm
>>
>>
>