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

[Fernando Pacheco]

On 4/16/19 8:04 AM, Chris Wilson wrote:
> 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

Sorry, I thought I was providing an explanation. I'll revise!

> things in the code; function doc are for telling users how to use the
> iface.

Very true. Thanks for pointing this out.

Fernando

> -Chris