mali_kbase: Use rt_mutex for scheduler lock

We use pm_runtime for handling suspends, which means that an
internal linux power workqueue will take and hold the CSF
scheduler lock while performing suspend operations.
This workqueue runs at default priority and so might not be
scheduled fast enough if there is high CPU load, which results
in missed frames.

By promoting the CSF scheduler lock to an rt_mutex we ensure
that the GPU wakes up faster when there is work that needs to
be done, since our other internal realtime threads will be
waiting on the scheduler lock in these cases.

Bug: 296862283
Test: CUJ close camera
Change-Id: Ibe81ad7e26a75acb1640b2820902eb8144a48fdd
Merged-In: I0e81a45e3d65f60337250d35c53ef6447c876051

1 files changed, 2 insertions, 2 deletions

diff --git a/mali_kbase/backend/gpu/mali_kbase_pm_policy.c b/mali_kbase/backend/gpu/mali_kbase_pm_policy.c
index 898d70f..f5dc008 100644
--- a/mali_kbase/backend/gpu/mali_kbase_pm_policy.c
+++ b/mali_kbase/backend/gpu/mali_kbase_pm_policy.c
@@ -322,7 +322,7 @@ void kbase_pm_set_policy(struct kbase_device *kbdev,
 	 * check it here. So we hold the scheduler lock to avoid other operations
 	 * interfering with the policy change and vice versa.
 	 */
-	mutex_lock(&scheduler->lock);
+	rt_mutex_lock(&scheduler->lock);
 	spin_lock_irqsave(&kbdev->hwaccess_lock, flags);
 	/* policy_change_clamp_state_to_off, when needed, is set/cleared in
 	 * this function, a very limited temporal scope for covering the
@@ -412,7 +412,7 @@ void kbase_pm_set_policy(struct kbase_device *kbdev,
 	/* Reverse the suspension done */
 	if (sched_suspend)
 		kbase_csf_scheduler_pm_resume_no_lock(kbdev);
-	mutex_unlock(&scheduler->lock);
+	rt_mutex_unlock(&scheduler->lock);
 
 	if (reset_op_prevented)
 		kbase_reset_gpu_allow(kbdev);