2020-12-11 10:12:09

by Punit Agrawal

[permalink] [raw]
Subject: [PATCH 0/2] Add processor to the ignore PSD override list

Hi,

Here's an update of the previously posted patches at [0].

Patch 1 refactors the test to ignore firmware provided frequency
domain into a separate function.

Patch 2 adds the APU (Family: 0x17, Model: 0x60, Stepping: 0x01) to
the list of CPUs for which the PSD override is ignored. In the absence
of clarity regarding the affected CPUs, the patch adds the CPU by
model numbers.

Thanks,
Punit

Changes since RFC:
* Dropped patches 3 and 4 to add macros for AMD processor families due
to lack of interest
* Patch 1
- renamed override_acpi_psd() to amd_override_acpi_psd()
- Changed return value of the function to bool

Punit Agrawal (2):
cpufreq: acpi-cpufreq: Re-factor overriding ACPI PSD
cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list

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

--
2.29.2


2020-12-11 10:12:09

by Punit Agrawal

[permalink] [raw]
Subject: [PATCH 1/2] cpufreq: acpi-cpufreq: Re-factor overriding ACPI PSD

Re-factor the code to override the firmware provided frequency domain
information (via PSD) to localise the checks in one function.

No functional change intended.

Signed-off-by: Punit Agrawal <[email protected]>
Cc: Wei Huang <[email protected]>
---
drivers/cpufreq/acpi-cpufreq.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 1e4fbb002a31..126315ad225f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -191,6 +191,20 @@ static int check_amd_hwpstate_cpu(unsigned int cpuid)
return cpu_has(cpu, X86_FEATURE_HW_PSTATE);
}

+static bool amd_override_acpi_psd(unsigned int cpu_id)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
+ if (c->x86_vendor == X86_VENDOR_AMD) {
+ if (!check_amd_hwpstate_cpu(cpu_id))
+ return false;
+
+ return c->x86 < 0x19;
+ }
+
+ return false;
+}
+
static unsigned extract_io(struct cpufreq_policy *policy, u32 value)
{
struct acpi_cpufreq_data *data = policy->driver_data;
@@ -691,8 +705,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
cpumask_copy(policy->cpus, topology_core_cpumask(cpu));
}

- if (check_amd_hwpstate_cpu(cpu) && boot_cpu_data.x86 < 0x19 &&
- !acpi_pstate_strict) {
+ if (amd_override_acpi_psd(cpu) && !acpi_pstate_strict) {
cpumask_clear(policy->cpus);
cpumask_set_cpu(cpu, policy->cpus);
cpumask_copy(data->freqdomain_cpus,
--
2.29.2

2020-12-11 15:50:21

by Punit Agrawal

[permalink] [raw]
Subject: [PATCH 2/2] cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list

Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
stepping: 0x1) shows the following message in the logs -

acpi_cpufreq: overriding BIOS provided _PSD data

Although commit 5368512abe08 ("acpi-cpufreq: Honor _PSD table setting
on new AMD CPUs") indicates that the override is not required for Zen3
onwards, it seems that domain information can be trusted even on
certain earlier systems. Update the check, to skip the override for
Zen2 processors known to work without the override.

Signed-off-by: Punit Agrawal <[email protected]>
Cc: Wei Huang <[email protected]>
---
drivers/cpufreq/acpi-cpufreq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 126315ad225f..32b6449a438b 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -198,8 +198,13 @@ static bool amd_override_acpi_psd(unsigned int cpu_id)
if (c->x86_vendor == X86_VENDOR_AMD) {
if (!check_amd_hwpstate_cpu(cpu_id))
return false;
-
- return c->x86 < 0x19;
+ /*
+ * CPU's before Zen3 (except some Zen2) need the
+ * override.
+ */
+ return (c->x86 < 0x19) &&
+ !(c->x86 == 0x17 && c->x86_model == 0x60 &&
+ c->x86_stepping == 0x1);
}

return false;
--
2.29.2

2020-12-11 15:54:32

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH 2/2] cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list

On Fri, Dec 11, 2020 at 07:56:40AM +0900, Punit Agrawal wrote:
> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
> stepping: 0x1) shows the following message in the logs -
>
> acpi_cpufreq: overriding BIOS provided _PSD data
>
> Although commit 5368512abe08 ("acpi-cpufreq: Honor _PSD table setting
> on new AMD CPUs") indicates that the override is not required for Zen3
> onwards, it seems that domain information can be trusted even on
> certain earlier systems. Update the check, to skip the override for
> Zen2 processors known to work without the override.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Cc: Wei Huang <[email protected]>
> ---
> drivers/cpufreq/acpi-cpufreq.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)

What about answers to those questions first?

https://lkml.kernel.org/r/[email protected]

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

2020-12-13 06:10:10

by Punit Agrawal

[permalink] [raw]
Subject: Re: [PATCH 2/2] cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list

Borislav Petkov <[email protected]> writes:

> On Fri, Dec 11, 2020 at 07:56:40AM +0900, Punit Agrawal wrote:
>> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
>> stepping: 0x1) shows the following message in the logs -
>>
>> acpi_cpufreq: overriding BIOS provided _PSD data
>>
>> Although commit 5368512abe08 ("acpi-cpufreq: Honor _PSD table setting
>> on new AMD CPUs") indicates that the override is not required for Zen3
>> onwards, it seems that domain information can be trusted even on
>> certain earlier systems. Update the check, to skip the override for
>> Zen2 processors known to work without the override.
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Cc: Wei Huang <[email protected]>
>> ---
>> drivers/cpufreq/acpi-cpufreq.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> What about answers to those questions first?
>
> https://lkml.kernel.org/r/[email protected]

Oh.. sorry I missed that mail for some reason. Let's continue
there.