{"push_id":581130058,"size":32,"distinct_size":32,"ref":"refs/heads/cm-12.0","head":"1c108e40770793d9ec865d2ef30208054d1cf70c","before":"7f0efad03825b8926f5f928c5eff471d7afd7301","commits":[{"sha":"f3fc96845c63b33f616b57d128fae318b88e4e9f","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Lower Min Voltage as earlier defined in the regulator\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nConflicts:\n\tarch/arm/mach-msm/acpuclock-krait.c","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/f3fc96845c63b33f616b57d128fae318b88e4e9f"},{"sha":"bffe3511c7cf0836fa8c654c2e5386b592eca83d","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Technically Stock Was 850000 Voltage\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/bffe3511c7cf0836fa8c654c2e5386b592eca83d"},{"sha":"63660ffcecc9cce31de722a8a29c9efc849f267f","author":{"email":"d7fac3f7b328449401fe64671e732ac315caee28@cn.fujitsu.com","name":"Miao Xie"},"message":"lib/memcopy: use glibc version\n\nthe kernel's memcpy and memmove is very inefficient. But the glibc version is\nquite fast, in some cases it is 10 times faster than the kernel version. So I\nintroduce some memory copy macros and functions of the glibc to improve the\nkernel version's performance.\n\nThe strategy of the memory functions is:\n1. Copy bytes until the destination pointer is aligned.\n2. Copy words in unrolled loops.  If the source and destination are not\n   aligned in the same way, use word memory operations, but shift and merge\n   two read words before writing.\n3. Copy the few remaining bytes.\n\nSigned-off-by: Miao Xie <miaox*******>\n\nConflicts:\n\n\tlib/Makefile","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/63660ffcecc9cce31de722a8a29c9efc849f267f"},{"sha":"d77938cafad228e82a9238df66de8aaba5387760","author":{"email":"d7fac3f7b328449401fe64671e732ac315caee28@cn.fujitsu.com","name":"Miao Xie"},"message":"lib/string: use glibc version\n\nthe performance of memcpy and memmove of the general version is very\ninefficient, this patch improved them.\n\nSigned-off-by: Miao Xie <miaox*******>\n\nConflicts:\n\n\tlib/string.c","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/d77938cafad228e82a9238df66de8aaba5387760"},{"sha":"d968cb90b21da098a4d42ab09e8109877ae0e509","author":{"email":"c0f122cd185966be6dba33f6e0bc5de2dbbd0b33@codeaurora.org","name":"Ashwin Chaugule"},"message":"Optimized ARM RWSEM algorithm\n\nRWSEM implementation for ARM using atomic functions.\nHeavily based on arch/sh/include/asm/rwsem.h\n\nSigned-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/d968cb90b21da098a4d42ab09e8109877ae0e509"},{"sha":"5134383c29d1188fac5e7a91fdcc279b896651df","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Fastcharge, thanks to @rmbq\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/5134383c29d1188fac5e7a91fdcc279b896651df"},{"sha":"e52a93286550900517f625f94caf76c4261a5ab0","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Update defconfig\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/e52a93286550900517f625f94caf76c4261a5ab0"},{"sha":"7910b2beb1e22a86336c9d512c92fe124c7ca20d","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Export Krait Variant\nExports to /sys/kernel/debug/krait_variant\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/7910b2beb1e22a86336c9d512c92fe124c7ca20d"},{"sha":"3e3d8cd61ea79ca95ac9fe4b9334a7bf624eb1ba","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"faux123"},"message":"KGSL: Add a simple GPU governor for Adreno xxx GPU series\n\ninitial coding for a Simple GPU governor based on my own work 2 years ago\nfrom Sensation GB kernel commit: c1ea8f6\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nModified for the latest Adreno drivers\n\nSigned-off-by: faux123 <reioux@gmail.com>\n\nConflicts:\n\tdrivers/gpu/msm/Kconfig\n\tdrivers/gpu/msm/kgsl_pwrscale_trustzone.c","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/3e3d8cd61ea79ca95ac9fe4b9334a7bf624eb1ba"},{"sha":"ab5c0749ebd00f23d47b5f0f0a9b638deda7d706","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"faux123"},"message":"KGSL: make simple govenor a selectable option, co-exist with ondemand\n\nalso removed some hardcoded values\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nConflicts:\n\n\tdrivers/gpu/msm/kgsl_pwrscale_trustzone.c\n\nSigned-off-by: faux123 <reioux@gmail.com>\n\nConflicts:\n\tdrivers/gpu/msm/kgsl_pwrscale_trustzone.c","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/ab5c0749ebd00f23d47b5f0f0a9b638deda7d706"},{"sha":"4942b14d723d93aaef80bb7a324d4d71c5281dec","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"KGSL: simple governor: expose tunables to sysfs interface via module_param\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/4942b14d723d93aaef80bb7a324d4d71c5281dec"},{"sha":"c0425a6ceba1225da4e0f829c974ccf7a410af63","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"KGSL: Simple Governor: fix minor logic issue\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/c0425a6ceba1225da4e0f829c974ccf7a410af63"},{"sha":"485d6831b9e38441df413274cffd25b595e5d650","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"BFQ v7r7\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nblock: BFQ-v6r1 I/O sched for 3.4\n\nBFQ is based on CFQ code, but it implements a more accurate scheduling policy. In brief, differently from CFQ, BFQ does not grant the disk to each process for a fixed time-slice, but until the process exhausts a previously assigned budget, measured in number of sectors. Budgets are scheduled with an internal budget scheduler, B-WF2Q+, a modified version of the WF2Q+ packet scheduler.\nIn more detail, in BFQ, as in CFQ, synchronous requests are collected in per-task queues, and asynchronous requests are collected in per-device (or, in case of hierarchical scheduling, per group) queues. When a new queue is created, it is assigned a budget, measured in number of sectors, to use when the queue itself is granted access to the disk. BFQ exclusively serves one queue at a time. When the underlying device driver asks for the next request to serve, BFQ selects the first request from the queue under service in C-LOOK order and returns it to the driver. The budget of the queue is decremented by the size of the request. As in CFQ, if a sync queue has no more requests to serve, but it has some budget left, the scheduler idles (i.e., it tells to the device driver that it has no requests to serve even if there are other backlogged queues) for a short period, waiting for a new request from the task associated to the queue. The queue under service goes on being served until one of the following conditions is met:\n\nthe idling timer expires while BFQ is idling to wait for the arrival of the next request from the task associated to the queue\nthe queue is spending too much time to consume its budget (budget timeout, see the timeout_* parameters below), or\nthe queue exhausts its budget, or\nthe queue is not sync and has no more requests to serve.\nWhen the queue is deselected, it is assigned a new budget, computed as a function of which of the above events occurred. The next queue to serve is selected with B-WF2Q+, a modified version of the WF2Q+ packet scheduler. B-WF2Q+ schedules backlogged queues as a function of: their budgets, their weights and the service they have already received.\n\nWorking in the service domain and not in the time domain is what allows BFQ to distribute the disk throughput as desired, unconditionally and even if it fluctuates. In addition, the accurate service distribution of the internal B-WF2Q+ scheduler, guarantees tight delays with respect to the completion times that the requests would enjoy in an ideal perfectly-fair system.\n\nThe idea for reducing the latency for interactive and soft real-time processes (when low_latency is enabled) is just raising the weight of the associated queues. More details can be found here. An important point is that such an heuristics allows interactive and soft real-time queues to steal more throughput than their fair share to other queues. If the resulting loss of fairness is undesired (e.g., in a server system), it is certainly better to switch low_latency off.\n\nWhen hierarchical scheduling is enabled, queues are collected in a tree of groups, and there is a distinct B-WFQ2+ scheduler on each non-leaf node. Leaf nodes are request queues as in the non-hierarchical case.\n\nBFQ supports ioprio classes at each hierarchy level, enforcing a strict priority ordering among classes. This means that idle queues/groups are served only if there are no best effort queues/group in the same scheduler, and best effort queues/groups are served only if there are no real-time queues/groups.\n\nblock: bfq: Squashed update from v7 to v7r1\n\nblock: squash update bfq from v7r1 to v7r2\n\nblock, bfq: add Early Queue Merge (EQM) to BFQ-v7r2 for 3.4.0\n\nA set of processes may happen  to  perform interleaved reads, i.e., requests\nwhose union would give rise to a  sequential read  pattern.  There are two\ntypical  cases: in the first  case,   processes  read  fixed-size chunks of\ndata at a fixed distance from each other, while in the second case processes\nmay read variable-size chunks at  variable distances. The latter case occurs\nfor  example with  KVM, which  splits the  I/O generated  by the  guest into\nmultiple chunks,  and lets these chunks  be served by a  pool of cooperating\nprocesses,  iteratively  assigning  the  next  chunk of  I/O  to  the first\navailable  process. CFQ  uses actual  queue merging  for the  first type of\nrocesses, whereas it  uses preemption to get a sequential  read pattern out\nof the read requests  performed by the second type of  processes. In the end\nit uses  two different  mechanisms to  achieve the  same goal: boosting the\nthroughput with interleaved I/O.\n\nThis patch introduces  Early Queue Merge (EQM), a unified mechanism to get a\nsequential  read pattern  with both  types of  processes. The  main idea is\nchecking newly arrived requests against the next request of the active queue\nboth in case of actual request insert and in case of request merge. By doing\nso, both the types of processes can be handled by just merging their queues.\nEQM is  then simpler and  more compact than the  pair of mechanisms used in\nCFQ.\n\nFinally, EQM  also preserves the  typical low-latency properties of BFQ, by\nproperly restoring the weight-raising state of  a queue when it gets back to\na non-merged state.\n\nSigned-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\nReviewed-by: Paolo Valente <paolo.valente@unimore.it>\n\nblock: bfq: bfq-v7r2 -> bfq-v7r3\n\nblock: bfq: BFQ-v7r3 -> BFQ-v7r4\n\nblock: bfq: BFQ-v7r4 -> BFQ-v7r5\n\nUpdate BFQ v7r7\n\nSigned-off-by: Paul <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/485d6831b9e38441df413274cffd25b595e5d650"},{"sha":"285334ac421e339fa7fd2c46b48d9ff32e16c7d8","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"FIOPS\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\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\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\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\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\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\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\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\nSigned-off-by: Shaohua Li <shaohua.li@intel.com>\n\nblock: fiops add some trace information","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/285334ac421e339fa7fd2c46b48d9ff32e16c7d8"},{"sha":"fa22d24494497e567b8c85d576243b8043c8431f","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"SIO\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nblock: Simple I/O scheduler\n\nThe Simple I/O scheduler is an extremely simple scheduler,\nbased on noop and deadline, that relies on deadlines to\nensure fairness. The algorithm does not do any sorting but\nbasic merging, trying to keep a minimum overhead. It is aimed\nmainly for aleatory access devices (eg: flash devices).","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/fa22d24494497e567b8c85d576243b8043c8431f"},{"sha":"2c658307b49ed7eacc698c6aace5e29915f2a387","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Improve ROW Algorithms\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nblock: row-iosched idling triggered by readahead pages\n\nIn the current implementation idling is triggered only by request\ninsertion frequency. This heuristic is not very accurate and may hit\nrandom requests that shouldn't trigger idling. This patch uses the\nPG_readahead flag in struct page's flags, which indicates that the page\nis part of a readahead window, to start idling upon dispatch of a request\nassociated with a readahead page.\n\nThe above readehead flag is used together with the existing\ninsertion-frequency trigger. The frequency timer will catch read requests\nwhich are not part of a readahead window, but are still part of a\nsequential stream (and therefore dispatched in small time intervals).\n\nChange-Id: Icb7145199c007408de3f267645ccb842e051fd00\nSigned-off-by: Lee Susman <lsusman@codeaurora.org>\n\nblock: row: add magic values.\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nblock: row: Remove warning massage from add_request\n\nRegular priority queues is marked as \"starved\" if it skipped a dispatch\ndue to being empty. When a new request is added to a \"starved\" queue\nit will be marked as urgent.\nThe removed WARN_ON was warning about an impossible case when a regular\npriority (read) queue was marked as starved but wasn't empty. This is\na possible case due to the bellow:\nIf the device driver fetched a read request that is pending for\ntransmission and an URGENT request arrives, the fetched read will be\nreinserted back to the scheduler. Its possible that the queue it will be\nreinserted to was marked as \"starved\" in the meanwhile due to being empty.\n\nCRs-fixed: 517800\nChange-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c\nSigned-off-by: Tatyana Brokhman <tlinder@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/2c658307b49ed7eacc698c6aace5e29915f2a387"},{"sha":"b14a3df2d0892c3011bd60b452f2bf4d437c09f9","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Improve Deadline Algorithms\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\ndeadline: Allow 0ms deadline latency, increase the read speed\n\nChange a timer compare from after to after-equals, thus allowing\n0 timeout and making deadline schedule FIFO.\n\nSigned-off-by: xiaobing tu <xiaobing.tu@intel.com>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/b14a3df2d0892c3011bd60b452f2bf4d437c09f9"},{"sha":"454de7ddb86600715a049ea53fb250a13430fb4a","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"block: Improve Algorithms\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nblock/partitions: optimize memory allocation in check_partition()\n\nCurrently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch, so\nit is easy to trigger page allocation failure by check_partition,\nespecially in hotplug block device situation(such as, USB mass storage,\nMMC card, ...), and Felipe Balbi has observed the failure.\n\nThis patch does below optimizations on the allocation of struct\nparsed_partitions to try to address the issue:\n\n- make parsed_partitions.parts as pointer so that the pointed memory can\n  fit in 32KB buffer, then approximate 32KB memory can be saved\n\n- vmalloc the buffer pointed by parsed_partitions.parts because 32KB is\n  still a bit big for kmalloc\n\n- given that many devices have the partition count limit, so only\n  allocate disk_max_parts() partitions instead of 256 partitions always\n\nChange-Id: Iee8afc643ea8e7dd2d7c038c542a0377f71bd34e\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nReported-by: Felipe Balbi <balbi@ti.com>\nCc: Jens Axboe <axboe@kernel.dk>\nReviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nblock: queue work on power efficient wq\n\nAdapted for 3.4 from lsk-v3.10\n\nBlock layer uses workqueues for multiple purposes. There is no real dependency\nof scheduling these on the cpu which scheduled them.\n\nOn a idle system, it is observed that and idle cpu wakes up many times just to\nservice this work. It would be better if we can schedule it on a cpu which the\nscheduler believes to be the most appropriate one.\n\nThis patch replaces normal workqueues with power efficient versions.\n\nCc: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Tejun Heo <tj@kernel.org>\n(cherry picked from commit 695588f9454bdbc7c1a2fbb8a6bfdcfba6183348)\nSigned-off-by: Mark Brown <broonie@linaro.org>\nSigned-off-by: Luis Cruz <ljc2491@gmail.com>\nSigned-off-by: poondog <markj338@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/454de7ddb86600715a049ea53fb250a13430fb4a"},{"sha":"d826417e60149edf8d8f5795524e8203d41c4833","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Intellidemand\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\n cpufreq/cpufreq_intellidemand: intellidemand cpufreq governor (version 4.0) @faux123\n\nIntellidemand is inspired by ondemand governor. Its main features are:\n\n - auto cpu hotplugging based on runnable thread average calculations\n - detection of browsing mode (long screen on activities with moderate run\n   queue depth =< 45 )\n - limit max frequencies when in browsing mode to conserve battery for long\n   duration tasks\n\nBrowsing State Determination:\n 1- Browsing state is enabled as power-on default. Browsing state is disabled\n    when run queue depth is > 45 (very high instantaneous spikes)\n\nBrowsing State Limit Max Freq Logic (sliding window algorithm):\n 1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then\n    CPU Max frequencies will remain power-on default\n 2- While Screen is On, if average CPU load > 35%, both CPUs max frequencies\n    will be limited to a lower user configurable max value\n 3- While Screen is On, After both CPUs' Max is limited to lowered max, when\n    the average CPU load has dropped down to less than < 25%, then both CPUs\n    Max freq will be restored to back to power-on default\n\nRunnable Thread Auto-hotplug (fast hotplug / slow unplug algorithm):\n 1- When average number of running thread is < threshold, 2nd cpu will be\n    unplugged.\n 2- When > threshold, 2nd cpu will be hotplugged.\n 3- The logic applies a fast hotplug and slow unplug algorithm so 2nd core\n    will stay enabled longer to help deal with performance spikes\n\nchanges from Ver 2.0 -> Ver 3.0:\n  - remove GPU Busy dependency for browsing state detection (this will make\n    the governor more portable to other platforms without specific GPU\n    architecture knowledge)\n\ndependencies:\n  -- Qualcomm's run queue average logic (SOC independent logic)\n  -- TI's runnable thread average logic (SOC independent logic)\n\nforward ported to Linux 3.4 for use on HTC One\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nConflicts:\n\tarch/arm/mach-msm/cpufreq.c\n\ncpufreq: update intellimand to version 5.0\n\ncpufreq: intellimand: config for ville\n\nintellidemand: minor clean up and tailor for MSM8960 devices","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/d826417e60149edf8d8f5795524e8203d41c4833"},{"sha":"809f8ef0d28ba5f431dde049507063540e594930","author":{"email":"a15ba919a159c9a831d26c40bda2f108afe9f008@gmail.com","name":"Paul Keith"},"message":"Intelliactive\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\ncpufreq: intelliactive: initial coding and introduction!\n\nintelliactive is based on Latest Google Interactive cpufreq governor from\nGoogle.  The original Interactive provides smooth UI operations but suffers\nslight battery drain due to its aggressive policies.  Intelliactive is an\nimprovement built on top of it.\n\nIt has the following enhancements added:\n1. self-boost capability from input drivers (no need for PowerHAL assist)\n2. two phase scheduling (idle/busy phases to prevent from jumping directly to\n   max freq\n3. Checks for offline cpus and short circuits some unnecessary checks to\n   improve code execution paths\n4. removed trace calls\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tdrivers/cpufreq/Kconfig\n\nintelliactive: fix race condition when unregistering input handlers\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nintelliactive: tune for MSM8960 SOCs\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>\n\nConflicts:\n\tdrivers/cpufreq/cpufreq_intelliactive.c\n\nFix\n\nSigned-off-by: Paul Keith <javelinanddart@gmail.com>","distinct":true,"url":"https://api.github.com/repos/mikronac/android_kernel_htc_msm8960/commits/809f8ef0d28ba5f431dde049507063540e594930"}]}