15 Sep, 2017
1 commit
-
On i.MX6ULL EVK board, when the overdrive mode(900MHz/800MHz) is
enable, the DC regulator voltage should not be changed. Keep the
DC regulator to default 1.4V.Signed-off-by: Bai Ping
(cherry picked from commit e4b51b651ae95226c0ae0447673c64b23b079ee6)Conflicts:
drivers/cpufreq/imx6q-cpufreq.c
09 Jun, 2017
4 commits
-
The pm Qos add/remove only need to be called when A7 change mode
between HSRUN and RUN mode.Signed-off-by: Bai Ping
-
Make sure we reparent pll1_sys to pll1_bypass before changing it's
rate. Otherwise, it may happen that pll1_sys is "parented" to
pll1_bypass_src like this:osc
pll1 0 0 996000000 0 0
pll1_bypass_src 0 0 24000000 0 0
pll1_bypass 0 0 24000000 0 0
pll1_sys 0 0 24000000 0 0in which case changing the rate of pll1_sys won't propagate up to pll1
and we will end up with a different pll1_sys rate than requested.This fixes an issue where cpufreq can't properly switch to 792Mhz:
$ cpufreq-set -f 996000
$ cpufreq-set -f 396000
$ cpufreq-set -f 792000
$ cat /sys/kernel/debug/clk/clk_summary
pll1 1 1 996000000 0 0
pll1_bypass 1 1 996000000 0 0
pll1_sys 1 1 996000000 0 0
pll1_sw 1 1 996000000 0 0
arm 2 2 498000000 0 0Signed-off-by: Octavian Purdila
-
This also fixes the following warning:
drivers/cpufreq/cpufreq_interactive.c: In function 'choose_freq':
drivers/cpufreq/cpufreq_interactive.c:284:7: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (ret)
^Signed-off-by: Octavian Purdila
-
This fixes an issue with imx6ull where setting the frequency to 528Mhz
would actually set the ARM clock to 324Mhz.Signed-off-by: Octavian Purdila
Reviewed-by: Leonard Crestez
08 Jun, 2017
10 commits
-
Upstream rejected this patch because it is wrong: Attaching clk and
regulator resources to the cpu device results in them never actually
getting freed.This is relevant now that we rely on supporting EPROBE_DEFER because we
must handle correctly returning from a partial probe.In particular this patch fixes imx6qp-sabresd not setting the PU
regulator to bypass mode because the cpufreq driver fetched the
regulator before gpc and leaked it.This is not a straight revert because other clks and regulators were
added, we add code to free them too.Signed-off-by: Leonard Crestez
-
According to the i.MX7ULP RM & datasheet, when A7 is in RUN mode,
the max CPU frequency it can run at is 500MHz, if we want to increase
the A7 CPU frequency to 800MHz, we need to change the A7 from RUN mode
to HSRUN mode. And only when A7 is in RUN mode, we can enter STOP mode
and VLLS mode.Signed-off-by: Bai Ping
-
The "arm" clock for imx7d has been modified to encapsulate
all other clocks needed for normal functioning ("arm_root_src",
"pll_arm", "pll_sys_main"). Modify cpufreq to use the new
version of "arm" clock.Signed-off-by: Irina Tirdea
-
If there are any errors in getting the cpu0 regulators, the driver returns
-ENOENT. In case the regulators are not yet available, the devm_regulator_get
calls will return -EPROBE_DEFER, so that the driver can be probed later.
If we return -ENOENT, the driver will fail its initialization and will
not try to probe again (when the regulators become available).Return the actual error received from regulator_get in probe. Print a
differentiated message in case we need to probe the device later and
in case we actually failed. Also add a message to inform when the
driver has been successfully registered.Signed-off-by: Irina Tirdea
-
This is a missing piece of 99a978fbde34227a2ab2a3595446b757b5d7c3ab from
linux-imx/imx_4.1.y.This fixes a hang on imx6sl when attempting to decrease cpufreq
during late boot. This was found through tracing and comparing code with
the imx_4.1.y branch -
On i.MX6SLL, if all PLLs is bypassed in low power run mode, we can decrease
the VDD_ARM_IN and VDD_SOC_IN voltage to 0.925V to save power. a 25mV margin
is added to cover IR drop and board tolerance.Add low power run voltage change support for i.MX6SLL.
Signed-off-by: Bai Ping
-
On i.MX6ULL, when the CPU freq is running at 198MHz or 396MHz, the system will
enter low bus mode if no device need high bus mode. The first time the system
entering low bus mode, CPU freq will be set to 24MHz, if cpufreq change the CPU
freq from 198MHz(396MHz) to 396MHz(198MHz), the CPU freq will be set to 198MHz or
396 MHz. At this time, if the CPU enter low power idle, system will hang.Signed-off-by: Bai Ping
-
When VPU runs at 396MHz, VDDSOC_CAP's voltage
should be set to 1.275V for all set-points,
add VPU clock rate check to support this case.Signed-off-by: Anson Huang
-
According the the latest datasheet, we updated the lowest
OPP to 198MHz. So we need to update the cpufreq code to fix
the syttem hang issue when run 'cpufreq-info' in low bus mode
on i.MX6ULL.Signed-off-by: Bai Ping
-
On i.MX6ULL, when the system entering the low bus mode, system will enter
low power run mode in which the cpufreq is at 24MHz. If we run
'cpufreq-info' until, the cpu frequency will be change from 24MHz to 99MHz,
this will lead to system enter low power idle wrong, and system will hang
in low power idle.Add the ARM core clock handling code to fix this issue.
Signed-off-by: Bai Ping
23 Feb, 2017
21 commits
-
Get the old_freq from the policy->cur.
Signed-off-by: Bai Ping
-
On i.MX6UL EVK board, we use a external GPIO DC regulator to control
the VDD_ARM_SOC_IN voltage, if default voltage is 1.4V when the system
is bootup. Per design team, when the highest setpoint freq is not
bigger than 528MHz, we can decrease this regulator voltage to 1.3V.
On i.MX6UL TO1.1, we add a 700MHz setpoint. When the highest setpoint
freq is 700MHz, the DC regulator should be at 1.4V to to cover the IR
drop.Signed-off-by: Bai Ping
-
The cpufreq_cpu_get() and cpufreq_cpu_put() should be called in
pairs. Otherwise, system will dump when enabling lock debug config.Signed-off-by: Bai Ping
-
Interactive governor has lived in Android sources for a very long time
and this commit is based on the code present in following branch:https://android.googlesource.com/kernel/common android-4.4
The Interactive governor is designed for latency-sensitive workloads,
such as interactive user interfaces like the mobile phones and tablets.
The interactive governor aims to be significantly more responsive to
ramp CPU quickly up when CPU-intensive activity begins.Existing governors sample CPU load at a particular rate, typically every
X ms and then update the frequency from a work-handler. This can lead
to under-powering UI threads for the period of time during which the
user begins interacting with a previously-idle system until the next
sample period happens.The 'interactive' governor uses a different approach.
A real-time thread is used for scaling up, giving the remaining tasks
the CPU performance benefit, unlike existing governors which are more
likely to schedule ramp-up work to occur after your performance starved
tasks have completed.The Android version of interactive governor also checks whether to scale
the CPU frequency up soon after coming out of idle. When the CPU comes
out of idle, the governor check if the CPU sampling is overdue or not.
If yes, it immediately starts the sampling. Otherwise, the utilization
hooks from the scheduler handle the sampling later. If the CPU is very
busy from exiting idle to when the evaluation happens, then it assumes
that the CPU is under-powered and ramps it to MAX speed.If the CPU was not sufficiently busy to immediately ramp to MAX speed,
then the governor evaluates the CPU load since the last speed
adjustment, choosing the highest value between that longer-term load or
the short-term load since idle exit to determine the CPU speed to ramp
to.Idle notifiers will be be handled later and are not included for now.
The core of this code is written and maintained (in Android
repositories) by Mike Chan and Todd Poyner over a long period of time.Vireshk has made changes to to the governor to align it with the current
practices followed with mainline governors, like using utilization hooks
from the scheduler and handling kobject (for governor's sysfs directory)
in a race free manner. And of course this included general cleanup of
the governor as well.Signed-off-by: Mike Chan
Signed-off-by: Todd Poynor
Signed-off-by: Viresh Kumar---
V1->V2:
- Changes to fix compilation issues with updated mainline
- Timer APIs got updated
- s/mod_timer_pinned/mod_timer
- s/init_timer/init_timer_pinned
- Updated prototypes of cpufreq_frequency_table_target() and
update_util_handler() -
These macros can be reused by governors which don't use the common
governor code present in cpufreq_governor.c and should be moved to the
relevant header.Now that they are getting moved to the right header file, reuse them in
schedutil governor as well (that required rename of show/store
routines).Also create gov_attr_wo() macro for write-only sysfs files, this will be
used by Interactive governor in a later patch.Signed-off-by: Viresh Kumar
-
After coverity code check, it reports dereference NULL return value
complain, so fix it.Signed-off-by: Bai Ping
-
In some i.MX6 board (i.MX6UL EVK), it will have a additional
GPIO controlled DC-DC regulator. we need to change this regulator's
voltage According the maximum frequency that CPU can run at.At present, we only need to set the voltage to minimum one, we need
to set the voltage to the maximum before suspend, resume back to the
minimum voltage after suspend.Signed-off-by: Bai Ping
(cherry picked from commit 31f0773ee7d6ba5715486a221857f2ceccb434b4) -
The 'OR' operation should be '||', so fix it.
Signed-off-by: Bai Ping
-
During suspend/ressume, when cpufreq driver try to increase
Voltage/freq, it needs to control I2C/SPI to communicate with
external PMIC to adjust voltage, but these I2C/SPI devices may
be already suspended, to avoid such scenario, we adjust increase
cpufreq to highest setpoint before suspend.As this pm notification's updating cpu policy may work together
with cpufreq governor, both of them may call set_target at same
time, so we need to add mutex lock to prevent this scenario,
otherwise, the clock use count will be wrong.Signed-off-by: Anson Huang
Signed-off-by: Robin Gong
Signed-off-by: Bai Ping
(cherry picked from commit 9f5158fd0fd6e11e2f69cf975d3843cf6cc84048) -
for i.MX6SX, according to the latest datasheet, added a 198MHz setpoint in cpufreq driver.
The 198MHz setpoint is NOT enough to support playing mp3,the system will stay at a higher
setpoint and high_bus_mode. So when having a setpoint lower than 396MHz, make sure when
the cpufreq is at 396MHz or lower, the busfreq is always in low_bus_mode to save more power.Signed-off-by: Bai Ping
(cherry picked from commit 3ba9548200ffb2c85111dd84946046ae0c7b09c4) -
Normally, the system is booting up with higher cpufreq. In the
cpufreq set_target_index we will release the high bus mode if
the target cpu frequency is the lowest. It will release the high
bus mode and dcrease the high_bus_count.This will lead to a wrong
release of high bus mode. So, in the cpufreq_init function, if the
original frequency is not the lowest, we need request high busfreq.Signed-off-by: Bai Ping
(cherry picked from commit 7df8887a6ddac148d33cd583da31ec72d0ba07da) -
Request high bus frequency before scaling up the CPU frequency
and release high bus frequency after scaling down the CPU frequencyDoing so makes a balance between high performance and lower power
consumption.Signed-off-by: Bai Ping
(cherry picked from commit 35c91da2591a70858d5eec184c662851e39082d2) -
Initialize local variable 'i' to 0, otherwise may fall into wrong
code path. The issue come with commit 757ff4b89.Signed-off-by: Robin Gong
(cherry picked from commit 186f722c260279e21e05e4b13c9cc4d8348ae370) -
Pfuze200 only provide one power supply for VDDARM_IN and VDDSOC_IN,
for ldo-bypass mode, we have to pretend they are different regulators
otherwise regulator famework will refuse update voltage.Signed-off-by: Robin Gong
(cherry picked from commit 1b41ab90288b2accd710f8852c11753007749e4a) -
When VPU is running at 352MHz, SOC/PU voltage need to be
at 1.25V for 396/792MHz setpoint, as 396M setpoint is
removed, so only increase 792M setpoint's voltage.Signed-off-by: Anson Huang
-
This patch adds pll1, pll_bypass and pll1_bypass_src that
will be used in ARM clock switching code.Signed-off-by: Bai Ping
-
Replace the clk_get and regulator_get will the devm ones to free the
resources automatically when probe failed or driver is removed.Signed-off-by: Bai Ping
-
remove a duplicated pm notify.
Signed-off-by: Bai Ping
-
System resume failed easily after commit b993956109856d3, the commit is no
problem, but it exposes the potential deadlock bug which not unlock mutex if
cpufreq not change, remove these code since the cpufreq framwork has consider
it.Signed-off-by: Robin Gong
(cherry picked from commit d791bf25e07023f7a936fcabe6f641ad391048b3) -
Add pm_notifier for cpufreq on i.MX7D to make sure when
system do suspend/resume no cpu frequency change.
cpu frequency change may use the I2C/SPI interface to
control the external PMIC chip, if the I2C/SPI are not
active in this procedure, frequency change will fail.Signed-off-by: Bai Ping
(cherry picked from commit b993956109856d3b86df501271b5a55620781c1a) -
Add the basic cpufreq driver for imx7.
Signed-off-by: Bai Ping
(cherry picked from commit db765324267a7c3b93aaf798cefd6a775cf46b1a)
15 Feb, 2017
1 commit
-
commit 6e978b22efa1db9f6e71b24440b5f1d93e968ee3 upstream.
Some Kabylake desktop processors may not reach max turbo when running in
HWP mode, even if running under sustained 100% utilization.This occurs when the HWP.EPP (Energy Performance Preference) is set to
"balance_power" (0x80) -- the default on most systems.It occurs because the platform BIOS may erroneously enable an
energy-efficiency setting -- MSR_IA32_POWER_CTL BIT-EE, which is not
recommended to be enabled on this SKU.On the failing systems, this BIOS issue was not discovered when the
desktop motherboard was tested with Windows, because the BIOS also
neglects to provide the ACPI/CPPC table, that Windows requires to enable
HWP, and so Windows runs in legacy P-state mode, where this setting has
no effect.Linux' intel_pstate driver does not require ACPI/CPPC to enable HWP, and
so it runs in HWP mode, exposing this incorrect BIOS configuration.There are several ways to address this problem.
First, Linux can also run in legacy P-state mode on this system.
As intel_pstate is how Linux enables HWP, booting with
"intel_pstate=disable"
will run in acpi-cpufreq/ondemand legacy p-state mode.Or second, the "performance" governor can be used with intel_pstate,
which will modify HWP.EPP to 0.Or third, starting in 4.10, the
/sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
attribute in can be updated from "balance_power" to "performance".Or fourth, apply this patch, which fixes the erroneous setting of
MSR_IA32_POWER_CTL BIT_EE on this model, allowing the default
configuration to function as designed.Signed-off-by: Srinivas Pandruvada
Reviewed-by: Len Brown
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
20 Jan, 2017
1 commit
-
commit 8a10c06a20ec8097a68fd7a4a1c0e285095b4d2f upstream.
With preemption turned on we can read incorrect throttling state
while being switched to CPU on a different chip.BUG: using smp_processor_id() in preemptible [00000000] code: cat/7343
caller is .powernv_cpufreq_throttle_check+0x2c/0x710
CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1
Call Trace:
[c0000007d25b75b0] [c000000000971378] .dump_stack+0xe4/0x150 (unreliable)
[c0000007d25b7640] [c0000000005162e4] .check_preemption_disabled+0x134/0x150
[c0000007d25b76e0] [c0000000007b63ac] .powernv_cpufreq_throttle_check+0x2c/0x710
[c0000007d25b7790] [c0000000007b6d18] .powernv_cpufreq_target_index+0x288/0x360
[c0000007d25b7870] [c0000000007acee4] .__cpufreq_driver_target+0x394/0x8c0
[c0000007d25b7920] [c0000000007b22ac] .cpufreq_set+0x7c/0xd0
[c0000007d25b79b0] [c0000000007adf50] .store_scaling_setspeed+0x80/0xc0
[c0000007d25b7a40] [c0000000007ae270] .store+0xa0/0x100
[c0000007d25b7ae0] [c0000000003566e8] .sysfs_kf_write+0x88/0xb0
[c0000007d25b7b70] [c0000000003553b8] .kernfs_fop_write+0x178/0x260
[c0000007d25b7c10] [c0000000002ac3cc] .__vfs_write+0x3c/0x1c0
[c0000007d25b7cf0] [c0000000002ad584] .vfs_write+0xc4/0x230
[c0000007d25b7d90] [c0000000002aeef8] .SyS_write+0x58/0x100
[c0000007d25b7e30] [c00000000000bfec] system_call+0x38/0xfcFixes: 09a972d16209 (cpufreq: powernv: Report cpu frequency throttling)
Reviewed-by: Gautham R. Shenoy
Signed-off-by: Denis Kirjanov
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
06 Jan, 2017
1 commit
-
commit 91291d9ad92faa65a56a9a19d658d8049b78d3d4 upstream.
Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.Reported-by: Joonyoung Shim
Signed-off-by: Stephen Boyd
Signed-off-by: Viresh Kumar
[ Viresh: Wrote commit log and tested on exynos 5250 ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
29 Oct, 2016
1 commit
-
* pm-cpufreq-fixes:
cpufreq: intel_pstate: Always set max P-state in performance mode
cpufreq: intel_pstate: Set P-state upfront in performance mode* pm-sleep-fixes:
PM / suspend: Fix missing KERN_CONT for suspend message
