summaryrefslogtreecommitdiff
path: root/drivers/cpufreq (follow)
Commit message (Collapse)AuthorAge
...
* | | qcom-cpufreq: Use new cpufreq_freq_transition_begin/end() APIJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | qcom-cpufreq: Rename cpufreq_suspend to suspend_dataJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | qcom-cpufreq: Remove save/restore of scheduling policyJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Restore CPU frequency during resumeJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | qcom-cpufreq: Remove per-cpu workqueueJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | arm: msm: Remove MSM_CPU_FREQ_SET_MIN_MAX related configJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: Add snapshot of qcom-cpufreq driverStephen Boyd2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | cpufreq: cpu-boost: Move CPU_BOOST Kconfig to correct sectionJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | cpu-boost driver is not a CPUFreq device. Moving it to the end of CPUFreq governor section. Change-Id: Ib433f81e7596789a2e6ea03d0bd0a8d166ecf9e9 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | | cpufreq: cpu-boost: Force most/all tasks to big cluster on input eventRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scheduler provides an API to force tasks to the big cluster. To improve performance, use this API to move most/all tasks to the big cluster for short duration on an input event. On the removal of frequency boost (after input_boost_ms), this scheduler boost is also deactivated. Change-Id: I9d643914ebc75266478cc22260a45862faad6236 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | sched: window-stats: Enhance cpu busy time accountingSrivatsa Vaddagiri2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rq->curr/prev_runnable_sum counters represent cpu demand from various tasks that have run on a cpu. Any task that runs on a cpu will have a representation in rq->curr_runnable_sum. Their partial_demand value will be included in rq->curr_runnable_sum. Since partial_demand is derived from historical load samples for a task, rq->curr_runnable_sum could represent "inflated/un-realistic" cpu usage. As an example, lets say that task with partial_demand of 10ms runs for only 1ms on a cpu. What is included in rq->curr_runnable_sum is 10ms (and not the actual execution time of 1ms). This leads to cpu busy time being reported on the upside causing frequency to stay higher than necessary. This patch fixes cpu busy accounting scheme to strictly represent actual usage. It also provides for conditional fixup of busy time upon migration and upon heavy-task wakeup. CRs-Fixed: 691443 Change-Id: Ic4092627668053934049af4dfef65d9b6b901e6b Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org> Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [joonwoop@codeaurora.org: fixed conflict in init_task_load(), se.avg.decay_count has deprecated.] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* | | sched: Introduce CONFIG_SCHED_FREQ_INPUTSrivatsa Vaddagiri2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a compile time flag to enable scheduler guidance of frequency selection. This flag is also used to turn on or off window-based load stats feature. Having a compile time flag will let some platforms avoid any overhead that may be present with this scheduler feature. Change-Id: Id8dec9839f90dcac82f58ef7e2bd0ccd0b6bd16c Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org> [rameezmustafa@codeaurora.org]: Port to msm-3.18] Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [joonwoop@codeaurora.org: fixed minor conflict around sysctl_timer_migration.] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* | | cpufreq: cpu-boost: Use one work to remove input boost for all CPUsRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each CPU queues up its own work for removing input boost. This is not really required as boost removal for all the CPUs can be done at the same time. So this patch uses a single work to remove input boost for all the CPUs and updates the policy for the online ones. Change-Id: I37c809f2f155548b1d8c1b9aa7626c8852b3acc6 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | cpufreq: cpu-boost: Support separate input_boost_freq for different CPUsJunjie Wu2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Different types of CPUs could have different frequency to satisfy same input workload. Add support for using different input_boost_freq on different CPUs. input_boost_freq now either takes a single number which applies to all CPUs, or cpuid:freq pairs separated by space for different CPUs. Change-Id: I20506a9fbdb4d532d94168bbd61744595bebc8e5 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | | cpufreq: cpu-boost: Make the code 64 bit compatibleRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the pointers' size change to 64 bits in the 64 bit kernel, the int declarations for them from the legacy code give compilation warnings which get flagged as errors. Replace int casting of pointers with long to get rid of these warnings. Change-Id: I96b6cf342c2bf110220eac0addfb72fbdd969c6e Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | cpufreq: cpu-boost: Use interruptible wait to not affect load averageSwetha Chikkaboraiah2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the function wait_event in cpu_boost puts the process enter to 'D' state which contribute to the high load average. This change will put the process boost_sync in the 'S' state (interruptible sleep) Change-Id: Ie121adbe1fac1d2862ac5342bb97c7c926f7d7a8 CRs-Fixed: 655484 Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org> Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
* | | cpufreq: cpu-boost: Consider only task load to decide on sync frequencyGirish S Ghongdemath2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we take the maximum between the source CPU frequency and the calculated frequency based on the migrating task load to decide on the frequency to sync the destination CPU to. This was done to handle short bursts in workloads of tasks which migrated immediately after causing a ramp up on the source CPU. Since their load history wasn't high enough, the destination CPU synced to a lower frequency which wasn't sufficient for the spike in workload. But as such cases are rare, taking the higher of source and calculated frequency can lead to destination CPU unnecessarily spending a considerable amount of time at higher frequencies which in turn can hurt power. With this change we make sure only the migrating task load is used to calculate the sync frequency for destination CPU when load based syncing is enabled. Change-Id: Ib1489d256c42ea7712aad2179aebffc87c549836 Signed-off-by: Girish Ghongdemath <girishsg@codeaurora.org>
* | | cpufreq: cpu-boost: Handle wakeup hints received for foreground tasksRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A previous change modifies the notification conditions in the scheduler to call the notifier chain even on foreground_thread wakeups for tasks having load more than a threshold value. If load_based_syncs is turned OFF then we do not need to perform cpu boost for wakeup hints for foreground tasks from scheduler Change-Id: Ifbdd3eccac5c9892dfc3a3c3edbfc0df766478ed Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | cpufreq: cpu-boost: Introduce scheduler assisted load based syncsRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, on getting a migration notification cpu-boost changed the scaling min of the destination frequency to match that of the source frequency or sync_threshold whichever was minimum. If the scheduler migration notification is extended with task load (cpu demand) information, the cpu boost driver can use this load to compute a suitable frequency for the migrating task. The required frequency for the task is calculated by taking the load percentage of the max frequency and no sync is performed if the load is less than a particular value (migration_load_threshold).This change is beneficial for both perf and power as demand of a task is taken into consideration while making cpufreq decisions and unnecessary syncs for lightweight tasks are avoided. The task load information provided by scheduler comes from a window-based load collection mechanism which also normalizes the load collected by the scheduler to the max possible frequency across all CPUs. Change-Id: Id2ba91cc4139c90602557f9b3801fb06b3c38992 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org> [rameezmustafa@codeaurora.org]: Port to msm-3.18] Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [joonwoop@codeaurora.org: fixed conflict in __migrate_task().] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* | | cpufreq: cpu-boost: Re-issue boosts above minimum frequencyPatrick Cain2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Frequency boosts where the source CPU frequency is greater than CPU's minimum frequency should always go through regardless of the destination CPU's current frequency. This fixes a performance issue where the governor lowers the CPU frequency shortly after a thread is migrated to it because the boost wasn't re-issued. Change-Id: I449545a688d84b0a6e834f5a51dcb499caa84d29 Signed-off-by: Patrick Cain <pcain@codeaurora.org>
* | | cpufreq: cpu-boost: Don't register for cpufreq notifiers too earlySaravana Kannan2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq notifiers should be registered only after all the data structures used in the notifier callbacks have been initialized. So, move the cpufreq notifier registration to a later point in the init function. Change-Id: I043ab5bc0ebb98164c40549fe151a8d801c8c186 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
* | | cpufreq: cpu-boost: Fix deadlock in wake_up of sync threadsSaravana Kannan2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If wake_up() is called on the current task on a CPU, the call will wait until the current task is switched out before it wakes it up again and returns. The sync notifier for a CPU always runs on that CPU. These two together can result in a deadlock if the sync notifier on CPU A tries to wake up the sync thread of CPU A as it goes to sleep (is the current task). A previous commit fixed this by adding a check to the sync notifier to not wake up the sync thread of CPU A if it's the current task. But this is still not sufficient to prevent deadlocks. Sync thread of CPU A could be the current task on CPU B and sync thread of CPU B could be the current task on CPU A. At this point, if sync notifier of CPU A and B try to wake up the sync threads of CPU A and B, it will result in CPU A waiting for the current task in CPU B to get switched out and CPU B waiting for the current task in CPU A to get switched out. This will result in a deadlock. Prevent this scenario from happening by pinning the sync threads of each CPU to run on that CPU. By doing this, we guarantee that sync notifiers will only try to wake up sync threads running on that CPU. The fix added by "cpufreq: cpu-boost: Resolve deadlock when waking up sync thread" ensures a deadlock doesn't happen when a sync notifier tries to wake up a sync thread running on that CPU. Change-Id: I864e545529722a23886dd5a82f66089155d2d193 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
* | | cpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplugSaravana Kannan2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling queue_delayed_work_on() on a CPU that's in the process of getting hotplugged out can result in that CPU infinitely looping in msm_pm_wait_cpu_shutdown(). If queue_delayed_work_on() is called after the CPU is hotplugged out, it could wake up the CPU without going through the hotplug path and cause instability. To avoid this, make sure the CPU is and stays online while queuing a work on it. Change-Id: I1b4aae3db803e476b1a7676d08f495c1f38bb154 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
* | | cpufreq: cpu-boost: Resolve deadlock when waking up sync threadSrivatsa Vaddagiri2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CPU boost driver receives notification from scheduler when threads migrate towards a cpu and in turn wakes up a sync thread associated with that cpu to handle any required frequency transitions. The wakeup call however can lead to a deadlock inside scheduler under some circumstance. The deadlock is seen when sync thread is the only thread running on a cpu and goes to sleep (say by calling wait_event() -> schedule()). Midway through this sleep (schedule()) call, while cpu is still running in context of sync thread, scheduler attempts a load balance (realizing that cpu is about to become idle) which can result in tasks being migrated towards the cpu going idle. This will cause migration notification to be issued and in turn a wakeup on sync thread. The wakeup call however gets stuck in below while() loop inside scheduler: try_to_wake_up(struct task_struct *p, ...) { /* * If the owning (remote) cpu is still in the middle of * schedule() with this task as prev, wait until its done * referencing the task. */ while (p->on_cpu) cpu_relax(); } A possible fix could be to teach try_to_wake_up() about this special case. Another fix, implemented in this patch and that helps minimize scheduler changes, is to have cpu boost driver not issue a wakeup under this special circumstance, which was found to occur very infrequently. Change-Id: I92bc68a22d51595a208673fe2a1eedfa97004f9e Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
* | | cpufreq: Add Input Boost feature to the cpu-boost driverRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | On incoming input events boost the frequency of all online cpus for at least input_boost_ms ms. This is accomplished by changing the policy->min of all the online cpus to input_boost_freq. Change-Id: Idb0ab75d68ae4ceff259cbbaaec1a9bb3bc871d3 Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | cpufreq: Add a sync limit to cpu-boostRohit Gupta2016-03-23
| | | | | | | | | | | | | | | | | | | | | | | | Perform frequency synchronization only when source CPU's frequency is less than sync_threshold, else sync to the sync_threshold. Change-Id: I544c414568d4e015b80ce5891dd215275bac95da Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | | cpufreq: cpu-boost: Add cpu-boost driverSaravana Kannan2016-03-23
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When certain bursty and important events take place, it might take a while for the current cpufreq governor to notice the new load and react to it. That would result in poor user experience. To alleviate this, the cpu-boost driver boosts the frequency of a CPU for a short duration to maintain good user experience while the governor catches up. Specifically, this commit deals with ensuring that when "important" tasks migrate from a fast CPU to a slow CPU, the frequency of the slow CPU is boosted to be at least as high as the fast CPU for a short duration. Since this driver enforces the boost by hooking into standard cpufreq ADJUST notifiers, it has several advantages: - More portable across kernel versions where the cpufreq internals might have been rewritten. - Governor agnostic and hence works with multiple governors like conservative, ondemand, interactive, etc. - Does not affect the sampling period/logic of existing governors. - Can have the boost period adjusted independent of governor sampling period. Change-Id: Ibd814a20043d0aba64ee7637a4a79b9ffa1b0991 Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [rameezmustafa@codeaurora.org]: Port to msm-3.18] Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [joonwoop@codeaurora.org: fixed conflict in drivers/cpufreq/Kconfig.] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
* | android: skip building drivers as modulesAmit Pundir2016-02-16
| | | | | | | | | | | | | | | | | | | | | | Few Android drivers e.g. uid_cputime and PPPoLAC/oPNS, keyreset/combo, cpufreq_interactive etc.. fail to build as kernel modules. Instead of fixing the build lets make these drivers non-modular (switch config to "bool" from "tristate" in Kconfig) since Android doesn't support building kernel modules anyway. Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* | trace: cpufreq: Add tracing for min/max cpufreqRuchi Kandoi2016-02-16
| | | | | | | | | | Change-Id: I73f6ec437c1f805437d9376abb6510d1364b07ec Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
* | subsystem: CPU FREQUENCY DRIVERS- Set cpu_load calculation on current frequencyrahul.khandelwal2016-02-16
| | | | | | | | | | | | | | | | | | | | | | In timer, cpu_load is calcuated on target_freq. cpu_load = loadadjfreq / pcpu->target_freq; But cpu is actually running on current freq i.e. pcpu->policy->cur. So cpu_load should be calculated on current frequency. cpu_load = loadadjfreq / pcpu->policy->cur; Change-Id: I89db6b68e9f82aa52077f6bf7d819dab74265790 Signed-off-by: rahul.khandelwal <rahul.khandelwal@spreadtrum.com>
* | cpufreq: interactive: build fixes for 4.4Amit Pundir2016-02-16
| | | | | | | | | | | | | | | | Bring back cpufreq_{get,put}_global_kobject() definitions removed by upstream commit 8eec1020f0c0 "cpufreq: create cpu/cpufreq at boot time" to fix build failures. Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* | cpufreq: interactive: replace strict_strtoul() with kstrtoul()Amit Pundir2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | strict_strtoul() is obsolete. Use kstrtoul() instead. Otherwise we run into following build error: CC drivers/cpufreq/cpufreq_interactive.o drivers/cpufreq/cpufreq_interactive.c: In function ‘store_hispeed_freq’: drivers/cpufreq/cpufreq_interactive.c:784:2: error: implicit declaration of function ‘strict_strtoul’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [drivers/cpufreq/cpufreq_interactive.o] Error 1 Change-Id: Ib91b9df3af5fe2a244861c2f598bd20ec8115e6c Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* | cpufreq: interactive: Rearm governor timer at max freqRohit Gupta2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interactive governor doesn't rearm per-cpu timer if target_freq is equal to policy->max. However, this does not have clear performance benefits. Profiling doesn't show any difference in benchmarks, games or other workloads, if timers are always rearmed. At same time, there are a few issues caused by not rearming timer at policy->max. 1) min_sample_time enforcement is inconsistent For target frequency that is lower than policy->max, it will not drop until min_sample_time has passed since last frequency evaluation selected current frequency. However, for policy->max, it will always drop immediately as long as CPU has been run for longer than min_sample_time. This is because timer is not running and thus floor_freq and floor_validate_time is not updated. Example: assume min_sample_time is 59ms and timer_rate is 20ms. Frequency X < Y. Let's say CPU would pick the following frequencies before accounting for min_sample_time in each 20ms sampling window. Y, Y, Y, Y, X, X, X, X, X If Y is not policy->max, the final target_freq after considering min_sample_time will be Y, Y, Y, Y, *Y, *Y, X, X, X * marks the windows where frequency is prevented from dropping. If Y is policy->max, the final target_freq will be Y, Y, Y, Y, X, X, X, X, X 2) Rearm timer in IDLE_START does not work as intended IDLE_START/END is sent in arch_cpu_idle_enter/exit(). However, next wake up is decided in tick_nohz_idle_enter(), which traverses the timer list before idle notification is sent out. Therefore, rearming timer in idle notification won't take effect until CPU wakes up at least once. In rare scenarios when a CPU goes to idle and sleeps for a long time immediately after a heavy load stops, it may not wake up to drop its frequency vote for a long time, defeating the purpose of having a slack_timer. 3) Need to rearm timer for policy->max change commit 535a553fc1c4b4c3627c73214ade6326615a7463 (cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS) mentions the problem of timer getting indefinitely pushed back due to frequency changes in policy->min/max. However, it still cancels and rearms timer if policy->max is increased, and same problem could still happen if policy->max is frequently changing after the fix. The best solution is to always rearm timer for each CPU even if it's running at policy->max. Rearming timers even if target_freq is policy->max solves these problems cleanly. It also simplifies the design and code of interactive governor. Change-Id: I973853d2375ea6f697fa4cee04a89efe6b8bf735 Reviewed-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Junjie Wu <junjiew@codeaurora.org> Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
* | cpufreq: interactive: Implement cluster-based min_sample_timeJunjie Wu2016-02-16
| | | | | | | | | | | | | | | | | | | | | | min_sample_time needs to be cluster-based to match above_hispeed_delay. If each CPU keeps making local decisions, it's possible min_sample_time is not correctly enforced at cluster level, which results in undesired frequency drops. Change-Id: Ia2ec2ad9b7a8d715d4408c924d6762b7e532e4b4 Reviewed-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | cpufreq: interactive: Exercise hispeed settings at a policy levelSaravana Kannan2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a heavy task migrates between otherwise idle CPUs in a policy during every sample window, the above hispeed delay window for the CPUs would get restarted for every sample window. Due to the continuous restart of above hispeed delay window, none of the CPUs would ever pick a target frequency higher than hispeed frequency. This causes the policy's frequency to be stuck at hispeed freq even if the load justifies a higher frequency. To fix this, the above high speed delay window is restarted only when the policy frequency changes. This ensures that tasks migrating between CPUs in a policy are handled correctly. Also, the hispeed load/frequency heuristic is only necessary when the information is insufficient to determine if the load on the CPU needs at least hispeed frequency. When the policy frequency is already at or above hispeed frequency, if the CPU load% based on policy frequency is not above hispeed load, then the information is clearly sufficient to determine that the load on the CPU does not need hispeed frequency. Therefore, compute CPU load% (which is used only to compare against hispeed load) based on policy frequency instead of CPU target frequency. Change-Id: I8b5dfe6c50bee567a6719f0980e3f7757876ce4b Signed-off-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | cpufreq: interactive: Round up timer_rate to match jiffyJunjie Wu2016-02-16
| | | | | | | | | | | | | | | | Timers are scheduled in unit of jiffies. Round up timer_rate so that it matches the actual sampling period. Change-Id: I88386a5a448e40333f9a9b9f0cf72af58cb54656 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | cpufreq: interactive: Don't set floor_validate_time during boostJunjie Wu2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Frequency selection algorithm guarantees its chosen frequency is not lower than hispeed_freq as long as boost is enabled. Setting floor_freq and floor_validate_time during boost could block CPU frequency from going below hispeed_freq even after boostpulse_duration expires, if min_sample_time is higher than boostpulse_duration. This conflicts with the intention of commit de091367ead15b6e95dd1d0743a18f0da5a07ee5 (cpufreq: interactive: specify duration of CPU speed boost pulse) to allow CPU to ramp down immediately after boost expires. It also makes boost behavior inconsistent since it depends on min_sample_time. Avoid setting floor_freq and floor_validate_time when boost starts. Change-Id: I12852998af46cfbfaf8661eb5e8d5301b6f631e7 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | cpufreq: interactive: Put global cpufreq kobject on failureJunjie Wu2016-02-16
| | | | | | | | | | | | | | | | | | Fix failure recovery path in cpufreq_governor_interactive(). Call cpufreq_put_global_kobject() to release cpufreq global kobject upon governor init failure. Change-Id: I7a977070b7a3c75c90acccd2c117064ed1a10d0e Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
* | cpufreq: interactive: only boost tunable affected cpusLianwei Wang2016-02-16
| | | | | | | | | | | | | | | | It is not correct to boost all the cpus when tunable boost parameters are changed. It also does not need to boost the cpus which is already boosted. Signed-off-by: Lianwei Wang <a22439@motorola.com>
* | cpufreq: interactive: don't skip waking up speedchange_task if target_freq > ↵Minsung Kim2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | policy->cur When __cpufreq_driver_target() in speedchange_task failed for some reason, the policy->cur could be lower than the target_freq. The governor misses to change the target_freq if the target_freq is equal to the next_freq at the next sample time. Added a check to prevent the CPU to stay at the speed that is lower than the target_freq for long duration. Change-Id: Ibfdcd193b8280390b8f8374a63218aa31267f310 Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
* | cpufreq: interactive: make common_tunables staticCylen Yao2016-02-16
| | | | | | | | | | | | | | common_tunables should be static. Change-Id: I502ee3062bece5082fea7861eff2f6237e25cede Signed-off-by: Todd Poynor <toddpoynor@google.com>
* | cpufreq: interactive: prevents the frequency to directly raise above the ↵Ruchi Kandoi2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hispeed_freq from a lower frequency. When the load was below go_hispeed_load, there is a possibility that choose_freq() would return a frequency which would be higher than the hispeed_freq. According to the policy we should first jump to the hispeed_freq, stay there for above_hispeed_delay and then be allowed to raise higher than that. Added a check to prevent the frequency to be directly raised to something higher than the hispeed_freq. Change-Id: Icda5d848dd9beadcc18835082ddf269732c75bd0 Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
* | cpufreq: interactive: remove compilation error from commit ↵Ruchi Kandoi2016-02-16
| | | | | | | | | | | | | | 49cc72365fb7ee87762a7ccc6a32ef68627216c5 Change-Id: I068b18281d03ac879ef64d8ff36ed43367293767 Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
* | cpufreq: interactive: turn boost_pulse off on boost offRuchi Kandoi2016-02-16
| | | | | | | | | | Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
* | cpufreq: interactive: restructure CPUFREQ_GOV_LIMITSBadhri Jagan Sridharan2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | The cpufreq_interactive_timer gets cancelled and rescheduled whenever the cpufreq_policy is changed. When the cpufreq policy is changed at a rate faster than the sampling_rate of the interactive governor, then the governor misses to change the target frequency for long duration. The patch removes the need of cancelling the timers when policy->min is changed. Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com> Change-Id: Ibd98d151e1c73b8bd969484583ff98ee9f1135ef
* | cpufreq: interactive: hold reference on global cpufreq kobject if neededGreg Hackmann2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 2361be23666232dbb4851a527f466c4cbf5340fc changed cpufreq to add the global cpufreq kobject to sysfs on demand. To ensure this happens, cpufreq_interactive must hold a reference on this object on devices where it intends to use it (i.e., devices where have_governor_per_policy() returns false). Otherwise a parentless kobject will be passed to sysfs_create_group() which will subsequently BUG(). Change-Id: I7dd03956e1d3c6c3c0cc17c799882c235804ae09 Signed-off-by: Greg Hackmann <ghackmann@google.com>
* | cpufreq: interactive: Use generic get_cpu_idle_time() from cpufreq.cViresh Kumar2016-02-16
| | | | | | | | | | | | | | | | | | | | Now that a generic version of get_cpu_idle_time() is available, use that for the interactive governor. [toddpoynor@google.com: commit text changes] Change-Id: Ia38b57085aac99ec3d415fe44471d5dfde519c2c Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org>
* | cpufreq: interactive: fix NULL pointer dereference at sysfs opsMinsung Kim2016-02-16
| | | | | | | | | | | | | | | | | | sysfs ops for target_loads and above_hispeed_delay can be called before initializing tunables at CPUFREQ_GOV_POLICY_INIT. Create sysfs entries after initialization. Change-Id: I50356198d7629731c0d32a3066d61fe8354e0001 Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
* | cpufreq: interactive: fix compiling warningsChih-Wei Huang2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gcc warns like: cpufreq_interactive.c:745:6: warning: operation on 'ret' may be undefined [-Wsequence-point] It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf. Since sprintf(...) just return 1 (one character) in this case, ret should not changed. Just discarding the result of sprintf(...) leads to the result that the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants. Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57 Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
* | cpufreq: interactive: delete timers for GOV_STARTShridhar Rasal2016-02-16
| | | | | | | | | | | | | | | | | | Make sure that timers cpu_timer and cpu_slack_timer deactivated before addition of new. Change-Id: If31c4049606871df6f00efdc24b1d713c86a6f69 Signed-off-by: Shridhar Rasal <srasal@nvidia.com> Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
* | cpufreq: Interactive: Implement per policy instances of governorViresh Kumar2016-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a multi-package system, where we have multiple instances of struct policy (per package), currently we can't have multiple instances of same governor. i.e. We can't have multiple instances of Interactive governor for multiple packages. This is a bottleneck for multicluster system, where we want different packages to use Interactive governor, but with different tunables. This patch uses the infrastructure provided by earlier patches pushed in Mainline in v3.10-rc1/rc2 and implements per policy instances of Interactive governor. Change-Id: I70436d4a5a45c6cb6edf37f3e46d0b9fbc930982 [toddpoynor@google.com: merge with later code, minor changes] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-28 19:36:36 +0000