linux.git/drivers/cpufreq/Kconfig, branch v3.19

cpufreq: Kconfig: Remove architecture specific menu entries

2014-11-18T01:47:42+00:00

CPUFreq driver's Kconfig entries are added in Kconfig. 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 
Suggested-by: Scott Wood 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Loongson1: Add cpufreq driver for Loongson1B

2014-11-06T00:23:44+00:00

This patch adds cpufreq driver for Loongson1B which
is capable of changing the CPU frequency dynamically.

Signed-off-by: Kelvin Cheung 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: allow powersave governor as the default without expert mode

2014-11-05T23:44:28+00:00

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

cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'

2014-10-03T13:37:54+00:00

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

cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency

2014-06-16T20:33:38+00:00

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

cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR

2014-06-10T20:52:35+00:00

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

cpufreq: enable ARM drivers on arm64

2014-02-28T15:03:17+00:00

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 
Acked-by: Viresh Kumar 
Signed-off-by: Mark Brown 
Signed-off-by: Catalin Marinas

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux

2014-01-25T01:13:49+00:00

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
  ...

cpufreq / boost: Kconfig: Support for software-managed BOOST

2014-01-17T01:00:45+00:00

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 
Signed-off-by: Myungjoo Ham 
Acked-by: Viresh Kumar 
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki

cpufreq: Select PM_OPP rather than depending on it

2013-12-22T21:03:49+00:00

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