[PATCH 0/5] updates for intel_pstate

[PATCH 0/5] updates for intel_pstate

[dirk.brandewie]

From: Dirk Brandewie <dirk.j.brandewie@intel.com>

Patches 1-4 are bugfixes.  Patch 4 specifically removes the wreckage
caused by C0 tracking change. 

Patch 5 Adds new CPU IDs for the Broadwell processors.

Dirk Brandewie (5):
  intel_pstate: Set turbo VID for Baytrail
  intel_pstate: remove setting P state to MAX on init
  intel_pstate: Fix fixed point rounding macro
  intel_pstate: Remove C0 tracking
  intel_pstate: Add CPU IDs for Broadwell processors

 drivers/cpufreq/intel_pstate.c | 52 +++++++++++++++++-------------------------
 1 file changed, 21 insertions(+), 31 deletions(-)

-- 
1.9.0

[PATCH 2/5] intel_pstate: remove setting P state to MAX on init

[dirk.brandewie]

From: Dirk Brandewie <dirk.j.brandewie@intel.com>

Setting the P state of the core to max at init time is a hold over
from early implementation of intel_pstate where intel_pstate disabled
cpufreq and loaded VERY early in the boot sequence.  This was to
ensure that intel_pstate did not affect boot time. This in not needed
now that intel_pstate is a cpufreq driver.

Removing this covers the case where a CPU has gone through a manual
CPU offline/online cycle and the P state is set to MAX on init and the
CPU immediately goes idle.  Due to HW coordination the P state request
on the idle CPU will drag all cores to MAX P state until the load is
reevaluated when to core goes non-idle.

Reported-by: Patrick Marlier <patrick.marlier@gmail.com>

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
 drivers/cpufreq/intel_pstate.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 39c4f85..eab8ccf 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -554,12 +554,7 @@ static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
 
 	if (pstate_funcs.get_vid)
 		pstate_funcs.get_vid(cpu);
-
-	/*
-	 * goto max pstate so we don't slow up boot if we are built-in if we are
-	 * a module we will take care of it during normal operation
-	 */
-	intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate);
+	intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
 }
 
 static inline void intel_pstate_calc_busy(struct cpudata *cpu,
@@ -704,11 +699,6 @@ static int intel_pstate_init_cpu(unsigned int cpunum)
 	cpu = all_cpu_data[cpunum];
 
 	intel_pstate_get_cpu_pstates(cpu);
-	if (!cpu->pstate.current_pstate) {
-		all_cpu_data[cpunum] = NULL;
-		kfree(cpu);
-		return -ENODATA;
-	}
 
 	cpu->cpu = cpunum;
 
@@ -719,7 +709,6 @@ static int intel_pstate_init_cpu(unsigned int cpunum)
 	cpu->timer.expires = jiffies + HZ/100;
 	intel_pstate_busy_pid_reset(cpu);
 	intel_pstate_sample(cpu);
-	intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate);
 
 	add_timer_on(&cpu->timer, cpunum);
 
-- 
1.9.0

[PATCH 3/5] intel_pstate: Fix fixed point rounding macro

[dirk.brandewie]

From: Dirk Brandewie <dirk.j.brandewie@intel.com>

Change the FP_ROUNDUP macro to add 0.5 in fixed point representation
instead of 1.0

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
 drivers/cpufreq/intel_pstate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index eab8ccf..bb20881 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -43,7 +43,7 @@
 #define FRAC_BITS 6
 #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
 #define fp_toint(X) ((X) >> FRAC_BITS)
