PowerOP, Intro 0/3

PowerOP, Intro 0/3

[Eugeny S. Mints]

The PowerOP Core provides completely arch independent interface
to create and control operating points which consist of arbitrary
subset of power parameters available on a certain platform.

PowerOP Core upper layer interface provides the following capabilities:
- to register an operating point by passing an idenificator of the point
represened by a string and arbitrary substet of power paremeters available on a
certain platform by a string (parameter name) and value pairs.
- to unregister operating point by name
- to set operating point by name
- to get values of arbitrary subset of platform power parameters associated
this  a point (point is passed by name or NULL to get current parameter values
from hw)

PowerOP get and register point APIs use name/value pairs for the power
parameters which eliminate the need for data structure sharing between
the PM core and consumers of the PowerOP API.   Earlier versions
required include/asm-xxx/power_params.h to be included in both places.

This also enables a variable argument list for the registration and get
APIs.  Some operating points may only need to work with a subset of the
power parameters.  In this case the creator of the operating point only
needs to provide the name/value pair for the parameters required for
that point.  The rest are set to a don't care value by the internals.

PowerOP is a building block for power management on systems that have a
large set of power parameter that can adjusted to maximize power and
operational efficiency.   Mobile consumer devices are examples of these
systems that require the PowerOP features.   However, PowerOP works
just as well on systems with one or two parameters.  The API allows the
h/w layer to define what parameters are available on that platform.

Operating points can be registered at anytime.  Registration can occur
from a architecture init-call, loadable kernel module or some other
layer.  Operating point registration notifiers are provided for layers,
such as cpufreq, that could take advantage of new operating
points that become available or just need to know when operating points
are loaded.

PowerOP continues to support in kernel governer concepts from cpufreq as well
as userspace policy managers.

Re: PowerOP, Intro 0/3

[Pavel Machek]

Hi!

> The PowerOP Core provides completely arch independent interface
> to create and control operating points which consist of arbitrary
> subset of power parameters available on a certain platform.
> 
> PowerOP Core upper layer interface provides the following capabilities:
> - to register an operating point by passing an idenificator of the point
> represened by a string and arbitrary substet of power paremeters available on a
> certain platform by a string (parameter name) and value pairs.
> - to unregister operating point by name
> - to set operating point by name
> - to get values of arbitrary subset of platform power parameters associated
> this  a point (point is passed by name or NULL to get current parameter values
> from hw)

I do not think this can work in notebook world, sorry. You'll just get
way too many operating points.

Workable solution would be to create power domains, and group devices
into power domains.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: PowerOP, Intro 0/3

[Eugeny S. Mints]

Pavel Machek wrote:
> Hi!
> 
>> The PowerOP Core provides completely arch independent interface
>> to create and control operating points which consist of arbitrary
>> subset of power parameters available on a certain platform.
>>
>> PowerOP Core upper layer interface provides the following capabilities:
>> - to register an operating point by passing an idenificator of the point
>> represened by a string and arbitrary substet of power paremeters available on a
>> certain platform by a string (parameter name) and value pairs.
>> - to unregister operating point by name
>> - to set operating point by name
>> - to get values of arbitrary subset of platform power parameters associated
>> this  a point (point is passed by name or NULL to get current parameter values
>> from hw)
> 
> I do not think this can work in notebook world, sorry. You'll just get
> way too many operating points.
The only feature for notebook world currently presented in the kernel is 
CPUFreq. CPUFreq PowerOP integration series I sent out for discussion is 
intended to at least provide the same functionality for notebook world as 
current functionality is. Did you glance at this series?

</personal> Pavel,
please stop removing original recipients from either TO: or CC: lists!
please, when you snip original message _do_not_ snip names of replied persons!
</end>
	Eugeny
> Workable solution would be to create power domains, and group devices
> into power domains.
> 								Pavel

Re: PowerOP, Intro 0/3

[Pavel Machek]

Hi!

