|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2 |
|
| #
b4cc466b |
| 08-Dec-2024 |
Mario Limonciello <[email protected]> |
cpufreq/amd-pstate: Replace all AMD_CPPC_* macros with masks
Bitfield masks are easier to follow and less error prone.
Reviewed-by: Dhananjay Ugwekar <[email protected]> Reviewed-by: Gautha
cpufreq/amd-pstate: Replace all AMD_CPPC_* macros with masks
Bitfield masks are easier to follow and less error prone.
Reviewed-by: Dhananjay Ugwekar <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
c9e6f7fb |
| 11-Feb-2025 |
Mario Limonciello <[email protected]> |
x86/ACPI: CPPC: Add missing include
Some minimial kernel configurations will fail with -Werror=implicit-function-declaration due to a missing header include.
Add that header.
Signed-off-by: Mario
x86/ACPI: CPPC: Add missing include
Some minimial kernel configurations will fail with -Werror=implicit-function-declaration due to a missing header include.
Add that header.
Signed-off-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc1, v6.12, v6.12-rc7 |
|
| #
b79276dc |
| 04-Nov-2024 |
Mario Limonciello <[email protected]> |
ACPI: processor: Move arch_init_invariance_cppc() call later
arch_init_invariance_cppc() is called at the end of acpi_cppc_processor_probe() in order to configure frequency invariance based upon the
ACPI: processor: Move arch_init_invariance_cppc() call later
arch_init_invariance_cppc() is called at the end of acpi_cppc_processor_probe() in order to configure frequency invariance based upon the values from _CPC.
This however doesn't work on AMD CPPC shared memory designs that have AMD preferred cores enabled because _CPC needs to be analyzed from all cores to judge if preferred cores are enabled.
This issue manifests to users as a warning since commit 21fb59ab4b97 ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"): ``` Could not retrieve highest performance (-19) ```
However the warning isn't the cause of this, it was actually commit 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") which exposed the issue.
To fix this problem, change arch_init_invariance_cppc() into a new weak symbol that is called at the end of acpi_processor_driver_init(). Each architecture that supports it can declare the symbol to override the weak one.
Define it for x86, in arch/x86/kernel/acpi/cppc.c, and for all of the architectures using the generic arch_topology.c code.
Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") Reported-by: Ivan Shapovalov <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219431 Tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc6, v6.12-rc5 |
|
| #
3eef25ab |
| 25-Oct-2024 |
Mario Limonciello <[email protected]> |
x86/amd: Use heterogeneous core topology for identifying boost numerator
AMD heterogeneous designs include two types of cores:
* Performance * Efficiency
Each core type has different highest per
x86/amd: Use heterogeneous core topology for identifying boost numerator
AMD heterogeneous designs include two types of cores:
* Performance * Efficiency
Each core type has different highest performance values configured by the platform. Drivers such as amd_pstate need to identify the type of core to correctly set an appropriate boost numerator to calculate the maximum frequency.
X86_FEATURE_AMD_HETEROGENEOUS_CORES is used to identify whether the SoC supports heterogeneous core type by reading CPUID leaf Fn_0x80000026.
On performance cores the scaling factor of 196 is used. On efficiency cores the scaling factor is the value reported as the highest perf. Efficiency cores have the same preferred core rankings.
Suggested-by: Perry Yuan <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6 |
|
| #
ad4caad5 |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
cpufreq: amd-pstate: Merge amd_pstate_highest_perf_set() into amd_get_boost_ratio_numerator()
The special case in amd_pstate_highest_perf_set() is the value used for calculating the boost numerator.
cpufreq: amd-pstate: Merge amd_pstate_highest_perf_set() into amd_get_boost_ratio_numerator()
The special case in amd_pstate_highest_perf_set() is the value used for calculating the boost numerator. Merge this into amd_get_boost_ratio_numerator() and then use that to calculate boost ratio.
This allows dropping more special casing of the highest perf value.
Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
279f838a |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()
AMD systems that support preferred cores will use "166" as their numerator for max frequency calculations instead of "255".
Add a
x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()
AMD systems that support preferred cores will use "166" as their numerator for max frequency calculations instead of "255".
Add a function for detecting preferred cores by looking at the highest perf value on all cores.
If preferred cores are enabled return 166 and if disabled the value in the highest perf register. As the function will be called multiple times, cache the values for the boost numerator and if preferred cores will be enabled in global variables.
Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
2819bfef |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
x86/amd: Move amd_get_highest_perf() out of amd-pstate
amd_pstate_get_highest_perf() is a helper used to get the highest perf value on AMD systems. It's used in amd-pstate as part of preferred core
x86/amd: Move amd_get_highest_perf() out of amd-pstate
amd_pstate_get_highest_perf() is a helper used to get the highest perf value on AMD systems. It's used in amd-pstate as part of preferred core handling, but applicable for acpi-cpufreq as well.
Move it out to cppc handling code as amd_get_highest_perf().
Reviewed-by: Perry Yuan <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
21fb59ab |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn
If the boost ratio isn't calculated properly for the system for any reason this can cause other problems that are non-obvious.
ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn
If the boost ratio isn't calculated properly for the system for any reason this can cause other problems that are non-obvious.
Raise all messages to warn instead.
Suggested-by: Perry Yuan <[email protected]> Reviewed-by: Perry Yuan <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
3355ac25 |
| 27-Aug-2024 |
Mario Limonciello <[email protected]> |
ACPI: CPPC: Drop check for non zero perf ratio
perf_ratio is a u64 and SCHED_CAPACITY_SCALE is a large number. Shifting by one will never have a zero value.
Drop the check.
Suggested-by: Gautham R
ACPI: CPPC: Drop check for non zero perf ratio
perf_ratio is a u64 and SCHED_CAPACITY_SCALE is a large number. Shifting by one will never have a zero value.
Drop the check.
Suggested-by: Gautham R. Shenoy <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
6c09e3b4 |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
x86/amd: Rename amd_get_highest_perf() to amd_get_boost_ratio_numerator()
The function name is ambiguous because it returns an intermediate value for calculating maximum frequency rather than the CP
x86/amd: Rename amd_get_highest_perf() to amd_get_boost_ratio_numerator()
The function name is ambiguous because it returns an intermediate value for calculating maximum frequency rather than the CPPC 'Highest Perf' register.
Rename the function to clarify its use and allow the function to return errors. Adjust the consumer in acpi-cpufreq to catch errors.
Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
| #
2bcec09c |
| 26-Aug-2024 |
Mario Limonciello <[email protected]> |
x86/amd: Move amd_get_highest_perf() from amd.c to cppc.c
To prepare to let amd_get_highest_perf() detect preferred cores it will require CPPC functions. Move amd_get_highest_perf() to cppc.c to pre
x86/amd: Move amd_get_highest_perf() from amd.c to cppc.c
To prepare to let amd_get_highest_perf() detect preferred cores it will require CPPC functions. Move amd_get_highest_perf() to cppc.c to prepare for 'preferred core detection' rework.
No functional changes intended.
Reviewed-by: Perry Yuan <[email protected]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4 |
|
| #
a51ab63b |
| 08-Feb-2024 |
Perry Yuan <[email protected]> |
ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors
As there are some AMD processors which only support CPPC V2 firmware and BIOS implementation, the amd_pstate driver will be failed to
ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors
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]> Reviewed-by: Gautham R. Shenoy <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7 |
|
| #
fbd74d16 |
| 13-Jul-2022 |
Mario Limonciello <[email protected]> |
ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory
When commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") was introduced, we found collateral
ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory
When commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") was introduced, we found collateral damage that a number of AMD systems that supported CPPC but didn't advertise support in _OSC stopped having a functional amd-pstate driver. The _OSC was only enforced on Intel systems at that time.
This was fixed for the MSR based designs by commit 8b356e536e69f ("ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported") but some shared memory based designs also support CPPC but haven't advertised support in the _OSC. Add support for those designs as well by hardcoding the list of systems.
Fixes: 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") Fixes: 8b356e536e69f ("ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported") Link: https://lore.kernel.org/all/[email protected]/ Cc: 5.18+ <[email protected]> # 5.18+ Reported-and-tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.19-rc6 |
|
| #
8b356e53 |
| 05-Jul-2022 |
Mario Limonciello <[email protected]> |
ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported
commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPP
ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported
commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPPC in _OSC on non-Intel platforms.
This unfortunately caused a regression on a vartiety of AMD platforms in the field because a number of AMD platforms don't set the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support.
As these AMD platforms already claim CPPC support via a dedicated MSR from `X86_FEATURE_CPPC`, use this enable this feature rather than requiring the `_OSC` on platforms with a dedicated MSR.
If there is additional breakage on the shared memory designs also missing this _OSC, additional follow up changes may be needed.
Fixes: 72f2ecb7ece7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported") Reported-by: Perry Yuan <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3 |
|
| #
0dfaf3f6 |
| 15-Apr-2022 |
Thomas Gleixner <[email protected]> |
x86/aperfmperf: Untangle Intel and AMD frequency invariance init
AMD boot CPU initialization happens late via ACPI/CPPC which prevents the Intel parts from being marked __init.
Split out the common
x86/aperfmperf: Untangle Intel and AMD frequency invariance init
AMD boot CPU initialization happens late via ACPI/CPPC which prevents the Intel parts from being marked __init.
Split out the common code and provide a dedicated interface for the AMD initialization and mark the Intel specific code and data __init.
The remaining text size is almost cut in half:
text: 2614 -> 1350 init.text: 0 -> 786
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
138a7f9c |
| 15-Apr-2022 |
Thomas Gleixner <[email protected]> |
x86/aperfmperf: Separate AP/BP frequency invariance init
This code is convoluted and because it can be invoked post init via the ACPI/CPPC code, all of the initialization functionality is built in i
x86/aperfmperf: Separate AP/BP frequency invariance init
This code is convoluted and because it can be invoked post init via the ACPI/CPPC code, all of the initialization functionality is built in instead of being part of init text and init data.
As a first step create separate calls for the boot and the application processors.
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5 |
|
| #
eb5616d4 |
| 14-Feb-2022 |
Huang Rui <[email protected]> |
x86/ACPI: CPPC: Move init_freq_invariance_cppc() into x86 CPPC
The init_freq_invariance_cppc code actually doesn't need the SMP functionality. So setting the CONFIG_SMP as the check condition for in
x86/ACPI: CPPC: Move init_freq_invariance_cppc() into x86 CPPC
The init_freq_invariance_cppc code actually doesn't need the SMP functionality. So setting the CONFIG_SMP as the check condition for init_freq_invariance_cppc may cause the confusion to misunderstand the CPPC. And the x86 CPPC file is better space to store the CPPC related functions, while the init_freq_invariance_cppc is out of smpboot, that means, the CONFIG_SMP won't be mandatory condition any more. And It's more clear than before.
Signed-off-by: Huang Rui <[email protected]> [ rjw: Subject adjustment ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
82d89369 |
| 14-Feb-2022 |
Huang Rui <[email protected]> |
x86/ACPI: CPPC: Move AMD maximum frequency ratio setting function into x86 CPPC
The AMD maximum frequency ratio setting function depends on CPPC, so the x86 CPPC implementation file is better space
x86/ACPI: CPPC: Move AMD maximum frequency ratio setting function into x86 CPPC
The AMD maximum frequency ratio setting function depends on CPPC, so the x86 CPPC implementation file is better space for this function.
Signed-off-by: Huang Rui <[email protected]> [ rjw: Subject adjustment ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
fd8af343 |
| 14-Feb-2022 |
Huang Rui <[email protected]> |
x86/ACPI: CPPC: Rename cppc_msr.c to cppc.c
Rename the cppc_msr.c to cppc.c in x86 ACPI, that expects to use this file to cover more function implementation for ACPI CPPC beside MSR helpers. Naming
x86/ACPI: CPPC: Rename cppc_msr.c to cppc.c
Rename the cppc_msr.c to cppc.c in x86 ACPI, that expects to use this file to cover more function implementation for ACPI CPPC beside MSR helpers. Naming as "cppc" is more straightforward as one of the functionalities under ACPI subsystem.
Signed-off-by: Huang Rui <[email protected]> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|