Re-patch: block: strict rq_affinity
aio.c: Asynchronous I/O latency to a solid-state disk greatly increased
Fix cflags
tegra3_clocks.c: refactor CPU frequency tables and ajust EMC clock ratios
edp.c: make all cores to go 1,5Ghz max
cpufreq.c: add userspace voltage control. Original implementation from faux123 (which was based on Michael Huang's OMAP4460 work). Interface cleaned up, made more robust and secure
tegra3_dvfs.c: reduce minimum voltage allowed for the CPU from 850mV to 600mV
cpufreq: ondemand: set sampling_time the same as cpu frequency transition latency
cpufreq: fix wrong report of the frequency table in the UV interface.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
timekeeping: fix 32-bit overflow in get_monotonic_boottime

get_monotonic_boottime adds three nanonsecond values stored
in longs, followed by an s64.  If the long values are all
close to 1e9 the first three additions can overflow and
become negative when added to the s64.  Cast the first
value to s64 so that all additions are 64 bit.

Change-Id: Ic996d8b6fbef0b72f2d027b0d8ef5259b5c1a540
Signed-off-by: Colin Cross <ccross@android.com>
tegra: add GPU overclock interface.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tegra: add CPU_LP custom max_frequency interface.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tegra: add mutex_lock and mutex_unlock sik for safety.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tegra: make host1x max_rate scale with GPU's's max frequency.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
tegra: add pll_c scaling based on gpu_freq*2. Also add new core voltage tables for separate types of gpu clocks. Thanks @morfic for all the testings and some of this commit code and ideas.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
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>