From: Dave Jones <davej@redhat.com>
To: Robert Love <rml@ximian.com>
Cc: Matthew Garrett <mgarrett@chiark.greenend.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: Laptops & CPU frequency
Date: Wed, 14 Jan 2004 04:59:45 +0000 [thread overview]
Message-ID: <20040114045945.GB23845@redhat.com> (raw)
In-Reply-To: <1073843690.1153.12.camel@localhost>
On Sun, Jan 11, 2004 at 12:54:51PM -0500, Robert Love wrote:
> On Sun, 2004-01-11 at 12:44, Matthew Garrett wrote:
>
> > Is there any realistic way of noticing this sort of change?
>
> Sure. That is how Speedstep works, right? We have an interface for
> Speedstep, so the kernel knows about it. We do not have an interface
> for the proprietary BIOS stuff, I assume, so the kernel is oblivious.
Speedstep support is one way right now. We tell the CPU "switch to this mode"
and it does. What we don't know how to do in cpufreq is detect when someone pulls
the power out, or plugs back in. BIOS SMM magick happens, and it all
gets taken care of transparently without us having a clue that anything
happened.
We *could* hook into the APM 'power source changed' notifiers, (and I
guess ACPI has something similar somewhere). That should take care of things.
> But if you had the docs, I suppose you could code a solution and tie it
> into the cpufreq code, just as we have proper support for Speedstep,
> Longrun, etc.
Of all the implementations I've played with (longhaul/powernow/speedstep-smi)
speedstep is the only one that does funky shit with SMM. The others are quite
dumb (and friendly) in comparison. (Ie, nothing happens on power source change)
Dave
next prev parent reply other threads:[~2004-01-14 5:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-11 2:56 Laptops & CPU frequency jlnance
2004-01-11 3:17 ` Robert Love
2004-01-11 4:12 ` Valdis.Kletnieks
2004-01-11 6:16 ` Willy Tarreau
2004-01-11 10:27 ` Xavier Bestel
2004-01-11 10:33 ` Xavier Bestel
2004-01-12 16:58 ` Jerry Cooperstein
2004-01-12 21:19 ` Xavier Bestel
2004-01-12 19:52 ` john stultz
2004-01-12 20:11 ` Disconnect
2004-01-12 23:19 ` john stultz
2004-01-12 21:28 ` Xavier Bestel
2004-01-12 22:07 ` john stultz
2004-01-13 9:13 ` Xavier Bestel
2004-01-11 17:06 ` Matthew Garrett
2004-01-11 17:13 ` Robert Love
2004-01-11 17:44 ` Matthew Garrett
2004-01-11 17:54 ` Robert Love
2004-01-14 4:59 ` Dave Jones [this message]
2004-01-14 19:11 ` Daniel Gryniewicz
2004-01-14 19:17 ` Robert Love
2004-01-14 19:23 ` Daniel Gryniewicz
2004-01-15 20:42 ` Pavel Machek
2004-01-15 21:18 ` Daniel Gryniewicz
2004-01-15 22:21 ` John Bradford
2004-01-15 22:48 ` Pavel Machek
2004-01-19 17:44 ` Ducrot Bruno
2004-01-16 10:47 ` Pavel Machek
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=20040114045945.GB23845@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgarrett@chiark.greenend.org.uk \
--cc=rml@ximian.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