msm: hotplug: Optimize latencies

Before this patch it took the algorithm too long to
react on sudden load spikes, although only noticable
in benchmarks. We would cycle 5-6 times until the
buffer average was finally high enough to trigger a
new target.  Improve latencies by instantly onlining
all cpus if current load on any cpu is above a certain
threshold.

fast_lane_load should not be higher than 78 as load
per cpu won't be above this value in our metric.

First cycle in hackbench
Before: 1.253sec
After: 0.796sec

Conflicts:
	arch/arm/mach-msm/msm_hotplug.c
msm: hotplug: Refactor load calculation

* Move core load calculations to this file and optimize.
* Calculate load based on current policy->max, not cpuinfo.max_freq
  which explains the strange 78% maximum load value before.
* Recalculate thresholds and fast_lane_load accordingly.
* Cleanup some ambiguous namings and other minor stuff.
* EXPORT_SYMBOL_* is useless for static functions.
msm_hotplug:sync with myfluxi
msm: thermal: Limit maximum cpu frequency instantly.

If current policy's max cpu frequency is below the maximum
possible frequency, instead of wasting time cycling through
indices, we are now limiting maximum cpu frequency instantly.
However, if limits are changed manually during throttling,
the logic may be confused.

Also, cleanup some kmsg info spam in the process.

Conflicts:
	arch/arm/mach-msm/include/mach/cpufreq.h
cpufreq: add new routine cpufreq_verify_within_cpu_limits()

Most of the users of cpufreq_verify_within_limits() calls it for
limiting with min/max from policy->cpuinfo. We can make that code
simple by introducing another routine which will do this for them
automatically.

This patch adds another routine cpufreq_verify_within_cpu_limits()
and updates others to use it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Conflicts:
	arch/arm/mach-msm/msm_hotplug.c