Revert "Perf: Reset pmu after hotplug"

This reverts commit 48044bb396e2d313385e020cb5a1fbbccf241e1a.
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.

Change-Id: I397133cb15eea4ab999d0f69617b4922438c6e11
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: Remove unnecessary cpu_online() check

Cpufreq no longer calls governor callback for offlined cpus. i.e. All
policy->cpus are guaranteed to be online. Hence we don't need explicit check to
see if cpu is online or not.

Change-Id: I9ad85ea4addd5b4a40952e59ed730dd15e328690
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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.

Change-Id: Iada28e08e812498e16d5189b309a7314f88814dd
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>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
cpufreq: export the cpu load across cores to the policy struct. On Performance governor let's emulate a constant 100% load (in this Kernel's case it will make all cores online, which is kinda the purpose of a performance governor isn't it?).

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: interactive: q squash code from HH repo.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: this governor is fundamentally different from Ondemand and by norm its a bit more sensitive to load changes in terms of which freqs are chosen, but even though sometimes it can be a little stupid and non react to load changes that linearly as one could hope for (even though it's better than Ondemand) so for that reason let's try to use this new formula by @stratosk found in this commit: https://github.com/stratosk/kernel_msm/commit/9df03b662b9c213c75ac082138f5ab8afadb9d94 make sure you read his commit message for better understanding of this.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
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.

Change-Id: Ibd98d151e1c73b8bd969484583ff98ee9f1135ef
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Git-commit: 9b97d655a558607c5d46ef1f21365d695f8d1ee2
Git-Repo: https://android.googlesource.com/kernel/common.git
[junjiew@codeaurora.org: resolve merge conflicts]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: calculate the load based on max (which is volatile) and not cpuinfo.max_freq, which is always 3GHz.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Consider changed min limit a frequency boost

A changed policy->min can safely be considered a frequency boost.
Process this change analogous to the cpufreq_interactive_boost()
routine.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: Honor boosted state in several timer calculations

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: don't scale beyond min if the load is really low (<= 5).

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: reformat the calculation. Functionality is unchanged - purely asthetical

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>