arm/crypto: Add optimized AES and SHA1 routines

Add assembler versions of AES and SHA1 for ARM platforms.  This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.

Platform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement

IXP425      533 MHz      big     11217042        15566294        ~38%
KS8695      166 MHz     little    3828549         5795373        ~51%

Signed-off-by: David McCullough <ucdevel@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: aatjitra <aatjitra@gmail.com>

Conflicts:
	arch/arm/crypto/Makefile
ARM: add support for bit sliced AES using NEON instructions

Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
and around 25% for decryption. This implementation of the AES algorithm
does not rely on any lookup tables so it is believed to be invulnerable
to cache timing attacks.

This algorithm processes up to 8 blocks in parallel in constant time. This
means that it is not usable by chaining modes that are strictly sequential
in nature, such as CBC encryption. CBC decryption, however, can benefit from
this implementation and runs about 25% faster. The other chaining modes
implemented in this module, XTS and CTR, can execute fully in parallel in
both directions.

The core code has been adopted from the OpenSSL project (in collaboration
with the original author, on cc). For ease of maintenance, this version is
identical to the upstream OpenSSL code, i.e., all modifications that were
required to make it suitable for inclusion into the kernel have been made
upstream. The original can be found here:

    http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130

Note to integrators:
While this implementation is significantly faster than the existing table
based ones (generic or ARM asm), especially in CTR mode, the effects on
power efficiency are unclear as of yet. This code does fundamentally more
work, by calculating values that the table based code obtains by a simple
lookup; only by doing all of that work in a SIMD fashion, it manages to
perform better.

Cc: Andy Polyakov <appro@openssl.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: aatjitra <aatjitra@gmail.com>

Conflicts:
	arch/arm/crypto/Makefile
msm: mdss: Enable solid fill on pipe

Add support to enable solid fill on pipe with an option to
configure fill-color by userspace. This support does not confine
to background pipe and can be used to enable solid fill on any source
surface processing pipes irrespective of the z-order.
This support can be used in requirements involving constant
color layers.

Change-Id: Iae3c2968ca2f2f1be161e9c2f857641ffbb859e5
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
Signed-off-by: aatjitra <aatjitra@gmail.com>
msm: mdss: Use MDP_SOLID_FILL to enable color on pipe

To enable constant color on a pipe, set MDP_SOLID_FILL in pipe
flag. This will do a solid fill on the pipe with the color
specified in bg_color.

CRs-Fixed:592032
Change-Id: I3201e2fa657a6fc6d0e7f51f8585366afc3d29a3
Signed-off-by: Mayank Chopra <makchopra@codeaurora.org>
Signed-off-by: aatjitra <aatjitra@gmail.com>