All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: cpufreq@lists.linux.org.uk
Subject: Re: [Bug 8581] acpi-cpufreq gets very confused on suspend to ram
Date: Mon, 22 Oct 2007 09:50:13 +0200	[thread overview]
Message-ID: <87640zr3ka.fsf@denkblock.local> (raw)
In-Reply-To: <20071022002423.3FC91108014@picon.linux-foundation.org> (bugme-daemon@bugzilla.kernel.org's message of "Sun, 21 Oct 2007 17:24:23 -0700 (PDT)")

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8581
>
>
> davej@codemonkey.org.uk changed:
[...]
> ------- Comment #8 from davej@codemonkey.org.uk  2007-10-21 17:24 -------
> there's some whitespace damage in this patch (spaces instead of tabs).
> Asides from that though, it looks like the right thing to do.
> Can you fix that up, and bounce a copy to cpufreq@www.linux.org.uk please?

Well, since this patch was mainly a copy-and-paste job from
cpufreq_userspace.c, the whitespace damages have been inherited once. In
fact, I have stumbled upon some more whitespace issues in in the cpufreq
subsystem and there are also some problems with lacking whitespace
causing misprinted debugging messages. If you're interested, I can come
up with a patch fixing all those problems I've accidentally come across.

Here is the patch fixing cpufreq_conservative.c anyway. It applies to
2.6.23.

Regards,

Elias

--------

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: conservative-handle-resume-2.patch --]
[-- Type: text/x-patch, Size: 2115 bytes --]

Make cpufreq_conservative handle out-of-sync events properly

Currently, the cpufreq_conservative governor doesn't get notified when the
actual frequency the cpu is running at differs from what cpufreq thought it
was. As a result the cpu may stay at the maximum frequency after a s2ram /
resume cycle even though the system is idle.

Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
---

 drivers/cpufreq/cpufreq_conservative.c |   32 ++++++++++++++++++++++++++++++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index 26f440c..7ad91d2 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -116,6 +116,27 @@ static inline unsigned int get_cpu_idle_
 	return ret;
 }
 
+/* keep track of frequency transitions */
+static int
+dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
+		     void *data)
+{
+	struct cpufreq_freqs *freq = data;
+	struct cpu_dbs_info_s *this_dbs_info = &per_cpu(cpu_dbs_info,
+							freq->cpu);
+
+	if (!this_dbs_info->enable)
+		return 0;
+
+	this_dbs_info->requested_freq = freq->new;
+
+	return 0;
+}
+
+static struct notifier_block dbs_cpufreq_notifier_block = {
+	.notifier_call = dbs_cpufreq_notifier
+};
+
 /************************** sysfs interface ************************/
 static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
 {
@@ -514,6 +535,9 @@ static int cpufreq_governor_dbs(struct c
 			dbs_tuners_ins.sampling_rate = def_sampling_rate;
 
 			dbs_timer_init();
+			cpufreq_register_notifier(
+					&dbs_cpufreq_notifier_block,
+					CPUFREQ_TRANSITION_NOTIFIER);
 		}
 		
 		mutex_unlock(&dbs_mutex);
@@ -528,9 +552,13 @@ static int cpufreq_governor_dbs(struct c
 		 * Stop the timerschedule work, when this governor
 		 * is used for first time
 		 */
-		if (dbs_enable == 0) 
+		if (dbs_enable == 0) {
 			dbs_timer_exit();
-		
+			cpufreq_unregister_notifier(
+					&dbs_cpufreq_notifier_block,
+					CPUFREQ_TRANSITION_NOTIFIER);
+		}
+
 		mutex_unlock(&dbs_mutex);
 
 		break;

[-- 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-10-22  7:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-8581-3570@http.bugzilla.kernel.org/>
2007-08-08 17:04 ` [Bug 8581] acpi-cpufreq gets very confused on suspend to ram bugme-daemon
2007-09-23 12:26 ` bugme-daemon
2007-10-06 15:38 ` bugme-daemon
2007-10-08 13:47 ` bugme-daemon
2007-10-12 19:48 ` bugme-daemon
2007-10-21 13:13 ` bugme-daemon
2007-10-22  0:24 ` bugme-daemon
2007-10-22  7:50   ` Elias Oltmanns [this message]
2007-10-22 20:49     ` Dave Jones
2007-06-04 16:45 bugme-daemon
  -- strict thread matches above, loose matches on Subject: below --
2007-06-04 12:38 bugme-daemon

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=87640zr3ka.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=cpufreq@lists.linux.org.uk \
    /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.