Commit Graph

131 Commits

Author SHA1 Message Date
Viresh Kumar f75d2accca Merge branch 'cpufreq/qcom-updates' into cpufreq/arm/linux-next 2019-09-03 07:55:22 +05:30
Sricharan R 7d12709544 cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
The kryo cpufreq driver reads the nvmem cell and uses that data to
populate the opps. There are other qcom cpufreq socs like krait which
does similar thing. Except for the interpretation of the read data,
rest of the driver is same for both the cases. So pull the common things
out for reuse.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
[niklas.cassel@linaro.org: split dt-binding into a separate patch and
do not rename the compatible string. Update MAINTAINERS file.]
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
Reviewed-by: Ilia Lin <ilia.lin@kernel.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-09-03 07:55:00 +05:30
Yangtao Li f328584f7b cpufreq: Add sun50i nvmem based CPU scaling driver
For some SoCs, the CPU frequency subset and voltage value of each OPP
varies based on the silicon variant in use. The sun50i-cpufreq-nvmem
driver reads the efuse value from the SoC to provide the OPP framework
with required information.

Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-07-22 11:10:51 +05:30
Rafael J. Wysocki fba7402017 Merge branch 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull ARM cpufreq changes for v5.3 from Viresh Kumar:

"This pull request contains:

 - Minor fixes for brcmstb driver (Florian).
 - New imx-cpufreq driver, its bindings and code around it (Leonard).
 - New Raspberry Pi driver (Nicolas).
 - Minor fix for s5pv210 driver (Pawel).
 - Minor cleanup for armada driver (YueHaibing)."

* 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
  cpufreq: s5pv210: Don't flood kernel log after cpufreq change
  cpufreq: add driver for Raspberry Pi
  cpufreq: Switch imx7d to imx-cpufreq-dt for speed grading
  cpufreq: imx-cpufreq-dt: Remove global platform match list
  cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency
  cpufreq: brcmstb-avs-cpufreq: Fix initial command check
  cpufreq: armada-37xx: Remove set but not used variable 'freq'
  cpufreq: imx-cpufreq-dt: Fix no OPPs available on unfused parts
  dt-bindings: imx-cpufreq-dt: Document opp-supported-hw usage
  cpufreq: Add imx-cpufreq-dt driver
2019-06-26 10:51:27 +02:00
Nicolas Saenz Julienne d3df18a97e cpufreq: add driver for Raspberry Pi
Raspberry Pi's firmware offers and interface though which update it's
performance requirements. It allows us to request for specific runtime
frequencies, which the firmware might or might not respect, depending on
the firmware configuration and thermals.

As the maximum and minimum frequencies are configurable in the firmware
there is no way to know in advance their values. So the Raspberry Pi
cpufreq driver queries them, builds an opp frequency table to then
launch cpufreq-dt.

Also, as the firmware interface might be configured as a module, making
the cpu clock unavailable during init, this implements a full fledged
driver, as opposed to most drivers registering cpufreq-dt, which only
make use of an init routine.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-06-13 08:58:22 +05:30
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
Leonard Crestez 4d28ba1d62 cpufreq: Add imx-cpufreq-dt driver
Right now in upstream imx8m cpufreq support just lists a common subset
of OPPs because the higher ones should only be attempted after checking
speed grading in fuses.

Add a small driver which checks speed grading from nvmem cells before
registering cpufreq-dt.

This driver allows unlocking all frequencies for imx8mm and imx8mq and
could be applied to other chips like imx7d

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-05-20 12:47:48 +05:30
Linus Torvalds ef8006846a Power management updates for 5.1-rc1
- Update the PM-runtime framework to use ktime instead of
    jiffies for accounting (Thara Gopinath, Vincent Guittot).
 
  - Optimize the autosuspend code in the PM-runtime framework
    somewhat (Ladislav Michl).
 
  - Add a PM core flag to mark devices that don't need any form of
    power management (Sudeep Holla).
 
  - Introduce driver API documentation for cpuidle and add a new
    cpuidle governor for tickless systems (Rafael Wysocki).
 
  - Add Jacobsville support to the intel_idle driver (Zhang Rui).
 
  - Clean up a cpuidle core header file and the cpuidle-dt and ACPI
    processor-idle drivers (Yangtao Li, Joseph Lo, Yazen Ghannam).
 
  - Add new cpufreq driver for Armada 8K (Gregory Clement).
 
  - Fix and clean up cpufreq core (Rafael Wysocki, Viresh Kumar,
    Amit Kucheria).
 
  - Add support for light-weight tear-down and bring-up of CPUs to the
    cpufreq core and use it in the cpufreq-dt driver (Viresh Kumar).
 
  - Fix cpu_cooling Kconfig dependencies, add support for CPU cooling
    auto-registration to the cpufreq core and use it in multiple
    cpufreq drivers (Amit Kucheria).
 
  - Fix some minor issues and do some cleanups in the davinci,
    e_powersaver, ap806, s5pv210, qcom and kryo cpufreq drivers
    (Bartosz Golaszewski, Gustavo Silva, Julia Lawall, Paweł Chmiel,
    Taniya Das, Viresh Kumar).
 
  - Add a Hisilicon CPPC quirk to the cppc_cpufreq driver (Xiongfeng
    Wang).
 
  - Clean up the intel_pstate and acpi-cpufreq drivers (Erwan Velu,
    Rafael Wysocki).
 
  - Clean up multiple cpufreq drivers (Yangtao Li).
 
  - Update cpufreq-related MAINTAINERS entries (Baruch Siach, Lukas
    Bulwahn).
 
  - Add support for exposing the Energy Model via debugfs and make
    multiple cpufreq drivers register an Energy Model to support
    energy-aware scheduling (Quentin Perret, Dietmar Eggemann,
    Matthias Kaehlcke).
 
  - Add Ice Lake mobile and Jacobsville support to the Intel RAPL
    power-capping driver (Gayatri Kammela, Zhang Rui).
 
  - Add a power estimation helper to the operating performance points
    (OPP) framework and clean up a core function in it (Quentin Perret,
    Viresh Kumar).
 
  - Make minor improvements in the generic power domains (genpd), OPP
    and system suspend frameworks and in the PM core (Aditya Pakki,
    Douglas Anderson, Greg Kroah-Hartman, Rafael Wysocki, Yangtao Li).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJcfSGlAAoJEILEb/54YlRxikwP/1rQ9+HqDmDUvO2QeYREGO/m
 R4kK+iUQW7O4ZJzsSvoGyuKCl7c2ANPlJWmbsEZKbevpKZ4XuUcv/CJDqKD1izV7
 hfsQyum34ePSCUEMf6CpMAGAkdmK//NVysHiLXZ4j1hhzi6gA6Cm50qyNZ8xX6kF
 Ri6zYG5x7nhn/o/l569FDe+K5W/LDDaZUmvr858pPsrZZR5c4p3ylq+HBrZt0FPQ
 70D+u7RcT5v3DQLTghNrgHHiOJ0/DQM43I7aZvkKM3JA8BCDou/Nvq+gH0C0YUP0
 QE+oFK9C8CBPEz9N9cSMTb0+S78GQNB0GntJPDN3QQFCHRe6EYKUtu6CvllIE1v9
 5pFfagXGVi9UmShu80v+qGGUILVK1ZJ5fjSyxx4UcneTsarNJZg7Y7d72mrX+0zi
 J3KodcqQi295jNq9P55K/9XtAiRdpRR6bQzXBtrprpw8PA94yqBHPpxbD32Wl05/
 U2+ss/SNyMAzhsP9kqzxSxPBlTFek/ArxZm0Uk4kHt75gkl09CG64r+6OG8gLtwD
 Skkr02AeYvx6fx0kFnKIS4sc2c2/8xW3FUtHlv+TDPvuzCEaL0ooqsWgt7rcwlmg
 Xz5ufXbEIiVSlLlH/YGZxbgy+WfIzYA5WMpYrA1Givn8s5jI9Sm+ROD2qhOKA2n4
 aekEDkum/bxVVeykZaXy
 =TSKG
 -----END PGP SIGNATURE-----

