cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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