[PATCH] drm/scheduler: remove incorrect param documentation

Nayan Deshmukh nayan26deshmukh at gmail.com
Mon Mar 26 17:04:05 UTC 2018


I will send in the patches.

On Mon, Mar 26, 2018 at 10:29 PM, Christian König
<christian.koenig at amd.com> wrote:
> 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 at amd.com> 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 at amd.com> wrote:
>>>>>
>>>>> Am 25.03.2018 um 13:09 schrieb Nayan Deshmukh:
>>>>>>
>>>>>> Signed-off-by: Nayan Deshmukh <nayan26deshmukh at gmail.com>
>>>>>> ---
>>>>>>     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
>>>>>
>>>>>
>


More information about the dri-devel mailing list