From: Dominik Brodowski <linux@brodo.de>
To: acpi-devel@lists.sourceforge.net, andrew.grover@intel.com
Cc: cpufreq@www.linux.org.uk
Subject: [PATCHES] ACPI Processor update [idle,throttling,thermal,cpufreq]
Date: Fri, 5 Sep 2003 00:24:34 +0200 [thread overview]
Message-ID: <20030904222434.GC6350@brodo.de> (raw)
Over the last few hours, I've rewritten large portions of ACPI processor
handling. Due to lack of appropriate hardware, I can hardly test these
changes, so expect a few rough edges.
These patches
- a) replace the broken ACPI CPUfreq driver with a better, flexible variant,
- b) modularize the processor.c code: instead of one large file there are
many small files.
- c) improve passive cooling support
- d) allow for easy adding of proper locking and ref-counting in processor.c
http://www.brodo.de/cpufreq_tmp/cpufreq-2.6.0-test4-ALL-series1
Large CPUfreq update -- needed for other changes
[in CPUfreq BK tree, merge with Linus expected soon]
http://www.brodo.de/cpufreq_tmp/cpufreq-2.6.0-test4-update_policy
http://www.brodo.de/cpufreq_tmp/cpufreq-2.6.0-test4-Kconfig-speedstep
Additional CPUfreq updates -- needed for other changes
[Already sent to CPUfreq list]
http://www.brodo.de/cpufreq_tmp/drivermodel-2.6.0-test4-exports
Missing EXPORTs in sysdevice -- needed for other changes
[Already sent to Patrick]
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-remove_previous_pstates_implementation
The previous arch/i386/kernel/cpu/cpufreq/acpi.c CPUfreq
driver was broken, of bad design, and needs to replaced
by something better. But, as a first step, remove all
parts related to P-States from ACPI code.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_submodules
Add a "submodule interface" to drivers/acpi/processor.c
It allows to create other "modules" which access the acpi_handle
for the processor, and which get notified if the event value
maches the value passed in acpi_processor_register_notify.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_perflib
This patch adds a new "P-States library" to drivers/acpi/
CPUfreq drivers can now easly access the contents of the
_PCT and the _PSS. For example, the speedstep-centrino
driver could be appended so that it passes the appropriate
value to the P-States library which then evaluates _PDC,
and then returns the updated _PCT and _PSS.
Also, the platform limit is now handled as a cpufreq notifier and
as a call to cpufreq_policy_update.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-new_acpi_io_driver
This re-adds the acpi P-States I/O driver. It is much smaller,
leaner and cleaner.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_idle_submodule
This moves the idle handler out of drivers/acpi/processor and into
an own module.
Even if only C1 is available, it is now used. If the user prefers the
default pm_idle, he can unload processor_idle, and still have the other
functionality available.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_thermal_submodule
This adds a new mechanism to manage passive cooling. Instead of
hardcoded -and partly wrong- access to CPUfreq and ACPI
throttling-, add a generic mechanism which other modules can
register with.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_thermal_cpufreq
Use _any_ CPUfreq driver for passive cooling. Implemented by an
cpufreq policy notifier and cpufreq_update_policy.
http://www.brodo.de/cpufreq_tmp/acpi-2.6.0-test4-processor_thermal_throttling
Move throttling into its own submodule, and register it with the new
passive cooling module. Also, the now-useless "limit" interface is
removed.
Please review, test (carefully), and -if appropriate- merge,
Dominik
next reply other threads:[~2003-09-04 22:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-04 22:24 Dominik Brodowski [this message]
2003-09-05 5:23 ` [ACPI] [PATCHES] ACPI Processor update [idle, throttling, thermal, cpufreq] Dmitry Torokhov
2003-09-05 6:52 ` Dominik Brodowski
2003-09-08 13:29 ` Pavel Machek
2003-09-09 17:21 ` linux
2003-09-09 23:13 ` Pavel Machek
2003-09-09 23:29 ` linux
2003-09-10 0:00 ` 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=20030904222434.GC6350@brodo.de \
--to=linux@brodo.de \
--cc=acpi-devel@lists.sourceforge.net \
--cc=andrew.grover@intel.com \
--cc=cpufreq@www.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox