[stable request <=3.5] acpi-cpufreq: set current frequency based on target P-State

[stable request <=3.5] acpi-cpufreq: set current frequency based on target P-State

[Vinson Lee]

Hi.

Is commit 8673b83bf2f013379453b4779047bf3c6ae387e4 "acpi-cpufreq: set
current frequency based on target P-State" applicable to kernels
before 3.8?

We found that this patch allows the kernel to control P-states on
3.4.74 on some platforms. However, other platforms were able to change
P-states even without this patch.

Cheers,
Vinson

Re: [stable request <=3.5] acpi-cpufreq: set current frequency based on target P-State

[Ross Lagerwall]

On Thu, Dec 19, 2013 at 06:14:12PM -0800, Vinson Lee wrote:
> Hi.
> 
> Is commit 8673b83bf2f013379453b4779047bf3c6ae387e4 "acpi-cpufreq: set
> current frequency based on target P-State" applicable to kernels
> before 3.8?
> 
> We found that this patch allows the kernel to control P-states on
> 3.4.74 on some platforms. However, other platforms were able to change
> P-states even without this patch.
> 

Well, it fixes a regression introduced in 3.8 which affected setting
turbo frequencies (I'm not sure if the 3.8 patch was backported).
However, there may be other situations where the target frequency is
different from the reported frequency which 8673b83bf2f0 could well fix.

Cheers
-- 
Ross Lagerwall

[stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[Vinson Lee]

Hi.

Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4 
"acpi-cpufreq: set current frequency based on target P-State" to stable 
kernels 3.7 and earlier. This patch enables the kernel to control 
P-states on several platforms. Without this patch, the kernel was unable 
to control P-states on the same platforms.

The upstream patch cleanly applies to 3.7.

A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE 
for kernels 3.6 and earlier.

Cheers,
Vinson


Ross Lagerwall (1):
  acpi-cpufreq: set current frequency based on target P-State

 drivers/cpufreq/acpi-cpufreq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.8.3.2

[PATCH] acpi-cpufreq: set current frequency based on target P-State

[Vinson Lee]

From: Ross Lagerwall <rosslagerwall@gmail.com>

commit 8673b83bf2f013379453b4779047bf3c6ae387e4 upstream.

Commit 4b31e774 (Always set P-state on initialization) fixed bug
#4634 and caused the driver to always set the target P-State at
least once since the initial P-State may not be the desired one.
Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target()
routine if target_freq == policy->cur) caused a regression in
this behavior.

This fixes the regression by setting policy->cur based on the CPU's
target frequency rather than the CPU's current reported frequency
(which may be different).  This means that the P-State will be set
initially if the CPU's target frequency is different from the
governor's target frequency.

This fixes an issue where setting the default governor to
performance wouldn't correctly enable turbo mode on all cores.

Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.8+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ srafiullah: Backported to <= 3.6:
  - SYSTEM_AMD_MSR_CAPABLE does not exist. ]
