debug remove
cpufreq: interactive: tune
cpufreq: interactive: Fix null pointer dereference in interactive governor

For the sync_freq feature currently we check pcpu->policy->cur frequency
for each online cpu.  But for a CPU that isn't using interactive governor
or for an offline CPU, pcpu->policy can be null or an invalid value.
This patch tries to avoid that scenario by using pcpu->target_freq
instead of policy->cur to get the frequency of an online CPU.

Kernel crash without this patch:
[   20.132373] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[   20.132375] pgd = c34f34c0
[   20.132377] pgd = ef6f2440
[   20.132383] [00000028] *pgd=00000000
[   20.132385]
[   20.132388] [00000028] *pgd=2e98f003, *pmd=00000000
[   20.132390] Internal error: Oops: 205 [#1] PREEMPT SMP ARM
[   20.132394] Modules linked in:
[   20.132398] CPU: 0 PID: 1560 Comm: chown Tainted: G        W    3.10.0-perf-gb12057b-00001-ga2c6c16-dirty #7
[   20.132401] task: ef9af300 ti: ee49c000 task.ti: ee49c000
[   20.132411] PC is at cpufreq_interactive_timer+0x10c/0x650
[   20.132415] LR is at cpufreq_interactive_timer+0x128/0x650
<snip>
[   20.133002] [<c07eb204>] (cpufreq_interactive_timer+0x10c/0x650) from [<c02804d8>] (call_timer_fn+0x80/0x198)
[   20.133012] [<c02804d8>] (call_timer_fn+0x80/0x198) from [<c0280acc>] (run_timer_softirq+0x1f8/0x270)
[   20.133019] [<c0280acc>] (run_timer_softirq+0x1f8/0x270) from [<c0279e20>] (__do_softirq+0x12c/0x2d4)
[   20.133025] [<c0279e20>] (__do_softirq+0x12c/0x2d4) from [<c027a2d4>] (irq_exit+0x74/0xc8)
[   20.133034] [<c027a2d4>] (irq_exit+0x74/0xc8) from [<c0206a00>] (handle_IRQ+0x68/0x8c)
[   20.133041] [<c0206a00>] (handle_IRQ+0x68/0x8c) from [<c02004b8>] (gic_handle_irq+0x3c/0x60)
[   20.133051] [<c02004b8>] (gic_handle_irq+0x3c/0x60) from [<c0ac6900>] (__irq_svc+0x40/0x70)
<snip>

Signed-off-by: Vijay Ganti <viganti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: delete timers for GOV_START

Make sure that timers cpu_timer and cpu_slack_timer
deactivated before addition of new.

Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
[mattw@codeaurora.org: resolved trivial context conflict]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: don't schedule timer on offline cpu

It shall not add timer on an offline CPUs, else it will cause
kernel panic.

And also don't reschedule the timer on an offline cpu in idle
and timer callback. Actually the timer shall be cancelled when
cpu is offline.

Signed-off-by: Lianwei Wang <a22439@motorola.com>
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
[ljc: formatting to use cpufreq_interactive_timer_start()]
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: cpu-boost: Don't register for cpufreq notifiers too early

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.

Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: cpu-boost: match CAF
cpufreq: Sync on thread migration optimizations

When threads migrate between CPUs the destination CPU will temporarily
have a boosted frequency and the source CPU will have a residual higher
frequency even though the load could have just been reduced. To avoid
leaving CPUs at a high frequencies notify the source CPU after a thread
migration and make the interactive governor's timer reschedule
conditionally.

Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Don't reset sampling down factor at max freq

A previous patch sets the min_sample_time to zero if the cpufreq
min/max limits have changed which would bring down the frequency
in the next sample even if min_sample_time doesnt allow it to do so.
This could severly affect benchmarks if this is applied to max
frequencies as min_sample_time for max frequencies is set to
sampling_down_factor.
This patch resets the limits_changed flag for cases where timer fires
while running at max frequencies so that sampling_down_factor is
still applicable as before.

Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: turn boost_pulse off on boost off

Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Optimize sync_freq implementation

Don't let frequency drop below sync_freq if either load or
frequency among other cpus is above a certain threshold,
not necessarily both.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: interactive: Revert timer start modification
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

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>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>