Am 24.08.21 um 13:57 schrieb Das, Nirmoy:
Hi Christian,
On 8/24/2021 8:10 AM, Christian König wrote:
I haven't followed the previous discussion, but that looks like this
change is based on a misunderstanding.
In previous discussion I sort of suggested to have new DRM prio as I
didn't see any other way to map priority provided by the userspace to
this new 3rd hw priority.
Do you think we should use other information from userspace like queue
id to determine hardware priority ?
If I'm not completely mistaken we have dropped the concept of exposing
multiple queues/instances completely.
What we should probably do is to use the (cleaned up) UAPI enum for
init_priority and override_priority instead of the drm scheduler enums.
Regards,
Christian.
Regards,
Nirmoy
Those here are the software priorities used in the scheduler, but
what you are working on are the hardware priorities.
That are two completely different things which we shouldn't mix up.
Regards,
Christian.
Am 24.08.21 um 07:55 schrieb Satyajit Sahu:
Adding a new priority level DRM_SCHED_PRIORITY_VERY_HIGH
Signed-off-by: Satyajit Sahu <satyajit.sahu@xxxxxxx>
---
include/drm/gpu_scheduler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index d18af49fd009..d0e5e234da5f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -40,6 +40,7 @@ enum drm_sched_priority {
DRM_SCHED_PRIORITY_MIN,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
+ DRM_SCHED_PRIORITY_VERY_HIGH,
DRM_SCHED_PRIORITY_KERNEL,
DRM_SCHED_PRIORITY_COUNT,
