{"push_id":2363862267,"size":5,"distinct_size":5,"ref":"refs/heads/eightone","head":"48a4d1c4cfdd2be693504689d86965d887ff86ca","before":"2191c10b2f1edfc50c2f7930e35c7566fcfd790d","commits":[{"sha":"4ee5175584b48bdfc2a505b39d6ce32bb7f3c6f1","author":{"name":"Humberto Borba","email":"9f16c628b38432879735648fff8ebbbe98efc08e@gmail.com"},"message":"drivers: Fix most qcom direct references to HZ\n\nChange-Id: I2a5cabc7a94bd75bcb98e0338755bdb4c3dd1f2b\nSigned-off-by: mydongistiny <jaysonedson@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BenzoRom/kernel_google_marlin/commits/4ee5175584b48bdfc2a505b39d6ce32bb7f3c6f1"},{"sha":"51c95c825006cc323be13ee980a008abffff28ab","author":{"name":"Sultanxda","email":"2a26fc11866c4c85a6bb605251817c00bbab3213@gmail.com"},"message":"i2c-msm-v2: Ensure system is always active for i2c transfers\n\nThere are quite a few i2c devices that are intended to remain active while\nthe system is suspended, which means that when one of them fires off an\ninterrupt, the subsequent i2c transfers inside the interrupt handler will\nfail.\n\nTo fix this, make the entire system resume when an i2c transfer is\nrequested while the system is suspended. i2c transfer requests will be\nblocked until the system is completely resumed, so that they won't fail.\n\nChange-Id: I33c6392d9f53ce4cf39475346168bf26ea998508\nSigned-off-by: Sultanxda <sultanxda@gmail.com>\nSigned-off-by: mydongistiny <jaysonedson@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BenzoRom/kernel_google_marlin/commits/51c95c825006cc323be13ee980a008abffff28ab"},{"sha":"b4d5646693ea742f433dcac59331cf0f0d55a1b7","author":{"name":"mydongistiny","email":"260ef2ac035ddb09a3bf4a9200ea5a144dd33fd3@gmail.com"},"message":"Revert \"PROTOTYPE: Add hold functionality to schedtune CPU boost\"\n\nThis reverts commit ed15688d89a4cf2a4c5c6e9e10095afac9569876.\n\nSigned-off-by: mydongistiny <jaysonedson@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BenzoRom/kernel_google_marlin/commits/b4d5646693ea742f433dcac59331cf0f0d55a1b7"},{"sha":"f592ef6a1ce18e6f3d69e1fa7ca6909286d8c29f","author":{"name":"Chris Redpath","email":"08674af3d33841cc36f9560b43efa886ec9d5c4f@arm.com"},"message":"sched: Move schedtune en/dequeue before schedutil update triggers\n\nCPU rq util updates happen when rq signals are updated as part of\nenqueue and dequeue operations. Doing these updates triggers a call to\nthe registered util update handler, which takes schedtune boosting\ninto account. Enqueueing the task in the correct schedtune group after\nthis happens means that we will potentially not see the boost for an\nentire throttle period.\n\nMove the enqueue/dequeue operations for schedtune before the signal\nupdates which can trigger OPP changes.\n\nChange-Id: I4236e6b194bc5daad32ff33067d4be1987996780\nSigned-off-by: Chris Redpath <chris.redpath@arm.com>\nSigned-off-by: mydongistiny <jaysonedson@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BenzoRom/kernel_google_marlin/commits/f592ef6a1ce18e6f3d69e1fa7ca6909286d8c29f"},{"sha":"48a4d1c4cfdd2be693504689d86965d887ff86ca","author":{"name":"Chris Redpath","email":"08674af3d33841cc36f9560b43efa886ec9d5c4f@arm.com"},"message":"sched/tune: Add hold functionality to schedtune CPU boost\n\nWhen tasks come and go from a runqueue quickly, this can lead to boost\nbeing applied and removed quickly which sometimes means we cannot raise\nthe CPU frequency again when we need to (due to the rate limit on\nfrequency updates). This has proved to be a particular issue for RT tasks\nand alternative methods have been used in the past to work around it.\n\nThis is an attempt to solve the issue for all task classes and cpufreq\ngovernors by introducing a generic mechanism in schedtune to retain\nthe max boost level from task enqueue for a minimum period - defined\nhere as 50ms. This timeout was determined experimentally and is not\nconfigurable.\n\nA sched_feat guards the application of this to tasks - in the default\nconfiguration, task boosting only applied to tasks which have RT\npolicy. Change SCHEDTUNE_BOOST_HOLD_ALL to true to apply it to all\ntasks regardless of class.\n\nIt works like so:\n\nEvery task enqueue (in an allowed class) stores a cpu-local timestamp.\nIf the task is not a member of an allowed class (all or RT depending\nupon feature selection), the timestamp is not updated.\nThe boost group will stay active regardless of tasks present until\n50ms beyond the last timestamp stored. We also store the timestamp\nof the active boost group to avoid unneccesarily revisiting the boost\ngroups when checking CPU boost level.\n\nIf the timestamp is more than 50ms in the past when we check boost then\nwe re-evaluate the boost groups for that CPU, taking into account the\ntimestamps associated with each group.\n\nIdea based on rt-boost-retention patches from Joel.\n\nEnabled by default\n\nChange-Id: I52cc2d2e82d1c5aa03550378c8836764f41630c1\nSuggested-by: Joel Fernandes <joelaf@google.com>\nReviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>\nSigned-off-by: Chris Redpath <chris.redpath@arm.com>\nSigned-off-by: mydongistiny <jaysonedson@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BenzoRom/kernel_google_marlin/commits/48a4d1c4cfdd2be693504689d86965d887ff86ca"}]}
{"actor":{"display_login":"mydongistiny"}}