genirq: fix handle_nested_irq for lazy disable

When lazy disabling is implemented and an interrupt is disabled the
genirq code ends up marking it as IRQ_DISABLED in the descriptor.
The interrupt stays enabled in the controller.  If the interrupt
fires after disabling, the flow handlers namely handle_level_irq and
handle_edge_irq mask the interrupt in the controller.

This is not the case with handle_nested_irq. The interrupt stays enabled in
the controller and if it were a level interrupt it keeps firing only to be
ignored by handle_nested_irq.

Update handle_nested_irq to mask such an interrupt.

CRs-Fixed: 300931
Change-Id: Iea5eee19f9b20aed40978fa124308f8cab6ac46f
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
arm: Implement ticket spin-locks

Introduce optional ticket locks to help ensure fairness in
contended locks, as well as preventing livelock.

CRs-fixed: 302764
Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
(cherry picked from commit bdd8a9ce573917b5de9f2340a5f9530d465ea731)

Change-Id: I8f4aece6ce1228f54407785ba05674b6e31f7c7c
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
qup_i2c: Calculate combined write length for multiple write transactions

When a transaction consists of multiple write requests, add up the total
length of the write requests.  If there is a read following the writes,
set the read mode appropriately.

Change-Id: I0c15e14fa4732e4e25f5bb885688662a066b8782
CRs-Fixed: 314843
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
msm: platsmp: Remove extraneous boot_secondary delay

Change msleep_interruptible to usleep. msleep_interruptible
takes around 16 ms to return while the secondary CPU can
come up in about 1.5 ms. usleep is much finer grained and
returns every .5 ms. This allows boot_secondary to complete
much more quickly.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 5e1770668107ea31f9ec3fa4ac04be48cff8e470)

Change-Id: I49b32101667b1c2bfd7ecacf6a1c96db2a696afc
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
cpu-hotplug: Add the function 'cpu_hotplug_inprogress'

Allows a caller to detect whether a cpu hotplug operation
is in progress. This is useful for optimizing code paths
based on this condition.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 9f6cabec8fd0d0cb95084d18ee7cddbcf922ac2d)

Change-Id: I2eae7fbb819e3a776dba77a061eb89f30ac3176d
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
printk: Don't allow cpu to get console lock during hotplugging

The flush of the console takes unnecessary time during the cpu
hotplug up operation.  It can delay the rcu synchronize_sched
operation, which in turn delays the hotplug operation. The flush
delays rcu synchronize_sched during scheduling domain creation
by up to 100 ms by interrupting the move to a quiescent state.
This change delays the flush of the console to later in the
notification chain of cpu_online. At the point in the cpu_up
operation where the flush now occurs, other tasks can already
be scheduled on the cpu that just came up.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit c7108258d7e44b56842f8215e31d7310f86febaa)

Change-Id: I2986071a5b05760e05d86da2f33ea2a9fe882469
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
rcu-tree: Check for extended quiescent state at start of gp

During a cpu_hotplug event, it is much more likely for a cpu to be in
extended quiescent state. For example, on cpu_up, tasks are not yet
schedulable on the cpu that is coming up, so that cpu will not context
switch.  Additionally, cpu_down occurs on our dual-core system when
there is not a heavy load on the cpus, which means the cpus are less
likely to context switch. Checking for extended quiescent state at the
beginning of the grace period decreases the hotplug latency because the
rcu process does not necessarily have to wait tens of milliseconds to
force a quiescent state.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 18f8787b8c476fe5e55f0415361faf5d437b76be)

Change-Id: I73063c4065395782cc2750db3086666f3474f9a4
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
sched: Do not block when waiting to free old root domain

Instead of calling synchronize_sched(), directly invoke
call_rcu_sched() which will not block the cpu hotplug
operation but will call free_rootdomain when the rcu
process is complete. This is safe because the root
domains are allocated dynamically so any new readers
will have pointers to the new data and the new data
does not overwrite the old data.

This is a partial backport from 3.0.0 kernel.
I did not backport the dynamic allocation of the sched
domain and sched group data structures.  This would
require inclusion of 10 other patches and would not be
stable.

dce840a08702bd13a9a186e07e63d1ef82256b5e
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu Apr 7 14:09:50 2011 +0200

    sched: Dynamically allocate sched_domain/sched_group data-structures

    Instead of relying on static allocations for the sched_domain and
    sched_group trees, dynamically allocate and RCU free them.

    Allocating this dynamically also allows for some build_sched_groups()
    simplification since we can now (like with other simplifications) rely
    on the sched_domain tree instead of hard-coded knowledge.

    One tricky to note is that detach_destroy_domains() needs to hold
    rcu_read_lock() over the entire tear-down, per-cpu is not sufficient
    since that can lead to partial sched_group existance (could possibly
    be solved by doing the tear-down backwards but this is much more
    robust).

    A concequence of the above is that we can no longer print the
    sched_domain debug stuff from cpu_attach_domain() since that might now
    run with preemption disabled (due to classic RCU etc.) and
    sched_domain_debug() does some GFP_KERNEL allocations.

    Another thing to note is that we now fully rely on normal RCU and not
    RCU-sched, this is because with the new and exiting RCU flavours we
    grew over the years BH doesn't necessarily hold off RCU-sched grace
    periods (-rt is known to break this). This would in fact already cause
    us grief since we do sched_domain/sched_group iterations from softirq
    context.

    This patch is somewhat larger than I would like it to be, but I didn't
    find any means of shrinking/splitting this.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20110407122942.245307941@chello.nl
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit 09d39b8ade298ffed33597926a1b30f4609400a6)

Change-Id: I7305af949900919f06cf3444daf1183370aa07b7
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
partition_sched_domains: Do not destroy old sched domain on cpu_up

This is safe on a cpu_up only. Although a reader may still have
access to the old scheduling domain data, the data indicates that
the new CPU is not up, and therefore the only limitation is the
new CPU will not be schedulable by that reader until that reader
receives the new data.

Signed-off-by: Maya Spivak <mspivak@codeaurora.org>
(cherry picked from commit f963077fba323bd06814639a691bd905006bb541)

Change-Id: I15b3e0fd8c182e14db1c14f2a45b467f24d41cc5
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>