[PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Perry Yuan]

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/63c2b3d7-083a-4daa-ba40-629b3223a92d@mailbox.org/
V2: https://lore.kernel.org/all/cover.1706863981.git.perry.yuan@amd.com/
v3: https://lore.kernel.org/lkml/cover.1707016927.git.perry.yuan@amd.com/
v4: https://lore.kernel.org/lkml/cover.1707193566.git.perry.yuan@amd.com/
v5: https://lore.kernel.org/lkml/cover.1707273526.git.perry.yuan@amd.com/

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

[PATCH v6 1/6] ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors

[Perry Yuan]

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 <mario.limonciello@amd.com>
Reported-by: Gino Badouri <badouri.g@gmail.com>
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 <perry.yuan@amd.com>
---
 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

[PATCH v6 2/6] cpufreq:amd-pstate: fix the nominal freq value set

[Perry Yuan]

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: stable@vger.kernel.org
Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
---
 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

[PATCH v6 3/6] cpufreq:amd-pstate: initialize nominal_freq of each cpudata

[Perry Yuan]

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 <mario.limonciello@amd.com>
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
---
 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

[PATCH v6 4/6] cpufreq:amd-pstate: get pstate transition delay and latency value from ACPI tables

[Perry Yuan]

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 <mario.limonciello@amd.com>
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
---
 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

[PATCH v6 5/6] cppc_acpi: print error message if CPPC is unsupported

[Perry Yuan]

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 <mario.limonciello@amd.com>
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
---
 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

[PATCH v6 6/6] cpufreq:amd-pstate: add quirk for the pstate CPPC capabilities missing

[Perry Yuan]

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 <mario.limonciello@amd.com>
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
---
 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

Re: [PATCH v6 1/6] ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors

[Gautham R. Shenoy]

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 <mario.limonciello@amd.com>
> Reported-by: Gino Badouri <badouri.g@gmail.com>
> 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 <perry.yuan@amd.com>
> ---
>  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 <gautham.shenoy@amd.com>

--
Thanks and Regards
gautham.

Re: [PATCH v6 2/6] cpufreq:amd-pstate: fix the nominal freq value set

[Gautham R. Shenoy]

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: stable@vger.kernel.org
> Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> ---
>  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
> 

Re: [PATCH v6 3/6] cpufreq:amd-pstate: initialize nominal_freq of each cpudata

[Gautham R. Shenoy]

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 <mario.limonciello@amd.com>
> Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> ---
>  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.

Re: [PATCH v6 5/6] cppc_acpi: print error message if CPPC is unsupported

[Gautham R. Shenoy]

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 <gautham.shenoy@amd.com>

> 
> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> ---
>  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
> 

Re: [PATCH v6 6/6] cpufreq:amd-pstate: add quirk for the pstate CPPC capabilities missing

[Gautham R. Shenoy]

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 <gautham.shenoy@amd.com>
--
Thanks and Regards
gautham.

> 
> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> ---
>  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
> 

Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Borislav Petkov]

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

RE: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Deucher, Alexander]

[AMD Official Use Only - General]

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: Thursday, February 8, 2024 5:21 AM
> To: Yuan, Perry <Perry.Yuan@amd.com>
> Cc: rafael.j.wysocki@intel.com; Limonciello, Mario
> <Mario.Limonciello@amd.com>; viresh.kumar@linaro.org; Huang, Ray
> <Ray.Huang@amd.com>; Shenoy, Gautham Ranjal
> <gautham.shenoy@amd.com>; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Huang, Shimmer
> <Shimmer.Huang@amd.com>; Du, Xiaojian <Xiaojian.Du@amd.com>; Meng,
> Li (Jassmine) <Li.Meng@amd.com>; linux-pm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> 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

Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Borislav Petkov]

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 <perry.yuan@amd.com>
+Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
 ---
  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 <mario.limonciello@amd.com>
 Signed-off-by: Perry Yuan <perry.yuan@amd.com>
+Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
 ---
  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 <perry.yuan@amd.com>
 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Perry Yuan <perry.yuan@amd.com>
+Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
 ---
  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 <perry.yuan@amd.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
 ---
- 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

RE: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Deucher, Alexander]

[Public]

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: Friday, February 9, 2024 10:51 AM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>
> Cc: Yuan, Perry <Perry.Yuan@amd.com>; rafael.j.wysocki@intel.com;
> Limonciello, Mario <Mario.Limonciello@amd.com>; viresh.kumar@linaro.org;
> Huang, Ray <Ray.Huang@amd.com>; Shenoy, Gautham Ranjal
> <gautham.shenoy@amd.com>; Huang, Shimmer
> <Shimmer.Huang@amd.com>; Du, Xiaojian <Xiaojian.Du@amd.com>; Meng,
> Li (Jassmine) <Li.Meng@amd.com>; linux-pm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> 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 <perry.yuan@amd.com>
> +Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
>  ---
>   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 <mario.limonciello@amd.com>
>  Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> +Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
>  ---
>   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 <perry.yuan@amd.com>
>  Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> +Signed-off-by: Perry Yuan <perry.yuan@amd.com>
> +Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
>  ---
>   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 <perry.yuan@amd.com>
> +Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
>  ---
> - 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

Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

[Borislav Petkov]

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

Re: [PATCH v6 1/6] ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors

[Rafael J. Wysocki]

On Thu, Feb 8, 2024 at 6:56 AM Gautham R. Shenoy <gautham.shenoy@amd.com> 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 <mario.limonciello@amd.com>
> > Reported-by: Gino Badouri <badouri.g@gmail.com>
> > 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 <perry.yuan@amd.com>
> > ---
> >  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 <gautham.shenoy@amd.com>

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.

Re: [PATCH v6 2/6] cpufreq:amd-pstate: fix the nominal freq value set

[Ugwekar, Dhananjay]

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: stable@vger.kernel.org
>> Fixes: ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
>> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Perry Yuan <perry.yuan@amd.com>
>> ---
>>  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
>>