[Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT

[Chris Wilson]

Quoting Fernando Pacheco (2019-04-16 15:51:15)
> 
> On 4/9/19 3:22 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:01)
> >> diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
> >> index 94c04f16a2ad..89e0b942ae86 100644
> >> --- a/drivers/gpu/drm/i915/intel_huc.c
> >> +++ b/drivers/gpu/drm/i915/intel_huc.c
> >> @@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
> >>         return 0;
> >>  }
> >>  
> >> +/*
> >> + * The HuC firmware image now sits above GUC_GGTT_TOP and this
> >> + * portion does not map through GTT. This means GuC cannot
> >> + * perform the HuC auth with the rsa signature sitting in that
> >> + * range. We resort to additionally perma-pinning the rsa signature
> >> + * below GUC_GGTT_TOP and utilizing this mapping to perform
> >> + * the authentication.
> >> + */
> >> +static int intel_huc_rsa_data_create(struct intel_huc *huc)
> >> +{
> >> +       struct drm_i915_private *i915 = huc_to_i915(huc);
> >> +       struct intel_guc *guc = &i915->guc;
> >> +       struct i915_vma *vma;
> >> +       void *vaddr;
> >> +
> >> +       vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
> >> +       if (IS_ERR(vma))
> >> +               return PTR_ERR(vma);
> >> +
> > Are we not allocating an object for the dma xfer here that is then bound
> > to the reserved ggtt node? Why pin it again into the ggtt?
> > -Chris
> 
> It is not bound to the reserved node. The reserved range is inaccessible by GuC, so I
> had to pull the signature back in for the auth stage.

Oh I see a stray comment above the function, and not about why you
allocate a second pinned vma. Comments are for describing why you do
things in the code; function doc are for telling users how to use the
iface.
-Chris