From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v12 05/11] drm/i915/guc: Introduce intel_uc_sanitize
Date: Fri, 29 Sep 2017 19:52:04 +0530 [thread overview]
Message-ID: <912405da-7f86-404f-e4fe-ead1db648d27@intel.com> (raw)
In-Reply-To: <1506686438.4729.69.camel@linux.intel.com>
On 9/29/2017 5:30 PM, Joonas Lahtinen wrote:
> On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote:
>> Currently GPU is reset at the end of suspend via i915_gem_sanitize.
>> On resume, GuC will not be loaded until intel_uc_init_hw happens
>> during GEM resume flow but action to exit sleep can be sent to GuC
>> considering the FW load status. To make sure we don't invoke that
>> action update GuC FW load status at the end of GPU reset as NONE.
>> load_status indicates HW state and it is sanitized through this new
>> function intel_uc_sanitize.
>>
>> v2: Rebase.
>>
>> v3: Removed intel_guc_sanitize. Marking load status as NONE at the
>> GPU reset point. (Chris/Michal)
>>
>> v4: Reinstated the uC function intel_uc_sanitize. (Michal Wajdeczko)
>>
>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> <SNIP>
>
>> @@ -508,6 +508,18 @@ int intel_uc_resume(struct drm_i915_private *dev_priv)
>> return intel_guc_resume(dev_priv);
>> }
>>
>> +void intel_uc_sanitize(struct drm_i915_private *dev_priv)
>> +{
>> + /*
>> + * FIXME: intel_uc_resume currently depends on load_status to resume
>> + * GuC. Since we are resetting Full GPU at the end of suspend, let us
>> + * mark the load status as NONE. Once intel_uc_resume is updated to take
>> + * into consideration GuC load state based on WOPCM, we can skip this
>> + * state update.
>> + */
>> + dev_priv->guc.fw.load_status = INTEL_UC_FIRMWARE_NONE;
> With what I suggested to Michal, this would be call to
> intel_guc_sanitize() (and in future also intel_huc_sanitize()
> intel_dmc_sanitize()).
Yes.
>
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -1763,6 +1763,9 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
>> }
>> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>>
>> + if (engine_mask == ALL_ENGINES)
>> + intel_uc_sanitize(dev_priv);
> We could propagate engine_mask to intel_uc_sanitize and let it decide
> what it does to keep a clear top level code flow. This also doesn't
> seem to depend on if GuC submission is enabled or not.
Sure. will make this change.
> If we want to be unconditional, wouldn't intel_guc_select_fw would not
> be more appropriate in intel_uc_sanitize?
Do we want to select different fw across resets? That would mean
changing i915.guc_firmware_path at runtime which I guess we don't want
do right?
> Regards, Joonas
_______________________________________________
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-29 14:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 6:48 [PATCH v12 00/11] GEM/GuC Suspend/Resume/Reset fixes and restructuring Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 01/11] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors Sagar Arun Kamble
2017-09-29 11:43 ` Joonas Lahtinen
2017-09-29 11:49 ` Chris Wilson
2017-09-29 13:16 ` Joonas Lahtinen
2017-09-29 13:51 ` Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 02/11] drm/i915: Update GEM suspend/resume flows with GuC suspend/resume functions Sagar Arun Kamble
2017-09-29 11:45 ` Joonas Lahtinen
2017-09-29 13:52 ` Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 03/11] drm/i915: Move i915_gem_restore_fences to i915_gem_resume Sagar Arun Kamble
2017-09-29 11:48 ` Joonas Lahtinen
2017-09-29 13:59 ` Sagar Arun Kamble
2017-09-29 14:01 ` Sagar Arun Kamble
2017-10-02 8:33 ` Joonas Lahtinen
2017-09-28 6:48 ` [PATCH v12 04/11] drm/i915: Create uC runtime and system suspend/resume helpers Sagar Arun Kamble
2017-09-29 12:12 ` Joonas Lahtinen
2017-09-29 14:13 ` Sagar Arun Kamble
2017-09-29 14:39 ` Michal Wajdeczko
2017-09-28 6:48 ` [PATCH v12 05/11] drm/i915/guc: Introduce intel_uc_sanitize Sagar Arun Kamble
2017-09-29 12:00 ` Joonas Lahtinen
2017-09-29 14:22 ` Sagar Arun Kamble [this message]
2017-10-02 8:37 ` Joonas Lahtinen
2017-09-28 6:48 ` [PATCH v12 06/11] drm/i915/guc: Make GuC related disable/destroy functions not depend on i915.enable_guc_submission Sagar Arun Kamble
2017-09-29 12:27 ` Joonas Lahtinen
2017-09-30 8:22 ` Sagar Arun Kamble
2017-10-02 8:51 ` Joonas Lahtinen
2017-09-28 6:48 ` [PATCH v12 07/11] drm/i915/guc: Update i915.enable_guc_loading check in intel_uc_fini_hw Sagar Arun Kamble
2017-09-29 12:29 ` Joonas Lahtinen
2017-09-28 6:48 ` [PATCH v12 08/11] drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 09/11] drm/i915/guc: Update GuC functionality in intel_uc_suspend/intel_uc_resume Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 10/11] drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset Sagar Arun Kamble
2017-09-28 6:48 ` [PATCH v12 11/11] drm/i915/guc: Fix GuC cleanup in unload path Sagar Arun Kamble
2017-09-28 7:11 ` ✗ Fi.CI.BAT: warning for GEM/GuC Suspend/Resume/Reset fixes and restructuring (rev5) Patchwork
2017-09-28 7:38 ` Sagar Arun Kamble
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=912405da-7f86-404f-e4fe-ead1db648d27@intel.com \
--to=sagar.a.kamble@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.