summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/Kconfig
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: Add Loongson-3 CPUFreq driver supportHuacai Chen2024-07-091-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of LoongArch processors (Loongson-3 series) support DVFS, their IOCSR.FEATURES has IOCSRF_FREQSCALE set. And they has a micro-core in the package called SMC (System Management Controller), which can be used to detect temperature, control fans, scale frequency and voltage, etc. The Loongson-3 CPUFreq driver is very simple now, it communicate with SMC, get DVFS info, set target frequency from CPUFreq core, and so on. There is a command list to interact with SMC, widely-used commands in the CPUFreq driver include: CMD_GET_VERSION: Get SMC firmware version. CMD_GET_FEATURE: Get enabled SMC features. CMD_SET_FEATURE: Enable SMC features, such as basic DVFS, BOOST. CMD_GET_FREQ_LEVEL_NUM: Get the number of all frequency levels. CMD_GET_FREQ_BOOST_LEVEL: Get the first boost frequency level. CMD_GET_FREQ_LEVEL_INFO: Get the detail info of a frequency level. CMD_GET_FREQ_INFO: Get the current frequency. CMD_SET_FREQ_INFO: Set the target frequency. In future we will add automatic frequency scaling, which is similar to Intel's HWP (HardWare P-State). Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> [ Viresh: Minor formatting cleanups, change return type of exit() to void and use devm_mutex_init() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* cpufreq: Move CPPC configs to common Kconfig and add RISC-VSunil V L2024-03-191-0/+29
| | | | | | | | | | | | | | | CPPC related config options are currently defined only in ARM specific file. However, they are required for RISC-V as well. Instead of creating a new Kconfig.riscv file and duplicating them, move them to the common Kconfig file and enable RISC-V too. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20240208034414.22579-3-sunilvl@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
* arch: Remove Itanium (IA-64) architectureArd Biesheuvel2023-09-111-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OFViresh Kumar2023-06-301-0/+1
| | | | | | | | | | The cpufreq-dt-platform.c driver requires CONFIG_OF to be selected. Mark it as a dependency. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306250025.savpMM8L-lkp@intel.com/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'cpufreq-arm-updates-6.5' of ↵Rafael J. Wysocki2023-06-271-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 6.5 from Viresh Kumar: "- Add support to build cpufreq-dt-platdev as module (Zhipeng Wang). - Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar). - Add support for TI's AM62A7 platform (Vibhore Vardhan). - Add support for Armada's ap807 platform (Russell King (Oracle)). - Add support for StarFive JH7110 SoC (Mason Huo). - Fix voltage selection for Mediatek Socs (Daniel Golle). - Fix error handling in Tegra's cpufreq driver (Christophe JAILLET). - Document Qualcomm's IPQ8074 in DT bindings (Robert Marko). - Don't warn for disabling a non-existing frequency for imx6q cpufreq driver (Christoph Niedermaier). - Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney)."
| * cpufreq: dt-platdev: Support building as moduleZhipeng Wang2023-06-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | Make the cpufreq platdev driver as tristate so that it can be built as loadable module. Also add MODULE_LICENSE to support building as module. Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com> [ Viresh: Merged two commits, included module.h ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* | cpufreq: amd-pstate: Set default governor to schedutilMario Limonciello2023-06-201-1/+1
|/ | | | | | | | | | | | | | | The Kconfig currently defaults the governor to schedutil on x86_64 only when intel-pstate and SMP have been selected. If the kernel is built only with amd-pstate, the default governor should also be schedutil. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Tested-by: Perry Yuan <Perry.Yuan@amd.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm-6.3-rc1' of ↵Linus Torvalds2023-02-211-10/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "These add EPP support to the AMD P-state cpufreq driver, add support for new platforms to the Intel RAPL power capping driver, intel_idle and the Qualcomm cpufreq driver, enable thermal cooling for Tegra194, drop the custom cpufreq driver for loongson1 that is not necessary any more (and the corresponding cpufreq platform device), fix assorted issues and clean up code. Specifics: - Add EPP support to the AMD P-state cpufreq driver (Perry Yuan, Wyes Karny, Arnd Bergmann, Bagas Sanjaya) - Drop the custom cpufreq driver for loongson1 that is not necessary any more and the corresponding cpufreq platform device (Keguang Zhang) - Remove "select SRCU" from system sleep, cpufreq and OPP Kconfig entries (Paul E. McKenney) - Enable thermal cooling for Tegra194 (Yi-Wei Wang) - Register module device table and add missing compatibles for cpufreq-qcom-hw (Nícolas F. R. A. Prado, Abel Vesa and Luca Weiss) - Various dt binding updates for qcom-cpufreq-nvmem and opp-v2-kryo-cpu (Christian Marangi) - Make kobj_type structure in the cpufreq core constant (Thomas Weißschuh) - Make cpufreq_unregister_driver() return void (Uwe Kleine-König) - Make the TEO cpuidle governor check CPU utilization in order to refine idle state selection (Kajetan Puchalski) - Make Kconfig select the haltpoll cpuidle governor when the haltpoll cpuidle driver is selected and replace a default_idle() call in that driver with arch_cpu_idle() to allow MWAIT to be used (Li RongQing) - Add Emerald Rapids Xeon support to the intel_idle driver (Artem Bityutskiy) - Add ARCH_SUSPEND_POSSIBLE dependencies for ARMv4 cpuidle drivers to avoid randconfig build failures (Arnd Bergmann) - Make kobj_type structures used in the cpuidle sysfs interface constant (Thomas Weißschuh) - Make the cpuidle driver registration code update microsecond values of idle state parameters in accordance with their nanosecond values if they are provided (Rafael Wysocki) - Make the PSCI cpuidle driver prevent topology CPUs from being suspended on PREEMPT_RT (Krzysztof Kozlowski) - Document that pm_runtime_force_suspend() cannot be used with DPM_FLAG_SMART_SUSPEND (Richard Fitzgerald) - Add EXPORT macros for exporting PM functions from drivers (Richard Fitzgerald) - Remove /** from non-kernel-doc comments in hibernation code (Randy Dunlap) - Fix possible name leak in powercap_register_zone() (Yang Yingliang) - Add Meteor Lake and Emerald Rapids support to the intel_rapl power capping driver (Zhang Rui) - Modify the idle_inject power capping facility to support 100% idle injection (Srinivas Pandruvada) - Fix large time windows handling in the intel_rapl power capping driver (Zhang Rui) - Fix memory leaks with using debugfs_lookup() in the generic PM domains and Energy Model code (Greg Kroah-Hartman) - Add missing 'cache-unified' property in the example for kryo OPP bindings (Rob Herring) - Fix error checking in opp_migrate_dentry() (Qi Zheng) - Let qcom,opp-fuse-level be a 2-long array for qcom SoCs (Konrad Dybcio) - Modify some power management utilities to use the canonical ftrace path (Ross Zwisler) - Correct spelling problems for Documentation/power/ as reported by codespell (Randy Dunlap)" * tag 'pm-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (53 commits) Documentation: amd-pstate: disambiguate user space sections cpufreq: amd-pstate: Fix invalid write to MSR_AMD_CPPC_REQ dt-bindings: opp: opp-v2-kryo-cpu: enlarge opp-supported-hw maximum dt-bindings: cpufreq: qcom-cpufreq-nvmem: make cpr bindings optional dt-bindings: cpufreq: qcom-cpufreq-nvmem: specify supported opp tables PM: Add EXPORT macros for exporting PM functions cpuidle: psci: Do not suspend topology CPUs on PREEMPT_RT MIPS: loongson32: Drop obsolete cpufreq platform device powercap: intel_rapl: Fix handling for large time window cpuidle: driver: Update microsecond values of state parameters as needed cpuidle: sysfs: make kobj_type structures constant cpuidle: add ARCH_SUSPEND_POSSIBLE dependencies PM: EM: fix memory leak with using debugfs_lookup() PM: domains: fix memory leak with using debugfs_lookup() cpufreq: Make kobj_type structure constant cpufreq: davinci: Fix clk use after free cpufreq: amd-pstate: avoid uninitialized variable use cpufreq: Make cpufreq_unregister_driver() return void OPP: fix error checking in opp_migrate_dentry() dt-bindings: cpufreq: cpufreq-qcom-hw: Add SM8550 compatible ...
| * drivers/cpufreq: Remove "select SRCU"Paul E. McKenney2023-01-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | Now that the SRCU Kconfig option is unconditionally selected, there is no longer any point in selecting it. Therefore, remove the "select SRCU" Kconfig statements. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: loongson1: Delete obsolete driverKeguang Zhang2023-01-201-9/+0
| | | | | | | | | | | | | | | | The generic DT based cpufreq driver works for Loongson-1, so delete the old custom driver. Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: remove sa1100 driverArnd Bergmann2023-01-161-1/+1
|/ | | | | | | | | | The sa11xx platform has two cpufreq drivers, one for the older StrongARM1100 SoC, and a second one for StrongARM1110. After the removal of most SA1100 based machines, this driver is unused, and only the sa1110-cpufreq driver remains. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* cpufreq: loongson2: fix Kconfig "its" grammarRandy Dunlap2022-07-251-1/+1
| | | | | | | | Use the possessive "its" instead of the contraction "it's" where appropriate. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Kconfig: fix documentation linksAlexander Monakov2021-04-211-17/+6
| | | | | | | | | | | | | User documentation for cpufreq governors and drivers has been moved to admin-guide; adjust references from Kconfig entries accordingly. Remove references from undocumented cpufreq drivers, as well as the 'userspace' cpufreq governor, for which no additional details are provided in the admin-guide text. Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation") Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Avoid configuring old governors as default with intel_pstateRafael J. Wysocki2020-10-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") was meant to cause intel_pstate to be used in the passive mode with the schedutil governor on top of it, but it missed the case in which either "ondemand" or "conservative" was selected as the default governor in the existing kernel config, in which case the previous old governor configuration would be used, causing the default legacy governor to be used on top of intel_pstate instead of schedutil. Address this by preventing "ondemand" and "conservative" from being configured as the default cpufreq governor in the case when schedutil is the default choice for the default governor setting. [Note that the default cpufreq governor can still be set via the kernel command line if need be and that choice is not limited, so if anyone really wants to use one of the legacy governors by default, it can be achieved this way.] Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") Reported-by: Julia Lawall <julia.lawall@inria.fr> Cc: 5.8+ <stable@vger.kernel.org> # 5.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* cpufreq: make schedutil the default for arm and arm64Valentin Schneider2020-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | schedutil is already a hard-requirement for EAS, which has lead to making it default on arm (when CONFIG_BIG_LITTLE), see: commit 8fdcca8e254a ("cpufreq: Select schedutil when using big.LITTLE") One thing worth pointing out is that schedutil isn't only relevant for asymmetric CPU capacity systems; for instance, schedutil is the only governor that honours util-clamp performance requests. Another good example of this is x86 switching to using it by default in: commit a00ec3874e7d ("cpufreq: intel_pstate: Select schedutil as the default governor") Arguably it should be made the default for all architectures, but it seems better to wait for them to also gain frequency invariance powers. Make it the default for arm && arm64 for now. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* cpufreq: qoriq: Add platform dependenciesGeert Uytterhoeven2020-05-081-1/+2
| | | | | | | | | | | | 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>
* cpufreq: Select schedutil when using big.LITTLELinus Walleij2020-04-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are using a system with big.LITTLE HMP configuration, we need to use EAS to schedule the system. As can be seen from kernel/sched/topology.c: "EAS can be used on a root domain if it meets all the following conditions: 1. an Energy Model (EM) is available; 2. the SD_ASYM_CPUCAPACITY flag is set in the sched_domain hierarchy. 3. no SMT is detected. 4. the EM complexity is low enough to keep scheduling overheads low; 5. schedutil is driving the frequency of all CPUs of the rd;" This means that at the very least, schedutil needs to be available as a scheduling policy for EAS to work on these systems. Make this explicit by defaulting to the schedutil governor if BIG_LITTLE is selected. Currently users of the TC2 board (like me) has to figure these dependencies out themselves and it is not helpful. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: intel_pstate: Select schedutil as the default governorRafael J. Wysocki2020-03-261-1/+2
| | | | | | | | | | | | Modify cpufreq Kconfig to select schedutil as the default governor if the intel_pstate driver has been selected and SMP support is enabled (because schedutil depends on SMP). Also select schedutil as well as the performance governor from the intel_pstate Kconfig section to ensure the equivalence of the passive and active mode governor configuration options. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2019-05-211-0/+1
| | | | | | | | | | | | | | Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: boost: Remove CONFIG_CPU_FREQ_BOOST_SW Kconfig optionYue Hu2019-04-101-4/+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>
* thermal: cpu_cooling: Require thermal core to be compiled inAmit Kucheria2019-01-291-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CPU cooling driver (cpu_cooling.c) allows the platform's cpufreq driver to register as a cooling device and cool down the platform by throttling the CPU frequency. In order to be able to auto-register a cpufreq driver as a cooling device from the cpufreq core, we need access to code inside cpu_cooling.c which, in turn, accesses code inside thermal core. CPU_FREQ is a bool while THERMAL is tristate. In some configurations (e.g. allmodconfig), CONFIG_THERMAL ends up as a module while CONFIG_CPU_FREQ is compiled in. This leads to following error: drivers/cpufreq/cpufreq.o: In function `cpufreq_offline': cpufreq.c:(.text+0x407c): undefined reference to `cpufreq_cooling_unregister' drivers/cpufreq/cpufreq.o: In function `cpufreq_online': cpufreq.c:(.text+0x70c0): undefined reference to `of_cpufreq_cooling_register' Given that platforms using CPU_THERMAL usually want it compiled-in so it is available early in boot, make CPU_THERMAL depend on THERMAL being compiled-in instead of allowing it to be a module. As a result of this change, get rid of the ugly (!CPU_THERMAL || THERMAL) dependency in all cpufreq drivers using CPU_THERMAL. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: remove at32ap-cpufreqCorentin LABBE2018-02-071-10/+0
| | | | | | | | | Since AVR32 arch was removed, at32ap-cpufreq is useless. Remove this driver. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Add Loongson machine dependenciesJames Hogan2017-11-211-0/+2
| | | | | | | | | | | | | | | | | | | | | The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan <jhogan@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: qoriq: add ARM64 SoCs supportTang Yuantian2017-02-091-1/+1
| | | | | | | | Add ARM64 config to Kconfig to enable CPU frequency feature on NXP ARM64 SoCs. Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCsMarkus Mayer2017-02-091-0/+10
| | | | | | | | | | Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on BMIPS5xxx-based SoCs. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config optionViresh Kumar2017-02-031-8/+0
| | | | | | | | | | | | | | | | This doesn't have any benefit apart from saving a small amount of memory when it is disabled. The ifdef hackery in the code makes it dirty unnecessarily. Clean it up by removing the Kconfig option completely. Few defconfigs are also updated and CONFIG_CPU_FREQ_STAT_DETAILS is replaced with CONFIG_CPU_FREQ_STAT now in them, as users wanted stats to be enabled. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'pm-cpufreq-sched' into pm-cpufreqRafael J. Wysocki2016-10-021-4/+1
|\
| * cpufreq / sched: Pass flags to cpufreq_update_util()Rafael J. Wysocki2016-08-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is useful to know the reason why cpufreq_update_util() has just been called and that can be passed as flags to cpufreq_update_util() and to the ->func() callback in struct update_util_data. However, doing that in addition to passing the util and max arguments they already take would be clumsy, so avoid it. Instead, use the observation that the schedutil governor is part of the scheduler proper, so it can access scheduler data directly. This allows the util and max arguments of cpufreq_update_util() and the ->func() callback in struct update_util_data to be replaced with a flags one, but schedutil has to be modified to follow. Thus make the schedutil governor obtain the CFS utilization information from the scheduler and use the "RT" and "DL" flags instead of the special utilization value of ULONG_MAX to track updates from the RT and DL sched classes. Make it non-modular too to avoid having to export scheduler variables to modules at large. Next, update all of the other users of cpufreq_update_util() and the ->func() callback in struct update_util_data accordingly. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* | cpufreq: dt: Update kconfig descriptionViresh Kumar2016-09-131-1/+1
|/ | | | | | | | | | | | The cpufreq DT driver also supports systems that have multiple clock/voltage domains for CPUs, i.e. multiple policy systems. The description of the Kconfig entry was never updated after the driver was modified to support such systems, fix it. Reported-by: Juri Lelli <Juri.Lelli@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Do not default-yes CPU_FREQ_STATBorislav Petkov2016-08-031-1/+0
| | | | | | | | | | CPU frequency transition statistics are not absolutely required for proper cpufreq operation on the system AFAICT so remove the default-yes setting in Kconfig. Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: stats: Make the stats code non-modularRafael J. Wysocki2016-06-021-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The modularity of cpufreq_stats is quite problematic. First off, the usage of policy notifiers for the initialization and cleanup in the cpufreq_stats module is inherently racy with respect to CPU offline/online and the initialization and cleanup of the cpufreq driver. Second, fast frequency switching (used by the schedutil governor) cannot be enabled if any transition notifiers are registered, so if the cpufreq_stats module (that registers a transition notifier for updating transition statistics) is loaded, the schedutil governor cannot use fast frequency switching. On the other hand, allowing cpufreq_stats to be built as a module doesn't really add much value. Arguably, there's not much reason for that code to be modular at all. For the above reasons, make the cpufreq stats code non-modular, modify the core to invoke functions provided by that code directly and drop the notifiers from it. Make the stats sysfs attributes appear empty if fast frequency switching is enabled as the statistics will not be updated in that case anyway (and returning -EBUSY from those attributes breaks powertop). While at it, clean up Kconfig help for the CPU_FREQ_STAT and CPU_FREQ_STAT_DETAILS options. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* Merge branch 'pm-cpufreq-sched' into pm-cpufreqRafael J. Wysocki2016-05-111-0/+1
|\
| * cpufreq: schedutil: Make default depend on CONFIG_SMPArnd Bergmann2016-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | CPU_FREQ_GOV_SCHEDUTIL gained a dependency on SMP, so now we get a warning if it gets selected by CPU_FREQ_DEFAULT_GOV_SCHEDUTIL without SMP: warning: (CPU_FREQ_DEFAULT_GOV_SCHEDUTIL) selects CPU_FREQ_GOV_SCHEDUTIL which has unmet direct dependencies (CPU_FREQ && SMP) This adds another dependency to avoid the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: bf7cdff19429 (cpufreq: schedutil: Make it depend on CONFIG_SMP) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'pm-cpufreq-sched' into pm-cpufreqRafael J. Wysocki2016-05-091-1/+1
|\|
| * cpufreq: schedutil: Make it depend on CONFIG_SMPRafael J. Wysocki2016-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | Make the schedutil cpufreq governor depend on CONFIG_SMP, because the scheduler-provided utilization numbers used by it are only available with CONFIG_SMP set. Fixes: 9bdcb44e391d (cpufreq: schedutil: New governor based on scheduler utilization data) Reported-by: Steve Muckle <steve.muckle@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: dt: Add generic platform-device creation supportViresh Kumar2016-04-091-0/+10
|/ | | | | | | | | | | | | | | | | | | | | | | Multiple platforms are using the generic cpufreq-dt driver now, and all of them are required to create a platform device with name "cpufreq-dt", in order to get the cpufreq-dt probed. Many of them do it from platform code, others have special drivers just to do that. It would be more sensible to do this at a generic place, where all such platform can mark their entries. This patch adds a separate file to get this device created. Currently the compat list of platforms that we support is empty, and will be filled in as and when we move platforms to use it. It always compiles as part of the kernel and so doesn't need a module-exit operation. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: schedutil: New governor based on scheduler utilization dataRafael J. Wysocki2016-04-021-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c555f3e1 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
* cpufreq: governor: Move abstract gov_attr_set code to seperate fileRafael J. Wysocki2016-04-021-0/+4
| | | | | | | | | | | Move abstract code related to struct gov_attr_set to a separate (new) file so it can be shared with (future) goverernors that won't share more code with "ondemand" and "conservative". No intentional functional changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* Merge branch 'pm-cpufreq'Rafael J. Wysocki2016-03-141-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-cpufreq: (94 commits) intel_pstate: Do not skip samples partially intel_pstate: Remove freq calculation from intel_pstate_calc_busy() intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance() intel_pstate: Optimize calculation for max/min_perf_adj intel_pstate: Remove extra conversions in pid calculation cpufreq: Move scheduler-related code to the sched directory Revert "cpufreq: postfix policy directory with the first CPU in related_cpus" cpufreq: Reduce cpufreq_update_util() overhead a bit cpufreq: Select IRQ_WORK if CPU_FREQ_GOV_COMMON is set cpufreq: Remove 'policy->governor_enabled' cpufreq: Rename __cpufreq_governor() to cpufreq_governor() cpufreq: Relocate handle_update() to kill its declaration cpufreq: governor: Drop unnecessary checks from show() and store() cpufreq: governor: Fix race in dbs_update_util_handler() cpufreq: governor: Make gov_set_update_util() static cpufreq: governor: Narrow down the dbs_data_mutex coverage cpufreq: governor: Make dbs_data_mutex static cpufreq: governor: Relocate definitions of tuners structures cpufreq: governor: Move per-CPU data to the common code cpufreq: governor: Make governor private data per-policy ...
| * cpufreq: Select IRQ_WORK if CPU_FREQ_GOV_COMMON is setRafael J. Wysocki2016-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | Commit 0eb463be3436 (cpufreq: governor: Replace timers with utilization update callbacks) made CPU_FREQ select IRQ_WORK, but that's not necessary, as it is sufficient for IRQ_WORK to be selected by CPU_FREQ_GOV_COMMON, so modify the cpufreq Kconfig to that effect. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
| * cpufreq: governor: Replace timers with utilization update callbacksRafael J. Wysocki2016-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a per-CPU deferrable timer for queuing up governor work items, register a utilization update callback that will be invoked from the scheduler on utilization changes. The sampling rate is still the same as what was used for the deferrable timers and the added irq_work overhead should be offset by the eliminated timers overhead, so in theory the functional impact of this patch should not be significant. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
* | cpufreq: qoriq: allow building as module with THERMAL=mArnd Bergmann2016-03-011-0/+1
|/ | | | | | | | | | | | | | My previous patch to avoid link errors with the qoriq cpufreq driver disallowed all of the broken cases, but also prevented the driver from being built when CONFIG_THERMAL is a module. This changes the dependency to allow the cpufreq driver to also be a module in this case, just not built-in. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 8ae1702a0df5 (cpufreq: qoriq: Register cooling device based on device tree) Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: qoriq: rename the driverTang Yuantian2015-03-181-0/+8
| | | | | | | | | | This driver works on all QorIQ platforms which include ARM-based cores and PPC-based cores. Rename it in order to represent better. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* rcu: Make SRCU optional by using CONFIG_SRCUPranith Kumar2015-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. If we do not select CONFIG_SRCU, srcu.o will not be compiled at all. text data bss dec hex filename 2007 0 0 2007 7d7 kernel/rcu/srcu.o Size of arch/powerpc/boot/zImage changes from text data bss dec hex filename 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after so the savings are about ~2000 bytes. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com> CC: Josh Triplett <josh@joshtriplett.org> CC: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> [ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
* cpufreq: Kconfig: Remove architecture specific menu entriesViresh Kumar2014-11-181-31/+19
| | | | | | | | | | | | | | | | | | | | CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Loongson1: Add cpufreq driver for Loongson1BKelvin Cheung2014-11-061-0/+10
| | | | | | | | | This patch adds cpufreq driver for Loongson1B which is capable of changing the CPU frequency dynamically. Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: allow powersave governor as the default without expert modeJames Geboski2014-11-061-1/+0
| | | | | | | | | | | | | | | | | | | | The intel_pstate driver only supports the performance and the powersave governors. With the performance governor ensuring the highest possible performance settings, userspace tools fail to make any lasting changes. In order to allow userspace tools to make modifications to the settings, the powersave governor must be in use. This makes having the powersave governor as the default convenient for systems where the intel_pstate driver is being employed. Having to enable expert mode in the kernel configuration is just a headache for such a trivial task. This patch applies to all kernel versions 2.6.38 or greater after the migration from CONFIG_EMBEDDED to CONFIG_EXPERT (6a108a14fa35). Most importantly, this applies to kernel versions 3.9 or greater when the intel_pstate driver was introduced. Signed-off-by: James Geboski <jgeboski@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'Viresh Kumar2014-10-031-4/+4
| | | | | | | | | | | | | | | The naming convention of this driver was always under the scanner, people complained that it should have a more generic name than cpu0, as it manages all CPUs that are sharing clock lines. Also, in future it will be modified to support any number of clusters with separate clock/voltage lines. Lets rename it to 'cpufreq_dt' from 'cpufreq_cpu0'. Tested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependencyArnd Bergmann2014-06-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") was a little too quick in completely removing the dependency on the THERMAL driver. The problem is that while there are inline wrappers to turn the thermal API calls into empty functions, those do not help if the cpu-thermal driver is a loadable module and cpufreq-cpu0 is builtin. Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu code is built into the thermal module or not, we have to use a dependency on the thermal driver itself. However, if CPU_THERMAL is disabled, we don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL' construct. Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATORViresh Kumar2014-06-101-1/+1
| | | | | | | | | | | | | | | | | cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't depend on it as there are dummy calls provided by thermal layer when CONFIG_THERMAL=n. And when these calls fail, the driver is still usable. Similar explanation is valid for regulators as well. We do have dummy calls available for regulator APIs and the driver can work even when those calls fail. So, we don't really need to mention thermal and regulators as a dependency for cpufreq-cpu0 in Kconfig as platforms without support for thermal/regulator can also use this driver. Remove this dependency. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-22 21:43:08 +0000