From: Thomas Renninger <trenn@suse.de>
To: cpufreq@www.linux.org.uk
Cc: f.alabas@ttnet.net.tr
Subject: [PATCH] fix limited (_PPC) freq machines to get all freqs when booted on battery
Date: Sat, 10 Mar 2007 17:20:04 +0100 [thread overview]
Message-ID: <1173543604.7690.27.camel@linux-8rt8.site> (raw)
[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]
Hi,
on machines that limit frequency on battery you will get stuck to
limited frequency if cpufreq driver is loaded when running on battery
and (real) max frequency will never be reached again, even when AC is
plugged in.
That is because cpufreq_set_policy() calls verify(within_limits) where
policy->max gets limited. Then policy->user_policy.max (the value that
is
used to restore to real max_freq later) gets overridden with the limited
freq value.
This one should fix it.
I couldn't find where policy->policy gets initialized (a bad name
for grepping in cpufreq dir) therefore I just added:
+ policy->user_policy.policy = policy->policy;
after
__cpufreq_set_policy(policy, &new_policy);
It would be great if someone could verify this working,
as I only had access to such a machine for some time
(all machines that limit freq when running on battery should be
affected)...
What about throwing out cpufreq_set_policy totally?
It will always mess up max freq if called in limited condition and
should
not get exported (but just deleted).
The last func accessing it, is acpi_processor_write_performance() in
drivers/acpi/processor_perflib.c
This interface (/proc/acpi/processor/*/performance) is deprecated
and interferes with rest of cpufreq core...
Any chance this still can get removed for 2.6.21?
Thanks,
Thomas
Fix limited (_PPC) freq machines to get all freqs when booted on battery
On machines that limit frequency on battery you will get stuck to
limited frequency if cpufreq driver is loaded when running on battery
and (real) max frequency will never be reached again, even when AC is
plugged in.
---
drivers/cpufreq/cpufreq.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Index: linux-2.6.21-rc3/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.21-rc3.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.21-rc3/drivers/cpufreq/cpufreq.c
@@ -768,7 +768,10 @@ static int cpufreq_add_dev (struct sys_d
unlock_policy_rwsem_write(cpu);
goto err_out;
}
-
+ policy->user_policy.min = policy->cpuinfo.min_freq;
+ policy->user_policy.max = policy->cpuinfo.max_freq;
+ policy->user_policy.governor = policy->governor;
+
#ifdef CONFIG_SMP
for_each_cpu_mask(j, policy->cpus) {
if (cpu == j)
@@ -858,10 +861,13 @@ static int cpufreq_add_dev (struct sys_d
policy->governor = NULL; /* to assure that the starting sequence is
* run in cpufreq_set_policy */
- unlock_policy_rwsem_write(cpu);
/* set default policy */
- ret = cpufreq_set_policy(&new_policy);
+ ret = __cpufreq_set_policy(policy, &new_policy);
+ policy->user_policy.policy = policy->policy;
+
+ unlock_policy_rwsem_write(cpu);
+
if (ret) {
dprintk("setting policy failed\n");
goto err_out_unregister;
[-- Attachment #2: cpufreq_fix_ppc_onbattery_init.patch --]
[-- Type: text/x-patch, Size: 1461 bytes --]
Fix limited (_PPC) freq machines to get all freqs when booted on battery
On machines that limit frequency on battery you will get stuck to
limited frequency if cpufreq driver is loaded when running on battery
and (real) max frequency will never be reached again, even when AC is
plugged in.
---
drivers/cpufreq/cpufreq.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Index: linux-2.6.21-rc3/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.21-rc3.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.21-rc3/drivers/cpufreq/cpufreq.c
@@ -768,7 +768,10 @@ static int cpufreq_add_dev (struct sys_d
unlock_policy_rwsem_write(cpu);
goto err_out;
}
-
+ policy->user_policy.min = policy->cpuinfo.min_freq;
+ policy->user_policy.max = policy->cpuinfo.max_freq;
+ policy->user_policy.governor = policy->governor;
+
#ifdef CONFIG_SMP
for_each_cpu_mask(j, policy->cpus) {
if (cpu == j)
@@ -858,10 +861,13 @@ static int cpufreq_add_dev (struct sys_d
policy->governor = NULL; /* to assure that the starting sequence is
* run in cpufreq_set_policy */
- unlock_policy_rwsem_write(cpu);
/* set default policy */
- ret = cpufreq_set_policy(&new_policy);
+ ret = __cpufreq_set_policy(policy, &new_policy);
+ policy->user_policy.policy = policy->policy;
+
+ unlock_policy_rwsem_write(cpu);
+
if (ret) {
dprintk("setting policy failed\n");
goto err_out_unregister;
[-- Attachment #3: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
reply other threads:[~2007-03-10 16:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1173543604.7690.27.camel@linux-8rt8.site \
--to=trenn@suse.de \
--cc=cpufreq@www.linux.org.uk \
--cc=f.alabas@ttnet.net.tr \
/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.