summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2020-07-15cpufreq: powernv: Make some symbols staticWei Yongjun
The sparse tool complains as follows: drivers/cpufreq/powernv-cpufreq.c:88:1: warning: symbol 'pstate_revmap' was not declared. Should it be static? drivers/cpufreq/powernv-cpufreq.c:383:18: warning: symbol 'cpufreq_freq_attr_cpuinfo_nominal_freq' was not declared. Should it be static? drivers/cpufreq/powernv-cpufreq.c:669:6: warning: symbol 'gpstate_timer_handler' was not declared. Should it be static? drivers/cpufreq/powernv-cpufreq.c:902:6: warning: symbol 'powernv_cpufreq_work_fn' was not declared. Should it be static? Those symbols are not used outside of this file, so mark them static. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: amd_freq_sensitivity: Mark sometimes used ID structs as __maybe_unusedLee Jones
ot used when MODULE is not defined. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/amd_freq_sensitivity.c:147:32: warning: ‘amd_freq_sensitivity_ids’ defined but not used [-Wunused-const-variable=] 147 | static const struct x86_cpu_id amd_freq_sensitivity_ids[] = { | ^~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: intel_pstate: Supply struct attribute description for ↵Lee Jones
get_aperf_mperf_shift() Fixes the following W=1 kernel build warning(s): drivers/cpufreq/intel_pstate.c:293: warning: Function parameter or member 'get_aperf_mperf_shift' not described in 'pstate_funcs' Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Remove line break ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: pcc-cpufreq: Mark sometimes used ID structs as __maybe_unusedLee Jones
Not used when MODULE is not defined. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/pcc-cpufreq.c:619:36: warning: ‘processor_device_ids’ defined but not used [-Wunused-const-variable=] 619 | static const struct acpi_device_id processor_device_ids[] = { | ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: powernow-k8: Mark 'hi' and 'lo' dummy variables as __always_unusedLee Jones
if we fail to use a variable, even a dummy ones, then the compiler complains that it is set but not used. We know this is fine, so we set them as __always_unused here to let the compiler know. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/powernow-k8.c: In function ‘pending_bit_stuck’: drivers/cpufreq/powernow-k8.c:89:10: warning: variable ‘hi’ set but not used [-Wunused-but-set-variable] 89 | u32 lo, hi; | ^~ drivers/cpufreq/powernow-k8.c: In function ‘core_voltage_pre_transition’: drivers/cpufreq/powernow-k8.c:285:14: warning: variable ‘lo’ set but not used [-Wunused-but-set-variable] 285 | u32 maxvid, lo, rvomult = 1; | ^~ Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: acpi-cpufreq: Mark sometimes used ID structs as __maybe_unusedLee Jones
Not used when MODULE is not defined. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/acpi-cpufreq.c:1004:36: warning: ‘processor_device_ids’ defined but not used [-Wunused-const-variable=] 997 | static const struct x86_cpu_id acpi_cpufreq_ids[] = { | ^~~~~~~~~~~~~~~~ drivers/cpufreq/acpi-cpufreq.c:997:32: warning: ‘acpi_cpufreq_ids’ defined but not used [-Wunused-const-variable=] 619 | static const struct acpi_device_id processor_device_ids[] = { | ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: acpi-cpufreq: Mark 'dummy' variable as __always_unusedLee Jones
If we fail to use a variable, even a 'dummy' one, then the compiler complains that it is set but not used. We know this is fine, so we set it as __always_unused to let the compiler know. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/acpi-cpufreq.c: In function ‘cpu_freq_read_intel’: drivers/cpufreq/acpi-cpufreq.c:247:11: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] drivers/cpufreq/acpi-cpufreq.c: In function ‘cpu_freq_read_amd’: drivers/cpufreq/acpi-cpufreq.c:265:11: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: powernv-cpufreq: Fix a bunch of kerneldoc related issuesLee Jones
Repair problems with formatting and missing attributes/parameters, and demote header comments which do not meet the required standards applicable to kerneldoc. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/powernv-cpufreq.c:84: warning: Function parameter or member 'last_lpstate_idx' not described in 'global_pstate_info' drivers/cpufreq/powernv-cpufreq.c:84: warning: Function parameter or member 'last_gpstate_idx' not described in 'global_pstate_info' drivers/cpufreq/powernv-cpufreq.c:84: warning: Function parameter or member 'policy' not described in 'global_pstate_info' drivers/cpufreq/powernv-cpufreq.c:182: warning: Function parameter or member 'i' not described in 'idx_to_pstate' drivers/cpufreq/powernv-cpufreq.c:201: warning: Function parameter or member 'pstate' not described in 'pstate_to_idx' drivers/cpufreq/powernv-cpufreq.c:670: warning: Function parameter or member 't' not described in 'gpstate_timer_handler' drivers/cpufreq/powernv-cpufreq.c:670: warning: Excess function parameter 'data' description in 'gpstate_timer_handler' Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: pasemi: Include header file for {check,restore}_astate prototypesLee Jones
If function callers and providers do not share the same prototypes the compiler complains of missing prototypes. Fix this by including the correct platforms header file. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/pasemi-cpufreq.c:109:5: warning: no previous prototype for ‘check_astate’ [-Wmissing-prototypes] 109 | int check_astate(void) | ^~~~~~~~~~~~ drivers/cpufreq/pasemi-cpufreq.c:114:6: warning: no previous prototype for ‘restore_astate’ [-Wmissing-prototypes] 114 | void restore_astate(int cpu) | ^~~~~~~~~~~~~~ Suggested-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: cpufreq_governor: Demote store_sampling_rate() header to standard ↵Lee Jones
comment block There is no need for this to be denoted as kerneldoc. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/cpufreq_governor.c:46: warning: Function parameter or member 'attr_set' not described in 'store_sampling_rate' drivers/cpufreq/cpufreq_governor.c:46: warning: Function parameter or member 'buf' not described in 'store_sampling_rate' drivers/cpufreq/cpufreq_governor.c:46: warning: Function parameter or member 'count' not described in 'store_sampling_rate' Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: cpufreq: Demote lots of function headers unworthy of kerneldoc statusLee Jones
Also provide missing function parameter description for 'cpu' and 'policy'. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/cpufreq.c:60: warning: cannot understand function prototype: 'struct cpufreq_driver *cpufreq_driver; ' drivers/cpufreq/cpufreq.c:90: warning: Function parameter or member 'cpufreq_policy_notifier_list' not described in 'BLOCKING_NOTIFIER_HEAD' drivers/cpufreq/cpufreq.c:312: warning: Function parameter or member 'val' not described in 'adjust_jiffies' drivers/cpufreq/cpufreq.c:312: warning: Function parameter or member 'ci' not described in 'adjust_jiffies' drivers/cpufreq/cpufreq.c:538: warning: Function parameter or member 'policy' not described in 'cpufreq_driver_resolve_freq' drivers/cpufreq/cpufreq.c:686: warning: Function parameter or member 'file_name' not described in 'show_one' drivers/cpufreq/cpufreq.c:686: warning: Function parameter or member 'object' not described in 'show_one' drivers/cpufreq/cpufreq.c:731: warning: Function parameter or member 'file_name' not described in 'store_one' drivers/cpufreq/cpufreq.c:731: warning: Function parameter or member 'object' not described in 'store_one' drivers/cpufreq/cpufreq.c:741: warning: Function parameter or member 'policy' not described in 'show_cpuinfo_cur_freq' drivers/cpufreq/cpufreq.c:741: warning: Function parameter or member 'buf' not described in 'show_cpuinfo_cur_freq' drivers/cpufreq/cpufreq.c:754: warning: Function parameter or member 'policy' not described in 'show_scaling_governor' drivers/cpufreq/cpufreq.c:754: warning: Function parameter or member 'buf' not described in 'show_scaling_governor' drivers/cpufreq/cpufreq.c:770: warning: Function parameter or member 'policy' not described in 'store_scaling_governor' drivers/cpufreq/cpufreq.c:770: warning: Function parameter or member 'buf' not described in 'store_scaling_governor' drivers/cpufreq/cpufreq.c:770: warning: Function parameter or member 'count' not described in 'store_scaling_governor' drivers/cpufreq/cpufreq.c:806: warning: Function parameter or member 'policy' not described in 'show_scaling_driver' drivers/cpufreq/cpufreq.c:806: warning: Function parameter or member 'buf' not described in 'show_scaling_driver' drivers/cpufreq/cpufreq.c:815: warning: Function parameter or member 'policy' not described in 'show_scaling_available_governors' drivers/cpufreq/cpufreq.c:815: warning: Function parameter or member 'buf' not described in 'show_scaling_available_governors' drivers/cpufreq/cpufreq.c:859: warning: Function parameter or member 'policy' not described in 'show_related_cpus' drivers/cpufreq/cpufreq.c:859: warning: Function parameter or member 'buf' not described in 'show_related_cpus' drivers/cpufreq/cpufreq.c:867: warning: Function parameter or member 'policy' not described in 'show_affected_cpus' drivers/cpufreq/cpufreq.c:867: warning: Function parameter or member 'buf' not described in 'show_affected_cpus' drivers/cpufreq/cpufreq.c:901: warning: Function parameter or member 'policy' not described in 'show_bios_limit' drivers/cpufreq/cpufreq.c:901: warning: Function parameter or member 'buf' not described in 'show_bios_limit' drivers/cpufreq/cpufreq.c:1625: warning: Function parameter or member 'dev' not described in 'cpufreq_remove_dev' drivers/cpufreq/cpufreq.c:1625: warning: Function parameter or member 'sif' not described in 'cpufreq_remove_dev' drivers/cpufreq/cpufreq.c:2380: warning: Function parameter or member 'cpu' not described in 'cpufreq_get_policy' drivers/cpufreq/cpufreq.c:2771: warning: Function parameter or member 'driver' not described in 'cpufreq_unregister_driver' Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-15cpufreq: freq_table: Demote obvious misuse of kerneldoc to standard comment ↵Lee Jones
blocks No attempt has been made to document any of the demoted functions here. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'policy' not described in 'show_available_freqs' drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'buf' not described in 'show_available_freqs' drivers/cpufreq/freq_table.c:229: warning: Function parameter or member 'show_boost' not described in 'show_available_freqs' drivers/cpufreq/freq_table.c:269: warning: Function parameter or member 'policy' not described in 'scaling_available_frequencies_show' drivers/cpufreq/freq_table.c:269: warning: Function parameter or member 'buf' not described in 'scaling_available_frequencies_show' drivers/cpufreq/freq_table.c:281: warning: Function parameter or member 'policy' not described in 'scaling_boost_frequencies_show' drivers/cpufreq/freq_table.c:281: warning: Function parameter or member 'buf' not described in 'scaling_boost_frequencies_show' Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-13cpufreq: intel_pstate: Fix active mode setting from command lineRafael J. Wysocki
If intel_pstate starts in the passive mode by default (that happens when the processor in the system doesn't support HWP), passing intel_pstate=active in the kernel command line doesn't work, so fix that. Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") Reported-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Doug Smythies <dsmythies@telus.net>
2020-07-13cpufreq: Replace HTTP links with HTTPS onesAlexander A. Klimov
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-13cpufreq: intel_pstate: Fix static checker warning for epp variableSrinivas Pandruvada
Fix warning for: drivers/cpufreq/intel_pstate.c:731 store_energy_performance_preference() error: uninitialized symbol 'epp'. This warning is for a case, when energy_performance_preference attribute matches pre defined strings. In this case the value of raw epp will not be used to set EPP bits in MSR_HWP_REQUEST. So initializing with any value is fine. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: Remove the weakly defined cpufreq_default_governor()Viresh Kumar
The default cpufreq governor is chosen with the help of a "choice" option in the Kconfig which will always end up selecting one of the governors and so the weakly defined definition of cpufreq_default_governor() will never get called. Moreover, this makes us skip the checking of the return value of that routine as it will always be non NULL. If the Kconfig option changes in future, then we will start getting a link error instead (and it won't go unnoticed as in the case of the weak definition). Suggested-by: Quentin Perret <qperret@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: Specify default governor on command lineQuentin Perret
Currently, the only way to specify the default CPUfreq governor is via Kconfig options, which suits users who can build the kernel themselves perfectly. However, for those who use a distro-like kernel (such as Android, with the Generic Kernel Image project), the only way to use a non-default governor is to boot to userspace, and to then switch using the sysfs interface. Being able to specify the default governor on the command line, like is the case for cpuidle, would allow those users to specify their governor of choice earlier on, and to simplify the userspace boot procedure slighlty. To support this use-case, add a kernel command line parameter allowing the default governor for CPUfreq to be specified, which takes precedence over the built-in default. This implementation has one notable limitation: the default governor must be registered before the driver. This is solved for builtin governors and drivers using appropriate *_initcall() functions. And in the modular case, this must be reflected as a constraint on the module loading order. Signed-off-by: Quentin Perret <qperret@google.com> [ Viresh: Converted 'default_governor' to a string and parsing it only at initcall level, and several updates to cpufreq_init_policy(). ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: Register governors at core_initcallQuentin Perret
Currently, most CPUFreq governors are registered at the core_initcall time when the given governor is the default one, and the module_init time otherwise. In preparation for letting users specify the default governor on the kernel command line, change all of them to be registered at the core_initcall unconditionally, as it is already the case for the schedutil and performance governors. This will allow us to assume that builtin governors have been registered before the built-in CPUFreq drivers probe. And since all governors have similar init/exit patterns now, introduce two new macros, cpufreq_governor_{init,exit}(), to factorize the code. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Quentin Perret <qperret@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: Fix locking issues with governorsViresh Kumar
The locking around governors handling isn't adequate currently. The list of governors should never be traversed without the locking in place. Also governor modules must not be removed while the code in them is still in use. Reported-by: Quentin Perret <qperret@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: All applicable <stable@vger.kernel.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: intel_pstate: Allow raw energy performance preference valueSrinivas Pandruvada
Currently using attribute "energy_performance_preference", user space can write one of the four per-defined preference string. These preference strings gets mapped to a hard-coded Energy-Performance Preference (EPP) or Energy-Performance Bias (EPB) knob. These four values are supposed to cover broad spectrum of use cases, but are not uniformly distributed in the range. There are number of cases, where this is not enough. For example: Suppose user wants more performance when connected to AC. Instead of using default "balance performance", the "performance" setting can be used. This changes EPP value from 0x80 to 0x00. But setting EPP to 0, results in electrical and thermal issues on some platforms. This results in aggressive throttling, which causes a drop in performance. But some value between 0x80 and 0x00 results in better performance. But that value can't be fixed as the power curve is not linear. In some cases just changing EPP from 0x80 to 0x75 is enough to get significant performance gain. Similarly on battery the default "balance_performance" mode can be aggressive in power consumption. But picking up the next choice "balance power" results in too much loss of performance, which results in bad user experience in use cases like "Google Hangout". It was observed that some value between these two EPP is optimal. This change allows fine grain EPP tuning for platform like Chromebook or for users who wants to fine tune power and performance. Here based on the product and use cases, different EPP values can be set. This change is similar to the change done for: /sys/devices/system/cpu/cpu*/power/energy_perf_bias where user has choice to write a predefined string or raw value. The change itself is trivial. When user preference doesn't match predefined string preferences and value is an unsigned integer and in range, use that value for EPP. When the EPP feature is not present writing raw value is not supported. Suggested-by: Len Brown <lenb@kernel.org> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02cpufreq: intel_pstate: Allow enable/disable energy efficiencySrinivas Pandruvada
By default intel_pstate the driver disables energy efficiency by setting MSR_IA32_POWER_CTL bit 19 for Kaby Lake desktop CPU model in HWP mode. This CPU model is also shared by Coffee Lake desktop CPUs. This allows these systems to reach maximum possible frequency. But this adds power penalty, which some customers don't want. They want some way to enable/ disable dynamically. So, add an additional attribute "energy_efficiency" under /sys/devices/system/cpu/intel_pstate/ for these CPU models. This allows to read and write bit 19 ("Disable Energy Efficiency Optimization") in the MSR IA32_POWER_CTL. This attribute is present in both HWP and non-HWP mode as this has an effect in both modes. Refer to Intel Software Developer's manual for details. The scope of this bit is package wide. Also these systems are single package systems. So read/write MSR on the current CPU is enough. The energy efficiency (EE) bit setting needs to be preserved during suspend/resume and CPU offline/online operation. To do this: - Restoring the EE setting from the cpufreq resume() callback, if there is change from the system default. - By default, don't disable EE from cpufreq init() callback for matching CPU models. Since the scope is package wide and is a single package system, move the disable EE calls from init() callback to intel_pstate_init() function, which is called only once. Suggested-by: Len Brown <lenb@kernel.org> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-01cpufreq: remove unicore32 driverMike Rapoport
The unicore32 port is removed from the kernel. There is no point to keep stale cpufreq driver for this architecture. Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net>
2020-06-30cpufreq: arm_scmi: Set fast_switch_possible conditionallyNicola Mazzucato
Currently the fast_switch_possible flag is set unconditionally to true. Based on this, schedutil does not create a thread for frequency switching and would always use the fast switch path. However, if the platform does not support SCMI fast channel, we use polling mode for SCMI message transfer. This may be possible only if there is dedicated channel for DVFS and all operations are in polling mode. Update this by retrieving the fast_switch capability based on the presence of fast channels in SCMI platform firmware. Link: https://lore.kernel.org/r/20200617094332.8391-2-nicola.mazzucato@arm.com Suggested-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-06-24OPP: refactor dev_pm_opp_of_register_em() and update related driversLukasz Luba
The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-24PM / EM: update callback structure and add device pointerLukasz Luba
The Energy Model framework is going to support devices other that CPUs. In order to make this happen change the callback function and add pointer to a device as an argument. Update the related users to use new function and new callback from the Energy Model. Acked-by: Quentin Perret <qperret@google.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-23cpufreq: intel_pstate: Add one more OOB control bitSrinivas Pandruvada
Add one more bit for OOB (Out Of Band) enabling of P-states. If OOB handling of P-states is enabled, intel_pstate shouldn't load. Currently, only "BIT(8) == 1" of the MSR MSR_MISC_PWR_MGMT is considered as OOB, but "BIT(18) == 1" needs to be taken into consideration as OOB condition too. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Add an empty code line, edit subject and changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-23cpufreq: blacklist SC7180 in cpufreq-dt-platdevSibi Sankar
Add SC7180 to cpufreq-dt-platdev blacklist since the actual scaling is handled by the 'qcom-cpufreq-hw' driver. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-06-23cpufreq: blacklist SDM845 in cpufreq-dt-platdevSibi Sankar
Add SDM845 to cpufreq-dt-platdev blacklist since the actual scaling is handled by the 'qcom-cpufreq-hw' driver. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-06-14treewide: replace '---help---' in Kconfig files with 'help'Masahiro Yamada
Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-10Merge tag 'pm-5.8-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "These are operating performance points (OPP) framework updates mostly, including support for interconnect bandwidth in the OPP core, plus a few cpufreq changes, including boost support in the CPPC cpufreq driver, an ACPI device power management fix and a hibernation code cleanup. Specifics: - Add support for interconnect bandwidth to the OPP core (Georgi Djakov, Saravana Kannan, Sibi Sankar, Viresh Kumar). - Add support for regulator enable/disable to the OPP core (Kamil Konieczny). - Add boost support to the CPPC cpufreq driver (Xiongfeng Wang). - Make the tegra186 cpufreq driver set the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag (Mian Yousaf Kaukab). - Prevent the ACPI power management from using power resources with devices where the list of power resources for power state D0 (full power) is missing (Rafael Wysocki). - Annotate a hibernation-related function with __init (Christophe JAILLET)" * tag 'pm-5.8-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PM: Avoid using power resources if there are none for D0 cpufreq: CPPC: add SW BOOST support cpufreq: change '.set_boost' to act on one policy PM: hibernate: Add __init annotation to swsusp_header_init() opp: Don't parse icc paths unnecessarily opp: Remove bandwidth votes when target_freq is zero opp: core: add regulators enable and disable opp: Reorder the code for !target_freq case opp: Expose bandwidth information via debugfs cpufreq: dt: Add support for interconnect bandwidth scaling opp: Update the bandwidth on OPP frequency changes opp: Add sanity checks in _read_opp_key() opp: Add support for parsing interconnect bandwidth cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flag OPP: Add helpers for reading the binding properties dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings
2020-06-10Merge branches 'pm-cpufreq' and 'pm-acpi'Rafael J. Wysocki
* pm-cpufreq: cpufreq: CPPC: add SW BOOST support cpufreq: change '.set_boost' to act on one policy cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flag * pm-acpi: ACPI: PM: Avoid using power resources if there are none for D0
2020-06-10Merge branch 'pm-opp'Rafael J. Wysocki
* pm-opp: opp: Don't parse icc paths unnecessarily opp: Remove bandwidth votes when target_freq is zero opp: core: add regulators enable and disable opp: Reorder the code for !target_freq case opp: Expose bandwidth information via debugfs cpufreq: dt: Add support for interconnect bandwidth scaling opp: Update the bandwidth on OPP frequency changes opp: Add sanity checks in _read_opp_key() opp: Add support for parsing interconnect bandwidth interconnect: Remove unused module exit code from core interconnect: Disallow interconnect core to be built as a module interconnect: Add of_icc_get_by_index() helper function OPP: Add helpers for reading the binding properties dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings
2020-06-05cpufreq: CPPC: add SW BOOST supportXiongfeng Wang
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 <wangxiongfeng2@huawei.com> Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-05cpufreq: change '.set_boost' to act on one policyXiongfeng Wang
Macro 'for_each_active_policy()' is defined internally. To avoid some cpufreq driver needing this macro to iterate over all the policies in '.set_boost' callback, we redefine '.set_boost' to act on only one policy and pass the policy as an argument. 'cpufreq_boost_trigger_state()' iterates over all the policies to set boost for the system. This is preparation for adding SW BOOST support for CPPC. To protect Boost enable/disable by sysfs from CPU online/offline, add 'cpu_hotplug_lock' before calling '.set_boost' for each CPU. Also move the lock from 'set_boost()' to 'store_cpb()' in acpi_cpufreq. Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-04Merge tag 'arm-drivers-5.8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM/SoC driver updates from Arnd Bergmann: "These are updates to SoC specific drivers that did not have another subsystem maintainer tree to go through for some reason: - Some bus and memory drivers for the MIPS P5600 based Baikal-T1 SoC that is getting added through the MIPS tree. - There are new soc_device identification drivers for TI K3, Qualcomm MSM8939 - New reset controller drivers for NXP i.MX8MP, Renesas RZ/G1H, and Hisilicon hi6220 - The SCMI firmware interface can now work across ARM SMC/HVC as a transport. - Mediatek platforms now use a new driver for their "MMSYS" hardware block that controls clocks and some other aspects in behalf of the media and gpu drivers. - Some Tegra processors have improved power management support, including getting woken up by the PMIC and cluster power down during idle. - A new v4l staging driver for Tegra is added. - Cleanups and minor bugfixes for TI, NXP, Hisilicon, Mediatek, and Tegra" * tag 'arm-drivers-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (155 commits) clk: sprd: fix compile-testing bus: bt1-axi: Build the driver into the kernel bus: bt1-apb: Build the driver into the kernel bus: bt1-axi: Use sysfs_streq instead of strncmp bus: bt1-axi: Optimize the return points in the driver bus: bt1-apb: Use sysfs_streq instead of strncmp bus: bt1-apb: Use PTR_ERR_OR_ZERO to return from request-regs method bus: bt1-apb: Fix show/store callback identations bus: bt1-apb: Include linux/io.h dt-bindings: memory: Add Baikal-T1 L2-cache Control Block binding memory: Add Baikal-T1 L2-cache Control Block driver bus: Add Baikal-T1 APB-bus driver bus: Add Baikal-T1 AXI-bus driver dt-bindings: bus: Add Baikal-T1 APB-bus binding dt-bindings: bus: Add Baikal-T1 AXI-bus binding staging: tegra-video: fix V4L2 dependency tee: fix crypto select drivers: soc: ti: knav_qmss_queue: Make knav_gp_range_ops static soc: ti: add k3 platforms chipid module driver dt-bindings: soc: ti: add binding for k3 platforms chipid module ...
2020-06-03Merge tag 'mips_5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds
Pull MIPS updates from Thomas Bogendoerfer: - added support for MIPSr5 and P5600 cores - converted Loongson PCI driver into a PCI host driver using the generic PCI framework - added emulation of CPUCFG command for Loogonson64 cpus - removed of LASAT, PMC MSP71xx and NEC MARKEINS/EMMA - ioremap cleanup - fix for a race between two threads faulting the same page - various cleanups and fixes * tag 'mips_5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (143 commits) MIPS: ralink: drop ralink_clk_init for mt7621 MIPS: ralink: bootrom: mark a function as __init to save some memory MIPS: Loongson64: Reorder CPUCFG model match arms MIPS: Expose Loongson CPUCFG availability via HWCAP MIPS: Loongson64: Guard against future cores without CPUCFG MIPS: Fix build warning about "PTR_STR" redefinition MIPS: Loongson64: Remove not used pci.c MIPS: Loongson64: Define PCI_IOBASE MIPS: CPU_LOONGSON2EF need software to maintain cache consistency MIPS: DTS: Fix build errors used with various configs MIPS: Loongson64: select NO_EXCEPT_FILL MIPS: Fix IRQ tracing when call handle_fpe() and handle_msa_fpe() MIPS: mm: add page valid judgement in function pte_modify mm/memory.c: Add memory read privilege on page fault handling mm/memory.c: Update local TLB if PTE entry exists MIPS: Do not flush tlb page when updating PTE entry MIPS: ingenic: Default to a generic board MIPS: ingenic: Add support for GCW Zero prototype MIPS: ingenic: DTS: Add memory info of GCW Zero MIPS: Loongson64: Switch to generic PCI driver ...
2020-06-01Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for v5.8-rc1 (part 2) from Viresh Kumar: "This contains a single patch to enable CPUFREQ_NEED_INITIAL_FREQ_CHECK flag for tegra driver." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flag
2020-06-01Merge branch 'opp/linux-next' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull operating performance points (OPP) framework changes for v5.8 from Viresh Kumar: "This contains: - support for interconnect bandwidth in the OPP core (Georgi Djakov, Saravana Kannan, Sibi Sankar, Viresh Kumar). - support for regulator enable/disable (Kamil Konieczny). This is based on three patches from the interconnect tree which shall get merged via Greg's tree." * 'opp/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: opp: Don't parse icc paths unnecessarily opp: Remove bandwidth votes when target_freq is zero opp: core: add regulators enable and disable opp: Reorder the code for !target_freq case opp: Expose bandwidth information via debugfs cpufreq: dt: Add support for interconnect bandwidth scaling opp: Update the bandwidth on OPP frequency changes opp: Add sanity checks in _read_opp_key() opp: Add support for parsing interconnect bandwidth interconnect: Remove unused module exit code from core interconnect: Disallow interconnect core to be built as a module interconnect: Add of_icc_get_by_index() helper function OPP: Add helpers for reading the binding properties dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings
2020-05-29cpufreq: dt: Add support for interconnect bandwidth scalingGeorgi Djakov
In addition to clocks and regulators, some devices can scale the bandwidth of their on-chip interconnect - for example between CPU and DDR memory. Add support for that, so that platforms which support it can make use of it. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Reused dev_pm_opp_of_find_icc_paths(). Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> fixup! cpufreq: dt: Add support for interconnect bandwidth scaling
2020-05-25Merge tag 'tegra-for-5.8-cpufreq' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers cpufreq: Changes for v5.8-rc1 This change move Tegra20 and Tegra30 to the generic DT CPU frequency scaling driver. * tag 'tegra-for-5.8-cpufreq' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now) Link: https://lore.kernel.org/r/20200515145311.1580134-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-05-18cpufreq: Fix up cpufreq_boost_set_sw()Rafael J. Wysocki
After commit 18c49926c4bf ("cpufreq: Add QoS requests for userspace constraints") the return value of freq_qos_update_request(), that can be 1, passed by cpufreq_boost_set_sw() to its caller sometimes confuses the latter, which only expects to see 0 or negative error codes, so notice that cpufreq_boost_set_sw() can return an error code (which should not be -EINVAL for that matter) as soon as the first policy without a frequency table is found (because either all policies have a frequency table or none of them have it) and rework it to meet its caller's expectations. Fixes: 18c49926c4bf ("cpufreq: Add QoS requests for userspace constraints") Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reported-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 5.3+ <stable@vger.kernel.org> # 5.3+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-18cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flagMian Yousaf Kaukab
The driver doesn't provide ->get() method to read current frequency and the frequency is set to 0 at initialization which makes the driver fail at initialization time. Set the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag for the driver, so the cpufreq core checks for the unlisted frequency and sets the CPU to a valid frequency from the frequency table. Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> [ Viresh: Massaged change log ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for v5.8 from Viresh Kumar: "- Build OMAP cpufreq driver by default for ARCH_OMAP2PLUS platform (Anders Roxell). - Fix compatible bindings for qcom cpufreq driver (Ansuel Smith). - Update qoriq cpufreq driver to automatically loaded when built as module and related changes (Mian Yousaf Kaukab and Geert Uytterhoeven). - Add support for r8a7742 to cpufreq-dt platform driver (Lad Prabhakar). - Add support for i.MX7ULP to imx cpufreq driver (Peng Fan)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qoriq: Add platform dependencies clk: qoriq: add cpufreq platform device cpufreq: qoriq: convert to a platform driver cpufreq: qcom: fix wrong compatible binding cpufreq: imx-cpufreq-dt: support i.MX7ULP cpufreq: dt: Add support for r8a7742 cpufreq: Add i.MX7ULP to cpufreq-dt-platdev blacklist cpufreq: omap: Build driver by default for ARCH_OMAP2PLUS
2020-05-08cpufreq: qoriq: Add platform dependenciesGeert Uytterhoeven
The Freescale QorIQ clock controller is only present on Freescale E500MC and Layerscape SoCs. Add platform dependencies to the QORIQ_CPUFREQ config symbol, to avoid asking the user about it when configuring a kernel without E500MC or Layerscape support. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-07cpufreq: qoriq: convert to a platform driverMian Yousaf Kaukab
The driver has to be manually loaded if it is built as a module. It is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover, no platform-device is created (and thus no uevent is sent) for the clockgen nodes it depends on. Convert the module to a platform driver with its own alias. Moreover, drop whitelisted SOCs. Platform device will be created only for the compatible platforms. Reviewed-by: Yuantian Tang <andy.tang@nxp.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-06cpufreq: tegra20: Use generic cpufreq-dt driver (Tegra30 supported now)Dmitry Osipenko
Re-parenting to intermediate clock is supported now by the clock driver and thus there is no need in a customized CPUFreq driver, all that code is common for both Tegra20 and Tegra30. The available CPU freqs are now specified in device-tree in a form of OPPs, all users should update their device-trees. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Marcel Ziswiler <marcel@ziswiler.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-05-04cpufreq: qcom: fix wrong compatible bindingAnsuel Smith
Binding in Documentation is still "operating-points-v2-kryo-cpu". Restore the old binding to fix the compatibility problem. Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-02Merge back cpufreq material for v5.8.Rafael J. Wysocki
2020-04-28cpufreq: imx-cpufreq-dt: support i.MX7ULPPeng Fan
i.MX7ULP's ARM core clock design is totally different compared with i.MX7D/8M SoCs which supported by imx-cpufreq-dt. It needs get_intermediate and target_intermedate to configure clk MUX ready, before let OPP configure ARM core clk. |---FIRC |------RUN---...---SCS(MUX2) --------| ARM --(MUX1) |---SPLL_PFD0(CLK_SET_RATE_GATE) |------HSRUN--...--HSRUN_SCS(MUX3)---| |---SRIC FIRC is step clk, SPLL_PFD0 is the normal clk driving ARM core. MUX2 and MUX3 share same inputs. So if MUX2/MUX3 both sources from SPLL_PFD0, both MUXes will lose input when configure SPLL_PFD0. So the target_intermediate will configure MUX2/MUX3 to FIRC, to avoid ARM core lose clk when configure SPLL_PFD0. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-04-28cpufreq: dt: Add support for r8a7742Lad Prabhakar
Add the compatible strings for supporting the generic cpufreq driver on the Renesas RZ/G1H (R8A7742) SoC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>