| Age | Commit message (Collapse) | Author |
|---|
|
A pipe reset restarts the shared PFP/ME, but CP firmware dequeues only
the requested queue. Wait for its CP_VMID_RESET bit and HQD_ACTIVE to
clear, and return -ETIMEDOUT if recovery does not complete.
Preempt each collateral kernel queue and wait for its HQD to deactivate
before rebuilding its MQD/ring and remapping it. Leave the guilty kernel
queue to the outer reset helper.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
A pipe reset restarts the shared PFP/ME, but CP firmware dequeues only
the requested queue. Wait for its CP_VMID_RESET bit and HQD_ACTIVE to
clear, and return -ETIMEDOUT if recovery does not complete.
Preempt each collateral kernel queue and wait for its HQD to deactivate
before rebuilding its MQD/ring and remapping it. Leave the guilty kernel
queue to the outer reset helper.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Expose amdgpu_gfx_mqd_reset_restore() so MES11/12 pipe reset can rebuild
collateral kernel rings.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Implement detect_hung_queue() by matching enabled HQD doorbells over
MMIO, allowing GFX reset to locate the queue without a MES request.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Implement detect_hung_queue() by matching enabled HQD doorbells over
MMIO, allowing GFX reset to locate the queue without a MES request.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Allow GFX recovery to resolve a doorbell to an HQD (ME, pipe, queue)
without querying a stalled MES scheduler.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_ring_set_fence_errors_and_reemit() and
amdgpu_ring_backup_unprocessed_commands() masked last_seq and sync_seq to
fence-array indices before the loop, then walked a do/while until the two
indices met. When hardware completed every command before the driver
signalled the fences, last_seq == sync_seq, but the masked-index do/while
could not tell that empty interval from a full table and walked the whole
fence array, backing up and replaying already-completed commands.
Read the raw sequence numbers, return early through amdgpu_fence_process()
when they are equal, and mask only at the array index. Guard the
force-completion against a NULL guilty_fence so a non-guilty backup does
not dereference it.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_ring_backup_unprocessed_commands() is also used to preserve a
ring that carries no guilty command - for example a collateral kernel
gfx ring that shares the faulting pipe during a gfx user-queue pipe
reset. Such a ring is backed up with a NULL guilty_fence and all of its
unprocessed commands must be saved so they can be replayed after the
reset rebuilds the ring's MQD.
The early-return that skips an already-seen guilty fence compared
"ring->guilty_fence == guilty_fence", which is also true when both are
NULL. A non-guilty save therefore hit the early return and left
ring_backup_entries_to_copy at 0, so the pending commands were dropped
when the ring was rebuilt.
Guard the early return with a non-NULL guilty_fence so a NULL fence
never takes it and every unprocessed command is backed up.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The soft_reset() function for IH (interrupt handler) blocks
of Vega and newer have never been implemented, and there are
no plans to implement them.
Let's delete these functions, they don't do anything and
also aren't called from anywhere.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The code for SI/CIK/VI IH (interrupt handler) IP blocks
has a soft_reset() function for each block.
These functions are not called from anywhere and are
dead code. It's unclear what the original intention
was or why the IH block would ever need to be reset.
All SI/CIK/VI GPUs have been working well for
10+ years without ever resetting the IH block
so it's time to just delete the dead code.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Just wait longer for psp command to complete.
Signed-off-by: Shiwu Zhang <shiwu.zhang@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
XNACK is not supported on A0. Updating RETRY_DISABLE only for the VMID
in use gives unreliable control, so all VMIDs must be programmed
identically.
Set SH_MEM_CONFIG.RETRY_DISABLE = 1 on rev_id 0 for every VMID in both
constants init and compute VMID init, so XNACK replay is off from device
boot up.
Signed-off-by: Alex Sierra <alex.sierra@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use the same helper for GMC v12.1 that is used by other
GMC IP block versions.
No functional changes intended. Just code cleanup.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DRM's fbdev helpers are for the fbdev-emulation clients. Move them
into the client-library module. Fix include statements throughout
DRM drivers.
While at it, rename the files from drm_fb_helper to drm_fbdev_helper.
The old name was too reminiscent of DRM's framebuffer code.
The GEM support code for fbdev remains part of DRM's memory managers.
v4:
- fix the depedendencies from v3
v3:
- remove obsolete dependencies from Kconfig
v2:
- update armada und docs
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260928080323.23909-3-tzimmermann@suse.de
|
|
https://gitlab.freedesktop.org/drm/kernel into drm-next
pci/vgaarb rework for drm/vfio
This reworks the vgaarb API to be a bit more sane.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Dave Airlie <airlied@gmail.com>
Link: https://patch.msgid.link/CAPM=9tzd3LteJG-Au=na-_X5Rff4tacFZ3X_cp5g0bCcQkV_jA@mail.gmail.com
|
|
amdgpu_gem_timeout() converts an absolute deadline in ns into jiffies,
which is what drm_timeout_abs_to_jiffies() already does for the other
drivers whose wait UAPI takes a deadline. Use the shared helper and keep
only the part that is specific to amdgpu, which was improved with a
clearer comment.
Two details change along this conversion: the helper rounds up rather than
truncating, so a deadline less than a tick away now waits for one jiffy
instead of returning 0. It also uses nsecs_to_jiffies64(), so the
conversion no longer truncates on 32-bit, where a large deadline could
previously be reduced to an arbitrary shorter one.
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-3-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
This changes the vgaarb client API so that the user can pass a
private data pointer into the register that will get used in
the decode callback.
This allows a bunch of pdev conversions in the drivers, and lets
some future vfio cleanups be nicer.
I'd like to merge this via the drm next tree but also fine with
it going via pci.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Alex Williamson <alex@shazbot.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/dri-devel/20260922071807.2533884-1-airlied@gmail.com/
|
|
Enable PerfOpt via amd_iommu_enable_perfopt() when the GPU's
iommu_perfopt module parameter is enabled (default 1) and the GPU
resides in the identity domain. The identity domain means the GPU is
already performing direct DMA with the IOMMU only enforcing IR/IW
permission bits -- no GPA->SPA translations.
amd_iommu_enable_perfopt() clears ATS, PRI, PASID and SVA for the
device. This is safe in identity domain because DTE[I]=0 means the
IOMMU already returns target abort for ATS requests from this
peripheral and the GPU manages its own TLB.
PerfOpt is a soft, optional latency optimization: failing to arm it (for
example on an IOMMU that does not implement the feature, which returns
-ENODEV) must not be fatal, so probe and resume warn and continue rather
than aborting.
PERF_OPT_EN is a per-IOMMU control shared by all devices behind that
IOMMU; the IOMMU driver reference counts it so that on systems where
multiple devices share one IOMMU, one GPU's teardown does not clear the
bit while a peer still requires it.
Arming PerfOpt trades IOMMU DMA containment for lower DMA latency. This
is enabled by default for GPUs in the identity domain as a deliberate,
documented policy and can be disabled with iommu_perfopt=0.
The AMD IOMMU spec indicates this is only supported on integrated GPUs
so check explicitly for AMD_IS_APU (which is set by
amdgpu_device_ip_early_init()).
PerfOpt is disabled during GPU init teardown and restored on resume.
Tested-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Boqun Feng (Netflix) <boqun@kernel.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
|
|
amdgpu_debugfs_test_ib_show() resumes the device with
pm_runtime_get_sync() before taking the reset domain semaphore with
down_write_killable(). If the write lock acquisition is interrupted,
the function returns without calling pm_runtime_put_autosuspend(),
leaking the runtime PM reference acquired for the device and keeping
the GPU awake.
Drop the runtime PM reference on the interrupted down_write_killable()
error path before returning.
Fixes: 6049db43d6dd ("drm/amdgpu: change reset lock from mutex to rw_semaphore")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ec30a576c2d4c0364549e6c04218f50704ef56c8)
Cc: stable@vger.kernel.org
|
|
amdgpu_vm_init() initializes vm->last_update, vm->last_unlocked and
vm->last_tlb_flush with references to the stub fence taken via
dma_fence_get_stub(). The error label at the end of the function
releases the last_unlocked and last_tlb_flush references with
dma_fence_put(), but the reference stored in vm->last_update is never
dropped, so whenever the page table root creation, the reservation of
the root BO or the PASID registration fails, the stub fence reference
leaks.
Drop the vm->last_update reference together with the other stub fence
references on the error path.
Fixes: 187916e6ed9d ("drm/amdgpu: install stub fence into potential unused fence pointers")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e7979c84fc05a176bdf855ee664871b1648404c9)
Cc: stable@vger.kernel.org
|
|
amdgpu_acpi_enumerate_xcc() looks up each XCC ACPI device with
acpi_dev_get_first_match_dev(), which takes a reference to the device.
The reference is dropped with acpi_dev_put() after the XCC info is
initialized, but if the kzalloc_obj() allocation of the XCC info fails
the function returns -ENOMEM without releasing the reference, leaking
the last reference to the ACPI device.
Drop the ACPI device reference on the allocation failure path before
returning.
Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects")
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9211ef48b31ec66999cf55e04d0cbc60cd855fd5)
Cc: stable@vger.kernel.org
|
|
amdgpu_ring_init() initializes ring->vmid_wait with a reference to the
stub fence taken via dma_fence_get_stub(). When a later step of the
initialization fails, e.g. amdgpu_fence_driver_init_ring(), a writeback
slot allocation or the ring buffer allocation, the function returns an
error without releasing the stub fence reference and the reference is
leaked if the ring is torn down without amdgpu_ring_fini().
Move the stub fence assignment to the end of the initialization, right
before the ring is registered with the GPU scheduler, where no further
failure is possible. The stub fence is only consumed by command
submission handling in amdgpu_ids.c once the ring is up and running, so
nothing reads it during the error-prone part of the initialization.
Fixes: 48e9fbd1a284 ("drm/amdgpu: initialize the vmid_wait with the stub fence")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f2b96986851203e9c50ca0d13aaa3581ca3e8ebd)
Cc: stable@vger.kernel.org
|
|
vcn_v4_0_3_reset_jpeg_pre_helper() passes adev->video_timeout directly
to amdgpu_fence_wait_polling(), whose timeout parameter is documented
and implemented in usecs (busy-wait loop decrementing by udelay(2)).
adev->video_timeout is set in jiffies by
amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies().
Passing it unconverted means the intended ~2s wait for outstanding
JPEG fences to complete before the JPEG queue is torn down actually
lasts only a couple of microseconds (HZ jiffies interpreted as usecs),
so pending jobs are almost never given a real chance to finish before
the reset path forces completion in the following helper.
Convert the jiffies value to usecs with jiffies_to_usecs() before
passing it to amdgpu_fence_wait_polling().
Fixes: d25c67fd9d6f ("drm/amdgpu/vcn4.0.3: rework reset handling")
Cc: Jesse.Zhang <Jesse.Zhang@amd.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5feabbd673c10ebee22b880e4d812f08974d2ef7)
Cc: stable@vger.kernel.org
|
|
vcn_v5_0_1_reset_jpeg_pre_helper() passes adev->video_timeout directly
to amdgpu_fence_wait_polling(), whose timeout parameter is documented
and implemented in usecs (busy-wait loop decrementing by udelay(2)).
adev->video_timeout is set in jiffies by
amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies().
Passing it unconverted means the intended ~2s wait for outstanding
JPEG fences to complete before the JPEG queue is torn down actually
lasts only a couple of microseconds (HZ jiffies interpreted as usecs),
so pending jobs are almost never given a real chance to finish before
the reset path forces completion in the following helper.
Convert the jiffies value to usecs with jiffies_to_usecs() before
passing it to amdgpu_fence_wait_polling().
Fixes: fab47d2db5ca ("drm/amdgpu/vcn5.0.1: rework reset handling")
Cc: Jesse.Zhang <Jesse.Zhang@amd.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b8334fec8b90ebffcaa01001a23edca9f29a05e9)
Cc: stable@vger.kernel.org
|
|
Function amdgpu_userq_start_hang_detect_work() calls msecs_to_jiffies()
on adev->gfx_timeout/compute_timeout/sdma_timeout before arming
hang_detect_work. These timeout values already hold jiffies values from
amdgpu_device_get_job_timeout_settings() at device init.
This silently shrinks the real hang-detect deadline to (2 * HZ) ms
instead of the intended timeout. e.g. 500ms instead of the 2000ms
default on a CONFIG_HZ=250 kernel, only coincidentally correct at
HZ=1000. The shortened window is easily exceeded by ordinary
fence-completion latency, causing hang_detect_work to fire and
trigger a per-queue or full GPU reset for queues that are not
actually hung.
Pass the jiffies value directly to queue_delayed_work() instead of
converting it a second time.
Fixes: fc3336be9c62 ("drm/amd/amdgpu: Add independent hang detect work for user queue fence")
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 13d44ca033cb74756c2aef0ade54a75cdf2f6271)
Cc: stable@vger.kernel.org
|
|
The eviction fence suspend worker waits for every pending userq fence
from inside a dma_fence_begin_signalling() critical section. Waiting on
another DMA fence while responsible for signalling one violates the
cross-driver fence contract and is reported by lockdep as a
dma_fence_map dependency.
Move the wait before dma_fence_begin_signalling(). Keep userq_mutex held
so queue lifetime remains stable while inspecting last_fence.
Fixes: fc61df151617 ("drm/amdgpu: annotate eviction fence signaling path")
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3bd4fbc5ed89621340b5cd249869092691a9c81f)
Cc: stable@vger.kernel.org
|
|
Use scoped_guard/scoped_cond_guard instead.
Saving and restoring the GFP flags is not necessary in those use case.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Natalie Vock <nat@pixelcluster.dev>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_debugfs_test_ib_show() resumes the device with
pm_runtime_get_sync() before taking the reset domain semaphore with
down_write_killable(). If the write lock acquisition is interrupted,
the function returns without calling pm_runtime_put_autosuspend(),
leaking the runtime PM reference acquired for the device and keeping
the GPU awake.
Drop the runtime PM reference on the interrupted down_write_killable()
error path before returning.
Fixes: 6049db43d6dd ("drm/amdgpu: change reset lock from mutex to rw_semaphore")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_vm_init() initializes vm->last_update, vm->last_unlocked and
vm->last_tlb_flush with references to the stub fence taken via
dma_fence_get_stub(). The error label at the end of the function
releases the last_unlocked and last_tlb_flush references with
dma_fence_put(), but the reference stored in vm->last_update is never
dropped, so whenever the page table root creation, the reservation of
the root BO or the PASID registration fails, the stub fence reference
leaks.
Drop the vm->last_update reference together with the other stub fence
references on the error path.
Fixes: 187916e6ed9d ("drm/amdgpu: install stub fence into potential unused fence pointers")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_acpi_enumerate_xcc() looks up each XCC ACPI device with
acpi_dev_get_first_match_dev(), which takes a reference to the device.
The reference is dropped with acpi_dev_put() after the XCC info is
initialized, but if the kzalloc_obj() allocation of the XCC info fails
the function returns -ENOMEM without releasing the reference, leaking
the last reference to the ACPI device.
Drop the ACPI device reference on the allocation failure path before
returning.
Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects")
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_ring_init() initializes ring->vmid_wait with a reference to the
stub fence taken via dma_fence_get_stub(). When a later step of the
initialization fails, e.g. amdgpu_fence_driver_init_ring(), a writeback
slot allocation or the ring buffer allocation, the function returns an
error without releasing the stub fence reference and the reference is
leaked if the ring is torn down without amdgpu_ring_fini().
Move the stub fence assignment to the end of the initialization, right
before the ring is registered with the GPU scheduler, where no further
failure is possible. The stub fence is only consumed by command
submission handling in amdgpu_ids.c once the ring is up and running, so
nothing reads it during the error-prone part of the initialization.
Fixes: 48e9fbd1a284 ("drm/amdgpu: initialize the vmid_wait with the stub fence")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
GC reset is not released during sw init and hence it shouldn't be
accessed. Move spm vmid programming to hw init phase. This programming
may later be overridden with the job's vmid.
Fixes: ad5f1ee0a9b0 ("drm/amdgpu: Add initial support for gfx v12_1")
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When MES fails to respond to a packet, the existing failure log only
prints the op name. Add fence_wait_ret and the packet's status word to
the same message. status_ptr is written directly by MES as part of
completing the packet, independently of the ring fence that
fence_wait_ret waits on, so a nonzero status despite a timed-out
fence_wait_ret narrows the failure to the trailing ring/query-status
packet rather than the original request.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When MES fails to respond to a packet, the existing failure log only
prints the op name. Add fence_wait_ret and the packet's status word to
the same message. status_ptr is written directly by MES as part of
completing the packet, independently of the ring fence that
fence_wait_ret waits on, so a nonzero status despite a timed-out
fence_wait_ret narrows the failure to the trailing ring/query-status
packet rather than the original request.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When MES fails to respond to a packet, the existing failure log only
prints the op name. Add fence_wait_ret and the packet's status word to
the same message, so a fence-wait timeout (MES itself stalled) can be
told apart from a fast explicit rejection (fence signaled, but the low
status word is 0) directly from the log, along with the MES-reported
error code carried in the high status word for the latter case.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
vcn_v4_0_3_reset_jpeg_pre_helper() passes adev->video_timeout directly
to amdgpu_fence_wait_polling(), whose timeout parameter is documented
and implemented in usecs (busy-wait loop decrementing by udelay(2)).
adev->video_timeout is set in jiffies by
amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies().
Passing it unconverted means the intended ~2s wait for outstanding
JPEG fences to complete before the JPEG queue is torn down actually
lasts only a couple of microseconds (HZ jiffies interpreted as usecs),
so pending jobs are almost never given a real chance to finish before
the reset path forces completion in the following helper.
Convert the jiffies value to usecs with jiffies_to_usecs() before
passing it to amdgpu_fence_wait_polling().
Fixes: d25c67fd9d6f ("drm/amdgpu/vcn4.0.3: rework reset handling")
Cc: Jesse.Zhang <Jesse.Zhang@amd.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
vcn_v5_0_1_reset_jpeg_pre_helper() passes adev->video_timeout directly
to amdgpu_fence_wait_polling(), whose timeout parameter is documented
and implemented in usecs (busy-wait loop decrementing by udelay(2)).
adev->video_timeout is set in jiffies by
amdgpu_device_get_job_timeout_settings(), via msecs_to_jiffies().
Passing it unconverted means the intended ~2s wait for outstanding
JPEG fences to complete before the JPEG queue is torn down actually
lasts only a couple of microseconds (HZ jiffies interpreted as usecs),
so pending jobs are almost never given a real chance to finish before
the reset path forces completion in the following helper.
Convert the jiffies value to usecs with jiffies_to_usecs() before
passing it to amdgpu_fence_wait_polling().
Fixes: fab47d2db5ca ("drm/amdgpu/vcn5.0.1: rework reset handling")
Cc: Jesse.Zhang <Jesse.Zhang@amd.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When one side of UALink nodes reboots, its ring wptr resets to 0 while
the peer keeps a stale value. Read the remote wptr and adopt it as the
local wptr and rptr to resync, before the first message is sent. Either
side can notice first, so do this both when setting up the connection
and when receiving the HELLO from the peer.
On the sdma path, read the wptr in a fence callback because the IB buffer
holding the result is recycled once the fence signals, so reading it
after dma_fence_wait_timeout() is too late. The lsdma path copies
synchronously, so it reads the wptr directly.
Take peer->lock in the callers (amdgpu_ualink_remote_interrupt and
amdgpu_ualink_remote_shootdown) instead of in amdgpu_ualink_send_command,
so the ring->ready check and the send are atomic against a concurrent
ring reset.
Move the rptr refresh and ring-full check out of amdgpu_ualink_send_command()
into amdgpu_ualink_ring_check_space(), so it runs under the caller's
peer->lock before the job is allocated.
On a failed NPA-REQ send, reset the connection like the NPA-RSP timeout path
already does, so the next attempt resyncs the ring wptr.
On connection reset, amdgpu_ualink_reset_peer_rings() only clears
ring->ready, so the writeback address is re-registered on the next send.
v10:
- Fix the resync missed on the receiving side: after a reboot the peer
may send HELLO before we set up the connection, so resync the ring
wptr in amdgpu_ualink_process_hello_msg() too.
v9:
- Fix the unnecessary connection reset after an app exits: the peer is
idle here but still busy handling NPA revokes on the remote, so the
HELLO reset a healthy connection. Only send it if the wptr changed.
- Resync both rings together under peer->lock, read both remote wptr
before updating either so a failed read changes nothing.
v8:
- Fix regression with concurrent import ioctls: do the idle check and
ring reset in amdgpu_ualink_setup_connection() under conn_state->lock,
and return -EAGAIN for IN_PROGRESS/PENDING first.
- Reset the peer rings only, the imp/exp xarray cleanup is not needed to
resync wptr.
v7:
- With v6 reboot one node of vPOD test passed on minirack.
- Use the per-remote imported and exported handle lists for the idle
check instead of walking the xarrays.
- Rename amdgpu_ualink_resync_peer_rings() to
amdgpu_ualink_reset_peer_rings(), it only clears ring->ready.
v6:
- Check idleness per remote accelerator instead of globally, and reset
the stale connection at the import ioctl so the peer re-runs the
HELLO handshake after a reboot.
v5:
- Resync the ring pointers at the import ioctl when the connection is
completely idle (no exported or imported BOs), so the first command
from a new application after a remote reboot/reset succeeds.
- Put the sdma wptr read fence callback on the stack instead of
allocating it; it is cancelled on timeout so it never outlives the
call.
v4:
- Cancel the sdma fence callback on the wait timeout/failure path so it
cannot write into the caller's stack after the function returns, and
free the callback state in one place.
v3:
- Resync both rings at connection setup instead of on the send path.
- Set the writeback rptr too, the stale value disagrees with the
resynced wptr until the remote FW writes it back.
v2:
- Match the FW change: resync wptr only on the first send or after a
timeout, instead of checking the remote periodically.
Suggested-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_generate_ualink_handle() continues when handle_lo is zero. For
accelerator ID 0, the random value can become zero after the low 10 bits
are cleared. This path reaches while (!unique) without assigning unique.
Clang's -Wconditional-uninitialized reports the read. A reduced
MemorySanitizer test reports use-of-uninitialized-value at the loop
condition.
If the uninitialized value ends the loop, handle 0 is inserted into
exp_xa while robj->ualink_handle_lo still says that the BO has no handle.
A later export can create another entry for the same BO.
Initialize unique to false so the zero-handle path repeats the loop.
Fixes: c67cb19811ec ("drm/amdgpu: Implement UALink handle export")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Function amdgpu_userq_start_hang_detect_work() calls msecs_to_jiffies()
on adev->gfx_timeout/compute_timeout/sdma_timeout before arming
hang_detect_work. These timeout values already hold jiffies values from
amdgpu_device_get_job_timeout_settings() at device init.
This silently shrinks the real hang-detect deadline to (2 * HZ) ms
instead of the intended timeout. e.g. 500ms instead of the 2000ms
default on a CONFIG_HZ=250 kernel, only coincidentally correct at
HZ=1000. The shortened window is easily exceeded by ordinary
fence-completion latency, causing hang_detect_work to fire and
trigger a per-queue or full GPU reset for queues that are not
actually hung.
Pass the jiffies value directly to queue_delayed_work() instead of
converting it a second time.
Fixes: fc3336be9c62 ("drm/amd/amdgpu: Add independent hang detect work for user queue fence")
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit 0a6da5dcfe42 ("drm/amdgpu: Improve ualink state transitions")
introduced an access to info->accel_state before checking whether info
is NULL.
Move the access after the NULL check to avoid a potential NULL pointer
dereference.
Fixes: 0a6da5dcfe42 ("drm/amdgpu: Improve ualink state transitions")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Lijo Lazar <lijo.lazar@amd.com>
Cc: Felix Kuehling <felix.kuehling@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The eviction fence suspend worker waits for every pending userq fence
from inside a dma_fence_begin_signalling() critical section. Waiting on
another DMA fence while responsible for signalling one violates the
cross-driver fence contract and is reported by lockdep as a
dma_fence_map dependency.
Move the wait before dma_fence_begin_signalling(). Keep userq_mutex held
so queue lifetime remains stable while inspecting last_fence.
Fixes: fc61df151617 ("drm/amdgpu: annotate eviction fence signaling path")
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The MES event-log/MSCRATCH region is only zeroed once at sw_init. On the
resume path (hw_init without sw_init) it retains stale data, so with
mes_log_enable=1 the MES firmware walks stale pointers on activation and
triggers a recoverable CPC page fault:
[gfxhub] page fault (src_id:0 ring:153 vmid:0 pasid:0)
in page starting at address 0x000000855c237000 from client 10
GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B33
Faulty UTCL2 client ID: CPC (0x5)
MORE_FAULTS: 0x1 WALKER_ERROR: 0x1 PERMISSION_FAULTS: 0x3
MAPPING_ERROR: 0x1 RW: 0x0
Re-clear it before unhalting MES.
Reviewed-by: James Zhu <James.Zhu@amd.com>
Tested-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The critical region v2 patches clear the fw_reserve.p_pf2vf variable after
pf2vf data is read the first time. have_atomics_support relies on that
variable to check for PCIe atomic ops support.
Move have_atomics_support check for SRIOV VFs to be when pf2vf data is
read.
Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
Reviewed-by: Ellen Pan <yunru.pan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The previous change set CP_HQD_PQ_CONTROL.SCOPE=3 (SYSTEM) only for KFD
AQL queues, but PM4 queues and the kernel-managed compute (KCQ) queues
can also use non-coherently cached ring buffers and hit the same
stale-packet problem.
Set the scope for both PM4 queues and KCQs as well.
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-next
[airlied: fix two merge conflicts]
amd-drm-next-7.4-2026-09-17:
amdgpu:
- SMU 14.x fix
- DC IRQ fix
- Runtime PM fix for P2P
- RAS fix
- PCIe reporting fix
- DCN 6 fix
- Device removal fix
- DC MALL fix
- Display KUNIT test fixes
- More display KUNIT tests
- GC 12.1 cleanup
- DC RMCM refactor
- Display forces RGB fix
- DP MST fixes
- USB4 fixes
- Plane update fixes
- DMUB updates
- ISM fixes
- DCN 4.2 updates
- HDMI FRL updates
- Add new trace events
- SDMA soft reset updates
- Update git trees in MAINTAINERS
- UALink fixes
- UserQ fixes
- SDMA clean ups
- Misc spelling fixes
- Documentation fixes
- ATOM range checks
amdkfd:
- GC 12.x fixes
- Boundary checks
- Mapping clear fix
- GC 10 CU occupancy support
- GC 12.1 fixes
- XNACK fix
- Partition fix
radeon:
- eDP fix for DCE3.2 iMacs
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260917203841.3881294-1-alexander.deucher@amd.com
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v7.4:
UAPI Changes:
ivpu:
- add DRM_IVPU_CAP_CMDQ_SET_PRIORITY
Cross-subsystem Changes:
dma-fence:
- fix documentation
vga_switcheroo:
- disconnect from fbcon; update fbcon from within DRM fbdev emulation
Core Changes:
atomic:
- replace state reset callback with create_state throughout DRM core
and drivers
panic:
- split into core and helpers
sched:
- clean up interface
sysfs:
- drop drm_class_device_register()
Driver Changes:
amdxdna:
- fix BO handling
arcpgu:
- replace simple-display pipeline with regular atomic helpers
aspeed:
- replace simple-display pipeline with regular atomic helpers
gm12u320:
- replace simple-display pipeline with regular atomic helpers
imagination:
- various improvement to firmware interaction
ivpu:
- support command-queue priority ioctl
mcde:
- replace simple-display pipeline with regular atomic helpers
p111:
- replace simple-display pipeline with regular atomic helpers
- drop unsupported alpha formats from primary plane
panel:
- edp: Add support for BOE NV140FHM-T0A
- samsung: Share test-key helpers
rcar-du:
- support Renesas R-Car V4H DSC
- dsi: Support larger transfers with AXI memory
repaper:
- replace simple-display pipeline with regular atomic helpers
rockchip:
- dsi: improve PHY timings
ssd130x:
- support Solomon SSD1351 OLED plus DT bindings
- ssd133x: upgrade color format to RGB565
tve200:
- replace simple-display pipeline with regular atomic helpers
xen:
- replace simple-display pipeline with regular atomic helpers
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260917090534.GA420415@2a02-2455-9062-2500-ec39-e8a6-193-9c05.dyn6.pyur.net
|
|
amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so
drm_dev_enter() is already false there and the iounmap() guarded by it
is skipped. This .remove path runs on both hot-unplug and plain rmmod,
so the register BAR ioremap mapping leaks one instance per unload.
Unmap rmmio unconditionally (guard only on non-NULL) and drop the now
unused idx.
Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged")
Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com>
Reviewed-by: Asad Kamal <asad.kamal@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6)
Cc: stable@vger.kernel.org
|
|
amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev
has a fully populated node array. This is not true when KFD device
initialization fails after probe.
For example, kgd2kfd_device_init() sets num_nodes before checking
PCIe atomics support. On Polaris systems without the required atomics,
it returns before allocating nodes[0], but the kfd_dev remains attached
to the amdgpu device. A later GPU reset then dereferences nodes[0]->id.
Require the authoritative KFD initialization flag before walking the
node array, matching the existing KFD reset and teardown paths.
Fixes: 70cadefcc616 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5833
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4ac1835823c47903fbb278bbf474773c46f59edc)
Cc: stable@vger.kernel.org
|
|
Commit eb53125a7ad9 ("drm/amd: Add dedicated helper for
amdgpu_device_find_parent()") made amdgpu_device_gpu_bandwidth() query
the first device outside the dGPU. That is the host side of the
physical link, not the GPU side.
As a result, the ASIC and platform capability masks can both be based
on the host port. drm_amdgpu_info_device then exposes the host
capabilities to userspace, such as Gen5 x16 for a Gen4 x8 GPU.
Cache both ends of the physical link during device initialization.
Use link_dev for the GPU capability and link_partner for the platform
capability and _PR3 detection.
Reported-by: "Marek Olšák" <maraeo@gmail.com>
Closes: https://lore.kernel.org/amd-gfx/CAAxE2A4VhsAzzO1QjBjUg+NgnbD04ZzMyN6xsUJxjKJHH6hxiw@mail.gmail.com/
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Fixes: eb53125a7ad9 ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7ea6a47224e2c6e89a3a682d7fbaace4817a55aa)
Cc: stable@vger.kernel.org
|
