[Intel-gfx] [PATCH v12 06/11] drm/i915/guc: Make GuC related disable/destroy functions not depend on i915.enable_guc_submission

Joonas Lahtinen joonas.lahtinen at linux.intel.com
Mon Oct 2 08:51:12 UTC 2017


On Sat, 2017-09-30 at 13:52 +0530, Sagar Arun Kamble wrote:
> 
> On 9/29/2017 5:57 PM, Joonas Lahtinen wrote:
> > On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote:
> > > During GuC load/enable, state is setup by driver that can be looked at
> > > while disabling. So remove the check for i915.enable_guc_submission
> > > parameter in those functions.
> > > 
> > > Suggested-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Signed-off-by: Sagar Arun Kamble <sagar.a.kamble at intel.com>
> > > Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> > > Cc: MichaƂ Winiarski <michal.winiarski at intel.com>
> > 
> > <SNIP>
> > 
> > > @@ -1002,7 +1002,8 @@ static int guc_ads_create(struct intel_guc *guc)
> > >   
> > >   static void guc_ads_destroy(struct intel_guc *guc)
> > >   {
> > > -	i915_vma_unpin_and_release(&guc->ads_vma);
> > > +	if (guc->ads_vma)
> > 
> > GEM_BUG_ON(!guc->ads_vma);
> 
> This check was unnecessary. Suggestion from Chris was to make these 
> destroys be self-check based instead of invoking
> based on module parameters like enable_guc_submission/loading. In my new 
> patch I have removed these checks.
> https://patchwork.freedesktop.org/patch/179683/

I pinged Chris about this. I do prefer the symmetry, and I think we
could have guc->enable_submission variable based on which
i915_guc_submission_init/fini() would be executed on. No conditionals
in the _init/_fini themselves. You can of course do the
enable_submission check at the beginning of i915_guc_submission_init
and _fini too, if that feels clearer for the upper level code flow.

If _init is called and succeeds, _fini needs to be called. If _init
fails, _fini is to never be called. The check outside or inside will
both adhere to that.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation


More information about the Intel-gfx mailing list