Linux kernel documentation tree maintained by Jonathan Corbet http://mirrors.hust.edu.cn/git/lwn.git/atom?h=doc%2F4.4 2014-02-19T22:33:18+00:00 2014-02-19T22:33:18+00:00 Len Brown len.brown@intel.com 2014-02-14T06:14:13+00:00 urn:sha1:2194324d8bbbad1b179c08b6095649b06abd62d5 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> 2013-12-19T19:54:44+00:00 Peter Zijlstra peterz@infradead.org 2013-12-12T14:08:36+00:00 urn:sha1:16824255394f55adf31b9a96a9965d8c15bdac4c 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> 2012-03-28T17:11:12+00:00 David Howells dhowells@redhat.com 2012-03-28T17:11:12+00:00 urn:sha1:f05e798ad4c09255f590f5b2c00a7ca6c172f983 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 2011-08-03T23:06:36+00:00 Len Brown len.brown@intel.com 2011-03-31T03:52:29+00:00 urn:sha1:4bfc8288bc4a64529c5547d17349a2a1f4675507 ...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> 2010-10-21T20:45:38+00:00 Linus Torvalds torvalds@linux-foundation.org 2010-10-21T20:45:38+00:00 urn:sha1:2a8b67fb72c4c4bc15fe8095e3ed613789c8b82f * 'x86-idle-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line x86, hotplug: Move WBINVD back outside the play_dead loop x86, hotplug: Use mwait to offline a processor, fix the legacy case x86, mwait: Move mwait constants to a common header file 2010-09-29T01:38:20+00:00 Namhyung Kim namhyung@gmail.com 2010-08-07T17:17:29+00:00 urn:sha1:bd126b23a2f30c3c7d268db2b96866923eb732a5 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> 2010-09-17T22:36:40+00:00 H. Peter Anvin hpa@linux.intel.com 2010-09-17T22:36:40+00:00 urn:sha1:bc83cccc761953f878088cdfa682de0970b5561f 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> 2010-07-22T20:54:27+00:00 Len Brown len.brown@intel.com 2010-07-22T20:54:27+00:00 urn:sha1:718be4aaf3613cf7c2d097f925abc3d3553c0605 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> 2009-12-15T02:54:30+00:00 Zhao Yakui yakui.zhao@intel.com 2009-12-11T07:17:20+00:00 urn:sha1:03a05ed1152944000151d57b71000de287a1eb02 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> 2009-09-27T07:43:42+00:00 Zhao Yakui yakui.zhao@intel.com 2009-09-27T07:30:51+00:00 urn:sha1:3e2ada5867b7e9fa0b296d30fa8f3726ebd0a8b7 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>