GitHub PushEvent at 2014-05-15 11:24:44
Repository: kernel_msm
Actor: Dancing--Dragon
Payload: {"shas":[["73f321b022d153538c65b793422fb6ca1f64920c","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","cpufreq: 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>","Paul Reioux",true],["40c0614d450dc47e0f1bad2e9af0bb0ea6f01f1a","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","intelliactive: tune for APQ8064 devices\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true],["2f9d37ea6e676ab10bba59df38cb761c7d26033a","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","intelliactive: fix race condition when unregistering input handlers\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true],["5bdfe8bc54f23e7730fdccae43bb660d7df9680c","2da78bf5d3173faffeb544adb9dca7e353467293@gmail.com","Tuning IntelliActive","barome",true],["29893d9b77f6f16dc19b2ec1fb1d8188b83e6704","5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","cpufreq: intelliactive: fix cpu target freq and timers","anarkia1976",true],["49ad5a7648e2c3af194b5caf9fe3384698e08df8","5db23874f34e45d59c69d81cd72d048d558566d7@gmail.com","cpufreq: intelliactive: add elan-touchscreen definitions","anarkia1976",true],["f8b457a9d853785e0553c5fe1bf3686fa4ae2caa","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","cpufreq: intelliactive: make touch boost interface generic\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tdrivers/cpufreq/cpufreq_intelliactive.c","Paul Reioux",true],["c8e6e95467570273ec4f57c5e071cf1ad9b6a77a","2da78bf5d3173faffeb544adb9dca7e353467293@gmail.com","Set Max Screen Off to 702MHz","barome",true],["540e09734231e36157dd2a4b0a6f399ad923e8fa","e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","cma: Remove potential deadlock situation\n\nA report was given of a deadlock situation on the cma_mutex:\n\nmutex_lock(cma_mutex)   (*2)\ndma_release_from_contiguous\nion_secure_cma_free_chunk\nion_secure_cma_shrinker\nshrink_slab\ntry_to_free_pages\nmigrate_pages\nalloc_contig_range\nmutex_lock(cma_mutex)  (*1)\ndma_alloc_from_contiguous\nion_alloc\n\nWe may need to free CMA allocations while a current CMA allocation is in\nprogress if CMA is freed from a shrinker. cma_mutex currently protects\ntwo things: the bitmap indicating which pages are allocated/free and\nserialization of isolation/migration calls on allocation. There is\nno need to take the mutex on free calls though as the pages are\nfreed back into the system via the regular __free_page call. Move\nthe free_contig_range call outside the cma_mutex to break the\nchain dependency. We can safely free the pages back into the system\nbefore changing the bitmap without any risk of races.\n\nChange-Id: I4989eb2891e502b08db8117a51bd86652e902778\nCRs-Fixed: 619644\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","Laura Abbott",true],["47150e648b3fd7604d145b1ce20dc6bbc55fa1eb","2da78bf5d3173faffeb544adb9dca7e353467293@gmail.com","cpufreq: intelliactive: Optimize sync_freq implementation","barome",true]],"size":10,"ref":"refs/heads/mr1-Upstream","head":"47150e648b3fd7604d145b1ce20dc6bbc55fa1eb"}