msm: mdss: use appropriate api to get length of scatterlist

Moving away from using sg_dma_len() api to be inline with
ion driver, use sg->length for scatterlist length.

Change-Id: I3a33340dc1bda5b24a406c29601aff4d5b2c5748
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
msm: mdss: add LP/HS mode DCS CMD support to MDP5 targets

LP/HS mode configuration for DCS Commands in currently not
supported on MDP5 targets. Add the required support to meet
all panel requirements.

Change-Id: Ib31ddc02f151033a59d6297c8f1a4f8897378947
Signed-off-by: Shuo Yan <shuoy@codeaurora.org>
msm: mdss: enable runtime autosuspend for mdp device

With MDSS idle power collapse feature enabled, it is possible that
the runtime suspend callback for MDP device to be called when there are
no display updates. This results in MDSS GDSC to be turned off in idle
screen usecases, and would subsequently be turned back on upon the next
update. However, toggling GDSC can be an expensive operation and should
only be done when it is expected to be off for a substantial time. To
achieve this, enable the runtime autosuspend status for the mdp device.

Change-Id: I6e4127efe7b01d7e164b0763d34995c82c2e8be9
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
mdss: mdp: reset init phase and phase step to default

reset the init phase and phase step registers to default
when the pixel extension are not calculated in userspace.

Change-Id: I876f1628fb46901a07deb1b97a4ab55f924612b0
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
msm: mdss: restore mdss register when clocks are turned on

When MDSS idle power collapse feature is enabled, MDSS GDSC can be
turned off for idle screen usecases. As a result, whenever MDSS
GDSC is turned back on, all MDSS registers need to be restored.
Current implementation restores this as part of bus bandwidth control
API which is only called whenever interface clocks are turned on.
However, the correct approach is to restore the hardware state whenever
any new register programming needs to be done. Therefore, move the
call to restore MDSS state from the bus bandwidth control function over
to the MDSS clock control function.

Change-Id: I85c934b8050b217253be98d9630ef922e76b6216
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
msm: mdss: Vote for bandwidth reference count for command transfer

Bandwidth vote needs to be enabled for DCS commands to be sent
during static screen on command mode panels.

Change-Id: I267c910dac9610b230f0138909c0dc8ca5797f11
Signed-off-by: Vishnuvardhan Prodduturi <vproddut@codeaurora.org>
msm: mdss: fix underrun between splash screen and boot animation

When continuous splash is enabled, avoid timing
engine flush in the first commit.

Change-Id: I11e7f86c910aa4dcaea3fcd72ec24cbbea450db2
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
msm: mdss: support mdp idle power collapse only for cmd mode panels

With MDP idle power collapse feature enabled, MDSS GDSC gets turned off
whenever there are no updates sent to the panel which results in all
hardware registers getting reset. These hardware registers need to be
restored whenever on the next udpate. Currently, this restore
functionality is only supported for command mode panels. However it is
possible that there could be additional framebuffer devices that may be
active (such as a writeback device) in conjunction with the primary
panel. In such cases, if idle power collapse happens, then these control
paths may not get correctly restored leading to unexpected behaviors.
Fix this by preventing MDP idle power-collapse when such panels are
active.

Change-Id: I226e72086bb6232ae452a999d961c80f2841f833
Signed-off-by: Aravind Venkateswaran <aravindh@codeaurora.org>
msm8974: Enable ULPS mode for JDI panel

 * For real this time!

Change-Id: Ibd0a40f41ebd4419635c69c6378e4c330dad8424
ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+

The open-coded mutex implementation for ARMv6+ cores suffers from a
severe lack of barriers, so in the uncontended case we don't actually
protect any accesses performed during the critical section.

Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
code but optimised to remove a branch instruction, as the mutex fastpath
was previously inlined. Now that this is executed out-of-line, we can
reuse the atomic access code for the locking (in fact, we use the xchg
code as this produces shorter critical sections).

This patch uses the generic xchg based implementation for mutexes on
ARMv6+, which introduces barriers to the lock/unlock operations and also
has the benefit of removing a fair amount of inline assembly code.

Cc: <stable@vger.kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Shan Kang <kangshan0910@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

mutex: Place lock in contended state after fastpath_lock failure

