[PATCH] x86: emphasize that c1e aware idle stuff is AMD specific

From: Andreas Herrmann
Date: Fri Jul 04 2008 - 11:19:08 EST


This is to clarify that AMD C1E has nothing to do with Intel's C1E or
C2E.

Furthermore I changed some comment to clarify that currently just AMD
family 0x10 CPUs support MWAIT. AMD family 0x11 has quite similar
power management features like family 0x10 but it has no MONITOR/MWAIT
instructions.

Signed-off-by: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
---
Patch is against current tip/master.
(git describe says: tip-history-2008-06-30_08.08_Mon-441-g7782052
whatever that means ;-)

Regards,
Andreas


arch/x86/kernel/process.c | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index beef5e1..f6da61a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -189,12 +189,12 @@ static void poll_idle(void)
/*
* mwait selection logic:
*
- * It depends on the CPU. For AMD CPUs that support MWAIT this is
- * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings
- * then depend on a clock divisor and current Pstate of the core. If
- * all cores of a processor are in halt state (C1) the processor can
- * enter the C1E (C1 enhanced) state. If mwait is used this will never
- * happen.
+ * It depends on the CPU. For AMD CPUs that support MWAIT - currently
+ * AMD family 0x10 - this is wrong. Those CPUs will enter C1 on
+ * HLT. Powersavings then depend on a clock divisor and current Pstate
+ * of the core. If all cores of a processor are in halt state (C1) the
+ * processor can enter the AMD C1E (C1 enhanced) state. If mwait is
+ * used this will never happen.
*
* idle=mwait overrides this decision and forces the usage of mwait.
*/
@@ -219,16 +219,16 @@ static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
return 1;

/*
- * edx enumeratios MONITOR/MWAIT extensions. Check, whether
- * C1 supports MWAIT
+ * EDX enumerates MONITOR/MWAIT extensions. Check, whether an
+ * C1 sub-state is supported using MONITOR/MWAIT.
*/
return (edx & MWAIT_EDX_C1);
}

/*
- * Check for AMD CPUs, which have potentially C1E support
+ * Check for AMD CPUs, which have potentially AMD's C1E support
*/
-static int __cpuinit check_c1e_idle(const struct cpuinfo_x86 *c)
+static int __cpuinit check_amd_c1e_idle(const struct cpuinfo_x86 *c)
{
if (c->x86_vendor != X86_VENDOR_AMD)
return 0;
@@ -236,7 +236,7 @@ static int __cpuinit check_c1e_idle(const struct cpuinfo_x86 *c)
if (c->x86 < 0x0F)
return 0;

- /* Family 0x0f models < rev F do not have C1E */
+ /* Family 0x0f models < rev F do not have AMD C1E */
if (c->x86 == 0x0f && c->x86_model < 0x40)
return 0;

@@ -244,11 +244,11 @@ static int __cpuinit check_c1e_idle(const struct cpuinfo_x86 *c)
}

/*
- * C1E aware idle routine. We check for C1E active in the interrupt
+ * AMD C1E aware idle routine. We check for C1E active in the interrupt
* pending message MSR. If we detect C1E, then we handle it the same
* way as C3 power states (local apic timer and TSC stop)
*/
-static void c1e_idle(void)
+static void amd_c1e_idle(void)
{
static cpumask_t c1e_mask = CPU_MASK_NONE;
static int c1e_detected;
@@ -262,8 +262,8 @@ static void c1e_idle(void)
rdmsr(MSR_K8_INT_PENDING_MSG, lo, hi);
if (lo & K8_INTP_C1E_ACTIVE_MASK) {
c1e_detected = 1;
- mark_tsc_unstable("TSC halt in C1E");
- printk(KERN_INFO "System has C1E enabled\n");
+ mark_tsc_unstable("TSC halts in AMD C1E");
+ printk(KERN_INFO "System has AMD C1E enabled\n");
}
}

@@ -316,9 +316,9 @@ void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
*/
printk(KERN_INFO "using mwait in idle threads.\n");
pm_idle = mwait_idle;
- } else if (check_c1e_idle(c)) {
- printk(KERN_INFO "using C1E aware idle routine\n");
- pm_idle = c1e_idle;
+ } else if (check_amd_c1e_idle(c)) {
+ printk(KERN_INFO "using AMD C1E aware idle routine\n");
+ pm_idle = amd_c1e_idle;
} else
pm_idle = default_idle;
}
--
1.5.6.1



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/