Merge tag 'pm-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management updates from Rafael Wysocki:
 "These are PM-runtime framework changes to use ktime instead of jiffies
  for accounting, new PM core flag to mark devices that don't need any
  form of power management, cpuidle updates including driver API
  documentation and a new governor, cpufreq updates including a new
  driver for Armada 8K, thermal cleanups and more, some energy-aware
  scheduling (EAS) enabling changes, new chips support in the intel_idle
  and RAPL drivers and assorted cleanups in some other places.

  Specifics:

   - Update the PM-runtime framework to use ktime instead of jiffies for
     accounting (Thara Gopinath, Vincent Guittot)

   - Optimize the autosuspend code in the PM-runtime framework somewhat
     (Ladislav Michl)

   - Add a PM core flag to mark devices that don't need any form of
     power management (Sudeep Holla)

   - Introduce driver API documentation for cpuidle and add a new
     cpuidle governor for tickless systems (Rafael Wysocki)

   - Add Jacobsville support to the intel_idle driver (Zhang Rui)

   - Clean up a cpuidle core header file and the cpuidle-dt and ACPI
     processor-idle drivers (Yangtao Li, Joseph Lo, Yazen Ghannam)

   - Add new cpufreq driver for Armada 8K (Gregory Clement)

   - Fix and clean up cpufreq core (Rafael Wysocki, Viresh Kumar, Amit
     Kucheria)

   - Add support for light-weight tear-down and bring-up of CPUs to the
     cpufreq core and use it in the cpufreq-dt driver (Viresh Kumar)

   - Fix cpu_cooling Kconfig dependencies, add support for CPU cooling
     auto-registration to the cpufreq core and use it in multiple
     cpufreq drivers (Amit Kucheria)

   - Fix some minor issues and do some cleanups in the davinci,
     e_powersaver, ap806, s5pv210, qcom and kryo cpufreq drivers
     (Bartosz Golaszewski, Gustavo Silva, Julia Lawall, Paweł Chmiel,
     Taniya Das, Viresh Kumar)

   - Add a Hisilicon CPPC quirk to the cppc_cpufreq driver (Xiongfeng
     Wang)

   - Clean up the intel_pstate and acpi-cpufreq drivers (Erwan Velu,
     Rafael Wysocki)

   - Clean up multiple cpufreq drivers (Yangtao Li)

   - Update cpufreq-related MAINTAINERS entries (Baruch Siach, Lukas
     Bulwahn)

   - Add support for exposing the Energy Model via debugfs and make
     multiple cpufreq drivers register an Energy Model to support
     energy-aware scheduling (Quentin Perret, Dietmar Eggemann, Matthias
     Kaehlcke)

   - Add Ice Lake mobile and Jacobsville support to the Intel RAPL
     power-capping driver (Gayatri Kammela, Zhang Rui)

   - Add a power estimation helper to the operating performance points
     (OPP) framework and clean up a core function in it (Quentin Perret,
     Viresh Kumar)

   - Make minor improvements in the generic power domains (genpd), OPP
     and system suspend frameworks and in the PM core (Aditya Pakki,
     Douglas Anderson, Greg Kroah-Hartman, Rafael Wysocki, Yangtao Li)"

* tag 'pm-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (80 commits)
  cpufreq: kryo: Release OPP tables on module removal
  cpufreq: ap806: add missing of_node_put after of_device_is_available
  cpufreq: acpi-cpufreq: Report if CPU doesn't support boost technologies
  cpufreq: Pass updated policy to driver ->setpolicy() callback
  cpufreq: Fix two debug messages in cpufreq_set_policy()
  cpufreq: Reorder and simplify cpufreq_update_policy()
  cpufreq: Add kerneldoc comments for two core functions
  PM / core: Add support to skip power management in device/driver model
  cpufreq: intel_pstate: Rework iowait boosting to be less aggressive
  cpufreq: intel_pstate: Eliminate intel_pstate_get_base_pstate()
  cpufreq: intel_pstate: Avoid redundant initialization of local vars
  powercap/intel_rapl: add Ice Lake mobile
  ACPI / processor: Set P_LVL{2,3} idle state descriptions
  cpufreq / cppc: Work around for Hisilicon CPPC cpufreq
  ACPI / CPPC: Add a helper to get desired performance
  cpufreq: davinci: move configuration to include/linux/platform_data
  cpufreq: speedstep: convert BUG() to BUG_ON()
  cpufreq: powernv: fix missing check of return value in init_powernv_pstates()
  cpufreq: longhaul: remove unneeded semicolon
  cpufreq: pcc-cpufreq: remove unneeded semicolon
  ..
