Re: [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 16/08/16 06:25, Goel, Akash wrote:
> On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote:
>> On 15/08/16 15:49, akash.goel@intel.com wrote:
>>> From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>>
>>> Before capturing the GuC logs as a part of error state, there should
>>> be a
>>> force log buffer flush action sent to GuC before proceeding with GPU
>>> reset
>>> and re-initializing GUC. There could be some data in the log buffer
>>> which
>>> is yet to be captured and those logs would be particularly useful to
>>> understand that why the GPU reset was initiated.
>>>
>>> v2:
>>> - Avoid the wait via flush_work, to serialize against an ongoing log
>>>    buffer flush, from the error state capture path. (Chris)
>>
>> Could you explain if the patch does anything now that the flush has been
>> removed?
>>
> flush_work for the regular log buffer flush work item has been removed
> but the forceful command is still sent to GuC.
>
>> In fact I don't even understand what it was doing before. :)
>>
> I am sorry for that.
>
>> If the idea is to send a flush command to GuC so it can raise an
>> interrupt for a partially full buffer,
> Yes exactly this is the idea.

But then isn't the order wrong? Should it first send the flush command 
to the GuC and then wait for something maybe gets flushed? I can see 
that it could be tricky since the timing is undefined, but I don't 
understand where it currently actually processes that potential extra 
packets. Especially since it disabled interrupts before hand.

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx