{"push_id":715867119,"size":28,"distinct_size":28,"ref":"refs/heads/brn-12.1","head":"c9eec6f9478f49c8602eb52d8eabd63ee944f07f","before":"81ca30ca6d3449eb358980a34d3e5e8f9c54b614","commits":[{"sha":"a73acdfac4a5ac1887fdb5917a7ecd53b1b562e0","author":{"email":"fa8048cf8a492157904bad3af5537885fbacf703@google.com","name":"Chad Jones"},"message":"Add build.config\n\nBug: 19677119\nChange-Id: I327eb4c242bbdf3065799078d6a506cabbfb331f","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/a73acdfac4a5ac1887fdb5917a7ecd53b1b562e0"},{"sha":"0c71bcc9432924d9b65949521152bb7ccad64d55","author":{"email":"4e8e9224f920d8ee7a72dfc715fd0eb121ef81f6@google.com","name":"Ed Tam"},"message":"Increase watchdog bark timeout to 45s\n\nBug: 11324320","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/0c71bcc9432924d9b65949521152bb7ccad64d55"},{"sha":"894341cd2526eaa8d71b5dcdf568c6680bf3cb04","author":{"email":"fa8048cf8a492157904bad3af5537885fbacf703@google.com","name":"Chad Jones"},"message":"Switch back to 4.6 toolchain\n\nBug: 19677119\nChange-Id: Icafce6f00c9180dc63761958aed6754ba6217f12","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/894341cd2526eaa8d71b5dcdf568c6680bf3cb04"},{"sha":"547e1e2c76fb70654e39dc1f2bc8a8458761116b","author":{"email":"546b05909706652891a87f7bfe385ae147f61f91@kernel.org","name":"Tejun Heo"},"message":"idr: fix a subtle bug in idr_get_next()\n\ncommit 6cdae7416a1c45c2ce105a78187d9b7e8feb9e24 upstream.\n\nThe iteration logic of idr_get_next() is borrowed mostly verbatim from\nidr_for_each().  It walks down the tree looking for the slot matching\nthe current ID.  If the matching slot is not found, the ID is\nincremented by the distance of single slot at the given level and\nrepeats.\n\nThe implementation assumes that during the whole iteration id is aligned\nto the layer boundaries of the level closest to the leaf, which is true\nfor all iterations starting from zero or an existing element and thus is\nfine for idr_for_each().\n\nHowever, idr_get_next() may be given any point and if the starting id\nhits in the middle of a non-existent layer, increment to the next layer\nwill end up skipping the same offset into it.  For example, an IDR with\nIDs filled between [64, 127] would look like the following.\n\n          [  0  64 ... ]\n       /----/   |\n       |        |\n      NULL    [ 64 ... 127 ]\n\nIf idr_get_next() is called with 63 as the starting point, it will try\nto follow down the pointer from 0.  As it is NULL, it will then try to\nproceed to the next slot in the same level by adding the slot distance\nat that level which is 64 - making the next try 127.  It goes around the\nloop and finds and returns 127 skipping [64, 126].\n\nNote that this bug also triggers in idr_for_each_entry() loop which\ndeletes during iteration as deletions can make layers go away leaving\nthe iteration with unaligned ID into missing layers.\n\nFix it by ensuring proceeding to the next slot doesn't carry over the\nunaligned offset - ie.  use round_up(id + 1, slot_distance) instead of\nid += slot_distance.\n\nBug: 19665182\nBug: 18069309\nBug: 19236185\n\nChange-Id: Iddd4b6fb27c39d7607bc778fc00bafe6ec289478\nSigned-off-by: Tejun Heo <tj@kernel.org>\nReported-by: David Teigland <teigland@redhat.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/547e1e2c76fb70654e39dc1f2bc8a8458761116b"},{"sha":"0baf67b70346a2a1da67ec75cdfab8c92add2186","author":{"email":"d1996fe015c1f347dddf6c16199179596b8014db@codeaurora.org","name":"Naveen Ramaraj"},"message":"smd_pkt: Add sanity check to avoid unregistering the driver twice\n\nAttempting to unregister it again will cause a panic\n\nBug: 18759663\nChange-Id: Iff2adbc79136c55141f35b872cb70584d303a689\nSigned-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/0baf67b70346a2a1da67ec75cdfab8c92add2186"},{"sha":"cc8e1428aaf3e8609ef8cdbcf76a50d2ec066b91","author":{"email":"e89c727aae6eac8af0dbd55ea2570f8224bd5b53@asus.com","name":"paris_yeh"},"message":"keys: notify system preparing to force reset if resetkey is defined\n\nOn flo/deb hardware platform, the power key button is able to reset\nwhole system forcely via predefined timer at PMIC side. Add notifying\ncall chains to let registered drivers have a chance to prepare data\nbackup before power is cut off by PMIC firmware.\n\nChange-Id: I25fe00020950f0d4208caffda172f46396082a4d\nSigned-off-by: paris_yeh <paris_yeh@asus.com>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/cc8e1428aaf3e8609ef8cdbcf76a50d2ec066b91"},{"sha":"077e2228daf0c09da0220c922489d6be46408289","author":{"email":"e89c727aae6eac8af0dbd55ea2570f8224bd5b53@asus.com","name":"paris_yeh"},"message":"flo/deb: keypad: set powerkey button to have reset notification\n\nhardware reset notfication is sent by keypad driver if powerkey\nbutton is pressed more than 7000 ms when can_reset flag is set.\n\nChange-Id: I642c01cf9a53dbbd8a55f87e93310f920f1f1f3c\nSigned-off-by: paris_yeh <paris_yeh@asus.com>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/077e2228daf0c09da0220c922489d6be46408289"},{"sha":"fe3bd6122588e0f99e1cb7034cfc89fa0faec754","author":{"email":"c87c757cacca283c93421fa11175766237055f07@asus.com","name":"hsuan-chih_chen"},"message":"mmc: add force poweroff notify and sw reset for some card\n\nsending power off notify to eMMC before power off.\ntrigger sw reset before actual HW reset.\n\nChange-Id: I4e3df098b084cc5f39cfd1c52718ed0833d8ba24\nSigned-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/fe3bd6122588e0f99e1cb7034cfc89fa0faec754"},{"sha":"79198ad21ae141b3c9e47166768ae782465ffc8b","author":{"email":"78601e57ee83647e8b7edd75f0813a55a70302d1@gmail.com","name":"Dave Daynard"},"message":"Merge remote-tracking branch 'google/android-msm-flo-3.4-lollipop-mr1.1' into cm-12.1\n\nConflicts:\n\tdrivers/mmc/core/core.c\n\nChange-Id: Ice77e8a22af19501d290259fe845ffc4776787d9","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/79198ad21ae141b3c9e47166768ae782465ffc8b"},{"sha":"27184ac69dba1f6763b902baf32bf3226ef19554","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: interactive: Move definition of cpufreq_gov_interactive downwards\n\nThis moves definition of cpufreq_gov_interactive towards the bottom of file, so\nthat we don't have to add prototype of cpufreq_governor_interactive() in the\nbeginning of file.\n\nChange-Id: I04bd1004954eb36502c5cd7e35d3d7274cddaf95\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nGit-commit: e50d640cacfe61e69f1b4fa92fa0174c688e919c\nGit-Repo: https://android.googlesource.com/kernel/common.git\n[junjiew@codeaurora.org: Resolve merge conflicts]\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/27184ac69dba1f6763b902baf32bf3226ef19554"},{"sha":"44084cd89bf043d0d41a9098bf98bd5f567e47ae","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: Move get_cpu_idle_time() to cpufreq.c\n\nGovernors other than ondemand and conservative can also use\nget_cpu_idle_time() and they aren't required to compile\ncpufreq_governor.c. So, move these independent routines to\ncpufreq.c instead.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nGit-commit: 72a4ce340a7ebf39e1c6fdc8f5feb4f974d6c635\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n[junjiew@codeaurora.org: update non-upstream files]\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nChange-Id: I3227454599250011a19a752c962e3cacb1fb0301","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/44084cd89bf043d0d41a9098bf98bd5f567e47ae"},{"sha":"d88f49f1bfdde850b34f32827bdc97141b0e2ce4","author":{"email":"7f5bb03cf507c861269be561971108be8f37d832@chemlab.org","name":"Steve Kondik"},"message":"cpufreq: interactive: Squashed cleanup patches\n\nRevert \"cpufreq: interactive: Remove unnecessary cpu_online() check\"\n\nThis reverts commit 7b46e2e6d8a3c3c32706ee3c3c3b507d050bedfb.\n\nRevert \"cpufreq: interactive: Allow 1 ms error in above_hispeed_delay comparisons\"\n\nThis reverts commit ff6af80775231f1dfab8353d0b665718222218bf.\n\nCommit ff6af807 tries to avoid a corner case where frequency is stuck in\nhispeed_freq for one additional window. For example, if timer_rate is\n20ms, and go_hispeed_delay is 40ms, frequency might be stuck at\nhispeed_freq for 60ms due to imprecision in jiffies. Same problem can be\neasily solved by making go_hispeed_delay 1ms smaller instead of changing\nthe code.\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: interactive: Revert timer start modification\n\ncommit f8b276565ce95bd788af0fc8d060f92632590a40\n(cpufreq: Sync on thread migration optimizations)\nintroduced a change to cpufreq_interactive_timer_start() in order\nto reschedule the timer differently based on whether min or max\nis changed. A better way is to reschedule the timer only when\nnecessary.\n\nRevert timer start modification in preparation for the final fix.\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nRevert \"cpufreq: interactive: Optimize sync_freq implementation\"\n\nThis reverts commit 4da7f27d4dbd5bcfb8479467444f2cf198217933.\n\ncpufreq: interactive: Revert sync on thread migration optimizations\n\nCommit f8b276565ce95bd788af0fc8d060f92632590a40\n(cpufreq: Sync on thread migration optimizations) is no longer needed\nfor targets with synchronous CPUs.\n\nPart of that commit has already been reverted in\na913b3afcaa55356f5f793ae895312c8ae7e1f71\n(cpufreq: interactive: Revert timer start modification)\n\nThis commit reverts the remaining changes.\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: interactive: Revert sync freq feature\n\nSync freq feature is not valid for a HMP system with clusters.\n\nThis commit reverts commit f3d1980b4db4c20f21acaed59cc511c2df84cec2\n(cpufreq: interactive: sync freq feature for interactive governor)\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: interactive: Remove sampling_down_factor\n\nRemove sampling_down_factor feature.\n\nThis commit revert d094d23694edf41fee50ebc544795d6116451643\n(cpufreq: interactive: Add a sampling_down_factor for max frequencies)\nand subsequent modifications related to sampling down factor.\n\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\nConflicts:\n\tdrivers/cpufreq/cpufreq_interactive.c\n\nChange-Id: I9e5fd451e7eaefe8ef7775365cc5a4527d37188f","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/d88f49f1bfdde850b34f32827bdc97141b0e2ce4"},{"sha":"41490b998ebded88a03c27564762e9fa640bdd53","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Align timer windows for all CPUs\n\nIt's more advantageous to evaluate all CPUs at same time so that\ninteractive governor gets a complete picture of the load on\neach CPU at a specific time. It could also reduce number of speed\nchanges made if there are many CPUs controlled by same policy. In\naddition, waking up all CPUs at same time would allow the cluster\nto go into a deeper sleep state when it's idle.\n\nChange-Id: I6915050c5339ef1af106eb906ebe4b7c618061e2\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/41490b998ebded88a03c27564762e9fa640bdd53"},{"sha":"b92b54af5bab9d744ec4bab06cb422ffe6a99bdb","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Reset last evaluated jiffy in idle callback\n\nWhen CPU has been busy for a long time, last evaluated jiffy will be\nquite behind because the timer would have been canceled. We don't want\nto schedule a timer to fire in the past as load will always be 100%.\n\nReset last evaluated jiffy so that timer will be scheduled for the\nnext window.\n\nChange-Id: Ie25e65eab1f16acdeda267987ca605d653f1f32a\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/b92b54af5bab9d744ec4bab06cb422ffe6a99bdb"},{"sha":"b98967c2ddf7e64914447d60c090ab844fbedbbd","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Use del_timer/add_timer_on to rearm timers\n\nReplace mod_timer_pinned() with del_timer(), add_timer_on().\nmod_timer_pinned() always adds timer onto current CPU. Interactive\ngovernor expects each CPU's timers to be running on the same CPU.\nIf cpufreq_interactive_timer_resched() is called from another CPU,\nthe timer will be armed on the wrong CPU.\n\nReplacing mod_timer_pinned() with del_timer() and add_timer_on()\nguarantees timers are still run on the right CPU even if another\nCPU reschedules the timer. This would provide more flexibility\nfor future changes.\n\nChange-Id: I3a10be37632afc0ea4e0cc9c86323b9783b216b1\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/b98967c2ddf7e64914447d60c090ab844fbedbbd"},{"sha":"89d069869ef18d408f9edb4166c14f7840e7721c","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Add max_freq_hysteresis feature\n\nPreviously known as sampling down factor, max_freq_hysteresis\nextends the period that interactive governor will stay at policy->max.\nThis feature is to accomodate short idle periods in an otherwise very\nintensive workload.\n\nWhen the feature is enabled, it ensures that once a CPU goes to max\nfrequency, it doesn't reduce the frequency for max_freq_hysteresis\nmicroseconds from the time it first goes to idle.\n\nChange-Id: Ia54985cb554f63f8c22d0b554a0a0f2ed2be038f\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/89d069869ef18d408f9edb4166c14f7840e7721c"},{"sha":"ecd2e74c360075f0956ebf819c64c1377dfdf7b6","author":{"email":"ce25c3cee4cc6c4c8acfc1680b3ed89cf644dba3@codeaurora.org","name":"Saravana Kannan"},"message":"cpufreq: interactive: Exercise hispeed settings at a policy level\n\nIf a heavy task migrates between otherwise idle CPUs in a policy during\nevery sample window, the above hispeed delay window for the CPUs would get\nrestarted for every sample window. Due to the continuous restart of above\nhispeed delay window, none of the CPUs would ever pick a target frequency\nhigher than hispeed frequency. This causes the policy's frequency to be\nstuck at hispeed freq even if the load justifies a higher frequency.\n\nTo fix this, the above high speed delay window is restarted only when the\npolicy frequency changes. This ensures that tasks migrating between CPUs in\na policy are handled correctly.\n\nAlso, the hispeed load/frequency heuristic is only necessary when the\ninformation is insufficient to determine if the load on the CPU needs at\nleast hispeed frequency. When the policy frequency is already at or above\nhispeed frequency, if the CPU load% based on policy frequency is not above\nhispeed load, then the information is clearly sufficient to determine that\nthe load on the CPU does not need hispeed frequency.\n\nTherefore, compute CPU load% (which is used only to compare against hispeed\nload) based on policy frequency instead of CPU target frequency.\n\nChange-Id: I1749d663949e34753ecb5c426a16563796f8b0b2\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/ecd2e74c360075f0956ebf819c64c1377dfdf7b6"},{"sha":"31fa72737fbf131cec3770edf866b1dfbb1e422c","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Record hispeed_validated_time in timer function\n\nChange 0cd554ae585f5ccbb95056e049a8fec0f0742dce\n(cpufreq: interactive: Exercise hispeed settings at a policy level)\nintroduced policy level hispeed settings. The change is correct in\ngeneral, but it sets hispeed_validate_time after actual frequency\nchange has completed. Waking up speedchange task and setting\nfrequency takes non-trival amount of time. This period is not accounted\nfor in above_hispeed_delay, resulting in additional delays when\nramping up frequency. Frequency switch latency varies a lot\ndepending on beginning and end frequency, and thus it cannot be easily\ncompensated by user setting above_hispeed_delay.\n\nRecord a local hispeed_validated_time in every CPU's timer function.\nCluster hispeed_validated_time is the local hispeed_validated_time of\nCPUs voting for the highest frequency.\n\nChange-Id: Id8ae547fe3a70f8710f60b6e2125954111b7a2b6\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/31fa72737fbf131cec3770edf866b1dfbb1e422c"},{"sha":"7bd2112db4391a743d2c76cc50c1552d743ac167","author":{"email":"45d857216ef082c1ddfd5d3991b4f3d23f51761f@arcor.de","name":"myfluxi"},"message":"cpufreq: interactive: Honor changed minimum frequency\n\nThis saves a few cycles in the timer routine.\n\nChange-Id: I4c0e89094a00a0b63eae6320e6c3bdbb2d4c307e","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/7bd2112db4391a743d2c76cc50c1552d743ac167"},{"sha":"89ced6db646268f7dbd9479872dd83505cd28626","author":{"email":"45d857216ef082c1ddfd5d3991b4f3d23f51761f@arcor.de","name":"myfluxi"},"message":"cpufreq: interactive: Consider changed min limit a frequency boost\n\nA changed policy->min can safely be considered a frequency boost.\nProcess this change analogous to the cpufreq_interactive_boost()\nroutine.\n\nChange-Id: Ie4ca2be2dad0f5bd541c2b79afee3bad3a349d80","distinct":true,"url":"https://api.github.com/repos/BRNmod/android_kernel_google_msm/commits/89ced6db646268f7dbd9479872dd83505cd28626"}]}