2019-03-06 12:59:46 -08:00
Rafael J. Wysocki b53c7348ca Merge branch 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm into pm-cpufreq
Pull ARM cpufreq driver updates for v5.1 from Viresh Kumar:

"This pull request contains following changes:

 - New Armada 8k cpufreq driver (Gregory CLEMENT).
 - qcom driver cleanups (Amit Kucheria, Taniya Das, Yangtao Li).
 - s5pv210 driver cleanup (Paweł Chmiel).
 - tegra driver cleanup (Yangtao Li).
 - Minor update to MAINTAINERS file (Baruch Siach)."

* 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
  cpufreq: qcom-hw: Register an Energy Model
  cpufreq: qcom: Read voltage LUT and populate OPP
  cpufreq: qcom-hw: Move to device_initcall
  cpufreq: tegra124: add missing of_node_put()
  cpufreq: qcom-kryo: make some variables static
  MAINTAINERS: Update the active pm tree for ARM
  cpufreq: ap806: add cpufreq driver for Armada 8K
  MAINTAINERS: add new entries for Armada 8K cpufreq driver
  cpufreq: s5pv210: Defer probe if getting regulators fail
  MAINTAINERS: use common indentation
  PM / OPP: Introduce a power estimation helper
  PM / OPP: Remove unused parameter of _generic_set_opp_clk_only()
2019-02-13 12:27:23 +01:00
Gregory CLEMENT f525a67053 cpufreq: ap806: add cpufreq driver for Armada 8K
Add cpufreq driver for Marvell AP-806 found on Aramda 8K.
The AP-806 has DFS (Dynamic Frequency Scaling) with coupled
clock domain for two clusters, so this driver will directly
use generic cpufreq-dt driver as backend.

Based on the work of Omri Itach <omrii@marvell.com>.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-07 10:01:51 +05:30
Joseph Lo 9f5ed5fe60 cpufreq: tegra124: do not handle the CPU rail
The Tegra124 cpufreq driver has no information to handle the Vdd-CPU
rail. So this driver shouldn't handle for the CPU clock switching from
DFLL to other PLL clocks. It was designed to work on DFLL clock only,
which handle the frequency/voltage scaling in the background.

This patch removes the driver dependency of the CPU rail, as well as not
allow it to be built as a module and remove the removal function. So it
can keep working on DFLL clock.

Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-02-06 14:30:11 +01: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
Taniya Das 2849dd8bc7 cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.

Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-18 23:43:09 +01:00
Sudeep Holla f174e49e49 cpufreq: remove unused arm_big_little_dt driver
Most of the ARM platforms used cpufreq-dt driver irrespective of
whether it's big-little(HMP) or SMP system. This arm_big_little_dt is
not used actively at all.

So let's remove the driver, so that it need not be maintained.

Signed-off-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>
2018-10-25 18:39:02 +02:00
Sudeep Holla a7314405d8 cpufreq: drop ARM_BIG_LITTLE_CPUFREQ support for ARM64
ARM_BIG_LITTLE_CPUFREQ depends on topology_physical_package_id to get
the cluster id which inturn provides the information on related cpus
in the same performance domain.

ARM64 core doesn't provide the cluster information as it's not
architecturally defined. There are no users of this driver in ARM64
after the one and only user(SCPI) moved away. So let's ban the usage
of this driver for ARM64.

Signed-off-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>
2018-10-25 18:39:02 +02:00
Krzysztof Kozlowski a443c1fc10 cpufreq: exynos: Remove support for Exynos5440
The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Rob Herring <robh@kernel.org>
2018-07-17 19:55:51 +02:00
Arnd Bergmann ac28927659 cpufreq: kryo: allow building as a loadable module
Building the kryo cpufreq driver while QCOM_SMEM is a loadable module
results in a link error:

drivers/cpufreq/qcom-cpufreq-kryo.o: In function `qcom_cpufreq_kryo_probe':
qcom-cpufreq-kryo.c:(.text+0xbc): undefined reference to `qcom_smem_get'

The problem is that Kconfig ignores interprets the dependency as met
when the dependent symbol is a 'bool' one. By making it 'tristate',
it will be forced to be a module here, which builds successfully.

Fixes: 46e2856b8e (cpufreq: Add Kryo CPU scaling driver)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-06 08:29:29 +02:00
Ilia Lin 46e2856b8e cpufreq: Add Kryo CPU scaling driver
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.

Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-30 12:53:11 +02:00
Dmitry Osipenko 7732c9e0db cpufreq: tegra20: Allow cpufreq driver to be built as loadable module
Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to
be built as a non-builtin kernel module.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-21 13:44:24 +02:00
Miquel Raynal 0cf442c6bc cpufreq: armada-37xx: driver relies on cpufreq-dt
Armada-37xx driver registers a cpufreq-dt driver. Not having
CONFIG_CPUFREQ_DT selected leads to a silent abort during the probe.
Prevent that situation by having the former depending on the latter.