-#define FP_ROUNDUP(X) ((X) += 1 << FRAC_BITS)
+#define FP_ROUNDUP(X) ((X) += 1 << (FRAC_BITS-1))
 
 static inline int32_t mul_fp(int32_t x, int32_t y)
 {
-- 
1.9.0

[PATCH 4/5] intel_pstate: Remove C0 tracking

[dirk.brandewie]

From: Dirk Brandewie <dirk.j.brandewie@intel.com>

Commit fcb6a15c intel_pstate: Take core C0 time into account for core busy
introduced a regression referenced below.  The issue with "lockup"
after suspend that this commit was addressing is now dealt with in the
suspend path.

References:
   https://bugzilla.kernel.org/show_bug.cgi?id=66581
   https://bugzilla.kernel.org/show_bug.cgi?id=75121

Reported-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
 drivers/cpufreq/intel_pstate.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index bb20881..4c26faf 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -59,7 +59,6 @@ struct sample {
 	int32_t core_pct_busy;
 	u64 aperf;
 	u64 mperf;
-	unsigned long long tsc;
 	int freq;
 };
 
@@ -100,7 +99,6 @@ struct cpudata {
 
 	u64	prev_aperf;
 	u64	prev_mperf;
-	unsigned long long prev_tsc;
 	struct sample sample;
 };
 
@@ -561,46 +559,37 @@ static inline void intel_pstate_calc_busy(struct cpudata *cpu,
 					struct sample *sample)
 {
 	int32_t core_pct;
-	int32_t c0_pct;
 
 	core_pct = div_fp(int_tofp((sample->aperf)),
 			int_tofp((sample->mperf)));
 	core_pct = mul_fp(core_pct, int_tofp(100));
 	FP_ROUNDUP(core_pct);
 
-	c0_pct = div_fp(int_tofp(sample->mperf), int_tofp(sample->tsc));
-
 	sample->freq = fp_toint(
 		mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct));
 
-	sample->core_pct_busy = mul_fp(core_pct, c0_pct);
+	sample->core_pct_busy = core_pct;
 }
 
 static inline void intel_pstate_sample(struct cpudata *cpu)
 {
 	u64 aperf, mperf;
-	unsigned long long tsc;
 
 	rdmsrl(MSR_IA32_APERF, aperf);
 	rdmsrl(MSR_IA32_MPERF, mperf);
-	tsc = native_read_tsc();
 
 	aperf = aperf >> FRAC_BITS;
 	mperf = mperf >> FRAC_BITS;
-	tsc = tsc >> FRAC_BITS;
 
 	cpu->sample.aperf = aperf;
 	cpu->sample.mperf = mperf;
-	cpu->sample.tsc = tsc;
 	cpu->sample.aperf -= cpu->prev_aperf;
 	cpu->sample.mperf -= cpu->prev_mperf;
-	cpu->sample.tsc -= cpu->prev_tsc;
 
 	intel_pstate_calc_busy(cpu, &cpu->sample);
 
 	cpu->prev_aperf = aperf;
 	cpu->prev_mperf = mperf;
-	cpu->prev_tsc = tsc;
 }
 
 static inline void intel_pstate_set_sample_time(struct cpudata *cpu)
-- 
1.9.0

[PATCH 5/5] intel_pstate: Add CPU IDs for Broadwell processors

[dirk.brandewie]

From: Dirk Brandewie <dirk.j.brandewie@intel.com>

Add support the Broadwell processors.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
 drivers/cpufreq/intel_pstate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 4c26faf..6ef6f7f 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -663,10 +663,13 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
 	ICPU(0x37, byt_params),
 	ICPU(0x3a, core_params),
 	ICPU(0x3c, core_params),
+	ICPU(0x3d, core_params),
 	ICPU(0x3e, core_params),
 	ICPU(0x3f, core_params),
 	ICPU(0x45, core_params),
 	ICPU(0x46, core_params),
+	ICPU(0x4f, core_params),
+	ICPU(0x56, core_params),
 	{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
-- 
1.9.0

Re: [PATCH 0/5] updates for intel_pstate

[Rafael J. Wysocki]

On Thursday, May 08, 2014 12:57:22 PM dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
> 
> Patches 1-4 are bugfixes.  Patch 4 specifically removes the wreckage
> caused by C0 tracking change. 

I would appreciate sending such stuff before the -rc4 time frame.

> Patch 5 Adds new CPU IDs for the Broadwell processors.
> 
> Dirk Brandewie (5):
>   intel_pstate: Set turbo VID for Baytrail
>   intel_pstate: remove setting P state to MAX on init
>   intel_pstate: Fix fixed point rounding macro
>   intel_pstate: Remove C0 tracking
>   intel_pstate: Add CPU IDs for Broadwell processors
> 
>  drivers/cpufreq/intel_pstate.c | 52 +++++++++++++++++-------------------------
>  1 file changed, 21 insertions(+), 31 deletions(-)

I'll queue them up for 3.15-rc6, but that's a bit too late.

Next time I may just wait for the next merge window, fixes or not.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 0/5] updates for intel_pstate

[Dirk Brandewie]

On 05/08/2014 01:30 PM, Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 12:57:22 PM dirk.brandewie@gmail.com wrote:
>> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
>>
>> Patches 1-4 are bugfixes.  Patch 4 specifically removes the wreckage
>> caused by C0 tracking change.
>
> I would appreciate sending such stuff before the -rc4 time frame.

