cpuidle-exynos4: calm down some logspam

* noticed these CONSTANTLY flooding the log with screen off
  using wireless adb (so it was unplugged)

Change-Id: I4df4f0da9f62cfd86552b77c71d4a2de11dac5d4

ALSO: .target_residency	= 10000
Version 0.9 beta4

Changelog:

- removed 'freq_step' functionality as it never had any function in this governor. it was a left over from mialwes 'smoove' governor and also
  had no function in his governor back then. so yeah all the 'feelings' about it's influence were placebo :)
- introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies
  in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end
  the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions
- added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)
  this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export implementation
  included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling
  interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the
  tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered
- if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu
  temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'
  so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach
  into exynos4 TMU driver trottling range)
- if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable
- added auto adjustment of all available frequency thresholds when scaling max limit has changed
- improved sampling rate idle switching by making it scaling thresholds independent
- again some code style and comment changes/fixes

profile header file (Version 0.2 beta3):

- added scaling block temperature tuneable to all profiles if CONFIG_EXYNOS4_EXPORT_TEMP is defined
- use CPU temperature treshold of 65°C instead of 15 scaling block cycles in game profile if
  CONFIG_EXYNOS4_EXPORT_TEMP is defined
- added proportional frequency tuneable to all profiles
- added auto adjust freq thresholds to all profiles (disabled by default)
- enabled scaling proportional in ybat, ybatext, zzbat, zzbatp, zzmod and zzgame profile
- enabled scaling fast down over 1200MHz and resposiveness over 400Mhz with up threshold of 20
  in ybat, ybatext, zzbat, zzbatp, and zzmod profile
- added core macros to exclude not used code like it is in governor
- removed freq_step tuneable from all profiles
mach-exynos: Support for current CPU temperature reading from Exynos4 TMU driver (ZaneZam <cyxman@yahoo.com>)
ksm: Provide support to use deferred timers for scanner thread

KSM thread to scan pages is getting schedule on definite timeout.
That wakes up CPU from idle state and hence may affect the power
consumption. Provide an optional support to use deferred timer
which suites low-power use-cases.

To enable deferred timers,
$ echo 1 > /sys/kernel/mm/ksm/deferred_timer

Change-Id: I07fe199f97fe1f72f9a9e1b0b757a3ac533719e8
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
ksm: check and skip page, if it is already scanned (Pradeep Sawlani)

On system like Android where most of the process are forked
from parent w/o execve, KSM can scan same page multiple times
in one scan cycle. There is no advantage in scanning same page
multiple times for merging. During testing with Android, it was
observed around 60% pages are skipped for each scan cycle.

Change-Id: I0cf01802f0b4d61fcab92558beb9e1c660dc9a77
Link: http://lkml.kernel.org/r/CAMrOTPgBtANS_ryRjan0-dTL97U7eRvtf3dCsss=Kn+Uk89fuA@mail.gmail.com
Signed-off-by: Pradeep Sawlani <sawlani@amazon.com>
ARM: smp: flush L1 cache in cpu_die()

Flush the L1 cache for the CPU which is going down in cpu_die() so
that we don't end up with all platforms doing this.  This ensures
that any cache lines we own are pushed out before the cache becomes
inaccessible.

We may end up subsequently creating some dirty cache lines - for
example, with the complete() call, but this update must become
visible to other CPUs before __cpu_die() can proceed.  Subsequent
accesses from the platforms cpu_die() function should _not_ matter.

Also place a mb() after the complete() call to ensure that this is
visible to other CPUs.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
arch: mm: do not invoke OOM killer on kernel fault OOM

Kernel faults are expected to handle OOM conditions gracefully (gup,
uaccess etc.), so they should never invoke the OOM killer.  Reserve this
for faults triggered in user context when it is the only option.

Most architectures already do this, fix up the remaining few.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: azurIt <azurit@pobox.sk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: 7606/1: cache: flush to LoUU instead of LoUIS on uniprocessor CPUs

flush_cache_louis flushes the D-side caches to the point of unification
inner-shareable. On uniprocessor CPUs, this is defined as zero and
therefore no flushing will take place. Rather than invent a new
interface
for UP systems, instead use our SMP_ON_UP patching code to read the
LoUU from the CLIDR instead.

Cc: <stable@vger.kernel.org>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect

On Cortex-A9 before version r1p0, the LoUIS bit field of the CLIDR
register returns zero when it should return one. This leads to cache
maintenance operations which rely on this value to not function as
intended, causing data corruption.

The workaround for this errata is to detect affected CPUs and correct
the LoUIS value read.

Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpuidle: Fix NULL pointer dereference during hotplug
misc changes (fs, kernel, net, uaccess)

Conflicts:
	net/bluetooth/hci_conn.c
ARM: mutex: use generic atomic_dec-based implementation for ARMv6+

Commit a76d7bd96d65 ("ARM: 7467/1: mutex: use generic xchg-based
implementation for ARMv6+") removed the barrier-less, ARM-specific
mutex implementation in favour of the generic xchg-based code.

Since then, a bug was uncovered in the xchg code when running on SMP
platforms, due to interactions between the locking paths and the
MUTEX_SPIN_ON_OWNER code. This was fixed in 0bce9c46bf3b ("mutex: place
lock in contended state after fastpath_lock failure"), however, the
atomic_dec-based mutex algorithm is now marginally more efficient for
ARM (~0.5% improvement in hackbench scores on dual A15).

This patch moves ARMv6+ platforms to the atomic_dec-based mutex code.

Change-Id: I5cb600b15f891dc692356322b38cae1d692a084c
Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
futex fixes from Thomas Gleixner

Conflicts:
	kernel/futex.c
ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp

If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
arch has different per-cpu loops_per_jiffy definition.

Signed-off-by: Richard Zhao <richard.zhao@linaro.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	arch/arm/kernel/smp.c
ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp

If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
arch has different per-cpu loops_per_jiffy definition.

Signed-off-by: Richard Zhao <richard.zhao@linaro.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	arch/arm/kernel/smp.c
cpufreq: Fix policy stucking if user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max
has
some overlap with the current policy min/max. This works out fine until
we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check
at
the start of __cpufreq_set_policy fails and prevents us from getting out
of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we
can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpuidle: make a single register function for all

The usual scheme to initialize a cpuidle driver on a SMP is:

	cpuidle_register_driver(drv);
	for_each_possible_cpu(cpu) {
		device = &per_cpu(cpuidle_dev, cpu);
		cpuidle_register_device(device);
	}

This code is duplicated in each cpuidle driver.

On UP systems, it is done this way:

	cpuidle_register_driver(drv);
	device = &per_cpu(cpuidle_dev, cpu);
	cpuidle_register_device(device);

On UP, the macro 'for_each_cpu' does one iteration:

        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

Hence, the initialization loop is the same for UP than SMP.

Beside, we saw different bugs / mis-initialization / return code
unchecked in
the different drivers, the code is duplicated including bugs. After
fixing all
these ones, it appears the initialization pattern is the same for
everyone.

Please note, some drivers are doing dev->state_count = drv->state_count.
This is
not necessary because it is done by the cpuidle_enable_device function
in the
cpuidle framework. This is true, until you have the same states for all
your
devices. Otherwise, the 'low level' API should be used instead with the
specific
initialization for the driver.

Let's add a wrapper function doing this initialization with a cpumask
parameter
for the coupled idle states and use it for all the drivers.

That will save a lot of LOC, consolidate the code, and the modifications
in the
future could be done in a single place. Another benefit is the
consolidation of
the cpuidle_device variable which is now in the cpuidle framework and no
longer
spread accross the different arch specific drivers.

Change-Id: I8f75188d5770871620f758c2973b74384ac570d5
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Karthik Parsha <kparsha@codeaurora.org>
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
timer: optimize apply_slack()

__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but
cheaper.
find_last_bit was showing up high on the list when I was profiling for
stalls
on icache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: edoko <r_data@naver.com>
ARM: smp: Wait just 1 second for other CPU to halt

Currently, the busyloop waiting for a 2nd CPU to stop takes about 4
seconds.  Adjust for the overhead of the loop by looping every 1ms
instead of 1us.

Signed-off-by: Chris Fries <C.Fries@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/537864
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-by: Russell Knize <rknize2@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
nohz: Reduce overhead under high-freq idling patterns

One testbox of mine (Intel Nehalem, 16-way) uses MWAIT for its idle
routine,
which apparently can break out of its idle loop rather frequently, with
high frequency.

In that case NO_HZ_FULL=y kernels show high ksoftirqd overhead and
constant
context switching, because tick_nohz_stop_sched_tick() will, if
delta_jiffies == 0, mis-identify this as a timer event - activating the
TIMER_SOFTIRQ, which wakes up ksoftirqd.

Fix this by treating delta_jiffies == 0 the same way we treat other
short
wakeups, delta_jiffies == 1.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Geoff Levand <geoff@infradead.org>
Cc: Gilad Ben Yossef <gilad@benyossef.com>
Cc: Hakan Akkan <hakanakkan@gmail.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpuidle: remove cross-cpu IPI by new latency request.

when drivers request new latency requirement, it's not necessary to
immediately wake up another cpu by sending cross-cpu IPI, we can
consider
the new latency to be taken into effect after next wakeup from idle,
this can save the unnecessary wakeup cost, and reduce the risk that
drivers may request latency in irq disabled context.

[<c08e0cc0>] (__irq_svc+0x40/0x70) from [<c00e801c>]
(smp_call_function_single+0x16c/0x240)
[<c00e801c>] (smp_call_function_single+0x16c/0x240) from [<c00e855c>]
(smp_call_function+0x40/0x6c)
[<c00e855c>] (smp_call_function+0x40/0x6c) from [<c0601c9c>]
(cpuidle_latency_notify+0x18/0x20)
[<c0601c9c>] (cpuidle_latency_notify+0x18/0x20) from [<c00b7c28>]
(blocking_notifier_call_chain+0x74/0x94)
[<c00b7c28>] (blocking_notifier_call_chain+0x74/0x94) from [<c00d563c>]
(pm_qos_update_target+0xe0/0x128)
[<c00d563c>] (pm_qos_update_target+0xe0/0x128) from [<c0620d3c>]
(msmsdcc_enable+0xac/0x158)
[<c0620d3c>] (msmsdcc_enable+0xac/0x158) from [<c06050e0>]
(mmc_try_claim_host+0xb0/0xb8)
[<c06050e0>] (mmc_try_claim_host+0xb0/0xb8) from [<c0605318>]
(mmc_start_bkops.part.15+0x50/0x2f4)
[<c0605318>] (mmc_start_bkops.part.15+0x50/0x2f4) from [<c00ab768>]
(process_one_work+0x124/0x55c)
[<c00ab768>] (process_one_work+0x124/0x55c) from [<c00abfc8>]
(worker_thread+0x178/0x45c)
[<c00abfc8>] (worker_thread+0x178/0x45c) from [<c00b0b24>]
(kthread+0x84/0x90)
[<c00b0b24>] (kthread+0x84/0x90) from [<c000fdd4>]
(kernel_thread_exit+0x0/0x8)
Disabling lock debugging due to kernel taint
coresight-etb coresight-etb.0: ETB aborted
Kernel panic - not syncing: softlockup: hung tasks

Signed-off-by: Guojian Chen <a21757@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/532702
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: David Ding <dding@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>