From: Pavel Machek <pavel@ucw.cz>
To: Todd Poynor <tpoynor@mvista.com>
Cc: linux-pm@lists.osdl.org, linux-kernel@vger.kernel.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>
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
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
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
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: 18+ 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 2:49 ` Todd Poynor
2005-08-09 18:12 ` Patrick Mochel
2005-08-09 18:12 ` [linux-pm] " Patrick Mochel
2005-08-10 2:18 ` Todd Poynor
2005-08-10 2:18 ` [linux-pm] " Todd Poynor
2005-08-09 3:00 ` Todd Poynor
2005-08-16 8:53 ` Dominik Brodowski
2005-08-16 8:53 ` Dominik Brodowski
2005-08-16 8:57 ` 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-25 3:02 ` Todd Poynor
2005-08-10 10:07 ` Pavel Machek [this message]
2005-08-10 10:07 ` Pavel Machek
2005-08-10 22:02 ` Todd Poynor
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.