ARM: mm: implement LoUIS API for cache maintenance ops

ARM v7 architecture introduced the concept of cache levels and related
control registers. New processors like A7 and A15 embed an L2 unified cache
controller that becomes part of the cache level hierarchy. Some operations in
the kernel like cpu_suspend and __cpu_disable do not require a flush of the
entire cache hierarchy to DRAM but just the cache levels belonging to the
Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
correspond to L1.

The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.

Therefore a new kernel cache maintenance API must be added to cope with
latest ARM system requirements.

This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

This function cleans and invalidates all data cache levels up to the
Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
cache for processors that support it (> v7).

This patch also creates an alias of the cache LoUIS function to flush_kern_all
for all processor versions prior to v7, so that the current cache flushing
behaviour is unchanged for those processors.

v7 cache maintenance code implements a cache LoUIS function that cleans and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: rename jump labels in v7_flush_dcache_all function

This patch renames jump labels in v7_flush_dcache_all in order to define
a specific flush cache levels entry point.

TODO: factor out the level flushing loop if considered worthwhile and
      define the input registers requirements.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update cpu_suspend code to use cache LoUIS operations

In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.

When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.

The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.

outer_cache management remains unchanged.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API

When a CPU is hotplugged out caches that reside in its power domain
lose their contents and so must be cleaned to the next memory level.

Currently, __cpu_disable calls flush_cache_all() that for new generation
processor like A15/A7 ends up cleaning and invalidating all cache levels
up to Level of Coherency, which includes the unified L2.

This ends up being a waste of cycles since the L2 cache contents are not
lost on power down.

This patch updates __cpu_disable to use the new LoUIS API cache operations.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API

The ARMv7 processor setup function __v7_setup() cleans and invalidates the
CPU cache before enabling MMU to start the CPU with a clean CPU local cache.

But on ARMv7 architectures like Cortex-[A15/A8], this code will end
up flushing the L2 caches(up to level of Coherency) which is undesirable
and expensive. The setup functions are used in the CPU hotplug scenario too
and hence flushing all cache levels should be avoided.

This patch replaces the cache flushing call with the newly introduced
v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
invalidated when a processors executes __v7_setup which is the expected
behavior.

For processors like A9 and A5 where the L2 cache is an outer one the
behavior should be unchanged.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
Revert "Intellidemand governor"

This reverts commit 8ceaec5cb6a1b57b0c3ea584b2f80998fa7d9d45.

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
	include/linux/cpufreq.h
cpufreq/cpufreq_intellidemand: intellidemand cpufreq governor (version 4.0)

Intellidemand is inspired by ondemand governor. Its main features are:

 - auto cpu hotplugging based on runnable thread average calculations
 - detection of browsing mode (long screen on activities with moderate run
   queue depth =< 45 )
 - limit max frequencies when in browsing mode to conserve battery for long
   duration tasks

Browsing State Determination:
 1- Browsing state is enabled as power-on default. Browsing state is disabled
    when run queue depth is > 45 (very high instantaneous spikes)

Browsing State Limit Max Freq Logic (sliding window algorithm):
 1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then
    CPU Max frequencies will remain power-on default
 2- While Screen is On, if average CPU load > 35%, both CPUs max frequencies
    will be limited to a lower user configurable max value
 3- While Screen is On, After both CPUs' Max is limited to lowered max, when
    the average CPU load has dropped down to less than < 25%, then both CPUs
    Max freq will be restored to back to power-on default

Runnable Thread Auto-hotplug (fast hotplug / slow unplug algorithm):
 1- When average number of running thread is < threshold, 2nd cpu will be
    unplugged.
 2- When > threshold, 2nd cpu will be hotplugged.
 3- The logic applies a fast hotplug and slow unplug algorithm so 2nd core
    will stay enabled longer to help deal with performance spikes

changes from Ver 2.0 -> Ver 3.0:
  - remove GPU Busy dependency for browsing state detection (this will make
    the governor more portable to other platforms without specific GPU
    architecture knowledge)

dependencies:
  -- Qualcomm's run queue average logic (SOC independent logic)
  -- TI's runnable thread average logic (SOC independent logic)

forward ported to Linux 3.4 for use on HTC One

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:
	arch/arm/mach-msm/board-m7.c
	arch/arm/mach-msm/cpufreq.c
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
	drivers/cpufreq/cpufreq.c
	include/linux/cpufreq.h
intellidemand: Add boost pulse capability

Boost pulse increases UI performance by increasing CPU freq and
reduce sampling time.

