Yeah, probably good idea to have that separate.
But would still be a nice cleanup and it is merged upstream after the
etnaviv patches anyway.
Regards,
Christian.
Am 26.03.2018 um 17:29 schrieb Nayan Deshmukh:
I am not removing jobs parameters as of now as it will lead to changes
in all the calls to this function and will affect the etnaviv patches.
Regards,
Nayan.
On Sun, Mar 25, 2018 at 4:59 PM, Christian König
<christian.koenig@xxxxxxx> wrote:
Am 25.03.2018 um 13:21 schrieb Nayan Deshmukh:
On Sun, Mar 25, 2018 at 4:44 PM, Christian König
<christian.koenig@xxxxxxx> wrote:
Am 25.03.2018 um 13:09 schrieb Nayan Deshmukh:
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@xxxxxxxxx>
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..27fdda1264f7 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -117,7 +117,6 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
* @sched The pointer to the scheduler
* @entity The pointer to a valid drm_sched_entity
* @rq The run queue this entity belongs
- * @kernel If this is an entity for the kernel
* @jobs The max number of jobs in the job queue
If I'm not completely mistaken the jobs parameter is unused and we also
have
a @guilty parameter as well.
Yes. But I am not sure what should be done with the jobs parameter.
Should I remove it entirely?
Yes, probably a leftover from when we used a kfifo for the queue.
Regards,
Christian.
The description for the @guilty should be something like "atomic_t set to
1
when a job on this queue is found to be guilty causing a timeout".
Regards,
Christian.
*
* return 0 if succeed. negative error code on failure
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
