06 Nov, 2018
2 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
29 Oct, 2018
35 commits
-
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
10 Sep, 2018
1 commit
-
commit 2a3eb51e30b9ac66fe1b75877627a7e4aaeca24a upstream.
If cppc_cpufreq.ko is deleted at the same time that tuned-adm is
changing profiles, there is a small chance that a race can occur
between cpufreq_dbs_governor_exit() and cpufreq_dbs_governor_limits()
resulting in a system failure when the latter tries to use
policy->governor_data that has been freed by the former.This patch uses gov_dbs_data_mutex to synchronize access.
Fixes: e788892ba3cc (cpufreq: governor: Get rid of governor events)
Signed-off-by: Henry Willard
[ rjw: Subject, minor white space adjustment ]
Cc: 4.8+ # 4.8+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
25 Jul, 2018
1 commit
-
commit 95d6c0857e54b788982746071130d822a795026b upstream.
Currently, intel_pstate doesn't register if _PSS is not present on
HP Proliant systems, because it expects the firmware to take over
CPU performance scaling in that case. However, if ACPI PCCH is
present, the firmware expects the kernel to use it for CPU
performance scaling and the pcc-cpufreq driver is loaded for that.Unfortunately, the firmware interface used by that driver is not
scalable for fundamental reasons, so pcc-cpufreq is way suboptimal
on systems with more than just a few CPUs. In fact, it is better to
avoid using it at all.For this reason, modify intel_pstate to look for ACPI PCCH if _PSS
is not present and register if it is there. Also prevent the
pcc-cpufreq driver from trying to initialize itself if intel_pstate
has been registered already.Fixes: fbbcdc0744da (intel_pstate: skip the driver if ACPI has power mgmt option)
Reported-by: Andreas Herrmann
Reviewed-by: Andreas Herrmann
Acked-by: Srinivas Pandruvada
Tested-by: Andreas Herrmann
Cc: 4.16+ # 4.16+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2018
1 commit
-
commit d4f3388afd488ed15368fa7413b8bd6d1f98bb1d upstream.
Add support to specify platform specific transition_delay_us instead
of using the transition delay derived from PCC.With commit 3d41386d556d (cpufreq: CPPC: Use transition_delay_us
depending transition_latency) we are setting transition_delay_us
directly and not applying the LATENCY_MULTIPLIER. Because of that,
on Qualcomm Centriq we can end up with a very high rate of frequency
change requests when using the schedutil governor (default
rate_limit_us=10 compared to an earlier value of 10000).The PCC subspace describes the rate at which the platform can accept
commands on the CPPC's PCC channel. This includes read and write
command on the PCC channel that can be used for reasons other than
frequency transitions. Moreover the same PCC subspace can be used by
multiple freq domains and deriving transition_delay_us from it as we
do now can be sub-optimal.Moreover if a platform does not use PCC for desired_perf register then
there is no way to compute the transition latency or the delay_us.CPPC does not have a standard defined mechanism to get the transition
rate or the latency at the moment.Given the above limitations, it is simpler to have a platform specific
transition_delay_us and rely on PCC derived value only if a platform
specific value is not available.Signed-off-by: Prashanth Prakash
Cc: 4.14+ # 4.14+
Fixes: 3d41386d556d (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