Agreed.

Patch 1 is a resend the others were sent as soon as they were ready/tested

>
>> Patch 5 Adds new CPU IDs for the Broadwell processors.
>>
>> Dirk Brandewie (5):
>>    intel_pstate: Set turbo VID for Baytrail
>>    intel_pstate: remove setting P state to MAX on init
>>    intel_pstate: Fix fixed point rounding macro
>>    intel_pstate: Remove C0 tracking
>>    intel_pstate: Add CPU IDs for Broadwell processors
>>
>>   drivers/cpufreq/intel_pstate.c | 52 +++++++++++++++++-------------------------
>>   1 file changed, 21 insertions(+), 31 deletions(-)
>
> I'll queue them up for 3.15-rc6, but that's a bit too late.
>
> Next time I may just wait for the next merge window, fixes or not.

OK the reporters of the issues already have the fixes in hand.

>
>

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Yuyang Du]

Hi Dirk,

I don't get why you remove the c0 tracking.  This is my understanding wrong.

Suppose it is removed, then the objective of the PID control is:

delta(aperf) / delta(mperf) * max_pstate / current_pstate

But delta(aperf) / delta(mperf) * max_pstate is the average frequency of the last
time frame, and current_pstate is the last requested frequency, then the
objective is:

last_freq_average / last_requested_freq ==> setpoint

What does it mean, SW satisfaction of freq request? Why control that?

Thanks
Yuyang

> @@ -561,46 +559,37 @@ static inline void intel_pstate_calc_busy(struct cpudata *cpu,
>  					struct sample *sample)
>  {
>  	int32_t core_pct;
> -	int32_t c0_pct;
>  
>  	core_pct = div_fp(int_tofp((sample->aperf)),
>  			int_tofp((sample->mperf)));
>  	core_pct = mul_fp(core_pct, int_tofp(100));
>  	FP_ROUNDUP(core_pct);
>  
> -	c0_pct = div_fp(int_tofp(sample->mperf), int_tofp(sample->tsc));
> -
>  	sample->freq = fp_toint(
>  		mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct));
>  
> -	sample->core_pct_busy = mul_fp(core_pct, c0_pct);
> +	sample->core_pct_busy = core_pct;
>  }

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Rafael J. Wysocki]

On Thursday, May 08, 2014 12:57:26 PM dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
> 
> Commit fcb6a15c intel_pstate: Take core C0 time into account for core busy
> introduced a regression referenced below.  The issue with "lockup"
> after suspend that this commit was addressing is now dealt with in the
> suspend path.
> 
> References:
>    https://bugzilla.kernel.org/show_bug.cgi?id=66581
>    https://bugzilla.kernel.org/show_bug.cgi?id=75121
> 
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>

Do we need this in -stable?

> ---
>  drivers/cpufreq/intel_pstate.c | 13 +------------
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index bb20881..4c26faf 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -59,7 +59,6 @@ struct sample {
>  	int32_t core_pct_busy;
>  	u64 aperf;
>  	u64 mperf;
> -	unsigned long long tsc;
>  	int freq;
>  };
>  
> @@ -100,7 +99,6 @@ struct cpudata {
>  
>  	u64	prev_aperf;
>  	u64	prev_mperf;
> -	unsigned long long prev_tsc;
>  	struct sample sample;
>  };
>  
> @@ -561,46 +559,37 @@ static inline void intel_pstate_calc_busy(struct cpudata *cpu,
>  					struct sample *sample)
>  {
>  	int32_t core_pct;
> -	int32_t c0_pct;
>  
>  	core_pct = div_fp(int_tofp((sample->aperf)),
>  			int_tofp((sample->mperf)));
>  	core_pct = mul_fp(core_pct, int_tofp(100));
>  	FP_ROUNDUP(core_pct);
>  
> -	c0_pct = div_fp(int_tofp(sample->mperf), int_tofp(sample->tsc));
> -
>  	sample->freq = fp_toint(
>  		mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct));
>  
> -	sample->core_pct_busy = mul_fp(core_pct, c0_pct);
> +	sample->core_pct_busy = core_pct;
>  }
>  
>  static inline void intel_pstate_sample(struct cpudata *cpu)
>  {
>  	u64 aperf, mperf;
> -	unsigned long long tsc;
>  
>  	rdmsrl(MSR_IA32_APERF, aperf);
>  	rdmsrl(MSR_IA32_MPERF, mperf);
> -	tsc = native_read_tsc();
>  
>  	aperf = aperf >> FRAC_BITS;
>  	mperf = mperf >> FRAC_BITS;
> -	tsc = tsc >> FRAC_BITS;
>  
>  	cpu->sample.aperf = aperf;
>  	cpu->sample.mperf = mperf;
> -	cpu->sample.tsc = tsc;
>  	cpu->sample.aperf -= cpu->prev_aperf;
>  	cpu->sample.mperf -= cpu->prev_mperf;
> -	cpu->sample.tsc -= cpu->prev_tsc;
>  
>  	intel_pstate_calc_busy(cpu, &cpu->sample);
>  
>  	cpu->prev_aperf = aperf;
>  	cpu->prev_mperf = mperf;
> -	cpu->prev_tsc = tsc;
>  }
>  
>  static inline void intel_pstate_set_sample_time(struct cpudata *cpu)
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Stratos Karafotis]

Hi,

On 12/05/2014 05:14 πμ, Stratos Karafotis wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
> 
> Commit fcb6a15c intel_pstate: Take core C0 time into account for core busy
> introduced a regression referenced below.  The issue with "lockup"
> after suspend that this commit was addressing is now dealt with in the
> suspend path.
> 
> References:
>    https://bugzilla.kernel.org/show_bug.cgi?id=66581
>    https://bugzilla.kernel.org/show_bug.cgi?id=75121
> 
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
> ---
>  drivers/cpufreq/intel_pstate.c | 13 +------------
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index bb20881..4c26faf 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -59,7 +59,6 @@ struct sample {
>         int32_t core_pct_busy;
>         u64 aperf;
>         u64 mperf;
> -       unsigned long long tsc;
>         int freq;
>  };
> 
> @@ -100,7 +99,6 @@ struct cpudata {
> 
>         u64     prev_aperf;
>         u64     prev_mperf;
> -       unsigned long long prev_tsc;
>         struct sample sample;
>  };
> 
> @@ -561,46 +559,37 @@ static inline void intel_pstate_calc_busy(struct
> cpudata *cpu,
>                                         struct sample *sample)
>  {
>         int32_t core_pct;
> -       int32_t c0_pct;
> 
>         core_pct = div_fp(int_tofp((sample->aperf)),
>                         int_tofp((sample->mperf)));
>         core_pct = mul_fp(core_pct, int_tofp(100));
>         FP_ROUNDUP(core_pct);
> 
> -       c0_pct = div_fp(int_tofp(sample->mperf), int_tofp(sample->tsc));
> -
>         sample->freq = fp_toint(
>                 mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct));
> 
> -       sample->core_pct_busy = mul_fp(core_pct, c0_pct);
> +       sample->core_pct_busy = core_pct;
>  }
> 
>  static inline void intel_pstate_sample(struct cpudata *cpu)
>  {
>         u64 aperf, mperf;
> -       unsigned long long tsc;
> 
>         rdmsrl(MSR_IA32_APERF, aperf);
>         rdmsrl(MSR_IA32_MPERF, mperf);
> -       tsc = native_read_tsc();
> 
>         aperf = aperf >> FRAC_BITS;
>         mperf = mperf >> FRAC_BITS;
> -       tsc = tsc >> FRAC_BITS;
> 
>         cpu->sample.aperf = aperf;
>         cpu->sample.mperf = mperf;
> -       cpu->sample.tsc = tsc;
>         cpu->sample.aperf -= cpu->prev_aperf;
>         cpu->sample.mperf -= cpu->prev_mperf;
> -       cpu->sample.tsc -= cpu->prev_tsc;
> 
>         intel_pstate_calc_busy(cpu, &cpu->sample);
> 
>         cpu->prev_aperf = aperf;
>         cpu->prev_mperf = mperf;
> -       cpu->prev_tsc = tsc;
>  }
> 
>  static inline void intel_pstate_set_sample_time(struct cpudata *cpu)
> --
> 1.9.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

With this patch, my CPU (Core i7-3770 @ 3.90GHz) seems to never use lowest
frequencies. Even on an idle system I get always ~2GHz. Normally,
on an idle system it used to be 1.6GHz.
On very small loads (mp3 decoding) the CPU goes up to 2.7G GHz (it used to
be 1.6GHz)

