u8500_hotplug: update cpufreq policies and hotplug cpus more appropriately

It is not guaranteed that cpu1 will be offline on suspend, etc. Also only online cpu1 after update cpufreq policy to follow suspend operations.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
u8500_hotplug: notify cpufreq only when actually updating

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
Revert "cpufreq: interactive: eliminate dead band effect in low load"

This reverts commit 49fe6eadab50018bc53b84b5c93471e3a715ac25.

We are not using extended cpufreq steps. We have only around 5 cpufreq steps to cover.
As this commit makes the governor more sensitive to load changes and thus scale cpufreqs more evenly,
we will most likely end up on higher frequencies than actually needed.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: choose the highest frequency at or below target frequency

Due to our limited frequency steps, the closest frequency to target is usually higher than needed.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: conservative: add support for micro idle accounting

Originally, mininum sample rate calculations assume that micro idle accounting is non-existent. This is incorrect. Thus, we can afford to set the minimum sample rate to lower levels. This should improve performance on conservative governor by a respectable amount.

With a more accurate and sensitive sample rates, we can afford to loosen up on frequency thresholds.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
nohz: Fix update_ts_time_stat idle accounting

update_ts_time_stat currently updates idle time even if we are in
iowait loop at the moment. The only real users of the idle counter
(via get_cpu_idle_time_us) are CPU governors and they expect to get
cumulative time for both idle and iowait times.
The value (idle_sleeptime) is also printed to userspace by print_cpu
but it prints both idle and iowait times so the idle part is misleading.

Let's clean this up and fix update_ts_time_stat to account both counters
properly and update consumers of idle to consider iowait time as well.
If we do this we might use get_cpu_{idle,iowait}_time_us from other
contexts as well and we will get expected values.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: Dave Jones <davej@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Link: http://lkml.kernel.org/r/e9c909c221a8da402c4da07e4cd968c3218f8eb1.1314172057.git.mhocko@suse.cz
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
cpufreq: conservative: Break out earlier on the lowest frequency

If we're on the lowest frequency, no need to calculate new freq.
Break out even earlier in this case.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[zwliew: adapt for 3.0]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: conservative: Fix relation when decreasing frequency

The relation should be CPUFREQ_RELATION_L to find optimal frequency
when decreasing.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[zwliew: Adapt for 3.0]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: conservative: Fix the logic in frequency decrease checking

When we evaluate the CPU load for frequency decrease we have to compare
the load against down_threshold. There is no need to subtract 10 points
from down_threshold.

Instead, we have to use the default down_threshold or user's selection
unmodified.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[zwliew: Adapt for 3.0]
Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
ux500_usb: driver updates
cpufreq: interactive: Re-add cpu_online() check on governor start

I believe cpufreq still calls this for all cpus, not just online cpus.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Uninitialise sync freq feature

This is too aggressive and will cause CPUs to increase frequencies prematurely.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
Revert "cpufreq: interactive: Allow 1 ms error in above_hispeed_delay comparisons"

This reverts commit ff6af80775231f1dfab8353d0b665718222218bf.

Commit ff6af807 tries to avoid a corner case where frequency is stuck in
hispeed_freq for one additional window. For example, if timer_rate is
20ms, and go_hispeed_delay is 40ms, frequency might be stuck at
hispeed_freq for 60ms due to imprecision in jiffies. Same problem can be
easily solved by making go_hispeed_delay 1ms smaller instead of changing
the code.

Change-Id: Idab7c29ed28374df219210e444454068864d144d
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Reset to latest CAF 3.10 branch

Between 3.4 branch and 3.10 branch, there were many changes.
Most of which, conflict with my previous changes. Thus, to
simplify things, I've decided to reset changes to 3.10 branch
with appropriate commits reverted to compile with 3.4. I will
probably re-add my changes afterwards.

The new 3.10 changes should make the governor more intelligent
in terms of scaling frequencies and CPU scheduling.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Re-add io_is_busy interface

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
u8500_hotplug: Fix max freq not capped on suspend bug (maybe)

Use a function to update cpufreq policy in order to prevent max freq from being overwritten during rapid suspend and resume.
cpufreq: interactive: Revert previous 2 commits

3.10 driver is causing random reboots. Revert until(or maybe if) I actually feel like testing.

Signed-off-by: zwliew <zhaoweiliew@gmail.com>
cpufreq: interactive: Don't max out when !go_hispeed_load

For sake of configurability and testing
cpufreq: interactive: Uninitialise sampling_down_factor

People's batteries die.
dm: suppress endian warnings

Suppress sparse warnings about cpu_to_le32() by using __le32 types for
on-disk data etc.

Signed-off-by: Alasdair G Kergon <agk@redhat.com>
(cherry picked from commit 283a8328ca5b987e547848de8ff0e28edcfb9e08)