Commit Graph

72 Commits

Author SHA1 Message Date
Randy Dunlap 9d822ccf33 cpufreq: loongson2: fix Kconfig "its" grammar
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>
2022-07-25 20:34:56 +02:00
Alexander Monakov 733dda9cc8 cpufreq: Kconfig: fix documentation links
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: 2a0e492798 ("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>
2021-04-21 19:00:42 +02:00
Rafael J. Wysocki db865272d9 cpufreq: Avoid configuring old governors as default with intel_pstate
Commit 33aa46f252 ("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: 33aa46f252 ("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>
2020-10-27 18:45:34 +01:00
Valentin Schneider f259eab3ea cpufreq: make schedutil the default for arm and arm64
schedutil is already a hard-requirement for EAS, which has lead to making
it default on arm (when CONFIG_BIG_LITTLE), see:

  commit 8fdcca8e25 ("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 a00ec3874e ("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>
2020-07-30 11:40:29 +05:30
Geert Uytterhoeven 1f1755af4f cpufreq: qoriq: Add platform dependencies
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-08 10:53:10 +05:30
Linus Walleij 8fdcca8e25 cpufreq: Select schedutil when using big.LITTLE
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>
2020-04-03 11:20:06 +02:00
Rafael J. Wysocki a00ec3874e cpufreq: intel_pstate: Select schedutil as the default governor
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>
2020-03-26 20:32:49 +01:00
Thomas Gleixner ec8f24b7fa treewide: Add SPDX license identifier - Makefile/Kconfig
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>
2019-05-21 10:50:46 +02:00
Yue Hu 9df1e2c60d cpufreq: boost: Remove CONFIG_CPU_FREQ_BOOST_SW Kconfig option
Commit 2fb4719b25 ("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>
2019-04-10 10:00:50 +02:00
Amit Kucheria afa1f2ab43 thermal: cpu_cooling: Require thermal core to be compiled in
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>
2019-01-29 11:46:31 +01:00
Corentin LABBE 3d70671667 cpufreq: remove at32ap-cpufreq
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>
2018-02-07 11:44:23 +01:00
James Hogan 0d307935fe cpufreq: Add Loongson machine dependencies
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>
2017-11-21 23:58:54 +01:00
Tang Yuantian 5026ac2314 cpufreq: qoriq: add ARM64 SoCs support
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>
2017-02-09 14:33:01 +01:00
Markus Mayer cdb56cbfd7 cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs
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>
2017-02-09 01:22:44 +01:00
Viresh Kumar 801e0f378f cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config option
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>
2017-02-03 23:59:39 +01:00
Rafael J. Wysocki b6e2511782 Merge branch 'pm-cpufreq-sched' into pm-cpufreq 2016-10-02 01:42:33 +02:00
Viresh Kumar 33cc4fc1b2 cpufreq: dt: Update kconfig description
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>
2016-09-13 02:39:12 +02:00
Rafael J. Wysocki 58919e83c8 cpufreq / sched: Pass flags to cpufreq_update_util()
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>
2016-08-16 22:14:55 +02:00
Borislav Petkov 79ad70de53 cpufreq: Do not default-yes CPU_FREQ_STAT
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>
2016-08-03 01:34:11 +02:00
Rafael J. Wysocki 1aefc75b24 cpufreq: stats: Make the stats code non-modular
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>
2016-06-02 23:24:41 +02:00
Rafael J. Wysocki c29af6f1a4 Merge branch 'pm-cpufreq-sched' into pm-cpufreq 2016-05-11 22:48:20 +02:00
Arnd Bergmann cfe9492fdf cpufreq: schedutil: Make default depend on CONFIG_SMP
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: bf7cdff194 (cpufreq: schedutil: Make it depend on CONFIG_SMP)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-11 22:47:44 +02:00
Rafael J. Wysocki d87de8f38a Merge branch 'pm-cpufreq-sched' into pm-cpufreq 2016-05-09 16:00:10 +02:00
Rafael J. Wysocki bf7cdff194 cpufreq: schedutil: Make it depend on CONFIG_SMP
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: 9bdcb44e39 (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>
2016-05-06 22:33:33 +02:00
Viresh Kumar f56aad1d98 cpufreq: dt: Add generic platform-device creation support
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>
2016-04-09 01:18:42 +02:00
Rafael J. Wysocki 9bdcb44e39 cpufreq: schedutil: New governor based on scheduler utilization data
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 34e2c555f3 (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>
2016-04-02 01:09:12 +02:00
Rafael J. Wysocki 2d0c58ad60 cpufreq: governor: Move abstract gov_attr_set code to seperate file
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>
2016-04-02 01:09:01 +02:00
Rafael J. Wysocki 4ed3900427 Merge branch 'pm-cpufreq'
* 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
  ...
2016-03-14 14:22:03 +01:00
Rafael J. Wysocki e6f036571e cpufreq: Select IRQ_WORK if CPU_FREQ_GOV_COMMON is set
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>
2016-03-09 15:01:37 +01:00
Rafael J. Wysocki 9be4fd2c77 cpufreq: governor: Replace timers with utilization update callbacks
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>
2016-03-09 14:40:53 +01:00
Arnd Bergmann ddd30ef474 cpufreq: qoriq: allow building as module with THERMAL=m
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: 8ae1702a0d (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>
2016-03-01 02:43:05 +01:00
Tang Yuantian 2f249358ee cpufreq: qoriq: rename the driver
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>
2015-03-18 22:35:16 +01:00
Pranith Kumar 83fe27ea53 rcu: Make SRCU optional by using CONFIG_SRCU
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. ]
2015-01-06 11:04:29 -08:00
Viresh Kumar f41f4815f8 cpufreq: Kconfig: Remove architecture specific menu entries
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>
2014-11-18 02:47:42 +01:00
Kelvin Cheung a0a22cf144 cpufreq: Loongson1: Add cpufreq driver for Loongson1B
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>
2014-11-06 01:23:44 +01:00
James Geboski b3a826c05b cpufreq: allow powersave governor as the default without expert mode
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 (6a108a14fa). 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>
2014-11-06 00:44:28 +01:00
Viresh Kumar bbcf071969 cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'
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>
2014-10-03 15:37:54 +02:00
Arnd Bergmann 217886d3f3 cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency
5fbfbcd3e8 ("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: 5fbfbcd3e8 ("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>
2014-06-16 22:33:38 +02:00
Viresh Kumar 5fbfbcd3e8 cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR
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>
2014-06-10 22:52:35 +02:00
Rob Herring addea9ef05 cpufreq: enable ARM drivers on arm64
Enable cpufreq and power kconfig menus on arm64 along with arm cpufreq
drivers. The power menu is needed for OPP support. At least on Calxeda
systems, the same cpufreq driver is used for arm and arm64 based
systems.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-02-28 15:03:17 +00:00
Linus Torvalds 91466574be Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal management updates from Zhang Rui:
 "This time, the biggest change is the work of representing hardware
  thermal properties in device tree infrastructure.

  This work includes the introduction of a device tree bindings for
  describing the hardware thermal behavior and limits, and also a parser
  to read and interpret the data, and build thermal zones and thermal
  binding parameters.  It also contains three examples on how to use the
  new representation on sensor devices, using three different drivers to
  accomplish it.  One driver is in thermal subsystem, the TI SoC
  thermal, and the other two drivers are in hwmon subsystem.

  Actually, this would be the first step of the complete work because we
  still need to check other potential drivers to be converted and then
  validate the proposed API.  But the reason why I include it in this
  pull request is that, first, this change does not hurt any others
  without using this approach, second, the principle and concept of this
  change would not break after converting the remaining drivers.  BTW,
  as you can see, there are several points in this change that do not
  belong to thermal subsystem.  Because it has been suggested by Guenter
  R that in such cases, it is recommended to send the complete series
  via one single subsystem.

  Specifics:

   - representing hardware thermal properties in device tree
     infrastructure

   - fix a regression that the imx thermal driver breaks system suspend.

   - introduce ACPI INT3403 thermal driver to retrieve temperature data
     from the INT3403 ACPI device object present on some systems.

   - introduce debug statement for thermal core and step_wise governor.

   - assorted fixes and cleanups for thermal core, cpu cooling, exynos
     thrmal, intel powerclamp and imx thermal driver"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (34 commits)
  thermal: remove const flag from .ops of imx thermal
  Thermal: update thermal zone device after setting emul_temp
  intel_powerclamp: Fix cstate counter detection.
  thermal: imx: add necessary clk operation
  Thermal cpu cooling: return error if no valid cpu frequency entry
  thermal: fix cpu_cooling max_level behavior
  thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST
  thermal: debug: add debug statement for core and step_wise
  thermal: imx_thermal: add module device table
  drivers: thermal: Mark function as static in x86_pkg_temp_thermal.c
  thermal:samsung: fix compilation warning
  thermal: imx: correct suspend/resume flow
  thermal: exynos: fix error return code
  Thermal: ACPI INT3403 thermal driver
  MAINTAINERS: add thermal bindings entry in thermal domain
  arm: dts: make OMAP4460 bandgap node to belong to OCP
  arm: dts: make OMAP443x bandgap node to belong to OCP
  arm: dts: add cooling properties on omap5 cpu node
  arm: dts: add omap5 thermal data
  arm: dts: add omap5 CORE thermal data
  ...
2014-01-24 17:13:49 -08:00
Lukasz Majewski 2fb4719b25 cpufreq / boost: Kconfig: Support for software-managed BOOST
Add CONFIG_CPU_FREQ_BOOST_SW Kconfig option such that software-managed
boost is enabled only after selecting "EXYNOS Frequency Overclocking -
Software".  It also depends on the thermal subsystem to be compiled in,
which is necessary for disabling boost and cooling down the device when
overheating is detected.

Software-managed boost _MUST_ _NOT_ be enabled without thermal subsystem
with properly defined overheating temperature thresholds.

This option doesn't affect the x86's hardware-driven boost support
in the acpi-cpufreq driver.

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>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 02:00:45 +01:00
Mark Brown 109df086e0 cpufreq: Select PM_OPP rather than depending on it
PM_OPP is a helper library used by several of the existing cpufreq drivers.
Some of the drivers select this symbol while others depend on it and rely
on the architecture to enable it. Make this behaviour more consistent and
obvious by having all the drivers select the symbol. This will also allow
better build coverage of the affected drivers.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-22 22:03:49 +01:00
Eduardo Valentin 77cff5926a cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.

In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
2013-12-04 09:34:24 -04:00
Viresh Kumar 3bc28ab6da cpufreq: remove CONFIG_CPU_FREQ_TABLE
CONFIG_CPU_FREQ_TABLE will be always enabled when cpufreq framework is used, as
cpufreq core depends on it. So, we don't need this CONFIG option anymore as it
is not configurable. Remove CONFIG_CPU_FREQ_TABLE and update its users.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16 00:50:33 +02:00
Viresh Kumar 70e9e77833 cpufreq: create cpufreq_generic_init() routine
Many CPUFreq drivers for SMP system (where all cores share same clock lines), do
similar stuff in their ->init() part.

This patch creates a generic routine in cpufreq core which can be used by these
so that we can remove some redundant code.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16 00:50:33 +02:00
Alexander Shiyan 559f56c70f cpufreq: Fix incorrect dependecies for ARM SA11xx drivers
Kconfig dependecies for ARM SA11xx drivers are incorrect, so fix
them.

[rjw: Changelog]
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-12 14:04:16 +02:00
Viresh Kumar 764295ae67 cpufreq: sparc: move cpufreq driver to drivers/cpufreq
This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 13:19:26 +02:00
Viresh Kumar 7258267e56 cpufreq: sh: move cpufreq driver to drivers/cpufreq
This patch moves cpufreq driver of SUPERH architecture to drivers/cpufreq.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 13:19:25 +02:00
Viresh Kumar 7a9989356b cpufreq: mips: move cpufreq driver to drivers/cpufreq
This patch moves cpufreq driver of MIPS architecture to drivers/cpufreq.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-10 13:19:25 +02:00