{"push_id":1048655295,"size":34,"distinct_size":34,"ref":"refs/heads/m","head":"7ec0d33b46a7849cf48cd2be568c1f74dfdb8ddb","before":"045b4bc0ee8d8923d148c44aadee88bc43fb8aac","commits":[{"sha":"b0a60059016c402f324a31f084763b4047e6a70a","author":{"email":"5b23f8226e886b22344fc642373ea657dd596b63@linux.vnet.ibm.com","name":"Srivatsa S. Bhat"},"message":"cpufreq: governor: Be friendly towards latency-sensitive bursty workloads\n\nCpufreq governors like the ondemand governor calculate the load on the CPU\nperiodically by employing deferrable timers. A deferrable timer won't fire\nif the CPU is completely idle (and there are no other timers to be run), in\norder to avoid unnecessary wakeups and thus save CPU power.\n\nHowever, the load calculation logic is agnostic to all this, and this can\nlead to the problem described below.\n\nTime (ms)               CPU 1\n\n100                Task-A running\n\n110                Governor's timer fires, finds load as 100% in the last\n                   10ms interval and increases the CPU frequency.\n\n110.5              Task-A running\n\n120\t\t   Governor's timer fires, finds load as 100% in the last\n\t\t   10ms interval and increases the CPU frequency.\n\n125\t\t   Task-A went to sleep. With nothing else to do, CPU 1\n\t\t   went completely idle.\n\n200\t\t   Task-A woke up and started running again.\n\n200.5\t\t   Governor's deferred timer (which was originally programmed\n\t\t   to fire at time 130) fires now. It calculates load for the\n\t\t   time period 120 to 200.5, and finds the load is almost zero.\n\t\t   Hence it decreases the CPU frequency to the minimum.\n\n210\t\t   Governor's timer fires, finds load as 100% in the last\n\t\t   10ms interval and increases the CPU frequency.\n\nSo, after the workload woke up and started running, the frequency was suddenly\ndropped to absolute minimum, and after that, there was an unnecessary delay of\n10ms (sampling period) to increase the CPU frequency back to a reasonable value.\nAnd this pattern repeats for every wake-up-from-cpu-idle for that workload.\nThis can be quite undesirable for latency- or response-time sensitive bursty\nworkloads. So we need to fix the governor's logic to detect such wake-up-from-\ncpu-idle scenarios and start the workload at a reasonably high CPU frequency.\n\nOne extreme solution would be to fake a load of 100% in such scenarios. But\nthat might lead to undesirable side-effects such as frequency spikes (which\nmight also need voltage changes) especially if the previous frequency happened\nto be very low.\n\nWe just want to avoid the stupidity of dropping down the frequency to a minimum\nand then enduring a needless (and long) delay before ramping it up back again.\nSo, let us simply carry forward the previous load - that is, let us just pretend\nthat the 'load' for the current time-window is the same as the load for the\nprevious window. That way, the frequency and voltage will continue to be set\nto whatever values they were set at previously. This means that bursty workloads\nwill get a chance to influence the CPU frequency at which they wake up from\ncpu-idle, based on their past execution history. Thus, they might be able to\navoid suffering from slow wakeups and long response-times.\n\nHowever, we should take care not to over-do this. For example, such a \"copy\nprevious load\" logic will benefit cases like this: (where # represents busy\nand . represents idle)\n\n##########.........#########.........###########...........##########........\n\nbut it will be detrimental in cases like the one shown below, because it will\nretain the high frequency (copied from the previous interval) even in a mostly\nidle system:\n\n##########.........#.................#.....................#...............\n\n(i.e., the workload finished and the remaining tasks are such that their busy\nperiods are smaller than the sampling interval, which causes the timer to\nalways get deferred. So, this will make the copy-previous-load logic copy\nthe initial high load to subsequent idle periods over and over again, thus\nkeeping the frequency high unnecessarily).\n\nSo, we modify this copy-previous-load logic such that it is used only once\nupon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the\nprevious load won't get blindly copied over; cpufreq will freshly evaluate the\nload in the second idle interval, thus ensuring that the system comes back to\nits normal state.\n\n[ The right way to solve this whole problem is to teach the CPU frequency\ngovernors to also track load on a per-task basis, not just a per-CPU basis,\nand then use both the data sources intelligently to set the appropriate\nfrequency on the CPUs. But that involves redesigning the cpufreq subsystem,\nso this patch should make the situation bearable until then. ]\n\nExperimental results:\n+-------------------+\n\nI ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in\nbetween its execution such that its total utilization can be a user-defined\nvalue, say 10% or 20% (higher the utilization specified, lesser the amount of\nsleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.\n\nBehavior observed with tracing (sample taken from 40% utilization runs):\n------------------------------------------------------------------------\n\nWithout patch:\n~~~~~~~~~~~~~~\nkworker/8:2-12137  416.335742: cpu_frequency: state=2061000 cpu_id=8\nkworker/8:2-12137  416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.345744: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-12137  416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n<snip>  ---------------------------------------------------------------------  <snip>\n      <...>-40753  416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8\n     <idle>-0      416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy\n      <...>-40753  416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.505739: cpu_frequency: state=2061000 cpu_id=8\nkworker/8:2-12137  416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.515742: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-12137  416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n\nObservation: Ebizzy went idle at 416.402202, and started running again at\n416.502130. But cpufreq noticed the long idle period, and dropped the frequency\nat 416.505739, only to increase it back again at 416.515742, realizing that the\nworkload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency\nfor almost 13 milliseconds (almost 1 full sample period), and this pattern\nrepeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite\na lot.\n\nWith patch:\n~~~~~~~~~~~\n\nkworker/8:2-29802  464.832535: cpu_frequency: state=2061000 cpu_id=8\n<snip>  ---------------------------------------------------------------------  <snip>\nkworker/8:2-29802  464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  464.972536: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-29802  464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n<snip>  ---------------------------------------------------------------------  <snip>\nkworker/8:2-29802  465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8\n     <idle>-0      465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy\n      <...>-40738  465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n\nObservation: Ebizzy went idle at 465.035797, and started running again at\n465.240178. Since ebizzy was the only real workload running on this CPU,\ncpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no\nmatter how many times ebizzy slept and woke-up in-between. Thus, ebizzy\ngot the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared\nto the run without the patch) and this boost gave a modest improvement in total\nthroughput, as shown below.\n\nSleeping-ebizzy records-per-second:\n-----------------------------------\n\nUtilization  Without patch  With patch  Difference (Absolute and % values)\n    10%         274767        277046        +  2279 (+0.829%)\n    20%         543429        553484        + 10055 (+1.850%)\n    40%        1090744       1107959        + 17215 (+1.578%)\n    60%        1634908       1662018        + 27110 (+1.658%)\n\nA rudimentary and somewhat approximately latency-sensitive workload such as\nsleeping-ebizzy itself showed a consistent, noticeable performance improvement\nwith this patch. Hence, workloads that are truly latency-sensitive will benefit\nquite a bit from this change. Moreover, this is an overall win-win since this\npatch does not hurt power-savings at all (because, this patch does not reduce\nthe idle time or idle residency; and the high frequency of the CPU when it goes\nto cpu-idle does not affect/hurt the power-savings of deep idle states).\n\nSigned-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nReviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/b0a60059016c402f324a31f084763b4047e6a70a"},{"sha":"b4bfac27aa82577ad7c098e859f153577f54ad8a","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: governor: remove copy_prev_load from 'struct cpu_dbs_common_info'\n\n'copy_prev_load' was recently added by commit: 18b46ab (cpufreq: governor: Be\nfriendly towards latency-sensitive bursty workloads).\n\nIt actually is a bit redundant as we also have 'prev_load' which can store any\ninteger value and can be used instead of 'copy_prev_load' by setting it zero.\n\nTrue load can also turn out to be zero during long idle intervals (and hence the\nactual value of 'prev_load' and the overloaded value can clash). However this is\nnot a problem because, if the true load was really zero in the previous\ninterval, it makes sense to evaluate the load afresh for the current interval\nrather than copying the previous load.\n\nSo, drop 'copy_prev_load' and use 'prev_load' instead.\n\nUpdate comments as well to make it more clear.\n\nThere is another change here which was probably missed by Srivatsa during the\nlast version of updates he made. The unlikely in the 'if' statement was covering\nonly half of the condition and the whole line should actually come under it.\n\nAlso checkpatch is made more silent as it was reporting this (--strict option):\n\nCHECK: Alignment should match open parenthesis\n+\t\tif (unlikely(wall_time > (2 * sampling_rate) &&\n+\t\t\t\t\t\tj_cdbs->prev_load)) {\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nReviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nAcked-by: Pavel Machek <pavel@ucw.cz>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/b4bfac27aa82577ad7c098e859f153577f54ad8a"},{"sha":"c8c5a0649eb0dafd4cc76142cc5353dc8eb50bdd","author":{"email":"2ab1abb4425a1076fb72949b41346e3705590156@nvidia.com","name":"Bibek Basu"},"message":"cpufreq: remove race while accessing cur_policy\n\nWhile accessing cur_policy during executing events\nCPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS,\nsame mutex lock is not taken, dbs_data->mutex, which leads\nto race and data corruption while running continious suspend\nresume test. This is seen with ondemand governor with suspend\nresume test using rtcwake.\n\n Unable to handle kernel NULL pointer dereference at virtual address 00000028\n pgd = ed610000\n [00000028] *pgd=adf11831, *pte=00000000, *ppte=00000000\n Internal error: Oops: 17 [#1] PREEMPT SMP ARM\n Modules linked in: nvhost_vi\n CPU: 1 PID: 3243 Comm: rtcwake Not tainted 3.10.24-gf5cf9e5 #1\n task: ee708040 ti: ed61c000 task.ti: ed61c000\n PC is at cpufreq_governor_dbs+0x400/0x634\n LR is at cpufreq_governor_dbs+0x3f8/0x634\n pc : [<c05652b8>] lr : [<c05652b0>] psr: 600f0013\n sp : ed61dcb0 ip : 000493e0 fp : c1cc14f0\n r10: 00000000 r9 : 00000000 r8 : 00000000\n r7 : eb725280 r6 : c1cc1560 r5 : eb575200 r4 : ebad7740\n r3 : ee708040 r2 : ed61dca8 r1 : 001ebd24 r0 : 00000000\n Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user\n Control: 10c5387d Table: ad61006a DAC: 00000015\n [<c05652b8>] (cpufreq_governor_dbs+0x400/0x634) from [<c055f700>] (__cpufreq_governor+0x98/0x1b4)\n [<c055f700>] (__cpufreq_governor+0x98/0x1b4) from [<c0560770>] (__cpufreq_set_policy+0x250/0x320)\n [<c0560770>] (__cpufreq_set_policy+0x250/0x320) from [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168)\n [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) from [<c0561ed0>] (cpu_freq_notify+0x68/0xdc)\n [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c)\n [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68)\n [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28)\n [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310)\n [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) from [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70)\n [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) from [<c004b4b8>] (tegra_pm_notify+0x114/0x134)\n [<c004b4b8>] (tegra_pm_notify+0x114/0x134) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c)\n [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68)\n [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28)\n [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34)\n [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) from [<c00ad38c>] (enter_state+0xec/0x128)\n [<c00ad38c>] (enter_state+0xec/0x128) from [<c00ad400>] (pm_suspend+0x38/0xa4)\n [<c00ad400>] (pm_suspend+0x38/0xa4) from [<c00ac114>] (state_store+0x70/0xc0)\n [<c00ac114>] (state_store+0x70/0xc0) from [<c027b1e8>] (kobj_attr_store+0x14/0x20)\n [<c027b1e8>] (kobj_attr_store+0x14/0x20) from [<c019cd9c>] (sysfs_write_file+0x104/0x184)\n [<c019cd9c>] (sysfs_write_file+0x104/0x184) from [<c0143038>] (vfs_write+0xd0/0x19c)\n [<c0143038>] (vfs_write+0xd0/0x19c) from [<c0143414>] (SyS_write+0x4c/0x78)\n [<c0143414>] (SyS_write+0x4c/0x78) from [<c000f080>] (ret_fast_syscall+0x0/0x30)\n Code: e1a00006 eb084346 e59b0020 e5951024 (e5903028)\n ---[ end trace 0488523c8f6b0f9d ]---\n\nSigned-off-by: Bibek Basu <bbasu@nvidia.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nCc: 3.11+ <stable@vger.kernel.org> # 3.11+\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/c8c5a0649eb0dafd4cc76142cc5353dc8eb50bdd"},{"sha":"7da57bd6665c3ea32f36b78042d8154c43ea815e","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"ElementalX Governor for Angler from @flar2\n\nElementalX governor version 2\n\nChange-Id: I099c80fe48c38cceb678b198606b3fa622deff30\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: refactor and adjust\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: apply input boost per-cpu\n\nSuggested-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: increase max screen off freq\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: let input boost drop to lower frequency\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: disable input boost\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: replace input boost with down factor and floor frequency\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: tune and make less aggressive\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: pick next freq from freq tables\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: remove fb notifier\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: store freq_table per policy and add static reference tables\n\nThis makes the governor work properly with clusters\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: freq_table per policy and pass policy to init function\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: remove gboost\n\nWe don't need it on this device\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: add powersave mode and adjust freq tables\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: cache tunables\n\nThis ensures settings stick if a cluster goes offline or user switches governor\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: add missing declaration\n\nFor configuring elementalx as default governor.\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\ncpufreq_elementalx: lower sampling_down_factor for big cluster\n\nAlso increase sampling rate to 20000","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/7da57bd6665c3ea32f36b78042d8154c43ea815e"},{"sha":"0c4576c0d76a7b8b2b0f4bee37933c24b1ad9806","author":{"email":"73dd783bda2153da307f29c6bb18df5c75fa0d93@gmail.com","name":"savoca"},"message":"Add KCAL control from @savoca\n\nmsm: mdss: Add KCAL support for post processing control [v2]\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nConflicts:\n\tdrivers/video/msm/mdss/Kconfig\n\tdrivers/video/msm/mdss/Makefile\n\tdrivers/video/msm/mdss/mdss_mdp_pp.c\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: Replace PGC implementation with PCC for KCAL\n\n - Unify enable/update routines\n - Remove no longer used update call from probe function\n - Pass lut_data struct to all kcal/mdss functions\n - Thank you to @cyanogen for PCC code reference\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: Add pa_v2 support to KCAL\n\n - Thank you @engstk for testing\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: Remove deprecated __dev* markings\n\n - These probably shouldn't have even been here in the first place... Oops\n - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54b956b903607\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: Keep KCAL within its own source file\n\n - Generate new IGC structure instead of pulling the current one\n - Remove unused header file\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nConflicts:\n\tdrivers/video/msm/mdss/mdss_mdp_pp.c\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Allow kcal_enable to control all post-processing features\n\n - Also update function calls to accurately reflect driver\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Check panel power state before applying values\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Update according to linux guidelines and checkpatch.pl\n\n - Long overdue...\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Update Kconfig description\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Remove MODULE_DESCRIPTION\n\n - Unnecessary\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Queue changes when panel is powered off\n\n - Support MMI panel notifications and fb notifications by default\n - Properly kfree() when probe fails\n - Check RGB values against kcal_min in mdss_mdp_kcal_update_pcc()\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Apply default values on boot\n\n - This is to guarantee that our default values are the ones active\n - Use devm_kzalloc as it guarantees to free memory for us on device remove\n - Properly remove notifier on probe fail\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Read values from MDP registers wherever possible\n\n - This will keep KCAL values updated even when other drivers write\n   to MDP registers (LiveDisplay/Sony)\n - Qcom/CAF code does not support kernel-space readings of IGC lut yet\n - Adjust minimum PCC value from '0' to '1'\n - Bring kcal_min filter back to its own function, values may need to be\n   updated but not written to MDP registers.\n   ex: changes queued when display is off\n - Update IGC variables\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Do not read from picture adjustment registers\n\n- These registers are not reliable for reading at the moment.\n  They will sometimes report a value offset by 0x100, and in some cases\n  report 0, even with MDP_PP_OPS_ENABLE flagged.\n\n- Read from stored values for now\n\nSigned-off-by: W4TCH0UT <ateekujjawal@gmail.com>\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: W4TCH0UT <ateekujjawal@gmail.com>\n\nmsm: mdss: KCAL: Use PCC for negative display mode\n\nmsm: mdss: KCAL: Only apply updates on index 0\n\nThis is just for qualities sake, all of the other functions around\nMDSS do this as well.\n\nChange-Id: I3ac28213c904ea1067b33c3ce6a05481752492b9","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/0c4576c0d76a7b8b2b0f4bee37933c24b1ad9806"},{"sha":"0277bcc17c13a630ab6e664c419b636a2303eb27","author":{"email":"9bbe2bc2582c2f5524e29c40bc5f39feafbfd193@lge.com","name":"Bongkyu Kim"},"message":"UPSTREAM: lz4: fix wrong compress buffer size for 64-bits\n\n(cherry picked from commit 06af1c52c9ea234e0b1266cc0b52c3e0c6c8fe9f)\n\nThe current lz4 compress buffer is 16kb on 32-bits, 32kb on 64-bits\nsystem.  But, lz4 needs only 16kb on both.  On 64-bits, this causes\nwasted cpu cycles for additional memset during every compression.\n\nIn case of lz4hc, the current buffer size is (256kb + 8) on 32-bits,\n(512kb + 16) on 64-bits.  But, lz4hc needs only (256kb + 2 * pointer) on\nboth.\n\nThis patch fixes these wrong compress buffer sizes for 64-bits.\n\nSigned-off-by: Bongkyu Kim <bongkyu.kim@lge.com>\nCc: Chanho Min <chanho.min@lge.com>\nCc: Yann Collet <yann.collet.73@gmail.com>\nCc: Kyungsik Lee <kyungsik.lee@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/0277bcc17c13a630ab6e664c419b636a2303eb27"},{"sha":"74772cb8528b5793c9e15977b0ea4eab6f4e32d2","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"UPSTREAM: arm64: cpu hotplug: ensure we mask out CPU_TASKS_FROZEN in notifiers\n\n(cherry picked from commit e56d82a116176f7af9d642b560abbbd3a2b68013)\n\nWe have a couple of CPU hotplug notifiers for resetting the CPU debug\nstate to a sane value when a CPU comes online.\n\nThis patch ensures that we mask out CPU_TASKS_FROZEN so that we don't\nmiss any online events occuring due to suspend/resume.\n\nAcked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\n\nSigned-off-by: Pavel Labath <labath@google.com>\nBug: 27189927\nChange-Id: I72549149b9bf1f0d05cb17a1db98f9a342c580c0","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/74772cb8528b5793c9e15977b0ea4eab6f4e32d2"},{"sha":"0c9747bd4725fe4c469c826a4089df033640c4bc","author":{"email":"00198f13417fb2e066da5908d444d839551c0414@google.com","name":"Nick Desaulniers"},"message":"msm: thermal: validate userspace args to prevent buffer overflow.\n\nPrevent a userspace ioctl variable from accessing an array out of\nbounds.\n\nBUG: 27243311\nChange-Id: I43690364273ace4a22e214bab88c76f0749c6d4f","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/0c9747bd4725fe4c469c826a4089df033640c4bc"},{"sha":"88cf603f96c33ea604f0438f01bb5f7e70ee3219","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"Makefile: build for Cortex A57\n\nChange-Id: Ida19fe9bae692c1f54c66d9e7da6624d9724206a\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/88cf603f96c33ea604f0438f01bb5f7e70ee3219"},{"sha":"d9e6926c640e644a3b87479a7996b5b38668eeb6","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"Makefile: use big.Little a53/a57 flag\n\nChange-Id: I41e6137fc12f59f542990c25546a99b1b429ad4c\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/d9e6926c640e644a3b87479a7996b5b38668eeb6"},{"sha":"682a97f41de448d8a31807d7bcc1c8272e82a30f","author":{"email":"bd67971edaf49a94837e91683b2145e95504e5dd@gmx.de","name":"andip71"},"message":"cpufreq: hardlimit: set forced min/max cpu frequencies\n\nOP2 version: 8 cores, 2 cpus, standard frequency tables","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/682a97f41de448d8a31807d7bcc1c8272e82a30f"},{"sha":"7eaaab97dbe481715e3ecf4a538f2f80f96eee79","author":{"email":"5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","name":"anarkia1976"},"message":"cpufreq: hardlimit: set right 6p min/max cpu frequencies","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/7eaaab97dbe481715e3ecf4a538f2f80f96eee79"},{"sha":"713718c106ef8e85cf99a707805c82d328f7cc01","author":{"email":"5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","name":"anarkia1976"},"message":"qcom: msm_perf: do not allow userspace to change min/max cpu limits anymore","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/713718c106ef8e85cf99a707805c82d328f7cc01"},{"sha":"d67b96a55727b57f842b7ebaf12334b90200c8a6","author":{"email":"5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","name":"anarkia1976"},"message":"cpufreq: hardlimit: update for min/max cpu frequencies per cores\n\nthanks @andip71","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/d67b96a55727b57f842b7ebaf12334b90200c8a6"},{"sha":"c34d3d3a7b7733ab54e2004b20bdab2ed92bf047","author":{"email":"1c5b678ffa30ab130073521930d7f2e5f75f3de9@gmail.com","name":"Susan McCombs"},"message":"Makefile: remove -mcpu\n\n-mcpu is deprecated\n\nChange-Id: Ide89383165ce8df50ab9c4e060a7d362a37c8e08","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/c34d3d3a7b7733ab54e2004b20bdab2ed92bf047"},{"sha":"28444ab82faf41f0c6991a6a8f5c30014d287ce2","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"msm_performance: Make input boosting optional","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/28444ab82faf41f0c6991a6a8f5c30014d287ce2"},{"sha":"66dc2766a37cb0b6687ca855aa56eb843756fa02","author":{"email":"742cc7da48fa788d384ec77ccfb9a4657661404c@gmail.com","name":"imoseyon"},"message":"sound: soc: reverted changes from Linux 3.10.96 to fix microphone","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/66dc2766a37cb0b6687ca855aa56eb843756fa02"},{"sha":"02b3cd052866e3c7cab7527d67a444a3fdacf279","author":{"email":"cb3904095a5bc20edc93ba3dfa3e7d27d981b654@intel.com","name":"Shaohua Li"},"message":"block: fiops\n\nblock: fiops ioscheduler core\n\nFIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets\nfor drive without I/O seek. It's quite similar like CFQ, but the dispatch\ndecision is made according to IOPS instead of slice.\n\nThe algorithm is simple. Drive has a service tree, and each task lives in\nthe tree. The key into the tree is called vios (virtual I/O). Every request\nhas vios, which is calculated according to its ioprio, request size and so\non. Task's vios is the sum of vios of all requests it dispatches. FIOPS\nalways selects task with minimum vios in the service tree and let the task\ndispatch request. The dispatched request's vios is then added to the task's\nvios and the task is repositioned in the sevice tree.\n\nUnlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O\nless writeback, usually a task can only dispatch either sync or async requests.\nBias read or write request can still be done with read/write scale.\n\nOne issue is if workload iodepth is lower than drive queue_depth, IOPS\nshare of a task might not be strictly according to its priority, request\nBias read or write request can still be done with read/write scale.\n\nOne issue is if workload iodepth is lower than drive queue_depth, IOPS\nshare of a task might not be strictly according to its priority, request\nsize and so on. In this case, the drive is in idle actually. Solving the\nproblem need make drive idle, so impact performance. I believe CFQ isn't\ncompletely fair between tasks in such case too.\n\nChange-Id: I1f86b964ada1e06ac979899ca05f1082d0d8228d\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops read/write request scale\n\nread/write speed of Flash based storage usually is different. For example,\nin my SSD maxium thoughput of read is about 3 times faster than that of\nwrite. Add a scale to differenate read and write. Also add a tunable, so\nuser can assign different scale for read and write.\n\nBy default, the scale is 1:1, which means the scale is a noop.\n\nChange-Id: Ic223e96d1c72591ef535307755d78ff33dbc6939\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops sync/async scale\n\nCFQ gives 2.5 times more share to sync workload. This matches CFQ.\n\nNote this is different with the read/write scale. We have 3 types of\nrequests:\n1. read\n2. sync write\n3. write\nCFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2\nare usually different for flash based storage. So we have both sync/async\nand read/write scale here.\n\nChange-Id: I3b36c94ba63df6d7a823c941a34a479da6243f20\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops add ioprio support\n\nAdd CFQ-like ioprio support. Priority A will get 20% more share than priority\nA+1, which matches CFQ.\n\nChange-Id: I0d6f145810e3f0979440063c030cddf30ad4179c\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops preserve vios key for deep queue depth workload\n\nIf the task has running request, even it's added into service tree newly,\nwe preserve its vios key, so it will not lost its share. This should work\nfor task driving big queue depth. For single depth task, there is no approach\nto preserve its vios key.\n\nChange-Id: I40bdaff6430b783b965ca434ffc46b7205b554cd\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops bias sync workload\n\nIf there are async requests running, delay async workload. Otherwise\nasync workload (usually very deep iodepth) will use all queue iodepth\nand later sync requests will get long delayed. The idea is from CFQ.\n\nChange-Id: I66b8b87ca33c9e92ed52067cead54a4fc48c6426\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops add some trace information\n\nAdd some trace information, which is helpful when I do debugging.\n\nChange-Id: Ib1082fc2547fd56c2fadbb7a9596a3dc4c7b15c8\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/02b3cd052866e3c7cab7527d67a444a3fdacf279"},{"sha":"ec7bf2517c3a66ae94264b187c345252511a064c","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"FIOPS: forward port for use on 3.10 Linux\n\nChange-Id: I1ae7f50feda51b2aacb15c7b632cd38937b1edb5\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/ec7bf2517c3a66ae94264b187c345252511a064c"},{"sha":"2bb24533006e31e3ac581106b59f812d999dd4f2","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block: cgroups, kconfig, build bits for BFQ-v7r8-3.10.8+\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.","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_huawei_angler/commits/2bb24533006e31e3ac581106b59f812d999dd4f2"}]}