From: Dominik Brodowski <linux@brodo.de>
To: paul.devriendt@AMD.com
Cc: pavel@suse.cz, richard.brunner@AMD.com, aj@suse.de,
cpufreq@www.linux.org.uk, davej@redhat.com,
mark.langsdorf@AMD.com
Subject: Re: ACPI P-State platform limit [Was: Re: Cpufreq for opteron]
Date: Fri, 5 Sep 2003 00:29:04 +0200 [thread overview]
Message-ID: <20030904222904.GA6488@brodo.de> (raw)
In-Reply-To: <20030827053300.GB4037@brodo.de>
On Wed, Aug 27, 2003 at 07:33:00AM +0200, Dominik Brodowski wrote:
> [removed CC:linux-kernel]
>
> > > I dislike this interaction between ACPI and cpufreq -- it
> > > should be done
> > > more generally. Let's discuss that seperately, though. And if
> > > the code is
> > > dead code at the moment.
> >
> > The dead code has been removed in 1.00.07 of the driver. I am
> > happy to receive suggestions as to better ways of detecting battery
> > versus mains power transitions.
>
> Currently, the ACPI P-States cpufreq driver does implement the "platform
> limit". However, I'm not really excited about how it works -- and especially
> that it only works with the ACPI P-States cpufreq driver and not with all
> drivers.
>
> The platform limit [ _PPC ] refers to the states defined in _PSS. This means
> that this knowledge can and should be used independent of the cpufreq driver:
> if the _PPC is, let's say, 2, and accoring to _PSS P2 is 1.2 GHz, a
> "platform limit CPUFREQ_POLICY_NOTIFIER". If the _PPC changes, a
> new cpufreq_reevaluate() function should be called:
I named it cpufreq_update_policy() instead, and you can check the
implementation for it and for the _PPC in:
http://www.brodo.de/cpufreq_tmp/cpufreq-2.6.0-test4-update_policy
and
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_perflib
Dominik
prev parent reply other threads:[~2003-09-04 22:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-27 0:43 Cpufreq for opteron paul.devriendt
2003-08-27 5:13 ` Dominik Brodowski
2003-09-04 10:00 ` Dominik Brodowski
2003-08-27 5:33 ` ACPI P-State platform limit [Was: Re: Cpufreq for opteron] Dominik Brodowski
2003-08-27 9:16 ` Ducrot Bruno
2003-09-04 22:29 ` Dominik Brodowski [this message]
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=20030904222904.GA6488@brodo.de \
--to=linux@brodo.de \
--cc=aj@suse.de \
--cc=cpufreq@www.linux.org.uk \
--cc=davej@redhat.com \
--cc=mark.langsdorf@AMD.com \
--cc=paul.devriendt@AMD.com \
--cc=pavel@suse.cz \
--cc=richard.brunner@AMD.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