- Add a new start parameter in trim function to specify exact
address from where to start the trimming. This would help us
in situations like if drivers would like to do address alignment
for specific requirements.
- Add a new flag DRM_BUDDY_TRIM_DISABLE. Drivers can use this
flag to disable the allocator trimming part. This patch enables
the drivers control trimming and they can do it themselves
based on the application requirements.
v1:(Matthew)
- check new_start alignment with min chunk_size
- use range_overflows()
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wedge the entire device, not just GT which may have triggered the wedge.
To implement this, cleanup the layering so xe_device_declare_wedged()
calls into the lower layers (GT) to ensure entire device is wedged.
While we are here, also signal any pending GT TLB invalidations upon
wedging device.
Lastly, short circuit reset wait if device is wedged.
v2:
- Short circuit reset wait if device is wedged (Local testing)
Fixes: 8ed9aaae39 ("drm/xe: Force wedged state and block GT reset upon any GPU hang")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240716063902.1390130-1-matthew.brost@intel.com
(cherry picked from commit 7dbe8af13c)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Due to the current design of the BO and VRAM manager, any object
with XE_BO_FLAG_PINNED flag, which the PF driver uses during VF
LMEM provisionining, is created with the TTM_PL_FLAG_CONTIGUOUS
flag, which may cause VRAM fragmentation that prevents subsequent
allocations of larger objects, like fair VF LMEM provisioning.
To avoid such failures, round down fair VF LMEM provisioning size
to next power of two size, to compensate what xe_ttm_vram_mgr is
doing to achieve contiguous allocations.
Fixes: ac6598aed1 ("drm/xe/pf: Add support to configure SR-IOV VFs")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240711192320.1198-2-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 4c3fe5eae4)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
In Xe, the perf layer allows capture of HW counter streams. These HW
counters are generally performance related but don't have to be necessarily
so. Also, the name "perf" is a carryover from i915 and is not preferred.
Here we propose the name "observation" for this common layer which allows
capture of different types of these counter streams.
v2: Rename observability layer to observation layer (Lucas/Rodrigo)
v3: Rename sysctl file to "observation_paranoid" (Jose)
Fixes: 52c2e956dc ("drm/xe/perf/uapi: "Perf" layer to support multiple perf counter stream types")
Fixes: fe8929bdf8 ("drm/xe/perf/uapi: Add perf_stream_paranoid sysctl")
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240703164801.2561423-1-ashutosh.dixit@intel.com
(cherry picked from commit 8169b2097d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Our debugfs allows to view and change VFs' provisioning configs.
If we attempt to experiment with VFs provisioning before enabling
them, this early config will affect fair provisioning calculations,
and will also be overwritten, which is undesirable behavior.
To improve this, check if the VFs configs are empty (unprovisioned)
before starting the fair provisioning procedure.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240701102738.934-2-michal.wajdeczko@intel.com
A couple copy/paste mistakes in the code that selects steering targets
for OADDRM and INSTANCE0 unintentionally clobbered the steering target
for DSS ranges in some cases.
The OADDRM/INSTANCE0 values were also not assigned as intended, although
that mistake wound up being harmless since the desired values for those
specific ranges were '0' which the kzalloc of the GT structure should
have already taken care of implicitly.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240626210536.1620176-2-matthew.d.roper@intel.com
It's not very obvious what the difference is between the 'size' and
'n_entries' fields of the MOCS structure. Rename both fields slightly
and add some comments explaining that one is the documentation-defined
table size, while the other is the number of entries that can be
programmed into the hardware (and the documented table size can
potentially be smaller than the number of hardware entries).
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240627203741.2042752-4-matthew.d.roper@intel.com
Rely more heavily on assertions to describe the MOCS programming
invariants. CI checks these assertions and will ensure no violations
sneak in due to programmer error, so we can remove some of the redundant
WARN and silent return checks from non-debug builds.
Also tweak/augment some of the existing assertions: there's no reason
we'd ever want a platform not to have a MOCS 'ops' structure hooked up
so ensure info->ops is non-NULL. Likewise, we should never have a case
where the bspec-defined MOCS setting table is larger than the number of
MOCS registers exposed by the hardware, so add an extra assert on those
sizes as well.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240627203741.2042752-3-matthew.d.roper@intel.com
Per client engine utilization uses RING_TIMESTAMP to return
drm-total-cycles to the user. Current code uses XE_FW_GT to read this
register on the first available engine in a GT. When testing on DG2, it
is observed that this value is 0 when running test on some engines. To
resolve that, get the hwe domain specific FW for reading the engine
timestamp.
v2:
- update commit message
- use domain specific FW (Matt)
v3:
- Drop check for hwe in the helper (Matt, Michal)
v4:
- checkpatch fixes
v5: Rebase
Fixes: 188ced1e0f ("drm/xe/client: Print runtime to fdinfo")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240627235105.2631135-1-umesh.nerlige.ramappa@intel.com
The cleanup is done by devres in irq_uninstall.
Commit bbc9651fe9 ("drm/xe/irq: move irq_uninstall over to devm")
resolved the ordering issue where irq_uninstall (registered with drmm)
was called after pci_free_irq_vectors (registered with devm upon calling
pci_alloc_irq_vectors). This happened because drmm action list is
registered with devm very early in the init flow - before
pci_alloc_irq_vectors.
Now that irq_uninstall is registered with devm, it will be called before
pci_free_irq_vectors and we can remove xe_irq_shutdown.
Signed-off-by: Ilia Levi <illevi@habana.ai>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606124705.822451-1-illevi@habana.ai
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This WA requires us to limit media GT frequency requests to a certain
cap value during driver load. Freq limits are restored after load
completes, so perf will not be affected during normal operations.
During normal driver operation, this WA requires dummy writes to media
offset 0x380D8C after every ~63 GGTT writes. This will ensure completion
of the LMEM writes originating from Gunit.
During driver unload(before FLR), the WA requires that we set requested
frequency to the cap value again.
v3: Do not use WA number in function name. Call WA wrapper from xe_device.
Rename some variables, check for locks in the correct function (Rodrigo).
Ensure reset path is also covered for this WA.
v4: Fix BAT failure
v5: Add a function pointer for ggtt_ops (Michal W)
v6: Fix name collision and use static function (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240620224928.3986377-2-vinay.belgaumkar@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Need to sync some header include that propagated through
drm-intel-next.
v2: After some changes in drm/drm-next
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
For fbdev we (temporarily) introduce intel_fbdev_min_alignment()
that simply queries the alignment from the primary plane of
the first crtc.
TODO: someone will need to fix xe's alignment handling
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240612204712.31404-4-ville.syrjala@linux.intel.com
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Use the suspend encoders helper which is also used by the i915 driver.
This fixes an issue in the xe driver where the encoder
suspend_complete() hook is not called and was an overlook when this hook
was added in commit b61fad5f7e ("drm/i915/tc: Call TypeC port
flush_work/cleanup without modeset locks held") for i915, but not added
to the xe driver (which was still in a separate source tree at the above
point).
v2: Fix checkpatch warn in commit log. (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240618125255.4080303-3-imre.deak@intel.com
