From: "Eugeny S. Mints" <eugeny.mints@gmail.com>
To: pm list <linux-pm@lists.osdl.org>
Cc: Matthew Locke <matt@nomadgs.com>,
Amit Kucheria <amit.kucheria@nokia.com>,
Igor Stoppa <igor.stoppa@nokia.com>,
kernel list <linux-kernel@vger.kernel.org>
Subject: [RFC] CPUFreq PowerOP integration, Intro 0/3
Date: Thu, 14 Sep 2006 18:42:26 +0400 [thread overview]
Message-ID: <45096A52.40706@gmail.com> (raw)
Integrating CPUFreq and PowerOP was discussed at the Linux PM summit
and in recent emails exchanges. Some say keep them separate and some
say they must be integrated. There is actually a very natural point
where integration makes sense - cpufreq_driver. This patchset presents
that integration point and is submitted for discussion.
The patches do not change the functionality of the cpufreq core.
Instead the idea is to redesign the tightly coupled interfaces of
cpufreq to clearly separate the arch dependent and independent pieces
layers. This enables cpufreq to become arch independent and can start
to use the named operating points in all its layers.
PowerOP replaces cpufreq driver as the h/w independent interface for
operating points. PM core handles the h/w specific details for
defining the power parameters and setting the power parameters in h/w
registers. Operating point definition/registration is now independent
of cpufreq.
Please note, that all userspace/kernel governor concepts, legacy sysfs cpufreq
interface remain untouched and SMP case is accounted in the resulting code as
well.
Highlights:
cpufreq.c
- get rid of cpufreq driver calls. the calls are replaced be calls to arch
independent freq_helpers (freq_helpers.c)
- available frequencies sysfs interface now can be handled in arch independent
way
- cpufreq_sysdev_driver now serves only cpufreq core internal needs upon cpu
add/remove events (since all hw related is handled by PM Core)
- cpufreq_powerop_call() is added to handle operating point registration in the
kernel by an independent module at arbitrary moment
freq_table.c (now freq_helpers.c)
- get rid of cpufreq_frequency_table structures as input parameter and made the
code arch independent by leveraging PowerOP interface
- routine remain the same but are no longer used by arch dependent code but by
cpufreq core arch independent code instead
- all routines are arch independent; the only shared knowledge is platform
power parameter names (string)
- target() method expects power parameter names "freqN", "vN" are supported by
PM Core for cpu N
- setpolisy() method expects power parameter names "hfreqN", "lfreqN", "vN" are
supported by PM Core for cpu N
next reply other threads:[~2006-09-14 14:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 14:42 Eugeny S. Mints [this message]
2006-10-07 3:19 ` [RFC] CPUFreq PowerOP integration, Intro 0/3 Dominik Brodowski
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=45096A52.40706@gmail.com \
--to=eugeny.mints@gmail.com \
--cc=amit.kucheria@nokia.com \
--cc=igor.stoppa@nokia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=matt@nomadgs.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