From: Thomas Renninger <mail@renninger.de>
To: cpufreq@lists.linux.org.uk
Cc: Dominik Brodowski <linux@dominikbrodowski.de>
Subject: DELL 600/800 - PPC frequency change issues
Date: Thu, 19 Jan 2006 18:59:22 +0100 [thread overview]
Message-ID: <43CFD37A.1040402@renninger.de> (raw)
When unplugging the AC adapter on these machines
following happens in BIOS:
- ACPI processor event fired, frequencies get limited
to the lowest one(600 MHz) and BIOS already sets lowest freq.
- when waiting about 10 seconds another ACPI processor
event is fired, and all frequencies are available again,
highest freq(1700 MHz) is set.
- when plugging in ac adapter before waiting 10 seconds
ACPI processor event is happening immediately and all
frequencies are available again, highest freq(1700 MHz) is set.
I found these bugs in kernel:
- speedstep centrino driver does not recognise that BIOS
changed the frequency behind it's back.
It tells you that 600 MHz are already set, and does not invoke
PRE/POST transition validation.
On next frequency settings, the frequency is "out_of_sync" and
the validater assumes 600 MHz and the frequency stays there.
Not sure, maybe it stayed on 600 because of next bug or both, still
the "out_of_sync" is valid and should be handled gracefully:
Patch [1/2]
- userspace governor is using its own cpufreq_policy struct and
forgets to set max_frequency there in
cpufreq_governor_userspace(CPUFREQ_GOV_LIMITS)
That results in scaling_setspeed staying high in sysfs even the
frequency has been lowered on _PPC change.
When _PPC allows all frequencies again, the userspace governor
uses it's own policy_struct with the old max value again (now the
low one) and the frequency still stays at lowest frequency.
Patch [2/2]
I tested with ondemand and userspace governor on a speedstep-centrino
system, both governors had problems with but should work fine with _PPC
changes whether the BIOS prechanges the freq or not.
Could someone please review.
Thanks,
Thomas
reply other threads:[~2006-01-19 17:59 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=43CFD37A.1040402@renninger.de \
--to=mail@renninger.de \
--cc=cpufreq@lists.linux.org.uk \
--cc=linux@dominikbrodowski.de \
/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.