| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a CPU comes online, clk_set_rate() silently refuses to change said CPU's
frequency to the frequency it was running at before going offline (since it
thinks that we are setting the same frequency redundantly). By default, each CPU
runs at its minimum frequency when coming online, so if the governor decides to
keep a CPU running at the frequency it used before going offline, then
clk_set_rate() will ignore the frequency change request and the CPU will stay
stuck running at its minimum frequency for a potentially long period of time
(i.e. until the governor decides to change the frequency to something
different). This can cause severe lag when a device is woken up from deep sleep.
In order to prevent a CPU from being stuck at its default frequency for a
potentially long period of time, set the CLKFLAG_NO_RATE_CACHE flag so that the
governor's frequency change requests will always be honored right after a CPU
comes online.
Note that this requires a CPU's component clocks to be using CLKFLAG_NO_RATE_CACHE
as well in order to fix the issue.
Signed-off-by: Sultanxda <sultanxda@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update cpufreq driver to adapt to opensource clock framework
Opensource clock framework dev_clk_get returns with the
different clock handle for all cpu cores with same clock source
This is different in the existing clock framework where
dev_clk_get returns with the same clock handle for the cores
which shares the same clock source.
Cpufreq driver was compatible with the existing clock
framework but with the opensource clock framework we need
to handle the different clock handles for all the cores
even the clock source is common.
Change-Id: Ic343bc20dc7c8b2ce151a5a2b5f85b43cdd949bf
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since not all frequencies line up between speed bins,
the common cpufreq table sometimes has frequencies
that round up the same actual frequency.
Fix this by skipping those frequencies.
Change-Id: I0516cc67a1343150f3d1f838b9d9b329e8e1e498
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: David Keitel <dkeitel@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
cpufreq_table_validate_and_show() is created as a standard way to
initialize frequency for a policy and assign freq_table. Use this new
API to assign freq_table.
CRs-Fixed: 1024229
Change-Id: Iac3a9394790e140492c5c0c0ad6d068840bfffa4
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
cpufreq_frequency_get_table could return NULL. Do error check on the
return value instead of continue with a potentially NULL pointer.
Change-Id: I0cb8a3a8ae3499e738683e5f45271aeadee488f6
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__cpufreq_driver_target() checks if policy->cur is same as target_freq
without holding any lock. This function is used by governor to
directly set CPU frequency. Governor calling this function can't hold
any CPUfreq framework locks due to deadlock possibility.
However, this results in a race condition where one thread could see
a stale policy->cur while another thread is changing CPU frequency.
Thread A: Governor calls __cpufreq_driver_target(), starts increasing
frequency but hasn't sent out CPUFREQ_POSTCHANGE notification yet.
Thread B: Some other driver (could be thermal mitigation) starts
limiting frequency using cpufreq_update_policy(). Every limits are
applied to policy->min/max and final policy->max happens to be same as
policy->cur. __cpufreq_driver_target() simply returns 0.
Thread A: Governor finish scaling and now policy->cur violates
policy->max and could last forever until next CPU frequency scaling
happens.
Shifting the responsibility of checking policy->cur and target_freq
to CPUfreq device driver would resolve the race as long as the device
driver holds a common mutex.
Change-Id: I6f943228e793a4a4300c58b3ae0143e09ed01d7d
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
Frequency table is allocated with devm_kzalloc() and thus should be
freed using devm_kfree().
Change-Id: I9c08838eadb9fc04bda9cc66596e1e0b45b3e4db
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
CPUfreq framework replaced per-cpu freq_table with per-policy
freq_table, and deprecated previous per-cpu APIs.
Fill in policy->freq_table.
Change-Id: Ifc9ac1b6695fd12629a447984dbbd57d657961b2
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Previous cpufreq_notify_transition() is deprecated in favor of
cpufreq_freq_transition_begin/end() API which provides serialization
guarantee for notifications.
Use the new API for transition notification.
Change-Id: I8d559e5c6ef4771986b24e017c900476da1f6cdf
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
cpufreq_suspend is now a function in core CPUfreq framework. Rename
qcom-cpufreq's local per-cpu variable to suspend_data.
Change-Id: I2f567f0c04271d728d4e6a17b61cea2152c4d8f7
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Different structures might need to be saved and restored based on
different scheduling policies of current thread. Saving and restoring
priority using scheduler APIs is very fragile due to potential changes
in scheduler code. In addition, the priority change doesn't
provide any starvation guarantee because threads can be preempted
before the priority change.
Therefore remove save and restore of priority to avoid potential bugs
when scheduler API changes. Caller will now be responsible for setting
the right priority for their CPU frequency scaling workqueue/thread.
Change-Id: I2a5d8599e75c0c4aa902df3214c17ab2b13dc9a9
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qcom-cpufreq blocks CPU frequency change request during suspend, because
its dependencies might be suspended. Thus a freq change request would
fail silently, and CPU clock won't change until first frequency update
is requested after system comes out of suspend. This creates a period
when thermal driver cannot perform frequency mitigation, even though
policy->min/max have been correctly updated.
Check each online CPU's policy during resume to correct any frequency
violation as soon as possible.
Change-Id: I3be79cf91e7d5e361314020c9806b770823c0b72
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
It's no longer a requirement to pin frequency change on the CPU that
is being scaled. Therefore, there is no longer a need for per-cpu
workqueue in qcom-cpufreq. Remove the workqueue.
Change-Id: Ic6fd7f898fa8b1b1226a178b04530c24f0398daa
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
MSM_CPU_FREQ_SET_MIN_MAX and related Kconfigs are deprecated. Purge
them from Kconfig and qcom-cpufreq.
Change-Id: I8ac786c155c7e235154b60c79f97d76ea15dace2
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
|
|
This is a snapshot of qcom-cpufreq as of msm-3.10 commit
acdce027751d5a7488b283f0ce3111f873a5816d (Merge "defconfig: arm64:
Enable ONESHOT_SYNC for msm8994")
Change-Id: Idb99a856330566ffad6309c48edabb220cee7917
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[junjiew@codeaurora.org: resolved conflicts in Kconfig.arm
and Makefile. Dropped dependency on ARCH_MSM.]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
|