> >>PowerOP Core upper layer interface provides the 
> >>following capabilities:
> >>- to register an operating point by passing an 
> >>idenificator of the point
> >>represened by a string and arbitrary substet of power 
> >>paremeters available on a
> >>certain platform by a string (parameter name) and 
> >>value pairs.
> >>- to unregister operating point by name
> >>- to set operating point by name
> >>- to get values of arbitrary subset of platform power 
> >>parameters associated
> >>this  a point (point is passed by name or NULL to get 
> >>current parameter values
> >>from hw)
> >
> >I do not think this can work in notebook world, sorry. 
> >You'll just get
> >way too many operating points.
> The only feature for notebook world currently presented 
> in the kernel is CPUFreq. CPUFreq PowerOP integration 

Actually no. In the notebook world, we do cpufreq, selective powerdown
of devices (/sys/**/power/state), and suspend-to-ram/disk (not sure if
it applies to you, but at least some powerop versions wanted to
replace that).

> series I sent out for discussion is intended to at least 
> provide the same functionality for notebook world as 
> current functionality is. Did you glance at this series?

Yes.

> </personal> Pavel,
> please stop removing original recipients from either TO: 
> or CC: lists!
> please, when you snip original message _do_not_ snip 
> names of replied persons!
> </end>

Do you have example where I did that?
							Pavel

-- 
Thanks for all the (sleeping) penguins.

Re: PowerOP, Intro 0/3

[Eugeny S. Mints]

Pavel,

2006/8/26, Pavel Machek <pavel@ucw.cz>:
> Hi!
>
> > >>PowerOP Core upper layer interface provides the
> > >>following capabilities:
> > >>- to register an operating point by passing an
> > >>idenificator of the point
> > >>represened by a string and arbitrary substet of power
> > >>paremeters available on a
> > >>certain platform by a string (parameter name) and
> > >>value pairs.
> > >>- to unregister operating point by name
> > >>- to set operating point by name
> > >>- to get values of arbitrary subset of platform power
> > >>parameters associated
> > >>this  a point (point is passed by name or NULL to get
> > >>current parameter values
> > >>from hw)
> > >
> > >I do not think this can work in notebook world, sorry.
> > >You'll just get
> > >way too many operating points.
> > The only feature for notebook world currently presented
> > in the kernel is CPUFreq. CPUFreq PowerOP integration
>
> Actually no. In the notebook world, we do cpufreq, selective powerdown
> of devices (/sys/**/power/state), and suspend-to-ram/disk (not sure if
> it applies to you, but at least some powerop versions wanted to
> replace that).
integration with legacy PM kernel code is the next step for PowerOP.
There is no chance to address all in one step. We need to go step by
step.
> > series I sent out for discussion is intended to at least
> > provide the same functionality for notebook world as
> > current functionality is. Did you glance at this series?
>
> Yes.
>
> > </personal> Pavel,
> > please stop removing original recipients from either TO:
> > or CC: lists!
> > please, when you snip original message _do_not_ snip
> > names of replied persons!
> > </end>
>
> Do you have example where I did that?
This thread is example of both: original letter in this thread has 3
recepients while in your first reply there is noone.
And there is no a name of reply originator between your 'Hi' and
'>>>>' signes while for example I have  '2006/8/26, Pavel Machek
<pavel@ucw.cz>' in this reply.

Thanks,
Eugeny
>                                                        Pavel
>
> --
> Thanks for all the (sleeping) penguins.
>

Re: PowerOP, Intro 0/3

[Pavel Machek]

On Sun 2006-08-27 14:34:06, Eugeny S. Mints wrote:
> 2006/8/26, Pavel Machek <pavel@ucw.cz>:

> >> >I do not think this can work in notebook world, sorry.
> >> >You'll just get
> >> >way too many operating points.
> >> The only feature for notebook world currently presented
> >> in the kernel is CPUFreq. CPUFreq PowerOP integration
> >
> >Actually no. In the notebook world, we do cpufreq, selective powerdown
> >of devices (/sys/**/power/state), and suspend-to-ram/disk (not sure if
> >it applies to you, but at least some powerop versions wanted to
> >replace that).
> integration with legacy PM kernel code is the next step for PowerOP.
> There is no chance to address all in one step. We need to go step by
> step.

