Matthew Auld [Wed, 22 May 2024 10:21:58 +0000 (11:21 +0100)]
drm/xe: reset mmio mappings with devm
Set our various mmio mappings to NULL. This should make it easier to
catch something rogue trying to mess with mmio after device removal. For
example, we might unmap everything and then start hitting some mmio
address which has already been unmamped by us and then remapped by
something else, causing all kinds of carnage.
Matthew Auld [Wed, 22 May 2024 10:21:57 +0000 (11:21 +0100)]
drm/xe/mmio: move mmio_fini over to devm
Not valid to touch mmio once the device is removed, so make sure we
unmap on removal and not just when driver instance goes away. Also set
the mmio pointers to NULL to hopefully catch such issues more easily.
Matthew Auld [Wed, 22 May 2024 10:21:54 +0000 (11:21 +0100)]
drm/xe/coredump: move over to devm
Here we are using drmm to ensure we release the coredump when unloading
the module, however the coredump is very much tied to the struct device
underneath. We can see this when we hotunplug the device, for which we
have already got a coredump attached. In such a case the coredump still
remains and adding another is not possible. However we still register
the release action via xe_driver_devcoredump_fini(), so in effect two or
more releases for one dump. The other consideration is that the
coredump state is embedded in the xe_driver instance, so technically
once the drmm release action fires we might free the coredumpe state
from a different driver instance, assuming we have two release actions
and they can race. Rather use devm here to remove the coredump when the
device is released.
Matthew Auld [Wed, 22 May 2024 10:21:49 +0000 (11:21 +0100)]
drm/xe/guc_pc: move pc_fini to devm
Here we are touching the HW/GuC and presumably this should happen when
the device is removed. Currently if you hotunplug the device this is
skipped if there is already open driver instance.
Matthew Auld [Wed, 22 May 2024 10:21:47 +0000 (11:21 +0100)]
drm/xe/guc: move guc_fini over to devm
Make sure to actually call this when the device is removed. Currently we
only trigger it when the driver instance goes away, but that doesn't
work too well with hotunplug, since device can be removed and re-probed
with a new driver instance, where the guc_fini() is called too late.
Move the fini over to devm to ensure this is called when device is
removed.
Matthew Auld [Wed, 22 May 2024 10:21:46 +0000 (11:21 +0100)]
drm/xe/ggtt: use drm_dev_enter to mark device section
Device can be hotunplugged before we start destroying gem objects. In
such a case don't touch the GGTT entries, trigger any invalidations or
mess around with rpm. This should already be taken care of when
removing the device, we just need to take care of dealing with the
software state, like removing the mm node.
v2: (Andrzej)
- Avoid some duplication by tracking the bound status and checking
that instead.
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1717 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240522102143.128069-21-matthew.auld@intel.com
Matthew Auld [Wed, 22 May 2024 10:21:45 +0000 (11:21 +0100)]
drm/xe: covert sysfs over to devm
Hotunplugging the device seems to result in stuff like:
kobject_add_internal failed for tile0 with -EEXIST, don't try to
register things with the same name in the same directory.
We only remove the sysfs as part of drmm, however that is tied to the
lifetime of the driver instance and not the device underneath. Attempt
to fix by using devm for all of the remaining sysfs stuff related to the
device.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1667 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1432 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240522102143.128069-20-matthew.auld@intel.com
Matthew Auld [Wed, 22 May 2024 10:21:44 +0000 (11:21 +0100)]
drm/xe/pci: remove broken driver_release
This is quite broken since we are nuking the pdev link to the private
driver struct, but note here that driver_release is called when the
drm_device is released (poor mans drmm), which can be long after the
device has been removed. So here what we are actually doing is nuking
the pdev link for what is potentially bound to a different drm_device.
If that happens before our pci remove callback is triggered (for the new
drm_device) we silently exit and skip some important cleanup steps,
resulting in hilarity.
There should be no reason to implement driver_release, when we already
have nicer stuff like drmm, so just remove completely. The actual pdev
link is already nuked when removing the device.
Michal Wajdeczko [Tue, 21 May 2024 09:25:18 +0000 (11:25 +0200)]
drm/xe/vf: Custom GuC initialization if VF
The GuC firmware is loaded and initialized by the PF driver. Make
sure VF drivers only perform permitted operations. For submission
initialization, use number of GuC context IDs from self config.
Michal Wajdeczko [Tue, 21 May 2024 09:25:17 +0000 (11:25 +0200)]
drm/xe/guc: Allow to initialize submission with limited set of IDs
While PF and native drivers may initialize submission code to use
all available GuC contexts IDs, the VF driver may only use limited
number of IDs. Update init function to accept number of context
IDs available for use.
Michal Wajdeczko [Mon, 20 May 2024 18:18:13 +0000 (20:18 +0200)]
drm/xe: Don't rely on indirect includes from xe_mmio.h
These compilation units use udelay() or some GT oriented printk
functions without explicitly including proper header files, and
relying on #includes from the xe_mmio.h instead. Fix that.
Nirmoy Das [Tue, 21 May 2024 10:36:23 +0000 (12:36 +0200)]
drm/xe: Add warn when level can not be zero.
At xe_pt_zap_ptes_entry() and xe_pt_stage_unbind_entry, the level cannot
be 0. Therefore, add an independent check for the level. Since the level
cannot be zero at this point, there is no need to check for `is_compact`,
so remove that instead.
The L3 bank mask is already generated and stored internally with
the rest of the GT topology. In user space, the compute runtime
now needs this information to be added to the device properties
therefore the topology mask query is extended to provide a new
mask which represents the L3 banks enabled on the GT.
The changes in the compute runtime are ready and approved, see
link below.
v2: Rewrite commit message and add a link to the compute
runtime PR (Francois Dugast)
Lucas De Marchi [Fri, 17 May 2024 20:43:10 +0000 (13:43 -0700)]
drm/xe/client: Print runtime to fdinfo
Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:
1) loop through all the exec queues for the current client and
accumulate the runtime, per engine class. CTX_TIMESTAMP is used for
that, being read from the context image.
2) Read a "GPU timestamp" that can be used for considering "how much GPU
time has passed" and that has the same unit/refclock as the one
recording the runtime. RING_TIMESTAMP is used for that via MMIO.
Since for all current platforms RING_TIMESTAMP follows the same
refclock, just read it once, using any first engine available.
This is exported to userspace as 2 numbers in fdinfo:
Since drm-cycles-<class> always starts at 0, it's also possible to know
if and engine was ever used by a client.
It's expected that userspace will read any 2 samples every few seconds.
Given the update frequency of the counters involved and that
CTX_TIMESTAMP is 32-bits, the counter for each exec_queue can wrap
around (assuming 100% utilization) after ~200s. The wraparound is not
perceived by userspace since it's just accumulated for all the
exec_queues in a 64-bit counter) but the measurement will not be
accurate if the samples are too far apart.
This could be mitigated by adding a workqueue to accumulate the counters
every so often, but it's additional complexity for something that is
done already by userspace every few seconds in tools like gputop (from
igt), htop, nvtop, etc, with none of them really defaulting to 1 sample
per minute or more.
Lucas De Marchi [Fri, 17 May 2024 20:43:08 +0000 (13:43 -0700)]
drm/xe: Cache data about user-visible engines
gt->info.engine_mask used to indicate the available engines, but that
is not always true anymore: some engines are reserved to kernel and some
may be exposed as a single engine (e.g. with ccs_mode).
Runtime changes only happen when no clients exist, so it's safe to cache
the list of engines in the gt and update that when it's needed. This
will help implementing per client engine utilization so this (mostly
constant) information doesn't need to be re-calculated on every query.
drm/xe: Add helper to accumulate exec queue runtime
Add a helper to accumulate per-client runtime of all its
exec queues. This is called every time a sched job is finished.
v2:
- Use guc_exec_queue_free_job() and execlist_job_free() to accumulate
runtime when job is finished since xe_sched_job_completed() is not a
notification that job finished.
- Stop trying to update runtime from xe_exec_queue_fini() - that is
redundant and may happen after xef is closed, leading to a
use-after-free
- Do not special case the first timestamp read: the default LRC sets
CTX_TIMESTAMP to zero, so even the first sample should be a valid
one.
- Handle the parallel submission case by multiplying the runtime by
width.
v3: Update comments
Lucas De Marchi [Fri, 17 May 2024 20:43:06 +0000 (13:43 -0700)]
drm/xe: Add helper to capture engine timestamp
Just like CTX_TIMESTAMP is used to calculate runtime, add a helper to
get the timestamp for the engine so it can be used to calculate the
"engine time" with the same unit as the runtime is recorded.
Lucas De Marchi [Fri, 17 May 2024 20:43:04 +0000 (13:43 -0700)]
drm/xe: Add XE_ENGINE_CLASS_OTHER to str conversion
XE_ENGINE_CLASS_OTHER was missing from the str conversion. Add it and
remove the default handling so it's protected by -Wswitch.
Currently the only user is xe_hw_engine_class_sysfs_init(), which
already skips XE_ENGINE_CLASS_OTHER, so there's no change in behavior.
José Roberto de Souza [Fri, 10 May 2024 15:01:08 +0000 (08:01 -0700)]
drm/xe: Replace RING_START_UDW by u64 RING_START
Other u64 registers are printed in a single line so RING_START
needs to follow that too.
As there is no upstream decoder tool parsing RING_START this will
not break any decoder application.
Michal Wajdeczko [Thu, 16 May 2024 11:05:46 +0000 (13:05 +0200)]
drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs
For debug purposes we might want to view actual VF configuration
(including GGTT range, LMEM size, number of GuC contexts IDs or
doorbells) and the negotiated ABI versions (with GuC and PF).
Michal Wajdeczko [Thu, 16 May 2024 11:05:44 +0000 (13:05 +0200)]
drm/xe/vf: Add support for VF to query its configuration
The VF driver doesn't know which GuC firmware was loaded by the PF
driver and must perform GuC ABI version handshake prior to sending
any other H2G actions to the GuC to submit workloads.
The VF driver also doesn't have access to the fuse registers and
must rely on the runtime info, which includes values of the fuse
registers, that the PF driver is exposing to the VFs.
Add functions to cover that functionality. We will use these
functions in upcoming patches.
Michal Wajdeczko [Thu, 16 May 2024 11:05:43 +0000 (13:05 +0200)]
drm/xe/guc: Add VF2GUC_QUERY_SINGLE_KLV to ABI
In upcoming patches we will add support to the VF driver to
read its configuration from the GuC using special H2G actions.
Add necessary definitions to our GuC firmware ABI header.
Michal Wajdeczko [Thu, 16 May 2024 11:05:42 +0000 (13:05 +0200)]
drm/xe/guc: Add VF2GUC_VF_RESET to ABI
The version negotiation between the VF driver and the GuC firmware
must start with explicit soft reset of the GuC state initiated by
the VF driver. Add VF2GUC action definitions to the ABI header.
Michal Wajdeczko [Thu, 16 May 2024 11:05:41 +0000 (13:05 +0200)]
drm/xe/guc: Add VF2GUC_MATCH_VERSION to ABI
In upcoming patches we will add a version negotiation between
the VF driver and the GuC firmware. Add necessary definitions
to our GuC firmware ABI header.
Michal Wajdeczko [Tue, 14 May 2024 19:00:14 +0000 (21:00 +0200)]
drm/xe/pf: Track adverse events notifications from GuC
When thresholds used to monitor VFs activities are configured,
then GuC may send GUC2PF_ADVERSE_EVENT messages informing the
PF driver about exceeded thresholds. Start handling such messages.
Michal Wajdeczko [Tue, 14 May 2024 19:00:13 +0000 (21:00 +0200)]
drm/xe/guc: Add GUC2PF_ADVERSE_EVENT to ABI
When thresholds used to monitor VFs activities are configured,
then GuC may send GUC2PF_ADVERSE_EVENT messages informing the
PF driver about exceeded thresholds. Add necessary definitions
to our GuC firmware ABI header.
Michal Wajdeczko [Tue, 14 May 2024 19:00:12 +0000 (21:00 +0200)]
drm/xe/pf: Allow configuration of VF thresholds over debugfs
Initial values of all thresholds used by the GuC to monitor VF's
activity is zero (disabled) and we need to explicitly configure
them per each VF. Expose additional attributes over debugfs.
Definitions of all attributes are generated so we will not need
to make any changes if new thresholds would be added to the set.
Michal Wajdeczko [Tue, 14 May 2024 19:00:11 +0000 (21:00 +0200)]
drm/xe/pf: Introduce functions to configure VF thresholds
The GuC firmware monitors VF's activity and notifies the PF driver
once any configured threshold related to such activity is exceeded.
Add functions to allow configuration of these thresholds per VF.
Michal Wajdeczko [Tue, 14 May 2024 19:00:09 +0000 (21:00 +0200)]
drm/xe/guc: Introduce GuC KLV thresholds set
The GuC firmware monitors VF's activity and notifies the PF driver
once any configured threshold related to such activity is exceeded.
The available thresholds are defined in the GuC ABI as part of the
GuC VF Configuration KLVs. Threshold configurations performed by
the PF driver and notifications sent by the GuC rely on the KLV keys,
which are not zero-based and might not guarantee continuity.
To simplify the driver code and eliminate the need to repeat very
similar code for each threshold, introduce the threshold set macro
that allows to generate required code based on unique threshold tag.
Michal Wajdeczko [Tue, 14 May 2024 19:00:08 +0000 (21:00 +0200)]
drm/xe/guc: Add more KLV helper macros
In upcoming patches we will want to generate some of the KLV keys
from other macros. Add MAKE_GUC_KLV_{KEY|LEN} macros for that and
make sure they will correctly expand provided TAG parameter. Also
fix PREP_GUC_KLV_TAG to also work correctly within other macros.
The PCI subsystem already exposes the "sriov_numvfs" attribute
that users can use to enable or disable SR-IOV VFs. Add custom
implementation of the .sriov_configure callback defined by the
pci_driver to perform additional steps, including fair VFs
provisioning with the resources, as required by our platforms.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> #v2 Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506184121.2615-1-michal.wajdeczko@intel.com
Michal Wajdeczko [Tue, 7 May 2024 16:57:57 +0000 (18:57 +0200)]
drm/xe/pf: Don't advertise support to enable VFs if not ready
Even if we have not enabled SR-IOV support using the platform
specific has_sriov flag, the hardware may still report SR-IOV
capability and the PCI layer may wrongly advertise driver support
to enable VFs. Explicitly reset the number of supported VFs to
zero to avoid confusion.
Applications may read the /sys/bus/pci/devices/.../sriov_totalvfs
prior to enabling VFs using the sriov_numvfs to check if such an
operation is possible.
Jonathan Cavitt [Fri, 10 May 2024 19:45:40 +0000 (12:45 -0700)]
drm/xe/xe_guc_submit: Declare reset if banned or killed or wedged
Add an additional condition to the reset_status guc_exec_queue_op that
returns true if the exec queue has been banned or killed or wedged. The
reset_status op is only used for exiting any xe_wait_user_fence_ioctl
that waits on an exec queue without timing out, so doing this will exit
the ioctl early in cases where the exec queue can no longer function,
such as after a GuC stop during a reset.
Jonathan Cavitt [Fri, 10 May 2024 19:45:39 +0000 (12:45 -0700)]
drm/xe/xe_guc_submit: Allow lr exec queues to be banned
LR queues currently don't get banned during a GT/GuC reset because they
lack a job. Though they don't have a job to detect the reset status of,
it's still possible to tell when they should be banned by looking at the
LRC: if the LRC head and tail don't match, then the exec queue should be
banned and cleaned up.
This also requires swapping the usage of xe_sched_tdr_queue_imm with
xe_guc_exec_queue_trigger_cleanup, as the former is specific to non-lr
exec queues.
Reorder the xe_sched_tdr_queue_imm and set_exec_queue_banned calls in
guc_exec_queue_stop. This prevents a possible race condition between
the two events in which it's possible for xe_sched_tdr_queue_imm to
wake the ufence waiter before the exec queue is banned, causing the
ufence waiter to miss the banned state.
Michal Wajdeczko [Fri, 10 May 2024 20:38:09 +0000 (22:38 +0200)]
drm/xe/uc: Reorder post hwconfig uC initialization step
We want to move the GuC submission initialization to the post
hwconfig step, but now this step is done too late as migration
initialization uses exec_queue that would crash due to a unset
exec_queue_ops. We can easily fix that by small function reorder.
Matthew Brost [Mon, 15 Apr 2024 19:04:53 +0000 (12:04 -0700)]
drm/xe: Only use reserved BCS instances for usm migrate exec queue
The GuC context scheduling queue is 2 entires deep, thus it is possible
for a migration job to be stuck behind a fault if migration exec queue
shares engines with user jobs. This can deadlock as the migrate exec
queue is required to service page faults. Avoid deadlock by only using
reserved BCS instances for usm migrate exec queue.
Fixes: a043fbab7af5 ("drm/xe/pvc: Use fast copy engines as migrate engine on PVC") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415190453.696553-2-matthew.brost@intel.com Reviewed-by: Brian Welty <brian.welty@intel.com>
drm/xe: Change pcode timeout to 50msec while polling again
Polling is initially attempted with timeout_base_ms enabled for
preemption, and if it exceeds this timeframe, another attempt is made
without preemption, allowing an additional 50 ms before timing out.
v2
- Rebase
v3
- Move warnings to separate patch (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Fixes: 7dc9b92dcfef ("drm/xe: Remove i915_utils dependency from xe_pcode.") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240508152216.3263109-2-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
xe_force_wake_init_gt() is a software-only initialization and doesn't
need to be called from xe_device_probe(). Move it to initialize
together with the gt.
Lucas De Marchi [Mon, 13 May 2024 21:37:49 +0000 (14:37 -0700)]
drm/xe: Move xe_gt_init_early() where it belongs
Early shall be early enough, stop doing other things with gt before it.
Now that xe_gt_init_early() doesn't need forcewake and doesn't depend on
the fake engine_mask initialization, move it where it belongs: it
doesn't need to be after hwconfig config anymore.
Lucas De Marchi [Mon, 13 May 2024 21:37:48 +0000 (14:37 -0700)]
drm/xe: Drop useless forcewake get/put
Forcewake used to be needed in xe_gt_init_early() since it was calling
xe_gt_topology_init(). That call was dropped in commit 4c47049d93b7
("drm/xe/guc: Fix missing topology init"), but the forcewake calls were
left behind. Remove them.
Michal Wajdeczko [Wed, 8 May 2024 17:10:00 +0000 (19:10 +0200)]
drm/xe: Rename few xe_args.h macros
To minimize the risk of future name collisions, rename macros to
always include the ARG or ARGS tag:
DROP_FIRST to DROP_FIRST_ARG
PICK_FIRST to FIRST_ARG
PICK_LAST to LAST_ARG
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> #v2 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240508171000.1864-1-michal.wajdeczko@intel.com
Shuicheng Lin [Tue, 7 May 2024 13:04:11 +0000 (13:04 +0000)]
drm/xe: Fix UBSAN shift-out-of-bounds failure
Here is the failure stack:
[ 12.988209] ------------[ cut here ]------------
[ 12.988216] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
[ 12.988232] shift exponent 64 is too large for 64-bit type 'long unsigned int'
[ 12.988235] CPU: 4 PID: 1310 Comm: gnome-shell Tainted: G U 6.9.0-rc6+prerelease1158+ #19
[ 12.988237] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3301.A02.2208050712 08/05/2022
[ 12.988239] Call Trace:
[ 12.988240] <TASK>
[ 12.988242] dump_stack_lvl+0xd7/0xf0
[ 12.988248] dump_stack+0x10/0x20
[ 12.988250] ubsan_epilogue+0x9/0x40
[ 12.988253] __ubsan_handle_shift_out_of_bounds+0x10e/0x170
[ 12.988260] dma_resv_reserve_fences.cold+0x2b/0x48
[ 12.988262] ? ww_mutex_lock_interruptible+0x3c/0x110
[ 12.988267] drm_exec_prepare_obj+0x45/0x60 [drm_exec]
[ 12.988271] ? vm_bind_ioctl_ops_execute+0x5b/0x740 [xe]
[ 12.988345] vm_bind_ioctl_ops_execute+0x78/0x740 [xe]
It is caused by the value 0 of parameter num_fences in function
drm_exec_prepare_obj. And lead to in function __rounddown_pow_of_two,
"0 - 1" causes the shift-out-of-bounds.
By design drm_exec_prepare_obj() should be called only when there are
fences to be reserved. If num_fences is 0, calling drm_exec_lock_obj()
is sufficient as was done in commit 9377de4cb3e8 ("drm/xe/vm: Avoid
reserving zero fences")
Niranjana Vishwanathapura [Tue, 7 May 2024 22:42:51 +0000 (15:42 -0700)]
drm/xe: Add Indirect Ring State support
When Indirect Ring State is enabled, the Ring Buffer state and
Batch Buffer state are context save/restored to/from Indirect
Ring State instead of the LRC. The Indirect Ring State is a 4K
page mapped in global GTT at a 4K aligned address. This address
is programmed in the INDIRECT_RING_STATE register of the
corresponding context's LRC.
v2: Fix kernel-doc, add bspec reference
v3: Fix typo in commit text
Lucas De Marchi [Mon, 6 May 2024 14:19:17 +0000 (07:19 -0700)]
drm/xe/ads: Use flexible-array
Zero-length arrays are deprecated and flexible arrays should be
used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arrays
Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506141917.205714-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Michal Wajdeczko [Tue, 7 May 2024 11:09:58 +0000 (13:09 +0200)]
drm/xe: Don't rely on xe_force_wake.h to be included elsewhere
While xe_force_wake.h is now included from the xe_device.h, we
want to drop that include as we don't need it there. Explicitly
include xe_force_wake.h where needed.
Michal Wajdeczko [Tue, 7 May 2024 11:09:57 +0000 (13:09 +0200)]
drm/xe: Don't rely on xe_assert.h to be included elsewhere
While xe_assert.h is now included and used by the xe_force_wake.h,
we want to stop include xe_force_wake.h from xe_device.h as it's
not needed there. Explicitly include xe_assert.h where needed.
drm/xe: skip error capture when exec queue is killed
When user closes exec queue soon after job submission,
we are generating error coredump. Instead check if
exec queue is killed during job timeout then skip
error coredump capture.
This is useful to check mocs configuration. Tests/Tools can use
this debugfs entry to get mocs info.
v2: Address review comments. Change debugfs output style similar
to pat debugfs. (Lucas De Marchi)
v3: rebase.
v4: Address review comments. Use function pointer inside ops
struct. Update Test-with links. Remove usage of flags wherever
not required. (Lucas De Marchi)
v5: Address review comments. Move register defines. Modify mocs
info struct to avoid holes. (Luca De Marchi)
Nirmoy Das [Tue, 30 Apr 2024 16:25:29 +0000 (18:25 +0200)]
drm/xe: Refactor default device atomic settings
The default behavior of device atomics depends on the
VM type and buffer allocation types. Device atomics are
expected to function with all types of allocations for
traditional applications/APIs. Additionally, in compute/SVM
API scenarios with fault mode or LR mode VMs, device atomics
must work with single-region allocations. In all other cases
device atomics should be disabled by default also on platforms
where we know device atomics doesn't on work on particular
allocations types.
v3: fault mode requires LR mode so only check for LR mode
to determine compute API(Jose).
Handle SMEM+LMEM BO's migration to LMEM where device
atomics is expected to work. (Brian).
v2: Fix platform checks to correct atomics behaviour on PVC.
Nirmoy Das [Tue, 30 Apr 2024 16:25:26 +0000 (18:25 +0200)]
drm/xe: Move vm bind bo validation to a helper function
Move vm bind bo validation to a helper function to make the
xe_vm_bind_ioctl() more readable.
v2: Capture ret value of xe_vm_bind_ioctl_validate_bo(Matt B).
Remove redundant coh_mode param.
Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Oak Zeng <oak.zeng@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-3-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Rodrigo Vivi [Fri, 3 May 2024 19:03:31 +0000 (15:03 -0400)]
drm/xe: Demote CCS_MODE info to debug only
This information is printed in any gt_reset, which actually
occurs in any runtime resume, what can be so verbose in
production build. Let's demote it to debug only.
Francois Dugast [Fri, 3 May 2024 08:24:50 +0000 (10:24 +0200)]
drm/xe/debugfs: Get a runtime_pm reference when setting wedged mode
This function is another entry point where it must be ensured that
the device resumes before operating on the GuC, so grab a runtime_pm
reference. This fixes inner xe_pm_runtime_get_noresume calls which
were previously failing.
projects / users / jedix / linux-maple.git / log