Quoting Chris Wilson (2018-01-10 19:32:09)
> Quoting Oscar Mateo (2018-01-10 19:25:39)
> >
> >
> > On 01/10/2018 01:36 AM, Chris Wilson wrote:
> > >> +/*
> > >> + * Determine which engines are fused off in our particular hardware.
> > >> + *
> > >> + * This function needs to be called after the MMIO has been setup (as we need
> > >> + * to read registers) but before uncore init (because the powerwell for the
> > >> + * fused off engines doesn't exist, so we cannot initialize forcewake for them)
> > >> + */
> > >> +void intel_device_info_fused_off_engines(struct drm_i915_private *dev_priv)
> > >> +{
> > >> + struct intel_device_info *info = mkwrite_device_info(dev_priv);
> > >> + u32 media_fuse;
> > >> + int i;
> > >> +
> > >> + if (INTEL_GEN(dev_priv) < 11)
> > >> + return;
> > >> +
> > >> + GEM_BUG_ON(!dev_priv->regs);
> > >> +
> > >> + media_fuse = I915_READ_FW(GEN11_GT_VEBOX_VDBOX_DISABLE);
> > >> +
> > >> + info->vdbox_disable = media_fuse & GEN11_GT_VDBOX_DISABLE_MASK;
> > >> + info->vebox_disable = (media_fuse & GEN11_GT_VEBOX_DISABLE_MASK) >>
> > >> + GEN11_GT_VEBOX_DISABLE_SHIFT;
> > > We don't need to keep these (just locals will do), the permanent
> > > information is in info->ring_mask.
> >
> > There are subsequent patches that pass this info to GuC, that's why I
> > was keeping them. I could retrieve the information back from
> > info->ring_mask, but it's a pity since we already have it in the right
> > format here.
>
> If there's a use, sure. You can always add it later along with the user
> if the patches are separated into a different series. Just nothing in
> this patch justified keeping them.
The counter argument is that if there is only a single use case, reading
the registers again isn't an issue, especially if, as you say, the
register contents are exactly what the guc wants to be told.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