Fixes: 92ce45fb87 (cpufreq: Add DVFS support for Armada 37xx)
Cc: 4.16+ <stable@vger.kernel.org> # 4.16+
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-14 22:25:56 +02:00
Markus Mayer ee53a65dc7 cpufreq: brcmstb-avs-cpufreq: remove development debug support
This debug code was helpful while developing the driver, but it isn't
being used for anything anymore.

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-24 11:34:57 +02:00
Linus Torvalds 38c23685b2 ARM: SoC driver updates for 4.17
The main addition this time around is the new ARM "SCMI" framework,
 which is the latest in a series of standards coming from ARM to do power
 management in a platform independent way. This has been through many
 review cycles, and it relies on a rather interesting way of using the
 mailbox subsystem, but in the end I agreed that Sudeep's version was
 the best we could do after all.
 
 Other changes include:
 
 - the ARM CCN driver is moved out of drivers/bus into drivers/perf,
   which makes more sense. Similarly, the performance monitoring
   portion of the CCI driver are moved the same way and cleaned up
   a little more.
 
 - a series of updates to the SCPI framework
 
 - support for the Mediatek mt7623a SoC in drivers/soc
 
 - support for additional NVIDIA Tegra hardware in drivers/soc
 
 - a new reset driver for Socionext Uniphier
 
 - lesser bug fixes in drivers/soc, drivers/tee, drivers/memory, and
   drivers/firmware and drivers/reset across platforms
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJaxiNzAAoJEGCrR//JCVInYhYP/2kPhc5t/kszA1bcklcbO9dY
 eX37Ra/RR4yQ5yeQZVIZ4UkUovxk9PmG2tM4K5oJaTDsz5pPEgavVOOr3sbfj6vb
 4O9auTeysEQlHcbVdNFum0YS2gUY2YD7D12DTRorotLxCqod184ccWXq0XGfIWaY
 l3YRrcL/lPlqmyS3z/GNx9oNygOMUzEfXfIQYICyzHuYiLBUGnkKC1vIb+Hx1TDq
 Cxk++AUqH13Mss24O2A2QQh+oBHj2BybDLLqwcC5PSpsUbFrVCfzG54l43mig32T
 NOxV0Qnml2wAtU4H0QcgtSgwRimHD0YOiX8ssquvDDiqTqM5G+llSTGkEbYe+AUW
 4GIZYoBOwGkfEXS+tyymHe9yfc5h1OLYAeFU1jRm723c7phanuu67rPn35YC8UMK
 zSql10JpkAGNzMikrxxb6wnis951w2UFlzhgZQ6ItA/nRq3l+oEQA0Qiljv965nz
 DVLsD5+gdhK6GBctkzlsD5HFn6GjM8JilnsOVPHD765nKnVBSxKiXRLV228XVug2
 rChF1FhQqLnM54jCMqHZX5fS9SbSgtYswHqIXpVw6GmJkqq/Ly10yGR0vuWD+uyn
 BV7q5AKpGrwm6wZkMM2uZ1VdUtWzn856AbkqrvX/QhmJcX4McuqaLUrC8bSOj1ty
 KeVil0akq3nU+xHl5Ojs
 =Pmsx
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC driver updates from Arnd Bergmann:
 "The main addition this time around is the new ARM "SCMI" framework,
  which is the latest in a series of standards coming from ARM to do
  power management in a platform independent way.

  This has been through many review cycles, and it relies on a rather
  interesting way of using the mailbox subsystem, but in the end I
  agreed that Sudeep's version was the best we could do after all.

  Other changes include:

   - the ARM CCN driver is moved out of drivers/bus into drivers/perf,
     which makes more sense. Similarly, the performance monitoring
     portion of the CCI driver are moved the same way and cleaned up a
     little more.

   - a series of updates to the SCPI framework

   - support for the Mediatek mt7623a SoC in drivers/soc

   - support for additional NVIDIA Tegra hardware in drivers/soc

   - a new reset driver for Socionext Uniphier

   - lesser bug fixes in drivers/soc, drivers/tee, drivers/memory, and
     drivers/firmware and drivers/reset across platforms"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (87 commits)
  reset: uniphier: add ethernet reset control support for PXs3
  reset: stm32mp1: Enable stm32mp1 reset driver
  dt-bindings: reset: add STM32MP1 resets
  reset: uniphier: add Pro4/Pro5/PXs2 audio systems reset control
  reset: imx7: add 'depends on HAS_IOMEM' to fix unmet dependency
  reset: modify the way reset lookup works for board files
  reset: add support for non-DT systems
  clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_remove
  firmware: arm_scmi: prevent accessing rate_discrete uninitialized
  hwmon: (scmi) return -EINVAL when sensor information is unavailable
  amlogic: meson-gx-socinfo: Update soc ids
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers
  soc: mediatek: update power domain data of MT2712
  dt-bindings: soc: update MT2712 power dt-bindings
  cpufreq: scmi: add thermal dependency
  soc: mediatek: fix the mistaken pointer accessed when subdomains are added
  soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC
  soc: mediatek: avoid hardcoded value with bus_prot_mask
  dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding
  dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC
  ...
2018-04-05 21:29:35 -07:00
Arnd Bergmann 3478b24c5e cpufreq: scpi: Add thermal dependency
A built-in scpi cpufreq driver cannot link against a modular
thermal framework:

drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_ready':
scpi-cpufreq.c:(.text+0x4c): undefined reference to `of_cpufreq_cooling_register'
drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_exit':
scpi-cpufreq.c:(.text+0x9c): undefined reference to `cpufreq_cooling_unregister'

This adds a Kconfig dependency that makes sure this configuration
is not possible, while allowing all configurations that can work.
Note that disabling CPU_THERMAL means we don't care about the
THERMAL dependency.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
2018-03-20 11:02:42 +01:00
Arnd Bergmann 697a3a873c cpufreq: scmi: add thermal dependency
A built-in scmi cpufreq driver cannot link against a modular
thermal framework:

drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_ready':
scmi-cpufreq.c:(.text+0x40): undefined reference to `of_cpufreq_cooling_register'
drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_exit':
scmi-cpufreq.c:(.text+0x88): undefined reference to `cpufreq_cooling_unregister'

