ACPI: CPPC: Fix _CPC register setting issue

Since commit 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC
registers cannot be changed from 1 to 0.

It turns out that there is an extra OR afte

ACPI: CPPC: Fix _CPC register setting issue

Since commit 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC
registers cannot be changed from 1 to 0.

It turns out that there is an extra OR after MASK_VAL_WRITE(), which
has already ORed prev_val with the register mask.

Remove the extra OR to fix the problem.

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

show more ...

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

ACPI: allow building without CONFIG_HAS_IOPORT

CONFIG_HAS_IOPORT will soon become optional and cause a build time
failure when it is disabled but a driver calls inb()/outb(). At the
moment, all arch

ACPI: allow building without CONFIG_HAS_IOPORT

CONFIG_HAS_IOPORT will soon become optional and cause a build time
failure when it is disabled but a driver calls inb()/outb(). At the
moment, all architectures that can support ACPI have port I/O, but this
is not necessarily the case in the future on non-x86 architectures.
The result is a set of errors like:

drivers/acpi/osl.c: In function 'acpi_os_read_port':
include/asm-generic/io.h:542:14: error: call to '_inb' declared with attribute error: inb()) requires CONFIG_HAS_IOPORT

Nothing should actually call these functions in this configuration,
and if it does, the result would be undefined behavior today, possibly
a NULL pointer dereference.

Change the low-level functions to return a proper error code when
HAS_IOPORT is disabled.

Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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

cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception

When the nominal_freq recorded by the kernel is equal to the lowest_freq,
and the frequency adjustment operation is triggered external

cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception

When the nominal_freq recorded by the kernel is equal to the lowest_freq,
and the frequency adjustment operation is triggered externally, there is
a logic error in cppc_perf_to_khz()/cppc_khz_to_perf(), resulting in perf
and khz conversion errors.

Fix this by adding a branch processing logic when nominal_freq is equal
to lowest_freq.

Fixes: ec1c7ad47664 ("cpufreq: CPPC: Fix performance/frequency conversion")
Signed-off-by: liwei <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

move asm/unaligned.h to linux/unaligned.h

asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-

move asm/unaligned.h to linux/unaligned.h

asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.

auto-generated by the following:

for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

show more ...

ACPI: CPPC: Add support for setting EPP register in FFH

Some Asus AMD systems are reported to not be able to change EPP values
because the BIOS doesn't advertise support for the CPPC MSR and the PCC

ACPI: CPPC: Add support for setting EPP register in FFH

Some Asus AMD systems are reported to not be able to change EPP values
because the BIOS doesn't advertise support for the CPPC MSR and the PCC
region is not configured.

However the ACPI 6.2 specification allows CPC registers to be declared
in FFH:
```
Starting with ACPI Specification 6.2, all _CPC registers can be in
PCC, System Memory, System IO, or Functional Fixed Hardware address
spaces. OSPM support for this more flexible register space scheme
is indicated by the “Flexible Address Space for CPPC Registers” _OSC
bit.
```

If this _OSC has been set allow using FFH to configure EPP.