forward ported for Linux 3.4 for use on Mako
Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: add bug fixes

 - Fix crash input event handler on governor switch
 - Fix panic when setting sampling rate

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: add a run queue persistence to determine browsing state

persistence will allow for better browsing state detection rather than just
purely based on run queue depth alone

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: add minimum cpu performance lock

a minimum cpu frequency performance lock is add to ensure smooth
operations when only 1 core is active

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	drivers/cpufreq/Kconfig
Intellidemand: update for quadcore operations. bump version to 4.0

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: code derps clean up!

Signed-off-by: faux123 <reioux@gmail.com>
Intellidemand: put cores 1~3 to sleep while screen is off

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: increase boost duration to 2.5 seconds from 1.5

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: add eco mode (dual core operations) bump version to 4.1

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: tweak for not using min performance lock

Signed-off-by: faux123 <reioux@gmail.com>
Intellidemand: adjust the nr_run hysteresis for better UI response

Signed-off-by: faux123 <reioux@gmail.com>
cpufreq: Avoid using smp_processor_id() in preemptible context

Even though this work item runs on only one cpu at a time (due to
queue_work_on()) it is possible for the work item to be preempted
and so use of smp_processor_id() is illegal.

BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/3:1/4162 caller is dbs_refresh_callback+0xc/0x188
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c0279058>]
(debug_smp_processor_id+0xbc/0xf0)
[<c0279058>] (debug_smp_processor_id+0xbc/0xf0) from [<c0454b54>]
(dbs_refresh_callback+0xc/0x188)
[<c0454b54>] (dbs_refresh_callback+0xc/0x188) from [<c0087290>]
(process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>]
(worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>]
(kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>]
(kernel_thread_exit+0x0/0x8)

The intent of the code is to determine which CPU this work item
is running on, which we can easily do by passing that information
in a wrapper struct around the work struct. Do this so we avoid
this problem.

Change-Id: I05ca0ff2b3cbaa239930463ea0760e3e9d75145f
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>
intellidemand: Add support to consider other cpu load when scaling frequencies

Currently only current cpu load is considered when frequency scaling.
As a side effect of this when scheduler migrates a thread to a slower
core, the execution time increases unexpectedly.

The new algorithm not only considers current cpu load for frequency
scaling, but also takes into account load of other online cpus. The
treshold for this can be controlled using up_threshold_any_cpu_load.
When the up_threshold_any_cpu_load is crossed in any cpu then the
current cpu is set to sync_freq.

Also, when more than one cpu is online a two step ramp-up mechanism
is used. When the up_threshold_multi_core is crossed the cpu is ramped
up to optimal_freq which is less than policy->max and set to a power
friendly value.

Change-Id: I64bed1b142cde1f239e73aa1f78981c78aaf59ce
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

intellidemand: Fix kernel warning in cpufreq_governor_dbs

GOV_STOP event destroys the timer_mutex and is not initialized back
upon GOV_START event.
The Kernel complains at mutex_lock(during GOV_LIMITS event) after
mutex_destroy.

[<c0014918>] (unwind_backtrace+0x0/0x11c)
[<c007c004>] (warn_slowpath_common+0x4c/0x64)
[<c007c034>] (warn_slowpath_null+0x18/0x1c)
[<c079eef8>] (__mutex_lock_slowpath+0x130/0x3c4)
[<c079f1ac>] (mutex_lock+0x20/0x3c) from [<c0540900>]
[<c0540900>] (cpufreq_governor_dbs+0x3c8/0x468)
[<c053d500>] (__cpufreq_governor+0x90/0xe0)
[<c053d774>] (__cpufreq_set_policy+0x224/0x258)
[<c053da58>] (cpufreq_add_dev_interface+0x2b0/0x308)
[<c053e784>] (cpufreq_add_dev+0x500/0x56c)
[<c079247c>] (cpufreq_cpu_callback+0x88/0x9c)
[<c07a2ca8>] (notifier_call_chain+0x38/0x68)
[<c007ded0>] (__cpu_notify+0x28/0x40)
[<c0790024>] (_cpu_up+0xe4/0x118)
[<c0790024>] (cpu_up+0x64/0x80)
[<c0765840>] (store_online+0x48/0x78)
[<c038d0c8>] (dev_attr_store+0x18/0x24)
[<c017be40>] (sysfs_write_file+0x108/0x13c)
[<c012cdfc>] (vfs_write+0xb0/0x128)
[<c012d034>](sys_write+0x38/0x64)

Change-Id: Ie2a796b17209243de731ccf2ab04b7f9e7048df8
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

Adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>