| Message ID | 1368801497-13072-1-git-send-email-dirk.j.brandewie@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Fri, May 17, 2013 at 7:38 AM, <dirk.brandewie@gmail.com> wrote: > > Add CPU ID's for supported Sandybridge and Ivybrigde processors. Hmm. Isn't 0x25 "Westmere"? Are the model numbers listed in some doc? I hate this "add random numbers (not even in order) without any logic to it". Here's the list we have of family six numbers from arch/x86/kernel/cpu/intel.c (used for tlb-flushall crap): case 0x60f: /* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */ case 0x616: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" */ case 0x617: /* current 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */ case 0x61d: /* six-core 45 nm xeon "Dunnington" */ case 0x61a: /* 45 nm nehalem, "Bloomfield" */ case 0x61e: /* 45 nm nehalem, "Lynnfield" */ case 0x625: /* 32 nm nehalem, "Clarkdale" */ case 0x62c: /* 32 nm nehalem, "Gulftown" */ case 0x62e: /* 45 nm nehalem-ex, "Beckton" */ case 0x62f: /* 32 nm Xeon E7 */ case 0x62a: /* SandyBridge */ case 0x62d: /* SandyBridge, "Romely-EP" */ case 0x63a: /* Ivybridge */ so it has 0x25 as "Clarkdale" (what's Westmere vs Clarkdale? - Intel codenames always seem like a f*cking exercise in trying to confuse you). But not SB in any case. So we used to have the two SB cases listed (2a/2d). Your patch adds Clarkdale/Ivybridge (but not in the right order). What about the other ones? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/17/2013 08:47 AM, Linus Torvalds wrote: > On Fri, May 17, 2013 at 7:38 AM, <dirk.brandewie@gmail.com> wrote: >> >> Add CPU ID's for supported Sandybridge and Ivybrigde processors. > > Hmm. Isn't 0x25 "Westmere"? > I will update the patch to only include Ivy bridge. This was a brain fade on my part. > Are the model numbers listed in some doc? I hate this "add random > numbers (not even in order) without any logic to it". > The numbers to marketing name decoding are in system programming manual. I don't know of a model number to project name list. > Here's the list we have of family six numbers from > arch/x86/kernel/cpu/intel.c (used for tlb-flushall crap): > > case 0x60f: /* original 65 nm celeron/pentium/core2/xeon, > "Merom"/"Conroe" */ > case 0x616: /* single-core 65 nm celeron/core2solo > "Merom-L"/"Conroe-L" */ > case 0x617: /* current 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */ > case 0x61d: /* six-core 45 nm xeon "Dunnington" */ > case 0x61a: /* 45 nm nehalem, "Bloomfield" */ > case 0x61e: /* 45 nm nehalem, "Lynnfield" */ > case 0x625: /* 32 nm nehalem, "Clarkdale" */ > case 0x62c: /* 32 nm nehalem, "Gulftown" */ > case 0x62e: /* 45 nm nehalem-ex, "Beckton" */ > case 0x62f: /* 32 nm Xeon E7 */ > case 0x62a: /* SandyBridge */ > case 0x62d: /* SandyBridge, "Romely-EP" */ > case 0x63a: /* Ivybridge */ > > so it has 0x25 as "Clarkdale" (what's Westmere vs Clarkdale? - Intel > codenames always seem like a f*cking exercise in trying to confuse > you). But not SB in any case. > > So we used to have the two SB cases listed (2a/2d). Your patch adds > Clarkdale/Ivybridge (but not in the right order). What about the other > ones? > intel_pstate is intended only for SandyBridge+ CPU's > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 1813311..85b1fd8 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -520,7 +520,9 @@ static void intel_pstate_timer_func(unsigned long __data) static const struct x86_cpu_id intel_pstate_cpu_ids[] = { ICPU(0x2a, default_policy), + ICPU(0x25, default_policy), ICPU(0x2d, default_policy), + ICPU(0x3a, default_policy), {} }; MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);