This adds a Kconfig dependency that makes sure this configuration
is not possible, while allowing all configurations that can work.
Note that disabling CPU_THERMAL means we don't care about the
THERMAL dependency.

Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-13 15:26:01 +01:00
Arnd Bergmann f46f11dc1e ARM SCMI support for v4.17
ARM System Control and Management Interface(SCMI)[1] is more flexible and
 easily extensible than any of the existing interfaces.
 
 Few existing as well as future ARM platforms provide micro-controllers
 to abstract various power and other system management tasks which have
 similar interfaces, both in terms of the functions that are provided by
 them, and in terms of how requests are communicated to them.
 
 There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
 BPMP, and so on already. This specification is to standardize and avoid any
 further fragmentation in the design of such interface by various vendors.
 
 The current SCMI driver implementation is very basic and initial support.
 It lacks support for notifications, asynchronous/delayed response, perf/power
 statistics region and sensor register region.
 
 Mailbox is the only form of transport supported currently in the driver.
 SCMI supports interrupt based mailbox communication, where, on completion
 of the processing of a message, the caller receives an interrupt as well as
 polling for completion.
 
 SCMI is designed to minimize the dependency on the mailbox/transport
 hardware. So in terms of SCMI, each channel in the mailbox includes
 memory area, doorbell and completion interrupt.
 
 However the doorbell and completion interrupt is highly mailbox dependent
 which was bit of controversial as part of SCMI/mailbox discussions.
 
 Arnd and me discussed about the few aspects of SCMI and the mailbox framework:
 
 1. Use of mailbox framework for doorbell type mailbox controller:
    - Such hardware may not require any data to be sent to signal the remote
      about the presence of a message. The channel will have in-built
      information on how to trigger the signal to the remote.
      There are few mailbox controller drivers which are purely doorbell based.
      e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc
 
 2. Supporting other mailbox controller:
    - SCMI just needs a mechanism to signal the remote firmware. Such
      controller may need fixed message to be sent to trigger a doorbell.
      In such case we may need to get that data from DT and pass the same
      to the controller. It's not covered in the current DT binding, but
      can be extended as optional property in future.
 
      However handling notifications may be interesting on such mailbox, but
      again there is no way to interpret what the data field(remote message)
      means, it could be a bit mask or a number or don't-care.
 
 Arnd mentioned that he doesn't like the way the mailbox binding deals
 with doorbell-type hardware, but we do have quite a few precedent drivers
 already and changing the binding to add a data field would not make it any
 better, but could cause other problems. So he is happy with the status quo
 of SCMI implementation.
 
 [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABCAAGBQJalvXJAAoJEABBurwxfuKYUHoQANi5gm0vGgRhb8/Cc6BHF9ij
 WVge3E2O+Ygg2qTKJJxWvwG3w09Pu9Pugwoa7vuisDNz4ihF+3WEYCZiwrbQhMOQ
 8ZyxXwdBu4Kp0fnNAGGq0MWllwspVgdC2Be5jviDTMw7H8ZIQEiKjxPkdSFY1xFj
 YAtTzuUeDcuztUb3IliOpLscxNUqGEQr4p/xj0VFu+1XSwtYo/9bDU7haiYNj0MD
 zbNv9WhyjUHTTsdQjDW4YGywQpFPu/oI8oSR5q+Q3mudccaZYbvvTwKDRACLVkr4
 rpeymFdGSEU8OI23pKql4eEZ2DC1VKuVnG9peTr9UhhuRL8jQKqFLeCYH0fGcY89
 VGWDIFBjyUg1NK7giCriqCq4m68UM49ChITXY6zRrIvyONgUZj6p6kTmCHC3TULH
 LWfu9lf7XqI5/AqZaXhHsDPL2Arf0u5K7rP6yaU0BgdQ2HRKV8rIT3KadjsOioAw
 bIDfpi4eInmq41CUy1gsWP6nIRg4qR4sZiWC2CW8ap0gbHq8a7PVuuRi4VDCZIkN
 CfntuDAnE+FMq/cMpgLRGteNbl0MVAeAeJfEGNyk5ahhYZtvnAy142zDpBmvWZth
 ZuZvb7mwiNPiZTC65B/DFDdSCKZtD+LVCodzcm2Pkx6zgW0SC6pje+mX0+zpDxZ9
 A9Eguiun1hInKX3URD1D
 =qOck
 -----END PGP SIGNATURE-----

Merge tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers

Pull "ARM SCMI support for v4.17" from Sudeep Holla:

ARM System Control and Management Interface(SCMI)[1] is more flexible and
easily extensible than any of the existing interfaces.

Few existing as well as future ARM platforms provide micro-controllers
to abstract various power and other system management tasks which have
similar interfaces, both in terms of the functions that are provided by
them, and in terms of how requests are communicated to them.

There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
BPMP, and so on already. This specification is to standardize and avoid any
further fragmentation in the design of such interface by various vendors.

The current SCMI driver implementation is very basic and initial support.
It lacks support for notifications, asynchronous/delayed response, perf/power
statistics region and sensor register region.

Mailbox is the only form of transport supported currently in the driver.
SCMI supports interrupt based mailbox communication, where, on completion
of the processing of a message, the caller receives an interrupt as well as
polling for completion.

SCMI is designed to minimize the dependency on the mailbox/transport
hardware. So in terms of SCMI, each channel in the mailbox includes
memory area, doorbell and completion interrupt.

However the doorbell and completion interrupt is highly mailbox dependent
which was bit of controversial as part of SCMI/mailbox discussions.

Arnd and me discussed about the few aspects of SCMI and the mailbox framework:

1. Use of mailbox framework for doorbell type mailbox controller:
   - Such hardware may not require any data to be sent to signal the remote
     about the presence of a message. The channel will have in-built
     information on how to trigger the signal to the remote.
     There are few mailbox controller drivers which are purely doorbell based.
     e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc

2. Supporting other mailbox controller:
   - SCMI just needs a mechanism to signal the remote firmware. Such
     controller may need fixed message to be sent to trigger a doorbell.
     In such case we may need to get that data from DT and pass the same
     to the controller. It's not covered in the current DT binding, but
     can be extended as optional property in future.

     However handling notifications may be interesting on such mailbox, but
     again there is no way to interpret what the data field(remote message)
     means, it could be a bit mask or a number or don't-care.

Arnd mentioned that he doesn't like the way the mailbox binding deals
with doorbell-type hardware, but we do have quite a few precedent drivers
already and changing the binding to add a data field would not make it any
better, but could cause other problems. So he is happy with the status quo
of SCMI implementation.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html

* tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  cpufreq: scmi: add support for fast frequency switching
  cpufreq: add support for CPU DVFS based on SCMI message protocol
  hwmon: add support for sensors exported via ARM SCMI
  hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration
  clk: add support for clocks provided by SCMI
  firmware: arm_scmi: add device power domain support using genpd
  firmware: arm_scmi: add per-protocol channels support using idr objects
  firmware: arm_scmi: refactor in preparation to support per-protocol channels
  firmware: arm_scmi: add option for polling based performance domain operations
  firmware: arm_scmi: add support for polling based SCMI transfers
  firmware: arm_scmi: probe and initialise all the supported protocols
  firmware: arm_scmi: add initial support for sensor protocol
  firmware: arm_scmi: add initial support for power protocol
  firmware: arm_scmi: add initial support for clock protocol
  firmware: arm_scmi: add initial support for performance protocol
  firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices
  firmware: arm_scmi: add common infrastructure and support for base protocol
  firmware: arm_scmi: add basic driver infrastructure for SCMI
  dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol
  dt-bindings: mailbox: add support for mailbox client shared memory
2018-03-07 16:45:07 +01:00
Sudeep Holla 99d6bdf338 cpufreq: add support for CPU DVFS based on SCMI message protocol
On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control including CPU DVFS. SCMI Message Protocol is used to
communicate with the SCP.

This patch adds a cpufreq driver for such systems using SCMI interface
to drive CPU DVFS.

Cc: linux-pm@vger.kernel.org
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-28 16:37:57 +00:00
Sudeep Holla 5c8b2623f6 cpufreq: scpi: Fix incorrect arm_big_little config dependency
Commit 343a8d17fa (cpufreq: scpi: remove arm_big_little dependency)
removed the SCPI cpufreq dependency on arm_big_little cpufreq driver.
However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ
which is clearly wrong.

This patch removes that unnecessary Kconfig dependency.

Fixes: 343a8d17fa (cpufreq: scpi: remove arm_big_little dependency)
Reported-by: Quentin Perret <quentin.perret@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-26 23:29:19 +01:00
Gregory CLEMENT 92ce45fb87 cpufreq: Add DVFS support for Armada 37xx
This patch adds DVFS support for the Armada 37xx SoCs

There are up to four CPU frequency loads for Armada 37xx controlled by
the hardware.

This driver associates the CPU load level to a frequency, then the
hardware will switch while selecting a load level.

The hardware also can associate a voltage for each level (AVS support)
but it is not yet supported

Tested-by: Andre Heider <a.heider@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-16 17:11:43 +01:00
Gregory CLEMENT b17d2f8d37 cpufreq: ARM: sort the Kconfig menu
Group all the related big LITTLE configuration together and sort the
other entries in alphabetic order.

Also fixing tab vs space issue while mofifying these entries.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-16 02:29:42 +01:00
Linus Walleij 919096f7f3 cpufreq: dbx500: Delete obsolete driver
We have moved the Ux500 over to use the generic DT based
cpufreq driver, so delete the old custom driver.

At the same time select CPUFREQ_DT from the machine's
Kconfig in order to satisfy the "default ARCH_U8500"
selection on the old driver.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-22 15:50:02 +02:00
Marc Gonzalez 9dbd224f9e cpufreq: dt: Don't use generic platdev driver for tango
On tango platforms, firmware configures the CPU clock, and Linux is
then only allowed to use the cpu_clk_divider to change the frequency.
Build the OPP table dynamically at init, in order to support whatever
firmware throws at us.

Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-22 02:20:59 +02:00
Sean Wang 501c574f4e cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with
single cluster and this hardware is also compatible with the existing
driver through enabling CPU frequency feature with operating-points-v2
bindings. Also, this driver actually supports all MediaTek SoCs, the
Kconfig menu entry and file name itself should be updated with more
generic name to drop "MT8173"

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-22 02:19:37 +02:00
Arnd Bergmann be0408d74d cpufreq: dbx500: add a Kconfig symbol
Moving the cooling code into the cpufreq driver caused a possible build failure
when the cpu_thermal helper code is a loadable module or disabled:

drivers/cpufreq/dbx500-cpufreq.o: In function `dbx500_cpufreq_ready':
dbx500-cpufreq.c:(.text.dbx500_cpufreq_ready+0x4): undefined reference to `cpufreq_cooling_register'

This adds the same dependency that we have in other cpufreq drivers,
forcing the driver to be disabled when we can't possibly link it.

Fixes: 19678ffb9f (cpufreq: dbx500: Manage cooling device from cpufreq driver)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-05-14 13:40:16 +02:00
Mikko Perttunen 939dc6f51e cpufreq: Add Tegra186 cpufreq driver
Add a new cpufreq driver for Tegra186 (and likely later).
The CPUs are organized into two clusters, Denver and A57,
with two and four cores respectively. CPU frequency can be
adjusted by writing the desired rate divisor and a voltage
hint to a special per-core register.

The frequency of each core can be set individually; however,
this is just a hint as all CPUs in a cluster will run at
the maximum rate of non-idle CPUs in the cluster.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19 23:23:08 +02:00
Arnd Bergmann a578884fa0 cpufreq: CPPC: add ACPI_PROCESSOR dependency
Without the Kconfig dependency, we can get this warning:

warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR)

