Revert "Usual tuning of deadline for flash."

This reverts commit 593901af72a5d81bce754d949abf185cd76aee65.
block: deadline: Optimize for non-rotational [myfluxi]
block: deadline: allow 0ms deadline latency, increase the read speed [tuxiaobing]

Change a timer compare from after to after-equals, thus allowing
0 timeout and making deadline schedule FIFO.

Signed-off-by: xiaobing tu <xiaobing.tu@intel.com
Compile stock and Samsung MTPs together [AndreiLux]
enable CONFIG_USB_ANDROID_SAMSUNG_MTP again.
ARM: implement KERNEL_MODE_NEON [halaszk]

7. Compiler flags updated (NEON)

6. 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>

5. 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>

4. 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>

3. 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>

2. 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>

1. 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>
enable CONFIG_KERNEL_MODE_NEON
arch/arm: compile with full -mfpu=neon-vfpv4 & hard float
gpu: ion: system_heap: add support for 2MB allocations [Mitchel Humpherys]

Enable 2MB (order 9) allocations from the system heap.
 This improves the performance of some heavyweight use cases. The benefit is
 especially large for use cases where the buffer is mapped into an IOMMU since
 we can leverage the 2MB IOMMU page table mappings.

Change-Id: I869733089b9ccba8090bbca80aac7b5f248b335e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
CHROMIUM: clocksource: allow clocksources to be selected earlier during boot [Andrew Bresticker]

Global and per-CPU timers ought to be initialized once SMP initialization
is complete.  Although the clocksources associated with these timers may
not be registered until later in the boot process, they should be ready
to go once registered.  We'd like to stop using the super low-resolution
boot clocksource (jiffies) as soon as possible since devices may rely on
accurate timekeeping while being brought up during boot, so move
clocksource_done_booting() to arch_initcall time so that we can switch
to a higher-resolution clocksrouce earlier in the boot process.

TEST=Pit and Lumpy both still boot reliably.  Boot time on Pit improves
considerably:
Before: [    3.032967] VFS: Mounted root ...
After:  [    1.855936] VFS: Mounted root ...
Lumpy boot time improves very slightly:
Before: [    1.786347] VFS: Mounted root ...
After:  [    1.754297] VFS: Mounted root ...

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
update cyanogenmod_chagallwifi_defconfig to 3.4.105
add a runtime dependency checker [AndreiLux]
mali gpu: lower treshold for 177 to 30 and for 266 to 50 to prevent lagging after idle.
lib: memcopy & string use glibc version [Miao Xie]

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.

Signed-off-by: Miao Xie <miaox*******>
Signed-off-by: faux123 <reioux@gmail.com>