Commit Graph

2364 Commits

Author SHA1 Message Date
Viresh Kumar
2dd0df8472 cpufreq: Drop cpufreq_table_validate_and_show()
This isn't used anymore. Remove the helper and update documentation
accordingly.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:40:45 +02:00
Viresh Kumar
d983af9864 cpufreq: SCMI: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from SCMI driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:39:55 +02:00
Shunyong Yang
8913315e94 cpufreq: CPPC: Initialize shared perf capabilities of CPUs
When multiple CPUs are related in one cpufreq policy, the first online
CPU will be chosen by default to handle cpufreq operations. Let's take
cpu0 and cpu1 as an example.

When cpu0 is offline, policy->cpu will be shifted to cpu1. cpu1's perf
capabilities should be initialized. Otherwise, perf capabilities are 0s
and speed change can not take effect.

This patch copies perf capabilities of the first online CPU to other
shared CPUs when policy shared type is CPUFREQ_SHARED_TYPE_ANY.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:38:02 +02:00
Gregory CLEMENT
bbcc328561 cpufreq: armada-37xx: Fix clock leak
There was no clk_put() balancing the clk_get(). This commit fixes it.

Fixes: 92ce45fb87 (cpufreq: Add DVFS support for Armada 37xx)
Cc: 4.16+ <stable@vger.kernel.org> # 4.16+
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:38:02 +02:00
Viresh Kumar
b8b10bc201 cpufreq: CPPC: Don't set transition_latency
Now that the driver has started to set transition_delay_us directly,
there is no need to set transition_latency along with it, as it is not
used by the cpufreq core.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:38:02 +02:00
Viresh Kumar
44a264ee1e cpufreq: ti-cpufreq: Use builtin_platform_driver()
This driver can not be built as a module and there is no need of the
platform driver unregister part. Use builtin_platform_driver() instead
of module_platform_driver().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10 08:38:02 +02:00
Rafael J. Wysocki
b258dfeafb cpufreq: intel_pstate: Do not include debugfs.h
The intel_pstate driver doesn't use debugfs any more, so drop
linux/debugfs.h from the list of included headers in it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-04-10 08:38:02 +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
Linus Torvalds
f2d285669a Power management updates for 4.17-rc1
- Modify the cpuidle poll state implementation to prevent CPUs from
    staying in the loop in there for excessive times (Rafael Wysocki).
 
  - Add Intel Cannon Lake chips support to the RAPL power capping
    driver (Joe Konno).
 
  - Add reference counting to the device links handling code in the
    PM core (Lukas Wunner).
 
  - Avoid reconfiguring GPEs on suspend-to-idle in the ACPI system
    suspend code (Rafael Wysocki).
 
  - Allow devices to be put into deeper low-power states via ACPI
    if both _SxD and _SxW are missing (Daniel Drake).
 
  - Reorganize the core ACPI suspend-to-idle wakeup code to avoid a
    keyboard wakeup issue on Asus UX331UA (Chris Chiu).
 
  - Prevent the PCMCIA library code from aborting suspend-to-idle due
    to noirq suspend failures resulting from incorrect assumptions
    (Rafael Wysocki).
 
  - Add coupled cpuidle supprt to the Exynos3250 platform (Marek
    Szyprowski).
 
  - Add new sysfs file to make it easier to specify the image storage
    location during hibernation (Mario Limonciello).
 
  - Add sysfs files for collecting suspend-to-idle usage and time
    statistics for CPU idle states (Rafael Wysocki).
 
  - Update the pm-graph utilities (Todd Brandt).
 
  - Reduce the kernel log noise related to reporting Low-power Idle
    constraings by the ACPI system suspend code (Rafael Wysocki).
 
  - Make it easier to distinguish dedicated wakeup IRQs in the
    /proc/interrupts output (Tony Lindgren).
 
  - Add the frequency table validation in cpufreq to the core and
    drop it from a number of cpufreq drivers (Viresh Kumar).
 
  - Drop "cooling-{min|max}-level" for CPU nodes from a couple of
    DT bindings (Viresh Kumar).
 
  - Clean up the CPU online error code path in the cpufreq core
    (Viresh Kumar).
 
  - Fix assorted issues in the SCPI, CPPC, mediatek and tegra186
    cpufreq drivers (Arnd Bergmann, Chunyu Hu, George Cherian,
    Viresh Kumar).
 
  - Drop memory allocation error messages from a few places in
    cpufreq and cpuildle drivers (Markus Elfring).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJawgTUAAoJEILEb/54YlRxI48QALc6IUfj/O+gLAWAf8qHk+8V
 eLn9E1NrZXUtNMNYItBcgZfuMImIj7MC5qRo/BhzYdd0VyUzFYEyd9liUVFBDEXA
 SH65jyjRrXORKfLrSP5H8lcCdckTFXfxzonVFN2n4l7Gdv540UFuqloU+vS4Wrfp
 wMg9UvKRxr+7LwOI4q2sMFtB8Uki+lySY5UECqRIKUIJKIH6RPo3m73Kps7kw8kU
 c2RCU8w/9PoomPaEjvwZ0vT5lNrQXmBbC5hxcMzBHtLS0Cwb3xJsUB4w6niezdGY
 e+n6Vx7XeId7+Ujnn4praxUwyVq2wEirJccvAEgKFcZzjmGAXrHl8rOgMLvb3ugN
 P+ftkYk+Vizci9hmACeA1LGw4hN/dXMfephnezCsy9Q/QK8QPJV8XO0vxfyaQYhZ
 ie6SKcdZimFDzqd6oHLFftRou3imvq8RUvKTx2CR0KVkApnaDDiTeP5ay1Yd+UU3
 EomWe7/mxoSgJ9kB/9GlKifQXBof62/fbrWH0AdM1oliONbbOZcLqg5x4DZUmfTK
 hTAx3SSxMRZSlc4Zl1CzbrHnFKi9cRBYCs0tPdOSnAO2ZfCsOmokJE+ig5I8lZre
 SlaciUpG2Vvf7m61mVlrqLLos8T9rTVM2pqwsoxII7A+dFrWK3HpqoypEN/87tm7
 4/zjPF6LK2eTKL9WdTCk
 =6JC2
 -----END PGP SIGNATURE-----

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