Tested-by: Shatil Rafiullah <srafiullah@twopensource.com>
Signed-off-by: Shatil Rafiullah <srafiullah@twopensource.com>
Signed-off-by: Vinson Lee <vlee@twitter.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 56c6c6b..227a316 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -215,7 +215,7 @@ static u32 get_cur_val(const struct cpumask *mask)
 	switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) {
 	case SYSTEM_INTEL_MSR_CAPABLE:
 		cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
-		cmd.addr.msr.reg = MSR_IA32_PERF_STATUS;
+		cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
 		break;
 	case SYSTEM_IO_CAPABLE:
 		cmd.type = SYSTEM_IO_CAPABLE;
-- 
1.8.3.2

Re: [stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[rosslagerwall]

On Tue, Mar 25, 2014 at 03:04:16PM -0700, Vinson Lee wrote:
> Hi.
> 
> Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4 
> "acpi-cpufreq: set current frequency based on target P-State" to stable 
> kernels 3.7 and earlier. This patch enables the kernel to control 
> P-states on several platforms. Without this patch, the kernel was unable 
> to control P-states on the same platforms.
> 
> The upstream patch cleanly applies to 3.7.
> 
> A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE 
> for kernels 3.6 and earlier.
> 

I seem to recall that the problem was a regression introduced by commit
5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if
target_freq == policy->cur) which was introduced in the 3.8 cycle.  Are
you sure it is necessary for kernels < 3.8?

Regards
-- 
Ross Lagerwall

Re: [stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[Vinson Lee]

On Tue, Mar 25, 2014 at 3:18 PM,  <rosslagerwall@gmail.com> wrote:
> On Tue, Mar 25, 2014 at 03:04:16PM -0700, Vinson Lee wrote:
>> Hi.
>>
>> Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4
>> "acpi-cpufreq: set current frequency based on target P-State" to stable
>> kernels 3.7 and earlier. This patch enables the kernel to control
>> P-states on several platforms. Without this patch, the kernel was unable
>> to control P-states on the same platforms.
>>
>> The upstream patch cleanly applies to 3.7.
>>
>> A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE
>> for kernels 3.6 and earlier.
>>
>
> I seem to recall that the problem was a regression introduced by commit
> 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if
> target_freq == policy->cur) which was introduced in the 3.8 cycle.  Are
> you sure it is necessary for kernels < 3.8?
>
> Regards
> --
> Ross Lagerwall


This specific patch allows P-states to work with the 3.4 kernel on
several hardware platforms.

Perhaps this is not the correct patch to backport. However, P-states
are not working properly with the 3.4 kernel, even though it does not
have the regression commit 5a1c0228 "cpufreq: Avoid calling cpufreq
driver's target() routine if target_freq == policy->cur" backported.

Cheers,
Vinson

Re: [stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[rosslagerwall]

On Tue, Mar 25, 2014 at 03:53:40PM -0700, Vinson Lee wrote:
> On Tue, Mar 25, 2014 at 3:18 PM,  <rosslagerwall@gmail.com> wrote:
> > On Tue, Mar 25, 2014 at 03:04:16PM -0700, Vinson Lee wrote:
> >> Hi.
> >>
> >> Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4
> >> "acpi-cpufreq: set current frequency based on target P-State" to stable
> >> kernels 3.7 and earlier. This patch enables the kernel to control
> >> P-states on several platforms. Without this patch, the kernel was unable
> >> to control P-states on the same platforms.
> >>
> >> The upstream patch cleanly applies to 3.7.
> >>
> >> A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE
> >> for kernels 3.6 and earlier.
> >>
> >
> > I seem to recall that the problem was a regression introduced by commit
> > 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if
> > target_freq == policy->cur) which was introduced in the 3.8 cycle.  Are
> > you sure it is necessary for kernels < 3.8?
> >
> > Regards
> > --
> > Ross Lagerwall
> 
> 
> This specific patch allows P-states to work with the 3.4 kernel on
> several hardware platforms.
> 
> Perhaps this is not the correct patch to backport. However, P-states
> are not working properly with the 3.4 kernel, even though it does not
> have the regression commit 5a1c0228 "cpufreq: Avoid calling cpufreq
> driver's target() routine if target_freq == policy->cur" backported.
> 

Fair enough,

Cheers
-- 
Ross Lagerwall

Re: [stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[Greg KH]

On Tue, Mar 25, 2014 at 10:18:03PM +0000, rosslagerwall@gmail.com wrote:
> On Tue, Mar 25, 2014 at 03:04:16PM -0700, Vinson Lee wrote:
> > Hi.
> > 
> > Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4 
> > "acpi-cpufreq: set current frequency based on target P-State" to stable 
> > kernels 3.7 and earlier. This patch enables the kernel to control 
> > P-states on several platforms. Without this patch, the kernel was unable 
> > to control P-states on the same platforms.
> > 
> > The upstream patch cleanly applies to 3.7.
> > 
> > A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE 
> > for kernels 3.6 and earlier.
> > 
> 
> I seem to recall that the problem was a regression introduced by commit
> 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if
> target_freq == policy->cur) which was introduced in the 3.8 cycle.  Are
> you sure it is necessary for kernels < 3.8?

Given the lack of response here, I'm dropping these from my queue.  If
someone wants them back in, please resend after responding to this...

greg k-h

Re: [stable request <=3.7] acpi-cpufreq: set current frequency based on target P-State

[Luís Henriques]

On Tue, Mar 25, 2014 at 03:04:16PM -0700, Vinson Lee wrote:
> Hi.
> 
> Please backport upstream commit 8673b83bf2f013379453b4779047bf3c6ae387e4 
> "acpi-cpufreq: set current frequency based on target P-State" to stable 
> kernels 3.7 and earlier. This patch enables the kernel to control 
> P-states on several platforms. Without this patch, the kernel was unable 
> to control P-states on the same platforms.
> 
> The upstream patch cleanly applies to 3.7.
> 
> A backported patch is needed with the removal of SYSTEM_AMD_MSR_CAPABLE 
> for kernels 3.6 and earlier.
> 

Thank you, I'm queuing this backport to the 3.5 kernel.

Cheers,
--
Luís

> Cheers,
> Vinson
> 
> 
> Ross Lagerwall (1):
>   acpi-cpufreq: set current frequency based on target P-State
> 
>  drivers/cpufreq/acpi-cpufreq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] acpi-cpufreq: set current frequency based on target P-State

