first some fixes
first some fixes - 1
USB force fast charging for Xperia Z

this patch
include:
https://github.com/faux123/htc-m7/commit/2fc85d234bd28f8a2eb76483faabd8d16a2ea0ae
https://github.com/faux123/htc-m7/commit/20c36e0338e2ff49fc72ee828c7123202a76fc6f
cpufreq:cpufreq_intellidemand: adaptation to Xperia Z
sched: add wait_for_completion_io[_timeout]

The only difference between wait_for_completion[_timeout]() and
wait_for_completion_io[_timeout]() is that the latter calls
io_schedule_timeout() instead of schedule_timeout() so that the caller
is accounted as waiting for IO, not just sleeping.

These functions can be used for correct iowait time accounting when the
completion struct is actually used for waiting for IO (e.g. completion
of a bio request in the block layer).

Modified to compile with 3.4.0 on the Xperia Z

idea is taken here -
https://github.com/flar2/m7-GPE/commit/0782a7b5cdf4eabde9ad0637e19e1278ec5457a7
Preparing for introduction of intelli_plug: update scheduler and mutex code.

Porting last patches from
https://github.com/faux123/htc-m7/commits/kk_mr1_GE/kernel/sched/core.c
(Jan 04, 2014)
and
https://github.com/faux123/moto_x/commits/kk_mr1_pub/kernel/sched/core.c
(Feb 12, 2014)

----------
scheduler: compute time-average nr_running per run-queue

Compute the time-average number of running tasks per run-queue for a
trailing window of a fixed time period. The detla add/sub to the
average value is weighted by the amount of time per nr_running value
relative to the total measurement period.

https://github.com/faux123/htc-m7/commit/28a88f1dc2f4dd745981cd394655b673b28b7a00

----------
scheduler: Re-compute time-average nr_running on read

Re-compute time-average nr_running when it is read. This would
prevent reading stalled average value if there were no run-queue
changes for a long time. New average value is returned to the reader,
but not stored to avoid concurrent writes. Light-weight sequential
counter synchronization is used to assure data consistency for
re-computing average.

https://github.com/faux123/htc-m7/commit/3dc726471fc7f7434f79e460c1e054fd9504e9d6

----------
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned
on) allow multiple tasks to spin on a single mutex concurrently. A
potential problem with the current approach is that when the mutex
becomes available, all the spinning tasks will try to acquire the
mutex more or less simultaneously. As a result, there will be a lot of
cacheline bouncing especially on systems with a large number of CPUs.

This patch tries to reduce this kind of contention by putting the
mutex spinners into a queue so that only the first one in the queue
will try to acquire the mutex. This will reduce contention and allow
all the tasks to move forward faster.

The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation. This
patch will add a new field into the mutex data structure for holding
the MCS lock. This expands the mutex size by 8 bytes for 64-bit system
and 4 bytes for 32-bit system. This overhead will be avoid if the
MUTEX_SPIN_ON_OWNER option is turned off.

https://github.com/faux123/htc-m7/commit/b6cab60dbd24a0864348907acea8ae09d8df43a1

----------
sched: Optimize build_sched_domains() for saving first SD node for a cpu

We are saving first scheduling domain for a cpu in build_sched_domains()
by
iterating over the nested sd->child list. We don't actually need to do
it this
way.

*per_cpu_ptr(d.sd, i) is guaranteed to be NULL in the beginning as we
have
called __visit_domain_allocation_hell() which does a memset to zero for
struct
s_data.

So, save pointer to first SD while running the iteration loop over tl's.

https://github.com/faux123/moto_x/commit/35e4182af1c130bbda9a4ac055c2a9c039287821

----------
sched: Optimize build_sched_domains() for saving first SD node for a cpu

We are saving first scheduling domain for a cpu in build_sched_domains()
by
iterating over the nested sd->child list. We don't actually need to do
it this
way.

tl will be equal to sched_domain_topology for the first iteration and so
we can
set *per_cpu_ptr(d.sd, i) based on that.  So, save pointer to first SD
while
running the iteration loop over tl's.

https://github.com/faux123/moto_x/commit/4a0b943f51022029db67e19c993381ea3fdabcc0

----------
sched: Remove unused params of build_sched_domain()

build_sched_domain() never uses parameter struct s_data *d and so
passing it is
useless.

Remove it.

