History log of /linux-6.15/arch/x86/kernel/acpi/cppc.c (Results 1 – 19 of 19)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...