{"push_id":2941899253,"size":20,"distinct_size":20,"ref":"refs/heads/gamma","head":"6daf3fbe6e897437f1f50a58b246bc9faab4e2ae","before":"69b70f1219bffc45c740e0572691c7cc8bbccd3c","commits":[{"sha":"8767ae95070f5345bf7ac1146830a7e7567a9f9a","author":{"name":"Omar Avelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"v20: Import LG msm8996 LineageOS base on top of CAF.\nKeeping the stock V20 and Qualcomm's HMP base as default for now.","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/8767ae95070f5345bf7ac1146830a7e7567a9f9a"},{"sha":"5df565faba84a4a7ef52236ebf64d8efa67db48e","author":{"name":"tbalden","email":"8757d1b25d3b16a8689f4b9cad39991c5b230a48@gmail.com"},"message":"mdss mdp: kcal for mdss_mdp_v1_7\n\nAdding the kcal interface by @savoca and\n@faux123\nporting from m9 version by @flar2\n\nUsing the MDP 1_7 userspace structs to inject\nconfigurations of kcal to the pp_cache configs.\nOverriding userspace copy with memcpy when\ncopy_from_user fails (in case of kcal interface\nused).\n\nAdding a simple mdp ctl struct caching to\nthe kcal driver to grab ctl struct for config\ncalls.\n\nCould be done nicer with direct interfacing\nto userspace, leaves some space to make the kernel\ncrash if a third party app sends faulty configs,\nbut there's no security issue or degradation\nof functionality with this memcpy patch.\n\n@tbalden\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nMinor fixup during the merge\n\nmsm: mdss: KCAL: Send a pp display commit when changes are made\n\nSending a PP display commit when changes are made, to prevent waiting on a panel update from\nsome other part of the kernel. Sending a display commit takes care of locking and panel state\nchecking for us.\n\nQC MDSS also handles queue-ing already for us, so remove that functionality from KCAL.\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nmsm: mdss: KCAL: disable igc update","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/5df565faba84a4a7ef52236ebf64d8efa67db48e"},{"sha":"047acba57413e5a5570fd9ef4fb3978bf9a14179","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"proc: set androidboot.verifiedbootstate=green","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/047acba57413e5a5570fd9ef4fb3978bf9a14179"},{"sha":"7d122196f3e79b5e7d59dfbbb56b3c3b463e7c1c","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"msm8996: GPU Undervolting\nTrim ~60 mV from the GPU voltage rails and 20mV from the floor","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/7d122196f3e79b5e7d59dfbbb56b3c3b463e7c1c"},{"sha":"cf2bfe3c8ad9c725ec2cd33f97d7820ca607549d","author":{"name":"Pranav Vashi","email":"d688953a19dcb476c5fb90e6abba87f77b09be65@gmail.com"},"message":"ASoC: wcdxxxx: queue work on power efficient wq\n\nChange-Id: I878e2cec9a87f9a1cd09ea15a6821c51aeac80e5\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/cf2bfe3c8ad9c725ec2cd33f97d7820ca607549d"},{"sha":"baab66bd6650e9f4068271582593bce6209c9ecd","author":{"name":"Francisco Franco","email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com"},"message":"drivers: thermal: queue work on system_power_efficient_wq\n\nThere doesn't seem to be any real dependency of scheduling these on\nthe cpu which scheduled them, so moving every *_delayed to the\npower efficient wq save potential needlessly idle cpu wake ups\nleaving the scheduler to decide the most appropriate cpus to wake up.\n\nChange-Id: Ib0917e11c85b7f5db320c56b8a0358a8fa8e8904\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/baab66bd6650e9f4068271582593bce6209c9ecd"},{"sha":"9f9ca1238a0daaa163066d22a7954c52592bdc9b","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"mdss: Enable qcom,panel-allow-phy-poweroff","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/9f9ca1238a0daaa163066d22a7954c52592bdc9b"},{"sha":"370f3a8b98a20f7a329ba6dd583e2f04036588e3","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"boeffla_wl_blocker: add generic wakelock blocker driver v1.1.0\n\nBased on ideas of FranciscoFranco's non-generic driver.\n\nSysfs node:\n\n\t/sys/class/misc/boeffla_wakelock_blocker/wakelock_blocker\n\n\t\t- list of wakelocks to be blocked, separated by semicolons\n\n\t/sys/class/misc/boeffla_wakelock_blocker/debug\n\n\t\t- write: 0/1 to switch off and on debug logging into dmesg\n\t\t- read:  get current driver internals\n\n\t/sys/class/misc/boeffla_wakelock_blocker/version\n\n\t\t- show driver version\n\nThere are now two lists:\n- the previously existing list of user defined wakelocks to block\n- a new list called \"wakelock_blocker_default\" which comes prepopulated with the most common\n  and safe wakelocks to block:\n\n    qcom_rx_wakelock;wlan;wlan_wow_wl;wlan_extscan_wl;netmgr_wl;NETLINK\n\nA combination of both wakelock lists will be blocked finally.\nCurrently active wakelocks on the list are forcefully killed.","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/370f3a8b98a20f7a329ba6dd583e2f04036588e3"},{"sha":"f0184244fe4290ec966b7b310a71804b9b81362d","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"sdfat: Import from https://github.com/cryptomilk/kernel-sdfat","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/f0184244fe4290ec966b7b310a71804b9b81362d"},{"sha":"7316e376e40533361c3ebfb6ecf3e4cc4cdba824","author":{"name":"dianlujitao","email":"426a063be0e36cd758b6e57f81d0d38f9087ed32@lineageos.org"},"message":"msm: camera: isp: Use boot clock for recording start time\n\n * Our camera HAL uses boot time for buffer timestamp, rather than\n   system monotonic time. This leads to issues as framework uses system\n   monotonic time as reference start time for timestamp adjustment.\n * This patch is taken from stock kernel source.\n\nChange-Id: Ia4fac1d48e2206a7befd0030585776371dd8c3a9","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/7316e376e40533361c3ebfb6ecf3e4cc4cdba824"},{"sha":"d20ba042c4a6ad6ca5b70a549cdb632a6035b795","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"v20: Disabling partial panel update for Oreo as a workaround","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/d20ba042c4a6ad6ca5b70a549cdb632a6035b795"},{"sha":"c1aeb3c406f7490be501446b0662dbdfdfb274e3","author":{"name":"Vikram Mulukutla","email":"577f74ec3f2c8a155237d5ad42a70103d17f8313@codeaurora.org"},"message":"Prepare MSM-3.18 base for EAS bringup\n1. Removed HMP\n2. Removed CPU Boost\n3. Removed EAS bits added by CAF\n4. Removed other CAF bits\n5. Reverted Interactive back to Google implementation\n6. Removed kernel/sched to inhert from 4.4","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/c1aeb3c406f7490be501446b0662dbdfdfb274e3"},{"sha":"4eb0a48f91974d1bc11feeb49246bd4d5f8cf6f4","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"EAS: Backported Energy Aware Scheduling from Linux 4.4\n4.4 EAS features into 3.18 Kernel base, working well","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/4eb0a48f91974d1bc11feeb49246bd4d5f8cf6f4"},{"sha":"7a3d49187ae5598c9eff4beea40aef813336e421","author":{"name":"Pranav Vashi","email":"d688953a19dcb476c5fb90e6abba87f77b09be65@gmail.com"},"message":"msm: thermal: Add sysfs nodes to control parameters\n\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\nSigned-off-by: engstk <eng.stk@sapo.pt>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/7a3d49187ae5598c9eff4beea40aef813336e421"},{"sha":"45a60b4d5b9cb8a21aee5c3f9d763c1dbcf8ba9c","author":{"name":"oxavelar","email":"7557861765a1dd65cc0ca5f5cd764463e172a232@gmail.com"},"message":"block: cgroups, kconfig, build bits for BFQ-v7r8-3.18.0\n\nUpdate Kconfig.iosched and do the related Makefile changes to include\nkernel configuration options for BFQ. Also add the bfqio controller\nto the cgroups subsystem.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\n\nblock: introduce the BFQ-v7r8 I/O sched for 3.18.0\n\nAdd the BFQ-v7r8 I/O scheduler to 3.18.0.\nThe general structure is borrowed from CFQ, as much of the code for\nhandling I/O contexts. Over time, several useful features have been\nported from CFQ as well (details in the changelog in README.BFQ). A\n(bfq_)queue is associated to each task doing I/O on a device, and each\ntime a scheduling decision has to be made a queue is selected and served\nuntil it expires.\n\n    - Slices are given in the service domain: tasks are assigned\n      budgets, measured in number of sectors. Once got the disk, a task\n      must however consume its assigned budget within a configurable\n      maximum time (by default, the maximum possible value of the\n      budgets is automatically computed to comply with this timeout).\n      This allows the desired latency vs \"throughput boosting\" tradeoff\n      to be set.\n\n    - Budgets are scheduled according to a variant of WF2Q+, implemented\n      using an augmented rb-tree to take eligibility into account while\n      preserving an O(log N) overall complexity.\n\n    - A low-latency tunable is provided; if enabled, both interactive\n      and soft real-time applications are guaranteed a very low latency.\n\n    - Latency guarantees are preserved also in the presence of NCQ.\n\n    - Also with flash-based devices, a high throughput is achieved\n      while still preserving latency guarantees.\n\n    - BFQ features Early Queue Merge (EQM), a sort of fusion of the\n      cooperating-queue-merging and the preemption mechanisms present\n      in CFQ. EQM is in fact a unified mechanism that tries to get a\n      sequential read pattern, and hence a high throughput, with any\n      set of processes performing interleaved I/O over a contiguous\n      sequence of sectors.\n\n    - BFQ supports full hierarchical scheduling, exporting a cgroups\n      interface.  Since each node has a full scheduler, each group can\n      be assigned its own weight.\n\n    - If the cgroups interface is not used, only I/O priorities can be\n      assigned to processes, with ioprio values mapped to weights\n      with the relation weight = IOPRIO_BE_NR - ioprio.\n\n    - ioprio classes are served in strict priority order, i.e., lower\n      priority queues are not served as long as there are higher\n      priority queues.  Among queues in the same class the bandwidth is\n      distributed in proportion to the weight of each queue. A very\n      thin extra bandwidth is however guaranteed to the Idle class, to\n      prevent it from starving.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\n\nblock, bfq: add Early Queue Merge (EQM) to BFQ-v7r8 for 3.18.0\n\nA set of processes may happen  to  perform interleaved reads, i.e.,requests\nwhose union would give rise to a  sequential read  pattern.  There are two\ntypical  cases: in the first  case,   processes  read  fixed-size chunks of\ndata at a fixed distance from each other, while in the second case processes\nmay read variable-size chunks at  variable distances. The latter case occurs\nfor  example with  QEMU, which  splits the  I/O generated  by the  guest into\nmultiple chunks,  and lets these chunks  be served by a  pool of cooperating\nprocesses,  iteratively  assigning  the  next  chunk of  I/O  to  the first\navailable  process. CFQ  uses actual  queue merging  for the  first type of\nrocesses, whereas it  uses preemption to get a sequential  read pattern out\nof the read requests  performed by the second type of  processes. In the end\nit uses  two different  mechanisms to  achieve the  same goal: boosting the\nthroughput with interleaved I/O.\n\nThis patch introduces  Early Queue Merge (EQM), a unified mechanism to get a\nsequential  read pattern  with both  types of  processes. The  main idea is\nchecking newly arrived requests against the next request of the active queue\nboth in case of actual request insert and in case of request merge. By doing\nso, both the types of processes can be handled by just merging their queues.\nEQM is  then simpler and  more compact than the  pair of mechanisms used in\nCFQ.\n\nFinally, EQM  also preserves the  typical low-latency properties of BFQ, by\nproperly restoring the weight-raising state of a queue when it gets back to\na non-merged state.\n\nSigned-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/45a60b4d5b9cb8a21aee5c3f9d763c1dbcf8ba9c"},{"sha":"b0e5791205b89222c5ce3fc2936a3351088c83c8","author":{"name":"Francisco Franco","email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com"},"message":"power: make sync on suspend optional\n\npropagate from (CR).\n\nOn embedded devices with built-in batteries, it is not so\nimportant to sync the file systems before suspend.  The chance\nof losing power during suspend are no greater than they are\nwhen the system is awake.  The sync operations can greatly\nincrease suspend latency when the system has accrued many dirty\npages and/or the target storage devices are not particularly\nfast.\n\nThis commit adds a kernel config option to allow file system\nsync in the suspend path to be disabled.\n\nChange-Id: Ib0f5fdbb55cd3e503a3768f8424b2863fbc7ff22\nSigned-off-by: Lianwei Wang <a22439@motorola.com>\nReviewed-on: http://gerrit.mot.com/726915\nSME-Granted: SME Approvals Granted\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: RenderBroken <zkennedy87@gmail.com>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/b0e5791205b89222c5ce3fc2936a3351088c83c8"},{"sha":"6a32413a0a201ac62045f710f3dc2d7cf7e01cb9","author":{"name":"Tim Murray","email":"fc967dd1b0265d0311b05dbb56de7d3bd8ed4e2b@google.com"},"message":"mmc: move to a SCHED_FIFO thread\n\nRunning mmcqd as a prio 120 thread forces it to compete with standard\nuser processes for IO performance, especially when the system is under\nsevere CPU load. Move it to a SCHED_FIFO thread to reduce the impact of\nload on IO performance.\n\nbug 25392275\n\nChange-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/6a32413a0a201ac62045f710f3dc2d7cf7e01cb9"},{"sha":"83cdf30700b07c21e4996d348b3f8db3f6434a34","author":{"name":"Tom Marshall","email":"aca7565efea89acd404c75db77b7f011dcc02175@gmail.com"},"message":"kernel: Only expose su when daemon is running\n\nIt has been claimed that the PG implementation of 'su' has security\nvulnerabilities even when disabled.  Unfortunately, the people that\nfind these vulnerabilities often like to keep them private so they\ncan profit from exploits while leaving users exposed to malicious\nhackers.\n\nIn order to reduce the attack surface for vulnerabilites, it is\ntherefore necessary to make 'su' completely inaccessible when it\nis not in use (except by the root and system users).\n\nChange-Id: I79716c72f74d0b7af34ec3a8054896c6559a181d","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/83cdf30700b07c21e4996d348b3f8db3f6434a34"},{"sha":"728c5e4a7c3f6a1c378daa97072a569b13631fe4","author":{"name":"Tom Marshall","email":"aca7565efea89acd404c75db77b7f011dcc02175@gmail.com"},"message":"kernel: Fix potential refcount leak in su check\n\nChange-Id: I8d2c8bed65a01eb0928308df638a04449a5bd881","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/728c5e4a7c3f6a1c378daa97072a569b13631fe4"},{"sha":"6daf3fbe6e897437f1f50a58b246bc9faab4e2ae","author":{"name":"Will Deacon","email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com"},"message":"UPSTREAM: arm64: lib: improve copy_page to deal with 128 bytes at a time\n\nWe want to avoid lots of different copy_page implementations, settling\nfor something that is \"good enough\" everywhere and hopefully easy to\nunderstand and maintain whilst we're at it.\n\nThis patch reworks our copy_page implementation based on discussions\nwith Cavium on the list and benchmarking on Cortex-A processors so that:\n\n  - The loop is unrolled to copy 128 bytes per iteration\n\n  - The reads are offset so that we read from the next 128-byte block\n    in the same iteration that we store the previous block\n\n  - Explicit prefetch instructions are removed for now, since they hurt\n    performance on CPUs with hardware prefetching\n\n  - The loop exit condition is calculated at the start of the loop\n\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nTested-by: Andrew Pinski <apinski@cavium.com>\nSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>\n\nBug: 30369029\nPatchset: kaslr-arm64-4.4\n\n(cherry picked from commit 223e23e8aa26b0bb62c597637e77295e14f6a62c)\nSigned-off-by: Jeff Vander Stoep <jeffv@google.com>\nChange-Id: Icabd86bbecc60ad0d730ab796e33b8762cecb1fb","distinct":true,"url":"https://api.github.com/repos/oxavelar/V20-Kernel-Gamma/commits/6daf3fbe6e897437f1f50a58b246bc9faab4e2ae"}]}
{"actor":{"display_login":"oxavelar"}}