Michal Wajdeczko [Tue, 26 Mar 2024 19:15:18 +0000 (20:15 +0100)]
drm/xe/pf: Add minimal support for VF_STATE_NOTIFY events
GuC will use VF_STATE_NOTIFY events to notify the PF about changes
of the VF state, in particular when a VF FLR was requested. Add
very minimal support for such events to avoid reporting errors due
to unexpected G2H. We will improve handling of these messages later.
While around also add few basic functions to control the VF state
(pause, resume, stop) as we will also exercise them soon.
Michal Wajdeczko [Tue, 26 Mar 2024 19:15:17 +0000 (20:15 +0100)]
drm/xe/guc: Add VF_STATE_NOTIFY and VF_CONTROL to ABI
In upcoming patches the PF driver will add support to handle the
GUC2PF_VF_STATE_NOTIFY events and to send PF2GUC_VF_CONTROL request
messages. Add necessary definitions to our GuC firmware ABI header.
Michal Wajdeczko [Wed, 27 Mar 2024 18:27:38 +0000 (19:27 +0100)]
drm/xe: Separate pure MMIO init from VRAM checkout
We can setup root tile registers mapping at the same time as we
do early mapping of the entire MMIO BAR and keep mandatory VRAM
checkout as a separate step. This will allow us to perform SR-IOV
VF mode detection between those two steps using regular MMIO regs
access functions.
Thomas Hellström [Wed, 27 Mar 2024 09:11:36 +0000 (10:11 +0100)]
drm/xe: Move vma rebinding to the drm_exec locking loop
Rebinding might allocate page-table bos, causing evictions.
To support blocking locking during these evictions,
perform the rebinding in the drm_exec locking loop.
Also Reserve fence slots where actually needed rather than trying to
predict how many fence slots will be needed over a complete
wound-wait transaction.
v2:
- Remove a leftover call to xe_vm_rebind() (Matt Brost)
- Add a helper function xe_vm_validate_rebind() (Matt Brost)
v3:
- Add comments and squash with previous patch (Matt Brost)
Fixes: 24f947d58fe5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted objects") Fixes: 29f424eb8702 ("drm/xe/exec: move fence reservation") Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327091136.3271-5-thomas.hellstrom@linux.intel.com
Thomas Hellström [Wed, 27 Mar 2024 09:11:34 +0000 (10:11 +0100)]
drm/xe: Rework rebinding
Instead of handling the vm's rebind fence separately,
which is error prone if they are not strictly ordered,
attach rebind fences as kernel fences to the vm's resv.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327091136.3271-3-thomas.hellstrom@linux.intel.com
Thomas Hellström [Wed, 27 Mar 2024 09:11:33 +0000 (10:11 +0100)]
drm/xe: Use ring ops TLB invalidation for rebinds
For each rebind we insert a GuC TLB invalidation and add a
corresponding unordered TLB invalidation fence. This might
add a huge number of TLB invalidation fences to wait for so
rather than doing that, defer the TLB invalidation to the
next ring ops for each affected exec queue. Since the TLB
is invalidated on exec_queue switch, we need to invalidate
once for each affected exec_queue.
v2:
- Simplify if-statements around the tlb_flush_seqno.
(Matthew Brost)
- Add some comments and asserts.
Michal Wajdeczko [Wed, 13 Mar 2024 22:11:10 +0000 (23:11 +0100)]
drm/xe/guc: Introduce GuC context ID Manager
While we are already managing GuC IDs directly in GuC submission
code, using bitmap() for MLRC and ida() for SLRC, this code can't
be easily extended to meet additional requirements for SR-IOV use
cases, like limited number of IDs available on VFs, or ID range
reservation for provisioning VFs by the PF.
Add a separate component for managing GuC IDs, that will replace
existing ID management. Start with bitmap() based implementation
that could be optimized later based on perf data.
Nirmoy Das [Thu, 21 Mar 2024 16:11:42 +0000 (17:11 +0100)]
drm/xe: Create a helper function to init job's user fence
Refactor xe_sync_entry_signal so it doesn't have to
modify xe_sched_job struct instead create a new helper function
to set user fence values for a job.
v2: Move the sync type check to xe_sched_job_init_user_fence(Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240321161142.4954-1-nirmoy.das@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Vinay Belgaumkar [Mon, 25 Mar 2024 23:56:02 +0000 (16:56 -0700)]
drm/xe/guc: Remove explicit shutdown of SLPC
SLPC shutdown is called in reset and suspend paths. In the reset
path, it is possible that the H2G call gets lost as GuC is in the
process of being reset. There is no value in stopping SLPC when
it will happen anyways.
In the suspend path, we disable communication with GuC, so there
is no need to explicitly shutdown SLPC.
Lucas De Marchi [Fri, 22 Mar 2024 14:48:43 +0000 (07:48 -0700)]
drm/xe: Fix END redefinition
mips declares an END macro in its headers so it can't be used without
namespace in a driver like xe.
Instead of coming up with a longer name, just remove the macro and
replace its use with 0 since it's still clear what that means:
set_offsets() was already using that implicitly when checking the data
variable.
drm/xe/guc: Check error code when initializing the CT mutex
The initialization via drmm_mutex_init can fail, so we need to check the
return code and escalate the failure.
The mutex initialization has been moved after all the other init steps
that can't fail, so we're always guaranteed to have those done and don't
have to check in the cleanup code.
drm/xe: Use USEC_PER_MSEC rather than the hard coding
Use USEC_PER_MSEC rather than the hard coded value of 1000.
Static analyzer Reported "casting either timeout_ms or
1000U to type u64" to avoid overflow-before-widen.
Using USEC_PER_MSEC seems better and will help with static analyzer
report cleanup.
Matthew Auld [Wed, 20 Mar 2024 11:27:32 +0000 (11:27 +0000)]
drm/xe/bb: assert width in xe_bb_create_migration_job()
The q->width should always be exactly one here for migration queue/vm.
The width will anyway be overridden later since we need to emit two
jumps for special migration jobs. Enforce that here to ensure caller is
not doing something strange. While here also convert to the helper to
determine if the queue is migration based.
Matthew Auld [Wed, 20 Mar 2024 11:27:31 +0000 (11:27 +0000)]
drm/xe/bb: assert width in xe_bb_create_job()
The queue width will determine the number of batch buffer emitted into
the ring. In the case of xe_bb_create_job() we pass exactly one batch
address, therefore add an assert for the width to make sure we don't go
out of bounds. While here also convert to the helper to determine if the
queue is migration based.
drm/xe/uc: Use u64 for offsets for which we use upper_32_bits()
The GGTT is currently a 32 bit address space, but the HW and GuC
support 48b addresses in GGTT-related operations, both to keep the
interface/HW paths common between PPGTT and GGTT and to allow for
future increase of the GGTT size.
This leaves us having to program a 64b field with a 32b offset, which
currently we're in some cases doing this by using an upper_32_bits()
call on a 32b variable, which doesn't make any sense. To do this cleanly
we have 2 options:
1 - Set the upper 32 bits directly to zero.
2 - Use 64b variables for the offset and keep programming the whole thing,
so we're ready if we ever have bigger offsets.
This patch goes with option #2 and switches the related variables to u64.
A force_wake_get failure means that the HW might not be awake for the
access we're doing; this can lead to an immediate error or it can be a
more subtle problem (e.g. a register read might return an incorrect
value that is still valid, leading the driver to make a wrong choice
instead of flagging an error).
We avoid an error from the force_wake function because callers might
handle or tolerate the error, but this only works if all callers
are checking the error code. The majority already do, but a few are not.
These are mainly falling into 3 categories, which are each handled
differently:
1) error capture: in this case we want to continue the capture, but we
log an info message in dmesg to notify the user that the capture
might have incorrect data.
2) ioctl: in this case we return a -EIO error to userspace
3) unabortable actions: these are scenarios where we can't simply abort
and retry and so it's better to just try it anyway because there is a
chance the HW is awake even with the failure. In this case we throw a
warning so we know there was a forcewake problem if something fails
down the line.
Maarten Lankhorst [Wed, 6 Mar 2024 05:20:02 +0000 (21:20 -0800)]
drm/xe: Move xe_ggtt_invalidate out from ggtt->lock
Considering the caller of the GGTT functions should keep the
backing storage alive before the function completes, it's not
necessary to invalidate with the GGTT lock held. This just adds
latency for every user of the GGTT.
Matthew Brost [Wed, 6 Mar 2024 05:20:01 +0000 (21:20 -0800)]
drm/xe: Add XE_BO_GGTT_INVALIDATE flag
Add XE_BO_GGTT_INVALIDATE flag which indicates the GGTT should be
invalidated when a BO is added / removed from the GGTT. This is
typically set when a BO is used by the GuC as the GuC has GGTT TLBs.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
[mlankhorst: Small fix to only inherit GGTT_INVALIDATE from src bo]
[mlankhorst: Remove _BIT from name] Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306052002.311196-4-matthew.brost@intel.com
Matthew Brost [Wed, 6 Mar 2024 05:20:00 +0000 (21:20 -0800)]
drm/xe: Drop ggtt invalidate from display code
Only buffers mapped in the GGTT used by the GuC require an invalidation.
Display buffers do not require an invalidation. Delete the invalidatio
from display code and make invalidation a static function in xe_ggtt.c.
Niranjana Vishwanathapura [Tue, 19 Mar 2024 17:59:46 +0000 (10:59 -0700)]
drm/xe: Streamline exec queue freeing path
Ensure exec queue freeing happens at one place, that is in
__xe_exec_queue_free(). It releases q->vm reference also. Set
q->vm before handling extensions as they can potentially reference it.
Niranjana Vishwanathapura [Tue, 19 Mar 2024 18:41:53 +0000 (11:41 -0700)]
drm/xe: Separate out sched/deregister_done handling
Abstract out the core part of sched_done and deregister_done handlers
to separate functions to decouple them from any protocol error handling
part and make them more readable.
Supporting older GuC versions comes with baggage, both on the coding
side (due to interfaces only being available from a certain version
onwards) and on the testing side (due to having to make sure the driver
works as expected with older GuCs).
Since all of our Xe platform are still under force probe, we haven't
committed to support any specific GuC version and we therefore don't
need to support the older once, which means that we can force a bottom
limit to what GuC we accept. This allows us to remove any conditional
statements based on older GuC versions and also to approach newer
additions knowing that we'll never attempt to load something older
than our minimum requirement.
As an initial value, the minimum expected version is set to 70.19,
which is the version currently in the firmware table, but the
expectation is that this will be bumbed every time we update the
table, until we remove the force probe.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240304162616.824884-1-daniele.ceraolospurio@intel.com
Matthew Auld [Thu, 14 Mar 2024 16:49:06 +0000 (16:49 +0000)]
drm/xe/display: mark DPT with XE_BO_PAGETABLE
Otherwise in the case where we use normal system memory, the CPU access
will always be cached, like when filling the DPT PTEs, which is likely
not what we want since HW access could be incoherent on platforms like
LNL. Marking as XE_BO_PAGETABLE will force wc/uc underneath on such
platforms.
Matthew Auld [Mon, 18 Mar 2024 18:05:35 +0000 (18:05 +0000)]
drm/xe/device: fix XE_MAX_TILES_PER_DEVICE check
Here XE_MAX_TILES_PER_DEVICE is the gt array size, therefore the gt
index should always be less than.
v2 (Lucas):
- Add fixes tag.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240318180532.57522-6-matthew.auld@intel.com
Michal Wajdeczko [Wed, 13 Mar 2024 10:41:31 +0000 (11:41 +0100)]
drm/xe/pf: Request 64K aligned allocations for LMTT PD
The LMTT Page Directory, as well as the directory entries, must be
aligned on a 64KB boundary in VRAM. Use explicit alignment flag to
match hardware requirement.
Michal Wajdeczko [Wed, 13 Mar 2024 10:41:30 +0000 (11:41 +0100)]
drm/xe: Allow VRAM BO allocations aligned to 64K
While today we are getting VRAM allocations aligned to 64K as the
XE_VRAM_FLAGS_NEED64K flag could be set, we shouldn't only rely on
that flag and we should also allow caller to specify required 64K
alignment explicitly. Define new XE_BO_NEEDS_64K flag for that.
Michal Wajdeczko [Thu, 14 Mar 2024 17:31:30 +0000 (18:31 +0100)]
drm/xe: Make xe_mmio_read|write() functions non-inline
Shortly we will updating xe_mmio_read|write() functions with SR-IOV
specific features making those functions less suitable for inline.
Convert now those functions into regular ones, lowering driver
footprint, according to scripts/bloat-o-meter, by 6%
add/remove: 18/18 grow/shrink: 31/603 up/down: 2719/-79663 (-76944)
Function old new delta
Total: Before=1276633, After=1199689, chg -6.03%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=48990, After=48990, chg +0.00%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
RO Data old new delta
Total: Before=115680, After=115680, chg +0.00%
Michal Wajdeczko [Thu, 14 Mar 2024 17:31:26 +0000 (18:31 +0100)]
drm/xe: Define XE_REG_OPTION_VF
We will tag registers that SR-IOV Virtual Functions can access.
This will help us catch any invalid usage and/or provide custom
replacement if available.
Matt Roper [Thu, 14 Mar 2024 19:58:27 +0000 (12:58 -0700)]
drm/xe/mocs: Clarify which GT is being operated on
Switch the MOCS-related debug messages to use a GT-specific logging
function and add ID/type output to the beginning of the MOCS kunit test
to assist with debug when problems arise.
Matt Roper [Thu, 14 Mar 2024 19:58:26 +0000 (12:58 -0700)]
drm/xe/mocs: Determine MCR separately for primary/media GT in kunit test
Although MOCS registers became multicast in graphics version 12.50 on
the primary GT, this transition did not happen until version 20 on the
media GT. Considering each GT independently is mostly important for
MTL/ARL where the Xe_LPM+ IP has non-MCR MOCS registers, even though
Xe_LPG IP has MCR registers.
Starting on Xe2, the GSCCS engine reset is a 2-step process. When the
driver or the GuC hits the GDRST register, the CS is immediately reset
and a success is reported, but the GSC shim continues its reset in the
background. While the shim reset is ongoing, the CS is able to accept
new context submission, but any commands that require the shim will
be stalled until the reset is completed. This means that we can keep
submitting to the GSCCS as long as we make sure that the preemption
timeout is big enough to cover any delay introduced by the reset; since
the GSC preempt timeout is not tunable at runtime, we only need to check
that the value set in kconfig is big enough (and increase it if it
isn't).
When the shim reset completes, a specific CS interrupt is triggered,
in response to which we need to check the GSCI_TIMER_STATUS register
to see if the reset was successful or not.
Note that the GSCI_TIMER_STATUS register is not power save/restored,
so it gets reset on MC6 entry. However, a reset failure stops MC6,
so in that scenario we're always guaranteed to find the correct value.
Since we can't check the register within interrupt context, the
existing GSC worker has been updated to handle it.
The expected action to take on ER failure is to trigger a driver FLR,
but we still don't support that, so for now we just print an error. A
comment has been added to the code to keep track of the FLR requirement.
v2: Add a check for the initial timeout value (Alan)
Matthew Auld [Thu, 14 Mar 2024 12:15:55 +0000 (12:15 +0000)]
drm/xe/guc_submit: use jiffies for job timeout
drm_sched_init() expects jiffies for the timeout, but here we are
passing the timeout in ms. Convert to jiffies instead.
Fixes: eef55700f302 ("drm/xe: Add sysfs for default engine scheduler properties") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240314121554.223229-2-matthew.auld@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
José Roberto de Souza [Wed, 13 Mar 2024 17:13:18 +0000 (10:13 -0700)]
drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC
Doing a XE_EXEC with num_batch_buffer == 0 makes signals passed as
argument to be signaled when the last real XE_EXEC is completed.
But to do that it was first pinning all VMAs in drm_gpuvm_exec_lock(),
this patch remove this pinning as it is not required.
This change also help Mesa implementing memory over-commiting recovery
as it needs to unbind not needed VMAs when the whole VM can't fit
in GPU memory but it can only do the unbiding when the last XE_EXEC
is completed.
So with this change Mesa can get the signal it want without getting
out-of-memory errors.
Fixes: eb9702ad2986 ("drm/xe: Allow num_batch_buffer / num_binds == 0 in IOCTLs") Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Co-developed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240313171318.121066-1-jose.souza@intel.com
Matthew Brost [Wed, 13 Mar 2024 18:44:30 +0000 (11:44 -0700)]
drm/xe: Use xe_assert in xe_device_assert_mem_access
The implementation of xe_device_assert_mem_access has a non-zero cost.
Use xe_assert rather than XE_WARN_ON so it will compile out in non-debug
kernel builds (Kconfig CONFIG_DRM_XE_DEBUG=n).
Matthew Brost [Tue, 12 Mar 2024 18:39:07 +0000 (11:39 -0700)]
drm/xe: Invalidate userptr VMA on page pin fault
Rather than return an error to the user or ban the VM when userptr VMA
page pin fails with -EFAULT, invalidate VMA mappings. This supports the
UMD use case of freeing userptr while still having bindings.
Now that non-faulting VMs can invalidate VMAs, drop the usm prefix for
the tile_invalidated member.
v2:
- Fix build error (CI)
v3:
- Don't invalidate VMA if in fault mode, rather kill VM (Thomas)
- Update commit message with tile_invalidated name chagne (Thomas)
- Wait VM bookkeep slots with VM resv lock (Thomas)
v4:
- Move list_del_init(&userptr.repin_link) after error check (Thomas)
- Assert not in fault mode (Matthew)
Matt Roper [Tue, 12 Mar 2024 21:12:25 +0000 (14:12 -0700)]
drm/xe/uapi: Add IP version and stepping to GT list query
For modern platforms (MTL and later), both kernel and userspace drivers
are expected to apply GT programming and workarounds based on the IP
version and stepping self-reported by the GT hardware via the GMD_ID
registers. Since userspace drivers can't access these registers
directly, pass along the version and stepping information via the GT
list query. Note that the new query fields will remain 0's when running
on pre-GMD_ID platforms. Userspace is expected to continue using PCI
devid / revid on those older platforms.
Although the hardware also has a GMD_ID register for display
version/stepping, that value is intentionally *not* included anywhere in
the Xe uapi. Display userspace should be using platform-agnostic APIs
and auto-detecting platform capabilities rather than matching specific
IP versions.
Suraj Kandpal [Fri, 8 Mar 2024 15:49:40 +0000 (21:19 +0530)]
drm/xe/hdcp: Fix condition for hdcp gsc cs requirement
Add condition for check of hdcp gsc cs requirement rather than
assuming gsc cs to always be required when xe is loaded. It is not
required for display version < 14
--v2
-Use display version in commit message [Lucas]
With the current state GUC_WA_RCS_REGS_IN_CCS_REGS_LIST could in theory
be removed since there is no render register being added to the list of
compute WAs. However the real issue is that 18020744125 is incomplete
and not setting the RING_HWSTAM on render as it should.
Writing this in RTP is a little more tricky as we want to write to
another's engine base when the match happens: first compute engine and
no render present. So use RING_HWSTAM(RENDER_RING_BASE) instead of the
usual XE_RTP_ACTION_FLAG(ENGINE_BASE).
Suraj Kandpal [Wed, 6 Mar 2024 02:42:48 +0000 (08:12 +0530)]
drm/xe/hdcp: Enable HDCP for XE
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
--v2
-add kfree at appropriate place [Daniele]
-remove useless define [Daniele]
-move host session logic to xe_gsc_submit.c [Daniele]
-call xe_gsc_check_and_update_pending directly in an if condition
[Daniele]
-use xe_device instead of drm_i915_private [Daniele]
--v3
-use xe prefix for newly exposed function [Daniele]
-remove client specific defines from intel_gsc_mtl_header [Daniele]
-add missing kfree() [Daniele]
-have NULL check for hdcp_message in finish function [Daniele]
-dont have too many variable declarations in the same line [Daniele]
--v4
-don't point the hdcp_message structure in xe_device to anything
until it properly gets initialized [Daniele]
Suraj Kandpal [Wed, 6 Mar 2024 02:42:46 +0000 (08:12 +0530)]
drm/xe/hdcp: Use xe_device struct
Use xe_device struct instead of drm_i915_private so as to not
cause confusion and comply with Xe standards as drm_i915_private is
xe_device under the hood.
Matthew Brost [Thu, 29 Feb 2024 19:45:20 +0000 (11:45 -0800)]
drm/xe: Do not grab forcewakes when issuing GGTT TLB invalidation via GuC
Forcewakes are not required for communication with the GuC via CTB
as it is a memory based interfaced. Acquring forcewakes takes
considerable time. With that, do not grab a forcewake when issuing a
GGTT TLB invalidation via the GuC.
Matt Roper [Wed, 6 Mar 2024 00:40:49 +0000 (16:40 -0800)]
drm/xe/arl: Add Arrow Lake H support
ARL-H uses the same media and display IP as MTL, and a version 12.74
graphics IP (referred to as Xe_LPG+). From a driver point of view, we
should be able to just treat the whole platform as MTL and rely on
GRAPHICS_VERx100 checks to handle any spots where ARL's Xe_LPG+ needs
different handling from MTL's Xe_LPG (i.e., workarounds).
v2: Resolve conflict and Reorder PCI ids in sorted order
v3: Append signed-off-by commiter to this commit
Matt Roper [Thu, 29 Feb 2024 07:08:05 +0000 (12:38 +0530)]
drm/xe/xelpg: Extend some workarounds to graphics version 12.74
A handful of Xe_LPG workarounds are also relevant to graphics version
12.74 as well. Extend the graphics version range for these workarounds
accordingly.
Matt Roper [Thu, 29 Feb 2024 07:08:04 +0000 (12:38 +0530)]
drm/xe/xelpg: Recognize graphics version 12.74 as Xe_LPG
Graphics version 12.74 (which is technically called "Xe_LPG+") should be
handled the same as versions Xe_LPG 12.70/12.71 by the KMD. Only the
workaround lists (handled in the next patch) will be a bit different.
projects / users / hch / configfs.git / log