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: 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.

Change-Id: I6ec1a724cfc6dcf228c0bae7f0b867c6435a92f1
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>
ARM: Fix deadlock scenario with smp_send_stop()

If one process calls sys_reboot and that process then stops other
CPUs while those CPUs are within a spin_lock() region we can
potentially encounter a deadlock scenario like below.

CPU 0                   CPU 1
-----                   -----
                        spin_lock(my_lock)
smp_send_stop()
 send_IPI               handle_IPI()
                         disable_preemption/irqs
                          while(1);
 <PREEMPT>
spin_lock(my_lock) <--- Waits forever

We shouldn't attempt to run any other tasks after we send a stop
IPI to a CPU so disable preemption so that this task runs to
completion.

Change-Id: I528af0b4448433bd9d6ca12d6a0e2c422a55d4be
CRs-Fixed: 396169
Reported-by: Sundarajan Srinivasan <sundaraj@codeaurora.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
msm_fb: display: Update mdp clocks based on perf patch

MDP clock was not getting updated to the correct values
causing underrun issues.

Change-Id: I4902ede1a8dda7408384261ca352e1ca1057a69c
Crs-Fixed: 395054, 395166
Signed-off-by: Siddhartha Agrawal <agrawals@codeaurora.org>
Revert "msm: Add sysfs interface for mfreq"

Remove mfreq sysfs interface as the functionality to boost
CPU clocks to maximum is no longer needed.

This reverts commit c79a2e06447a6253f24142b0143ab9b1b2a1e488.

CRs-Fixed: 335675
Change-Id: Ic6f0ad40e15a0f6c234617a430387517d3556b0c
Signed-off-by: David Ng <dave@codeaurora.org>
msm: cpufreq: Add API to allow limiting of min and max cpu frequencies

CPUFreq provides scaling sysfs nodes to set min and max frequencies, but
there are times when the operating range has to be controlled
irrespective of the scaling limits, to ensure the thermal stability of
the device.

The API allows kernel thermal safeguards to pitch in and limit the
frequencies.

Change-Id: I3dc7496747792e6223695131f1644dd87054b025
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
msm_fb: display: free base layer pipe at adb stop

Base layer pipe need to be freed at adb stop so that same
pipe can be allocated at adb start.

CRs-fixed: 390644
Change-Id: I948bb27687cfe1c96cc3b071b7bb9bb84b2c52c6
Signed-off-by: Kalyan Thota <kalyant@codeaurora.org>
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm: vidc: suppress non-fatal error messages.

These messages are non-fatal and appear frequently
during video session. Hence suppressing them.

CRs-fixed: 389408
Signed-off-by: Arun Menon <menon@codeaurora.org>
(cherry picked from commit 24631e349a3f306cc3b06fb411d5fb1f7ac8f0ae)

Conflicts:

	drivers/video/msm/vidc/1080p/ddl/vcd_ddl_shared_mem.c
	drivers/video/msm/vidc/1080p/ddl/vcd_ddl_utils.c

Change-Id: Ifb874912ac79c863ed8fc531272d3822d8aebebe
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
msm:vidc: add support for pause in eos state

This commit will add support for pause command in
eos state along with run state of the video driver.

(cherry picked from commit da817ebe8a4dea682b2cc9beaa582e0f0f0f0112)

Change-Id: Ia75c7ee43fb13cab5898ded69459469ddec4be54
CRs-fixed: 387562
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
cpufreq: ondemand: Add duration for boosting

 * Keep default behavior of 500ms boost if "1" is given, otherwise use
   the value (microseconds) as the boost duration.

Change-Id: Id38adef1aece7b5609689e50d33cb11b74a352c5
drivers: cpufreq: Add max duration for boosting

 * Don't allow boosting for more than 5 seconds.

Change-Id: Ib602c398ab117ee06c9fa113b1dc9042f1255a8f
Merge remote-tracking branch 'upstream/jellybean' into jellybean