[Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Sagar Arun Kamble]

On 3/2/2018 3:44 PM, Sagar Arun Kamble wrote:
>
>
> On 3/2/2018 2:01 PM, Chris Wilson wrote:
>> Quoting Sagar Arun Kamble (2018-03-01 16:45:45)
>>> +static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct i915_vma 
>>> *vma)
>>> +{
>>> +       struct intel_huc *huc = container_of(huc_fw, struct 
>>> intel_huc, fw);
>>> +       struct drm_i915_private *dev_priv = huc_to_i915(huc);
>>> +       unsigned long offset = 0;
>>> +       u32 size;
>>> +       int ret;
>>> +
>>> +       GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
>>> +
>>> +       intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>>> +
>>> +       /* Set the source address for the uCode */
>>> +       offset = guc_ggtt_offset(vma) + huc_fw->header_offset;
>>> +       I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
>>> +       I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0xFFFF);
>> So these same registers are used to transfer the guc image. What
>> serialisation do we have between the two to prevent conflicts?
>>
>> (lockdep_assert_held the appropriate guard with explanation :)
> Yes. Currently they are implicitly serialized by load ordering. Will 
> need locking if async load is to be done.
> But no harm in adding locking/lockdep now. Will do. Thank you.
Hi Chris,

Checked more on this and I see that *HuC has to be loaded before GuC 
always* hence we will not have situation of
dma_xfer for them happening in parallel. So we don't need the locking.

Thanks,
Sagar
>> As it's not a new issue, please follow up with another patch and we'll
>> apply this in the meantime.
>> -Chris
>

-- 
Thanks,
Sagar