From: Oscar Mateo <oscar.mateo@intel.com>
To: Sagar Arun Kamble <sagar.a.kamble@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 08/10] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path
Date: Thu, 21 Sep 2017 12:49:10 -0700 [thread overview]
Message-ID: <25313eb8-e67c-454f-aa65-a3d909c510c7@intel.com> (raw)
In-Reply-To: <f058310b-aa0e-ef97-90f3-1d7b418089bb@intel.com>
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?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-09-21 19:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-17 12:17 [PATCH 01/10] drm/i915/guc: Create intel_guc.c for defining GuC specific functionality Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 02/10] drm/i915/guc: Move guc_send_* functions to intel_guc.c Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 03/10] drm/i915/guc: Move guc_sample_forcewake " Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 04/10] drm/i915/guc: Move GuC specific declarations from intel_uc.h to intel_guc.h Sagar Arun Kamble
2017-09-17 18:24 ` Michal Wajdeczko
2017-09-18 6:10 ` Kamble, Sagar A
2017-09-17 12:17 ` [PATCH 05/10] drm/i915: Reorganize HuC authentication Sagar Arun Kamble
2017-09-17 18:41 ` Michal Wajdeczko
2017-09-17 12:17 ` [PATCH 06/10] drm/i915/huc: Move HuC specific declarations from intel_uc.h to intel_huc.h Sagar Arun Kamble
2017-09-17 20:13 ` Michal Wajdeczko
2017-09-18 6:24 ` Kamble, Sagar A
2017-09-17 12:17 ` [PATCH 07/10] drm/i915/guc: Fix GuC interaction in reset/suspend scenarios Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 08/10] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path Sagar Arun Kamble
2017-09-21 18:33 ` Oscar Mateo
2017-09-21 19:09 ` Sagar Arun Kamble
2017-09-21 19:49 ` Oscar Mateo [this message]
2017-09-22 4:13 ` Sagar Arun Kamble
2017-09-22 4:42 ` Sagar Arun Kamble
2017-09-22 4:42 ` [PATCH v6] drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend path Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 09/10] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9 Sagar Arun Kamble
2017-09-17 12:17 ` [PATCH 10/10] drm/i915/guc: Remove i915_guc_log_unregister Sagar Arun Kamble
2017-09-17 19:30 ` [PATCH 01/10] drm/i915/guc: Create intel_guc.c for defining GuC specific functionality Michal Wajdeczko
2017-09-18 6:23 ` Kamble, Sagar A
2017-09-18 6:59 ` ✓ Fi.CI.BAT: success for series starting with [01/10] " Patchwork
2017-09-18 7:53 ` ✗ Fi.CI.IGT: warning " Patchwork
2017-09-22 11:00 ` ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915/guc: Create intel_guc.c for defining GuC specific functionality (rev2) Patchwork
2017-09-22 11:26 ` Kamble, Sagar A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25313eb8-e67c-454f-aa65-a3d909c510c7@intel.com \
--to=oscar.mateo@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sagar.a.kamble@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox