linux/drivers/cpufreq/cppc_cpufreq.c, branch v5.9

cpufreq: CPPC: Reuse caps variable in few routines

2020-07-30T05:27:47Z

The 'caps' variable has been defined in cppc_cpufreq_khz_to_perf() and cppc_cpufreq_perf_to_khz() routines, so there is no need to get 'highest_perf' value through 'cpu->caps.highest_perf', we can use 'caps->highest_perf' instead. Signed-off-by: Xin Hao [ Viresh: Updated commit log ] Signed-off-by: Viresh Kumar

cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable

2020-07-30T05:27:46Z

With the current approach we have an extra check in the cppc_cpufreq_get_rate() callback, which checks if hisilicon's get rate implementation should be used instead. While it works fine, the approach isn't very straight forward, over that we have an extra check in the routine. Rearrange code and update the cpufreq driver's get() callback pointer directly for the hisilicon case. This gets the extra variable is removed and the extra check isn't required anymore as well. Tested-by: Xiongfeng Wang Signed-off-by: Viresh Kumar

cpufreq: CPPC: add SW BOOST support

2020-06-05T12:20:02Z

To add SW BOOST support for CPPC, we need to get the max frequency of boost mode and non-boost mode. ACPI spec 6.2 section 8.4.7.1 describes the following two CPC registers. "Highest performance is the absolute maximum performance an individual processor may reach, assuming ideal conditions. This performance level may not be sustainable for long durations, and may only be achievable if other platform components are in a specific state; for example, it may require other processors be in an idle state. Nominal Performance is the maximum sustained performance level of the processor, assuming ideal operating conditions. In absence of an external constraint (power, thermal, etc.) this is the performance level the platform is expected to be able to maintain continuously. All processors are expected to be able to sustain their nominal performance state simultaneously." To add SW BOOST support for CPPC, we can use Highest Performance as the max performance in boost mode and Nominal Performance as the max performance in non-boost mode. If the Highest Performance is greater than the Nominal Performance, we assume SW BOOST is supported. The current CPPC driver does not support SW BOOST and use 'Highest Performance' as the max performance the CPU can achieve. 'Nominal Performance' is used to convert 'performance' to 'frequency'. That means, if firmware enable boost and provide a value for Highest Performance which is greater than Nominal Performance, boost feature is enabled by default. Because SW BOOST is disabled by default, so, after this patch, boost feature is disabled by default even if boost is enabled by firmware. Signed-off-by: Xiongfeng Wang Suggested-by: Viresh Kumar Acked-by: Viresh Kumar [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki

cpufreq: Avoid creating excessively large stack frames

2020-01-27T09:33:33Z

In the process of modifying a cpufreq policy, the cpufreq core makes a copy of it including all of the internals which is stored on the CPU stack. Because struct cpufreq_policy is relatively large, this may cause the size of the stack frame to exceed the 2 KB limit and so the GCC complains when -Wframe-larger-than= is used. In fact, it is not necessary to copy the entire policy structure in order to modify it, however. First, because cpufreq_set_policy() obtains the min and max policy limits from frequency QoS now, it is not necessary to pass the limits to it from the callers. The only things that need to be passed to it from there are the new governor pointer or (if there is a built-in governor in the driver) the "policy" value representing the governor choice. They both can be passed as individual arguments, though, so make cpufreq_set_policy() take them this way and rework its callers accordingly. This avoids making copies of cpufreq policies in the callers of cpufreq_set_policy(). Second, cpufreq_set_policy() still needs to pass the new policy data to the ->verify() callback of the cpufreq driver whose task is to sanitize the min and max policy limits. It still does not need to make a full copy of struct cpufreq_policy for this purpose, but it needs to pass a few items from it to the driver in case they are needed (different drivers have different needs in that respect and all of them have to be covered). For this reason, introduce struct cpufreq_policy_data to hold copies of the members of struct cpufreq_policy used by the existing ->verify() driver callbacks and pass a pointer to a temporary structure of that type to ->verify() (instead of passing a pointer to full struct cpufreq_policy to it). While at it, notice that intel_pstate and longrun don't really need to verify the "policy" value in struct cpufreq_policy, so drop those check from them to avoid copying "policy" into struct cpufreq_policy_data (which allows it to be slightly smaller). Also while at it fix up white space in a couple of places and make cpufreq_set_policy() static (as it can be so). Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS") Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.com Reported-by: kbuild test robot Reported-by: Geert Uytterhoeven Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: CPPC: put ACPI table after using it

2019-12-29T21:17:26Z

Put the ACPI table to release the table mapping after using it successfully. Signed-off-by: Hanjun Guo [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki

cpufreq : CPPC: Break out if HiSilicon CPPC workaround is matched

2019-12-29T21:17:26Z

Bail out if we match the OEM information, to save some possible extra iteration. Also update the code to fix minor coding style issue. Signed-off-by: Hanjun Guo [ rjw: Subject ] 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

cpufreq / cppc: Work around for Hisilicon CPPC cpufreq

2019-02-18T10:27:42Z

Hisilicon chips do not support delivered performance counter register and reference performance counter register. But the platform can calculate the real performance using its own method. We reuse the desired performance register to store the real performance calculated by the platform. After the platform finished the frequency adjust, it gets the real performance and writes it into desired performance register. Os can use it to calculate the real frequency. Signed-off-by: Xiongfeng Wang [ rjw: Drop unnecessary braces ] Signed-off-by: Rafael J. Wysocki

cpufreq / CPPC: Mark acpi_ids as used

2018-10-03T11:36:27Z

Clang warns: drivers/cpufreq/cppc_cpufreq.c:431:36: warning: variable 'cppc_acpi_ids' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct acpi_device_id cppc_acpi_ids[] = { ^ 1 warning generated. Mark the definition as used so that Clang understands we don't want this warning while not inhibiting Clang's dead code elimination from removing the unreferenced internal symbol when moving the data it contains to the globally available symbol via MODULE_DEVICE_TABLE. $ nm -S drivers/cpufreq/cppc_cpufreq.o | grep acpi | tail -1 0000000000000000 0000000000000040 R __mod_acpi__cppc_acpi_ids_device_table Suggested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki

cpufreq / CPPC: Add cpuinfo_cur_freq support for CPPC

2018-07-18T08:13:16Z

Per Section 8.4.7.1.3 of ACPI 6.2, the platform provides performance feedback via set of performance counters. To determine the actual performance level delivered over time, OSPM may read a set of performance counters from the Reference Performance Counter Register and the Delivered Performance Counter Register. OSPM calculates the delivered performance over a given time period by taking a beginning and ending snapshot of both the reference and delivered performance counters, and calculating: delivered_perf = reference_perf X (delta of delivered_perf counter / delta of reference_perf counter). Implement the above and hook this up to the cpufreq->get method. Signed-off-by: George Cherian Acked-by: Viresh Kumar Acked-by: Prashanth Prakash Signed-off-by: Rafael J. Wysocki