Pull power management updates from Rafael Wysocki:
 "These update the cpuidle poll state definition to reduce excessive
  energy usage related to it, add new CPU ID to the RAPL power capping
  driver, update the ACPI system suspend code to handle some special
  cases better, extend the PM core's device links code slightly, add new
  sysfs attribute for better suspend-to-idle diagnostics and easier
  hibernation handling, update power management tools and clean up
  cpufreq quite a bit.

  Specifics:

   - Modify the cpuidle poll state implementation to prevent CPUs from
     staying in the loop in there for excessive times (Rafael Wysocki).

   - Add Intel Cannon Lake chips support to the RAPL power capping
     driver (Joe Konno).

   - Add reference counting to the device links handling code in the PM
     core (Lukas Wunner).

   - Avoid reconfiguring GPEs on suspend-to-idle in the ACPI system
     suspend code (Rafael Wysocki).

   - Allow devices to be put into deeper low-power states via ACPI if
     both _SxD and _SxW are missing (Daniel Drake).

   - Reorganize the core ACPI suspend-to-idle wakeup code to avoid a
     keyboard wakeup issue on Asus UX331UA (Chris Chiu).

   - Prevent the PCMCIA library code from aborting suspend-to-idle due
     to noirq suspend failures resulting from incorrect assumptions
     (Rafael Wysocki).

   - Add coupled cpuidle supprt to the Exynos3250 platform (Marek
     Szyprowski).

   - Add new sysfs file to make it easier to specify the image storage
     location during hibernation (Mario Limonciello).

   - Add sysfs files for collecting suspend-to-idle usage and time
     statistics for CPU idle states (Rafael Wysocki).

   - Update the pm-graph utilities (Todd Brandt).

   - Reduce the kernel log noise related to reporting Low-power Idle
     constraings by the ACPI system suspend code (Rafael Wysocki).

   - Make it easier to distinguish dedicated wakeup IRQs in the
     /proc/interrupts output (Tony Lindgren).

   - Add the frequency table validation in cpufreq to the core and drop
     it from a number of cpufreq drivers (Viresh Kumar).

   - Drop "cooling-{min|max}-level" for CPU nodes from a couple of DT
     bindings (Viresh Kumar).

   - Clean up the CPU online error code path in the cpufreq core (Viresh
     Kumar).

   - Fix assorted issues in the SCPI, CPPC, mediatek and tegra186
     cpufreq drivers (Arnd Bergmann, Chunyu Hu, George Cherian, Viresh
     Kumar).

   - Drop memory allocation error messages from a few places in cpufreq
     and cpuildle drivers (Markus Elfring)"

