The patch series adds some fixes and enhancements to the AMD pstate
driver.
It enables CPPC v2 for certain processors in the family 17H, as
requested
by TR40 processor users who expect improved performance and lower system
temperature.
Additionally, it fixes the initialization of nominal_freq for each
cpudata
and changes latency and delay values to be read from platform firmware
firstly
for more accurate timing.
A new quirk is also added for legacy processors that lack CPPC
capabilities which caused the pstate driver to fail loading.
I would greatly appreciate any feedbacks.
Thank you!
Changes from v5:
* rebased to linux-pm v6.8
* pick up RB flag from for patch 6(Mario)
Changes from v4:
* improve the dmi matching rule with zen2 flag only
Changes from v3:
* change quirk matching broken BIOS with family/model ID and Zen2
flag to fix the CPPC definition issue
* fix typo in quirk
Changes from v2:
* change quirk matching to BIOS version and release (Mario)
* pick up RB flag from Mario
Changes from v1:
* pick up the RB flags from Mario
* address review comment of patch #6 for amd_get_nominal_freq()
* rebased the series to linux-pm/bleeding-edge v6.8.0-rc2
* update debug log for patch #5 as Mario suggested.
* fix some typos and format problems
* tested on 7950X platform
V1: https://lore.kernel.org/lkml/[email protected]/
V2: https://lore.kernel.org/all/[email protected]/
v3: https://lore.kernel.org/lkml/[email protected]/
v4: https://lore.kernel.org/lkml/[email protected]/
v5: https://lore.kernel.org/lkml/[email protected]/
Perry Yuan (6):
ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors
cpufreq:amd-pstate: fix the nominal freq value set
cpufreq:amd-pstate: initialize nominal_freq of each cpudata
cpufreq:amd-pstate: get pstate transition delay and latency value from
ACPI tables
cppc_acpi: print error message if CPPC is unsupported
cpufreq:amd-pstate: add quirk for the pstate CPPC capabilities missing
arch/x86/kernel/acpi/cppc.c | 2 +-
drivers/acpi/cppc_acpi.c | 4 +-
drivers/cpufreq/amd-pstate.c | 116 ++++++++++++++++++++++++++++++-----
include/linux/amd-pstate.h | 6 ++
4 files changed, 109 insertions(+), 19 deletions(-)
--
2.34.1
As there are some AMD processors which only support CPPC V2 firmware and
BIOS implementation, the amd_pstate driver will be failed to load when
system booting with below kernel warning message:
[ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
To make the amd_pstate driver can be loaded on those TR40 processors, it
needs to match x86_model from 0x30 to 0x7F for family 17H.
With the change, the system can load amd_pstate driver as expected.
Reviewed-by: Mario Limonciello <[email protected]>
Reported-by: Gino Badouri <[email protected]>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")
Signed-off-by: Perry Yuan <[email protected]>
---
arch/x86/kernel/acpi/cppc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 8d8752b44f11..ff8f25faca3d 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -20,7 +20,7 @@ bool cpc_supported_by_cpu(void)
(boot_cpu_data.x86_model >= 0x20 && boot_cpu_data.x86_model <= 0x2f)))
return true;
else if (boot_cpu_data.x86 == 0x17 &&
- boot_cpu_data.x86_model >= 0x70 && boot_cpu_data.x86_model <= 0x7f)
+ boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x7f)
return true;
return boot_cpu_has(X86_FEATURE_CPPC);
}
--
2.34.1
Address an untested error where the nominal_freq was returned in KHz
instead of the correct MHz units, this oversight led to a wrong
nominal_freq set and resued, it will cause the max frequency of core to
be initialized with a wrong frequency value.
Cc: [email protected]
Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
---
drivers/cpufreq/amd-pstate.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 08e112444c27..ac7faa98a450 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -640,8 +640,7 @@ static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
if (ret)
return ret;
- /* Switch to khz */
- return cppc_perf.nominal_freq * 1000;
+ return cppc_perf.nominal_freq;
}
static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
--
2.34.1
Optimizes the process of retrieving the nominal frequency by utilizing
'cpudata->nominal_freq' instead of repeatedly accessing the cppc_acpi interface.
To enhance efficiency and reduce the CPU load, shifted to using
'cpudata->nominal_freq'. It allows for the nominal frequency to be accessed
directly from the cached data in 'cpudata' of each CPU.
It will also slightly reduce the frequency change latency while using pstate
driver passive mode.
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
---
drivers/cpufreq/amd-pstate.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index ac7faa98a450..ea8681ea3bad 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -619,7 +619,7 @@ static int amd_get_max_freq(struct amd_cpudata *cpudata)
if (ret)
return ret;
- nominal_freq = cppc_perf.nominal_freq;
+ nominal_freq = READ_ONCE(cpudata->nominal_freq);
nominal_perf = READ_ONCE(cpudata->nominal_perf);
max_perf = READ_ONCE(cpudata->highest_perf);
@@ -654,7 +654,7 @@ static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
if (ret)
return ret;
- nominal_freq = cppc_perf.nominal_freq;
+ nominal_freq = READ_ONCE(cpudata->nominal_freq);
nominal_perf = READ_ONCE(cpudata->nominal_perf);
lowest_nonlinear_perf = cppc_perf.lowest_nonlinear_perf;
@@ -848,13 +848,14 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
goto free_cpudata1;
min_freq = amd_get_min_freq(cpudata);
- max_freq = amd_get_max_freq(cpudata);
nominal_freq = amd_get_nominal_freq(cpudata);
+ cpudata->nominal_freq = nominal_freq;
+ max_freq = amd_get_max_freq(cpudata);
lowest_nonlinear_freq = amd_get_lowest_nonlinear_freq(cpudata);
- if (min_freq < 0 || max_freq < 0 || min_freq > max_freq) {
- dev_err(dev, "min_freq(%d) or max_freq(%d) value is incorrect\n",
- min_freq, max_freq);
+ if (min_freq < 0 || max_freq < 0 || min_freq > max_freq || nominal_freq == 0) {
+ dev_err(dev, "min_freq(%d) or max_freq(%d) or nominal_freq(%d) is incorrect\n",
+ min_freq, max_freq, nominal_freq);
ret = -EINVAL;
goto free_cpudata1;
}
@@ -893,7 +894,6 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
cpudata->min_freq = min_freq;
cpudata->max_limit_freq = max_freq;
cpudata->min_limit_freq = min_freq;
- cpudata->nominal_freq = nominal_freq;
cpudata->lowest_nonlinear_freq = lowest_nonlinear_freq;
policy->driver_data = cpudata;
@@ -1310,12 +1310,13 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
goto free_cpudata1;
min_freq = amd_get_min_freq(cpudata);
- max_freq = amd_get_max_freq(cpudata);
nominal_freq = amd_get_nominal_freq(cpudata);
+ cpudata->nominal_freq = nominal_freq;
+ max_freq = amd_get_max_freq(cpudata);
lowest_nonlinear_freq = amd_get_lowest_nonlinear_freq(cpudata);
- if (min_freq < 0 || max_freq < 0 || min_freq > max_freq) {
- dev_err(dev, "min_freq(%d) or max_freq(%d) value is incorrect\n",
- min_freq, max_freq);
+ if (min_freq < 0 || max_freq < 0 || min_freq > max_freq || nominal_freq == 0) {
+ dev_err(dev, "min_freq(%d) or max_freq(%d) or nominal_freq(%d) is incorrect\n",
+ min_freq, max_freq, nominal_freq);
ret = -EINVAL;
goto free_cpudata1;
}
@@ -1328,7 +1329,6 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
/* Initial processor data capability frequencies */
cpudata->max_freq = max_freq;
cpudata->min_freq = min_freq;
- cpudata->nominal_freq = nominal_freq;
cpudata->lowest_nonlinear_freq = lowest_nonlinear_freq;
policy->driver_data = cpudata;
--
2.34.1
make pstate driver initially retrieve the P-state transition delay and latency
values from the BIOS ACPI tables which has more reasonable delay and latency
values according to the platform design and requirements.
Previously there values were hardcoded at specific value which may
have conflicted with platform and it might not reflect the most accurate or
optimized setting for the processor.
[054h 0084 8] Preserve Mask : FFFFFFFF00000000
[05Ch 0092 8] Write Mask : 0000000000000001
[064h 0100 4] Command Latency : 00000FA0
[068h 0104 4] Maximum Access Rate : 0000EA60
[06Ch 0108 2] Minimum Turnaround Time : 0000
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
---
drivers/cpufreq/amd-pstate.c | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index ea8681ea3bad..77effc3caf6c 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -820,6 +820,36 @@ static void amd_pstate_update_limits(unsigned int cpu)
mutex_unlock(&amd_pstate_driver_lock);
}
+/**
+ * Get pstate transition delay time from ACPI tables that firmware set
+ * instead of using hardcode value directly.
+ */
+static u32 amd_pstate_get_transition_delay_us(unsigned int cpu)
+{
+ u32 transition_delay_ns;
+
+ transition_delay_ns = cppc_get_transition_latency(cpu);
+ if (transition_delay_ns == CPUFREQ_ETERNAL)
+ return AMD_PSTATE_TRANSITION_DELAY;
+
+ return transition_delay_ns / NSEC_PER_USEC;
+}
+
+/**
+ * Get pstate transition latency value from ACPI tables that firmware set
+ * instead of using hardcode value directly.
+ */
+static u32 amd_pstate_get_transition_latency(unsigned int cpu)
+{
+ u32 transition_latency;
+
+ transition_latency = cppc_get_transition_latency(cpu);
+ if (transition_latency == CPUFREQ_ETERNAL)
+ return AMD_PSTATE_TRANSITION_LATENCY;
+
+ return transition_latency;
+}
+
static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
{
int min_freq, max_freq, nominal_freq, lowest_nonlinear_freq, ret;
@@ -860,8 +890,8 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
goto free_cpudata1;
}
- policy->cpuinfo.transition_latency = AMD_PSTATE_TRANSITION_LATENCY;
- policy->transition_delay_us = AMD_PSTATE_TRANSITION_DELAY;
+ policy->cpuinfo.transition_latency = amd_pstate_get_transition_latency(policy->cpu);
+ policy->transition_delay_us = amd_pstate_get_transition_delay_us(policy->cpu);
policy->min = min_freq;
policy->max = max_freq;
--
2.34.1
to be more clear what is wrong with CPPC when pstate driver failed to
load which has dependency on the CPPC capabilities.
Add one more debug message to notify user if CPPC is not supported by
the CPU, then it will be easy to find out what need to fix for pstate
driver loading issue.
[ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
Above message is not clear enough to verify whether CPPC is not supported.
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
---
drivers/acpi/cppc_acpi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index a50e70abdf19..e23a84f4a50a 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -679,8 +679,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
if (!osc_sb_cppc2_support_acked) {
pr_debug("CPPC v2 _OSC not acked\n");
- if (!cpc_supported_by_cpu())
+ if (!cpc_supported_by_cpu()) {
+ pr_debug("CPPC is not supported by the CPU\n");
return -ENODEV;
+ }
}
/* Parse the ACPI _CPC table for this CPU. */
--
2.34.1
Add quirks table to get CPPC capabilities issue fixed by providing
correct perf or frequency values while driver loading.
If CPPC capabilities are not defined in the ACPI tables or wrongly
defined by platform firmware, it needs to use quick to get those
issues fixed with correct workaround values to make pstate driver
can be loaded even though there are CPPC capabilities errors.
The workaround will match the broken BIOS which lack of CPPC capabilities
nominal_freq and lowest_freq definition in the ACPI table.
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq
0
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
0
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
---
drivers/cpufreq/amd-pstate.c | 57 ++++++++++++++++++++++++++++++++++--
include/linux/amd-pstate.h | 6 ++++
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 77effc3caf6c..ff4727c22dce 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;
static int cppc_state = AMD_PSTATE_UNDEFINED;
static bool cppc_enabled;
static bool amd_pstate_prefcore = true;
+static struct quirk_entry *quirks;
/*
* AMD Energy Preference Performance (EPP)
@@ -111,6 +112,41 @@ static unsigned int epp_values[] = {
typedef int (*cppc_mode_transition_fn)(int);
+static struct quirk_entry quirk_amd_7k62 = {
+ .nominal_freq = 2600,
+ .lowest_freq = 550,
+};
+
+static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
+{
+ /**
+ * match the broken bios for family 17h processor support CPPC V2
+ * broken BIOS lack of nominal_freq and lowest_freq capabilities
+ * definition in ACPI tables
+ */
+ if (boot_cpu_has(X86_FEATURE_ZEN2)) {
+ quirks = dmi->driver_data;
+ pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
+ return 1;
+ }
+
+ return 0;
+}
+
+static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
+ {
+ .callback = dmi_matched_7k62_bios_bug,
+ .ident = "AMD EPYC 7K62",
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VERSION, "5.14"),
+ DMI_MATCH(DMI_BIOS_RELEASE, "12/12/2019"),
+ },
+ .driver_data = &quirk_amd_7k62,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
+
static inline int get_mode_idx_from_str(const char *str, size_t size)
{
int i;
@@ -600,13 +636,19 @@ static void amd_pstate_adjust_perf(unsigned int cpu,
static int amd_get_min_freq(struct amd_cpudata *cpudata)
{
struct cppc_perf_caps cppc_perf;
+ u32 lowest_freq;
int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
if (ret)
return ret;
+ if (quirks && quirks->lowest_freq)
+ lowest_freq = quirks->lowest_freq;
+ else
+ lowest_freq = cppc_perf.lowest_freq;
+
/* Switch to khz */
- return cppc_perf.lowest_freq * 1000;
+ return lowest_freq * 1000;
}
static int amd_get_max_freq(struct amd_cpudata *cpudata)
@@ -635,12 +677,18 @@ static int amd_get_max_freq(struct amd_cpudata *cpudata)
static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
{
struct cppc_perf_caps cppc_perf;
+ u32 nominal_freq;
int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
if (ret)
return ret;
- return cppc_perf.nominal_freq;
+ if (quirks && quirks->nominal_freq)
+ nominal_freq = quirks->nominal_freq;
+ else
+ nominal_freq = cppc_perf.nominal_freq;
+
+ return nominal_freq;
}
static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
@@ -1672,6 +1720,11 @@ static int __init amd_pstate_init(void)
if (cpufreq_get_current_driver())
return -EEXIST;
+ quirks = NULL;
+
+ /* check if this machine need CPPC quirks */
+ dmi_check_system(amd_pstate_quirks_table);
+
switch (cppc_state) {
case AMD_PSTATE_UNDEFINED:
/* Disable on the following configs by default:
diff --git a/include/linux/amd-pstate.h b/include/linux/amd-pstate.h
index d21838835abd..7b2cbb892fd9 100644
--- a/include/linux/amd-pstate.h
+++ b/include/linux/amd-pstate.h
@@ -124,4 +124,10 @@ static const char * const amd_pstate_mode_string[] = {
[AMD_PSTATE_GUIDED] = "guided",
NULL,
};
+
+struct quirk_entry {
+ u32 nominal_freq;
+ u32 lowest_freq;
+};
+
#endif /* _LINUX_AMD_PSTATE_H */
--
2.34.1
Hello Perry,
On Thu, Feb 08, 2024 at 11:46:28AM +0800, Perry Yuan wrote:
> As there are some AMD processors which only support CPPC V2 firmware and
> BIOS implementation, the amd_pstate driver will be failed to load when
> system booting with below kernel warning message:
>
> [ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
>
> To make the amd_pstate driver can be loaded on those TR40 processors, it
> needs to match x86_model from 0x30 to 0x7F for family 17H.
> With the change, the system can load amd_pstate driver as expected.
>
> Reviewed-by: Mario Limonciello <[email protected]>
> Reported-by: Gino Badouri <[email protected]>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
> Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")
> Signed-off-by: Perry Yuan <[email protected]>
> ---
> arch/x86/kernel/acpi/cppc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
> index 8d8752b44f11..ff8f25faca3d 100644
> --- a/arch/x86/kernel/acpi/cppc.c
> +++ b/arch/x86/kernel/acpi/cppc.c
> @@ -20,7 +20,7 @@ bool cpc_supported_by_cpu(void)
> (boot_cpu_data.x86_model >= 0x20 && boot_cpu_data.x86_model <= 0x2f)))
> return true;
> else if (boot_cpu_data.x86 == 0x17 &&
> - boot_cpu_data.x86_model >= 0x70 && boot_cpu_data.x86_model <= 0x7f)
> + boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x7f)
This looks ok to me.
Reviewed-by: Gautham R. Shenoy <[email protected]>
--
Thanks and Regards
gautham.
On Thu, Feb 08, 2024 at 11:46:29AM +0800, Perry Yuan wrote:
> Address an untested error where the nominal_freq was returned in KHz
> instead of the correct MHz units, this oversight led to a wrong
> nominal_freq set and resued, it will cause the max frequency of core to
> be initialized with a wrong frequency value.
The _CPC object on my Zen2 EPYC server which has CPPC v3, I see :
0x00000190, //LowestFrequency
0x000007D0 //NominalFrequency
})
}
where 0x7D0 is 2000 Mhz. Thus the value returend by cppc_perf.nominal_freq is in Mhz.
In this patch, we are changing making amd_get_nominal_freq() return
2000 (Mhz) instead of 2000000 (Khz) as it was doing previously.
amd_get_min_freq(), amd_get_max_freq(),
amd_get_lowest_nonlinear_perf() -all these functions return the
frequency in Khz units.
These functions are used the initialize the value of
cpudata->max_freq, cpu_data->min_freq, .... all of which are in Khz
units.
In, amd_pstate_set_boost(), we have:
if (state)
policy->cpuinfo.max_freq = cpudata->max_freq; <---- In Khz
else
policy->cpuinfo.max_freq = cpudata->nominal_freq; <--- Now in Mhz
Since policy->cpuinfo.max_freq is expected to be in Khz, isn't this
patch introducing an error ? Or perhaps this patch series is based on
another patchset ?
--
Thanks and Regards
gautham.
>
> Cc: [email protected]
> Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
> Reviewed-by: Mario Limonciello <[email protected]>
> Signed-off-by: Perry Yuan <[email protected]>
> ---
> drivers/cpufreq/amd-pstate.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 08e112444c27..ac7faa98a450 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -640,8 +640,7 @@ static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
> if (ret)
> return ret;
>
> - /* Switch to khz */
> - return cppc_perf.nominal_freq * 1000;
> + return cppc_perf.nominal_freq;
> }
>
> static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
> --
> 2.34.1
>
On Thu, Feb 08, 2024 at 11:46:30AM +0800, Perry Yuan wrote:
> Optimizes the process of retrieving the nominal frequency by utilizing
> 'cpudata->nominal_freq' instead of repeatedly accessing the cppc_acpi interface.
>
> To enhance efficiency and reduce the CPU load, shifted to using
> 'cpudata->nominal_freq'. It allows for the nominal frequency to be accessed
> directly from the cached data in 'cpudata' of each CPU.
> It will also slightly reduce the frequency change latency while using pstate
> driver passive mode.
>
> Reviewed-by: Mario Limonciello <[email protected]>
> Signed-off-by: Perry Yuan <[email protected]>
> ---
> drivers/cpufreq/amd-pstate.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index ac7faa98a450..ea8681ea3bad 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -619,7 +619,7 @@ static int amd_get_max_freq(struct amd_cpudata *cpudata)
> if (ret)
> return ret;
>
> - nominal_freq = cppc_perf.nominal_freq;
> + nominal_freq = READ_ONCE(cpudata->nominal_freq);
Does it make sense to call cppc_get_perf_caps() in
amd_pstate_cpu_init() and amd_pstate_epp_cpu_init() and cache all the
relevant metrics such as highest_perf, lowest_perf,
lowest_nonlinear_perf, nominal_perf, nominal_freq, lowest_freq so that
subsequent calls to amd_get_max/min/lowest_nonlinear/nominal_freq()
can use these cached values instead of calling cppc_get_perf_caps()
again ?
Because even with this patch, we continue to call cppc_get_perf_caps()
in amd_get_max_freq(), amd_get_min_freq() and
amd_get_lowest_nonlinear_freq().
> nominal_perf = READ_ONCE(cpudata->nominal_perf);
> max_perf = READ_ONCE(cpudata->highest_perf);
>
> @@ -654,7 +654,7 @@ static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
> if (ret)
> return ret;
>
> - nominal_freq = cppc_perf.nominal_freq;
> + nominal_freq = READ_ONCE(cpudata->nominal_freq);
> nominal_perf = READ_ONCE(cpudata->nominal_perf);
>
> lowest_nonlinear_perf = cppc_perf.lowest_nonlinear_perf;
> @@ -848,13 +848,14 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> goto free_cpudata1;
>
> min_freq = amd_get_min_freq(cpudata);
> - max_freq = amd_get_max_freq(cpudata);
> nominal_freq = amd_get_nominal_freq(cpudata);
> + cpudata->nominal_freq = nominal_freq;
> + max_freq = amd_get_max_freq(cpudata);
> lowest_nonlinear_freq = amd_get_lowest_nonlinear_freq(cpudata);
>
> - if (min_freq < 0 || max_freq < 0 || min_freq > max_freq) {
> - dev_err(dev, "min_freq(%d) or max_freq(%d) value is incorrect\n",
> - min_freq, max_freq);
> + if (min_freq < 0 || max_freq < 0 || min_freq > max_freq || nominal_freq == 0) {
+1 for the "nominal_freq == 0" check. On CPPCv2, nominal_freq and
lowest_freq are not advertised. So nominal_freq will be 0. It is
better to fail here than failing later at the time of governor
initialization.
> + dev_err(dev, "min_freq(%d) or max_freq(%d) or nominal_freq(%d) is incorrect\n",
> + min_freq, max_freq, nominal_freq);
> ret = -EINVAL;
> goto free_cpudata1;
> }
> @@ -893,7 +894,6 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
> cpudata->min_freq = min_freq;
> cpudata->max_limit_freq = max_freq;
> cpudata->min_limit_freq = min_freq;
> - cpudata->nominal_freq = nominal_freq;
> cpudata->lowest_nonlinear_freq = lowest_nonlinear_freq;
>
> policy->driver_data = cpudata;
> @@ -1310,12 +1310,13 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> goto free_cpudata1;
>
> min_freq = amd_get_min_freq(cpudata);
> - max_freq = amd_get_max_freq(cpudata);
> nominal_freq = amd_get_nominal_freq(cpudata);
> + cpudata->nominal_freq = nominal_freq;
> + max_freq = amd_get_max_freq(cpudata);
> lowest_nonlinear_freq = amd_get_lowest_nonlinear_freq(cpudata);
> - if (min_freq < 0 || max_freq < 0 || min_freq > max_freq) {
> - dev_err(dev, "min_freq(%d) or max_freq(%d) value is incorrect\n",
> - min_freq, max_freq);
> + if (min_freq < 0 || max_freq < 0 || min_freq > max_freq || nominal_freq == 0) {
Ditto.
> + dev_err(dev, "min_freq(%d) or max_freq(%d) or nominal_freq(%d) is incorrect\n",
> + min_freq, max_freq, nominal_freq);
> ret = -EINVAL;
> goto free_cpudata1;
> }
> @@ -1328,7 +1329,6 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> /* Initial processor data capability frequencies */
> cpudata->max_freq = max_freq;
> cpudata->min_freq = min_freq;
> - cpudata->nominal_freq = nominal_freq;
> cpudata->lowest_nonlinear_freq = lowest_nonlinear_freq;
--
Thanks and Regards
gautham.
On Thu, Feb 08, 2024 at 11:46:32AM +0800, Perry Yuan wrote:
> to be more clear what is wrong with CPPC when pstate driver failed to
> load which has dependency on the CPPC capabilities.
>
> Add one more debug message to notify user if CPPC is not supported by
> the CPU, then it will be easy to find out what need to fix for pstate
> driver loading issue.
>
> [ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
>
> Above message is not clear enough to verify whether CPPC is not supported.
Looks good to me.
Reviewed-by: Gautham R. Shenoy <[email protected]>
>
> Reviewed-by: Mario Limonciello <[email protected]>
> Signed-off-by: Perry Yuan <[email protected]>
> ---
> drivers/acpi/cppc_acpi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index a50e70abdf19..e23a84f4a50a 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -679,8 +679,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
>
> if (!osc_sb_cppc2_support_acked) {
> pr_debug("CPPC v2 _OSC not acked\n");
> - if (!cpc_supported_by_cpu())
> + if (!cpc_supported_by_cpu()) {
> + pr_debug("CPPC is not supported by the CPU\n");
> return -ENODEV;
> + }
> }
>
> /* Parse the ACPI _CPC table for this CPU. */
> --
> 2.34.1
>
On Thu, Feb 08, 2024 at 11:46:33AM +0800, Perry Yuan wrote:
> Add quirks table to get CPPC capabilities issue fixed by providing
> correct perf or frequency values while driver loading.
>
> If CPPC capabilities are not defined in the ACPI tables or wrongly
> defined by platform firmware, it needs to use quick to get those
> issues fixed with correct workaround values to make pstate driver
> can be loaded even though there are CPPC capabilities errors.
>
> The workaround will match the broken BIOS which lack of CPPC capabilities
> nominal_freq and lowest_freq definition in the ACPI table.
>
> $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq
> 0
> $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
> 0
I am ok with this patch as it makes the nominal and min frequency
values explicit for older BIOSes which do support CPPC but only v2.
However, it can be noted that even those older BIOSes are likely to
have the ACPI _PSS data. From this we can look into the P0 frequency,
which could be used as a stand-in for the nominal frequency (We
already do that in acpi_cpufreq_cpu_init() while computing the maximum
frequency). All the other frequencies can be computed in relation to
that.
Reviewed-by: Gautham R. Shenoy <[email protected]>
--
Thanks and Regards
gautham.
>
> Reviewed-by: Mario Limonciello <[email protected]>
> Signed-off-by: Perry Yuan <[email protected]>
> ---
> drivers/cpufreq/amd-pstate.c | 57 ++++++++++++++++++++++++++++++++++--
> include/linux/amd-pstate.h | 6 ++++
> 2 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 77effc3caf6c..ff4727c22dce 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;
> static int cppc_state = AMD_PSTATE_UNDEFINED;
> static bool cppc_enabled;
> static bool amd_pstate_prefcore = true;
> +static struct quirk_entry *quirks;
>
> /*
> * AMD Energy Preference Performance (EPP)
> @@ -111,6 +112,41 @@ static unsigned int epp_values[] = {
>
> typedef int (*cppc_mode_transition_fn)(int);
>
> +static struct quirk_entry quirk_amd_7k62 = {
> + .nominal_freq = 2600,
> + .lowest_freq = 550,
> +};
> +
> +static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
> +{
> + /**
> + * match the broken bios for family 17h processor support CPPC V2
> + * broken BIOS lack of nominal_freq and lowest_freq capabilities
> + * definition in ACPI tables
> + */
> + if (boot_cpu_has(X86_FEATURE_ZEN2)) {
> + quirks = dmi->driver_data;
> + pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> + {
> + .callback = dmi_matched_7k62_bios_bug,
> + .ident = "AMD EPYC 7K62",
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VERSION, "5.14"),
> + DMI_MATCH(DMI_BIOS_RELEASE, "12/12/2019"),
> + },
> + .driver_data = &quirk_amd_7k62,
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
> +
> static inline int get_mode_idx_from_str(const char *str, size_t size)
> {
> int i;
> @@ -600,13 +636,19 @@ static void amd_pstate_adjust_perf(unsigned int cpu,
> static int amd_get_min_freq(struct amd_cpudata *cpudata)
> {
> struct cppc_perf_caps cppc_perf;
> + u32 lowest_freq;
>
> int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
> if (ret)
> return ret;
>
> + if (quirks && quirks->lowest_freq)
> + lowest_freq = quirks->lowest_freq;
> + else
> + lowest_freq = cppc_perf.lowest_freq;
> +
> /* Switch to khz */
> - return cppc_perf.lowest_freq * 1000;
> + return lowest_freq * 1000;
> }
>
> static int amd_get_max_freq(struct amd_cpudata *cpudata)
> @@ -635,12 +677,18 @@ static int amd_get_max_freq(struct amd_cpudata *cpudata)
> static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
> {
> struct cppc_perf_caps cppc_perf;
> + u32 nominal_freq;
>
> int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
> if (ret)
> return ret;
>
> - return cppc_perf.nominal_freq;
> + if (quirks && quirks->nominal_freq)
> + nominal_freq = quirks->nominal_freq;
> + else
> + nominal_freq = cppc_perf.nominal_freq;
> +
> + return nominal_freq;
> }
>
> static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
> @@ -1672,6 +1720,11 @@ static int __init amd_pstate_init(void)
> if (cpufreq_get_current_driver())
> return -EEXIST;
>
> + quirks = NULL;
> +
> + /* check if this machine need CPPC quirks */
> + dmi_check_system(amd_pstate_quirks_table);
> +
> switch (cppc_state) {
> case AMD_PSTATE_UNDEFINED:
> /* Disable on the following configs by default:
> diff --git a/include/linux/amd-pstate.h b/include/linux/amd-pstate.h
> index d21838835abd..7b2cbb892fd9 100644
> --- a/include/linux/amd-pstate.h
> +++ b/include/linux/amd-pstate.h
> @@ -124,4 +124,10 @@ static const char * const amd_pstate_mode_string[] = {
> [AMD_PSTATE_GUIDED] = "guided",
> NULL,
> };
> +
> +struct quirk_entry {
> + u32 nominal_freq;
> + u32 lowest_freq;
> +};
> +
> #endif /* _LINUX_AMD_PSTATE_H */
> --
> 2.34.1
>
On Thu, Feb 08, 2024 at 11:46:27AM +0800, Perry Yuan wrote:
> The patch series adds some fixes and enhancements to the AMD pstate
> driver.
Is there any chance you could stop spamming people with your patchset?
102625 O T Feb 02 Perry Yuan ( : 12K|) [PATCH v2 0/6] AMD Pstate Fixes And Enhancements
104232 O T Feb 04 Perry Yuan ( : 12K|) [PATCH v3 0/6] AMD Pstate Fixes And Enhancements
106714 O T Feb 06 Perry Yuan ( : 12K|) [PATCH v4 0/6] AMD Pstate Fixes And Enhancements
107828 O T Feb 07 Perry Yuan ( : 13K|) [PATCH v5 0/6] AMD Pstate Fixes And Enhancements
108745 N T Feb 08 Perry Yuan ( : 13K|) [PATCH v6 0/6] AMD Pstate Fixes And Enhancements
You should send stuff once a week tops, not every other day.
While waiting your can read about it in Documentation/process/submitting-patches.rst
"Don't get discouraged - or impatient
------------------------------------
After you have submitted your change, be patient and wait. Reviewers are
busy people and may not get to your patch right away.
Once upon a time, patches used to disappear into the void without comment,
but the development process works more smoothly than that now. You should
receive comments within a few weeks (typically 2-3); if that does not
happen, make sure that you have sent your patches to the right place.
Wait for a minimum of one week before resubmitting or pinging reviewers
- possibly longer during busy times like merge windows.
It's also ok to resend the patch or the patch series after a couple of
weeks with the word "RESEND" added to the subject line::
[PATCH Vx RESEND] sub/sys: Condensed patch summary
Don't add "RESEND" when you are submitting a modified version of your
patch or patch series - "RESEND" only applies to resubmission of a
patch or patch series which have not been modified in any way from the
previous submission."
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
[AMD Official Use Only - General]
> -----Original Message-----
> From: Borislav Petkov <[email protected]>
> Sent: Thursday, February 8, 2024 5:21 AM
> To: Yuan, Perry <[email protected]>
> Cc: [email protected]; Limonciello, Mario
> <[email protected]>; [email protected]; Huang, Ray
> <[email protected]>; Shenoy, Gautham Ranjal
> <[email protected]>; Deucher, Alexander
> <[email protected]>; Huang, Shimmer
> <[email protected]>; Du, Xiaojian <[email protected]>; Meng,
> Li (Jassmine) <[email protected]>; [email protected]; linux-
> [email protected]
> Subject: Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements
>
> On Thu, Feb 08, 2024 at 11:46:27AM +0800, Perry Yuan wrote:
> > The patch series adds some fixes and enhancements to the AMD pstate
> > driver.
>
> Is there any chance you could stop spamming people with your patchset?
>
> 102625 O T Feb 02 Perry Yuan ( : 12K|) [PATCH v2 0/6] AMD Pstate
> Fixes And Enhancements
> 104232 O T Feb 04 Perry Yuan ( : 12K|) [PATCH v3 0/6] AMD Pstate
> Fixes And Enhancements
> 106714 O T Feb 06 Perry Yuan ( : 12K|) [PATCH v4 0/6] AMD Pstate
> Fixes And Enhancements
> 107828 O T Feb 07 Perry Yuan ( : 13K|) [PATCH v5 0/6] AMD Pstate
> Fixes And Enhancements
> 108745 N T Feb 08 Perry Yuan ( : 13K|) [PATCH v6 0/6] AMD Pstate
> Fixes And Enhancements
>
> You should send stuff once a week tops, not every other day.
>
Why? In this case, there have been a number of review comments which have been addressed in the new revisions of the patch set. Why delay the new revisions? You'll ultimately get the same amount of email just with a much longer latency.
Alex
> While waiting your can read about it in Documentation/process/submitting-
> patches.rst
>
> "Don't get discouraged - or impatient
> ------------------------------------
>
> After you have submitted your change, be patient and wait. Reviewers are
> busy people and may not get to your patch right away.
>
> Once upon a time, patches used to disappear into the void without comment,
> but the development process works more smoothly than that now. You
> should receive comments within a few weeks (typically 2-3); if that does not
> happen, make sure that you have sent your patches to the right place.
> Wait for a minimum of one week before resubmitting or pinging reviewers
> - possibly longer during busy times like merge windows.
>
> It's also ok to resend the patch or the patch series after a couple of weeks with
> the word "RESEND" added to the subject line::
>
> [PATCH Vx RESEND] sub/sys: Condensed patch summary
>
> Don't add "RESEND" when you are submitting a modified version of your
> patch or patch series - "RESEND" only applies to resubmission of a patch or
> patch series which have not been modified in any way from the previous
> submission."
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Feb 08, 2024 at 11:09:47PM +0000, Deucher, Alexander wrote:
> Why?
Because we have those rules, you know. You should send about once a week,
unless you've reworked your set fundamentally.
Otherwise maintainers mailboxes would be a serious mess. Not that
they're already such now...
> In this case, there have been a number of review comments which have
> been addressed in the new revisions of the patch set. Why delay the
> new revisions?
See above.
And see below for the "whopping" differences between the last two.
> You'll ultimately get the same amount of email just with a much longer
> latency.
No, you'll have a lot less email. You send the set, sit tight and
collect review feedback, work it in and send again after a week or so.
diff v5..v6 - definitely not resend one day later just to pick up tags.
-----------
--- v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx 2024-02-09 16:43:29.487104935 +0100
+++ v6_20240208_perry_yuan_amd_pstate_fixes_and_enhancements.mbx 2024-02-09 16:42:55.671303380 +0100
@@ -23,6 +23,7 @@ Reported-by: Gino Badouri <badouri.g@gma
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")
Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Gautham R. Shenoy <[email protected]>
---
arch/x86/kernel/acpi/cppc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -293,6 +294,7 @@ Above message is not clear enough to ver
Reviewed-by: Mario Limonciello <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Gautham R. Shenoy <[email protected]>
---
drivers/acpi/cppc_acpi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -342,8 +344,9 @@ $ cat /sys/devices/system/cpu/cpu0/acpi_
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
0
-Signed-off-by: Perry Yuan <[email protected]>
Reviewed-by: Mario Limonciello <[email protected]>
+Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Gautham R. Shenoy <[email protected]>
---
drivers/cpufreq/amd-pstate.c | 57 ++++++++++++++++++++++++++++++++++--
include/linux/amd-pstate.h | 6 ++++
diff v4..v5 - *definitely* *not* warranting a new resend on the next
day!
-----------
--- v4_20240206_perry_yuan_amd_pstate_fixes_and_enhancements.mbx 2024-02-09 16:43:53.922961536 +0100
+++ v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx 2024-02-09 16:43:29.487104935 +0100
@@ -343,13 +343,14 @@ $ cat /sys/devices/system/cpu/cpu0/acpi_
0
Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Mario Limonciello <[email protected]>
---
- drivers/cpufreq/amd-pstate.c | 59 ++++++++++++++++++++++++++++++++++--
+ drivers/cpufreq/amd-pstate.c | 57 ++++++++++++++++++++++++++++++++++--
include/linux/amd-pstate.h | 6 ++++
- 2 files changed, 63 insertions(+), 2 deletions(-)
+ 2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
-index 77effc3caf6c..874d8b663790 100644
+index 77effc3caf6c..ff4727c22dce 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;
@@ -372,18 +373,16 @@ index 77effc3caf6c..874d8b663790 100644
+static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
+{
+ /**
-+ * match the broken bios for family 17h, model 31h processor
++ * match the broken bios for family 17h processor support CPPC V2
+ * broken BIOS lack of nominal_freq and lowest_freq capabilities
+ * definition in ACPI tables
+ */
-+ if (boot_cpu_data.x86 == 0x17 && boot_cpu_data.x86_model == 0x31 &&
-+ boot_cpu_has(X86_FEATURE_ZEN2)) {
++ if (boot_cpu_has(X86_FEATURE_ZEN2)) {
+ quirks = dmi->driver_data;
-+ pr_info("hardware type %s found\n", dmi->ident);
++ pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
+ return 1;
+ }
+
-+
+ return 0;
+}
+
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
[Public]
> -----Original Message-----
> From: Borislav Petkov <[email protected]>
> Sent: Friday, February 9, 2024 10:51 AM
> To: Deucher, Alexander <[email protected]>
> Cc: Yuan, Perry <[email protected]>; [email protected];
> Limonciello, Mario <[email protected]>; [email protected];
> Huang, Ray <[email protected]>; Shenoy, Gautham Ranjal
> <[email protected]>; Huang, Shimmer
> <[email protected]>; Du, Xiaojian <[email protected]>; Meng,
> Li (Jassmine) <[email protected]>; [email protected]; linux-
> [email protected]
> Subject: Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements
>
> On Thu, Feb 08, 2024 at 11:09:47PM +0000, Deucher, Alexander wrote:
> > Why?
>
> Because we have those rules, you know. You should send about once a week,
> unless you've reworked your set fundamentally.
>
My reading of the rules is that you should wait before resending or pinging if you have not received feedback. If you are actively receiving feedback, to me, it makes sense to rapidly iterate. If a patch is reviewed and comments are addressed, it can land rather than waiting an extra week or two.
> Otherwise maintainers mailboxes would be a serious mess. Not that they're
> already such now...
>
> > In this case, there have been a number of review comments which have
> > been addressed in the new revisions of the patch set. Why delay the
> > new revisions?
>
> See above.
>
> And see below for the "whopping" differences between the last two.
>
> > You'll ultimately get the same amount of email just with a much longer
> > latency.
>
> No, you'll have a lot less email. You send the set, sit tight and collect review
> feedback, work it in and send again after a week or so.
It also adds extra latency. With my maintainer hat on, I'd like to have new revisions rapidly. I guess it comes down to personal preference, but I don't do well with task switching. When a patch set is fresh in my mind, I'd rather see it finished off and committed sooner rather than lingering and then a week or two later, I'd need to page the whole discussion back into my head to make sure everything was addressed and all the tags were collected.
Alex
>
> diff v5..v6 - definitely not resend one day later just to pick up tags.
> -----------
> --- v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
> 2024-02-09 16:43:29.487104935 +0100
> +++ v6_20240208_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
> 2024-02-09 16:42:55.671303380 +0100
> @@ -23,6 +23,7 @@ Reported-by: Gino Badouri <badouri.g@gma
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
> Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with
> shared memory")
> Signed-off-by: Perry Yuan <[email protected]>
> +Reviewed-by: Gautham R. Shenoy <[email protected]>
> ---
> arch/x86/kernel/acpi/cppc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-) @@ -293,6 +294,7 @@ Above
> message is not clear enough to ver
>
> Reviewed-by: Mario Limonciello <[email protected]>
> Signed-off-by: Perry Yuan <[email protected]>
> +Reviewed-by: Gautham R. Shenoy <[email protected]>
> ---
> drivers/acpi/cppc_acpi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-) @@ -342,8 +344,9 @@ $ cat
> /sys/devices/system/cpu/cpu0/acpi_
> $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
> 0
>
> -Signed-off-by: Perry Yuan <[email protected]>
> Reviewed-by: Mario Limonciello <[email protected]>
> +Signed-off-by: Perry Yuan <[email protected]>
> +Reviewed-by: Gautham R. Shenoy <[email protected]>
> ---
> drivers/cpufreq/amd-pstate.c | 57
> ++++++++++++++++++++++++++++++++++--
> include/linux/amd-pstate.h | 6 ++++
>
>
> diff v4..v5 - *definitely* *not* warranting a new resend on the next day!
> -----------
> --- v4_20240206_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
> 2024-02-09 16:43:53.922961536 +0100
> +++ v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
> 2024-02-09 16:43:29.487104935 +0100
> @@ -343,13 +343,14 @@ $ cat /sys/devices/system/cpu/cpu0/acpi_
> 0
>
> Signed-off-by: Perry Yuan <[email protected]>
> +Reviewed-by: Mario Limonciello <[email protected]>
> ---
> - drivers/cpufreq/amd-pstate.c | 59
> ++++++++++++++++++++++++++++++++++--
> + drivers/cpufreq/amd-pstate.c | 57
> ++++++++++++++++++++++++++++++++++--
> include/linux/amd-pstate.h | 6 ++++
> - 2 files changed, 63 insertions(+), 2 deletions(-)
> + 2 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c -
> index 77effc3caf6c..874d8b663790 100644
> +index 77effc3caf6c..ff4727c22dce 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;
> @@ -372,18 +373,16 @@ index 77effc3caf6c..874d8b663790 100644
> +static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id
> *dmi) +{
> + /**
> -+ * match the broken bios for family 17h, model 31h processor
> ++ * match the broken bios for family 17h processor support CPPC V2
> + * broken BIOS lack of nominal_freq and lowest_freq capabilities
> + * definition in ACPI tables
> + */
> -+ if (boot_cpu_data.x86 == 0x17 && boot_cpu_data.x86_model ==
> 0x31 &&
> -+ boot_cpu_has(X86_FEATURE_ZEN2)) {
> ++ if (boot_cpu_has(X86_FEATURE_ZEN2)) {
> + quirks = dmi->driver_data;
> -+ pr_info("hardware type %s found\n", dmi->ident);
> ++ pr_info("Overriding nominal and lowest frequencies for
> %s\n",
> ++dmi->ident);
> + return 1;
> + }
> +
> -+
> + return 0;
> +}
> +
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Feb 09, 2024 at 05:33:35PM +0000, Deucher, Alexander wrote:
> My reading of the rules is that you should wait before resending or
> pinging if you have not received feedback.
But the feedback you've received is not the whole feedback. Someone
might want to review them but not have the time right now. So at the
time we did agree that a week is kinda ok to let people have a look.
And from experience reviewers tend to ignore patchsets which get resent
rapidly.
> If you are actively receiving feedback, to me, it makes sense to
> rapidly iterate. If a patch is reviewed and comments are addressed,
> it can land rather than waiting an extra week or two.
There's the other problem - if you keep dealing with only a single
patchset, all the others who are waiting get starved. I, for example,
try to have at least some fairness when it comes to looking at people's
submissions and round-robin between them as much as I can.
> It also adds extra latency. With my maintainer hat on, I'd like to
> have new revisions rapidly. I guess it comes down to personal
> preference, but I don't do well with task switching.
I know *exactly* what you mean. I usually read my replies to the
previous submissions in order to swap in everything I was pointing at
the last time...
Can you review it all? Definitely not. :-\
> When a patch set is fresh in my mind, I'd rather see it finished off
> and committed sooner rather than lingering and then a week or two
> later, I'd need to page the whole discussion back into my head to make
> sure everything was addressed and all the tags were collected.
Yeah, I definitely see your point. But there are also those other
things I mentioned. I think one could find a good balance between the
two...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Feb 8, 2024 at 6:56 AM Gautham R. Shenoy <[email protected]> wrote:
>
> Hello Perry,
>
> On Thu, Feb 08, 2024 at 11:46:28AM +0800, Perry Yuan wrote:
> > As there are some AMD processors which only support CPPC V2 firmware and
> > BIOS implementation, the amd_pstate driver will be failed to load when
> > system booting with below kernel warning message:
> >
> > [ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
> >
> > To make the amd_pstate driver can be loaded on those TR40 processors, it
> > needs to match x86_model from 0x30 to 0x7F for family 17H.
> > With the change, the system can load amd_pstate driver as expected.
> >
> > Reviewed-by: Mario Limonciello <[email protected]>
> > Reported-by: Gino Badouri <[email protected]>
> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
> > Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")
> > Signed-off-by: Perry Yuan <[email protected]>
> > ---
> > arch/x86/kernel/acpi/cppc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
> > index 8d8752b44f11..ff8f25faca3d 100644
> > --- a/arch/x86/kernel/acpi/cppc.c
> > +++ b/arch/x86/kernel/acpi/cppc.c
> > @@ -20,7 +20,7 @@ bool cpc_supported_by_cpu(void)
> > (boot_cpu_data.x86_model >= 0x20 && boot_cpu_data.x86_model <= 0x2f)))
> > return true;
> > else if (boot_cpu_data.x86 == 0x17 &&
> > - boot_cpu_data.x86_model >= 0x70 && boot_cpu_data.x86_model <= 0x7f)
> > + boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x7f)
>
> This looks ok to me.
> Reviewed-by: Gautham R. Shenoy <[email protected]>
Applied as 6.9 material, thanks!
However, I'm not sure what to do with the rest of the series. It
doesn't appear to be ready yet as they are comments that need
addressing AFAICS.
On 2/8/2024 11:37 AM, Gautham R. Shenoy wrote:
> On Thu, Feb 08, 2024 at 11:46:29AM +0800, Perry Yuan wrote:
>> Address an untested error where the nominal_freq was returned in KHz
>> instead of the correct MHz units, this oversight led to a wrong
>> nominal_freq set and resued, it will cause the max frequency of core to
>> be initialized with a wrong frequency value.
>
> The _CPC object on my Zen2 EPYC server which has CPPC v3, I see :
> 0x00000190, //LowestFrequency
> 0x000007D0 //NominalFrequency
> })
> }
>
> where 0x7D0 is 2000 Mhz. Thus the value returend by cppc_perf.nominal_freq is in Mhz.
>
> In this patch, we are changing making amd_get_nominal_freq() return
> 2000 (Mhz) instead of 2000000 (Khz) as it was doing previously.
>
> amd_get_min_freq(), amd_get_max_freq(),
> amd_get_lowest_nonlinear_perf() -all these functions return the
> frequency in Khz units.
>
> These functions are used the initialize the value of
> cpudata->max_freq, cpu_data->min_freq, .... all of which are in Khz
> units.
>
> In, amd_pstate_set_boost(), we have:
>
>
> if (state)
> policy->cpuinfo.max_freq = cpudata->max_freq; <---- In Khz
> else
> policy->cpuinfo.max_freq = cpudata->nominal_freq; <--- Now in Mhz
>
> Since policy->cpuinfo.max_freq is expected to be in Khz, isn't this
> patch introducing an error ? Or perhaps this patch series is based on
> another patchset ?
>
> --
> Thanks and Regards
> gautham.
>
>
I can confirm on Gautham's comment, when boost is disabled with the scaling
driver set as amd-pstate, the max frequency reported is incorrect, as it
shows the frequency in MHz.
I tested this patch on Zen4 Genoa server platform, below are the
inconsistent min and max frequencies I observed.
[cpufreq]# grep . *freq
amd_pstate_lowest_nonlinear_freq:1804000
amd_pstate_max_freq:3514000
cpuinfo_max_freq:2151
cpuinfo_min_freq:400000
scaling_cur_freq:2151
scaling_max_freq:2151
scaling_min_freq:2151
[cpufreq]# pwd
/sys/devices/system/cpu/cpu0/cpufreq
According to Documentation/admin-guide/pm/cpufreq.rst, all the frequency
values need to be in KHz.
Thanks,
Dhananjay
>>
>> Cc: [email protected]
>> Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
>> Reviewed-by: Mario Limonciello <[email protected]>
>> Signed-off-by: Perry Yuan <[email protected]>
>> ---
>> drivers/cpufreq/amd-pstate.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>> index 08e112444c27..ac7faa98a450 100644
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@ -640,8 +640,7 @@ static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
>> if (ret)
>> return ret;
>>
>> - /* Switch to khz */
>> - return cppc_perf.nominal_freq * 1000;
>> + return cppc_perf.nominal_freq;
>> }
>>
>> static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
>> --
>> 2.34.1
>>