{"push_id":629576960,"size":6,"distinct_size":6,"ref":"refs/heads/mkl","head":"62aec486facf70eca3f8589f5448f0c658212bc8","before":"3cfc0175ed2577db0615adbdee59b471168f8813","commits":[{"sha":"d3f7e41fc0bcef2c3cee6b48e63e5c939d8e1ea3","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"ARM: 7449/1: use generic strnlen_user and strncpy_from_user functions\n\nThis patch implements the word-at-a-time interface for ARM using the\nsame algorithm as x86. We use the fls macro from ARMv5 onwards, where\nwe have a clz instruction available which saves us a mov instruction\nwhen targetting Thumb-2. For older CPUs, we use the magic 0x0ff0001\nconstant. Big-endian configurations make use of the implementation from\nasm-generic.\n\nWith this implemented, we can replace our byte-at-a-time strnlen_user\nand strncpy_from_user functions with the optimised generic versions.\n\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\n\nlib: Sparc's strncpy_from_user is generic enough, move under lib/\n\nTo use this, an architecture simply needs to:\n\n1) Provide a user_addr_max() implementation via asm/uaccess.h\n\n2) Add \"select GENERIC_STRNCPY_FROM_USER\" to their arch Kcnfig\n\n3) Remove the existing strncpy_from_user() implementation and symbol\n   exports their architecture had.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nAcked-by: David Howells <dhowells@redhat.com>\n\nlib: add generic strnlen_user() function\n\nThis adds a new generic optimized strnlen_user() function that uses the\n<asm/word-at-a-time.h> infrastructure to portably do efficient string\nhandling.\n\nIn many ways, strnlen is much simpler than strncpy, and in particular we\ncan always pre-align the words we load from memory.  That means that all\nthe worries about alignment etc are a non-issue, so this one can easily\nbe used on any architecture.  You obviously do have to do the\nappropriate word-at-a-time.h macros.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nkernel: Move REPEAT_BYTE definition into linux/kernel.h\n\nAnd make sure that everything using it explicitly includes\nthat header file.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\n\nword-at-a-time: make the interfaces truly generic\n\nThis changes the interfaces in <asm/word-at-a-time.h> to be a bit more\ncomplicated, but a lot more generic.\n\nIn particular, it allows us to really do the operations efficiently on\nboth little-endian and big-endian machines, pretty much regardless of\nmachine details.  For example, if you can rely on a fast population\ncount instruction on your architecture, this will allow you to make your\noptimized <asm/word-at-a-time.h> file with that.\n\nNOTE! The \"generic\" version in include/asm-generic/word-at-a-time.h is\nnot truly generic, it actually only works on big-endian.  Why? Because\non little-endian the generic algorithms are wasteful, since you can\ninevitably do better. The x86 implementation is an example of that.\n\n(The only truly non-generic part of the asm-generic implementation is\nthe \"find_zero()\" function, and you could make a little-endian version\nof it.  And if the Kbuild infrastructure allowed us to pick a particular\nheader file, that would be lovely)\n\nThe <asm/word-at-a-time.h> functions are as follows:\n\n - WORD_AT_A_TIME_CONSTANTS: specific constants that the algorithm\n   uses.\n\n - has_zero(): take a word, and determine if it has a zero byte in it.\n   It gets the word, the pointer to the constant pool, and a pointer to\n   an intermediate \"data\" field it can set.\n\n   This is the \"quick-and-dirty\" zero tester: it's what is run inside\n   the hot loops.\n\n - \"prep_zero_mask()\": take the word, the data that has_zero() produced,\n   and the constant pool, and generate an *exact* mask of which byte had\n   the first zero.  This is run directly *outside* the loop, and allows\n   the \"has_zero()\" function to answer the \"is there a zero byte\"\n   question without necessarily getting exactly *which* byte is the\n   first one to contain a zero.\n\n   If you do multiple byte lookups concurrently (eg \"hash_name()\", which\n   looks for both NUL and '/' bytes), after you've done the prep_zero_mask()\n   phase, the result of those can be or'ed together to get the \"either\n   or\" case.\n\n - The result from \"prep_zero_mask()\" can then be fed into \"find_zero()\"\n   (to find the byte offset of the first byte that was zero) or into\n   \"zero_bytemask()\" (to find the bytemask of the bytes preceding the\n   zero byte).\n\n   The existence of zero_bytemask() is optional, and is not necessary\n   for the normal string routines.  But dentry name hashing needs it, so\n   if you enable DENTRY_WORD_AT_A_TIME you need to expose it.\n\nThis changes the generic strncpy_from_user() function and the dentry\nhashing functions to use these modified word-at-a-time interfaces.  This\ngets us back to the optimized state of the x86 strncpy that we lost in\nthe previous commit when moving over to the generic version.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nARM: 7450/1: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs\n\nDCACHE_WORD_ACCESS uses the word-at-a-time API for optimised string\ncomparisons in the vfs layer.\n\nThis patch implements support for load_unaligned_zeropad for ARM CPUs\nwith native support for unaligned memory accesses (v6+) when running\nlittle-endian.\n\nChange-Id: Ifdf8207f2581f93870eb0e627f5d12f97c4be7cc\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/d3f7e41fc0bcef2c3cee6b48e63e5c939d8e1ea3"},{"sha":"7c159bbaba6a2fa22c4e097afea6b5b7caa21c2a","author":{"email":"d77b46f71ad07d1c66a004715c9110750816d270@motorola.com","name":"Jason Hrycay"},"message":"msm: memutils: memcpy, memmove, copy_page optimization\n\nPreload farther to take advantage of the memory bus, and assume\n64-byte cache lines.  Unroll some pairs of ldm/stm as well, for\nunexplainable reasons.\n\nFuture enhancements should include,\n\n- #define for how far to preload, possibly defined separately for\n  memcpy, copy_*_user\n- Tuning for misaligned buffers\n- Tuning for memmove\n- Tuning for small buffers\n- Understanding mechanism behind ldm/stm unroll causing some gains\n  in copy_to_user\n\nBASELINE (msm8960pro):\n======================================================================\nmemcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s\ncopy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s\ncopy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s\nmemmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s\ncopy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s\ncopy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s\ncopy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s\n\nTHIS PATCH:\n======================================================================\nmemcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s\ncopy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s\ncopy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s\nmemmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s\ncopy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s\ncopy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s\ncopy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s\n\nSigned-off-by: Chris Fries <C.Fries@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\n\nChange-Id: I9a32a7cb83ca8c13a9c511d356764fe9e32fbb12","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/7c159bbaba6a2fa22c4e097afea6b5b7caa21c2a"},{"sha":"31c1a81c3f3c6bd1ffc2748a9597bf965aa80cfc","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"arm: lib: Fix makefile bug\n\nWhen HAS_MACH_MEMUTILS is defined, two version of memcpy.S would\nbe built at the same time, fix the issue here.\n\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\n\nChange-Id: Icfd5aaa176830e125891fa536bee850dba938fc7","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/31c1a81c3f3c6bd1ffc2748a9597bf965aa80cfc"},{"sha":"1c5bbf5a29fd521789a7b7d0ca53fdc99ce9bb81","author":{"email":"915655ad01061a8ee4f5aedf64e4a81e454408f3@codeaurora.org","name":"Ping Li"},"message":"msm: display: Add data stuctures for MSM8974 target support\n\nAdd data structures for picture adjustment, IGC, QSEED2 sharpening/smooth\nfeature support on MSM8974.\nThese data structures are needed by the hardware/qcom/display project,\nwhich is shared between multiple jb branches, including B-family jb\nbranches.\n\nChange-Id: I0e228c90b70dbe4655173b753032eaae5748f7d9\nSigned-off-by: Ping Li <quicpingli@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/1c5bbf5a29fd521789a7b7d0ca53fdc99ce9bb81"},{"sha":"e82069c03cf101eeb1b91031f95b5eb21cd5c6a7","author":{"email":"9ce5770b3bb4b2a1d59be2d97e34379cd192299f@cyngn.com","name":"Steve Kondik"},"message":"video: mdp4: Color temperature interface using PCC\n\n * MDP 4.2 supports Polynomial Color Correction. Use this to implement\n   a simple sysfs API for adjusting RGB scaling values. This can be\n   used to implement color temperature and other controls.\n * Why use this when we have KCAL? This code is dead simple, the\n   interface is in the right place, and it allows for 128X accuracy.\n\nChange-Id: Ie17c84ee3c1092ea65804566bdf05326a34a6d4d","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/e82069c03cf101eeb1b91031f95b5eb21cd5c6a7"},{"sha":"62aec486facf70eca3f8589f5448f0c658212bc8","author":{"email":"239d0dcf4c4fca4a9859e3f56c56755f6b1aec1c@mokeedev.com","name":"martincz"},"message":"Merge branch 'remote' into mkl","distinct":true,"url":"https://api.github.com/repos/MoKee/android_kernel_samsung_msm8930-common/commits/62aec486facf70eca3f8589f5448f0c658212bc8"}]}