From: Pavel Machek <pavel@ucw.cz>
To: Todd Poynor <tpoynor@mvista.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@lists.osdl.org,
cpufreq@www.linux.org.uk
Subject: Re: PowerOP 0/3: System power operating point management API
Date: Wed, 10 Aug 2005 12:07:18 +0200 [thread overview]
Message-ID: <20050810100718.GC1945@elf.ucw.cz> (raw)
In-Reply-To: <20050809024907.GA25064@slurryseal.ddns.mvista.com>
Hi!
> PowerOP is a system power parameter management API submitted for
> discussion. PowerOP writes and reads power "operating points",
> comprised of arbitrary integer-valued values, called power parameters,
> that correspond to registers, clocks, dividers, voltage regulators,
> etc. that may be modified to set a basic power/performance point for the
> system. The core basically passes an array of integer-valued power
> parameters (with very little additional structure imposed by the core)
> to a platform-specific backend that interprets those values and makes
> the requested adjustments. PowerOP is intended to leave all power
> policy decisions to higher layers. An optional sysfs representation of
> power parameters is also available, primarily for diagnostic use.
>
> PowerOP can be thought of as a layer below cpufreq that actually
> accesses the hardware to make cpu frequency, voltage, core bus, and
> perhaps other modifications to set a power point, leaving cpufreq to
> manage the interfaces based around the "cpu frequency" abstraction, the
> policies and governors that select the frequency, its notifiers, and so
> forth. An example hooking up support for one cpufreq platform to
> PowerOP is in patch 3/3.
>
> Depending on the ability of the hardware to make software-controlled
> power/performance adjustments, this may be useful to select custom
> voltages, bus speeds, etc. in desktop/server systems. Various embedded
> systems have several parameters that can be set. For example, an XScale
> PXA27x could be considered to have six basic power parameters (mainly
> cpu run mode and memory and bus dividers) that for the most part
> should
This scares me a bit. Is table enough to handle this? I'm afraid that
table will get very large on systems that allow you to do "almost
anything".
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
next prev parent reply other threads:[~2005-08-10 10:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-09 2:49 PowerOP 0/3: System power operating point management API Todd Poynor
2005-08-09 18:12 ` [linux-pm] " Patrick Mochel
2005-08-10 2:18 ` Todd Poynor
[not found] ` <20050809030000.GA25112@slurryseal.ddns.mvista.com>
2005-08-16 8:53 ` Dominik Brodowski
2005-08-16 8:57 ` Dominik Brodowski
2005-08-17 1:52 ` Todd Poynor
2005-08-17 1:39 ` Todd Poynor
2005-08-10 10:07 ` Pavel Machek [this message]
2005-08-10 22:02 ` Todd Poynor
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=20050810100718.GC1945@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=cpufreq@www.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=tpoynor@mvista.com \
/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