{"push_id":704884614,"size":9,"distinct_size":9,"ref":"refs/heads/lp5.1","head":"5d237efdc242726922df26091f93e55041a94f6a","before":"bc0013e3980ace118783a7269aeee60300793e15","commits":[{"sha":"a644c46e61010451a25a031df0abf0446c0c4553","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/SlimForce/kernel_lge_hammerhead/commits/a644c46e61010451a25a031df0abf0446c0c4553"},{"sha":"d27421efdd8a45cdfc08b94e590e73734783bf30","author":{"email":"6f9d97df82107736b1c4f0e11d74242c25499ec8@chromium.org","name":"Andrew Bresticker"},"message":"CHROMIUM: cpufreq: interactive: validate above_hispeed_delay\n\nWe rely on the frequencies in above_hispeed_delay being in ascending\norder.  Ensure that is the case for the values the user gives us.\n\nBUG=chrome-os-partner:20830\nTEST=Boot Pit; write invalid above_hispeed_delay value:\nlocalhost ~ # echo \"20000 1800000:20000 700000:0\" > above_hispeed_delay\n-bash: echo: write error: Invalid argument\n\nChange-Id: Ifb431e58ad4b6b371152d7b09fcbefa127b0cbe2\nSigned-off-by: Andrew Bresticker <abrestic@chromium.org>\nReviewed-on: https://gerrit.chromium.org/gerrit/65742\nReviewed-by: Sonny Rao <sonnyrao@chromium.org>","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/d27421efdd8a45cdfc08b94e590e73734783bf30"},{"sha":"065d3093596a3ef88f8973f3be052c73936f60c8","author":{"email":"32f072be9e2a1650a4123445afd33554f6ea8ff4@chromium.org","name":"Bryan Freed"},"message":"CHROMIUM: Replace obsolete strict_strtoul calls.\n\nstrict_strtoul has been replaced by kstrtoul.\n\nChange-Id: I10e2a0a1b114b34283d0111e81ba5b4796d90eb0\n[bfreed: added in the 3.18 rebase]\nSigned-off-by: Bryan Freed <bfreed@chromium.org>","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/065d3093596a3ef88f8973f3be052c73936f60c8"},{"sha":"370b9a66ab0ee603c5cfb0fb21fd5389ef787cdb","author":{"email":"9296a0ca31e8299ed6ec39daa4ff56fd47a51cb6@codeaurora.org","name":"Rohit Gupta"},"message":"cpufreq: interactive: Rearm governor timer at max freq\n\nCurrently interactive governor timer doesn't re-arm itself when it\nselects policy->max as the new frequency to go to. On hitting idle\nfor the first time at max frequency timer is armed again. This\nmechanism doesn't have any noticeable performance benefits since\nCPUs running at max frequencies without going into idles show high\nloads which prevents the governor from lowering their frequencies.\nThis change rearms the timer even at max frequency which removes\nthe need to handle idle starts. This simplifies the code and also\nmakes the governor timer windows more regular so that the\nnotifications going out from the governor are uniformly spaced\napart. Max freq hysteresis start timestamp is refreshed everytime\npolicy->max is selected as the new frequency to prevent stepping\ndown from max frequency earlier than intended.\n\nChange-Id: I9c137113b703f2064f1e668628db91de94cc0887\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/370b9a66ab0ee603c5cfb0fb21fd5389ef787cdb"},{"sha":"6804e62a443e8afcdb41a17e45ed382da32a83f5","author":{"email":"fb1ef5d447d8cd53e9e4511d7b18b7cdbb10397f@chromium.org","name":"Derek Basehore"},"message":"CHROMIUM: cpufreq: interactive: calculate load before freq change\n\nThe update to cpu load for cpufreq rate changes was happening after the rate\nchange instead of before. This switches it to update the cpu load before the\ncpufreq rate change so the old frequency is used for calculating the speed\nadjusted cpu load. The old frequency was used for that active time, so it should\nbe used for calculating the speed adjusted cpu load.\n\nBUG=chrome-os-partner:37673\nTEST=power_LoadTest on Jerry\ncheck we spend most of our time at the lower cpu frequencies\n\nChange-Id: I2fff785561ad8aebd354ddd305e91d96c799a617\nSigned-off-by: Derek Basehore <dbasehore@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/262925\nReviewed-by: Douglas Anderson <dianders@chromium.org>","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/6804e62a443e8afcdb41a17e45ed382da32a83f5"},{"sha":"31749c249705efe5323aed4cc651783a69ee4958","author":{"email":"bb05168246ed1a6b66d0e7b1ffb0c5e3707764ca@codeaurora.org","name":"Junjie Wu"},"message":"cpufreq: interactive: Reschedule timer if min_freq is reduced\n\nWhen a CPU is running at policy->min, slack timer will not be scheduled.\nIf policy->min is reduced later, current implementation doesn't\nreschedule slack timer and thus could leave CPU at a higher\nfrequency indefinitely as long as the CPU is idle. This behavior is\nundesirable from power perspective.\n\nChange-Id: I40bfd7c93ad3fd06e3837dc48befdc07f29c78c8\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/31749c249705efe5323aed4cc651783a69ee4958"},{"sha":"03c49f27e1e528f9d06329eb63662bcca7d7d64e","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/SlimForce/kernel_lge_hammerhead/commits/03c49f27e1e528f9d06329eb63662bcca7d7d64e"},{"sha":"6307cff2651755580c82ef893d059afbfc772fb3","author":{"email":"dea94a0844b5eabbd4facc1feb96e20a0f3b79ea@googlemail.com","name":"Elektroschmock"},"message":"cpufreq: interactive: Replace strict_strtoul with kstrtoul\n\nstrict_strtoul() is obsolete. Thus, kstrtoul() should be used.\n\nChange-Id: I17303f6bfe4ae32abd372bbdc08d5cd480835d3b\n(cherry picked from commit 9a373572b4d9157ffc5eee7fb948061269cd9fde)","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/6307cff2651755580c82ef893d059afbfc772fb3"},{"sha":"5d237efdc242726922df26091f93e55041a94f6a","author":{"email":"196bec0f6b1472f3037aefb09c79b5ebea986d31@gmail.com","name":"Chang Long"},"message":"Merge remote-tracking branch 'sr/lp5.1' into lp5.1","distinct":true,"url":"https://api.github.com/repos/SlimForce/kernel_lge_hammerhead/commits/5d237efdc242726922df26091f93e55041a94f6a"}]}