Fixes: 5477fb3bd1 (ACPI / CPPC: Add a CPUFreq driver for use with CPPC)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-16 01:00:03 +01:00
Dave Gerlach e13cf046cd cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
have different OPPs available for the MPU depending on which specific
variant of the SoC is in use. This can be determined through use of the
revision and an eFuse register present in the silicon. Introduce a
ti-cpufreq driver that can read the aformentioned values and provide
them as version matching data to the opp framework. Through this the
opp-supported-hw dt binding that is part of the operating-points-v2
table can be used to indicate availability of OPPs for each device.

This driver also creates the "cpufreq-dt" platform_device after passing
the version matching data to the OPP framework so that the cpufreq-dt
handles the actual cpufreq implementation. Even without the necessary
data to pass the version matching data the driver will still create this
device to maintain backwards compatibility with operating-points v1
tables.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-09 22:57:48 +01:00
Markus Mayer 33de45c133 cpufreq: brcmstb-avs-cpufreq: add debugfs support
In order to aid debugging, we add a debugfs interface to the driver
that allows direct interaction with the AVS co-processor.

The debugfs interface provides a means for reading all and writing some
of the mailbox registers directly from the shell prompt and enables a
user to execute the communications protocol between ARM CPU and AVS CPU
step-by-step.

This interface should be used for debugging purposes only.

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-01 06:07:38 +01:00
Markus Mayer de322e0859 cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs
This driver supports voltage and frequency scaling on Broadcom STB SoCs
using AVS firmware with DFS and DVFS support.

Actual frequency or voltage scaling is done exclusively by the AVS
firmware. The driver merely provides a standard CPUfreq interface to
other kernel components and userland, and instructs the AVS firmware to
perform frequency or voltage changes on its behalf.

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-01 06:07:37 +01:00
Linus Walleij ae8b8d8f86 cpufreq: retire the Integrator cpufreq driver
After switching the core module clocks controlling the Integrator
clock frequencies to the common clock framework, defining the
operating points in the device tree, and activating the generic
DT-based CPUfreq driver, we can retire the old Integrator
cpufreq driver.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-01 06:01:18 +01:00
Viresh Kumar 3920be471c cpufreq: hisilicon: Use generic platdev driver
The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
device now, reuse that and remove similar code from platform code.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-25 16:18:24 +02:00
Arnd Bergmann 3c2002aec3 cpufreq: mediatek: allow building as a module
The MT8173 cpufreq driver can currently only be built-in, but
it has a Kconfig dependency on the thermal core. THERMAL
can be a loadable module, which in turn makes this driver
impossible to build.

It is nicer to make the cpufreq driver a module as well, so
this patch turns the option in to a 'tristate' and adapts
the dependency accordingly.

The driver has no module_exit() function, so it will continue
to not support unloading, but it can be built as a module
and loaded at runtime now.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 5269e7067c (cpufreq: Add ARM_MT8173_CPUFREQ dependency on THERMAL)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-01 02:43:05 +01:00
Rafael J. Wysocki 4157c2fc84 Merge back earlier cpufreq material for v4.5. 2015-12-21 03:15:15 +01:00
Lee Jones ab0ea257fc cpufreq: st: Provide runtime initialised driver for ST's platforms
The bootloader is charged with the responsibility to provide platform
specific Dynamic Voltage and Frequency Scaling (DVFS) information via
Device Tree.  This driver takes the supplied configuration and
registers it with the new generic OPP framework, to then be used with
CPUFreq.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-12 02:55:21 +01:00
Arnd Bergmann b5832e4b62 cpufreq: tegra: add regulator dependency for T124
This driver is the only one that calls regulator_sync_voltage(), but it
can currently be built with CONFIG_REGULATOR disabled, producing
this build error:

drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx':
drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration]
  regulator_sync_voltage(priv->vdd_cpu_reg);

My first attempt was to implement a helper for this function
for regulator_sync_voltage, but Mark Brown explained:

   We don't do this for *all* regulator API functions - there's some where
   using them strongly suggests that there is actually a dependency on
   the regulator API.  This does seem like it might be falling into the
   specialist category [...]
   Looking at the code I'm pretty unclear on what the authors think the
   use of _sync_voltage() is doing in the first place so it may be even
   better to just remove the call.  It seems to have been included in the
   first commit so there's not changelog explaining things and there's
   no comment either.  I'd *expect* it to be a noop as far as I can see.

This adds the dependency to make the driver always build successfully
or not be enabled at all. Alternatively, we could investigate if the
driver should stop calling regulator_sync_voltage instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-12 02:25:56 +01:00
Punit Agrawal 2f7e8a175d cpufreq: arm_big_little: Add support to register a cpufreq cooling device
Register passive cooling devices when initialising cpufreq on
big.LITTLE systems. If the device tree provides a dynamic power
coefficient for the CPUs then the bound cooling device will support
the extensions that allow it to be used with all the existing thermal
governors including the power allocator governor.

A cooling device will be created per individual frequency domain and
can be bound to thermal zones via the thermal DT bindings.

Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-10 00:14:58 +01:00
Punit Agrawal 73124ced9c cpufreq: SCPI: Depend on SCPI clk driver
The SCPI clk driver registers the virtual cpufreq device that kicks off
initialisation of the SCPI cpufreq driver. Also, clk_get() will fail for
the cpufreq driver if the SCPI clk driver is missing.

Fix this by making the SCPI cpufreq driver explicitly depend on the SCPI
clk driver.

Fixes: 8def31034d (cpufreq: arm_big_little: add SCPI interface driver)
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-23 23:50:27 +01:00
Rafael J. Wysocki 9832bf3a35 Merge branches 'pm-cpufreq' and 'acpi-cppc'
* pm-cpufreq:
  Revert "Documentation: kernel_parameters for Intel P state driver"
  cpufreq: mediatek: fix build error
  cpufreq: intel_pstate: Add separate support for Airmont cores
  cpufreq: intel_pstate: Replace BYT with ATOM
  Revert "cpufreq: intel_pstate: Use ACPI perf configuration"
  Revert "cpufreq: intel_pstate: Avoid calculation for max/min"

* acpi-cppc:
  ACPI / CPPC: Use h/w reduced version of the PCCT structure
2015-11-20 01:22:10 +01:00
Arnd Bergmann 2d4ee30367 cpufreq: mediatek: fix build error
The recently added mt8173 cpufreq driver relies on the cpu topology
that is always present on ARM64 but optional on ARM32:

drivers/cpufreq/mt8173-cpufreq.c: In function 'mtk_cpufreq_init':
drivers/cpufreq/mt8173-cpufreq.c:441:30: error: 'cpu_topology' undeclared (first use in this function)
  cpumask_copy(policy->cpus, &cpu_topology[policy->cpu].core_sibling);

