[Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros
Chris Wilson
chris at chris-wilson.co.uk
Wed Dec 6 13:41:26 UTC 2017
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 at 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 at intel.com>
> > >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > >> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > >> Cc: Sagar Arun Kamble <sagar.a.kamble at intel.com>
> > >> Reviewed-by: Chris Wilson <chris at 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
More information about the Intel-gfx
mailing list