https://github.com/faux123/moto_x/commit/c240acfd414a136c9eb339569ae59d39fa42d0b7

----------
sched: Use cached value of span instead of calling sched_domain_span()

In the beginning of build_sched_groups() we called sched_domain_span()
and
cached its return value in span. Few statements later we are calling it
again to
get the same pointer.

Lets use the cached value instead as it hasn't changed in between.

https://github.com/faux123/moto_x/commit/653be0170e58858fd9da6f46ede1b75ee449f41c

----------
sched: don't call get_group() for covered cpus

In build_sched_groups() we don't need to call get_group() for cpus which
are
already covered in previous iterations. So, call get_group() after
checking if
cpu is covered or not.

https://github.com/faux123/moto_x/commit/f1c67cfcdb097b1034643c638b1edd296737ee6c

----------
sched: remove WARN_ON(!sd) from init_sched_groups_power()

sd can't be NULL in init_sched_groups_power() and so checking it for
NULL isn't
useful. In case it is required, then also we need to rearrange the code
a bit as
we already accessed invalid pointer sd to get sg: sg = sd->groups.

https://github.com/faux123/moto_x/commit/6dd7d04c792ae883f36e5dffed0bde3df9a233a0

----------
sched: Reduce overestimating rq->avg_idle

When updating avg_idle, if the delta exceeds some max value, then
avg_idle
gets set to the max, regardless of what the previous avg was. This can
cause
avg_idle to often be overestimated.

This patch modifies the way we update avg_idle by always updating it
with the
function call to update_avg() first. Then, if avg_idle exceeds the max,
we set
it to the max.

https://github.com/faux123/moto_x/commit/2b0ff53b6b1580af58e759b2162e68344ddd2b98

----------
sched: Consider max cost of idle balance per sched domain

In this patch, we keep track of the max cost we spend doing idle load
balancing
for each sched domain. If the avg time the CPU remains idle is less then
the
time we have already spent on idle balancing + the max cost of idle
balancing
in the sched domain, then we don't continue to attempt the balance. We
also
keep a per rq variable, max_idle_balance_cost, which keeps track of the
max
time spent on newidle load balances throughout all its domains.
Additionally,
we swap sched_migration_cost used in idle_balance for
rq->max_idle_balance_cost.

By using the max, we avoid overrunning the average. This further reduces
the chance
we attempt balancing when the CPU is not idle for longer than the cost
to balance.

I also limited the max cost of each domain to
5*sysctl_sched_migration_cost as
a way to prevent the max from becoming too inflated.

https://github.com/faux123/moto_x/commit/92ddc5baad81b16fbef4ea39b1bc9ac482a86f31

----------
sched: Implement smarter wake-affine logic

The wake-affine scheduler feature is currently always trying to pull
the wakee close to the waker. In theory this should be beneficial if
the waker's CPU caches hot data for the wakee, and it's also beneficial
in the extreme ping-pong high context switch rate case.

Testing shows it can benefit hackbench up to 15%.

However, the feature is somewhat blind, from which some workloads
such as pgbench suffer. It's also time-consuming algorithmically.

Testing shows it can damage pgbench up to 50% - far more than the
benefit it brings in the best case.

So wake-affine should be smarter and it should realize when to
stop its thankless effort at trying to find a suitable CPU to wake on.

This patch introduces 'wakee_flips', which will be increased each
time the task flips (switches) its wakee target.

So a high 'wakee_flips' value means the task has more than one
wakee, and the bigger the number, the higher the wakeup frequency.

Now when making the decision on whether to pull or not, pay attention to
the wakee with a high 'wakee_flips', pulling such a task may benefit
the wakee. Also imply that the waker will face cruel competition later,
it could be very cruel or very fast depends on the story behind
'wakee_flips', waker therefore suffers.

Furthermore, if waker also has a high 'wakee_flips', that implies that
multiple tasks rely on it, then waker's higher latency will damage all
of them, so pulling wakee seems to be a bad deal.

Thus, when 'waker->wakee_flips / wakee->wakee_flips' becomes
higher and higher, the cost of pulling seems to be worse and worse.

https://github.com/faux123/moto_x/commit/8da8770e58f8b1158c7b270d69212d0d219a17d3

----------
sched: Micro-optimize the smart wake-affine logic

Smart wake-affine is using node-size as the factor currently, but the
overhead
of the mask operation is high.

