Back to stock resume speed
Remove extra slash \
arm: Allow CPU-supported unaligned accesses

This change reconfigures the CPU to allow CPU-supported unaligned
accesses, which are generally faster than software-only fixups,
resulting in fewer alignment exceptions.
kernel: scheduler features: turn off GENTLTE_FAIR_SLEEPERS

-Theoretically should improve UI performance on Android
lib/sha1: use the git implementation of SHA-1
For ChromiumOS, we use SHA-1 to verify the integrity of the root
filesystem.  The speed of the kernel sha-1 implementation has a major
impact on our boot performance.

To improve boot performance, we investigated using the heavily optimized
sha-1 implementation used in git.  With the git sha-1 implementation, we
see a 11.7% improvement in boot time.

10 reboots, remove slowest/fastest.

Before:

  Mean: 6.58 seconds Stdev: 0.14

After (with git sha-1, this patch):

  Mean: 5.89 seconds Stdev: 0.07

The other cool thing about the git SHA-1 implementation is that it only
needs 64 bytes of stack for the workspace while the original kernel
implementation needed 320 bytes.

Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Nicolas Pitre <nico@cam.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sched, fair: Let minimally loaded cpu balance the group
Currently we let the leftmost (or first idle) cpu acend the
sched_domain tree and perform load-balancing. The result is that the
busiest cpu in the group might be performing this function and pull
more load to itself. The next load balance pass will then try to
equalize this again.

Change this to pick the least loaded cpu to perform higher domain
balancing.
Remove ARM sha1 routines
Since commit 8827a4a
("lib/sha1: use the git implementation of SHA-1"), the ARM SHA1
routines no longer work. The reason? They depended on the larger
320-byte workspace, and now the sha1 workspace is just 16 words
(64 bytes). So the assembly version would overwrite the stack randomly.

The optimized asm version is also probably slower than the new improved
C version, so there's no reason to keep it around.  At least that was
the case in git, where what appears to be the same assembly language
version was removed two years ago because the optimized C BLK_SHA1 code
was faster.

Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
lib/memcopy: use glibc version

the kernel's memcpy and memmove is very inefficient. But the glibc
version is quite fast, in some cases it is 10 times faster than the
kernel version. So I introduce some memory copy macros and functions of
the glibc to improve the kernel version's performance.

The strategy of the memory functions is:
1. Copy bytes until the destination pointer is aligned.
2. Copy words in unrolled loops.  If the source and destination are not
   aligned in the same way, use word memory operations, but shift and
merge two read words before writing.
3. Copy the few remaining bytes.
Revert "sched, fair: Let minimally loaded cpu balance the group Currently we let the leftmost (or first idle) cpu acend the sched_domain tree and perform load-balancing. The result is that the busiest cpu in the group might be performing this function and pull more load to itself. The next load balance pass will then try to equalize this again."

This reverts commit baba795e34f8ff3777d918ef2d6a8bc0117c4b1b.
kernel/mutex.c: update to upstream 3.0
This fixes various mutex_lock problems.
tps80031-regulator.c fixes from Nvidia

(1) regulator: tps80031: use correct voltage conversion formula
The correct voltage conversion formula for the register programming
is:  Code=((Vout-0.6077)/0.01266)+1
Changing existing formula to above equation.
bug 915859
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>

(2) regulator: tps80031: Correct voltage selection logics
Fixing the voltage selection logics for a given mininum/maximum
range.
bug 934544
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
SPI fixes

SPI: tegra: Pass rx data only to req bit length
When fifo is read, it can contain valid data bits and random bits
in rest of the fifo.
Reading only valid bits from fifo and resetting rest to zero
before sending to client.
Varun Wadekar <vwadekar@nvidia.com>

spi: tegra: Add runtime PM support
Bug 886806
Ashwini Ghuge <aghuge@nvidia.com>

spi: tegra: use run time pm apis for clock control
Used run time apis for clock controls i.e. clock enable/
disable in place of direct clock apis.
Using of runtime pm api was already implemented but it was
missed on probe where it was calling clock_disable.
Fixing this issue.
bug 928541
Laxman Dewangan <ldewangan@nvidia.com>
Fixed some code style issues
Updated defconfigs

-G
Missed header file in previous commit: kernel/mutex.h: update to
upstream 3.0
Asynchronous I/O latency to a solid-state disk greatly increased
between the 2.6.32 and 3.0 kernels. By removing the plug from
do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Userspace voltage control, i.e. undervolting

Reference:
-Richard Trip endeavoru (thanks!)
https://github.com/richardtrip/endeavoru/commits/villain
-My Galaxy 8.9 kernel voltage control that was also based on the same
methodology that richardtrip employed on the Acer Iconia A500 tegra 2.
https://github.com/motley-git/Kernel-GT-P73xx-v2