intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: Oscar Mateo <oscar.mateo@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 08/12] drm/i915/guc: Wait for doorbell to be inactive before deallocating
Date: Tue, 21 Mar 2017 11:20:14 -0700	[thread overview]
Message-ID: <a3ba13e6-f991-4e23-ab6c-ccf514d6ae22@intel.com> (raw)
In-Reply-To: <1490086977-9282-9-git-send-email-oscar.mateo@intel.com>



On 3/21/2017 2:02 AM, Oscar Mateo wrote:
> Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
> to zero after updating db_status before we call the GuC to release the
> doorbell.
>
> Kudos to Daniele for finding this out.
>
> v2: WARN instead of DRM_ERROR (Joonas)
>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

I'd like Joonas to give his ack on not returning after the wait since he 
commented on it in the previous version. I personally prefer it this way 
because we gain a bit more time for the doorbell to disable itself 
(there is no spec in regards to how long this should take, but it should 
be quick) while the GuC processes the H2G. If we ever see a case where 
the warn fires but the H2G is successful it would mean that we have to 
tune our wait time.

Thanks,
Daniele

> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 855112d..143ef26 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -206,12 +206,22 @@ static int __create_doorbell(struct i915_guc_client *client)
>
>  static int __destroy_doorbell(struct i915_guc_client *client)
>  {
> +	struct drm_i915_private *dev_priv = guc_to_i915(client->guc);
>  	struct guc_doorbell_info *doorbell;
> +	u16 db_id = client->doorbell_id;
> +
> +	GEM_BUG_ON(db_id >= GUC_DOORBELL_INVALID);
>
>  	doorbell = __get_doorbell(client);
>  	doorbell->db_status = GUC_DOORBELL_DISABLED;
>  	doorbell->cookie = 0;
>
> +	/* Doorbell release flow requires that we wait for GEN8_DRB_VALID bit
> +	 * to go to zero after updating db_status before we call the GuC to
> +	 * release the doorbell */
> +	if (wait_for_us(!(I915_READ(GEN8_DRBREGL(db_id)) & GEN8_DRB_VALID), 10))
> +		WARN_ONCE(true, "Doorbell never became invalid after disable\n");
> +




>  	return __guc_deallocate_doorbell(client->guc, client->ctx_index);
>  }
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-03-21 18:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21  9:02 [PATCH 00/12] Various improvements around the GuC topic Oscar Mateo
2017-03-21  9:02 ` [PATCH 01/12] drm/i915/guc: Sanitize GuC client initialization Oscar Mateo
2017-03-22  9:28   ` Joonas Lahtinen
2017-03-22  9:46     ` Oscar Mateo
2017-03-21  9:02 ` [PATCH 02/12] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access Oscar Mateo
2017-03-22  9:45   ` Chris Wilson
2017-03-22  9:42     ` Oscar Mateo
2017-03-22 16:57       ` Chris Wilson
2017-03-21  9:02 ` [PATCH 03/12] drm/i915/guc: Add onion teardown to the GuC setup Oscar Mateo
2017-03-21  9:02 ` [PATCH 04/12] drm/i915/guc: The Additional Data Struct (ADS) should get enabled together with GuC submission Oscar Mateo
2017-03-21 17:51   ` Ceraolo Spurio, Daniele
2017-03-21  9:02 ` [PATCH 05/12] drm/i915/guc: Break out the GuC log extras into their own "runtime" struct Oscar Mateo
2017-03-21  9:02 ` [PATCH 06/12] drm/i915/guc: Make intel_guc_send a function pointer Oscar Mateo
2017-03-21  9:02 ` [PATCH 07/12] drm/i915/guc: Improve the GuC documentation & comments about proxy submissions Oscar Mateo
2017-03-21 17:54   ` Ceraolo Spurio, Daniele
2017-03-21  9:02 ` [PATCH 08/12] drm/i915/guc: Wait for doorbell to be inactive before deallocating Oscar Mateo
2017-03-21 18:20   ` Ceraolo Spurio, Daniele [this message]
2017-03-21 11:24     ` Oscar Mateo
2017-03-22  9:33       ` Joonas Lahtinen
2017-03-21  9:02 ` [PATCH 09/12] drm/i915/guc: A little bit more of doorbell sanitization Oscar Mateo
2017-03-21  9:02 ` [PATCH 10/12] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor" Oscar Mateo
2017-03-22 10:05   ` Joonas Lahtinen
2017-03-21  9:02 ` [PATCH 11/12] drm/i915/guc: Split out the mmio_white_list struct Oscar Mateo
2017-03-21 18:04   ` Ceraolo Spurio, Daniele
2017-03-21  9:02 ` [PATCH 12/12] drm/i915/guc: Move guc_interrupts_release next to guc_interrupts_capture Oscar Mateo
2017-03-21 18:08   ` Ceraolo Spurio, Daniele
2017-03-21 17:42 ` ✗ Fi.CI.BAT: warning for Various improvements around the GuC topic Patchwork
2017-03-22 10:08   ` Joonas Lahtinen

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=a3ba13e6-f991-4e23-ab6c-ccf514d6ae22@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=oscar.mateo@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;
as well as URLs for NNTP newsgroup(s).