* tag 'pm-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (56 commits)
  ACPI / PM: Fix keyboard wakeup from suspend-to-idle on ASUS UX331UA
  cpufreq: CPPC: Use transition_delay_us depending transition_latency
  PM / hibernate: Change message when writing to /sys/power/resume
  PM / hibernate: Make passing hibernate offsets more friendly
  cpuidle: poll_state: Avoid invoking local_clock() too often
  PM: cpuidle/suspend: Add s2idle usage and time state attributes
  cpuidle: Enable coupled cpuidle support on Exynos3250 platform
  cpuidle: poll_state: Add time limit to poll_idle()
  cpufreq: tegra186: Don't validate the frequency table twice
  cpufreq: speedstep: Don't validate the frequency table twice
  cpufreq: sparc: Don't validate the frequency table twice
  cpufreq: sh: Don't validate the frequency table twice
  cpufreq: sfi: Don't validate the frequency table twice
  cpufreq: scpi: Don't validate the frequency table twice
  cpufreq: sc520: Don't validate the frequency table twice
  cpufreq: s3c24xx: Don't validate the frequency table twice
  cpufreq: qoirq: Don't validate the frequency table twice
  cpufreq: pxa: Don't validate the frequency table twice
  cpufreq: ppc_cbe: Don't validate the frequency table twice
  cpufreq: powernow: Don't validate the frequency table twice
  ...
2018-04-03 10:45:39 -07:00
George Cherian
3d41386d55 cpufreq: CPPC: Use transition_delay_us depending transition_latency
With commit e948bc8fbe (cpufreq: Cap the default transition delay
value to 10 ms)  the cpufreq was not honouring the delay passed via
ACPI (PCCT). Due to which on ARM based platforms using CPPC the
cpufreq governor tries to change the frequency of CPUs faster than
expected.

This leads to continuous error messages like the following.
" ACPI CPPC: PCC check channel failed. Status=0 "

Earlier (without above commit) the default transition delay was
taken form the value passed from PCCT. Use the same value provided
by PCCT to set the transition_delay_us.

Fixes: e948bc8fbe (cpufreq: Cap the default transition delay value to 10 ms)
Signed-off-by: George Cherian <george.cherian@cavium.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-30 12:15:58 +02:00
Arnd Bergmann
9a1651dcc1 cpufreq: remove cris specific drivers
The cris architecture is getting removed, including the artpec3
and etraxfs SoCs, so these cpufreq drivers are now unused.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-26 15:56:52 +02:00
Arnd Bergmann
9a3daf58f9 cpufreq: remove blackfin driver
The blackfin architecture is getting removed, so this driver is
now obsolete.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Aaron Wu <aaron.wu@analog.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-26 15:56:50 +02:00
Viresh Kumar
a8b6966034 cpufreq: tegra186: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from tegra186 driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:53 +01:00
Viresh Kumar
2d28b03686 cpufreq: speedstep: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from speedstep driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
31f4b7a86b cpufreq: sparc: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from sparc driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
ec8d2cc62c cpufreq: sh: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from sh-cpufreq driver.

The driver though prints the min/max frequency values and the same is
done from the ->ready() callback now to keep the behavior unchanged.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
54a277ebf2 cpufreq: sfi: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from sfi driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
472ada6021 cpufreq: scpi: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from scpi driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
f35750c885 cpufreq: sc520: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from sc520 driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
09e390f30f cpufreq: s3c24xx: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from s3c24xx driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
5ab508bebf cpufreq: qoirq: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from qoirq driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
8ed5a219d0 cpufreq: pxa: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from pxa driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
20dfdb9c80 cpufreq: ppc_cbe: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from ppc_cbe driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
e2376d1fa0 cpufreq: powernow: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from powernow driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
b01b531f67 cpufreq: p4-clockmod: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from p4-clockmod driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
b563afbaa8 cpufreq: mediatek: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from mediatek driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
2c65616b98 cpufreq: longhaul: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from longhaul driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
b6663622a3 cpufreq: ia64-acpi: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from ia64-acpi driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
c3e3cc8aa3 cpufreq: elanfreq: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from elanfreq driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
0d10539445 cpufreq: e_powersaver: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from e_powersaver driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
29aa18a762 cpufreq: cpufreq-dt: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from cpufreq-dt driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
5d8d4f9215 cpufreq: brcmstb: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from brcmstb driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:52 +01:00
Viresh Kumar
3c1f5a462e cpufreq: arm_big_little: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from arm_big_little driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:51 +01:00
Viresh Kumar
1a186d9e11 cpufreq: ACPI: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table in the acpi-cpufreq driver.