Reported-by: [email protected]
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218686
Suggested-by: [email protected]
Tested-by: [email protected]
Tested-by: [email protected]
Signed-off-by: Mario Limonciello <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[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: Replace ternary operator with umax()

Replace ternary operator with umax() in cppc_find_dmi_mhz().

Signed-off-by: Prabhakar Pujeri <[email protected]>
[ rjw: Subject and changel

ACPI: CPPC: Replace ternary operator with umax()

Replace ternary operator with umax() in cppc_find_dmi_mhz().

Signed-off-by: Prabhakar Pujeri <[email protected]>
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: add sysfs entry for guaranteed performance

Expose the CPPC guaranteed performance as reported by the platform through
GuaranteedPerformanceRegister.

The current value is already read in

ACPI: CPPC: add sysfs entry for guaranteed performance

Expose the CPPC guaranteed performance as reported by the platform through
GuaranteedPerformanceRegister.

The current value is already read in cppc_get_perf_caps() and stored in
struct cppc_perf_caps (to be used by the intel_pstate driver), so only the
attribute itself needs to be defined.

Signed-off-by: Petr Tesařík <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cppc_acpi: print error message if CPPC is unsupported

The amd-pstate driver can fail when _CPC objects are not supported by
the CPU. However, the current error message is ambiguous (see below) and
t

cppc_acpi: print error message if CPPC is unsupported

The amd-pstate driver can fail when _CPC objects are not supported by
the CPU. However, the current error message is ambiguous (see below) and
there is no clear way for attributing the failure of the amd-pstate
driver to the lack of CPPC support.

[ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

Fix this by adding an debug message to notify the user if the amd-pstate
driver failed to load due to CPPC not be supported by the CPU

Reviewed-by: Mario Limonciello <[email protected]>
Reviewed-by: Gautham R. Shenoy <[email protected]>
Tested-by: Dhananjay Ugwekar <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
Acked-by: Huang Rui <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Fix access width used for PCC registers

commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system
memory accesses") modified cpc_read()/cpc_write() to use access_width

ACPI: CPPC: Fix access width used for PCC registers

commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system
memory accesses") modified cpc_read()/cpc_write() to use access_width to
read CPC registers.

However, for PCC registers the access width field in the ACPI register
macro specifies the PCC subspace ID. For non-zero PCC subspace ID it is
incorrectly treated as access width. This causes errors when reading
from PCC registers in the CPPC driver.

For PCC registers, base the size of read/write on the bit width field.
The debug message in cpc_read()/cpc_write() is updated to print relevant
information for the address space type used to read the register.

Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Vanshidhar Konda <[email protected]>
Tested-by: Jarred White <[email protected]>
Reviewed-by: Jarred White <[email protected]>
Reviewed-by: Easwar Hariharan <[email protected]>
Cc: 5.15+ <[email protected]> # 5.15+
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro

Commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for
system memory accesses") neglected to properly wrap the bit_offset shift
wh

ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro

Commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for
system memory accesses") neglected to properly wrap the bit_offset shift
when it comes to applying the mask. This may cause incorrect values to be
read and may cause the cpufreq module not be loaded.

[ 11.059751] cpu_capacity: CPU0 missing/invalid highest performance.
[ 11.066005] cpu_capacity: partial information: fallback to 1024 for all CPUs

Also, corrected the bitmask generation in GENMASK (extra bit being added).

Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Jarred White <[email protected]>
Cc: 5.15+ <[email protected]> # 5.15+
Reviewed-by: Vanshidhar Konda <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Use access_width over bit_width for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary.

ACPI: CPPC: Use access_width over bit_width for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary. This was
uncovered on the Cobalt 100 platform.

SError Interrupt on CPU26, code 0xbe000011 -- SError
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
pc : cppc_get_perf_caps+0xec/0x410
lr : cppc_get_perf_caps+0xe8/0x410
sp : ffff8000155ab730
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
5.15.2.1-13 #1
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
Call trace:
dump_backtrace+0x0/0x1e0
show_stack+0x24/0x30
dump_stack_lvl+0x8c/0xb8
dump_stack+0x18/0x34
panic+0x16c/0x384
add_taint+0x0/0xc0
arm64_serror_panic+0x7c/0x90
arm64_is_fatal_ras_serror+0x34/0xa4
do_serror+0x50/0x6c
el1h_64_error_handler+0x40/0x74
el1h_64_error+0x7c/0x80
cppc_get_perf_caps+0xec/0x410
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
cpufreq_online+0x2dc/0xa30
cpufreq_add_dev+0xc0/0xd4
subsys_interface_register+0x134/0x14c
cpufreq_register_driver+0x1b0/0x354
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
do_one_initcall+0x50/0x250
do_init_module+0x60/0x27c
load_module+0x2300/0x2570
__do_sys_finit_module+0xa8/0x114
__arm64_sys_finit_module+0x2c/0x3c
invoke_syscall+0x78/0x100
el0_svc_common.constprop.0+0x180/0x1a0
do_el0_svc+0x84/0xa0
el0_svc+0x2c/0xc0
el0t_64_sync_handler+0xa4/0x12c
el0t_64_sync+0x1a4/0x1a8

Instead, use access_width to determine the size and use the offset and
width to shift and mask the bits to read/write out. Make sure to add a
check for system memory since pcc redefines the access_width to
subspace id.

If access_width is not set, then fall back to using bit_width.

Signed-off-by: Jarred White <[email protected]>
Reviewed-by: Easwar Hariharan <[email protected]>
Cc: 5.15+ <[email protected]> # 5.15+
[ rjw: Subject and changelog edits, comment adjustments ]
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 min and max perf register writing support

Currently writing of min and max perf register is deferred in
cppc_set_perf function. In CPPC guided mode, these registers needed to
be writ

ACPI: CPPC: Add min and max perf register writing support

Currently writing of min and max perf register is deferred in
cppc_set_perf function. In CPPC guided mode, these registers needed to
be written to guide the platform about min and max perf levels. Add this support
to make guided mode work properly on AMD shared memory systems.

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 a multiline comment, subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: make kobj_type structures constant

Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.

Take advantage of this to co

ACPI: make kobj_type structures constant

Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.

Take advantage of this to constify the structure definitions to prevent
modification at runtime.

Signed-off-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: CPPC: Fix some kernel-doc comments

Add the description of @pcc_ss_id in pcc_data_alloc().
Add the description of @cpu_num in cppc_get_transition_latency().

clear the below warnings:
drivers/a

ACPI: CPPC: Fix some kernel-doc comments

Add the description of @pcc_ss_id in pcc_data_alloc().
Add the description of @cpu_num in cppc_get_transition_latency().

clear the below warnings:
drivers/acpi/cppc_acpi.c:607: warning: Function parameter or member 'pcc_ss_id' not described in 'pcc_data_alloc'
drivers/acpi/cppc_acpi.c:1616: warning: Function parameter or member 'cpu_num' not described in 'cppc_get_transition_latency'

Reported-by: Abaci Robot <[email protected]>
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3983
Signed-off-by: Yang Li <[email protected]>
[ rjw: Dropped redundant empty code lines, minor 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: use sysfs_emit() instead of scnprintf()

Replace the open-code with sysfs_emit() to simplify the code.

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

ACPI: use sysfs_emit() instead of scnprintf()

Replace the open-code with sysfs_emit() to simplify the code.

Signed-off-by: ye xingchen <[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: Add ACPI disabled check to acpi_cpc_valid()

Make acpi_cpc_valid() check if ACPI is disabled, so that its callers
don't need to check that separately. This will also cause the AMD
pstate

ACPI: CPPC: Add ACPI disabled check to acpi_cpc_valid()

Make acpi_cpc_valid() check if ACPI is disabled, so that its callers
don't need to check that separately. This will also cause the AMD
pstate driver to refuse to load right away when ACPI is disabled.

Also update the warning message in amd_pstate_init() to mention the
ACPI disabled case for completeness.

Signed-off-by: Perry Yuan <[email protected]>
[ rjw: Subject edits, new changelog ]
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 ...