[Ross Lagerwall]

4b31e774 fixed bug #4634 and caused the driver to always set the
target P-State at least once since the initial P-State may not be the
desired one.  5a1c0228 caused a regression in this behavior.

This fixes the regression by setting policy->cur based on the CPU's
target frequency rather than the CPU's current reported frequency
(which may be different).  This means the P-State will be set initially
if the CPU's target frequency is different from the governor's target
frequency.

This fixes an issue where setting the default governor to performance
wouldn't correctly enable turbo mode on all cores.

Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 11b8b4b..edc089e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -347,11 +347,11 @@ static u32 get_cur_val(const struct cpumask *mask)
 	switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) {
 	case SYSTEM_INTEL_MSR_CAPABLE:
 		cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
-		cmd.addr.msr.reg = MSR_IA32_PERF_STATUS;
+		cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
 		break;
 	case SYSTEM_AMD_MSR_CAPABLE:
 		cmd.type = SYSTEM_AMD_MSR_CAPABLE;
-		cmd.addr.msr.reg = MSR_AMD_PERF_STATUS;
+		cmd.addr.msr.reg = MSR_AMD_PERF_CTL;
 		break;
 	case SYSTEM_IO_CAPABLE:
 		cmd.type = SYSTEM_IO_CAPABLE;
-- 
1.8.3

Re: [PATCH] acpi-cpufreq: set current frequency based on target P-State

[Len Brown]

On Fri, May 31, 2013 at 3:45 PM, Ross Lagerwall <rosslagerwall@gmail.com> wrote:
>
> 4b31e774 fixed bug #4634 and caused the driver to always set the
> target P-State at least once since the initial P-State may not be the
> desired one.  5a1c0228 caused a regression in this behavior.
>
> This fixes the regression by setting policy->cur based on the CPU's
> target frequency rather than the CPU's current reported frequency
> (which may be different).  This means the P-State will be set initially
> if the CPU's target frequency is different from the governor's target
> frequency.
>
> This fixes an issue where setting the default governor to performance
> wouldn't correctly enable turbo mode on all cores.
>
> Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>

Reviewed-by: Len Brown <len.brown@intel.com>

Ack -- MSR_IA32_PERF_STATUS is ill-conceived.  It is un-reliable
by its very definition.  Any code that depends on it should be questioned...

thanks,
Len Brown, Intel Open Source Technology Center

> ---
>  drivers/cpufreq/acpi-cpufreq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 11b8b4b..edc089e 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -347,11 +347,11 @@ static u32 get_cur_val(const struct cpumask *mask)
>         switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) {
>         case SYSTEM_INTEL_MSR_CAPABLE:
>                 cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
> -               cmd.addr.msr.reg = MSR_IA32_PERF_STATUS;
> +               cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
>                 break;
>         case SYSTEM_AMD_MSR_CAPABLE:
>                 cmd.type = SYSTEM_AMD_MSR_CAPABLE;
> -               cmd.addr.msr.reg = MSR_AMD_PERF_STATUS;
> +               cmd.addr.msr.reg = MSR_AMD_PERF_CTL;
>                 break;
>         case SYSTEM_IO_CAPABLE:
>                 cmd.type = SYSTEM_IO_CAPABLE;
> --
> 1.8.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Len Brown, Intel Open Source Technology Center

Re: [PATCH] acpi-cpufreq: set current frequency based on target P-State

[Viresh Kumar]

On Sat, Jun 1, 2013 at 1:15 AM, Ross Lagerwall <rosslagerwall@gmail.com> wrote:
> 4b31e774 fixed bug #4634 and caused the driver to always set the
> target P-State at least once since the initial P-State may not be the
> desired one.  5a1c0228 caused a regression in this behavior.
>
> This fixes the regression by setting policy->cur based on the CPU's
> target frequency rather than the CPU's current reported frequency
> (which may be different).  This means the P-State will be set initially
> if the CPU's target frequency is different from the governor's target
> frequency.
>
> This fixes an issue where setting the default governor to performance
> wouldn't correctly enable turbo mode on all cores.
>
> Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
> ---
>  drivers/cpufreq/acpi-cpufreq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks for your patch.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>