Skip to contentSkip to conversation

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

stable request <=3.5 New Vinson Lee 4 participants 9 messages Dec 20, 2013 – Apr 11, 2014 CPU frequency scaling framework

lore
Share & tools
lore

Vinson Lee

author
#0 lore raw

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

#1 lore raw
Quoted 10 lines · 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.

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

Signature · 1 line
Ross Lagerwall
author
#2 lore raw

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(-)
Signature · 1 line
1.8.3.2
author
#3 lore raw

PATCH 1/1 acpi-cpufreq: set current frequency based on target P-State

From: Ross Lagerwall <[email protected]>

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 <[email protected]>
Reviewed-by Len Brown <[email protected]>
Acked-by Viresh Kumar <[email protected]>
Cc 3.8+ <[email protected]>
Signed-off-by Rafael J. Wysocki <[email protected]>

[ srafiullah: Backported to <= 3.6:
- SYSTEM_AMD_MSR_CAPABLE does not exist. ]

Tested-by Shatil Rafiullah <[email protected]>
Signed-off-by Shatil Rafiullah <[email protected]>
Signed-off-by Vinson Lee <[email protected]>
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/cpufreq/acpi-cpufreq.c +1 -1
index 56c6c6b..227a316 100644
@@ -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;
Signature · 1 line
1.8.3.2
#4 lore raw
In reply to Vinson Lee
Quoted 8 lines · 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.

Quoted 5 lines

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

Signature · 1 line
Ross Lagerwall
author
#5 lore raw
Quoted 15 lines · On Tue, Mar 25, 2014 at 3:18 PM, <[email protected]> wrote:
Quoted 8 lines · 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.

Quoted 5 lines

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.

Quoted 8 lines

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

#6 lore raw
Quoted 26 lines · Vinson Lee
Quoted 15 lines · On Tue, Mar 25, 2014 at 3:18 PM, <[email protected]> wrote:
Quoted 8 lines · 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.

Quoted 5 lines

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.

Quoted 8 lines

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

Quoted 8 lines

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

Signature · 1 line
Ross Lagerwall
#7 lore raw
In reply to [email protected]
Quoted 11 lines · On Tue, Mar 25, 2014 at 10:18:03PM +0000, [email protected] wrote:
Quoted 10 lines · 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.

Quoted 8 lines
Quoted 3 lines

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

#8 lore raw
In reply to Vinson Lee
Quoted 8 lines · 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.

Quoted 5 lines

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

Quoted 17 lines

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(-)
Signature · 6 lines
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html