From: Dirk Brandewie <[email protected]>
Add CPU ID's for supported Sandybridge and Ivybrigde processors.
Cc: [email protected]
Signed-off-by: Dirk Brandewie <[email protected]>
---
drivers/cpufreq/intel_pstate.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
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);
--
1.7.7.6
On Fri, May 17, 2013 at 7:38 AM, <[email protected]> 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
On 05/17/2013 08:47 AM, Linus Torvalds wrote:
> On Fri, May 17, 2013 at 7:38 AM, <[email protected]> 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
>
From: Dirk Brandewie <[email protected]>
Add CPU ID for Ivybrigde processor.
Cc: [email protected]
Signed-off-by: Dirk Brandewie <[email protected]>
---
drivers/cpufreq/intel_pstate.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1813311..d1e36fe 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -521,6 +521,7 @@ static void intel_pstate_timer_func(unsigned long __data)
static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x2a, default_policy),
ICPU(0x2d, default_policy),
+ ICPU(0x3a, default_policy),
{}
};
MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
--
1.7.7.6
On Fri, May 17, 2013 at 9:40 PM, <[email protected]> wrote:
> From: Dirk Brandewie <[email protected]>
>
> Add CPU ID for Ivybrigde processor.
>
> Cc: [email protected]
> Signed-off-by: Dirk Brandewie <[email protected]>
> ---
> drivers/cpufreq/intel_pstate.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Add my Acked-by: Viresh Kumar <[email protected]>, even if
next version is required with some more machine no.s
On Fri, May 17, 2013 at 09:10:24AM -0700, [email protected] wrote:
> From: Dirk Brandewie <[email protected]>
>
> Add CPU ID for Ivybrigde processor.
>
> Cc: [email protected]
> Signed-off-by: Dirk Brandewie <[email protected]>
BTW, there are some good comments about this by Arjan in this G+ post
https://plus.google.com/117091380454742934025/posts/2vEekAsG2QT
I've tested a patch identical to this on my Thinkpad T430s and it
seems to work quite well for me.
- Ted