Ok, but I guess I can't review it unless you do all the steps, and it
seems to me you are going into the wrong direction now.

> >> </personal> Pavel,
> >> please stop removing original recipients from either TO:
> >> or CC: lists!
> >> please, when you snip original message _do_not_ snip
> >> names of replied persons!
> >> </end>
> >
> >Do you have example where I did that?
> This thread is example of both: original letter in this thread has 3
> recepients while in your first reply there is noone.
> And there is no a name of reply originator between your 'Hi' and
> '>>>>' signes while for example I have  '2006/8/26, Pavel Machek
> <pavel@ucw.cz>' in this reply.

Ok, so you care about attribution lines. I'll try to keep them.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: PowerOP, Intro 0/3

[Matthew Locke]

On Aug 26, 2006, at 1:38 PM, Pavel Machek wrote:

> Hi!
>
>>>> PowerOP Core upper layer interface provides the
>>>> following capabilities:
>>>> - to register an operating point by passing an
>>>> idenificator of the point
>>>> represened by a string and arbitrary substet of power
>>>> paremeters available on a
>>>> certain platform by a string (parameter name) and
>>>> value pairs.
>>>> - to unregister operating point by name
>>>> - to set operating point by name
>>>> - to get values of arbitrary subset of platform power
>>>> parameters associated
>>>> this  a point (point is passed by name or NULL to get
>>>> current parameter values
>>>> from hw)
>>>
>>> I do not think this can work in notebook world, sorry.
>>> You'll just get
>>> way too many operating points.
>> The only feature for notebook world currently presented
>> in the kernel is CPUFreq. CPUFreq PowerOP integration
>
> Actually no. In the notebook world, we do cpufreq, selective powerdown
> of devices (/sys/**/power/state), and suspend-to-ram/disk (not sure if
> it applies to you, but at least some powerop versions wanted to
> replace that).


The main point is that you won't get too many operating points.  You 
will get the number of operating points the x86 port of PowerOP chooses 
to have.  In the cpufreq/PowerOP integration patches you get the same 
number of operating points you have today in cpufreq.   We query ACPI 
for the list or use the hardcoded table.  Also, if we provide a 
userspace API for creating operating points,  distro's can create 
additional operating points that make sense for some specific use cases 
they would like to optimize around.


Matt

Re: PowerOP, Intro 0/3

[Preece Scott-PREECE]

Hi, Matt,

Can you (and David, if his thoughts are different) clarify for me the
scope of the "arbitrary subset of power parameters" managed by PowerOP?

I had visualized this as managing CPU speed, voltage, and some
associated clock and bus speeds and voltages, as opposed to "devices",
though there would be some interaction with devices indirectly through
dependencies on specific speeds and voltages. I put "devices" in quotes
because it's a somewhat ambiguous - it covers both things that you would
normally think of as devices (like disk drives) and things that are
modeled by device drivers but are actually just part of the system
infrastructure (like the power management IC).

Put another way, I had been thinking of PowerOP as managing system-level
power control, but that device-level controls would still be layered on
that. Pavel's comments suggest that he thinks it would be managing
devices as well (thereby creating a state explosion).

What model did you have in mind?

Thanks,
scott

