Implement kexec-hardboot by. All work done by @Tasssadar

Change-Id: I20bbb5181327e56362ab82460ed43d03834d1ae5
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: I74a79f3ed3177a12a5f23181a41b837f49d11ca8
PM / QoS: Fix deadlock during PM QoS vote to default value

pm_qos_work_fn() calls pm_qos_update_request() which does
cancel_delayed_work_sync() on the same pm_qos_work_fn()
causing deadlock. Fix this by updating the target with
default timeout value directly instead of calling
pm_qos_update_request().

CRs-Fixed: 526216
Change-Id: I7de2fb1c89f87b0ebf7427116b8920aec50d5b2b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
random: entropy tweaks are all the rage nowadays

use nonblocking for all.  Read this web page:
http://lwn.net/Articles/489734/

Change-Id: I91c2a4299593709c0bbb1c6bf5a1096d2469c82c
random: prevent add_input from doing anything

Change-Id: If6cb629788f170d3b904373a7d4ad4829ea69e4b
random: remove warning

Change-Id: I1c61bb75c53d3fb4a1e569f2facd759607c2d844
readahead: make context readahead more conservative

This helps performance on moderately dense random reads on SSD.

Transaction-Per-Second numbers provided by Taobao:

		QPS	case
		-------------------------------------------------------
		7536	disable context readahead totally
w/ patch:	7129	slower size rampup and start RA on the 3rd read
		6717	slower size rampup
w/o patch:	5581	unmodified context readahead

Before, readahead will be started whenever reading page N+1 when it happen
to read N recently.  After patch, we'll only start readahead when *three*
random reads happen to access pages N, N+1, N+2.  The probability of this
happening is extremely low for pure random reads, unless they are very
dense, which actually deserves some readahead.

Also start with a smaller readahead window.  The impact to interleaved
sequential reads should be small, because for a long run stream, the the
small readahead window rampup phase is negletable.

The context readahead actually benefits clustered random reads on HDD
whose seek cost is pretty high.  However as SSD is increasingly used for
random read workloads it's better for the context readahead to concentrate
on interleaved sequential reads.

Another SSD rand read test from Miao

        # file size:        2GB
        # read IO amount: 625MB
        sysbench --test=fileio          \
                --max-requests=10000    \
                --num-threads=1         \
                --file-num=1            \
                --file-block-size=64K   \
                --file-test-mode=rndrd  \
                --file-fsync-freq=0     \
                --file-fsync-end=off    run

shows the performance of btrfs grows up from 69MB/s to 121MB/s, ext4 from
104MB/s to 121MB/s.

Change-Id: Id53ca3937a4f0b53610a6d1474b201bc7ff3d47d
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Tested-by: Tao Ma <tm@tao.ma>
Tested-by: Miao Xie <miaox@cn.fujitsu.com>
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>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
fix another bunch of warnings I missed

thanks showmp

Change-Id: I5a15c646977b03c6e54a5b4eb22225c32828ce83
Hammerhead: Enable various optimizations

use neon and pipe flags
use O3
and some other

Change-Id: I003a614a5d513f56916fc0ca6ce7ce92ad0356f5
Hammerhead: Add IntelliPlug option

intelli_plug: intelligent hotplug cpu driver with eco mode

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

intelli_plug: tweak for faster wakeup from suspend

bump version to 1.1

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

intelli_plug: increase cores on persistence

also replace hardcoded values with Macros for ease of updating later

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

intelli_plug: make it gcc-4.6.x eabi compatible :p

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

intelli_plug: use rq_stats to help detect artificial or constant loads

benchmarks often create fake / artificial loads at a constant rate.  These
type of loads are not detected corectly by run average algorithms. Use
the run queue stats to help detect these cases and bring up the cores in
correspondence.

bump version to 1.2

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

intelli_plug: use mp_decision() algorithm for core 3 and 4

This replaces the simplistic check for run queue thresholds with a more
sophisticate algorithm with time awareness

bump version to 1.3

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

intelli_plug: tweak mp_decsion parameters and remove unused logic

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