Reverting, this patch on my local build, the problem is resolved.


Thanks,
Stratos Karafotis

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Rafael J. Wysocki]

On Monday, May 12, 2014 05:27:25 AM Stratos Karafotis wrote:
> Hi,
> 

[cut]

> 
> With this patch, my CPU (Core i7-3770 @ 3.90GHz) seems to never use lowest
> frequencies. Even on an idle system I get always ~2GHz. Normally,
> on an idle system it used to be 1.6GHz.
> On very small loads (mp3 decoding) the CPU goes up to 2.7G GHz (it used to
> be 1.6GHz)
> 
> Reverting, this patch on my local build, the problem is resolved.

Dirk, seriously, I can't regard this as a fix that can go into -rc6.

Which of the other patch in the series are must-go for 3.15?  [1-2/5] I guess?
And do we need [2/5] it in -stable too?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 3/5] intel_pstate: Fix fixed point rounding macro

[Rafael J. Wysocki]

On Thursday, May 08, 2014 12:57:25 PM dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
> 
> Change the FP_ROUNDUP macro to add 0.5 in fixed point representation
> instead of 1.0

It would be good to say why exactly it is a problem too.  I guess it overflows
sometimes, right?

> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
> ---
>  drivers/cpufreq/intel_pstate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index eab8ccf..bb20881 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -43,7 +43,7 @@
>  #define FRAC_BITS 6
>  #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
>  #define fp_toint(X) ((X) >> FRAC_BITS)
> -#define FP_ROUNDUP(X) ((X) += 1 << FRAC_BITS)
> +#define FP_ROUNDUP(X) ((X) += 1 << (FRAC_BITS-1))
>  
>  static inline int32_t mul_fp(int32_t x, int32_t y)
>  {
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Dirk Brandewie]

On 05/12/2014 05:16 AM, Rafael J. Wysocki wrote:
> On Monday, May 12, 2014 05:27:25 AM Stratos Karafotis wrote:
>> Hi,
>>
>
> [cut]
>
>>
>> With this patch, my CPU (Core i7-3770 @ 3.90GHz) seems to never use lowest
>> frequencies. Even on an idle system I get always ~2GHz. Normally,
>> on an idle system it used to be 1.6GHz.
>> On very small loads (mp3 decoding) the CPU goes up to 2.7G GHz (it used to
>> be 1.6GHz)
>>
>> Reverting, this patch on my local build, the problem is resolved.
>
> Dirk, seriously, I can't regard this as a fix that can go into -rc6.
>

Ok I will resubmit after more testing

> Which of the other patch in the series are must-go for 3.15?  [1-2/5] I guess?
> And do we need [2/5] it in -stable too?

1/5  is for stable it fixes a random MCE on baytrail.
2/5  is for stable it should have went with the stop_cpu patch
5/5  can go too since it is just adding CPU IDs

>
>

Re: [PATCH 4/5] intel_pstate: Remove C0 tracking

[Rafael J. Wysocki]

On Monday, May 12, 2014 07:39:35 AM Dirk Brandewie wrote:
> On 05/12/2014 05:16 AM, Rafael J. Wysocki wrote:
> > On Monday, May 12, 2014 05:27:25 AM Stratos Karafotis wrote:
> >> Hi,
> >>
> >
> > [cut]
> >
> >>
> >> With this patch, my CPU (Core i7-3770 @ 3.90GHz) seems to never use lowest
> >> frequencies. Even on an idle system I get always ~2GHz. Normally,
> >> on an idle system it used to be 1.6GHz.
> >> On very small loads (mp3 decoding) the CPU goes up to 2.7G GHz (it used to
> >> be 1.6GHz)
> >>
> >> Reverting, this patch on my local build, the problem is resolved.
> >
> > Dirk, seriously, I can't regard this as a fix that can go into -rc6.
> >
> 
> Ok I will resubmit after more testing
> 
> > Which of the other patch in the series are must-go for 3.15?  [1-2/5] I guess?
> > And do we need [2/5] it in -stable too?
> 
> 1/5  is for stable it fixes a random MCE on baytrail.
> 2/5  is for stable it should have went with the stop_cpu patch

Which -stable are these two for?  All of them?

> 5/5  can go too since it is just adding CPU IDs

Well, I'm a bit reluctant to push that for -rc6.  There were cases where new
IDs broke stuff that worked without them just fine.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.