From: "Goel, Akash" <akash.goel@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset
Date: Tue, 16 Aug 2016 17:49:49 +0530 [thread overview]
Message-ID: <f854e784-302f-ba6b-944a-5ff2af7fc53d@intel.com> (raw)
In-Reply-To: <57B2F888.1030106@linux.intel.com>
On 8/16/2016 4:57 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)
>> - Rebase.
>>
>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Signed-off-by: Akash Goel <akash.goel@intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
>> drivers/gpu/drm/i915/i915_guc_submission.c | 30
>> ++++++++++++++++++++++++++++++
>> drivers/gpu/drm/i915/intel_guc.h | 1 +
>> 3 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
>> b/drivers/gpu/drm/i915/i915_gpu_error.c
>> index 94297aa..b73c671 100644
>> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
>> @@ -1301,6 +1301,8 @@ static void
>> i915_gem_capture_guc_log_buffer(struct drm_i915_private *dev_priv,
>> if (!dev_priv->guc.log.vma || (i915.guc_log_level < 0))
>> return;
>>
>> + i915_guc_flush_logs(dev_priv, false);
>> +
>> error->guc_log = i915_error_object_create(dev_priv,
>> dev_priv->guc.log.vma);
>> }
>> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
>> b/drivers/gpu/drm/i915/i915_guc_submission.c
>> index b8d6313..85df2f3 100644
>> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
>> @@ -185,6 +185,16 @@ static int
>> host2guc_logbuffer_flush_complete(struct intel_guc *guc)
>> return host2guc_action(guc, data, 1);
>> }
>>
>> +static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
>> +{
>> + u32 data[2];
>> +
>> + data[0] = HOST2GUC_ACTION_FORCE_LOG_BUFFER_FLUSH;
>> + data[1] = 0;
>> +
>> + return host2guc_action(guc, data, 2);
>> +}
>> +
>> /*
>> * Initialise, update, or clear doorbell data shared with the GuC
>> *
>> @@ -1536,6 +1546,26 @@ void i915_guc_capture_logs(struct
>> drm_i915_private *dev_priv)
>> intel_runtime_pm_put(dev_priv);
>> }
>>
>> +void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool
>> can_wait)
>> +{
>> + if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
>> + return;
>> +
>> + /* First disable the interrupts, will be renabled afterwards */
>> + gen9_disable_guc_interrupts(dev_priv);
>> +
>> + /* Before initiating the forceful flush, wait for any
>> pending/ongoing
>> + * flush to complete otherwise forceful flush may not happen, but
>> wait
>> + * can't be done for some paths like error state capture in which
>> case
>> + * take a chance & directly attempt the forceful flush.
>> + */
>> + if (can_wait)
>> + flush_work(&dev_priv->guc.log.flush_work);
>> +
>> + /* Ask GuC to update the log buffer state */
>> + host2guc_force_logbuffer_flush(&dev_priv->guc);
>
> Should you just call i915_guc_capture_logs from here? Error capture
> could also potentially benefit from it and you could remove it from the
> debugfs patch then.
>
Actually earlier it was done like that only, but now after adding the
patch,
[PATCH 13/18] drm/i915: Augment i915 error state to include the dump of
GuC log buffer,
Contents of GuC log buffer is anyways made part of the error state, so
thought it may not be of any real use to capture the left over logs in
the relay sub buffer also.
For the analysis purpose, GuC logs part of the error state dump would be
good enough.
best regards
Akash
>> +}
>> +
>> void i915_guc_unregister(struct drm_i915_private *dev_priv)
>> {
>> if (!i915.enable_guc_submission)
>> diff --git a/drivers/gpu/drm/i915/intel_guc.h
>> b/drivers/gpu/drm/i915/intel_guc.h
>> index 8598f38..d7eda42 100644
>> --- a/drivers/gpu/drm/i915/intel_guc.h
>> +++ b/drivers/gpu/drm/i915/intel_guc.h
>> @@ -182,6 +182,7 @@ int i915_guc_wq_check_space(struct
>> drm_i915_gem_request *rq);
>> void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
>> void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
>> void i915_guc_capture_logs(struct drm_i915_private *dev_priv);
>> +void i915_guc_flush_logs(struct drm_i915_private *dev_priv, bool
>> can_wait);
>> void i915_guc_register(struct drm_i915_private *dev_priv);
>> void i915_guc_unregister(struct drm_i915_private *dev_priv);
>>
>>
>
> Regards,
>
> Tvrtko
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-16 12:19 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 14:49 [PATCH v6 00/18] Support for sustained capturing of GuC firmware logs akash.goel
2016-08-15 14:49 ` [PATCH 01/18] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-08-15 14:49 ` [PATCH 02/18] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-08-15 14:49 ` [PATCH 03/18] drm/i915: New structure to contain GuC logging related fields akash.goel
2016-08-15 14:49 ` [PATCH 04/18] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set akash.goel
2016-08-15 14:49 ` [PATCH 05/18] drm/i915: Support for GuC interrupts akash.goel
2016-08-15 14:54 ` Tvrtko Ursulin
2016-08-15 14:49 ` [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-08-15 15:20 ` Tvrtko Ursulin
2016-08-15 15:57 ` Goel, Akash
2016-08-15 16:06 ` Chris Wilson
2016-08-15 16:46 ` Goel, Akash
2016-08-15 16:56 ` Chris Wilson
2016-08-16 5:37 ` Goel, Akash
2016-08-15 14:49 ` [PATCH 07/18] relay: Use per CPU constructs for the relay channel buffer pointers akash.goel
2016-08-15 14:49 ` [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-08-15 15:29 ` Tvrtko Ursulin
2016-08-15 16:02 ` Goel, Akash
2016-08-15 16:09 ` Chris Wilson
2016-08-15 16:12 ` Chris Wilson
2016-08-15 16:38 ` Goel, Akash
2016-08-15 16:47 ` Chris Wilson
2016-08-15 14:49 ` [PATCH 09/18] drm/i915: New lock to serialize the Host2GuC actions akash.goel
2016-08-15 14:49 ` [PATCH 10/18] drm/i915: Add stats for GuC log buffer flush interrupts akash.goel
2016-08-15 14:49 ` [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer akash.goel
2016-08-15 15:36 ` Tvrtko Ursulin
2016-08-15 16:13 ` Goel, Akash
2016-08-15 14:49 ` [PATCH 12/18] drm/i915: Increase GuC log buffer size to reduce flush interrupts akash.goel
2016-08-15 14:49 ` [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer akash.goel
2016-08-15 15:39 ` Tvrtko Ursulin
2016-08-15 14:49 ` [PATCH 14/18] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-08-15 15:48 ` Tvrtko Ursulin
2016-08-16 5:25 ` Goel, Akash
2016-08-16 9:25 ` Tvrtko Ursulin
2016-08-16 9:39 ` Goel, Akash
2016-08-16 9:42 ` Tvrtko Ursulin
2016-08-16 11:27 ` Tvrtko Ursulin
2016-08-16 12:19 ` Goel, Akash [this message]
2016-08-15 14:49 ` [PATCH 15/18] drm/i915: Debugfs support for GuC logging control akash.goel
2016-08-15 16:03 ` Tvrtko Ursulin
2016-08-15 14:49 ` [PATCH 16/18] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer akash.goel
2016-08-15 14:49 ` [PATCH 17/18] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling " akash.goel
2016-08-15 14:49 ` [PATCH 18/18] drm/i915: Early creation of relay channel for capturing boot time logs akash.goel
2016-08-15 15:59 ` Tvrtko Ursulin
2016-08-15 15:10 ` ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev7) Patchwork
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=f854e784-302f-ba6b-944a-5ff2af7fc53d@intel.com \
--to=akash.goel@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox