Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance, then
the policy shall be CPUFREQ_POLICY_PERFORMANCE
If user chooses powersave governor, they want the least power consumption,
then the policy shall be CPUFREQ_POLICY_POWERSAVE
Function cpufreq_policy_from_governor() is responsible for above transition,
and it shall be also effective when users setting new governor through xenpm.
Userspace is a forbidden choice, and if users specify such option, we shall
not only give warning message to suggest using "xenpm set-cpufreq-cppc", but
also error out.
Signed-off-by: Penny Zheng <penny.zh...@amd.com>
---
v4 -> v5:
- new commit
---
v5 -> v6:
- refactor warning message
---
v6 -> v7:
- move policy->policy set where it firstly gets introduced
- refactor commit message
---
v7 -> v8:
- policy transition is only limited in CPPC mode
---
xen/drivers/acpi/pm-op.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
index 2f516e62b1..a7eaf29c31 100644
--- a/xen/drivers/acpi/pm-op.c
+++ b/xen/drivers/acpi/pm-op.c
@@ -207,6 +207,17 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
if ( new_policy.governor == NULL )
return -EINVAL;
+ if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+ {
+ new_policy.policy = cpufreq_policy_from_governor(new_policy.governor);
+ if ( new_policy.policy == CPUFREQ_POLICY_UNKNOWN )
+ {
+ printk("Failed to get performance policy from %s, Try \"xenpm
set-cpufreq-cppc\"\n",
+ new_policy.governor->name);
+ return -EINVAL;
+ }
+ }
+
return __cpufreq_set_policy(old_policy, &new_policy);
}
--
2.34.1
