Voltage Control: initial voltage control for MSM Snapdragon 800 SOC

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
Voltage Control: add sysfs interface

Signed-off-by: faux123 <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
Reclaim memory from logger

Signed-off-by: aatjitra <aatjitra@gmail.com>
msm8974: Adapt memutils optimizations from msm8960pro

Preload farther to take advantage of the memory bus, and assume
64-byte cache lines.  Unroll some pairs of ldm/stm as well, for
unexplainable reasons.

Future enhancements should include,

- #define for how far to preload, possibly defined separately for
  memcpy, copy_*_user
- Tuning for misaligned buffers
- Tuning for memmove
- Tuning for small buffers
- Understanding mechanism behind ldm/stm unroll causing some gains
  in copy_to_user

BASELINE (msm8960pro):
======================================================================
memcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s
copy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s
copy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s
memmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s
copy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s
copy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s
copy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s

THIS PATCH:
======================================================================
memcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s
copy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s
copy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s
memmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s
copy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s
copy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s
copy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
Update CPU governor to the latest

Signed-off-by: aatjitra <aatjitra@gmail.com>
LCD_KCAL: Color Control driver for Nexus 5

Signed-off-by: aatjitra <aatjitra@gmail.com>

Conflicts:
	arch/arm/mach-msm/lge/board-8974-hammerhead.c

Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
LCD KCAL: Fix Gamma max value issue

Major thanks to Yorici Vz for his tireless pursuit of perfection on Nexus 5
Color / Gamma :D

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
arch/arm/mach-msm/cpufreq.c: reduce dmesg log spam

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: move VFP init to an earlier boot stage

In order to use the NEON unit in the kernel, we should
initialize it a bit earlier in the boot process so NEON users
that like to do a quick benchmark at load time (like the
xor_blocks or RAID-6 code) find the NEON/VFP unit already
enabled.

Replaced late_initcall() with core_initcall().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: be strict about FP exceptions in kernel mode

The support code in vfp_support_entry does not care whether the
exception that caused it to be invoked occurred in kernel mode or
in user mode. However, neither condition that could trigger this
exception (lazy restore and VFP bounce to support code) is
currently allowable in kernel mode.

In either case, print a message describing the condition before
letting the undefined instruction handler run its course and trigger
an oops.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: add support for kernel mode NEON

In order to safely support the use of NEON instructions in
kernel mode, some precautions need to be taken:
- the userland context that may be present in the registers (even
  if the NEON/VFP is currently disabled) must be stored under the
  correct task (which may not be 'current' in the UP case),
- to avoid having to keep track of additional vfpstates for the
  kernel side, disallow the use of NEON in interrupt context
  and run with preemption disabled,
- after use, re-enable preemption and re-enable the lazy restore
  machinery by disabling the NEON/VFP unit.

This patch adds the functions kernel_neon_begin() and
kernel_neon_end() which take care of the above. It also adds
the Kconfig symbol KERNEL_MODE_NEON to enable it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: crypto: add NEON accelerated XOR implementation

Add a source file xor-neon.c (which is really just the reference
C implementation passed through the GCC vectorizer) and hook it
up to the XOR framework.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: 7835/2: fix modular build of xor_blocks() with NEON enabled

Commit 0195659 introduced a NEON accelerated version of the xor_blocks()
function, but it needs the changes in this patch to allow it to be built
as a module rather than statically into the kernel.

This patch creates a separate module xor-neon.ko which exports the NEON
inner xor_blocks() functions depended upon by the regular xor.ko if it
is built with CONFIG_KERNEL_MODE_NEON=y

Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: aatjitra <aatjitra@gmail.com>
ARM: only allow kernel mode neon with AEABI

This prevents the linker erroring with:

arm-linux-ld: error: arch/arm/lib/xor-neon.o uses VFP instructions, whereas arch/arm/lib/built-in.o does not
arm-linux-ld: failed to merge target specific data of file arch/arm/lib/xor-neon.o

This is due to the non-neon files being marked as containing FPA data/
instructions (even though they do not) being mixed with files which
contain VFP, which is an incompatible floating point format.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: aatjitra <aatjitra@gmail.com>
drivers/input/touchscreen/touch_synaptics_ds5.c: No suspend irq

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
add sweep2wake source files

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
sweep2wake: add qpnp-power-on hooks for the power key

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
drivers/input/touchscreen/touch_synaptics_ds5: add is_single_touch & s2w detection hook

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
sweep2wake: backport per device settings from sweep2wake2 (like pwr btn choice too)

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>
drivers/input/touchscreen/touch_synaptics_ds5: disable suspend if sweep2wake is enabled

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
Signed-off-by: aatjitra <aatjitra@gmail.com>