[Intel-gfx] [PATCH 38/40] drm/i915/execlists: Flush the CS events before unpinning

[Tvrtko Ursulin]

On 01/10/2018 14:26, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-10-01 14:15:49)
>>
>> On 01/10/2018 12:06, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-10-01 11:51:23)
>>>>
>>>> Hm hm hm... my initial thought was that interrupts could be more delayed
>>>> than breadcrumb writes (more than one context ahead), in which case the
>>>> process_csb below could be premature and the assert would trigger. But I
>>>> must be forgetting something since that would also mean we would
>>>> prematurely unpin the context. So I must be forgetting something..
>>>
>>> There will have been at least one CS event written because we have
>>> switched contexts due to the unpin being one seqno behind. I have not
>>> (yet) observed CS events being out of order with breadcrumb writes (and
>>> we have very strict checking) so confident that a single process_csb()
>>> is required rather than a loop.
>>
>> I did not mean out of order but just delayed.
>>
>> Say port 0 & 1 are both submitted, we observe seqno 1 & 2 as complete,
>> but the ctx complete irq/handler has been delayed. We go to unpin ctx0
>> (port0) but ce->active hasn't been cleared due no ctx complete yet so
>> the assert triggers. Impossible in your experience?
> 
> I have not seen anything to doubt that the CS interrupts, and more
> importantly here, the CS events are delayed. It's the CS event itself
> that we care about, and I think we are very safe in our assertion that
> it is written on the context switch prior to the breadcrumb in the
> second context.

Ugh.. yes.. direct call of the tasklet exactly has nothing to do with 
irq delivery. My confusion.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Regards,

Tvrtko