> -----Original Message-----
> From: linux-pm-bounces@lists.osdl.org 
> [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Matthew Locke
> Sent: Monday, August 28, 2006 2:38 AM
> To: Pavel Machek
> Cc: pm list
> Subject: Re: [linux-pm] PowerOP, Intro 0/3
> 
> 
> On Aug 26, 2006, at 1:38 PM, Pavel Machek wrote:
> 
> > Hi!
> >
> >>>> PowerOP Core upper layer interface provides the following 
> >>>> capabilities:
> >>>> - to register an operating point by passing an 
> idenificator of the 
> >>>> point represened by a string and arbitrary substet of power 
> >>>> paremeters available on a certain platform by a string 
> (parameter 
> >>>> name) and value pairs.
> >>>> - to unregister operating point by name
> >>>> - to set operating point by name
> >>>> - to get values of arbitrary subset of platform power parameters 
> >>>> associated this  a point (point is passed by name or NULL to get 
> >>>> current parameter values from hw)
> >>>
> >>> I do not think this can work in notebook world, sorry.
> >>> You'll just get
> >>> way too many operating points.
> >> The only feature for notebook world currently presented in 
> the kernel 
> >> is CPUFreq. CPUFreq PowerOP integration
> >
> > Actually no. In the notebook world, we do cpufreq, 
> selective powerdown 
> > of devices (/sys/**/power/state), and suspend-to-ram/disk 
> (not sure if 
> > it applies to you, but at least some powerop versions wanted to 
> > replace that).
> 
> 
> The main point is that you won't get too many operating 
> points.  You will get the number of operating points the x86 
> port of PowerOP chooses to have.  In the cpufreq/PowerOP 
> integration patches you get the same 
> number of operating points you have today in cpufreq.   We query ACPI 
> for the list or use the hardcoded table.  Also, if we provide 
> a userspace API for creating operating points,  distro's can 
> create additional operating points that make sense for some 
> specific use cases they would like to optimize around.
> 
> 
> Matt
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
> 

Re: PowerOP, Intro 0/3

[Matthew Locke]

Scott, Pavel,


On Aug 28, 2006, at 9:59 AM, Preece Scott-PREECE wrote:

> Hi, Matt,
>
> Can you (and David, if his thoughts are different) clarify for me the
> scope of the "arbitrary subset of power parameters" managed by PowerOP?

Scott does a pretty good job of clarifying, so my comments are below.

>
> I had visualized this as managing CPU speed, voltage, and some
> associated clock and bus speeds and voltages, as opposed to "devices",
> though there would be some interaction with devices indirectly through
> dependencies on specific speeds and voltages. I put "devices" in quotes
> because it's a somewhat ambiguous - it covers both things that you 
> would
> normally think of as devices (like disk drives) and things that are
> modeled by device drivers but are actually just part of the system
> infrastructure (like the power management IC).
>
> Put another way, I had been thinking of PowerOP as managing 
> system-level
> power control, but that device-level controls would still be layered on
> that. Pavel's comments suggest that he thinks it would be managing
> devices as well (thereby creating a state explosion).

> What model did you have in mind?
>

Basically, PowerOP is a building block for managing system-level power 
control as you describe.  Its for controlling bus, clocks, and voltages 
that affect the entire system.  Devices are not controlled directly by 
PowerOP.   Device state should be managed by the devices themselves and 
some other higher level software.  The connection between devices and 
powerop is not device state control; it is notification and 
constraints.

PowerOP does not automatically lead to an explosion of states/points.  
As you can see from the cpufreq patches, PowerOP provides the same 
number points currently available in cpufreq.  It gives the kernel 
developer and/or system designer the choice how to define the operating 
points.

> Thanks,
> scott
>
>> -----Original Message-----
>> From: linux-pm-bounces@lists.osdl.org
>> [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Matthew Locke
>> Sent: Monday, August 28, 2006 2:38 AM
>> To: Pavel Machek
>> Cc: pm list
>> Subject: Re: [linux-pm] PowerOP, Intro 0/3
>>
>>
>> On Aug 26, 2006, at 1:38 PM, Pavel Machek wrote:
>>
>>> Hi!
>>>
>>>>>> PowerOP Core upper layer interface provides the following
>>>>>> capabilities:
>>>>>> - to register an operating point by passing an
>> idenificator of the
>>>>>> point represened by a string and arbitrary substet of power
>>>>>> paremeters available on a certain platform by a string
>> (parameter
>>>>>> name) and value pairs.
>>>>>> - to unregister operating point by name
>>>>>> - to set operating point by name
>>>>>> - to get values of arbitrary subset of platform power parameters
>>>>>> associated this  a point (point is passed by name or NULL to get
>>>>>> current parameter values from hw)
>>>>>
>>>>> I do not think this can work in notebook world, sorry.
>>>>> You'll just get
>>>>> way too many operating points.
>>>> The only feature for notebook world currently presented in
>> the kernel
>>>> is CPUFreq. CPUFreq PowerOP integration
>>>
>>> Actually no. In the notebook world, we do cpufreq,
>> selective powerdown
>>> of devices (/sys/**/power/state), and suspend-to-ram/disk
>> (not sure if
>>> it applies to you, but at least some powerop versions wanted to
>>> replace that).
>>
>>
>> The main point is that you won't get too many operating
>> points.  You will get the number of operating points the x86
>> port of PowerOP chooses to have.  In the cpufreq/PowerOP
>> integration patches you get the same
>> number of operating points you have today in cpufreq.   We query ACPI
>> for the list or use the hardcoded table.  Also, if we provide
>> a userspace API for creating operating points,  distro's can
>> create additional operating points that make sense for some
>> specific use cases they would like to optimize around.
>>
>>
>> Matt
>>
>> _______________________________________________
>> linux-pm mailing list
>> linux-pm@lists.osdl.org
>> https://lists.osdl.org/mailman/listinfo/linux-pm
>>
>

Re: PowerOP, Intro 0/3

[David Singleton]

On 8/29/06, Matthew Locke <matt@nomadgs.com> wrote:
> Scott, Pavel,
>
>
> On Aug 28, 2006, at 9:59 AM, Preece Scott-PREECE wrote:
>
> > Hi, Matt,
> >
> > Can you (and David, if his thoughts are different) clarify for me the
> > scope of the "arbitrary subset of power parameters" managed by PowerOP?
>
> Scott does a pretty good job of clarifying, so my comments are below.
>
> >
> > I had visualized this as managing CPU speed, voltage, and some
> > associated clock and bus speeds and voltages, as opposed to "devices",
> > though there would be some interaction with devices indirectly through
> > dependencies on specific speeds and voltages. I put "devices" in quotes
> > because it's a somewhat ambiguous - it covers both things that you
> > would
> > normally think of as devices (like disk drives) and things that are
> > modeled by device drivers but are actually just part of the system
> > infrastructure (like the power management IC).
> >
> > Put another way, I had been thinking of PowerOP as managing
> > system-level
> > power control, but that device-level controls would still be layered on
> > that. Pavel's comments suggest that he thinks it would be managing
> > devices as well (thereby creating a state explosion).
>
> > What model did you have in mind?
> >
>
> Basically, PowerOP is a building block for managing system-level power
> control as you describe.  Its for controlling bus, clocks, and voltages
> that affect the entire system.  Devices are not controlled directly by
> PowerOP.   Device state should be managed by the devices themselves and
> some other higher level software.  The connection between devices and
> powerop is not device state control; it is notification and
> constraints.

Matt has it exactly right.
>
> PowerOP does not automatically lead to an explosion of states/points.
> As you can see from the cpufreq patches, PowerOP provides the same
> number points currently available in cpufreq.  It gives the kernel
> developer and/or system designer the choice how to define the operating
> points.

The possible combinations of system state and device state should be
managed by the power daemon.  The kernel should just provide the
services to put the system and devices into their supported states.  Policies
about combination to create and when to use them is the power managers
relm.

The difference between the designs is that the operating point definition
is defined at compile time in OpPoint greatly simplifying the code.

The power manager just manages system state by operating point name
and controls devices through the standard sysfs device interface.

David
>
> > Thanks,
> > scott
> >
> >> -----Original Message-----
> >> From: linux-pm-bounces@lists.osdl.org
> >> [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of Matthew Locke
> >> Sent: Monday, August 28, 2006 2:38 AM
> >> To: Pavel Machek
> >> Cc: pm list
> >> Subject: Re: [linux-pm] PowerOP, Intro 0/3
> >>
> >>
> >> On Aug 26, 2006, at 1:38 PM, Pavel Machek wrote:
> >>
> >>> Hi!
> >>>
> >>>>>> PowerOP Core upper layer interface provides the following
> >>>>>> capabilities:
> >>>>>> - to register an operating point by passing an
> >> idenificator of the
> >>>>>> point represened by a string and arbitrary substet of power
> >>>>>> paremeters available on a certain platform by a string
> >> (parameter
> >>>>>> name) and value pairs.
> >>>>>> - to unregister operating point by name
> >>>>>> - to set operating point by name
> >>>>>> - to get values of arbitrary subset of platform power parameters
> >>>>>> associated this  a point (point is passed by name or NULL to get
> >>>>>> current parameter values from hw)
> >>>>>
> >>>>> I do not think this can work in notebook world, sorry.
> >>>>> You'll just get
> >>>>> way too many operating points.
> >>>> The only feature for notebook world currently presented in
> >> the kernel
> >>>> is CPUFreq. CPUFreq PowerOP integration
> >>>
> >>> Actually no. In the notebook world, we do cpufreq,
> >> selective powerdown
> >>> of devices (/sys/**/power/state), and suspend-to-ram/disk
> >> (not sure if
> >>> it applies to you, but at least some powerop versions wanted to
> >>> replace that).
> >>
> >>
> >> The main point is that you won't get too many operating
> >> points.  You will get the number of operating points the x86
> >> port of PowerOP chooses to have.  In the cpufreq/PowerOP
> >> integration patches you get the same
> >> number of operating points you have today in cpufreq.   We query ACPI
> >> for the list or use the hardcoded table.  Also, if we provide
> >> a userspace API for creating operating points,  distro's can
> >> create additional operating points that make sense for some
> >> specific use cases they would like to optimize around.
> >>
> >>
> >> Matt
> >>
> >> _______________________________________________
> >> linux-pm mailing list
> >> linux-pm@lists.osdl.org
> >> https://lists.osdl.org/mailman/listinfo/linux-pm
> >>
> >
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>

Re: PowerOP, Intro 0/3

[Dominik Brodowski]

Matthew,

Nitpicking, I know, but:

On Tue, Aug 29, 2006 at 12:28:21AM -0700, Matthew Locke wrote:
> PowerOP does not automatically lead to an explosion of states/points.  
> As you can see from the cpufreq patches, PowerOP provides the same 
> number points currently available in cpufreq.

- Also the ~64.000 points[*] currently available in gx-suspmod.c ?
- Also the intervals + "mode" currently available in and for longrun.c ?

Thanks,
	Dominik


[*] rough calculation. Might be significantly lower, but it's definitely in
    the 1E5 area.

Re: PowerOP, Intro 0/3

[Vitaly Wool]

Hi Pavel,

> Workable solution would be to create power domains, and group devices
> into power domains.

what do you mean by power domain here? Is a power domain a set of
arbitrary chosen devices?
Do you think "operating point" operating with power domains and not
devices directly is an acceptable solution for your laptop? :)

Vitaly

Re: PowerOP, Intro 0/3

[Pavel Machek]

Hi!

> >Workable solution would be to create power domains, and group devices
> >into power domains.
> 
> what do you mean by power domain here? Is a power domain a set of
> arbitrary chosen devices?

Basically, yes. Set of devices, where power/frequency transitions need
to be coordinated between them.

> Do you think "operating point" operating with power domains and not
> devices directly is an acceptable solution for your laptop? :)

I guess it would be more like many different powerops for independend
pieces of hardware. And yes, that should work.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: PowerOP, Intro 0/3

[Vitaly Wool]

Hello Pavel,

On 8/26/06, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > >Workable solution would be to create power domains, and group devices
> > >into power domains.
> >
> > what do you mean by power domain here? Is a power domain a set of
> > arbitrary chosen devices?
>
> Basically, yes. Set of devices, where power/frequency transitions need
> to be coordinated between them.
>
> > Do you think "operating point" operating with power domains and not
> > devices directly is an acceptable solution for your laptop? :)
>
> I guess it would be more like many different powerops for independend
> pieces of hardware. And yes, that should work.

okay, this is just another layer of indirection which can be added
later. Why not reach a consensus here that PowerOP is basically fine,
probably needing to have power domain concept added (though there
might be some disagreement, I guess) and, consequently, start
integrating PowerOP into the mainline?

Vitaly