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.

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>
DPLL_CORE_M6_OPP100_RATE should be 266666666 -  from Ezekeel
cpufreq: separate Interactive governor into two, one with static settings and another one with dynamic settings (it adjusts itself according to load). The new governor is called Dynamic Interactive.
Kconfig: disable some useless options
Change 512Mhz GPU to 499,2Mhz to make it multiple of 38,4
Revert "Change 512Mhz GPU to 499,2Mhz to make it multiple of 38,4"

This reverts commit 0f1d3a43d1055a1eec5fe97b92df1f7f37597e59.
Revert "smartreflex-class1p5.c: decrease the nominal voltage needed for SR to skip calibration"

This reverts commit 9a043fd8e100a4a705df0d71591066ba88b58712.
Revert "smartreflex-class1p5.c: change the check from only > 1350mV to >= 1350mV"

This reverts commit 5348be72b2a651ba2de1c9ea6560bfd2ad99ae12.
Revert "smartreflex-class1p5.c: add a routine for SR not to calibrate the MPU step if the nominal voltage is above 1400mV. Original idea from Imoseyon"

This reverts commit d641cc4066f27c0ad945f6bff70ccfa5b5e365e8.
opp4xxx_data.c: Since we removed the hacky routine for disabling SR for some frequencies we gotta make the device to boot with our desired voltages on certain frequencies. So for 230Mhz SR is disabled, from 1420Mhz to 1804Mhz is also disabled. Core OPP1 also has SR disabled. Smartreflex calibrates this OPP too aggressively and it causes a few data drops in the long run. Booting it with more voltage and no calibration should help on data dropage.
Set PVR driver chip clock. Also add an extra step, 384Mhz on the 512Mhz build. Should reduce the amount of times 512Mhz is used.
opp4xxx_data.c: remove 384Mhz GPU step from 512Mhz GPU build.
omap4: pvr: comment unused defines
opp4xxx_data.c: bump Core OPP1 voltage by 25mV for stability
opp4xxx_data.c: fix integer pointer initialization
gpu: pvr: comment unused defines to prevent confusion in the future
Revert "Kconfig: disable some useless options"

This reverts commit de05ecbf2cad45e3abd28d855809b6b8d78c98ee.
Prevent a module to be compiled since its useless for us
opp4xxx_data.c: give 10mV margin to 384Mhz CPU slot