From: Dominik Brodowski <linux-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org
Subject: [PATCHES] add _CST support
Date: Sat, 27 Nov 2004 22:51:18 +0100 [thread overview]
Message-ID: <20041127215118.GA30309@dominikbrodowski.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
On top of the processor.c splitup patchset announced earlier today I've
rediffed, modified and split up the _CST patches originally developed by Bruno Ducrot
(i.e. the static approach, not my broken dynamic patch) and tracked at
http://bugme.osdl.org/show_bug.cgi?id=1958 .
A "bigdiff" which should apply cleanly on top of 2.6.10-rc2-mm3 is available at
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~176KB)
and zipped
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~36KB)
To apply the following individual patches, you first need the processor.c splitup patches:
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-processor-splitup-perflib
http://www.brodo.de/patches/2004-11-27/02-acpi-20041127-processor-splitup-throttling
http://www.brodo.de/patches/2004-11-27/03-acpi-20041127-processor-splitup-idle
http://www.brodo.de/patches/2004-11-27/04-acpi-20041127-processor-splitup-thermal
http://www.brodo.de/patches/2004-11-27/05-acpi-20041127-processor-splitup-core
http://www.brodo.de/patches/2004-11-27/06-acpi-20041127-throttling-disableirqsforshorterperiods
Please test + apply,
Dominik
http://www.brodo.de/patches/2004-11-27/07-acpi-20041127-cst-type
It's important to make a difference between the actual C-States and the
_type_ of the C-State. While they're always equal for ACPI 1.0 systems,
they can differ for ACPI 2.0 or later systems. Therefore, use _type_
wherever appropriate.
http://www.brodo.de/patches/2004-11-27/08-acpi-20041127-fadtpblk
Split up the extraction of information from the FADT and the pblk_address
(acpi_processor_get_power_info_fadt()) and the validation whether the state
is indeed available (acpi_processor_power_verify()).
http://www.brodo.de/patches/2004-11-27/09-acpi-20041127-power-remove-default-state
"default_state" is unused, so remove it.
http://www.brodo.de/patches/2004-11-27/10-acpi-20041127-make-power-state-a-pointer
Make the current "state" in struct acpi_processor_power a pointer. If it
doesn't exist, simply use C1 type sleep...
http://www.brodo.de/patches/2004-11-27/11-acpi-20041127-power-policy-independent-of-states
- make the state a pointer inside struct acpi_processor_cx_policy,
- make acpi_cstate_limit aware of c-state types instead of numbers, as the
latter mean (almost) nothing
- make the policy decisions of demotion and promotion independent of
the assumption "one state per type"
http://www.brodo.de/patches/2004-11-27/12-acpi-20041127-cst-parsing
Add parsing for _CST
http://www.brodo.de/patches/2004-11-27/13-acpi-20041127-cst-change
Add a notifier for _CST changing events. It is necessary to unload
the processor idle handle for a short period of time to avoid for nasty
races -- and we don't want to grab too many locks so that the idle handler
continues to be speedy.
http://www.brodo.de/patches/2004-11-27/14-acpi-20041127-cst-notify_smm
Notify the BIOS that we can handle _CST.
http://www.brodo.de/patches/2004-11-27/15-acpi-20041127-power-only-init-modify-exit
Consolidate code in processor_idle(). Only symbols "exported" are
_init(), _exit() and _cst_has_changed().
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2004-11-27 21:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-27 21:51 Dominik Brodowski [this message]
[not found] ` <20041127215118.GA30309-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-11-27 21:56 ` [PATCHES] add _CST support Dominik Brodowski
2004-12-22 5:44 ` Len Brown
2004-12-23 0:08 ` Dominik Brodowski
[not found] ` <20041223000842.GA8289-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-12-23 5:02 ` Len Brown
2004-12-23 13:07 ` Pavel Machek
[not found] ` <20041223130723.GE731-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org>
2004-12-28 3:27 ` Len Brown
2004-12-28 17:50 ` Dominik Brodowski
2004-12-28 21:28 ` Pavel Machek
2004-12-22 6:52 ` Len Brown
2004-12-22 20:37 ` Len Brown
2004-12-23 0:18 ` Dominik Brodowski
[not found] ` <20041223001830.GC8289-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-12-23 5:30 ` Len Brown
2004-12-23 0:10 ` Dominik Brodowski
[not found] ` <20041223001024.GB8289-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org>
2004-12-23 5:07 ` Len Brown
2004-12-22 7:22 ` Len Brown
2004-12-22 20:13 ` Len Brown
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=20041127215118.GA30309@dominikbrodowski.de \
--to=linux-x3ehhduj6siigcdfoqap7bvvk+yq3zxh@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/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