{"push_id":939085588,"size":26,"distinct_size":26,"ref":"refs/heads/stable-5.1.1-lentislte","head":"61316eae6dbd2dd8fabe5fb8dedd73842431933b","before":"4d87439e99aebde0ecaf89370edd732008435629","commits":[{"sha":"c2557dbd5125061bfebad6181f45d971bd3d8ffb","author":{"email":"67557c94e2bf37c98ef3ab1e7320477b2dc082cf@outlook.com","name":"Jesse Chan"},"message":"drivers/staging: Add Modem Host Interface Module\n\n* And compile by default\n* From N910F-POK1","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/c2557dbd5125061bfebad6181f45d971bd3d8ffb"},{"sha":"48dc994aef9ee6db59d2cbb0482cd312d3e587f2","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/Dev-in-Advance/android_kernel_samsung_apq8084/commits/48dc994aef9ee6db59d2cbb0482cd312d3e587f2"},{"sha":"1177b5ff06fa50466b5dc2b9a09fb56dac88c7aa","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/Dev-in-Advance/android_kernel_samsung_apq8084/commits/1177b5ff06fa50466b5dc2b9a09fb56dac88c7aa"},{"sha":"f97f9bed6ecfa79d67dab86f6d8995d52312158b","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/Dev-in-Advance/android_kernel_samsung_apq8084/commits/f97f9bed6ecfa79d67dab86f6d8995d52312158b"},{"sha":"529b1c235bf9925786a853a22791c0664cf50e06","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"ElementalX governor version 2\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/529b1c235bf9925786a853a22791c0664cf50e06"},{"sha":"40efbf39445048d99b2d51408e39d0291703d322","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: refactor and adjust\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/40efbf39445048d99b2d51408e39d0291703d322"},{"sha":"fd9b0a2a61aac51d685b39107d76f6f0a8a4b29f","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: apply input boost per-cpu\n\nSuggested-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/fd9b0a2a61aac51d685b39107d76f6f0a8a4b29f"},{"sha":"ad9ce70cf35df82b72b779096cdb01d6135ce14b","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: increase max screen off freq\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/ad9ce70cf35df82b72b779096cdb01d6135ce14b"},{"sha":"1fbd1042bfac933983e97849eede5dc4cbf44b83","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: let input boost drop to lower frequency\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/1fbd1042bfac933983e97849eede5dc4cbf44b83"},{"sha":"cedd20b281f43e24da520ba5ccc7ce9c9841f0d5","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: disable input boost\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/cedd20b281f43e24da520ba5ccc7ce9c9841f0d5"},{"sha":"6f29b969506a4943accce9a041aeff45a164f686","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: replace input boost with down factor and floor frequency\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/6f29b969506a4943accce9a041aeff45a164f686"},{"sha":"7bf3193eba8cf7ae27946fec526fef9d3bf0adbc","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: tune and make less aggressive\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/7bf3193eba8cf7ae27946fec526fef9d3bf0adbc"},{"sha":"7e60599ef2cc2c6ca1e8005ab9d8bbf88f7b134c","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"cpufreq_elementalx: pick next freq from freq tables\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/7e60599ef2cc2c6ca1e8005ab9d8bbf88f7b134c"},{"sha":"0fa4a32f25d2aa8d47a6d77fbb75c32c47031bc3","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: Make sure CPU is running on a freq from freq-table\n\nSometimes boot loaders set CPU frequency to a value outside of frequency table\npresent with cpufreq core. In such cases CPU might be unstable if it has to run\non that frequency for long duration of time and so its better to set it to a\nfrequency which is specified in freq-table. This also makes cpufreq stats\ninconsistent as cpufreq-stats would fail to register because current frequency\nof CPU isn't found in freq-table.\n\nBecause we don't want this change to affect boot process badly, we go for the\nnext freq which is >= policy->cur ('cur' must be set by now, otherwise we will\nend up setting freq to lowest of the table as 'cur' is initialized to zero).\n\nIn case current frequency doesn't match any frequency from freq-table, we throw\nwarnings to user, so that user can get this fixed in their bootloaders or\nfreq-tables.\n\nReported-by: Carlos Hernandez <ceh@ti.com>\nReported-and-tested-by: Nishanth Menon <nm@ti.com>\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Tkkg1994 <luca.grifo@outlook.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/0fa4a32f25d2aa8d47a6d77fbb75c32c47031bc3"},{"sha":"22acb4d91bb423765fb530e34ed2cc45805ed7bc","author":{"email":"d79fadde9de82c838211e8a952123da40fe360c0@motorola.com","name":"Lianwei Wang"},"message":"cpufreq: set policy with user_policy data\n\nWhen we update/set cpufreq policy, we should set the new\npolicy with user_policy data, and the cpufreq notifier\nwill limit the min/max freq accordingly.\n\nThis is the right process to update the cpufreq policy.\n\nBut we miss it in store_scaling_governor func, which cause\nthe governor set failed if the policy.max is less than\nuser_policy.min.\n\nSigned-off-by: Lianwei Wang <a22439@motorola.com>\nReviewed-on: http://gerrit.mot.com/746797\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Ke Lu <a2435c@motorola.com>\nReviewed-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Zhi-Ming Yuan <a14194@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/22acb4d91bb423765fb530e34ed2cc45805ed7bc"},{"sha":"6603c8ae46dc741381b7448fa182b3ab8f9acdd7","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flag\n\nSometimes boot loaders set CPU frequency to a value outside of frequency table\npresent with cpufreq core. In such cases CPU might be unstable if it has to run\non that frequency for long duration of time and so its better to set it to a\nfrequency which is specified in frequency table.\n\nOn some systems we can't really say what frequency we're running at the moment\nand so for these we shouldn't check if we are running at a frequency present in\nfrequency table. And so we really can't force this for all the cpufreq drivers.\n\nHence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that\nwill be marked by platforms which want to go for this check at boot time.\n\nInitially this is done for all ARM platforms but others may follow if required.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Tkkg1994 <luca.grifo@outlook.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/6603c8ae46dc741381b7448fa182b3ab8f9acdd7"},{"sha":"b3e8e94ffe3870f1f573a2aeb9a7b7d7ef4ca123","author":{"email":"51b0aed1a48556115b152d4619664105ddea9243@lge.com","name":"Kyungsik Lee"},"message":"decompressor: add LZ4 decompressor module\n\nAdd support for LZ4 decompression in the Linux Kernel.  LZ4 Decompression\nAPIs for kernel are based on LZ4 implementation by Yann Collet.\n\nBenchmark Results(PATCH v3)\nCompiler: Linaro ARM gcc 4.6.2\n\n1. ARMv7, 1.5GHz based board\n   Kernel: linux 3.4\n   Uncompressed Kernel Size: 14MB\n        Compressed Size  Decompression Speed\n   LZO  6.7MB            20.1MB/s, 25.2MB/s(UA)\n   LZ4  7.3MB            29.1MB/s, 45.6MB/s(UA)\n\n2. ARMv7, 1.7GHz based board\n   Kernel: linux 3.7\n   Uncompressed Kernel Size: 14MB\n        Compressed Size  Decompression Speed\n   LZO  6.0MB            34.1MB/s, 52.2MB/s(UA)\n   LZ4  6.5MB            86.7MB/s\n- UA: Unaligned memory Access support\n- Latest patch set for LZO applied\n\nThis patch set is for adding support for LZ4-compressed Kernel.  LZ4 is a\nvery fast lossless compression algorithm and it also features an extremely\nfast decoder [1].\n\nBut we have five of decompressors already and one question which does\narise, however, is that of where do we stop adding new ones?  This issue\nhad been discussed and came to the conclusion [2].\n\nRussell King said that we should have:\n\n - one decompressor which is the fastest\n - one decompressor for the highest compression ratio\n - one popular decompressor (eg conventional gzip)\n\nIf we have a replacement one for one of these, then it should do exactly\nthat: replace it.\n\nThe benchmark shows that an 8% increase in image size vs a 66% increase\nin decompression speed compared to LZO(which has been known as the\nfastest decompressor in the Kernel).  Therefore the \"fast but may not be\nsmall\" compression title has clearly been taken by LZ4 [3].\n\n[1] http://code.google.com/p/lz4/\n[2] http://thread.gmane.org/gmane.linux.kbuild.devel/9157\n[3] http://thread.gmane.org/gmane.linux.kbuild.devel/9347\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>\nSigned-off-by: Yann Collet <yann.collet.73@gmail.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Russell King <rmk@arm.linux.org.uk>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Florian Fainelli <florian@openwrt.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/b3e8e94ffe3870f1f573a2aeb9a7b7d7ef4ca123"},{"sha":"473a04229a5132b5f1b7b291df834fb33173a692","author":{"email":"51b0aed1a48556115b152d4619664105ddea9243@lge.com","name":"Kyungsik Lee"},"message":"lib: add support for LZ4-compressed kernel\n\nAdd support for extracting LZ4-compressed kernel images, as well as\nLZ4-compressed ramdisk images in the kernel boot process.\n\nSigned-off-by: Kyungsik Lee <kyungsik.lee@lge.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Russell King <rmk@arm.linux.org.uk>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Florian Fainelli <florian@openwrt.org>\nCc: Yann Collet <yann.collet.73@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/473a04229a5132b5f1b7b291df834fb33173a692"},{"sha":"cf98e0e57068e1c529ec1cc444035338a50eb0d2","author":{"email":"f29209e176deba8cfd2e79bb6b9166c7d43dc10b@lge.com","name":"Chanho Min"},"message":"lib: add lz4 compressor module\n\nThis patchset is for supporting LZ4 compression and the crypto API using\nit.\n\nAs shown below, the size of data is a little bit bigger but compressing\nspeed is faster under the enabled unaligned memory access.  We can use\nlz4 de/compression through crypto API as well.  Also, It will be useful\nfor another potential user of lz4 compression.\n\nlz4 Compression Benchmark:\nCompiler: ARM gcc 4.6.4\nARMv7, 1 GHz based board\n   Kernel: linux 3.4\n   Uncompressed data Size: 101 MB\n         Compressed Size  compression Speed\n   LZO   72.1MB\t\t  32.1MB/s, 33.0MB/s(UA)\n   LZ4   75.1MB\t\t  30.4MB/s, 35.9MB/s(UA)\n   LZ4HC 59.8MB\t\t   2.4MB/s,  2.5MB/s(UA)\n- UA: Unaligned memory Access support\n- Latest patch set for LZO applied\n\nThis patch:\n\nAdd support for LZ4 compression in the Linux Kernel.  LZ4 Compression APIs\nfor kernel are based on LZ4 implementation by Yann Collet and were changed\nfor kernel coding style.\n\nLZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html\nLZ4 source repository : http://code.google.com/p/lz4/\nsvn revision : r90\n\nTwo APIs are added:\n\nlz4_compress() support basic lz4 compression whereas lz4hc_compress()\nsupport high compression or CPU performance get lower but compression\nratio get higher.  Also, we require the pre-allocated working memory with\nthe defined size and destination buffer must be allocated with the size of\nlz4_compressbound.\n\n[akpm@linux-foundation.org: make lz4_compresshcctx() static]\nSigned-off-by: Chanho Min <chanho.min@lge.com>\nCc: \"Darrick J. Wong\" <djwong@us.ibm.com>\nCc: Bob Pearson <rpearson@systemfabricworks.com>\nCc: Richard Weinberger <richard@nod.at>\nCc: Herbert Xu <herbert@gondor.hengli.com.au>\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>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/cf98e0e57068e1c529ec1cc444035338a50eb0d2"},{"sha":"20e4d50b836cb92cb61e3f94c10f771493889048","author":{"email":"c48a977c99df211699aa56461f1372547350aebb@gmail.com","name":"LaboDJ"},"message":"crypto: add lz4 Cryptographic API\n\nAdd support for lz4 and lz4hc compression algorithm using the lib/lz4/*\ncodebase.\n\n[akpm@linux-foundation.org: fix warnings]\nSigned-off-by: Chanho Min <chanho.min@lge.com>\nCc: \"Darrick J. Wong\" <djwong@us.ibm.com>\nCc: Bob Pearson <rpearson@systemfabricworks.com>\nCc: Richard Weinberger <richard@nod.at>\nCc: Herbert Xu <herbert@gondor.hengli.com.au>\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>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Dev-in-Advance/android_kernel_samsung_apq8084/commits/20e4d50b836cb92cb61e3f94c10f771493889048"}]}