From: "Eugeny S. Mints" <eugeny.mints@gmail.com>
To: pm list <linux-pm@lists.osdl.org>
Subject: PowerOP, Intro 0/3
Date: Thu, 24 Aug 2006 05:08:30 +0400 [thread overview]
Message-ID: <44ECFC0E.10803@gmail.com> (raw)
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.
next reply other threads:[~2006-08-24 1:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 1:08 Eugeny S. Mints [this message]
2006-08-26 8:28 ` PowerOP, Intro 0/3 Pavel Machek
2006-08-25 18:11 ` Eugeny S. Mints
2006-08-26 20:38 ` Pavel Machek
2006-08-27 21:34 ` Eugeny S. Mints
2006-08-28 17:34 ` Pavel Machek
2006-08-28 7:37 ` Matthew Locke
2006-08-28 16:59 ` Preece Scott-PREECE
2006-08-29 7:28 ` Matthew Locke
2006-08-29 15:42 ` David Singleton
2006-10-05 3:26 ` Dominik Brodowski
2006-08-26 13:43 ` Vitaly Wool
2006-08-26 13:55 ` Pavel Machek
2006-08-29 18:56 ` Vitaly Wool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44ECFC0E.10803@gmail.com \
--to=eugeny.mints@gmail.com \
--cc=linux-pm@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox