Re: [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Chris Wilson (2017-12-06 11:32:01)
> Quoting Michal Wajdeczko (2017-12-06 11:24:33)
> > On Tue, 05 Dec 2017 23:43:19 +0100, Chris Wilson  
> > <chris@chris-wilson.co.uk> wrote:
> > 
> > > Quoting Michal Wajdeczko (2017-12-05 16:38:39)
> > >> In the upcoming patch we will change the way how to recognize
> > >> when GuC is in use. Using helper macros will minimize scope
> > >> of that changes. While here, update dev_info message.
> > >>
> > >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > >> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > >> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> > >> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > ... but can we please stop it with dev_priv :) We don't use it now or
> > > later, we are just making it more complicated for no imminent benefit,
> > > right?
> > 
> > Note that there are few benefits for keeping dev_priv:
> > 
> > a) it nicely matches all other existing HAS_|USES_ macros
> >     (even if dev_priv is not used/required: see USES_PPGTT or HAS_AUX_IRQ)
> >     (yes I know that you want to kill former and later is not widely used ;)
> > b) as "uses" suggests that it reflects state of the driver, I hope one day
> >     we will stop relying on modparam and read actual state of driver from
> >     dev_priv (or struct guc or struct uc or something else that can be
> >     reached out from this dev_priv)
> 
> But we don't and we are adding it to places where we didn't need, if I
> remember the patches correctly. My concern is that we are creating work
> and not saving it, as we^W I don't have a design for the future derived
> state checks.

To be clear, I'm happy if you see value in keeping dev_priv. Just
whinging, because first its dev_priv! and I could see no reason why we
need it. (So whether it is a "stitch in time" is debatable, it may
equally just cause more work later.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx