GitHub PushEvent at 2014-05-11 05:46:15
Repository: KashKernel_MT6589
Actor: kashifmin
Payload: {"shas":[["c0445085fc6eb73aa59b6a5854a642f32b78af47","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib/string: use glibc version\n\nthe performance of memcpy and memmove of the general version is very\ninefficient, this patch improved them.\n\nSigned-off-by: Miao Xie <miaox*******>\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["c7b9bbcd1b62bdf91fa44518b79864e4f86b68c5","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","Optimized ARM RWSEM algorithm\n\nRWSEM implementation for ARM using atomic functions.\nHeavily based on arch/sh/include/asm/rwsem.h\n\nSigned-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>","faux123",true],["0f1ae03095251ad2cb7116c4d1886d2607728331","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","arm/crypto: Add optimized AES and SHA1 routines\n\nAdd assembler versions of AES and SHA1 for ARM platforms.  This has provided\nup to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.\n\nPlatform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement\n\nIXP425      533 MHz      big     11217042        15566294        ~38%\nKS8695      166 MHz     little    3828549         5795373        ~51%\n\nSigned-off-by: David McCullough <ucdevel@gmail.com>\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["02c3d80221755385d00bf22c643155323ac78e7b","300a2d193222dd0c23d880e16d727d352b404a01@oberhumer.com","lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c\n\nRename the source file to match the function name and thereby\nalso make room for a possible future even slightly faster\n\"non-safe\" decompressor version.\n\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>","Markus F.X.J. Oberhumer",true],["8efdd490cbe56bd983adfdb32065b428a5b8fc7a","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib/lzo: Update LZO compression to current upstream version\n\nThis commit updates the kernel LZO code to the current upsteam version\nwhich features a significant speed improvement - benchmarking the Calgary\nand Silesia test corpora typically shows a doubled performance in\nboth compression and decompression on modern i386/x86_64/powerpc machines.\n\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>\n\nConflicts:\n\tinclude/linux/lzo.h\n\nConflicts:\n\n\tinclude/linux/lzo.h","faux123",true],["90c714914ad3a485cf4aac73b8e1b4579e6aaca8","300a2d193222dd0c23d880e16d727d352b404a01@oberhumer.com","lib/lzo: Optimize code for CPUs with inefficient unaligned access\n\nSome code paths are only benefical on machines with fast unaligned\nloads, so only use these if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS\ndefined.\n\nSigned-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>","Markus F.X.J. Oberhumer",true],["27d36e7001dfa5cdfd57355d661c0ad15fadc0ca","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","ARM: 7493/1: use generic unaligned.h\n\nThis moves ARM over to the asm-generic/unaligned.h header. This has the\nbenefit of better code generated especially for ARMv7 on gcc 4.7+\ncompilers.\n\nAs Arnd Bergmann, points out: The asm-generic version uses the \"struct\"\nversion for native-endian unaligned access and the \"byteshift\" version\nfor the opposite endianess. The current ARM version however uses the\n\"byteshift\" implementation for both.\n\nThanks to Nicolas Pitre for the excellent analysis:\n\nTest case:\n\nint foo (int *x) { return get_unaligned(x); }\nlong long bar (long long *x) { return get_unaligned(x); }\n\nWith the current ARM version:\n\nfoo:\n\tldrb\tr3, [r0, #2]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]\n\tldrb\tr1, [r0, #1]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]\n\tldrb\tr2, [r0, #0]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]\n\tmov\tr3, r3, asl #16\t@ tmp154, MEM[(const u8 *)x_1(D) + 2B],\n\tldrb\tr0, [r0, #3]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]\n\torr\tr3, r3, r1, asl #8\t@, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],\n\torr\tr3, r3, r2\t@ tmp157, tmp155, MEM[(const u8 *)x_1(D)]\n\torr\tr0, r3, r0, asl #24\t@,, tmp157, MEM[(const u8 *)x_1(D) + 3B],\n\tbx\tlr\t@\n\nbar:\n\tstmfd\tsp!, {r4, r5, r6, r7}\t@,\n\tmov\tr2, #0\t@ tmp184,\n\tldrb\tr5, [r0, #6]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]\n\tldrb\tr4, [r0, #5]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]\n\tldrb\tip, [r0, #2]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]\n\tldrb\tr1, [r0, #4]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]\n\tmov\tr5, r5, asl #16\t@ tmp175, MEM[(const u8 *)x_1(D) + 6B],\n\tldrb\tr7, [r0, #1]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]\n\torr\tr5, r5, r4, asl #8\t@, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],\n\tldrb\tr6, [r0, #7]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]\n\torr\tr5, r5, r1\t@ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]\n\tldrb\tr4, [r0, #0]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]\n\tmov\tip, ip, asl #16\t@ tmp188, MEM[(const u8 *)x_1(D) + 2B],\n\tldrb\tr1, [r0, #3]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]\n\torr\tip, ip, r7, asl #8\t@, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],\n\torr\tr3, r5, r6, asl #24\t@,, tmp178, MEM[(const u8 *)x_1(D) + 7B],\n\torr\tip, ip, r4\t@ tmp191, tmp189, MEM[(const u8 *)x_1(D)]\n\torr\tip, ip, r1, asl #24\t@, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],\n\tmov\tr1, r3\t@,\n\torr\tr0, r2, ip\t@ tmp171, tmp184, tmp194\n\tldmfd\tsp!, {r4, r5, r6, r7}\n\tbx\tlr\n\nIn both cases the code is slightly suboptimal.  One may wonder why\nwasting r2 with the constant 0 in the second case for example.  And all\nthe mov's could be folded in subsequent orr's, etc.\n\nNow with the asm-generic version:\n\nfoo:\n\tldr\tr0, [r0, #0]\t@ unaligned\t@,* x\n\tbx\tlr\t@\n\nbar:\n\tmov\tr3, r0\t@ x, x\n\tldr\tr0, [r0, #0]\t@ unaligned\t@,* x\n\tldr\tr1, [r3, #4]\t@ unaligned\t@,\n\tbx\tlr\t@\n\nThis is way better of course, but only because this was compiled for\nARMv7. In this case the compiler knows that the hardware can do\nunaligned word access.  This isn't that obvious for foo(), but if we\nremove the get_unaligned() from bar as follows:\n\nlong long bar (long long *x) {return *x; }\n\nthen the resulting code is:\n\nbar:\n\tldmia\tr0, {r0, r1}\t@ x,,\n\tbx\tlr\t@\n\nSo this proves that the presumed aligned vs unaligned cases does have\ninfluence on the instructions the compiler may use and that the above\nunaligned code results are not just an accident.\n\nStill... this isn't fully conclusive without at least looking at the\nresulting assembly fron a pre ARMv6 compilation.  Let's see with an\nARMv5 target:\n\nfoo:\n\tldrb\tr3, [r0, #0]\t@ zero_extendqisi2\t@ tmp139,* x\n\tldrb\tr1, [r0, #1]\t@ zero_extendqisi2\t@ tmp140,\n\tldrb\tr2, [r0, #2]\t@ zero_extendqisi2\t@ tmp143,\n\tldrb\tr0, [r0, #3]\t@ zero_extendqisi2\t@ tmp146,\n\torr\tr3, r3, r1, asl #8\t@, tmp142, tmp139, tmp140,\n\torr\tr3, r3, r2, asl #16\t@, tmp145, tmp142, tmp143,\n\torr\tr0, r3, r0, asl #24\t@,, tmp145, tmp146,\n\tbx\tlr\t@\n\nbar:\n\tstmfd\tsp!, {r4, r5, r6, r7}\t@,\n\tldrb\tr2, [r0, #0]\t@ zero_extendqisi2\t@ tmp139,* x\n\tldrb\tr7, [r0, #1]\t@ zero_extendqisi2\t@ tmp140,\n\tldrb\tr3, [r0, #4]\t@ zero_extendqisi2\t@ tmp149,\n\tldrb\tr6, [r0, #5]\t@ zero_extendqisi2\t@ tmp150,\n\tldrb\tr5, [r0, #2]\t@ zero_extendqisi2\t@ tmp143,\n\tldrb\tr4, [r0, #6]\t@ zero_extendqisi2\t@ tmp153,\n\tldrb\tr1, [r0, #7]\t@ zero_extendqisi2\t@ tmp156,\n\tldrb\tip, [r0, #3]\t@ zero_extendqisi2\t@ tmp146,\n\torr\tr2, r2, r7, asl #8\t@, tmp142, tmp139, tmp140,\n\torr\tr3, r3, r6, asl #8\t@, tmp152, tmp149, tmp150,\n\torr\tr2, r2, r5, asl #16\t@, tmp145, tmp142, tmp143,\n\torr\tr3, r3, r4, asl #16\t@, tmp155, tmp152, tmp153,\n\torr\tr0, r2, ip, asl #24\t@,, tmp145, tmp146,\n\torr\tr1, r3, r1, asl #24\t@,, tmp155, tmp156,\n\tldmfd\tsp!, {r4, r5, r6, r7}\n\tbx\tlr\n\nCompared to the initial results, this is really nicely optimized and I\ncouldn't do much better if I were to hand code it myself.\n\nSigned-off-by: Rob Herring <rob.herring@calxeda.com>\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nTested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\nReviewed-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nmodified for Mako from kernel.org reference\n\nSigned-off-by: faux123 <reioux@gmail.com>\n\nConflicts:\n\tarch/arm/include/asm/unaligned.h\n\nConflicts:\n\n\tarch/arm/include/asm/unaligned.h","faux123",true],["aad82c19c1a375cf0cd7d922eb7f945a45095dd4","aa00819e304141d872f2e4b1c4be422ea3abbfe1@calxeda.com","ARM: 7492/1: add strstr declaration for decompressors\n\nWith the generic unaligned.h, more kernel headers get pulled in including\ndynamic_debug.h which needs strstr. As it is not really used, we only need\na declaration here.\n\nSigned-off-by: Rob Herring <rob.herring@calxeda.com>\nTested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\nReviewed-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Rob Herring",true],["a49946a19821ee5f45416e67c493a596bbced0a9","b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","ARM: 7592/1: nommu: prevent generation of kernel unaligned memory accesses\n\nRecent ARMv7 toolchains assume that unaligned memory accesses will not\nfault and will instead be handled by the processor.\n\nFor the nommu case (without an MPU), memory will be treated as\nstrongly-ordered and therefore unaligned accesses may fault regardless\nof the SCTLR.A setting.\n\nThis patch passes -mno-unaligned-access to GCC when compiling for nommu\ntargets, preventing the generation of unaligned memory access in the\nkernel.\n\nAcked-by: Nicolas Pitre <nico@linaro.org>\nTested-by: Jonathan Austin <jonathan.austin@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Will Deacon",true],["7efde31a9245f876f1e86aa5a31dd2bbbe138131","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","decompress_unlzo: fix compilation error\n\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["2507ee436f9c05848a8001dc30c96619c68900fd","e5de08c96da1cc296eb9ce61b18b8780882255a2@gmail.com","SCHEDULER: Autogroup patch group by current user android UID instead of task ID","Lance Poore",true],["980673fede37849bb29b8a1d696b7f1a3d7f7192","1e0ce936bb9b355d257bf5790d2513c3f28be22b@linux.vnet.ibm.com","fs/sync: Make sync() satisfy many requests with one invocation\n\nDave Jones reported RCU stalls, overly long hrtimer interrupts, and\namazingly long NMI handlers from a trinity-induced workload involving\nlots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).\nThere are any number of things that one might do to make sync() behave\nbetter under high levels of contention, but it is also the case that\nmultiple concurrent sync() system calls can be satisfied by a single\nsys_sync() invocation.\n\nGiven that this situation is reminiscent of rcu_barrier(), this commit\napplies the rcu_barrier() approach to sys_sync().  This approach uses\na global mutex and a sequence counter.  The mutex is held across the\nsync() operation, which eliminates contention between concurrent sync()\noperations.  The counter is incremented at the beginning and end of\neach sync() operation, so that it is odd while a sync() operation is in\nprogress and even otherwise, just like sequence locks.\n\nThe code that used to be in sys_sync() is now in do_sync(), and sys_sync()\nnow handles the concurrency.  The sys_sync() function first takes a\nsnapshot of the counter, then acquires the mutex, and then takes another\nsnapshot of the counter.  If the values of the two snapshots indicate that\na full do_sync() executed during the mutex acquisition, the sys_sync()\nfunction releases the mutex and returns (\"Our work is done!\").  Otherwise,\nsys_sync() increments the counter, invokes do_sync(), and increments\nthe counter again.\n\nThis approach allows a single call to do_sync() to satisfy an arbitrarily\nlarge number of sync() system calls, which should eliminate issues due\nto large numbers of concurrent invocations of the sync() system call.\n\nChanges since v1 (https://lkml.org/lkml/2013/7/24/683):\n\no\tAdd a pair of memory barriers to keep the increments from\n\tbleeding into the do_sync() code.  (The failure probability\n\tis insanely low, but when you have several hundred million\n\tdevices running Linux, you can expect several hundred instances\n\tof one-in-a-million failures.)\n\no\tActually CC some people who have experience in this area.\n\nReported-by: Dave Jones <davej@redhat.com>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Alexander Viro <viro@zeniv.linux.org.uk>\nCc: Christoph Hellwig <hch@lst.de>\nCc: Jan Kara <jack@suse.cz>\nCc: Curt Wohlgemuth <curtw@google.com>\nCc: Jens Axboe <jaxboe@fusionio.com>\nCc: linux-fsdevel@vger.kernel.org\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul E. McKenney",true],["ad51ee4bc950e59249a9e44cce57cb2139493b56","51b0aed1a48556115b152d4619664105ddea9243@lge.com","decompressor: Add LZ4 decompressor module\n\nDate\tTue, 26 Feb 2013 15:24:27 +0900\n\nThis patch adds support for LZ4 decompression in the Linux Kernel.\nLZ4 Decompression APIs for kernel are based on LZ4 implementation\nby Yann Collet.\n\nLZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html\nLZ4 source repository : http://code.google.com/p/lz4/\n\nSigned-off-by: Kyungsik Lee <kyungsik.lee@lge.com>\n\nv2:\n- Clean up code\n- Enable unaligned access for ARM v6 and above with\n  CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS\n- Add lz4_decompress() for faster decompression with\n  uncompressed output size\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Kyungsik Lee",true],["ecc8712001fed88593df2056885b12d143402313","4fc5dc16b2f6af80c339ad07af1610737253f28c@googlemail.com","Added CPUfreq governor 'wheatley'\n\nThanks to r_data for taking the time to fix all the build errors for the Nexus 4.","Ezekeel",true],["9b68849d9679c89ec50d88010a86aa308036c6d6","58aaa54a95c8120fa14f3a1bc7ef6ebc3dafafbe@gmail.com","Add intelliplug 2.0 and misc kernel fixes\nSigned-off-by: Braydon Saporito <altabraydon@gmail.com>\n\nConflicts:\n\tarch/arm/mach-msm/Kconfig","Paul Reioux",true],["150b95043fa9523d8a0dab2c0a268e9703c1e946","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","scripts: remove localversion \"+\" from kernel version strings\n\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["c182a1de0f6fea69b065eafbbecb627ceb9f24d8","56db94a65c3e3a6043f0d37512cd99ded0879598@gmail.com","Fix compilation errors + add missing header","kashifmin",true]],"size":17,"ref":"refs/heads/master","head":"c182a1de0f6fea69b065eafbbecb627ceb9f24d8"}