#
6b8e288f |
| 04-Mar-2024 |
He Rongguang <herongguang@linux.alibaba.com> |
cpuidle: ACPI/intel: fix MWAIT hint target C-state computation
According to x86 spec ([1] and [2]), MWAIT hint_address[7:4] plus 1 is the corresponding C-state, and 0xF means C0.
ACPI C-state table
cpuidle: ACPI/intel: fix MWAIT hint target C-state computation
According to x86 spec ([1] and [2]), MWAIT hint_address[7:4] plus 1 is the corresponding C-state, and 0xF means C0.
ACPI C-state table usually only contains C1+, but nothing prevents ACPI firmware from presenting a C-state (maybe C1+) but using MWAIT address C0 (i.e., 0xF in ACPI FFH MWAIT hint address). And if this is the case, Linux erroneously treat this cstate as C16, while actually this should be valid C0 instead of C16, as per the specifications.
Since ACPI firmware is out of Linux kernel scope, fix the kernel handling of 0xF ->(to) C0 in this situation. This is found when a tweaked ACPI C-state table is presented by Qemu to VM.
Also modify the intel_idle case for code consistency.
[1]. Intel SDM Vol 2, Table 4-11. MWAIT Hints Register (EAX): "Value of 0 means C1; 1 means C2 and so on Value of 01111B means C0".
[2]. AMD manual Vol 3, MWAIT: "The processor C-state is EAX[7:4]+1, so to request C0 is to place the value F in EAX[7:4] and to request C1 is to place the value 0 in EAX[7:4].".
Signed-off-by: He Rongguang <herongguang@linux.alibaba.com> [ rjw: Subject and changelog edits, whitespace fixups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
dacca1e5 |
| 07-Nov-2022 |
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> |
x86/acpi/cstate: Optimize ARB_DISABLE on Centaur CPUs
On all recent Centaur platforms, ARB_DISABLE is handled by PMU automatically while entering C3 type state. No need for OS to issue the ARB_DISAB
x86/acpi/cstate: Optimize ARB_DISABLE on Centaur CPUs
On all recent Centaur platforms, ARB_DISABLE is handled by PMU automatically while entering C3 type state. No need for OS to issue the ARB_DISABLE, so set bm_control to zero to indicate that.
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/all/1667792089-4904-1-git-send-email-TonyWWang-oc%40zhaoxin.com
show more ...
|
#
a8fb4096 |
| 24-Sep-2021 |
Deepak Sharma <deepak.sharma@amd.com> |
x86: ACPI: cstate: Optimize C3 entry on AMD CPUs
All Zen or newer CPU which support C3 shares cache. Its not necessary to flush the caches in software before entering C3. This will cause drop in per
x86: ACPI: cstate: Optimize C3 entry on AMD CPUs
All Zen or newer CPU which support C3 shares cache. Its not necessary to flush the caches in software before entering C3. This will cause drop in performance for the cores which share some caches. ARB_DIS is not used with current AMD C state implementation. So set related flags correctly.
Signed-off-by: Deepak Sharma <deepak.sharma@amd.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
280b68a3 |
| 28-May-2021 |
Pu Wen <puwen@hygon.cn> |
x86/cstate: Allow ACPI C1 FFH MWAIT use on Hygon systems
Hygon systems support the MONITOR/MWAIT instructions and these can be used for ACPI C1 in the same way as on AMD and Intel systems.
The BIOS
x86/cstate: Allow ACPI C1 FFH MWAIT use on Hygon systems
Hygon systems support the MONITOR/MWAIT instructions and these can be used for ACPI C1 in the same way as on AMD and Intel systems.
The BIOS declares a C1 state in _CST to use FFH and CPUID_Fn00000005_EDX is non-zero on Hygon systems.
Allow ffh_cstate_init() to succeed on Hygon systems to default using FFH MWAIT instead of HALT for ACPI C1.
Signed-off-by: Pu Wen <puwen@hygon.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210528081417.31474-1-puwen@hygon.cn
show more ...
|
#
696ac2e3 |
| 03-Apr-2020 |
Qian Cai <cai@lca.pw> |
x86: ACPI: fix CPU hotplug deadlock
Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug deadlock") except this is for acpi_processor_ffh_cstate_probe():
"The problem is that the wo
x86: ACPI: fix CPU hotplug deadlock
Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug deadlock") except this is for acpi_processor_ffh_cstate_probe():
"The problem is that the work is scheduled on the current CPU from the hotplug thread associated with that CPU.
It's not required to invoke these functions via the workqueue because the hotplug thread runs on the target CPU already.
Check whether current is a per cpu thread pinned on the target CPU and invoke the function directly to avoid the workqueue."
WARNING: possible circular locking dependency detected ------------------------------------------------------ cpuhp/1/15 is trying to acquire lock: ffffc90003447a28 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: __flush_work+0x4c6/0x630
but task is already holding lock: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x3e/0xc0 irq_calc_affinity_vectors+0x5f/0x91 __pci_enable_msix_range+0x10f/0x9a0 pci_alloc_irq_vectors_affinity+0x13e/0x1f0 pci_alloc_irq_vectors_affinity at drivers/pci/msi.c:1208 pqi_ctrl_init+0x72f/0x1618 [smartpqi] pqi_pci_probe.cold.63+0x882/0x892 [smartpqi] local_pci_probe+0x7a/0xc0 work_for_cpu_fn+0x2e/0x50 process_one_work+0x57e/0xb90 worker_thread+0x363/0x5b0 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50
-> #0 ((work_completion)(&wfc.work)){+.+.}-{0:0}: __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50
other info that might help us debug this:
Chain exists of: (work_completion)(&wfc.work) --> cpuhp_state-up --> cpuidle_lock
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(cpuidle_lock); lock(cpuhp_state-up); lock(cpuidle_lock); lock((work_completion)(&wfc.work));
*** DEADLOCK ***
3 locks held by cpuhp/1/15: #0: ffffffffaf51ab10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #1: ffffffffaf51ad40 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #2: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20
Call Trace: dump_stack+0xa0/0xea print_circular_bug.cold.52+0x147/0x14c check_noncircular+0x295/0x2d0 __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50
Signed-off-by: Qian Cai <cai@lca.pw> Tested-by: Borislav Petkov <bp@suse.de> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
f8c0e061 |
| 18-Jun-2019 |
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> |
x86/acpi/cstate: Add Zhaoxin processors support for cache flush policy in C3
Same as Intel, Zhaoxin MP CPUs support C3 share cache and on all recent Zhaoxin platforms ARB_DISABLE is a nop. So set re
x86/acpi/cstate: Add Zhaoxin processors support for cache flush policy in C3
Same as Intel, Zhaoxin MP CPUs support C3 share cache and on all recent Zhaoxin platforms ARB_DISABLE is a nop. So set related flags correctly in the same way as Intel does.
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: "hpa@zytor.com" <hpa@zytor.com> Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> Cc: "rjw@rjwysocki.net" <rjw@rjwysocki.net> Cc: "lenb@kernel.org" <lenb@kernel.org> Cc: David Wang <DavidWang@zhaoxin.com> Cc: "Cooper Yan(BJ-RD)" <CooperYan@zhaoxin.com> Cc: "Qiyuan Wang(BJ-RD)" <QiyuanWang@zhaoxin.com> Cc: "Herry Yang(BJ-RD)" <HerryYang@zhaoxin.com> Link: https://lkml.kernel.org/r/a370503660994669991a7f7cda7c5e98@zhaoxin.com
show more ...
|
#
457c8996 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier for missed files
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was use
treewide: Add SPDX license identifier for missed files
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
987ddbe4 |
| 27-Dec-2018 |
David Wang <davidwang@zhaoxin.com> |
x86/power: Optimize C3 entry on Centaur CPUs
For new Centaur CPUs the ucode will take care of the preservation of cache coherence between CPU cores in C-states regardless of how deep the C-states ar
x86/power: Optimize C3 entry on Centaur CPUs
For new Centaur CPUs the ucode will take care of the preservation of cache coherence between CPU cores in C-states regardless of how deep the C-states are. So, it is not necessary to flush the caches in software befor entering C3. This useless operation will cause performance drop for the cores which share some caches with the idling core.
Signed-off-by: David Wang <davidwang@zhaoxin.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: brucechang@via-alliance.com Cc: cooperyan@zhaoxin.com Cc: len.brown@intel.com Cc: linux-pm@kernel.org Cc: qiyuanwang@zhaoxin.com Cc: rjw@rjwysocki.net Cc: timguo@zhaoxin.com Link: http://lkml.kernel.org/r/1545900110-2757-1-git-send-email-davidwang@zhaoxin.com [ Tidy up the comment. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
3d95b89e |
| 13-Aug-2018 |
Prarit Bhargava <prarit@redhat.com> |
x86/ACPI/cstate: Make APCI C1 FFH MWAIT C-state description vendor-neutral
Commit 5209654a46ee (x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems) forgot to update the ACPI C1 idle state d
x86/ACPI/cstate: Make APCI C1 FFH MWAIT C-state description vendor-neutral
Commit 5209654a46ee (x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems) forgot to update the ACPI C1 idle state description and tools like turbostat display "ACPI FFH INTEL MWAIT 0x0" which is quite confusing on an AMD system.
Drop the "INTEL" part from the ACPI C1 FFH MWAIT C-state description to avoid confusion.
Fixes: 5209654a46ee (x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems) Signed-off-by: Prarit Bhargava <prarit@redhat.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
5209654a |
| 07-Jun-2017 |
Yazen Ghannam <yazen.ghannam@amd.com> |
x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems
AMD systems support the Monitor/Mwait instructions and these can be used for ACPI C1 in the same way as on Intel systems.
Three things ar
x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems
AMD systems support the Monitor/Mwait instructions and these can be used for ACPI C1 in the same way as on Intel systems.
Three things are needed: 1) This patch. 2) BIOS that declares a C1 state in _CST to use FFH, with correct values. 3) CPUID_Fn00000005_EDX is non-zero on the system.
The BIOS on AMD systems have historically not defined a C1 state in _CST, so the acpi_idle driver uses HALT for ACPI C1.
Currently released systems have CPUID_Fn00000005_EDX as reserved/RAZ. If a BIOS is released for these systems that requests a C1 state with FFH, the FFH implementation in Linux will fail since CPUID_Fn00000005_EDX is 0. The acpi_idle driver will then fallback to using HALT for ACPI C1.
Future systems are expected to have non-zero CPUID_Fn00000005_EDX and BIOS support for using FFH for ACPI C1.
Allow ffh_cstate_init() to succeed on AMD systems.
Tested on Fam15h and Fam17h systems.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
2dc8ffad |
| 12-Dec-2016 |
Nick Desaulniers <nick.desaulniers@gmail.com> |
ACPI / idle: small formatting fixes
A quick cleanup with scripts/checkpatch.pl -f <file>.
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-o
ACPI / idle: small formatting fixes
A quick cleanup with scripts/checkpatch.pl -f <file>.
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
6727ad9e |
| 08-Oct-2016 |
Chris Metcalf <cmetcalf@mellanox.com> |
nmi_backtrace: generate one-line reports for idle cpus
When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messag
nmi_backtrace: generate one-line reports for idle cpus
When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messages for cpus that are idling when they are interrupted and just emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
We do this by grouping all the cpuidle code together into a new .cpuidle.text section, and then checking the address of the interrupted PC to see if it lies within that section.
This commit suitably tags x86 and tile idle routines, and only adds in the minimal framework for other architectures.
Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Tested-by: Petr Mladek <pmladek@suse.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
186f4360 |
| 14-Jul-2016 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
x86/kernel: Audit and remove any unnecessary uses of module.h
Historically a lot of these existed because we did not have a distinction between what was modular code and what was providing support t
x86/kernel: Audit and remove any unnecessary uses of module.h
Historically a lot of these existed because we did not have a distinction between what was modular code and what was providing support to modules via EXPORT_SYMBOL and friends. That changed when we forked out support for the latter into the export.h file.
This means we should be able to reduce the usage of module.h in code that is obj-y Makefile or bool Kconfig. The advantage in doing so is that module.h itself sources about 15 other headers; adding significantly to what we feed cpp, and it can obscure what headers we are effectively using.
Since module.h was the source for init.h (for __init) and for export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance for the presence of either and replace as needed. Build testing revealed some implicit header usage that was fixed up accordingly.
Note that some bool/obj-y instances remain since module.h is the header for some exception table entry stuff, and for things like __init_or_module (code that is tossed when MODULES=n).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
2194324d |
| 14-Feb-2014 |
Len Brown <len.brown@intel.com> |
ACPI idle: permit sparse C-state sub-state numbers
Linux uses CPUID.MWAIT.EDX to validate the C-states reported by ACPI, silently discarding states which are not supported by the HW.
This test is t
ACPI idle: permit sparse C-state sub-state numbers
Linux uses CPUID.MWAIT.EDX to validate the C-states reported by ACPI, silently discarding states which are not supported by the HW.
This test is too restrictive, as some HW now uses sparse sub-state numbering, so the sub-state number may be higher than the number of sub-states...
Also, rather than silently ignoring an invalid state, we should complain about a firmware bug.
In practice...
Bay Trail systems originally supported C6-no-shrink as MWAIT sub-state 0x58, and in CPUID.MWAIT.EDX 0x03000000 indicated that there were 3 MWAIT-C6 sub-states. So acpi_idle would discard that C-state because 8 >= 3.
Upon discovering this issue, the ucode was updated so that C6-no-shrink was also exported as 0x51, and the BIOS was updated to match. However, systems shipped with 0x58, will never get a BIOS update, and this patch allows Linux to see C6-no-shrink on early Bay Trail.
Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
16824255 |
| 12-Dec-2013 |
Peter Zijlstra <peterz@infradead.org> |
x86, acpi, idle: Restructure the mwait idle routines
People seem to delight in writing wrong and broken mwait idle routines; collapse the lot.
This leaves mwait_play_dead() the sole remaining user
x86, acpi, idle: Restructure the mwait idle routines
People seem to delight in writing wrong and broken mwait idle routines; collapse the lot.
This leaves mwait_play_dead() the sole remaining user of __mwait() and new __mwait() users are probably doing it wrong.
Also remove __sti_mwait() as its unused.
Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jacob Jun Pan <jacob.jun.pan@linux.intel.com> Cc: Mike Galbraith <bitbucket@online.de> Cc: Len Brown <lenb@kernel.org> Cc: Rui Zhang <rui.zhang@intel.com> Acked-by: Rafael Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20131212141654.616820819@infradead.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
show more ...
|
#
f05e798a |
| 28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Disintegrate asm/system.h for X86
Disintegrate asm/system.h for X86.
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: H. Peter Anvin <hpa@zytor.com> cc: x86@kernel.org
|
#
4bfc8288 |
| 31-Mar-2011 |
Len Brown <len.brown@intel.com> |
x86 idle: move mwait_idle_with_hints() to where it is used
...and make it static
no functional change
cc: x86@kernel.org Acked-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Len Brown <le
x86 idle: move mwait_idle_with_hints() to where it is used
...and make it static
no functional change
cc: x86@kernel.org Acked-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
bd126b23 |
| 07-Aug-2010 |
Namhyung Kim <namhyung@gmail.com> |
ACPI: add missing __percpu markup in arch/x86/kernel/acpi/cstate.c
cpu_cstate_entry is a percpu pointer but was missing __percpu markup.
Signed-off-by: Namhyung Kim <namhyung@gmail.com> Acked-by: T
ACPI: add missing __percpu markup in arch/x86/kernel/acpi/cstate.c
cpu_cstate_entry is a percpu pointer but was missing __percpu markup.
Signed-off-by: Namhyung Kim <namhyung@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
bc83cccc |
| 17-Sep-2010 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, mwait: Move mwait constants to a common header file
We have MWAIT constants spread across three different .c files, for no good reason. Move them all into a common header file.
Signed-off-by:
x86, mwait: Move mwait constants to a common header file
We have MWAIT constants spread across three different .c files, for no good reason. Move them all into a common header file.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Len Brown <lenb@kernel.org> LKML-Reference: <tip-*@git.kernel.org>
show more ...
|
#
718be4aa |
| 22-Jul-2010 |
Len Brown <len.brown@intel.com> |
ACPI: skip checking BM_STS if the BIOS doesn't ask for it
It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not.
Linux has been unco
ACPI: skip checking BM_STS if the BIOS doesn't ask for it
It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not.
Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat:
http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/
ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state
https://bugzilla.kernel.org/show_bug.cgi?id=15886
Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
03a05ed1 |
| 11-Dec-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.
Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skip
ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.
Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE.
The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly.
So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f.
http://bugzilla.kernel.org/show_bug.cgi?id=14700
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
3e2ada58 |
| 27-Sep-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: fix Compaq Evo N800c (Pentium 4m) boot hang regression
Don't disable ARB_DISABLE when the familary ID is 0x0F.
http://bugzilla.kernel.org/show_bug.cgi?id=14211
This was a 2.6.31 regression,
ACPI: fix Compaq Evo N800c (Pentium 4m) boot hang regression
Don't disable ARB_DISABLE when the familary ID is 0x0F.
http://bugzilla.kernel.org/show_bug.cgi?id=14211
This was a 2.6.31 regression, and so this patch needs to be applied to 2.6.31.stable
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
ee1ca48f |
| 22-May-2009 |
Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> |
ACPI: Disable ARB_DISABLE on platforms where it is not needed
ARB_DISABLE is a NOP on all of the recent Intel platforms.
For such platforms, reduce contention on c3_lock by skipping the fake ARB_DI
ACPI: Disable ARB_DISABLE on platforms where it is not needed
ARB_DISABLE is a NOP on all of the recent Intel platforms.
For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
13b40a1a |
| 04-Jan-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Avoid array address overflow when _CST MWAIT hint bits are set
The Cx Register address obtained from the _CST object is used as the MWAIT hints if the register type is FFixedHW. And it is used
ACPI: Avoid array address overflow when _CST MWAIT hint bits are set
The Cx Register address obtained from the _CST object is used as the MWAIT hints if the register type is FFixedHW. And it is used to check whether the Cx type is supported or not.
On some boxes the following Cx state package is obtained from _CST object: >{ ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000889759, // Address 0x03, // Access Size ) },
0x03, 0xF5, 0x015E }
In such case we should use the bit[7:4] of Cx address to check whether the Cx type is supported or not.
mask the MWAIT hint to avoid array address overflow
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by:Venki Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
c74f31c0 |
| 04-Jan-2009 |
Mike Travis <travis@sgi.com> |
cpumask: use work_on_cpu in acpi/cstate.c
Impact: use new cpumask API to reduce stack usage
Replace the saving of current->cpus_allowed and set_cpus_allowed_ptr() with a work_on_cpu function for th
cpumask: use work_on_cpu in acpi/cstate.c
Impact: use new cpumask API to reduce stack usage
Replace the saving of current->cpus_allowed and set_cpus_allowed_ptr() with a work_on_cpu function for the acpi_processor_ffh_cstate_probe() function.
Basically splits acpi_processor_ffh_cstate_probe() into two functions, the other being acpi_processor_ffh_cstate_probe_cpu which is the work function run on the designated cpu.
Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
show more ...
|