12 Feb, 2019
37 commits
-
This patch fixes coverity issue of "divide by 0".
Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
This patch fixes coverity issue of "unchecked return value".
Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
Remove the unnecessary mutex and rcu lock from i.MX8MQ & i.MX7ULP
cpufreq driver.Signed-off-by: Bai Ping
Reviewed-by: Anson Huang -
Add cpufreq support for i.MX6ULZ.
Signed-off-by: Bai Ping
-
i.MX8MM shares same cpu-freq driver with i.MX8MQ, but
its EVK board has a PMIC which can scale VDD_ARM voltage
according to voltage defined in dtb, add support for it.Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
According to datasheet Rev-D, on B0 part, below CPU
freq needs to be supported:500MHz for RUN mode;
720MHz for HSRUN mode.To achieve best accurate frequency for CPU, adjust
SPLL's frequency for SPLL_PFD0 which is CPU's
clock source:SPLL 528MHz -> SPLL_PFD0 500.2MHz;
SPLL 480MHz -> SPLL_PFD0 720MHz;Remove CPU RUN/HSRUN mode switch, since it is implemented
as clock mux, whenever clock parent is switched, the
RUN/HSRUN mode will be changed accordingly.Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
On i.MX8MQ, since the OPP table is initialized in cpu-freq platform
device register according to chip type, so no need to redo the OPP
table initialization in cpu-freq driver, this patch adds check for
OPP table initialization to avoid below warning during boot up:[ 1.468378] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1501
[ 1.468388] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1301
[ 1.468417] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 1300000000
[ 1.468425] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1001
[ 1.468434] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 8001
[ 1.468443] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 800000000Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
For multi-cluster platforms like i.MX8QM, the best cpufreq
governor is schedutil, as common cpufreq framework decides
default cpufreq governor in static compile, so this patch
adds dynamic switch of cpufreq governor according to cluster
number, changing it via sysfs interface, although it is
ugly, but it realizes dynamic cpufreq governor select for
users.Signed-off-by: Anson Huang
-
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
-
Register cpu-freq cooling device if device tree
supports cooling-cells, different cluster can
have its own cooling device settings.Signed-off-by: Anson Huang
-
For i.MX8MQ, suspend freq can use policy->max after cpu freq
table is validated, so no need to get OPP number and MAX
frequency for suspend freq now, also add necessary resource free
when probe failed.Signed-off-by: Anson Huang
-
For i.MX8QM/8QXP, suspend freq can use policy->max after cpu
freq table is validated, so no need to get OPP number and MAX
frequency for suspend freq now, also add necessary resource free
when probe failed.Signed-off-by: Anson Huang
-
Add SIP cpu-freq support, the CPU hardware frequency
scale will be performed by ARM Trusted Firmware,
and add cpu-freq suspend support, MAX frequency will
be used during suspend.Signed-off-by: Anson Huang
-
i.MX8MQ can run at over-drive mode which needs
increasing VDD_ARM voltage, add gpio regulator support
for over-drive mode.Signed-off-by: Anson Huang
-
Add i.MX8MQ cooling device support, when temperature
exceeds passive threshold, cpu-freq will drop to lowest
set-point, and once temperature drops below passive
threshold, cpu-freq will restore.Signed-off-by: Anson Huang
-
Add i.MX8MQ cpufreq support, current version of
EVK board does NOT support voltage scale, but next
version will add this support, so this driver only
supports cpu frequency scale, voltage scale will
be added later once new board available.A53 CPU clock normally is from ARM_PLL, but during
ARM_PLL relock window, it will be switched to
SYS1_PLL_800M to avoid clock missing, and after
arm pll relock done, it will be switched back.Signed-off-by: Anson Huang
-
The pm Qos add/remove only need to be called when A7 change mode
between HSRUN and RUN mode.Signed-off-by: Bai Ping
-
Add multi-clusters cpu-freq driver support for i.MX8,
only support cpu-freq get now.Signed-off-by: Anson Huang
-
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
-
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
-
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
-
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 -
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
-
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) -
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
-
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) -
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
Also squashed: MLK-10123: cpufreq: imx6q-cpufreq: initialize local variable 'i'
Signed-off-by: Robin Gong
-
This fixes hangs on imx6sl when attempting to change cpufreq
Also 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.Signed-off-by: Octavian Purdila
Signed-off-by: Leonard Crestez -
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
Updated during 4.14 rebase
Signed-off-by: Leonard Crestez
01 Dec, 2018
1 commit
-
[ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ]
Add return value check for voltage scale when ARM clock
rate change fail.Signed-off-by: Anson Huang
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
14 Nov, 2018
2 commits
-
[ Upstream commit 51c99dd2c06b234575661fa1e0a1dea6c3ef566f ]
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
since the latest OPP core updates as that uses reference counting to
free resources. There are cases where no static OPPs are added (using
DT) for a platform and trying to remove the OPP table may end up
decrementing refcount which is already zero and hence generating
warnings.Lets track if we were able to add static OPPs or not and then only
remove the table based on that. Some reshuffling of code is also done to
do that.Reported-by: Niklas Cassel
Tested-by: Niklas Cassel
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit da5e79bc70b84971d2b3a55fb252e34e51d81d48 upstream.
If the policy limits change between invocations of cs_dbs_update(),
the requested frequency value stored in dbs_info may not be updated
and the function may use a stale value of it next time. Moreover, if
idle periods are takem into account by cs_dbs_update(), the requested
frequency value stored in dbs_info may be below the min policy limit,
which is incorrect.To fix these problems, always update the requested frequency value
in dbs_info along with the local copy of it when the previous
requested frequency is beyond the policy limits and avoid decreasing
the requested frequency below the min policy limit when taking
idle periods into account.Fixes: abb6627910a1 (cpufreq: conservative: Fix next frequency selection)
Fixes: 00bfe05889e9 (cpufreq: conservative: Decrease frequency faster for deferred updates)
Reported-by: Waldemar Rymarkiewicz
Cc: All applicable
Signed-off-by: Rafael J. Wysocki
Acked-by: Waldemar Rymarkiewicz
Acked-by: Viresh Kumar
Signed-off-by: Greg Kroah-Hartman
