Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org ---
Changes from V1 -> V2: - Enhance the commit message. - Move amd_get_highest_perf() into amd.c. - Refine the implementation of switch-case. - Cc stable mail list.
Changes from V2 -> V3: - Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
--- arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } } + +u32 amd_get_highest_perf(void) +{ + struct cpuinfo_x86 *c = &boot_cpu_data; + u32 cppc_max_perf = 225; + + switch (c->x86) { + case 0x17: + if ((c->x86_model >= 0x30 && c->x86_model < 0x40) || + (c->x86_model >= 0x70 && c->x86_model < 0x80)) + cppc_max_perf = 166; + break; + case 0x19: + if ((c->x86_model >= 0x20 && c->x86_model < 0x30) || + (c->x86_model >= 0x40 && c->x86_model < 0x70)) + cppc_max_perf = 166; + break; + } + + return cppc_max_perf; +} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
- cpc_read(cpunum, highest_reg, &high); - perf_caps->highest_perf = high; + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) { + perf_caps->highest_perf = amd_get_highest_perf(); + } else { + cpc_read(cpunum, highest_reg, &high); + perf_caps->highest_perf = high; + }
cpc_read(cpunum, lowest_reg, &low); perf_caps->lowest_perf = low;
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
perf_caps->highest_perf = amd_get_highest_perf();} else {cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;} cpc_read(cpunum, lowest_reg, &low); perf_caps->lowest_perf = low;-- 2.25.1
On Fri, Apr 23, 2021 at 08:09:49PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ $B"*(B lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.k... Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
OK, I see, it will be used by ARM as well.
Can I rollback to implementation of V2:
https://lore.kernel.org/r/20210421023807.1540290-1-ray.huang@amd.com
If stick to add quirk in cppc_acpi.c and avoid x86-specific check at the same time here, the code will not be straight forward. Or will you have any other good idea?
Thanks, Ray
On Fri, Apr 23, 2021 at 2:52 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 08:09:49PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ $B"* (B lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.k... Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
OK, I see, it will be used by ARM as well.
Can I rollback to implementation of V2:
https://lore.kernel.org/r/20210421023807.1540290-1-ray.huang@amd.com
This would work IMO, but it can be simplified somewhat AFAICS.
The obvious drawback is that amd_get_highest_perf() would need to be called directly wherever the CPPC highest perf is needed and the vendor may be AMD.
If stick to add quirk in cppc_acpi.c and avoid x86-specific check at the same time here, the code will not be straight forward. Or will you have any other good idea?
Not at the moment, sorry.
On Fri, Apr 23, 2021 at 09:53:37PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 2:52 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 08:09:49PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ $B"* (B lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.k... Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
OK, I see, it will be used by ARM as well.
Can I rollback to implementation of V2:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...
This would work IMO, but it can be simplified somewhat AFAICS.
The obvious drawback is that amd_get_highest_perf() would need to be called directly wherever the CPPC highest perf is needed and the vendor may be AMD.
Should I send V4 to continue review (fallback to V2 actually) or you can comment it on V2 directly?
If stick to add quirk in cppc_acpi.c and avoid x86-specific check at the same time here, the code will not be straight forward. Or will you have any other good idea?
Not at the moment, sorry.
No problem, thanks for your time and comments. :-)
Thanks, Ray
On Fri, Apr 23, 2021 at 5:07 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 09:53:37PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 2:52 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 08:09:49PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ $B"* (B lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.k... Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
OK, I see, it will be used by ARM as well.
Can I rollback to implementation of V2:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...
This would work IMO, but it can be simplified somewhat AFAICS.
The obvious drawback is that amd_get_highest_perf() would need to be called directly wherever the CPPC highest perf is needed and the vendor may be AMD.
Should I send V4 to continue review (fallback to V2 actually) or you can comment it on V2 directly?
Done, thanks!
On Fri, Apr 23, 2021 at 11:20:37PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 5:07 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 09:53:37PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 2:52 PM Huang Rui ray.huang@amd.com wrote:
On Fri, Apr 23, 2021 at 08:09:49PM +0800, Rafael J. Wysocki wrote:
On Fri, Apr 23, 2021 at 4:40 AM Huang Rui ray.huang@amd.com wrote:
Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:
~ $B"* (B lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.k... Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.
arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 22 ++++++++++++++++++++++ drivers/acpi/cppc_acpi.c | 8 ++++++-- 3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..aadb691d9357 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,25 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }
+u32 amd_get_highest_perf(void) +{
struct cpuinfo_x86 *c = &boot_cpu_data;u32 cppc_max_perf = 225;switch (c->x86) {case 0x17:if ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||(c->x86_model >= 0x70 && c->x86_model < 0x80))cppc_max_perf = 166;break;case 0x19:if ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||(c->x86_model >= 0x40 && c->x86_model < 0x70))cppc_max_perf = 166;break;}return cppc_max_perf;+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 69057fcd2c04..58e72b6e222f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1107,8 +1107,12 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) } }
cpc_read(cpunum, highest_reg, &high);perf_caps->highest_perf = high;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {This is a generic arch-independent file.
Can we avoid adding the x86-specific check here?
OK, I see, it will be used by ARM as well.
Can I rollback to implementation of V2:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...
This would work IMO, but it can be simplified somewhat AFAICS.
The obvious drawback is that amd_get_highest_perf() would need to be called directly wherever the CPPC highest perf is needed and the vendor may be AMD.
Should I send V4 to continue review (fallback to V2 actually) or you can comment it on V2 directly?
Done, thanks!
Thank you!
Ray
linux-stable-mirror@lists.linaro.org
-
Huang Rui -
Rafael J. Wysocki