intelli_plug: bump threshold slightly for better response

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

wip: intelli_plug: change logic for better benchmark performance

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

intelli_plug: use mp_decision to reduce online persistence count for cores

this should bring down the cores faster when run queue is low
also optimized code a bit using local vars

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

intelli_plug: disable by default

let the user enable via sysfs so it won't clash with mpdecision which is
enabled by default for qualcomm phones

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

intelli_plug: slow down hotplug activity from 50ms to 200ms

this will reduce the hotplug chaos which may in turn save more power

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

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

intelli_plug: code clean up and minor bug fixes

bump to version 1.6

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

intelliplug: replaced deprecated early_suspend driver with userspace interface

early_suspend has been deprecated, so move original functionality to sysfs
interfae and have userspace app to replicate the early_suspend functionality

bump version to 1.7

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

intelli_plug: add dynamic load sampling rate logic

Add dynamic sampling logic based on load. If load is high and required more
than 2 cores, increase the sampling rate for a duration of 3 seconds to help
manage the load better during this time.  Once duration expires, revert back
to lazier sampling rate for better batter performance.

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

intelli_plug: add new power_suspend PM driver

bump version to 1.9

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

intelli_plug: add touch input logic

changed intelli_plug sampling rates and bump to version 2.0

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

intelli_plug: use a context safe function call instead

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

intelli_plug: performance tune-up continued...

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

intelli_plug: switch to use dedicated high priority workqueue

from the shared global workqueue.  This should prevent hang ups while the
global workqueue is busy and cleaned up some logic issues.

give input boost its own workqueue

bump to version 2.2

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

intelli_plug: code review clean up

set def sampling rate to something sane rather than zero (instantaneous
rescheduling is not good if intelli_plug is disabled)

make touch input more generic rather than tied to a touchscreen driver

remove unused code

thanks to @dorimanx for the code reviews and suggestions

bump to version 2.3

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

Intelli_plug: add wakeup cpufreq boost for quicker wakeup

bump version to 2.4

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

intelli_plug: add screen off max controls

bump to version 2.5

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

intelli_plug: add parameter to control touch boost on/off

bump version to 2.6

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

intelli_plug: refactor stats calculation code to be less intrusive

this is done for those kernels which do not have 100% source code available
and must use existing closed source modules such as wifi drivers

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

Intelli_plug: kernel sched/core: add per cpu nr_running stats

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

intelli_plug: add profiles support and misc code optimization

bump to version 3.0

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

intelli_plug: use per cpu nr_runnings stats for unplugging cores

bump version to 3.1

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

intelli_plug: allow cpu_nr_running_threshold to be user adjustable

bump version to 3.2

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

intelli_plug: tweak cpu_nr_running threshold

and fix minor logic issues

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

intelli_plug: remove legacy msm_rq based code

just use the original algorithm based on nr_running_stats

bump version to 3.3

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

intelli_plug: add nr_running_thresholds based on thread capacity of SOC type

instead of hard coded nr_running_thresholds, perform compile time calculation
of thresholds based on thread capacity of SOC types.

bump version to 3.4

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

intelli_plug: misc minor code fixup post 3.4 update

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

intelli_plug: add automatic dual-core initializations

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

intelli_plug: deprecate eco mode. replaced by built-in profile

bump version to 3.5

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

intelli_plug: post 3.5 tweaks and code clean up

bump to version 3.6

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

intelli_plug: move to its own directory. It's been cross platform for a while

intelli_plug driver has been working on OMAP44xx, TEGRA 3, Exynos and
MSM Krait/Cortex multi-core SOCs.  So it doesn't make sense to patch on a per
SOC basis, move it to its own ARM platform independent folder so patches can
apply to all supported ARM platforms

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

intelli_plug: unify powersuspend and earlysuspend drivers

also minor clean up on the persist logic

bump to version 3.7

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

intelli_plug: adjust thread capacity for Cortex A7 SOCs

Cortex A7 is much weaker than Krait processors

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

intelli_plug: fix thread capacity threshold calculation

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

intelli_plug: fix logic error for eco mode profiles

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

