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@xxxxxxxxxxxxxxxxxx>
> > > Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
> > > Cc: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx>
> > > Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx>
> >
> > <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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
