summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/freq_table.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: Fix up printing large CPU numbers and frequency valuesJoshua Yeong2024-04-301-2/+2
| | | | | | | | | | | A negative CPU number or frequency value may be printed if they are really large (which is unlikely, though). Signed-off-by: Joshua Yeong <joshua.yeong@starfivetech.com> Reviewed-by: Thorsten Blum <thorsten.blum@toblux.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject and changelog edits. ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Use a smaller freq for the policy->max when verifyXuewen Yan2024-03-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When driver use the cpufreq_frequency_table_verify() as the cpufreq_driver->verify's callback. It may cause the policy->max bigger than the freq_qos's max freq. Just as follow: unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_available_frequencies 614400 768000 988000 1228800 1469000 1586000 1690000 1833000 2002000 2093000 unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_max_freq unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_min_freq unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_max_freq 2002000 unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_min_freq 2002000 When user set the qos_min and qos_max as the same value, and the value is not in the freq-table, the above scenario will occur. This is because in cpufreq_frequency_table_verify() func, when it can not find the freq in table, it will change the policy->max to be a bigger freq, as above, because there is no 1.9G in the freq-table, the policy->max would be set to 2.002G. As a result, the cpufreq_policy->max is bigger than the user's qos_max. This is unreasonable. So use a smaller freq when can not find the freq in fre-table, to prevent the policy->max exceed the qos's max freq. Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()Sibi Sankar2024-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | In the existing code, per-policy flags don't have any impact i.e. if cpufreq_driver boost is enabled and boost is disabled for one or more of the policies, the cpufreq driver will behave as if boost is enabled. Fix this by incorporating per-policy boost flag in the policy->max computation used in cpufreq_frequency_table_cpuinfo and setting the default per-policy boost to mirror the cpufreq_driver boost flag. Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost") Reported-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Tested-by:Yipeng Zou <zouyipeng@huawei.com> <mailto:zouyipeng@huawei.com> Reviewed-by: Yipeng Zou <zouyipeng@huawei.com> <mailto:zouyipeng@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'cpufreq-arm-updates-6.4' of ↵Rafael J. Wysocki2023-04-201-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull cpufreq/ARM updates for 6.4 from Viresh Kumar: "- Add opp and bandwidth support to tegra194 cpufreq driver (Sumit Gupta). - Use of_property_present() for testing DT property presence (Rob Herring). - Remove MODULE_LICENSE in non-modules (Nick Alcock). - Add SM7225 to cpufreq-dt-platdev blocklist (Luca Weiss). - Optimizations and fixes for qcom-cpufreq-hw driver (Krzysztof Kozlowski, Konrad Dybcio, and Bjorn Andersson). - DT binding updates for qcom-cpufreq-hw driver (Konrad Dybcio and Bartosz Golaszewski). - Updates and fixes for mediatek driver (Jia-Wei Chang and AngeloGioacchino Del Regno)."
| * kbuild, cpufreq: remove MODULE_LICENSE in non-modulesNick Alcock2023-03-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* | cpufreq: drivers with target_index() must set freq_tableViresh Kumar2023-04-071-1/+6
|/ | | | | | | | | | | | | | Since the cpufreq core directly uses freq_table, for cpufreq drivers that set their target_index() callback, make it mandatory for them to set the same. Since this is set per policy and normally from policy->init(), do this from cpufreq_table_validate_and_sort() which gets called right after ->init(). Reported-by: Yajun Deng <yajun.deng@linux.dev> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Fix scaling_{available,boost}_frequencies_show() commentsGeert Uytterhoeven2021-03-261-2/+2
| | | | | | | | | | The function names in the comment blocks for the functions scaling_available_frequencies_show() and scaling_boost_frequencies_show() do not match the actual names. Fixes: 6f19efc0a1ca08bc ("cpufreq: Add boost frequency support in core") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is knownRafael J. Wysocki2021-02-181-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") attempted to address a performance issue involving acpi-cpufreq, the schedutil governor and scale-invariance on x86 by extending the frequency tables created by acpi-cpufreq to cover the entire range of "turbo" (or "boost") frequencies, but that caused frequencies reported via /proc/cpuinfo and the scaling_cur_freq attribute in sysfs to change which may confuse users and monitoring tools. For this reason, revert the part of commit 3c55e94c0ade adding the extra entry to the frequency table and use the observation that in principle cpuinfo.max_freq need not be equal to the maximum frequency listed in the frequency table for the given policy. Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq drivers to set their own cpuinfo.max_freq above that frequency and change acpi-cpufreq to set cpuinfo.max_freq to the maximum boost frequency found via CPPC. This should be sufficient to let all of the cpufreq subsystem know the real maximum frequency of the CPU without changing frequency reporting. Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305 Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Matt McDonald <gardotd426@gmail.com> Tested-by: Matt McDonald <gardotd426@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz> Tested-by: Michael Larabel <Michael@phoronix.com> Cc: 5.11+ <stable@vger.kernel.org> # 5.11+
* cpufreq: freq_table: Demote obvious misuse of kerneldoc to standard comment ↵Lee Jones2020-07-151-3/+3
| | | | | | | | | | | | | | | | | | | | 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>
* cpufreq: Avoid creating excessively large stack framesRafael J. Wysocki2020-01-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <lkp@intel.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 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 version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: boost: Remove CONFIG_CPU_FREQ_BOOST_SW Kconfig optionYue Hu2019-04-101-3/+0
| | | | | | | | | | | | | Commit 2fb4719b2560 ("cpufreq / boost: Kconfig: Support for software-managed BOOST") added the CONFIG_CPU_FREQ_BOOST_SW config. However EXYNOS based cpufreq drivers have been removed because of switching to cpufreq-dt driver which will set boost-attr if required. So, let's remove this option and update cpufreq_generic_attr[]. Signed-off-by: Yue Hu <huyue2@yulong.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Drop cpufreq_table_validate_and_show()Viresh Kumar2018-04-101-14/+0
| | | | | | | | This isn't used anymore. Remove the helper and update documentation accordingly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Validate frequency table in the coreViresh Kumar2018-02-271-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | By design, cpufreq drivers are responsible for calling cpufreq_frequency_table_cpuinfo() from their ->init() callbacks to validate the frequency table. However, if a cpufreq driver is buggy and fails to do so properly, it lead to unexpected behavior of the driver or the cpufreq core at a later point in time. It would be better if the core could validate the frequency table during driver initialization. To that end, introduce cpufreq_table_validate_and_sort() and make the cpufreq core call it right after invoking the ->init() callback of the driver and destroy the cpufreq policy if the table is invalid. For the time being the validation of the table happens twice, once from the driver and then from the core. The individual drivers will be updated separately to drop table validation if they don't need it for other reasons. The frequency table is marked "sorted" or "unsorted" by the new helper now instead of in cpufreq_table_validate_and_show(), as it should only be done after validating the table (which the drivers won't do going forward). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject/changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Add and use cpufreq_for_each_{valid_,}entry_idx()Dominik Brodowski2018-02-081-4/+4
| | | | | | | | | | | | Pointer subtraction is slow and tedious. Therefore, replace all instances where cpufreq_for_each_{valid_,}entry loops contained such substractions with an iteration macro providing an index to the frequency_table entry. Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Link: http://lkml.kernel.org/r/20180120020237.GM13338@ZenIV.linux.org.uk Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Handle sorted frequency tables more efficientlyViresh Kumar2016-07-071-8/+65
| | | | | | | | | | | | | cpufreq drivers aren't required to provide a sorted frequency table today, and even the ones which provide a sorted table aren't handled efficiently by cpufreq core. This patch adds infrastructure to verify if the freq-table provided by the drivers is sorted or not, and use efficient helpers if they are sorted. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Return index from cpufreq_frequency_table_target()Viresh Kumar2016-06-091-11/+13
| | | | | | | | | | | This routine can't fail unless the frequency table is invalid and doesn't contain any valid entries. Make it return the index and WARN() in case it is used for an invalid table. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Drop freq-table param to cpufreq_frequency_table_target()Viresh Kumar2016-06-091-1/+1
| | | | | | | The policy already has this pointer set, use it instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Remove cpufreq_frequency_get_table()Viresh Kumar2016-06-091-6/+3
| | | | | | | | | | | | | | | | | | | | | | Most of the callers of cpufreq_frequency_get_table() already have the pointer to a valid 'policy' structure and they don't really need to go through the per-cpu variable first and then a check to validate the frequency, in order to find the freq-table for the policy. Directly use the policy->freq_table field instead for them. Only one user of that API is left after above changes, cpu_cooling.c and it accesses the freq_table in a racy way as the policy can get freed in between. Fix it by using cpufreq_cpu_get() properly. Since there are no more users of cpufreq_frequency_get_table() left, get rid of it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@arm.com> (cpu_cooling.c) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Unexport cpufreq_frequency_table_cpuinfo()Viresh Kumar2016-06-021-2/+0
| | | | | | | | | | | | All cpufreq drivers with a freq-table are migrated to use cpufreq_table_validate_and_show() long back and the routine cpufreq_frequency_table_cpuinfo() isn't used outside of cpufreq core now. Unexport it and update Documentation as well. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Allow drivers to enable boost support after registering driverViresh Kumar2015-08-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | In some cases it wouldn't be known at time of driver registration, if the driver needs to support boost frequencies. For example, while getting boost information from DT with opp-v2 bindings, we need to parse the bindings for all the CPUs to know if turbo/boost OPPs are supported or not. One way out to do that efficiently is to delay supporting boost mode (i.e. creating /sys/devices/system/cpu/cpufreq/boost file), until the time OPP bindings are parsed. At that point, the driver can enable boost support. This can be done at ->init(), where the frequency table is created. To do that, the driver requires few APIs from cpufreq core that let him do this. This patch provides these APIs. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Allow freq_table to be obtained for offline CPUsViresh Kumar2015-07-101-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | Users of freq table may want to access it for any CPU from policy->related_cpus mask. One such user is cpu-cooling layer. It gets a list of 'clip_cpus' (equivalent to policy->related_cpus) during registration and tries to get freq_table for the first CPU of this mask. If the CPU, for which it tries to fetch freq_table, is offline, cpufreq_frequency_get_table() fails. This happens because it relies on cpufreq_cpu_get_raw() for its functioning which returns policy only for online CPUs. The fix is to access the policy data structure for the given CPU directly (which also returns a valid policy for offline CPUs), but the policy itself has to be active (meaning that at least one CPU using it is online) for the frequency table to be returned. Because we will be using 'cpufreq_cpu_data' now, which is internal to the cpufreq core, move cpufreq_frequency_get_table() to cpufreq.c. Reported-and-tested-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Introduce new relation for freq selectionStratos Karafotis2014-07-211-1/+11
| | | | | | | | | | Introduce CPUFREQ_RELATION_C for frequency selection. It selects the frequency with the minimum euclidean distance to target. In case of equal distance between 2 frequencies, it will select the greater frequency. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Break out early when frequency equals target_freqStratos Karafotis2014-05-201-2/+6
| | | | | | | | | | | | | | | | | | | Many drivers keep frequencies in frequency table in ascending or descending order. When governor tries to change to policy->min or policy->max respectively then the cpufreq_frequency_table_target could return on first iteration. This will save some iteration cycles. So, break out early when a frequency in cpufreq_frequency_table equals to target one. Testing this during kernel compilation using ondemand governor with a frequency table in ascending order, the cpufreq_frequency_table_target returned early on the first iteration at about 30% of times called. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Use cpufreq_for_each_* macros for frequency table iterationStratos Karafotis2014-04-301-31/+25
| | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_entry and cpufreq_for_each_valid_entry macros helpers for iteration over the cpufreq_frequency_table, so use them. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: create another field .flags in cpufreq_frequency_tableViresh Kumar2014-04-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | Currently cpufreq frequency table has two fields: frequency and driver_data. driver_data is only for drivers' internal use and cpufreq core shouldn't use it at all. But with the introduction of BOOST frequencies, this assumption was broken and we started using it as a flag instead. There are two problems due to this: - It is against the description of this field, as driver's data is used by the core now. - if drivers fill it with -3 for any frequency, then those frequencies are never considered by cpufreq core as it is exactly same as value of CPUFREQ_BOOST_FREQ, i.e. ~2. The best way to get this fixed is by creating another field flags which will be used for such flags. This patch does that. Along with that various drivers need modifications due to the change of struct cpufreq_frequency_table. Reviewed-by: Gautham R Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: don't print value of .driver_data from coreViresh Kumar2014-04-071-4/+3
| | | | | | | | | | | CPUFreq core doesn't control value of .driver_data and this field is completely driver specific. This can contain any value and not only indexes. For most of the drivers, which aren't using this field, its value is zero. So, printing this from core doesn't make any sense. Don't print it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: add 'freq_table' in struct cpufreq_policyViresh Kumar2014-03-121-38/+8
| | | | | | | | | | | freq table is not per CPU but per policy, so it makes more sense to keep it within struct cpufreq_policy instead of a per-cpu variable. This patch does it. Over that, there is no need to set policy->freq_table to NULL in ->exit(), as policy structure is going to be freed soon. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Add boost frequency support in coreLukasz Majewski2014-01-171-7/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds boost frequency support in cpufreq core (Hardware & Software). Some SoCs (like Exynos4 - e.g. 4x12) allow setting frequency above its normal operation limits. Such mode shall be only used for a short time. Overclocking (boost) support is essentially provided by platform dependent cpufreq driver. This commit unifies support for SW and HW (Intel) overclocking solutions in the core cpufreq driver. Previously the "boost" sysfs attribute was defined in the ACPI processor driver code. By default boost is disabled. One global attribute is available at: /sys/devices/system/cpu/cpufreq/boost. It only shows up when cpufreq driver supports overclocking. Under the hood frequencies dedicated for boosting are marked with a special flag (CPUFREQ_BOOST_FREQ) at driver's frequency table. It is the user's concern to enable/disable overclocking with a proper call to sysfs. The cpufreq_boost_trigger_state() function is defined non static on purpose. It is used later with thermal subsystem to provide automatic enable/disable of the BOOST feature. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Make sure CPU is running on a freq from freq-tableViresh Kumar2014-01-061-0/+22
| | | | | | | | | | | | | | | | | | | | | | Sometimes boot loaders set CPU frequency to a value outside of frequency table present with cpufreq core. In such cases CPU might be unstable if it has to run on that frequency for long duration of time and so its better to set it to a frequency which is specified in freq-table. This also makes cpufreq stats inconsistent as cpufreq-stats would fail to register because current frequency of CPU isn't found in freq-table. Because we don't want this change to affect boot process badly, we go for the next freq which is >= policy->cur ('cur' must be set by now, otherwise we will end up setting freq to lowest of the table as 'cur' is initialized to zero). In case current frequency doesn't match any frequency from freq-table, we throw warnings to user, so that user can get this fixed in their bootloaders or freq-tables. Reported-by: Carlos Hernandez <ceh@ti.com> Reported-and-tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: define generic .attr, .exit() and .verify() routinesViresh Kumar2013-10-161-0/+20
| | | | | | | | | | | Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch introduces generic .attr, .exit() and .verify() cpufreq drivers. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: add new routine cpufreq_verify_within_cpu_limits()Viresh Kumar2013-10-161-4/+2
| | | | | | | | | | | | | | Most of the users of cpufreq_verify_within_limits() calls it for limiting with min/max from policy->cpuinfo. We can make that code simple by introducing another routine which will do this for them automatically. This patch adds another routine cpufreq_verify_within_cpu_limits() and updates others to use it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Optimize cpufreq_frequency_table_verify()Viresh Kumar2013-10-161-12/+13
| | | | | | | | | | | | | cpufreq_frequency_table_verify() is rewritten here to make it more logical and efficient. - merge multiple lines for variable declarations together. - quit early if any frequency between min/max is found. - don't call cpufreq_verify_within_limits() in case any valid freq is found as it is of no use. - rename the count variable as found and change its type to boolean. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Add new helper cpufreq_table_validate_and_show()Viresh Kumar2013-09-301-0/+12
| | | | | | | | | | | | | | | | | Almost every cpufreq driver is required to validate its frequency table with: cpufreq_frequency_table_cpuinfo() and then expose it to cpufreq core with: cpufreq_frequency_table_get_attr(). This patch creates another helper routine cpufreq_table_validate_and_show() that will do both these steps in a single call and will return 0 for success, error otherwise. This also fixes potential bugs in cpufreq drivers where people have called cpufreq_frequency_table_get_attr() before calling cpufreq_frequency_table_cpuinfo(), as the later may fail. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Clean up header files included in the coreViresh Kumar2013-08-071-3/+1
| | | | | | | | | | | | | | | | This patch addresses the following issues in the header files in the cpufreq core: - Include headers in ascending order, so that we don't add same many times by mistake. - <asm/> must be included after <linux/>, so that they override whatever they need to. - Remove unnecessary includes. - Don't include files already included by cpufreq.h or cpufreq_governor.h. [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: rename index as driver_data in cpufreq_frequency_tableViresh Kumar2013-06-041-13/+13
| | | | | | | | | | | | | | | | | The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful for cpufreq drivers for their internal purposes. Many people nowadays blindly set it in ascending order with the assumption that the core will use it, which is a mistake. Rename it to "driver_data" as that's what its purpose is. All of its users are updated accordingly. [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Don't check cpu_online(policy->cpu)Viresh Kumar2013-02-091-6/+0
| | | | | | | | policy->cpu or cpus in policy->cpus can't be offline anymore. And so we don't need to check if they are online or not. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Simplify __cpufreq_remove_dev()Viresh Kumar2013-02-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | __cpufreq_remove_dev() is called on multiple occasions: cpufreq_driver unregister and cpu removals. Current implementation of this routine is overly complex without much need. If the cpu to be removed is the policy->cpu, we remove the policy first and add all other cpus again from policy->cpus and then finally call __cpufreq_remove_dev() again to remove the cpu to be deleted. Haahhhh.. There exist a simple solution to removal of a cpu: - Simply use the old policy structure - update its fields like: policy->cpu, etc. - notify any users of cpufreq, which depend on changing policy->cpu Hence this patch, which tries to implement the above theory. It is tested well by myself on ARM big.LITTLE TC2 SoC, which has 5 cores (2 A15 and 3 A7). Both A15's share same struct policy and all A7's share same policy structure. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Improve debug printsViresh Kumar2012-11-151-0/+2
| | | | | | | | With debug options on, it is difficult to locate cpufreq core's debug prints. Fix this by prefixing debug prints with KBUILD_MODNAME. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* [CPUFREQ] use dynamic debug instead of custom infrastructureDominik Brodowski2011-05-041-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With dynamic debug having gained the capability to report debug messages also during the boot process, it offers a far superior interface for debug messages than the custom cpufreq infrastructure. As a first step, remove the old cpufreq_debug_printk() function and replace it with a call to the generic pr_debug() function. How can dynamic debug be used on cpufreq? You need a kernel which has CONFIG_DYNAMIC_DEBUG enabled. To enabled debugging during runtime, mount debugfs and $ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control for debugging the complete "cpufreq" module. To achieve the same goal during boot, append ddebug_query="module cpufreq +p" as a boot parameter to the kernel of your choice. For more detailled instructions, please see Documentation/dynamic-debug-howto.txt Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com>
* percpu: make percpu symbols in cpufreq uniqueTejun Heo2009-10-291-6/+6
| | | | | | | | | | | | | | | | | | This patch updates percpu related symbols in cpufreq such that percpu symbols are unique and don't clash with local symbols. This serves two purposes of decreasing the possibility of global percpu symbol collision and allowing dropping per_cpu__ prefix from percpu symbols. * drivers/cpufreq/cpufreq.c: s/policy_cpu/cpufreq_policy_cpu/ * drivers/cpufreq/freq_table.c: s/show_table/cpufreq_show_table/ * arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: s/drv_data/acfreq_data/ s/old_perf/acfreq_old_perf/ Partly based on Rusty Russell's "alloc_percpu: rename percpu vars which cause name clashes" patch. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Rusty Russell <rusty@rustcorp.com.au>
* [CPUFREQ] checkpatch cleanups for freq_tableDave Jones2009-02-251-9/+9
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* Merge branch 'next' of ↵Linus Torvalds2008-07-221-6/+6
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] cpufreq: remove CVS keywords [CPUFREQ] change cpu freq arrays to per_cpu variables
| * [CPUFREQ] change cpu freq arrays to per_cpu variablesMike Travis2008-05-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change cpufreq_policy and cpufreq_governor pointer tables from arrays to per_cpu variables in the cpufreq subsystem. Also some minor complaints from checkpatch.pl fixed. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Dave Jones <davej@redhat.com>
* | [CPUFREQ] clarify license of freq_table.cDominik Brodowski2008-05-221-0/+5
|/ | | | | Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] fix incorrect comment on show_available_freqs() in freq_table.cFenghua Yu2008-02-071-1/+1
| | | | | | | | | In freq_table.c, show_available_freqs()'s comment is oberviously wrong. Change the comment to a new one to avoid confusion. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
* sysfs: kill unnecessary attribute->ownerTejun Heo2007-07-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | sysfs is now completely out of driver/module lifetime game. After deletion, a sysfs node doesn't access anything outside sysfs proper, so there's no reason to hold onto the attribute owners. Note that often the wrong modules were accounted for as owners leading to accessing removed modules. This patch kills now unnecessary attribute->owner. Note that with this change, userland holding a sysfs node does not prevent the backing module from being unloaded. For more info regarding lifetime rule cleanup, please read the following message. http://article.gmane.org/gmane.linux.kernel/510293 (tweaked by Greg to not delete the field just yet, to make it easier to merge things properly.) Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [CPUFREQ] Fix coding style issues in cpufreq.Gautham R Shenoy2006-11-071-10/+18
| | | | | | | | Clean up cpufreq subsystem to fix coding style issues and to improve the readability. Signed-off-by: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove more freq_table reinitialisations.Dave Jones2006-05-311-4/+8
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix another redundant initialisation in freq_tableDave Jones2006-05-301-1/+1
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 08:24:44 +0100