Because cpufreq core and governors worry only about the online cpus, if a cpu is
hot [un]plugged, we must notify governors about it, otherwise be ready to expect
something unexpected.
We already have notifiers in the form of CPUFREQ_GOV_START/CPUFREQ_GOV_STOP, we
just need to call them now.
Change-Id: I46e78a1d171a652dcc6b91abfbf22cfaaecdd4a5
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq core doesn't manage offline cpus and if driver->init() has returned
mask including offline cpus, it may result in unwanted behavior by cpufreq core
or governors.
We need to get only online cpus in this mask. There are two places to fix this
mask, cpufreq core and cpufreq driver. It makes sense to do this at common place
and hence is done in core.
Change-Id: I51cd5928818b669095468379de5f55534b239154
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Waking up sync thread recursively for same CPU causes deadlock.
Fix this by avoiding recursive wakeup call to same thread.
CRs-Fixed: 823472
Change-Id: Idc51f53da9fafc17d609132c8d72d85f76c8160f
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
Function dbs_check_cpu calls __cpufreq_driver_getavg
With policy as IN/OUT parameter.
There is possiblity of policy becoming NULL in
__cpufreq_driver_getavg. Same policy is getting
accessed in the for loop which leads to NULL pointer dereference.
So NULL check is required for the policy
CRs-fixed: 582925
Change-Id: Ib8d8de8d66500430a5aa4c275937640e4f934aa8
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
Commit 1ce28d6b (ondemand: updated tune for hardware coordination)
brings in an attempt to synchronize expiry of per-cpu ondemand timer
at same time across all online cpus. This is meant to help systems
where "multiple cores share P-state via Hardware Coordination".
Synchronization is achieved by having timers expire when jiffy value
would be a perfect multiple of sampling window size. While such
synchronozation attemps are unnecessary on systems where cores don't
share P-states, it can hurt on power as cpus can now work off shorter
sampling windows (when percentage utilization over short window can be
observed to be high, causing frequency to be boosted).
Remove this unnecessary attempt to synchronize expiry of ondemand
timer across online cpus. A more acceptable solution could be to have
low-level architecture specific cpufreq driver indicate the need for
synchronization.
Change-Id: I6cb1cf3472ca106f029dc01248e0df7cfbb495b8
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
This change adds sysfs entry for the ondemand governor's attribute
down_differential_multi_core. This is required to be able to program
this knob to attain better perf/power for use cases like camcorder.
CRs-fixed: 561456
Change-Id: Ib7c1223215c6b714c286c231ed37f3abfae741c6
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
The dbs_timer_init() call in store_powersave_bias() re-initializes the
dbs_info workqueue, call on dbs_timer_exit() to ensure
outstanding work is cleared prior to making this call. Also, grab the
percpu timer_mutex lock to avoid race conditions with respect to the
dbs timer.
Change-Id: I79f3d43eeb51d2d8e21edd0fe043d6583333951f
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
store_powersave_bias() acquires the hotplug lock and the dbs_mutex
lock, but does so in the wrong order. Deadlocks like the following
can result.
Thread A:
get_online_cpus+0x3c/0x5c <- acquires 'cpu_hotplug.lock'
store_powersave_bias+0x80/0x3f4 <- acquires 'dbs_mutex'
kobj_attr_store+0x14/0x20
sysfs_write_file+0x108/0x13c
vfs_write+0xb0/0x128
sys_write+0x38/0x64
Thread B:
cpufreq_governor_dbs+0x7c/0x55c <- acquires 'dbs_mutex'
__cpufreq_governor+0x90/0xe0
__cpufreq_set_policy+0x1b0/0x258
cpufreq_add_dev_interface+0x2cc/0x334
cpufreq_add_dev+0x514/0x580
cpufreq_cpu_callback+0x88/0x9c
notifier_call_chain+0x38/0x68
__cpu_notify+0x28/0x40
_cpu_up+0xe4/0x118 <- acquires 'cpu_hotplug.lock'
cpu_up+0x64/0x80
store_online+0x48/0x78
dev_attr_store+0x18/0x24
sysfs_write_file+0x108/0x13c
vfs_write+0xb0/0x128
sys_write+0x38/0x64
Fix this by flipping the order in which the locks are acquired and
released in store_powersave_bias so that it is the same as in the
hotplug path.
Change-Id: Idc59fb29d60b8f7fceb8ed0f2bb9eff4670abda7
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
update_sampling_rate has a for loop which goes through each
online cpu and possibly queue up the ondemand work for them.
But while doing this it doesnt take any hotplug lock which
could potentially cause a race condition where ondemand work
is queued after the hotplug code (which sets the policy to NULL)
in the governor has cancelled any pending work. This could cause
a crash while trying to access the NULL policy in dbs_check_cpu.
Protecting the for_each_online_cpu loop with get_online_cpus()
and put_online_cpus().
Change-Id: Ia3f43ca7e4bed542834ab03ca1191d728f13311c
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Currently Ondemand governor handles any input event
like touch by scaling the CPU frequency to maximum
available on the target.
This change adds a new sysfs interface "input_boost"
whereby the CPU will scale to this frequency on input events.
The value of this sysfs is user defined so input events
can now be handled by scaling the CPU to lower frequencies
than target max.
Change-Id: I5428fd8797c9984b17a66b01a44557f2160e8b68
Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>
Even though this work item runs on only one cpu at a time (due to
queue_work_on()) it is possible for the work item to be preempted
and so use of smp_processor_id() is illegal.
BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/3:1/4162 caller is dbs_refresh_callback+0xc/0x188
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c0279058>]
(debug_smp_processor_id+0xbc/0xf0)
[<c0279058>] (debug_smp_processor_id+0xbc/0xf0) from [<c0454b54>]
(dbs_refresh_callback+0xc/0x188)
[<c0454b54>] (dbs_refresh_callback+0xc/0x188) from [<c0087290>]
(process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>]
(worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>]
(kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>]
(kernel_thread_exit+0x0/0x8)
The intent of the code is to determine which CPU this work item
is running on, which we can easily do by passing that information
in a wrapper struct around the work struct. Do this so we avoid
this problem.
Change-Id: I05ca0ff2b3cbaa239930463ea0760e3e9d75145f
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Originally CPU frequency were boosted for any input event.
In some case, sensor sends a lot of input event, which
keep CPU in high frequency. CPU frequency only need to
be boosted when real user interaction happens.
Change-Id: Ia3ad755b98d8363a17729926610b5dd6f0075288
CR-Fixed: 507519
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Turn off frequency synchronization of CPUs on thread migrations
when powersave bias is enabled. This is done to prevent re-arming
of the dbs timer work (which is cancelled by store_powersave_bias)
by the sync_thread.
Change-Id: I165dd591845c1d66d01a14e8dfc44c767c677b0d
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
store_powersave_bias takes timer_mutex before calling dbs_timer_exit
which tries to cancel the delayed work do_dbs_timer which in turn
tries to take the same lock. This can cause a lock recursion under
the race condition where can cancel_delayed_work_sync is called
when the work has already started executing.
This can be avoided by taking that lock after calling
dbs_timer_exit.
Change-Id: I7f862286e66f1ddc1e13e4eeee369dd188fc10d5
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
This allows userspace to specify a min/max limit to the CPU
frequency, working around the standard scaling_[max|min]_freq
sysfs interfaces.
Initially based on Paul's cpufreq_limit driver.
Change-Id: I87dd8a0f67aadce0ca0f5cb668d7ee16c616deb0
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
Cpufreq time_in_state data for all CPUs is made persistent across
hotplug and exposed to userspace via sysfs file
/sys/devices/system/cpu/cpufreq/all_time_in_state
Change-Id: I97cb5de24b6de16189bf8b5df9592d0a6e6ddf32
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
The migration notifier may run in a context where it is not safe to
enqueue a work item. For example:
(__queue_work+0x1f4/0x40c)
(queue_work_on+0x34/0x44)
(dbs_migration_notify+0x2c/0x40)
(notifier_call_chain+0x38/0x68)
(__atomic_notifier_call_chain+0x34/0x44)
(atomic_notifier_call_chain+0x14/0x18)
(try_to_wake_up+0x350/0x36c)
(autoremove_wake_function+0xc/0x34)
(__wake_up_common+0x48/0x7c)
(__wake_up+0x3c/0x50)
(trustee_thread+0x1d0/0x528)
(kthread+0x80/0x8c)
The trustee code already takes a lock internal to the workqueue
implementation and is not expecting a wake up to come around and
enter the workqueue code again, where the same lock will be needed.
Instead of relying on a workqueue, use a per-CPU kthread to do
the frequency syncing.
Change-Id: I7555ee40867792fa8ec4ea8f9a6309323775e797
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
In the process of scaling CPU frequencies, cpufreq and the APIS is
calls may hold resources that will prevent threads critical for
system stability from running.
Specifically, thermal-mitigation software may need to respond
quickly to high-temperature conditions and throttle the CPU speed
in an effort to cool down. If the system is already in the middle
of a CPU frequency switch being executed on behalf of a cpufreq
governor, thermal mitigation will be blocked until the scaling
action has completed. If the system is under heave load of medium
or high-priority threads, this may take a long while and the system
may potentially surpass thermal limits in the meantime.
Resolve this by using high priority workqueues for all ondemand
and conservative governor scaling operations. This will allow them
to complete promptly and release their hold on resources necessary
for maintaining system stability.
Change-Id: I2f56052c131442838036cf4cdd8059f7c09bb805
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Sometimes when foreground threads, crucial for UI, migrate
from a core at higher frequency to the one running at a lower
frequency, it could badly affect performance for cases like
scrolling.
This change tries to raise the frequency of the destination core
to the same value as the source core, if it is not already running
at the same or higher frequency. In order for the ondemand
governor to have a fair idea of load in the next sample, it also
reschedules the next sample one sampling interval from the
frequency transition after which the ondemand governor again
takes over.
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
Change-Id: I9d2fbb166b0cc042d3fd57cea75a5066df4c794b
Cpufreq suspend variable get's updated in kernel pm notifier
callback which gets called in process context. This will create
window where cpufreq governor may try to change the frequency
before suspend variable is updated while resume.
Define suspend/resume for cpufreq driver to update suspend variable
in atomic context.
Don't update the policy->cur upon cpufreq driver failure.
CRs-fixed: 423791
Change-Id: Id78705f5c3b8bf801c6253e9362299280903769f
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Currently only current cpu load is considered when frequency scaling.
As a side effect of this when scheduler migrates a thread to a slower
core, the execution time increases unexpectedly.
The new algorithm not only considers current cpu load for frequency
scaling, but also takes into account load of other online cpus. The
treshold for this can be controlled using up_threshold_any_cpu_load.
When the up_threshold_any_cpu_load is crossed in any cpu then the
current cpu is set to sync_freq.
Also, when more than one cpu is online a two step ramp-up mechanism
is used. When the up_threshold_multi_core is crossed the cpu is ramped
up to optimal_freq which is less than policy->max and set to a power
friendly value.
Change-Id: I64bed1b142cde1f239e73aa1f78981c78aaf59ce
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
(cherry picked from commit d3ca78370df00ec7a5b6816321ea1a1a371f2850)
System performance is enhanced if the gpu frequency is given a
minimum corresponding to various frequency levels of CPU 0.
Change-Id: Iba168d708524fc8ef164428bb5f4e0631a499342
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
(cherry picked from commit 682c7a01c1d86518cdc7bec25cb413498811137b)
Currently core_name is used to identify which core the dcvs operates on.
Instead use a type and the type num while registration with dcvs and
return an id (dcvs_core_id) upon successfull registration.
The dcvs_core_id is used by the clients of msm_dcvs to call upon its
apis viz. freq_start, freq_stop, msm_dcvs_idle etc.
The dcvs inturn uses the type num passed in at registration time to
invoke apis on the clients viz. set_freq, get_freq, idle_enable.
This further cleans up the internal dcvs add_core and get_core
implementation. One need not pass around the core_name and use the type
instead.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 1bbc0321a6871e018c17da6f244b9df442faead6)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit 09456d7d7618e6d0fc6b907b7af75268ea08a942)
Change-Id: Id27751a8ec8f5d3d386bbe7c7625ed56757b8bd7
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Register the idle enable callback along with the core. The code
becomes cleaner and easy to update.
Importantly, the msm_dcvs_idle driver becomes useless. Remove it
and instead let the msm governor handle idle enabling and disabling.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit c1ed66c9035b4fbf240e46837d86a9a6442531f1)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit b4f5c2274fa2180b53563f2db0922eef212c0fcd)
Change-Id: Ice039e608d45bdeb9b8b718e5fbbf82a698d584d
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
There is no need to register a separate structure for setting and
getting frequency.
Simply pass function pointers to set and get callbacks when a
core is registered.
While at it rename the msm_dcvs_freq_sink_register/unregister to
msm_dcvs_freq_sink_start/stop to better reflect that those
apis are meant to do.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 69134111c2a24002d1995a05c99f84403ac6a7e8)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit 52cb57c3c6bc1c0d08c1ae9eb5dd0ff1e1125a96)
Change-Id: Iee7aee1cbb2f33ed2852f1816ab62416b96fa7e6
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
We had seen issues where dcvs goes out of sync with the actual
freq the cpu is running at. The root cause was if the userspace
changes the limits on the governor, the governor ends up changing
the frequency without notifying dcvs.
Provide an api for the governor to call dcvs when a frequency change
happens.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 68c970e38fcb700d851301dbacc56da9387294c6)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit a7d720e513cfae2d3f9c03c25f2ce2f10c2e9de7)
Change-Id: I3f321df0270e997531d1a4cf3ee2251f86aef0bc
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
__cpufreq_driver_target expects to be called with the rw semaphore
held. We are not doing this when the frequency is asked to be changed
by dcvs.
Use cpufreq_driver_target variant of that function which gets the
rw semaphore before setting the frequency.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 54fc08ea6d33c6c561167f369cba060fe33755c9)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit a63446bcd75909db632ffc8ff3c4e6a96c8593c5)
Change-Id: I33cdac0aaac7fb44acf6f9eb451a80ff94175c46
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
The stop could end up calling set_frequency callback. The set_frequency
callback takes the same gov_mutex lock and we end up in a deadlock.
Fix this by removing the locks around stop.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 5106c477a747279dbf045eed5a6ab4f68ac3501c)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit e0fa1831db0c57a8be8d5471ee3382b0f8a9165e)
Change-Id: I306f9cd2c05ce1e9c4c36d22d16b775a42881f0d
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
The algorithm needs thermal inputs for all the cores. Create members in
the internal core_info strucutre and platform data/device tree to pass
in the sensors they use.
Update the dcvs code to notify the temperature to TZ.
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit fc7dca4c325725492af997fa282e07b9d03154d1)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit eb478c5b7b55ea8a57e0336e4cf9979be935b289)
Change-Id: I505903eb8b9779f2065aebfab5b3f2aefc874200
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
This change
-removes the use of group id and instead introduces core type
-rearranges platform data, adds energy curve coefficients and power
parameters
-allow for the energy params to be -ve numbers
The change also mandates updates to the msm8974-gpu.dtsi and the
associated binding documentation.
Also take this opportunity to remove devices for unsupported platform
- 8930 and 8960
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
(cherry picked from commit 4445166ad16be0c45b077bfb10487de355ed2e05)
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
(cherry picked from commit 24d2351f6a5e7069e5d554dbc999280a69288c5d)
Change-Id: I5c65c0e65cc7652eee72c525f0db10e128061cf9
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_set_speed node eventually deadlocks with:
=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
(s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4
but task is already holding lock:
(s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(s_active#13);
lock(s_active#13);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by filemonkey/122:
#0: (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
#1: (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)
This is because store() in cpufreq.c indirectly grabs a kobject
with kobject_get() and is the last one to call kobject_put()
indirectly via cpufreq_cpu_put().
Fix this deadlock by introducing two new functions,
cpufreq_cpu_get_sysfs() and cpufreq_cpu_put_sysfs() which do the
same thing as cpufreq_cpu_{get,put}() but don't grab the kobject.
CRs-fixed: 366560
Change-Id: I23ea50a01793b2b2af0972cde52dba7396925fe3
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The demand based switching responds to input events and schedules
work items on all online cpus to increase the frequency. This will
call the dbs_refresh_callback on respective cpu. If this work item
kicks in while cpu1 is progressing its way through cpufreq_add_dev,
there is a chance that work item grabs the cpu_policy_rwsem of cpu1
and relases that of cpu0, when add device is working through releas-
ing lock of cpu1 and reaquiring that of cpu0. This is locking out
cpu1 when it tries to come up online next time. The fix is hold the
hot plug lock while processing refresh work items.
CRs-Fixed: 362444
Change-Id: I57db7c7a9b58369bf059302896f3bf9eca2bc2bb
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
Current code assumes that all online CPUs runs their own timers to
collect CPU samples for demand based switching (dbs). But in case of
synchronous CPUs, ondemand governor registers only one timer at init
time because both CPUs are accounted in the same timer call. Hence
trying to restart/cancel dbs timers for all online CPUs is not legal
for these CPUs. This change fixes above function to restart/cancel
timers only once for group of synchronous CPUs.
Change-Id: I23f1697783a65f125679a07a076620e8fa5e62d5
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
Original ondemand powersave_bias parameter allows value
range from 0 (no powersave) to 1000 (100% reduction in
calculated CPU frequency). This change extends powersave_bias
into the negative range (-1 to -1000) to allow a corresponding
boost to CPU frequency. When set at either limit (-1000 or
1000), ondemand timer is cancelled as periodic load
sampling at sampling_rate is not necessary.
Change-Id: I2ee05729ceec20c2e2a4c6d9ca05cecd16ab161a
Signed-off-by: David Ng <dave@codeaurora.org>
When an input event and CPU1 hotplug occurs at the same
time, a race condition can happen between cpufreq and
cpu hotplug resulting in a kernel panic.
When a hotplug operation is underway on CPU1,
__cpufreq_remove_dev is called. __cpufreq_remove_dev gets
the lock, proceeds to free the policy info of the current
governor and calls the ondemand governor with a STOP event.
If an input event occurs around the same time, it waits
for __cpufreq_remove_dev to release the lock. Meanwhile,
the ondemand governor clears some of its settings, but
fails to clear its local current policy. As soon as the
input event handler acquires the lock, it now uses the
invalid ondemand current policy handle to make frequency
changes. This results in a kernel panic.
Skip making frequency changes if this condition happens.
CRs-fixed: 327622,319348
Change-Id: I78227352fc66cc3ec5ab095c45eda76a92d1ba46
Signed-off-by: Anitha Anand <anithas@codeaurora.org>
When input handler is running on a CPU not in ondemand
governor, skip making CPU frequency changes.
CRs-Fixed: 299451
Change-Id: I9fe1ac3432d7b1613d1e3766e86160e4fe61d6ec
Signed-off-by: David Ng <dave@codeaurora.org>
Previously, only the first CPU in an SMP system was bumped to the
maximum clock when receiving an input event. This worked fine on
uniprocessor systems or scenarios were other CPUs tended to be
powered down. In other situations, it is better to bump up the
clocks of all CPUs that are online. This will not affect the
situations mentioned above, but it will help others.
Change-Id: Id51ebefe57ada56cefb8474cdbfebe1230432680
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
Make sure that only a single input handle is registered for the
ondemand governor. Force the input handler to run on cpu0 so it
will not be migrated due to cpu hotplug.
Change-Id: Ic72c34355c629da01290cf1a5e81d534aaf83d86
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
This will cause switch to maximum opp immediately when user
interaction occurs, i.e. touchscreen input or keypad activity.
Change-Id: I0cfe32479ef62a967f359c1bf57f97eefde7e8f7
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Jouni Hogander <jouni.hogander@nokia.com>
[bsteuer@quicinc.com: fixed cpu_dbs_info naming, added header]
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
The down_differential parameter determines the down threshold for
the governor to scale down the frequency and when made configurable
provides for a variable operating range for the governor.
Usage:
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/down_differential
echo 30 >
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/down_differential
Change-Id: Ice94b8ae961aa3df7f9582c2af2275414931faed
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
Wakeup userspace poll on change of cpu frequency. The userspace
may then take action to change the power/performance
characteristics of the device.
Change-Id: I3030b22084fe7e0143b978a198ddcc579e7d6e83
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
In addition to restoring the previous governor after hotplug, restore
policy min and max frequencies.
CRs-fixed: 277482
Change-Id: I0d29281cecf4bd14ede06cd97d7bd3bffd0652c0
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
A userspace module programs different qos-rules depending on the
governor running in the system. Make the governor node
pollable, so that the userspace module can be triggered when
the value of the governor changes.
change-Id: Ic89c77c7d16b0f8954d59a211612e9a8e98a2c28
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Understanding system load as seen by cpufreq can help userspace
algorithms make better decisions to improve system responsiveness.
One such example would be the MP decision algorithm which mines
various system info to make decisions on hotplugging in/out
the additional cores.
Change-Id: I277db7e1a7803a3822b61e7befa25131487cfe17
Signed-off-by: Anitha Anand <anithas@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The 'msm-dcvs' CPUFreq governor interfaces the msm_dcvs driver frequency
change requests with the CPUFreq framework.
Change-Id: I950e5b09f568412760d9b022f59f208c6bcb54ce
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Fix NR_IPI to be 7 instead of 6 because both googly and core add
an IPI.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Conflicts:
arch/arm/Kconfig
arch/arm/common/Makefile
arch/arm/include/asm/hardware/cache-l2x0.h
arch/arm/mm/cache-l2x0.c
arch/arm/mm/mmu.c
include/linux/wakelock.h
kernel/power/Kconfig
kernel/power/Makefile
kernel/power/main.c
kernel/power/power.h