linux/include/acpi/cppc_acpi.h, branch v5.15

ACPI: CPPC: Introduce cppc_get_nominal_perf()

2021-09-07T19:15:16Z

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

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

2021-03-23T18:44:17Z

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 Tested-by: Chen Yu

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

2021-01-22T15:28:19Z

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 Signed-off-by: Ionela Voinescu Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: replace per-cpu data array with a list

2020-12-15T18:19:32Z

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 Tested-by: Mian Yousaf Kaukab Signed-off-by: Rafael J. Wysocki

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

2019-06-05T15:37:17Z

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 Reviewed-by: Allison Randal Reviewed-by: Armijn Hemel Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman

ACPI / CPPC: Add a helper to get desired performance

2019-02-18T10:27:42Z

This patch add a helper to get the value of desired performance register. Signed-off-by: Xiongfeng Wang [ rjw: More white space ] Signed-off-by: Rafael J. Wysocki

x86/kernel: Fix more -Wmissing-prototypes warnings

2018-12-08T11:24:35Z

... 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 . Signed-off-by: Borislav Petkov Reviewed-by: Masami Hiramatsu Reviewed-by: Ingo Molnar Acked-by: Rafael J. Wysocki # ACPI + cpufreq bits Cc: Andrew Banman Cc: Dimitri Sivanich Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: Mike Travis Cc: "Steven Rostedt (VMware)" Cc: Thomas Gleixner Cc: Yi Wang Cc: linux-acpi@vger.kernel.org

ACPI / CPPC: Add support for guaranteed performance

2018-10-16T08:33:38Z

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 Signed-off-by: Rafael J. Wysocki

ACPI / CPPC: Add support for CPPC v3

2018-04-24T10:33:28Z

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 Signed-off-by: Rafael J. Wysocki

ACPI / CPPC: add sysfs entries for CPPC perf capabilities

2017-04-18T21:37:50Z

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 Signed-off-by: Rafael J. Wysocki