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.lahti...@linux.intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com>
> Signed-off-by: Oscar Mateo <oscar.ma...@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
