[Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Mon Mar 5 12:25:21 UTC 2018
On 05/03/2018 11:21, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-03-05 11:12:45)
>>
>> On 05/03/2018 10:41, Chris Wilson wrote:
>>> After we call dma_fence_signal(), confirm that the request was indeed
>>> complete.
>>>
>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>> ---
>>> drivers/gpu/drm/i915/i915_irq.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>>> index ce16003ef048..633c18785c1e 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -1123,6 +1123,7 @@ static void notify_ring(struct intel_engine_cs *engine)
>>>
>>> if (rq) {
>>> dma_fence_signal(&rq->fence);
>>> + GEM_BUG_ON(!i915_request_completed(rq));
>>> i915_request_put(rq);
>>> }
>>>
>>>
>>
>> What's the motivation? There is a i915_seqno_passed check a few lines
>
> The seqno check is on wait.seqno, this is to confirm it all ties
> together with the request and our preemption avoidance is solid. The
> motivation was the bug in the signaler along the same lines.
>
>> above. So there would have to be a confusion in internal breadcrumbs
>> state for this to be possible. In which case I'd rather put the assert
>> in breadcrumbs code. For instance in intel_wait_check_request, asserting
>> that the seqno in wait matches the seqno in wait->request.
>
> The entire point of that check is to say when they don't match so that
> we know when the request was unsubmitted during the wait.
Ok my suggesting wasn't really appropriate. I just disliked a bit open
coding the assert. No smart and worthwhile suggestions to improve it.
i915_request_signal came to mind to wrap the assert and dma_fence_signal
but I dont see sufficient call sites.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Regards,
Tvrtko
More information about the Intel-gfx
mailing list