[Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

[Chris Wilson]

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.
-Chris