From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Oscar Mateo <oscar.mateo@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating
Date: Thu, 16 Mar 2017 15:26:19 +0200 [thread overview]
Message-ID: <1489670779.3964.21.camel@linux.intel.com> (raw)
In-Reply-To: <1489163337-36080-9-git-send-email-oscar.mateo@intel.com>
On pe, 2017-03-10 at 08:28 -0800, 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.
>
> 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>
<SNIP>
> 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))
> + DRM_ERROR("Doorbell never became invalid after disable\n");
Would the appropriate action be to return -ETIMEOUT and not proceed
with deallocation? I would at least WARN here. If GuC submission gets
enabled, we should yell if it's not working. So only the enable stage
should bail out with DRM_ERRORs and without WARN.
> +
> return __guc_deallocate_doorbell(client->guc, client->ctx_index);
> }
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-03-16 13:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 16:28 [00/11 v2] Various improvements around the GuC topic Oscar Mateo
2017-03-10 16:28 ` [01/11 v3] drm/i915/guc: Sanitize GuC client initialization Oscar Mateo
2017-03-13 20:19 ` Daniele Ceraolo Spurio
2017-03-10 16:28 ` [02/11 v3] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access Oscar Mateo
2017-03-10 16:28 ` [03/11 v3] drm/i915/guc: Add onion teardown to the GuC setup Oscar Mateo
2017-03-13 13:30 ` Arkadiusz Hiler
2017-03-16 13:04 ` Joonas Lahtinen
2017-03-10 16:28 ` [04/11 v2] drm/i915/guc: s/ads_vma/addon Oscar Mateo
2017-03-10 16:28 ` [05/11 v2] drm/i915/guc: Break out the GuC log extras into their own "runtime" struct Oscar Mateo
2017-03-16 13:20 ` Joonas Lahtinen
2017-03-10 16:28 ` [06/11 v3] drm/i915/guc: Make intel_guc_send a function pointer Oscar Mateo
2017-03-13 21:00 ` Daniele Ceraolo Spurio
2017-03-10 16:28 ` [07/11] drm/i915/guc: Improve the GuC documentation & comments about proxy submissions Oscar Mateo
2017-03-13 21:37 ` Daniele Ceraolo Spurio
2017-03-10 16:28 ` [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating Oscar Mateo
2017-03-13 11:46 ` Chris Wilson
2017-03-13 8:56 ` Oscar Mateo
2017-03-15 0:55 ` Daniele Ceraolo Spurio
2017-03-16 13:26 ` Joonas Lahtinen [this message]
2017-03-10 16:28 ` [09/11] drm/i915/guc: A little bit more of doorbell sanitization Oscar Mateo
2017-03-20 13:14 ` Joonas Lahtinen
2017-03-10 16:28 ` [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor" Oscar Mateo
2017-03-13 11:49 ` Chris Wilson
2017-03-13 8:59 ` Oscar Mateo
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=1489670779.3964.21.camel@linux.intel.com \
--to=joonas.lahtinen@linux.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 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.