intelli_plug: only apply suspend/resume logic if active

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

intelli_plug: fix incorrect cpufreq API usage

This resolves the wakeup kick and screen off max issues

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

intelli_plug: initialize ip_info struct element during driver init

this will eliminate race issues

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

intelli_plug: use primary CPU's info data for non-boot cpu's settings

Async CPU design has caused quite a bit of grief for controlling cpu
frequencies

bump to version 3.8

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

intelli_plug: older Qualcomm kernel compatibility fixup

ARGH... really angry at CAF code.

some cpufreq driver APIs are incredibly unstable with some of the older
MSM kernels.  The correct way is the fix the cpufreq drivers, but there are
tons of variations out there, so rather than depending on a fix, make
intelli_plug more universal by avoiding the troubling APIs altogether

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

Change-Id: Ia530ec03b2b678fdb538b94b272599e96309133f
Hammerhead: Add BFQ I/O Scheduler

block: cgroups, kconfig, build bits for BFQ-v6-3.4

Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

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

block: introduce the BFQ-v6 I/O sched for 3.4

Add the BFQ-v6 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be made a queue is selected and served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved while
      still preserving latency guarantees.

    - A useful feature borrowed from CFQ: static fallback queue for OOM.

    - Differently from CFQ, BFQ uses a unified mechanism (Early Queue Merge,
      EQM) to get a sequential read pattern, and hence a high throughput,
      with any set of processes performing interleaved I/O. EQM also
      preserves low latency. The code for detecting whether two queues have
      to be merged is a slightly modified version of the CFQ code for
      detecting whether two queues belong to cooperating processes and whether
      the service of a queue should be preempted to boost the throughput.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio (mapped to a weight, see next point)
      and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weight of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

block/bfq-iosched.c: GCC 4.8.x compatibility fixup

Change-Id: I2908369ec9590b95541ddaa7c26f89ed0b8e4b3b
Signed-off-by: Paul Reioux <reioux@gmail.com>
Hammerhead: Add FIOPS I/O Scheduler

block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

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

block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Change-Id: Ie61b1887a915bbfb4b75c7333ab0ad2205a6fe57
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Hammerhead: Add Intelliactive gov

cpufreq: intelliactive: initial coding and introduction!

intelliactive is based on Latest Google Interactive cpufreq governor from
Google.  The original Interactive provides smooth UI operations but suffers
slight battery drain due to its aggressive policies.  Intelliactive is an
improvement built on top of it.

It has the following enhancements added:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to
   max freq
3. Checks for offline cpus and short circuits some unnecessary checks to
   improve code execution paths
4. removed trace calls

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

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
	include/linux/cpufreq.h

Change-Id: I874e836480117d5c9169c32661e955bee706ae07

intelliactive: fix race condition when unregistering input handlers

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

intelliactive: add upstream patches

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

intelliactive: make touch boost interface generic

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

intelliactive: rework input register/unregister

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

Change-Id: I0953a3ae65c39c764f0469a2ed5c232b8652be6e
Hammerhead: Add IntelliMM gov

cpufreq_intellimm: intelliminmax cpu governor initial baseline commit

intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs).  It is designed to work within those
fixed voltage ranges in order to maximize battery performance while creating a
smooth UI operations.

Copyright 2014 Paul Reioux <aka faux123>

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

WIP: Intellimm: remove unused code and change tblmap algorithm

tblmap: add power-save frequencies for the first 5 entries

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

WIP: intellimm: more tweaks and table clean up

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

WIP: intellimm: more tweaks

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

WIP: intellimm: clean up derpy logic

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

WIP: intellimm: final clean up and algorithm tweaks

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

WIP: intellimm: finalizing part 2

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

WIP: intellimm: finalizing part 3

add back burst for smoother UI

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

intellimm: fix div by zero derp

Change-Id: Iba7c414ceab26b1bec36823366db27b2173c500f
Signed-off-by: Paul Reioux <reioux@gmail.com>
Hammerhead: Add additional TCP Congestion Controls

Change-Id: I961b693afd76465e58690e4f4393b2c159417565