ARM recently moved to asm-generic/mutex-xchg.h for its mutex
implementation after the previous implementation was found to be missing
some crucial memory barriers. However, this has revealed some problems
running hackbench on SMP platforms due to the way in which the
MUTEX_SPIN_ON_OWNER code operates.

The symptoms are that a bunch of hackbench tasks are left waiting on an
unlocked mutex and therefore never get woken up to claim it. This boils
down to the following sequence of events:

        Task A        Task B        Task C        Lock value
0                                                     1
1       lock()                                        0
2                     lock()                          0
3                     spin(A)                         0
4       unlock()                                      1
5                                   lock()            0
6                     cmpxchg(1,0)                    0
7                     contended()                    -1
8       lock()                                        0
9       spin(C)                                       0
10                                  unlock()          1
11      cmpxchg(1,0)                                  0
12      unlock()                                      1

At this point, the lock is unlocked, but Task B is in an uninterruptible
sleep with nobody to wake it up.

This patch fixes the problem by ensuring we put the lock into the
contended state if we fail to acquire it on the fastpath, ensuring that
any blocked waiters are woken up when the mutex is released.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Mason <chris.mason@fusionio.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@vger.kernel.org>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

ARM: 7495/1: 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: I6621bcd491a75f75aa6e75adffc7e47d3632c6e6
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch: arm: TLB invalidate if power collapse gets aborted

Invalidate entire local TLB in non sharable mode when
power collapse is aborted due to pending interrupt.

Change-Id: Ie6d46db8f6c1779b4f15e8940ad961a4cd014e37
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
kernel/smp.c: quit unconditionally enabling irqs in on_each_cpu_mask().

As in commit f21afc25f9ed ("smp.h: Use local_irq_{save,restore}() in
!SMP version of on_each_cpu()"), we don't want to enable irqs if they
are not already enabled.

I don't know of any bugs currently caused by this unconditional
local_irq_enable(), but I want to use this function in MIPS/OCTEON early
boot (when we have early_boot_irqs_disabled).  This also makes this
function have similar semantics to on_each_cpu() which is good in
itself.

Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

genirq: Allow forcing cpu affinity of interrupts

commit 01f8fa4f01d8362358eb90e412bd7ae18a3ec1ad upstream.

The current implementation of irq_set_affinity() refuses rightfully to
route an interrupt to an offline cpu.

But there is a special case, where this is actually desired. Some of
the ARM SoCs have per cpu timers which require setting the affinity
during cpu startup where the cpu is not yet in the online mask.

If we can't do that, then the local timer interrupt for the about to
become online cpu is routed to some random online cpu.

The developers of the affected machines tried to work around that
issue, but that results in a massive mess in that timer code.

We have a yet unused argument in the set_affinity callbacks of the irq
chips, which I added back then for a similar reason. It was never
required so it got not used. But I'm happy that I never removed it.

That allows us to implement a sane handling of the above scenario. So
the affected SoC drivers can add the required force handling to their
interrupt chip, switch the timer code to irq_force_affinity() and
things just work.

This does not affect any existing user of irq_set_affinity().

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Reported-and-tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

irq: Set CPU affinity right on thread creation

As irq_thread_check_affinity is called ONLY inside the while loop in
the irq thread, the core affinity is set only when an interrupt
occurs. This patch sets the core affinity right after the irq thread
is created and before it waits for interrupts. In real-tiime targets
that do not typically change the core affinity of irqs during
run-time, this patch will save additional latency of an irq thread in
setting the core affinity during the first interrupt occurrence for
that irq.

Change-Id: I4db2caefe0286437cddfe348a0f1e63db91ee749
Signed-off-by: Sankara S Muthukrishnan <sankara.m@ni.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/CAFQPvXeVZ858WFYimEU5uvLNxLDd6bJMmqWihFmbCf3ntokz0A@mail.gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
bacon: Update defconfig

 * Disable unnecessary options

Change-Id: I3e9efc8f74ece07a922f49dde678eb5b35ea3a22
ak_bacon_defconfig: merged with 20140927 commits
Kernel Version: AKernel.042.opo.cm11
Merge remote-tracking branch 'AK/ak-11.0-nightly-rebased' into sensei-cm11