Thus, this patch introduce the 'sd_llc_size' percpu variable, which will
record
the highest cache-share domain size, and make it to be the new factor,
in order
to reduce the overhead and make it more reasonable.

https://github.com/faux123/moto_x/commit/6b15a2c548018491e7fa143034f8d7dad7a33855
sched: added time-based average load

idea is taken here -
https://github.com/n3ocort3x/android_kernel_htc_msm8960/commit/68b0ceb0b171e0f9d45950db83526cab96818a76
Remove tracing

idea is taken here -
https://github.com/flar2/ElementalX-ville-6.0/commit/cb4322178a14a177b3fae560e85dff6db02ee9ec#diff-a28f9d22c41841e788e9f2a3f2d33e9eR52
sched: Remove get_online_cpus() usage

Testing/Modified for 3.4.y from upstream.

Remove get_online_cpus() usage from the scheduler; there's 4 sites that
use it:

- sched_init_smp(); where its completely superfluous since we're in
'early' boot and there simply cannot be any hotplugging.

- sched_getaffinity(); we already take a raw spinlock to protect the
task cpus_allowed mask, this disables preemption and therefore
also stabilizes cpu_online_mask as that's modified using
stop_machine. However switch to active mask for symmetry with
sched_setaffinity()/set_cpus_allowed_ptr(). We guarantee active
mask stability by inserting sync_rcu/sched() into _cpu_down.

- sched_setaffinity(); we don't appear to need get_online_cpus()
either, there's two sites where hotplug appears relevant:
* cpuset_cpus_allowed(); for the !cpuset case we use possible_mask,
for the cpuset case we hold task_lock, which is a spinlock and
thus for mainline disables preemption (might cause pain on RT).
* set_cpus_allowed_ptr(); Holds all scheduler locks and thus has
preemption properly disabled; also it already deals with hotplug
races explicitly where it releases them.

- reinit_sched_domains(); we shouldn't need to hotplug here. In fact,
this has likely been the thorn in my side, causing mpdecision to
break on sched_mc_power_savings changes.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(Modified for 3.4.y to include sched_domains())
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

idea is taken here -
https://github.com/franciscofranco/flo/commit/320492c9358d623fc7db920625b56655d8f40b28
sched: Remove extra put_online_cpus() inside sched_setaffinity()

Commit:

sched: Remove get_online_cpus() usage

