374ef13...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/huc: define HuC FW version for MTL
Follow the same logic as DG2, so just a meu binary with no version number.
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
4030d21...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/mtl/huc: Use the media gt for the HuC getparam
On MTL, for obvious reasons, HuC is only available on the media tile.
We already disable SW support for HuC on the root gt due to the
absence of VCS engines, but we also need to update the getparam to point
to the HuC struct in the media GT.
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: John Harrison <email address hidden>
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
e19f8a8...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/mtl/huc: auth HuC via GSC
The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth function is also updated to handle both authentication
types.
v2: check that the GuC auth for clear media has completed before
proceding with the full auth
v3: use a define for the object size (Alan)
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Reviewed-by: Alan Previn <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
3ede82b...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with
GSC-enabled binaries being considered fully authenticated only after
the GSC auth step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
v5: drop references to meu and esclamation mark in huc_auth print (John)
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Cc: John Harrison <email address hidden>
Reviewed-by: Alan Previn <email address hidden> #v2
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
77c944d...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v3: split check for GSC access, better comments (John)
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Cc: John Harrison <email address hidden>
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
cc5c191...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/huc: Parse the GSC-enabled HuC binary
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
v4: fix log for real (John)
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Cc: John Harrison <email address hidden>
Reviewed-by: Alan Previn <email address hidden> #v2
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
442508d...
by
Daniele Ceraolo Spurio <email address hidden>
drm/i915/uc: perma-pin firmwares
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Since the vma is now valid for a long time and not just for the quick
pin-load-unpin dance, the name "dummy" is no longer appropriare and has
been replaced with vma_res. All the functions have also been updated to
operate on vma_res for consistency.
Given that we pin the vma behind the allocator's back (which is ok
because we do the pinning in an area that was previously reserved for
thus purpose), we do need to explicitly re-pin on resume because the
automated helper won't cover us.
v2: better comments and commit message, s/dummy/vma_res/
Signed-off-by: Daniele Ceraolo Spurio <email address hidden>
Cc: Alan Previn <email address hidden>
Cc: John Harrison <email address hidden>
Reviewed-by: John Harrison <email address hidden>
Signed-off-by: You-Sheng Yang <email address hidden>
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.
In case when only two or less transmit lanes are owned such as MFD
(DP-alt with x2 lanes) we need to reset only one data lane (lane0).
With only x2 lanes we don't need to poll for the phy current
status on both data lanes since only the owned data lane will respond.
v2: Find better naming for lanes and revise the commit message (Luca)
b29a20f...
by
=?utf-8?q?Jouni_H=C3=B6gander?= <email address hidden>
drm/i915: Use 18 fast wake AUX sync len
HW default for wake sync pulses is 18. 10 precharge and 8 preamble. There
is no reason to change this especially as it is causing problems with
certain eDP panels.
