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.

Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
[PATCH v1] tegra: remove the clock sleepable WARNING
mmc: core: Claim host while freeing card

When SD/MMC card is removed without unmounting and
then reinserted again while gendisk is freed. Partition
invalidation and deletion may take more than 10secs during
which SDCC controller can suspend due to runtime pm functionality.
Once the block layer activity is done it claims host to detach card
from MMC bus which triggers SDCC resume. As the host->card is
NULL  already there is a BUG_ON hit in mmc_sd_resume(). Fix this
by claiming host even before we free host->card.

CRs-Fixed: 284262
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 5eed6a9778440ef512f597b43368337a7ef9438b)

Change-Id: I6b58aab1865a93a025fd9912200ab0beea21be92
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
mmc: core: Increase write data timeout value for bad SDHC cards

SD2.0 specification says the max. timeout for writes is 250msecs
for SDHC cards. But when the card is almost full and there are too few
free sectors, the garbage collectors inside SD card  may take more time
and hence delaying the write more than 250msecs. This typically happens
with cards that don't adhere to specification. Based on this the timeout
is increased to 300msecs but still for some cards this is not sufficient.

Few SanDisk class4 SD cards violate the spec. and may take more time than
expected when the card is full. So increase the data timeout to 800msecs,
otherwise we might see file system corruption due to loss of important FS
metadata in timeouts.

Change-Id: Ie8f0616dbbb2a15d7dbe95cd49eeb2308a5badd1
Signed-off-by: Sujith Reddy Thumma <sthumma@codeaurora.org>
binder: Quiet binder

The majority of the binder messages are not very informative
and useful to the reader. Make them available via debug
mechanisms.

Change-Id: Ie0dbd924e583bf045a99a04d812b52a668b6cbb2
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
USB: f_mass_storage: Disable write cache support

As part of mode sense CBW command, communicate to the
host that write cache support is enabled and due to this
during the write commnd, the host is asking for FUA and
because of this write performance is degrading. Hence during
mode sense command, intimate the host that write cache is not
supported.
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>
lib: Introduce some memory copy macros and functions
    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.

 [ported to 3.0]
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>
arm: remove "optimized" SHA1 routines

Since commit 1eb19a12bd22 ("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>
hardfloat + toolchain change
Revert Makefile changes to my version; will pick at Zack's next
Just bring in the stuff from Zach's tree I like for top-level Makefile
LOAD_FREQ (4*HZ+61) avoids loadavg Moire (thx to Klaus Ripke)
unlikely-likely cleanups & optimizations
arm: remove stale export of 'sha_transform'

The generic library code already exports the generic function, this was
left-over from the ARM-specific version that just got removed.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
lib/crc: add slice by 8 algorithm to crc32.c

Add support for slice by 8 to existing crc32 algorithm.  Also modify
gen_crc32table.c to only produce table entries that are actually used.
The parameters CRC_LE_BITS and CRC_BE_BITS determine the number of bits in
the input array that are processed during each step.  Generally the more
bits the faster the algorithm is but the more table data required.

Using an x86_64 Opteron machine running at 2100MHz the following table was
collected with a pre-warmed cache by computing the crc 1000 times on a
buffer of 4096 bytes.

BITS Size LE Cycles/byte BE Cycles/byte
----------------------------------------------
1 873 41.65 34.60
2 1097 25.43 29.61
4 1057 13.29 15.28
8 2913 7.13 8.19
32 9684 2.80 2.82
64 18178 1.53 1.53

BITS is the value of CRC_LE_BITS or CRC_BE_BITS. The old
default was 8 which actually selected the 32 bit algorithm. In
this version the value 8 is used to select the standard
8 bit algorithm and two new values: 32 and 64 are introduced
to select the slice by 4 and slice by 8 algorithms respectively.

Where Size is the size of crc32.o's text segment which includes
code and table data when both LE and BE versions are set to BITS.

The current version of crc32.c by default uses the slice by 4 algorithm
which requires about 2.8 cycles per byte.  The slice by 8 algorithm is
roughly 2X faster and enables packet processing at over 1GB/sec on a
typical 2-3GHz system.

Signed-off-by: Bob Pearson <rpearson@systemfabricworks.com>
Cc: Roland Dreier <roland@kernel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ezekeel <notezekeel@googlemail.com>
ARM: tegra: stingray: turn on CPU-supported unaligned accesses
ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR
Get rid of the CFLAG "-mstructure-size-boundary=32"

Made the front-facing camera (and God knows what else) not work.
(I'm now not sure what to trust of any of the changes past the
floating-point stuff; one more issue and they're all outta here.)