has left one extra put_online_cpus() inside sched_setaffinity(),
remove it to fix the WARN:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 put_online_cpus+0x43/0x70()
...
[<ffffffff810c3fef>] put_online_cpus+0x43/0x70 [
[<ffffffff810efd59>] sched_setaffinity+0x7d/0x1f9 [
...

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/526DD0EE.1090309@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

idea is taken here -
https://github.com/franciscofranco/flo/commit/3bc17a9d03dad94983f085e2078eb4adc1901afd
Enable ARCH_POWER
sched: Fix select_idle_sibling() bouncing cow syndrome

If the previous CPU is cache affine and idle, select it.

The current implementation simply traverses the sd_llc domain,
taking the first idle CPU encountered, which walks buddy pairs
hand in hand over the package, inflicting excruciating pain.

1 tbench pair (worst case) in a 10 core + SMT package:

pre   15.22 MB/sec 1 procs
post 252.01 MB/sec 1 procs

Signed-off-by: Mike Galbraith <bitbucket@online.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link:
http://lkml.kernel.org/r/1359371965.5783.127.camel@marge.simpson.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: flar2 <asegaert@gmail.com>

idea is taken here -
https://github.com/flar2/m8-Sense/commit/1433dfa91557964ea386a6415c1a9135f55dcd24
sched: Fix clear NOHZ_BALANCE_KICK

I have faced a sequence where the Idle Load Balance was sometime
not
triggered for a while on my platform, in the following scenario:

CPU 0 and CPU 1 are running tasks and CPU 2 is idle

 CPU 1 kicks the
Idle Load Balance
 CPU 1 selects CPU 2 as the new Idle Load Balancer

CPU 2 sets NOHZ_BALANCE_KICK for CPU 2
 CPU 2 sends a reschedule IPI to
CPU 2

 While CPU 3 wakes up, CPU 0 or CPU 1 migrates a waking up task A
on CPU 2

 CPU 2 finally wakes up, runs task A and discards the Idle
Load Balance
       task A quickly goes back to sleep (before a tick
occurs on CPU 2)
 CPU 2 goes back to idle with NOHZ_BALANCE_KICK
set

Whenever CPU 2 will be selected as the ILB, no reschedule IPI will
be sent
because NOHZ_BALANCE_KICK is already set and no Idle Load
Balance will be
performed.

We must wait for the sched softirq to be
raised on CPU 2 thanks to another
part the kernel to come back to clear
NOHZ_BALANCE_KICK.

The proposed solution clears NOHZ_BALANCE_KICK in
schedule_ipi if
we can't raise the sched_softirq for the Idle Load
Balance.

Change since V1:

- move the clear of NOHZ_BALANCE_KICK in
got_nohz_idle_kick if the ILB
  can't run on this CPU (as suggested by
Peter)

Signed-off-by: Vincent Guittot
<vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra
<peterz@infradead.org>
Link:
http://lkml.kernel.org/r/1370419991-13870-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by:
Ingo Molnar <mingo@kernel.org>
Git-commit: 873b4c6
Git-repo:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[smuckle@codeaurora.org:
minor merge resolution for 3.4 in scheduler_ipi()]
Signed-off-by: Steve
Muckle <smuckle@codeaurora.org>
Change-Id:
I3548612057cccc2ecc29429c129c44183083831f

idea is taken here -
https://github.com/jrior001/android_kernel_samsung_d2/commit/51c8bddb6812c3162a3115fb22f01b2a798d8754
add intelli_plug by faux123
block: introduce the BFQ-v7r4 I/O sched for 3.4

Add the BFQ-v7r4 I/O scheduler to 3.4.
The general structure is
borrowed
from CFQ, as much of the code for
handling I/O contexts. Over
time,
several useful features have been
ported from CFQ as well (details
in
the changelog in README.BFQ). 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 a very low latency.

    -
Latency
guarantees are preserved also in the presence of NCQ.

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

    - BFQ features Early Queue
Merge
(EQM), a sort of fusion of the
      cooperating-queue-merging and
the
preemption mechanisms present
      in CFQ. EQM is in fact a
unified
mechanism that tries to get a
      sequential read pattern, and
hence a
high throughput, with any
      set of processes performing
interleaved
I/O over a contiguous
      sequence of sectors.

    - BFQ
supports
full hierarchical scheduling, exporting a cgroups

interface.
Since each node has a full scheduler, each group can
      be
assigned
its own weight.

    - If the cgroups interface is not used,
only I/O
priorities can be
      assigned to processes, with ioprio
values mapped
to weights
      with 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>
Signed-off-by:
poondog
<markj338@gmail.com>
Add the BFQ-v7r4 I/O scheduler to 3.4 (add)
block, bfq: add Early Queue Merge (EQM) to BFQ-v7r4 for 3.4.0

A set of processes may happen  to  perform interleaved reads, i.e.,
requests whose union would give rise to a  sequential read  pattern. There are two typical  cases: in the first  case,   processes  read fixed-size chunks of data at a fixed distance from each other, while in the second case processes may read variable-size chunks at  variable distances. The latter case occurs for  example with  KVM, which  splits the  I/O generated  by the  guest into multiple chunks,  and lets these chunks  be served by a  pool of cooperating processes,  iteratively assigning  the  next  chunk of  I/O  to  the first available  process. CFQ  uses actual  queue merging  for the  first type of
rocesses, whereas it  uses preemption to get a sequential  read pattern out of the read requests  performed by the second type of  processes. In the end it uses  two different  mechanisms to  achieve the  same goal: boosting the throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a sequential  read pattern  with
both  types of  processes. The  main idea is checking newly arrived
requests against the next request of the active queue both in case of actual request insert and in case of request merge. By doing so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms used in CFQ.

Finally, EQM  also preserves the  typical low-latency
properties of BFQ, by properly restoring the weight-raising state of  a queue when it gets back to a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: poondog <markj338@gmail.com>
exFAT 1.2.6
intelli/msm_thermal from faux123
Merge remote-tracking branch 'brakern/cm-11.0-se-nightly' into cm-11.0

Conflicts:
	drivers/power/pm8921-charger-sony.c
	drivers/usb/otg/msm_otg.c

Change-Id: Idfedbb182278c22477d909daa91c21a352320498