This refines the Kconfig dependencies so that we can still build on
ARM32, but only if COMPILE_TEST is selected and the CPU topology
code is present.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-19 00:21:47 +01:00
Linus Torvalds b44a3d2a85 ARM: SoC driver updates for v4.4
As we've enabled multiplatform kernels on ARM, and greatly done away with
 the contents under arch/arm/mach-*, there's still need for SoC-related
 drivers to go somewhere.
 
 Many of them go in through other driver trees, but we still have
 drivers/soc to hold some of the "doesn't fit anywhere" lowlevel code
 that might be shared between ARM and ARM64 (or just in general makes
 sense to not have under the architecture directory).
 
 This branch contains mostly such code:
 
 - Drivers for qualcomm SoCs for SMEM, SMD and SMD-RPM, used to communicate
   with power management blocks on these SoCs for use by clock, regulator and
   bus frequency drivers.
 - Allwinner Reduced Serial Bus driver, again used to communicate with PMICs.
 - Drivers for ARM's SCPI (System Control Processor). Not to be confused with
   PSCI (Power State Coordination Interface). SCPI is used to communicate with
   the assistant embedded cores doing power management, and we have yet to see
   how many of them will implement this for their hardware vs abstracting in
   other ways (or not at all like in the past).
 - To make confusion between SCPI and PSCI more likely, this release also
   includes an update of PSCI to interface version 1.0.
 - Rockchip support for power domains.
 - A driver to talk to the firmware on Raspberry Pi.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWQC+cAAoJEIwa5zzehBx3jEUP/0GpxfDVanEUkudVLLe7J0RH
 CNlRan107Cw6hXRUJo7elEsuCALjccXjc1CAH4+RnNpOAeBKW97n+WU7trTv+wUZ
 sQX4SkBPKFBlgwGF2qhsi5q74gms/BrgtCa4kNb9joOYso039tlfIOPzK80DMkOm
 TkyIJdUCgFJMjCQLhX6kGT0PDcrbIjb6aA2cF3FAVeaJA7uz8lNe/eHJr3oHxIEY
 CvC651yJ2mIHQUU4BJx/AJo+wXg3dRUXNCAtBjwLRPEAzduYZXYm1ZTVIby/1q9r
 dR2KDFEuibODXmXrDBzKNJwCu/TLJEwo/1oPaEIVfY91XLKfiWUhgVqa1o1I+d9U
 XoGPibCW461qFahjQW87MfInALpCOA7/RbTNjFp+MVyipCYvkaYq7KFiYEldgFDx
 z4Qx/J4hYc2TlDWrpNiUCZMfmhwi7y+Ib+tnenYTO1eyMuw0e9mfnVdjk5iU3Pvk
 Ye4qPqpYclJruyHbYi164878+1lLaW2NCUgC3rkBO/GWPAzp7d9iLWoZ3PuyD5i5
 PEjs668UcRdZYbI4rdrhGHL8Eq9Gnuc4Rthu7HxPOK+DG0XgP8r97PhM8aYGYVDO
 +yikBtjWRsA9fPj3rMKA3UsQ61DAeR9LmZ0XPGjWFMCjCG0JlUoIMaA+Uu0i8fr8
 95qxBVxbO7rhL39r1rhV
 =dm+I
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC driver updates from Olof Johansson:
 "As we've enabled multiplatform kernels on ARM, and greatly done away
  with the contents under arch/arm/mach-*, there's still need for
  SoC-related drivers to go somewhere.

  Many of them go in through other driver trees, but we still have
  drivers/soc to hold some of the "doesn't fit anywhere" lowlevel code
  that might be shared between ARM and ARM64 (or just in general makes
  sense to not have under the architecture directory).

  This branch contains mostly such code:

   - Drivers for qualcomm SoCs for SMEM, SMD and SMD-RPM, used to
     communicate with power management blocks on these SoCs for use by
     clock, regulator and bus frequency drivers.

   - Allwinner Reduced Serial Bus driver, again used to communicate with
     PMICs.

   - Drivers for ARM's SCPI (System Control Processor).  Not to be
     confused with PSCI (Power State Coordination Interface).  SCPI is
     used to communicate with the assistant embedded cores doing power
     management, and we have yet to see how many of them will implement
     this for their hardware vs abstracting in other ways (or not at all
     like in the past).

   - To make confusion between SCPI and PSCI more likely, this release
     also includes an update of PSCI to interface version 1.0.

   - Rockchip support for power domains.

   - A driver to talk to the firmware on Raspberry Pi"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (57 commits)
  soc: qcom: smd-rpm: Correct size of outgoing message
  bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus
  bus: sunxi-rsb: Add Allwinner Reduced Serial Bus (RSB) controller bindings
  ARM: bcm2835: add mutual inclusion protection
  drivers: psci: make PSCI 1.0 functions initialization version dependent
  dt-bindings: Correct paths in Rockchip power domains binding document
  soc: rockchip: power-domain: don't try to print the clock name in error case
  soc: qcom/smem: add HWSPINLOCK dependency
  clk: berlin: add cpuclk
  ARM: berlin: dts: add CLKID_CPU for BG2Q
  ARM: bcm2835: Add the Raspberry Pi firmware driver
  soc: qcom: smem: Move RPM message ram out of smem DT node
  soc: qcom: smd-rpm: Correct the active vs sleep state flagging
  soc: qcom: smd: delete unneeded of_node_put
  firmware: qcom-scm: build for correct architecture level
  soc: qcom: smd: Correct SMEM items for upper channels
  qcom-scm: add missing prototype for qcom_scm_is_available()
  qcom-scm: fix endianess issue in __qcom_scm_is_call_available
  soc: qcom: smd: Reject send of too big packets
  soc: qcom: smd: Handle big endian CPUs
  ...
2015-11-10 15:00:03 -08:00
Ashwin Chaugule 5477fb3bd1 ACPI / CPPC: Add a CPUFreq driver for use with CPPC
This driver utilizes the methods introduced in a previous
patch titled - "ACPI: Introduce CPU performance controls using CPPC"
and enables usage with existing CPUFreq governors.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-12 23:04:31 +02:00