Commit graph

21 commits

Author SHA1 Message Date
Jinzhou Su
fb0b00af04 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 <Jinzhou.Su@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-30 18:51:39 +01:00
Rafael J. Wysocki
0654cf05d1 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 <rafael.j.wysocki@intel.com>
2021-09-07 21:15:16 +02:00
Rafael J. Wysocki
8a02d99876 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 <rafael.j.wysocki@intel.com>
Tested-by: Chen Yu <yu.c.chen@intel.com>
2021-03-23 19:44:17 +01:00
Ionela Voinescu
d8f85cc021 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 <viro@zeniv.linux.org.uk>
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22 16:28:19 +01:00
Ionela Voinescu
a28b2bfc09 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 <ionela.voinescu@arm.com>
Tested-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-15 19:19:32 +01:00
Thomas Gleixner
b886d83c5b 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 <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Armijn Hemel <armijn@tjaldur.nl>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05 17:37:17 +02:00
Xiongfeng Wang
1757d05f31 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 <wangxiongfeng2@huawei.com>
[ rjw: More white space ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-18 11:27:42 +01:00
Borislav Petkov
ad3bc25a32 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 <rostedt@goodmis.org>.

Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> # ACPI + cpufreq bits
Cc: Andrew Banman <andrew.banman@hpe.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yi Wang <wang.yi59@zte.com.cn>
Cc: linux-acpi@vger.kernel.org
2018-12-08 12:24:35 +01:00
Srinivas Pandruvada
29523f0953 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 <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-10-16 10:33:38 +02:00
Prashanth Prakash
4773e77cdc 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 <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-24 12:33:28 +02:00
Prakash, Prashanth
2c74d8473d 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 <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-18 23:37:50 +02:00
Prakash, Prashanth
368520a6b2 ACPI / CPPC: Read lowest nonlinear perf in cppc_get_perf_caps()
Read lowest non linear perf in cppc_get_perf_caps so that it can be exposed
via sysfs to the usespace. Lowest non linear perf is the lowest performance
level at which nonlinear power savings are achieved.

Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-18 23:37:49 +02:00
Srinivas Pandruvada
41dd640389 ACPI / CPPC: Add prefix cppc to cpudata structure name
Since struct cpudata is defined in a header file, add prefix cppc_ to
make it not a generic name. Otherwise it causes compile issue in locally
define structure with the same name.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-08 23:02:15 +02:00
Prakash, Prashanth
139aee73f0 ACPI / CPPC: check for error bit in PCC status field
PCC status field exposes an error bit(2) to indicate any errors during
the execution of last comamnd. This patch checks the error bit before
notifying success/failure to the cpufreq driver.

Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 01:02:34 +02:00
Ashwin Chaugule
158c998ea4 ACPI / CPPC: add sysfs support to compute delivered performance
The CPPC tables contain entries for per CPU feedback counters which
allows us to compute the delivered performance over a given interval
of time.

The math for delivered performance per the CPPCv5.0+ spec is:
  reference perf * delta(delivered perf ctr)/delta(ref perf ctr)

Maintaining deltas of the counters in the kernel is messy, as it
depends on when the reads are triggered. (e.g. via the cpufreq
->get() interface). Also the ->get() interace only returns one
value, so cant return raw values. So instead, leave it to userspace
to keep track of raw values and do its math for CPUs it cares about.

delivered and reference perf counters are exposed via the same
sysfs file to avoid the potential "skid", if these values are read
individually from userspace.

Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 01:02:34 +02:00
Prakash, Prashanth
be8b88d7d9 ACPI / CPPC: set a non-zero value for transition_latency
Compute the expected transition latency for frequency transitions
using the values from the PCCT tables when the desired perf
register is in PCC.

Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Reviewed-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 01:02:33 +02:00
Prakash, Prashanth
80b8286aee ACPI / CPPC: support for batching CPPC requests
CPPC defined in section 8.4.7 of ACPI 6.0 specification suggests
"To amortize the cost of PCC transactions, OSPM should read or write
all PCC registers via a single read or write command when possible"
This patch enables opportunistic batching of frequency transition
requests whenever the request happen to overlap in time.

Currently the access to pcc is serialized by a spin lock which does
not scale well as we increase the number of cores in the system. This
patch improves the scalability by allowing the differnt CPU cores to
update PCC subspace in parallel and by batching requests which will
reduce the certain types of operation(checking command completion bit,
ringing doorbell) by a significant margin.

Profiling shows significant improvement in the overall effeciency
to service freq. transition requests. With this patch we observe close
to 30% of the frequency transition requests being batched with other
requests while running apache bench on a ARM platform with 6
independent domains(or sets of related cpus).

Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 01:02:33 +02:00
Ashwin Chaugule
5bbb86aa4b ACPI / CPPC: restructure read/writes for efficient sys mapped reg ops
For cases where sys mapped CPC registers need to be accessed
frequently, it helps immensly to pre-map them rather than map
and unmap for each operation. e.g. case where feedback counters
are sys mem map registers.

Restructure cpc_read/write and the cpc_regs structure to allow
pre-mapping the system addresses and unmap them when the CPU exits.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 01:02:33 +02:00
Hoan Tran
866ae696e2 mailbox: pcc: Add PCC request and free channel declarations
Exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
declarations into a pcc.h header file.

Looks-good-to: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Hoan Tran <hotran@apm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-25 02:53:37 +02:00
Timur Tabi
2db8f9a1d8 ACPI / CPPC: remove redundant mbox_send_message() declaration
Remove a redundant function declaration in cppc_acpi.h for
mbox_send_message().  That function is defined in mailbox_client.h,
which is already included.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-03 01:09:52 +01:00
Ashwin Chaugule
337aadff8e ACPI: Introduce CPU performance controls using CPPC
CPPC stands for Collaborative Processor Performance Controls
and is defined in the ACPI v5.0+ spec. It describes CPU
performance controls on an abstract and continuous scale
allowing the platform (e.g. remote power processor) to flexibly
optimize CPU performance with its knowledge of power budgets
and other architecture specific knowledge.

This patch adds a shim which exports commonly used functions
to get and set CPPC specific controls for each CPU. This enables
CPUFreq drivers to gather per CPU performance data and use
with exisiting governors or even allows for customized governors
which are implemented inside CPUFreq drivers.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-12 22:49:55 +02:00