…ABLE_NOISE_TEST_MODE" This reverts commit cd8aaa9.
…I-9100 (GSII), Update 4" This reverts commit 9e2bd0e.
…100), Update 4" This reverts commit 6926fbc.
…tional (in resume)" This reverts commit 3e1bf1e.
Rather than open-coding the jiffy-based wait, and polling for the secondary CPU to come online, use a completion instead. This removes the need to poll, instead we will be notified when the secondary CPU has initialized. Signed-off-by: Russell King <email@example.com>
-reference ch33kybutt http://goo.gl/IuJ2i
We can stall RCU processing on SMP platforms if a CPU sits in its idle loop for a long time. This happens because we don't call irq_enter() and irq_exit() around generic_smp_call_function_interrupt() and friends. Add the necessary calls, and remove the one from within ipi_timer(), so that they're all in a common place. Signed-off-by: Russell King <firstname.lastname@example.org>
Change-Id: I37c5085b91318242612440dfd775ad762996612f Signed-off-by: Todd Poynor <email@example.com>
Based on previous patches by Tero Kristo <firstname.lastname@example.org>, Brian Steuer <email@example.com>, David Ng <firstname.lastname@example.org>, Antti P Miettinen <email@example.com>, and Thomas Renninger <firstname.lastname@example.org> Change-Id: Ic55fedcf6f9310f43a7022fb88e23b0392122769 Signed-off-by: Todd Poynor <email@example.com> Conflicts: drivers/cpufreq/cpufreq_interactive.c
…ctor, and sustain_load -reference https://github.com/arco
Allow speed drop after min_sample_time elapses from last time the current speed was last re-validated as appropriate for current load / input boost. Allow speed bump after min_sample_time (or above_hispeed_delay) elapses from the time the current speed was originally set. Change-Id: Ic25687a7a53d25e6544c30c47d7ab6f27a47bee8 Signed-off-by: Todd Poynor <firstname.lastname@example.org>
For systems that set a common speed for all CPUs, checking current speed here could bypass the intermediate hispeed bump decision for this CPU when another CPU was already at hispeed. This could result in an overly high setting (for all CPUs) in situations where all CPUs were about to drop to load levels that map to hispeed or below. Change-Id: I186f23dcfc5e2b6336cab8b0327f0c8a9a4482bc Signed-off-by: Todd Poynor <email@example.com>
Change-Id: If59c668d514a29febe5c35404fd9d01df8548eb1 Signed-off-by: Todd Poynor <firstname.lastname@example.org> Conflicts: Documentation/cpu-freq/governors.txt
Change-Id: I4d6ac40b23a3790d48e30c37408284e9f955e8fa Signed-off-by: Todd Poynor <email@example.com>
Apply min_sample_time to the last time the current target speed was originally requested or re-validated as appropriate for the current load, not to the time since the current speed was originally set. Avoids periodic dips in speed during bursty loads. Change-Id: I250bda657985de60373f9897cc41f480664d51a1 Signed-off-by: Todd Poynor <firstname.lastname@example.org> Conflicts: drivers/cpufreq/cpufreq_interactive.c
If load is above go_hispeed_load, always go to at least hispeed_freq, even when reducing speed from a higher speed, not just when jumping up from minimum speed. Avoids running at a lower than intended speed after a burst of even higher load. Change-Id: I5b9d2a15ba25ce609b21bac7c724265cf6838dee Signed-off-by: Todd Poynor <email@example.com>
Evaluate spikes in load (below go_hispeed_load) against the maximum speed supported by the device, not the current speed (which tends to make it too difficult to raise speed to intermediate levels until very busy). Change-Id: Ib937006abf8bedb60891a739acd733e89b732ae0 Signed-off-by: Todd Poynor <firstname.lastname@example.org>
…load -reference github.com/arco
Change-Id: Ic13614a3da2faa2d4bd215ca3eb7191614f0cf66 Signed-off-by: Todd Poynor <email@example.com>
This patch (http://goo.gl/iYyln) breaks the kernel boot when lockdep is enabled. v7_setup (called before the MMU is enabled) calls v7_flush_dcache_all, and the save_and_disable_irqs added by this patch ends up calling into lockdep C code (trace_hardirqs_off()) when we are in no position to execute it (no stack, no MMU). The following fixes it. Original Patch: Stephen Boyd <firstname.lastname@example.org> -Reference: https://lkml.org/lkml/2012/2/13/269 dorimanx
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 <email@example.com> Cc: Roland Dreier <firstname.lastname@example.org> Cc: Eric Dumazet <email@example.com> Signed-off-by: Andrew Morton <firstname.lastname@example.org> Signed-off-by: Ezekeel <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com> Cc: Andreas Schwab <firstname.lastname@example.org> Cc: Nicolas Pitre <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
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 <email@example.com> Cc: Ramsay Jones <firstname.lastname@example.org> Cc: Nicolas Pitre <email@example.com> Cc: Herbert Xu <firstname.lastname@example.org> Cc: David S. Miller <email@example.com> Cc: firstname.lastname@example.org Signed-off-by: Linus Torvalds <email@example.com>
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] Conflicts: lib/Makefile
When updating the stats for a given uid it would incorrectly assume IPV4 and pick up the wrong protocol when IPV6. Change-Id: Iea4a635012b4123bf7aa93809011b7b2040bb3d5 Signed-off-by: JP Abgrall <firstname.lastname@example.org>
There was a case that might have seemed like new_tag_stat was not initialized and actually used. Added comment explaining why it was impossible, and a BUG() in case the logic gets changed. Change-Id: I1eddd1b6f754c08a3bf89f7e9427e5dce1dfb081 Signed-off-by: JP Abgrall <email@example.com>