All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 19/19] drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable
Date: Fri, 19 Aug 2016 13:19:13 +0300	[thread overview]
Message-ID: <1471601953.29793.1.camel@intel.com> (raw)
In-Reply-To: <1471596198-30748-20-git-send-email-akash.goel@intel.com>

On pe, 2016-08-19 at 14:13 +0530, akash.goel@intel.com wrote:
> From: Akash Goel <akash.goel@intel.com>
> 
> The GuC log buffer flush work item has to do a register access to send the
> ack to GuC and this work item, if not synced before suspend, can potentially
> get executed after the GFX device is suspended. This work item function uses
> rpm get/put calls around the Hw access, which covers the rpm suspend case
> but for system suspend a sync would be required as kernel can potentially
> schedule the work items even after some devices, including GFX, have been
> put to suspend. But sync has to be done only for the system suspend case,
> as sync along with rpm get/put can cause a deadlock for rpm suspend path.
> To have the sync, but like a NOOP, for rpm suspend path also this work
> item could have been queued from the irq handler only when the device is
> runtime active & kept active while that work item is pending or getting
> executed but an interrupt can come even after the device is out of use and
> so can potentially lead to missing of this work item.
> 
> By marking the workqueue, dedicated for handling GuC log buffer flush
> interrupts, as freezable we don't have to bother about flushing of this
> work item from the suspend hooks, the pending work item if any will be
> either executed before the suspend or scheduled later on resume. This way
> the handling of log buffer flush work item can be kept same between system
> suspend & rpm suspend.
> 
> Suggested-by: Imre Deak <imre.deak@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Akash Goel <akash.goel@intel.com>

Thanks for taking the time, looks good to me:
Reviewed-by: Imre Deak <imre.deak@intel.com>

> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index d4a1c84..bb25404 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1242,8 +1242,19 @@ static int guc_create_log_extras(struct intel_guc *guc)
>  
>  		/* Need a dedicated wq to process log buffer flush interrupts
>  		 * from GuC without much delay so as to avoid any loss of logs.
> +		 *
> +		 * GuC log buffer flush work item has to do register access to
> +		 * send the ack to GuC and this work item, if not synced before
> +		 * suspend, can potentially get executed after the GFX device is
> +		 * suspended.
> +		 * By marking the WQ as freezable, we don't have to bother about
> +		 * flushing of this work item from the suspend hooks, the pending
> +		 * work item if any will be either executed before the suspend
> +		 * or scheduled later on resume. This way the handling of work
> +		 * item can be kept same between system suspend & rpm suspend.
>  		 */
> -		guc->log.flush_wq = alloc_ordered_workqueue("i915-guc_log", 0);
> +		guc->log.flush_wq =
> +			alloc_ordered_workqueue("i915-guc_log", WQ_FREEZABLE);
>  		if (guc->log.flush_wq == NULL) {
>  			DRM_ERROR("Couldn't allocate the wq for GuC logging\n");
>  			return -ENOMEM;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-08-19 10:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19  8:42 [PATCH v8 00/19] Support for sustained capturing of GuC firmware logs akash.goel
2016-08-19  8:43 ` [PATCH 01/19] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-08-19  8:43 ` [PATCH 02/19] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-08-19  8:43 ` [PATCH 03/19] drm/i915: New structure to contain GuC logging related fields akash.goel
2016-08-19  8:43 ` [PATCH 04/19] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set akash.goel
2016-08-19  8:43 ` [PATCH 05/19] drm/i915: Support for GuC interrupts akash.goel
2016-08-19  8:43 ` [PATCH 06/19] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-08-19 10:08   ` Tvrtko Ursulin
2016-08-19  8:43 ` [PATCH 07/19] relay: Use per CPU constructs for the relay channel buffer pointers akash.goel
2016-08-19  8:43 ` [PATCH 08/19] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-08-19 18:03   ` Chris Wilson
2016-08-20  6:40     ` Goel, Akash
2016-08-19  8:43 ` [PATCH 09/19] drm/i915: New lock to serialize the Host2GuC actions akash.goel
2016-08-19  8:43 ` [PATCH 10/19] drm/i915: Add stats for GuC log buffer flush interrupts akash.goel
2016-08-19  8:43 ` [PATCH 11/19] drm/i915: Optimization to reduce the sampling time of GuC log buffer akash.goel
2016-08-19  8:43 ` [PATCH 12/19] drm/i915: Increase GuC log buffer size to reduce flush interrupts akash.goel
2016-08-19  8:43 ` [PATCH 13/19] drm/i915: Augment i915 error state to include the dump of GuC log buffer akash.goel
2016-08-19  8:43 ` [PATCH 14/19] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-08-19 18:10   ` Chris Wilson
2016-08-20  6:49     ` Goel, Akash
2016-08-19  8:43 ` [PATCH 15/19] drm/i915: Debugfs support for GuC logging control akash.goel
2016-08-19 18:18   ` Chris Wilson
2016-08-20  6:40     ` Goel, Akash
2016-08-19  8:43 ` [PATCH 16/19] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer akash.goel
2016-08-19  8:43 ` [PATCH 17/19] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling " akash.goel
2016-08-19 18:19   ` Chris Wilson
2016-08-20  6:44     ` Goel, Akash
2016-08-20  8:40       ` Chris Wilson
2016-08-19  8:43 ` [PATCH 18/19] drm/i915: Early creation of relay channel for capturing boot time logs akash.goel
2016-08-19  8:43 ` [PATCH 19/19] drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable akash.goel
2016-08-19 10:19   ` Imre Deak [this message]
2016-08-19  9:01 ` ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev9) 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=1471601953.29793.1.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=akash.goel@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.