[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

[Arkadiusz Hiler]

On Thu, Dec 22, 2016 at 03:12:19PM -0800, Anusha Srivatsa wrote:
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
> 
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of them.
> 
> v2: rebased on-top of drm-intel-nightly.
>     removed if(HAS_GUC()) before the guc call. (D.Gordon)
>     update huc_version number of format.
> v3: rebased to drm-intel-nightly, changed the file name format to
>     match the one in the huc package.
>     Changed dev->dev_private to to_i915()
> v4: moved function back to where it was.
>     change wait_for_atomic to wait_for.
> v5: rebased + comment changes.
> v7: rebased.
> v8: rebased.
> v9: rebased. Changed the year in the copyright message to reflect
> the right year.Correct the comments,remove the unwanted WARN message,
> replace drm_gem_object_unreference() with i915_gem_object_put().Make the
> prototypes in intel_huc.h non-extern.
> v10: rebased. Update the file construction done by HuC. It is similar to
> GuC.Adopted the approach used in-
> https://patchwork.freedesktop.org/patch/104355/ <Tvrtko Ursulin>
> v11: Fix warnings remove old declaration
> v12: Change dev to dev_priv in macro definition.
> Corrected comments.
> v13: rebased.
> v14: rebased on top of drm-tip
> v15: rebased. Updated functions intel_huc_load(),intel_huc_init() and
> intel_uc_fw_fetch() to accept dev_priv instead of dev. Moved contents
> of intel_huc.h to intel_uc.h
> v16: change SKL_FW_ to SKL_HUC_FW_. Add intel_ prefix to guc_wopcm_size().
> Remove unwanted checks in intel_uc.h. Rename huc_fw in struct intel_huc to
> simply fw to avoid redundency.
> v17: rebased.
> 
> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Tested-by: Xiang Haihao <haihao.xiang at intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.srivatsa at intel.com>
> Signed-off-by: Alex Dai <yu.dai at intel.com>
> Signed-off-by: Peter Antoine <peter.antoine at intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>

-- 
Cheers,
Arek