[Intel-gfx] [PATCH 08/10] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path

Sagar Arun Kamble sagar.a.kamble at intel.com
Fri Sep 22 04:13:21 UTC 2017



On 9/22/2017 1:19 AM, Oscar Mateo wrote:
>
>
> On 09/21/2017 12:09 PM, Sagar Arun Kamble wrote:
>>
>>
>> On 9/22/2017 12:03 AM, Oscar Mateo wrote:
>>> <SNIP>
>>>
>>>
>>> On 09/17/2017 05:17 AM, Sagar Arun Kamble wrote:
>>>> Teardown of GuC HW/SW state was not properly done in unload path.
>>>> guc_submission_disable was called as part of intel_uc_fini_hw which
>>>> happens post gem_unload in the i915_driver_unload path.
>>>> s/i915_gem_fini/i915_gem_cleanup as it looks more suitable as that
>>>> function does cleanup.
>>>> To differentiate the tasks during suspend and unload w.r.t GuC this
>>>> patch introduces new function i915_gem_fini which in addition to
>>>> disabling GuC interfaces also disables GuC submission during which
>>>> communication with GuC is needed for destroying doorbell.
>>>> i915_gem_fini is copy of i915_gem_suspend with difference w.r.t
>>>> GuC operations. To achieve this, new helpers i915_gem_context_suspend
>>>> and i915_gem_suspend_complete are prepared.
>>>>
>>>
>>> Sagar, I just realized this patch would make this comment in 
>>> guc_client_free superfluous, right?:
>>>
>>>     /* FIXME: in many cases, by the time we get here the GuC has been
>>>      * reset, so we cannot destroy the doorbell properly. Ignore the
>>>      * error message for now */
>>>
>>> Can you make sure you remove it in this patch?
>>>
>>> Thanks!
>> Yes. Will need to remove this comment :)
>> Will make this change as part of 
>> https://patchwork.freedesktop.org/patch/178189/
>> How about another comment before it? i915_gem_suspend is ensuring no 
>> outstanding submissions before coming to
>> uc_suspend. So shall we remove that as well?
>>
>>         /*
>>          * XXX: wait for any outstanding submissions before freeing 
>> memory.
>>          * Be sure to drop any locks
>>          */
>
> I have the impression that this comment was here as a future design 
> guide for Direct Submission. It seems to be the case for almost all 
> the "XXX" comments in that file, like:
>
>     /* XXX: wait for any interrupts */
>     /* XXX: wait for workqueue to drain */
>
> Since Direct Submission is not being considered at the moment, maybe 
> we can just drop of all them (or transform them into something more 
> innocuous than a "XXX").
> What do people think?
>
I feel it makes sense to keep for future changes then. If needed, let us 
update these in separate patch.
Thanks for the review Oscar.


More information about the Intel-gfx mailing list