kernel/drivers/cpufreq/Kconfig, branch linux-5.1.y

thermal: cpu_cooling: Require thermal core to be compiled in

2019-01-29T10:46:31Z

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 Signed-off-by: Amit Kucheria Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: remove at32ap-cpufreq

2018-02-07T10:44:23Z

Since AVR32 arch was removed, at32ap-cpufreq is useless. Remove this driver. Signed-off-by: Corentin Labbe Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Add Loongson machine dependencies

2017-11-21T22:58:54Z

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 Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: qoriq: add ARM64 SoCs support

2017-02-09T13:33:01Z

Add ARM64 config to Kconfig to enable CPU frequency feature on NXP ARM64 SoCs. Signed-off-by: Tang Yuantian Signed-off-by: Rafael J. Wysocki

cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs

2017-02-09T00:22:44Z

Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on BMIPS5xxx-based SoCs. Signed-off-by: Markus Mayer Acked-by: Florian Fainelli Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config option

2017-02-03T22:59:39Z

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 Acked-by: Gregory CLEMENT Reviewed-by: Chanwoo Choi Acked-by: Krzysztof Kozlowski Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-cpufreq-sched' into pm-cpufreq

2016-10-01T23:42:33Z

cpufreq: dt: Update kconfig description

2016-09-13T00:39:12Z

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 Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq / sched: Pass flags to cpufreq_update_util()

2016-08-16T20:14:55Z

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 Signed-off-by: Rafael J. Wysocki Acked-by: Peter Zijlstra (Intel) Acked-by: Viresh Kumar

cpufreq: Do not default-yes CPU_FREQ_STAT

2016-08-02T23:34:11Z

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 Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki