ACPI: CPPC: Make rmw_lock a raw_spin_lock

The following BUG was triggered:

=============================
[ BUG: Invalid wait context ]
6.12.0-rc2-XXX #406 Not tainted
-----------------------------

ACPI: CPPC: Make rmw_lock a raw_spin_lock

The following BUG was triggered:

=============================
[ BUG: Invalid wait context ]
6.12.0-rc2-XXX #406 Not tainted
-----------------------------
kworker/1:1/62 is trying to lock:
ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370
other info that might help us debug this:
context-{5:5}
2 locks held by kworker/1:1/62:
#0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50
#1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280
stack backtrace:
CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406
Workqueue: 0x0 (events)
Call trace:
dump_backtrace+0xa4/0x130
show_stack+0x20/0x38
dump_stack_lvl+0x90/0xd0
dump_stack+0x18/0x28
__lock_acquire+0x480/0x1ad8
lock_acquire+0x114/0x310
_raw_spin_lock+0x50/0x70
cpc_write+0xcc/0x370
cppc_set_perf+0xa0/0x3a8
cppc_cpufreq_fast_switch+0x40/0xc0
cpufreq_driver_fast_switch+0x4c/0x218
sugov_update_shared+0x234/0x280
update_load_avg+0x6ec/0x7b8
dequeue_entities+0x108/0x830
dequeue_task_fair+0x58/0x408
__schedule+0x4f0/0x1070
schedule+0x54/0x130
worker_thread+0xc0/0x2e8
kthread+0x130/0x148
ret_from_fork+0x10/0x20

sugov_update_shared() locks a raw_spinlock while cpc_write() locks a
spinlock.

To have a correct wait-type order, update rmw_lock to a raw spinlock and
ensure that interrupts will be disabled on the CPU holding it.

Fixes: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage")
Signed-off-by: Pierre Gondois <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 ...

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 ...

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 ...

ACPI: CPPC: Adjust return code for inline functions in !CONFIG_ACPI_CPPC_LIB

Checkpath emits the following warning:
```
WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP
```

Adjust the

ACPI: CPPC: Adjust return code for inline functions in !CONFIG_ACPI_CPPC_LIB

Checkpath emits the following warning:
```
WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP
```

Adjust the code accordingly.

Reviewed-by: Gautham R. Shenoy <[email protected]>
Signed-off-by: Mario Limonciello <[email protected]>

show more ...

ACPI: CPPC: Fix MASK_VAL() usage

MASK_VAL() was added as a way to handle bit_offset and bit_width for
registers located in system memory address space. However, while suited
for reading, it does not

ACPI: CPPC: Fix MASK_VAL() usage

MASK_VAL() was added as a way to handle bit_offset and bit_width for
registers located in system memory address space. However, while suited
for reading, it does not work for writing and result in corrupted
registers when writing values with bit_offset > 0. Moreover, when a
register is collocated with another one at the same address but with a
different mask, the current code results in the other registers being
overwritten with 0s. The write procedure for SYSTEM_MEMORY registers
should actually read the value, mask it, update it and write it with the
updated value. Moreover, since registers can be located in the same
word, we must take care of locking the access before doing it. We should
potentially use a global lock since we don't know in if register
addresses aren't shared with another _CPC package but better not
encourage vendors to do so. Assume that registers can use the same word
inside a _CPC package and thus, use a per _CPC package lock.

Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Clément Léger <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Dropped redundant semicolon ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Add helper to get the highest performance value

Add support for getting the highest performance to the
generic CPPC driver. This enables downstream drivers
such as amd-pstate to discover

ACPI: CPPC: Add helper to get the highest performance value

Add support for getting the highest performance to the
generic CPPC driver. This enables downstream drivers
such as amd-pstate to discover and use these values.

Refer to Chapter 8.4.6.1.1.1. Highest Performance of ACPI
Specification 6.5 for details on continuous performance control
of CPPC (linked below).

Tested-by: Oleksandr Natalenko <[email protected]>
Reviewed-by: Mario Limonciello <[email protected]>
Reviewed-by: Wyes Karny <[email protected]>
Reviewed-by: Perry Yuan <[email protected]>
Acked-by: Huang Rui <[email protected]>
Signed-off-by: Meng Li <[email protected]>
Link: https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html?highlight=cppc#highest-performance
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}()

Move and rename cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf() to
use them outside cppc_cpufreq in topology_init_cpu

cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}()

Move and rename cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf() to
use them outside cppc_cpufreq in topology_init_cpu_capacity_cppc().

Modify the interface to use struct cppc_perf_caps *caps instead of
struct cppc_cpudata *cpu_data as we only use the fields of cppc_perf_caps.

cppc_cpufreq was converting the lowest and nominal freq from MHz to kHz
before using them. We move this conversion inside cppc_perf_to_khz and
cppc_khz_to_perf to make them generic and usable outside cppc_cpufreq.

No functional change

Signed-off-by: Vincent Guittot <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Pierre Gondois <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

ACPI: CPPC: Add auto select register read/write support

For some AMD shared memory based systems, the autonomous selection bit
needed to be set explicitly. Add autonomous selection register related

ACPI: CPPC: Add auto select register read/write support

For some AMD shared memory based systems, the autonomous selection bit
needed to be set explicitly. Add autonomous selection register related
APIs to acpi driver, which amd_pstate driver uses later.

Acked-by: Huang Rui <[email protected]>
Reviewed-by: Mario Limonciello <[email protected]>
Tested-by: Oleksandr Natalenko <[email protected]>
Signed-off-by: Wyes Karny <[email protected]>
[ rjw: Fixed up kerneldoc comments, white space adjustment, subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Add AMD pstate energy performance preference cppc control

Add support for setting and querying EPP preferences to the generic
CPPC driver. This enables downstream drivers such as amd-ps

ACPI: CPPC: Add AMD pstate energy performance preference cppc control

Add support for setting and querying EPP preferences to the generic
CPPC driver. This enables downstream drivers such as amd-pstate to discover
and use these values.

Downstream drivers that want to use the new symbols cppc_get_epp_caps
and cppc_set_epp_perf for querying and setting EPP preferences will need
to call cppc_set_epp_perf to enable the EPP function firstly.

Acked-by: Huang Rui <[email protected]>
Reviewed-by: Mario Limonciello <[email protected]>
Reviewed-by: Wyes Karny <[email protected]>
Tested-by: Wyes Karny <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Disable FIE if registers in PCC regions

PCC regions utilize a mailbox to set/retrieve register values used by
the CPPC code. This is fine as long as the operations are
infrequent. With t

ACPI: CPPC: Disable FIE if registers in PCC regions

PCC regions utilize a mailbox to set/retrieve register values used by
the CPPC code. This is fine as long as the operations are
infrequent. With the FIE code enabled though the overhead can range
from 2-11% of system CPU overhead (ex: as measured by top) on Arm
based machines.

So, before enabling FIE assure none of the registers used by
cppc_get_perf_ctrs() are in the PCC region. Finally, add a module
parameter which can override the PCC region detection at boot or
module reload.

Signed-off-by: Jeremy Linton <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Reviewed-by: Ionela Voinescu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Do not prevent CPPC from working in the future

There is a problem with the current revision checks in
is_cppc_supported() that they essentially prevent the CPPC support
from working if a

ACPI: CPPC: Do not prevent CPPC from working in the future

There is a problem with the current revision checks in
is_cppc_supported() that they essentially prevent the CPPC support
from working if a new _CPC package format revision being a proper
superset of the v3 and only causing _CPC to return a package with more
entries (while retaining the types and meaning of the entries defined by
the v3) is introduced in the future and used by the platform firmware.

In that case, as long as the number of entries in the _CPC return
package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to
use the v3 support code and disregard the additional package entries
added by the new package format revision.

For this reason, drop is_cppc_supported() altogether, put the revision
checks directly into acpi_cppc_processor_probe() so they are easier to
follow and rework them to take the case mentioned above into account.

Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3")
Cc: 4.18+ <[email protected]> # 4.18+
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 ...

cpufreq: CPPC: Enable fast_switch

The communication mean of the _CPC desired performance can be
PCC, System Memory, System IO, or Functional Fixed Hardware.

commit b7898fda5bc7 ("cpufreq: Support f

cpufreq: CPPC: Enable fast_switch

The communication mean of the _CPC desired performance can be
PCC, System Memory, System IO, or Functional Fixed Hardware.

commit b7898fda5bc7 ("cpufreq: Support for fast frequency switching")
fast_switching is 'for switching CPU frequencies from interrupt
context'.
Writes to SystemMemory and SystemIo are fast and suitable this.
This is not the case for PCC and might not be the case for FFH.

Enable fast_switching for the cppc_cpufreq driver in above cases.

Add cppc_allow_fast_switch() to check the desired performance
register address space and set fast_switching accordingly.

Signed-off-by: Pierre Gondois <[email protected]>
Reviewed-by: Sudeep Holla <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Add CPPC enable register function

Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.

CPPC

ACPI: CPPC: Add CPPC enable register function

Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.

CPPC EnableRegister register described in section 8.4.7.1 of ACPI 6.4:
This element is optional. If supported, contains a resource descriptor
with a single Register() descriptor that describes a register to which
OSPM writes a One to enable CPPC on this processor. Before this register
is set, the processor will be controlled by legacy mechanisms (ACPI
Pstates, firmware, etc.).

This register will be used for AMD processors to enable AMD P-State
function instead of legacy ACPI P-States.

Signed-off-by: Jinzhou Su <[email protected]>
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Introduce cppc_get_nominal_perf()

On some systems the nominal_perf value retrieved via CPPC is just
a constant and fetching it doesn't require accessing any registers,
so if it is the on

ACPI: CPPC: Introduce cppc_get_nominal_perf()

On some systems the nominal_perf value retrieved via CPPC is just
a constant and fetching it doesn't require accessing any registers,
so if it is the only CPPC capability that's needed, it is wasteful
to run cppc_get_perf_caps() in order to get just that value alone,
especially when this is done for CPUs other than the one running
the code.

For this reason, introduce cppc_get_nominal_perf() allowing
nominal_perf to be obtained individually, by generalizing the
existing cppc_get_desired_perf() (and renaming it) so it can be
used to retrieve any specific CPPC capability value.

While at it, clean up the cppc_get_desired_perf() kerneldoc comment
a bit.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unset

For convenience, add empty stubs of library functions defined in
cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case.

Because

ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unset

For convenience, add empty stubs of library functions defined in
cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case.

Because one of them needs to return CPUFREQ_ETERNAL, include
linux/cpufreq.h into the CPPC library header file and drop the
direct inclusion of it from cppc_acpi.c.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Tested-by: Chen Yu <[email protected]>

show more ...

ACPI: CPPC: remove __iomem annotation for cpc_reg's address

The cpc_reg address does not represent either an I/O virtual address,
nor a field located in iomem. This address is used as an address off

ACPI: CPPC: remove __iomem annotation for cpc_reg's address

The cpc_reg address does not represent either an I/O virtual address,
nor a field located in iomem. This address is used as an address offset
which eventually is given as physical address argument to ioremap or PCC
space offset to GET_PCC_VADDR. Therefore, having the __iomem annotation
does not make sense.

Fix the following sparse warnings by removing the __iomem annotation
for cpc_reg's address.

drivers/acpi/cppc_acpi.c:762:37: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:765:48: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:948:25: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:954:67: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:987:25: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:993:68: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:1120:13: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:1134:13: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:1137:13: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:1182:14: warning: dereference of noderef expression
drivers/acpi/cppc_acpi.c:1212:13: warning: dereference of noderef expression

Suggested-by: Al Viro <[email protected]>
Signed-off-by: Ionela Voinescu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cppc_cpufreq: replace per-cpu data array with a list

The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu dat

cppc_cpufreq: replace per-cpu data array with a list

The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.

(1) The amount of information needed for CPPC performance control in its
cpufreq driver depends on the domain (PSD) coordination type:

ANY: One set of CPPC control and capability data (e.g desired
performance, highest/lowest performance, etc) applies to all
CPUs in the domain.

ALL: Same as ANY. To be noted that this type is not currently
supported. When supported, information about which CPUs
belong to a domain is needed in order for frequency change
requests to be sent to each of them.

HW: It's necessary to store CPPC control and capability
information for all the CPUs. HW will then coordinate the
performance state based on their limitations and requests.

NONE: Same as HW. No HW coordination is expected.

Despite this, the previous initialisation code would indiscriminately
allocate memory for all CPUs (all_cpu_data) and unnecessarily
duplicate performance capabilities and the domain sharing mask and type
for each possible CPU.

(2) With the current per-cpu structure, when having ANY coordination,
the cppc_cpudata cpu information is not initialised (will remain 0)
for all CPUs in a policy, other than policy->cpu. When policy->cpu is
hotplugged out, the driver will incorrectly use the uninitialised (0)
value of the other CPUs when making frequency changes. Additionally,
the previous values stored in the perf_ctrls.desired_perf will be
lost when policy->cpu changes.

Therefore replace the array of per cpu data with a list. The memory for
each structure is allocated at policy init, where a single structure
can be allocated per policy, not per cpu. In order to accommodate the
struct list_head node in the cppc_cpudata structure, the now unused cpu
and cur_policy variables are removed.

For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1,
(4, 5) in PSD2 - ANY coordination, the memory allocation comparison shows:

Before patch:

- ANY coordination:
total slack req alloc/free caller
0 0 0 0/1 _kernel_size_le_hi32+0x0xffff800008ff7810
0 0 0 0/6 _kernel_size_le_hi32+0x0xffff800008ff7808
128 80 48 1/0 _kernel_size_le_hi32+0x0xffff800008ffc070
768 0 768 6/0 _kernel_size_le_hi32+0x0xffff800008ffc0e4

After patch:

- ANY coordination:
total slack req alloc/free caller
256 0 256 2/0 _kernel_size_le_hi32+0x0xffff800008fed410
0 0 0 0/2 _kernel_size_le_hi32+0x0xffff800008fed274

Additional notes:
- A pointer to the policy's cppc_cpudata is stored in policy->driver_data
- Driver registration is skipped if _CPC entries are not present.

Signed-off-by: Ionela Voinescu <[email protected]>
Tested-by: Mian Yousaf Kaukab <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 315 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Armijn Hemel <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ACPI / CPPC: Add a helper to get desired performance

This patch add a helper to get the value of desired performance
register.

Signed-off-by: Xiongfeng Wang <[email protected]>
[ rjw: More

ACPI / CPPC: Add a helper to get desired performance

This patch add a helper to get the value of desired performance
register.

Signed-off-by: Xiongfeng Wang <[email protected]>
[ rjw: More white space ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

x86/kernel: Fix more -Wmissing-prototypes warnings

... with the goal of eventually enabling -Wmissing-prototypes by
default. At least on x86.

Make functions static where possible, otherwise add pro

x86/kernel: Fix more -Wmissing-prototypes warnings

... with the goal of eventually enabling -Wmissing-prototypes by
default. At least on x86.

Make functions static where possible, otherwise add prototypes or make
them visible through includes.

asm/trace/ changes courtesy of Steven Rostedt <[email protected]>.

Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Masami Hiramatsu <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]> # ACPI + cpufreq bits
Cc: Andrew Banman <[email protected]>
Cc: Dimitri Sivanich <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: "Steven Rostedt (VMware)" <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Yi Wang <[email protected]>
Cc: [email protected]

show more ...

ACPI / CPPC: Add support for guaranteed performance

The Continuous Performance Control package may contain an optional
guaranteed performance field.

Add support to read guaranteed performance from

ACPI / CPPC: Add support for guaranteed performance

The Continuous Performance Control package may contain an optional
guaranteed performance field.

Add support to read guaranteed performance from _CPC.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / CPPC: Add support for CPPC v3

CPPC V3 introduces two new entries to make it easier to convert between
abstract processor performance and frequency. The two new entries are
lowest frequency an

ACPI / CPPC: Add support for CPPC v3

CPPC V3 introduces two new entries to make it easier to convert between
abstract processor performance and frequency. The two new entries are
lowest frequency and nominal frequency. These are the frequencies
corresponding to lowest and nominal abstract performance.

Add support to read the new entries and populate them as part of the
CPPC performance capabilities which can be used by cpufreq drivers

Signed-off-by: Prashanth Prakash <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / CPPC: add sysfs entries for CPPC perf capabilities

Computed delivered performance using CPPC feedback counters are in the
CPPC abstract scale, whereas cppc_cpufreq driver operates in KHz scal

ACPI / CPPC: add sysfs entries for CPPC perf capabilities

Computed delivered performance using CPPC feedback counters are in the
CPPC abstract scale, whereas cppc_cpufreq driver operates in KHz scale.
Exposing the CPPC performance capabilities (highest,lowest, nominal,
lowest non-linear) will allow userspace to figure out the conversion
factor from CPPC abstract scale to KHz.

Also rename ctr_wrap_time to wraparound_time so that show_cppc_data()
macro will work with it.

Signed-off-by: Prashanth Prakash <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...