The driver needs to crosscheck if the max frequency corresponds to the
P-state 0 or not and the same is done from the ->ready() callback now.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:51 +01:00
Viresh Kumar
92c99d159c cpufreq: Don't validate cpufreq table from cpufreq_generic_init()
The cpufreq table is already validated by the cpufreq core and none of
the users of cpufreq_generic_init() have any dependency on it to
validate the table as well.

Don't validate the cpufreq table anymore from cpufreq_generic_init().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:51 +01:00
Viresh Kumar
8d768cdcf0 cpufreq: imx6q: Find max freq from frequency table itself
This is a preparatory commit to make policy->suspend_freq independent of
validation of the cpufreq table, as a later commit would update
cpufreq_generic_init() to not validate the cpufreq table any longer.

The driver already assumes the order in which the frequency table is
sorted and we can get the max frequency easily.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 12:07:51 +01: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
Chunyu Hu
55b55abc17 cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path
Kmemleak reported the below leak. When cppc_cpufreq_init went into
failure path, the cpu mask is not freed. After fix, this report is
gone. And to avaoid potential NULL pointer reference, check the cpu
value first.

unreferenced object 0xffff800fd5ea4880 (size 128):
  comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s)
  hex dump (first 32 bytes):
    00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00  .... ...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffff0000082c4ae4>] __kmalloc_node+0x278/0x634
    [<ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60
    [<ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c
    [<ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c
    [<ffff000008083828>] do_one_initcall+0xec/0x15c
    [<ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4
    [<ffff0000089099b0>] kernel_init+0x18/0x10c
    [<ffff000008084d50>] ret_from_fork+0x10/0x18
    [<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-20 10:52:31 +01:00
Viresh Kumar
bf14721c97 cpufreq: powernv: Don't validate the frequency table twice
The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from powernv driver.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-19 00:04:56 +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
Rafael J. Wysocki
1179c2aeb4 Merge cpufreq fixes from v4.16-rc4. 2018-03-05 12:37:06 +01:00
Rafael J. Wysocki
b61e070305 Merge branch 'cpufreq-scpi'
* cpufreq-scpi:
  cpufreq: scpi: Fix incorrect arm_big_little config dependency
  cpufreq: scpi: invoke frequency-invariance setter function
2018-03-02 10:44:44 +01:00
Sudeep Holla
02f208c5c6 cpufreq: scmi: add support for fast frequency switching
The cpufreq core provides option for drivers to implement fast_switch
callback which is invoked for frequency switching from interrupt context.

This patch adds support for fast_switch callback in SCMI cpufreq driver
by making use of polling based SCMI transfer. It also sets the flag
fast_switch_possible.

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
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
Markus Elfring
0f555518ea cpufreq: powernow-k8: Drop unnecessary return statements from two functions
The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 18:29:01 +01:00
Markus Elfring
7f3a1d66df cpufreq: powernow-k8: Drop memory allocation error messages from three functions
Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 18:29:01 +01:00
Markus Elfring
d6b96e4706 cpufreq: qoriq: Drop memory allocation error messages from qoriq_cpufreq_cpu_init()
Omit extra messages for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 18:29:01 +01:00
Markus Elfring
d430fb9984 cpufreq: s3c24xx: Drop memory allocation error messages from two functions
Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 18:29:01 +01:00
Viresh Kumar
3e3b507ef6 cpufreq: tegra186: Break after initialization is done for policy->cpu
There are two clusters (2 + 4 CPUs) on this platform and a separate
cpufreq policy is available for each of the CPUs. The loop in
tegra186_cpufreq_init() tries to find the structure for the right CPU
and finish initialization. But it is missing a `break` statement at the
end, which forces it to restart the loop even when the CPU already
matched and initialization is done.

Fix that by adding the missing `break` statement.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 18:22:12 +01:00