[Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
Sagar Arun Kamble
sagar.a.kamble at intel.com
Wed Mar 14 09:28:14 UTC 2018
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
>>> + 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.
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.
>> As it's not a new issue, please follow up with another patch and we'll
>> apply this in the meantime.
More information about the Intel-gfx