| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
The compute partition switch locked the kfd device, freed it during the
pre-switch teardown, and then unlocked at the end - by which point
adev->kfd.dev referenced the newly reinitialized device, so the unlock
landed on the wrong object and the per-device lock was never balanced.
Add a dedicated prepare function to unwind and clean up kfd device.
Don't use the global lock during teardown. A new device is created after
partition switch; hence there is no need to do 'unlock' on a different
object after the switch.
User is not supposed to run any process on the device during partition
switch. Keep acquire/release semantics for init_complete so that the
device remains unavailable for a process till its reinitialization is
complete.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
After "drm/amdgpu: Fix GPU PCIe link capability reporting" there are
now a few areas of walking topology.
Use the cached GPU-side link device for ASPM queries and switch state
caching instead of walking the PCI topology independently in each path.
Validate the internal downstream/upstream switch pair when initializing
the cached link devices so all consumers share the existing topology
checks.
Acked-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>
|
|
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>
|
|
dcn42_prepare_bandwidth
dc->clk_mgr is already dereferenced inside dcn401_prepare_bandwidth(),
so the dc->clk_mgr NULL check that follows is redundant and misleading.
Drop it.
Fixes: 53845307d52e ("drm/amd/display: Register DCN as a PMFW DF C-state client on DCN42")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Leo Chen <leo.chen@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix a hardware RTL bug in the TCP XNACK scoreboard reset path where a wave
receiving a no-retry FAULT from UTC and subsequently terminating may leave
its scoreboard entry uncleared when reset events arrive back-to-back.
This can cause a later, unrelated wave using the same slot to incorrectly
inherit the XNACK error state, resulting in its VMEM operations being
dropped even though the wave never faulted.
Signed-off-by: Gang Ba <Gang.Ba@amd.com>
Reviewed-by: Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
atom_get_vbios_date(), atom_get_vbios_pn(), atom_get_vbios_version()
and atom_get_vbios_build() all walk the BIOS image using offsets and
counts taken from the image itself, checked only against each other
and never against ctx->bios_size:
- atom_get_vbios_date() reads 14 bytes at a fixed offset that
check_atom_bios()'s minimum size (0x49) does not cover.
- atom_get_vbios_pn() dereferences an image-supplied u16 string
offset unchecked, then walks and copies from it with only a length
cap, not an image cap.
- atom_get_vbios_version() takes its search bounds from image u16s;
atom_find_str_in_rom() already clamps the search itself, but the
match is then advanced by a fixed 18 bytes and STRLEN_NORMAL bytes
are copied from there with no check that this still lands inside
the image.
- atom_get_vbios_build() walks from an image-supplied config-string
offset toward the ROM header; a config offset at or past the
header makes the pointer difference negative, wrapping through the
u16 'len' and passing strscpy() a bound far larger than the
32-byte destination.
Bound each getter's reads, walks and copies to ctx->bios_size, falling
back to an empty string on a malformed image.
Fixes: 29b4c589b43d ("drm/amdgpu: Add vbios info ioctl interface")
Fixes: d6fa80266178 ("drm/amdgpu: Add vbios build number interface")
Assisted-by: gkh_clanker_t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
dc->clk_mgr is checked for NULL earlier in dcn50_init_hw() and
dcn60_init_hw(), but dcn50_initialize_min_clocks() and
dcn401_initialize_min_clocks() are called without any guard,
causing Smatch to report potential NULL dereferences.
Guard both call sites with the same pattern used throughout
both functions:
if (dc->clk_mgr && dc->clk_mgr->funcs)
Also fix dcn50_initialize_min_clocks() which calls
get_dispclk_from_dentist without checking the function pointer,
unlike the dcn401 equivalent which guards that call.
Fix kernel-doc in dcn60_hwseq.c by adding missing parameter descriptions
for @probe in dcn60_update_probe_status() and @type in
is_probe_measurement_type_for_hubbub().
Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
order_base_2(q->eop_ring_buffer_size / 4) - 1
But order_base_2 can in theory return 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
order_base_2(q->eop_ring_buffer_size / 8)
using properties of logarithms.
Also add to the above comment to make the mathematics more clear.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1
But ffs can in theory return 1 or 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4)
using properties of logarithms.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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>
|
|
Instead of searching for the matching SDMA instance inside many of the
SDMA ring vfuncs lets just use the instance number already stored in the
ring and replace the function calls and array walks with direct lookups.
As these helpers are used only from SDMA vfuncs we can remove safely
remove the "is this a SDMA ring" checks as well.
We could add an assert that ring->type queried is AMDGPU_RING_TYPE_SDMA
but as currently there are no debug build only assert macros in this
driver for now I opted not to so the helper can stay a trivial static
inline without polluting the callers with out of line logging.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There is an include loop between amdgpu.h and amdgpu_sdma.h which
prevents adding any interesting static inline helpers to the latter.
Break it by moving the type definitions to a new amdgpu_sdma_types.h
header.
This is required so static inline helpers which need to dereference
struct amdgpu_device can be added to amdgpu_sdma.h.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
atomctrl_get_smc_sclk_range_table() copies ucSclkEntryNum entries from
the VBIOS SMU_Info table into pp_atom_ctrl_sclk_range_table. Both the
source (asSclkFcwRangeEntry[]) and destination (table->entry[]) arrays
are fixed at MAX_SCLK_RANGE (8) entries, but ucSclkEntryNum is an
unchecked u8 read straight from the VBIOS, so it can be up to 255. The
destination is stack-allocated in both callers
(polaris10_get_sclk_range_table(), vegam_get_sclk_range_table()), so a
count above 8 overflows a stack buffer, not just a heap read.
Reject counts above MAX_SCLK_RANGE rather than clamping to it. Only
one version of this VBIOS struct (ATOM_SMU_INFO_V2_1) has ever
existed, so a count above 8 corresponds to no legitimate table format
and means either a corrupted or a tampered VBIOS.
Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.")
Assisted-by: gkh_clanker_t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On GFX 12.1, ring buffers may be mapped with a non-coherently
cached memory type. In that case the queue fetch can observe stale
packets, since the packet producers (CPU or other GPUs) do not keep the
device-side cache coherent.
Set CP_HQD_PQ_CONTROL.SCOPE=3 (SYSTEM) so the queue fetches use
system scope and pick up the latest packets. Apply this to compute queue
MQDs and to MES-managed queues.
Without this, the queue can consume stale packets for long periods,
causing severe slowdowns and, in the worst case, application hangs.
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Joseph Greathouse <joseph.greathouse@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
scripts/kernel-doc reports missing and excess member descriptions
for struct amdgpu_display_manager:
struct member 'power_module' not described
struct member 'hdmi_frl_status_polling_wq' not described
struct member 'hdmi_frl_status_polling_delay_ms' not described
struct member 'boot_time_crc_info' not described
Excess struct member 'dm_boot_time_crc_info' description
Add @power_module to the main struct doc, document
hdmi_frl_status_polling_wq/work/delay_ms with separate inline
comments, and rename @dm_boot_time_crc_info to @boot_time_crc_info
to match the actual member name.
Signed-off-by: Omokefe Emmanuel Onanaroghene <emmaonana18@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix the spelling in comments. No functional change.
Signed-off-by: Ruslan Vagner <rusya92266@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
nbio_v7_9_handle_ras_controller_intr_no_bifring() dereferences ras and obj
without checking either for NULL. Both amdgpu_ras_get_context() and
amdgpu_ras_find_obj() can return NULL, e.g. during the window between
adev->nbio.ras being set (early in amdgpu_ras_init(), by design, to
enable the fatal-error interrupt as soon as possible) and the PCIE_BIF
ras object actually being created in RAS late_init. Any interrupt in that
window crashes in hard-IRQ context.
This is analogous to commit d190b459b2a4 ("drm/amdgpu: the warning
dereferencing obj for nbio_v7_4"), which fixed the same issue in the
nbio_v7_4 handler.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 7692e1ee2446 ("drm/amdgpu: add RAS fatal error handler for NBIO v7.9")
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Now, sdma_v4_4_2_reset_queue() does basically the same
as amdgpu_sdma_reset_queue_legacy() so let's use that.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Consolidate one part of the SDMA ring initialization with a new
amdgpu_sdma_ring_init() helper.
Only code which is completely IP version agnostic is moved to the helper.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Root cause:
- In userq restore/rearm, root PD was locked with amdgpu_vm_lock_pd(vm, &exec, 1).
- Later in the same drm_exec context, amdgpu_evf_mgr_rearm() attaches
BOOKKEEP eviction fences to all locked BOs.
- In this flow, root PD validation/update can also consume move-fence slots,
so reserving only +1 at PD lock time is not sufficient under stress.
Fix:
- Reserve caller-side slots at the actual source by switching to:
amdgpu_vm_lock_pd(vm, &exec, TTM_NUM_MOVE_FENCES + 1)
This keeps reservation policy in callers, consistent with Christian Konig
feedback and with amdgpu_gem_object_open() where callers reserve
TTM_NUM_MOVE_FENCES + 1 before attaching eviction fences.
Credit:
- Christian Konig: confirmed fence-slot reservation belongs to callers and
asked to investigate why +1 was still not enough.
- Prike Liang: clarified the initial variant was workaround-only and
developed that initial version independently.
Cc: Prike Liang <prike.liang@amd.com>
Cc: Sunil Khatri <sunil.khatri@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Root cause analysis showed that the previous workaround was fixing the
symptom in the wrong layer.
Problem:
kernel BUG at drivers/dma-buf/dma-resv.c:319!
BUG_ON(fobj->num_fences >= fobj->max_fences)
Workqueue: events amdgpu_userq_restore_worker
- amdgpu_evf_mgr_attach_fence() had been temporarily taught to reserve/add
fence bookkeeping internally as a workaround.
- This hid the real contract violation and made reservation policy implicit
inside a helper.
Review clarification:
- The helper-side dma_resv_add_fence-related workaround was only an intended
proposal sent for review discussion, not the final direction.
- Final fix keeps fence-slot reservation explicit in callers and leaves the
helper free of policy decisions.
Findings from investigation:
- drm_exec_prepare_obj() both locks and reserves fence slots.
- drm_exec_lock_obj() only locks and does not reserve slots.
- Existing attach_fence callers in the GEM/userq restore flows already reserve
TTM_NUM_MOVE_FENCES + 1 before adding the bookkeeping eviction fence.
- The WPTR mapping path in mes_userq_create_wptr_mapping() used
drm_exec_lock_obj() and then called amdgpu_evf_mgr_attach_fence(), so this
specific path could add a fence without pre-reserved space.
Fix:
- Switch the WPTR mapping path to drm_exec_prepare_obj(...,
TTM_NUM_MOVE_FENCES + 1), restoring the caller-side reservation contract.
- Remove the helper-side reservation workaround from
amdgpu_evf_mgr_attach_fence().
Why this is the right layer:
- Reservation policy stays explicit at call sites that define how many fences
may be added in that execution context.
- The helper only performs validate + add_fence when called with a properly
prepared reservation object, matching the existing drm_exec model.
Fixes: 7264bc10c7c6 (drm/amdgpu: dont pin wptr bo instead use eviction fence)
Cc: Sunil Khatri <sunil.khatri@amd.com>
Cc: Prike Liang <prike.liang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Prike Liang <prike.liang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The Apple iMac10,1 and iMac11,2 (RV730/DCE3.2) drive their internal eDP
panel through an LVTMA power sequencer whose enable bit (PWRSEQ_EN in
LVTMA_PWRSEQ_CNTL) is programmed exactly once, by EFI at cold boot.
Apple's minimal ATOM tables never touch it afterwards, so any GPU
re-initialisation - S3 resume or a GPU-lockup reset - clears PWRSEQ_EN
and the panel comes back dark while the rest of the GPU resumes fine.
The driver never programs this register itself; on every other radeon
board the platform firmware maintains it across a re-POST, which is why
this only bites the Apple machines. Re-assert PWRSEQ_EN in the eDP
DPMS-on path when it is found cleared; the hardware then runs the
DIGON->DE->VARY_BL->BLON power-on sequence on its own. Both failure
paths pass through here, as radeon_gpu_reset() restores the modeset
state via radeon_resume_kms(), so a single site covers resume and reset.
The write is gated to Apple parts and to exactly DCE3.2 (ASIC_IS_DCE32
is >= RV730, so DCE4+ must be excluded - Apple also shipped DCE5, e.g.
the 2011 MacBook Pro, where the register lives at a different offset).
It is skipped when the sequencer is already enabled, so lit panels,
DCE4+ boards and non-Apple boards are untouched. DCE3.2 places the
register 0x18 above the documented R600 offset.
Only iMac11,2 is verified on hardware; iMac10,1 shares the same RV730
design and Apple EFI behaviour.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5719
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260914022002.2005150-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When a HELLO arrived on an already ESTABLISHED connection,
amdgpu_ualink_process_hello_msg() set the state to PENDING before
calling amdgpu_ualink_handle_connection_reset(). That function only
runs the imp/exp XA cleanup when it observes the state as ESTABLISHED,
so the premature change skipped the cleanup and left stale NPA
mappings and pinned BOs from the previous connection.
Leave the state as ESTABLISHED and let
amdgpu_ualink_handle_connection_reset() perform the transition, so the
cleanup runs.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by : Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_dma_buf_map() adds VRAM to the allowed domains for a peer2peer
attachment. GTT is only a fallback placement when VRAM is preferred, so
ttm_bo_validate() migrates the buffer from GTT into VRAM. While the
exporting device is runtime suspended its SDMA rings are down and the
move fails:
amdgpu: Move buffer fallback to memcpy unavailable
An importer on a second GPU reaches this holding no runtime PM
reference on the exporter, e.g. a compositor on the APU submitting a
frame that references a buffer exported by an idle dGPU:
amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_cs_bo_validate
-> ttm_bo_validate -> amdgpu_bo_move -> dma_buf_map_attachment
-> amdgpu_dma_buf_map -> ttm_bo_validate -> amdgpu_bo_move
Pinning a dma-buf into VRAM has the same requirement, which
commit 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference
when we attach a buffer" v2") called out as the one case that would
need the reference back.
Take it in attach and drop it in detach. pm_runtime_get_if_active()
never resumes the device, so it cannot deadlock against the reservation
taken during resume, which is why the old pm_runtime_get_sync() had to
go. If the device is not active, clear peer2peer instead: the buffer
then stays in GTT, which remains accessible while the GPU is powered
down. If runtime PM is disabled, take a plain reference so the put in
detach stays balanced.
Fixes: 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2")
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
Assisted-by: Claude:Opus-5 [Claude Code]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove the caller_handles_kernel_queues argument from
the amdgpu_sdma_reset_engine() function and make it
always handle kernel queues.
Now the SDMA recovery sequence is more consistent
between callers for the KFD as follows.
Before recovery: first the KFD is suspended,
then the SDMA queue contents are backed up.
After recovery: first the SDMA queue contents
are restored, then the KFD is resumed.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The code was exactly the same between SDMA v5.0 and v5.2
furthermore the exact same implementation can be shared
between all SDMA versions that don't use MES.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The ring contains commands that were emitted before the reset.
These need to be cleared to make sure the HW doesn't execute
them, because they are garbage at this point.
Note that the ring reset helpers will re-emit the commands
that are necessary after the reset.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
A new helper function which clears the contents of
a ring and the relevant pointers such as rptr/wptr.
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_sdma_reset_engine() saves and restores contents of
both the SDMA gfx queue and the paging queue, so it's
not necessary to track which queue was guilty anymore.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
SDMA v4.4.2 had a custom recovery implementation that
tried to keep ring contents and restore the rptr after
an SDMA soft reset. Later it was changed to use the
more common amdgpu_sdma_reset_engine() implementation.
Currently, SDMA v4.4.2 may execute some commands twice
after a recovery:
1. From the old ring buffer contents at the restored rptr
2. From the contents restored by amdgpu_sdma_reset_engine()
that calls the ring reset helper functions.
Fix that by removing the code that restores rptr.
This is not needed anymore because amdgpu_sdma_reset_engine()
already saves and restores the contents of both the SDMA gfx
and paging rings, so there is no need to do anything extra.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Every SDMA generation has an rlc_resume and rlc_stop function
which are not doing anything.
Starting from CIK, the SDMA engine supports additional queues
which are called "SDMA compute" or "RLC" queues, and these
queues are used by the KFD, and configured using the HWS.
There is nothing for the kernel driver to do for these.
Let's delete the functions that don't do anything.
In case of SDMA v4.0 and v4.4.2 let's move the init_pg()
call to the start() function.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
These functions are not called from anywhere
and don't do anything. Let's delete them.
Also remove the srbm_soft_reset field from amdgpu_sdma
which is not set anywhere anymore.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
kfd_mqd_manager_v12.c (GFX 12.0) and kfd_mqd_manager_v12_1.c (GFX 12.1)
do not implement restore_mqd callbacks, leaving the function pointers
NULL and causing CRIU restore to return -EOPNOTSUPP on GFX12.
Implement restore_mqd for both compute and SDMA queues in
kfd_mqd_manager_v12.c and kfd_mqd_manager_v12_1.c, modeled after the
GFX 11 implementation with the following improvements:
- update cp_mqd_base_addr_lo/hi to the newly allocated MQD address,
fixing a pre-existing gap shared with v11 where the in-MQD copy
still pointed at the old checkpoint-time address after restore
- memset the full allocation before memcpy for compute queues to avoid
stale data in the GTT sub-allocator tail; SDMA MQDs use sizeof(*m)
since they are packed at mqd_size stride in a shared BO
checkpoint_mqd registration is deferred to a follow-up patch that also
implements get_checkpoint_info, so that checkpoint and restore are
enabled together as a complete and testable unit.
Note: GFX12.1 restore handles XCC0 only. Multi-XCC CRIU restore is
currently unreachable due to a separate validation issue in
kfd_criu_restore_queue(). A pr_warn_once() is emitted if a multi-XCC
device is encountered.
Signed-off-by: Vladimir Marioukhine <Vladimir.Marioukhine@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Disable gfxoff while collecting CU occupancy data.
Reported-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Belanger <david.belanger@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Port changes from GFX9 to GFX10/GFX10.3 mostly as-is.
Minor changes to register access code.
Assisted-by: Claude:sonnet-4-6
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Belanger <david.belanger@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Some debugging applications need to track when a process starts
or stops using the amdgpu driver. For those processes, add ftrace
events that track when a amdgpu_vm task info is changed or destroyed.
v2: Deregister in fini, not destroy.
v3: Also report render minor and major
cc: Sunil Khatri <Sunil.Khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This version brings along the following updates:
- Expand amdgpu_dm KUnit coverage across connector init, sink stream
creation, FreeSync caps, forced atomic commit, plane modifiers, cursor
updates, panic flush, MST connector creation, AUX transfers, link
bandwidth readback and MST DSC configuration.
- Refactor RMCM into a separate module.
- Decouple cursor offload hwss executors from pipe context.
- Decouple HUBP_UPDATE_PLANE_ADDR from pipe_ctx.
- Rename lock_and_validation_needed to needs_dc_state_realloc.
- Drop the dead update_type param from update_planes_and_stream_adapter.
- Attach only plane updates and stream updates that actually changed.
- Unify fast update classification paths.
- Request DMUB HW cursor offload.
- Program DCC as part of address update.
- Update LLS and UPSP programming paths.
- Add lock-free memory pool.
- Add instance field to struct mpc and struct dccg.
- Cleanup DMUB command submission interfaces.
- Add inbox0 HW lock helpers for DCN35.
- Atomize IRQ register read/modify/write ops.
- Add Replay cumulative residency query.
- Add urgent assertion counter probe.
- Add debug option to force optional UCLK support.
- Force DSC to 8bpp for SST and MST DP tunneling over USB4.
- Honor forced RGB pixel encoding.
- Add option for certain panels to disable FEC.
- Cap DML2.1 vmin ODM combine at 2:1 for eDP.
- Add is_odm_enabled callback to skip init_odm on active ODM pipes.
- Remove MALL capabilities from DCN42B.
- Skip MALL calculations when there is no MALL.
- Enable power gating on dcn42b.
- Remove SDPIF_PORT_CONTROL programming for DCN31/35/42.
- Enable back alt-ch.
- Flush ISM work before releasing the stream.
- Fix HDMI FRL audio enable.
- Fix peak bandwidth measurement sequence.
- Bound the DSC power gating loop by num_dsc.
- Cast DP DTO pixel clock math to avoid overflow and narrowing.
- Use unsigned types for FRL cap check params and HPO read_state.
- Return success status from check_mode_supported.
- Add SPDX license identifier to dcn30_dpp_cm.c.
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Commit c3fb1fb9e65f ("drm/amd/display: Fix warnings") aligned the
signedness of a large number of DC values, but two hunks of the original
change were not carried over:
- struct frl_cap_chk_params_fixed31_32 still declares audio_packet_type,
h_active and h_blank as int. All three only ever hold non-negative
values: h_active and h_blank are HDMI timing quantities counted in
pixels, and audio_packet_type is only compared against the positive
HDMI audio packet type constants 0x02, 0x07, 0x08, 0x09 and 0x0e in
frl_capacity_computations_common().
- hpo_enc3_read_state() still declares pixel_encoding, color_depth and
odm_combine as int and passes their addresses to REG_GET_2()/REG_GET(),
whose generic_reg_get*() backends take uint32_t *. The mismatch is only
hidden by the explicit (uint32_t *) cast inside the REG_GET macros. The
DCN401 equivalent, hpo_enc401_read_state(), already uses uint32_t.
[How]
Widen the three struct fields to unsigned int/uint32_t and the three
locals to uint32_t so the types match how the values are produced and
consumed. No computed value changes.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The dc_fast_update intermediate struct created code duplication and
complexity with multiple classification paths (populate_fast_updates,
fast_nonaddr_updates_exist, full_update_required). This refactoring
simplifies the update classification system by consolidating to a
single path while maintaining compatibility.
[How]
Remove entire dc_fast_update struct and associated helper functions:
- populate_fast_updates
- fast_nonaddr_updates_exist
- full_update_required
Refactor check_update_surfaces_for_stream as the
single classification path with explicit handling for func_shaper,
lut3d_func, cursor_csc_color_matrix_change, and
scaler_sharpener_update. Add a reserved bitfield to the
stream_update_flags union for completeness guards. Extract
dc_check_address_only_update and dc_check_update_surfaces_for_stream
as public.
Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add dcn35_dmub_hw_control_lock() and dcn35_dmub_hw_control_lock_fast(),
a SW lock mechanism to prevent racing between driver and FW.
The helpers are not wired into dcn35_funcs/dcn351_funcs yet, so there is
no functional change: DCN3.5/3.5.1/3.6 keep using the existing inbox1
lock path. Enabling them will come in a follow-up patch.
Reviewed-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Commit 0421fc6ab3a8 ("drm/amd/display: fix __udivdi3 link error") switched
get_dp_dto_frequency_100hz() and dcn401_get_dp_dto_frequency_100hz() to
div_u64() but dropped the original explicit casts, leaving two issues:
- In get_dp_dto_frequency_100hz(), "clock_hz * dp_dto_ref_khz * 10" is
computed in 32-bit unsigned arithmetic (both operands are unsigned int)
before being stored into the u64 temp, so the product can overflow
before it is widened (flagged by Coverity OVERFLOW_BEFORE_WIDEN).
- div_u64() returns a u64 that is assigned directly to the unsigned int
*pixel_clk_100hz, an implicit narrowing conversion that trips
-Wconversion (possible loss of data) on stricter builds.
[How]
Cast clock_hz to unsigned long long so the multiplication is performed in
64-bit, and make the u64 -> unsigned int narrowing explicit with an
(unsigned int) cast on the div_u64() results in both functions. The
computed values are unchanged.
Fixes: 0421fc6ab3a8 ("drm/amd/display: fix __udivdi3 link error")
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: James Lin <PingLei.Lin@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why/How]
The APG_CLOCK_EN bit can stay at 0 in some cases when going between
DPMS off and DPMS on.
Add APG_CLOCK_EN to audio_mute_control functions to make sure it gets
programmed.
Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
DCN42 has 0 bytes allocated for MALL, but this results in a 0 <= 0 comparison in
CalculateMALLUseForStaticScreen(), which blindly returns true.
This causes DML to calculate with is_using_mall_for_ss[n] = true.
Example:
0 + 0 <= 0 -> true
|
v
is_using_mall_for_ss[1] = true
|
v
use_one_row_for_frame[1] = true
PTE_BUFFER_MODE[1] = true
|
v
dpte_row_height : 128 -> 808
dpte_row_width_ub : 196,608 -> 1,204,224
|
+--> DST_Y_PER_PTE_ROW_NOM_L = 808
|
+--> N_groups = ceil(1,204,224 / 65,536 / 2) = 10
|
v
REFCYC_PER_PTE_GROUP_NOM_L = 8416 (0x20E0)
Currently, DML does not plumb out the programming for PTE_BUFFER_MODE and FORCE_ONE_ROW_FOR_FRAME,
but even adding that programming does not enable the mode to work with these values.
The simplest fix is to just block any opportunistic MALL calculations.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Description]
dml21_top_utm_check_mode_supported must return the success status from
the mode support result otherwise the caller will believe that mode
support always returns true. This can cause issues where mode support
returns true, where mode programming returns false.
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for
the output timing generator (OTG). VUPDATE_NO_LOCK is one of them.
To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the
GLOBAL_SYNC_STATUS register.
To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR
bit in the same GLOBAL_SYNC_STATUS register.
The bit sets are done through read/modify/write operations, which are
not atomic. Thus, the following race is possible:
Thread A: IRQ handler:
*HW IRQ fires*
# IRQ disable
val = read(GLOBAL_SYNC_STATUS)
unset(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# ACK reads VUPDATE_NO_LOCK_EN unset
val1 = read(GLOBAL_SYNC_STATUS)
set(val1, VUPDATE_NO_LOCK_CLEAR)
# IRQ enable
val = read(GLOBAL_SYNC_STATUS)
set(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# BAD! clears VUPDATE_NO_LOCK_EN
write(val1, GLOBAL_SYNC_STATUS)
Regarding the tagged Fixes: change, it appears the change made this race
more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source
for vblank handling, a single race on high refresh panels can lead to a
time out.
[How]
The GLOBAL_SYNC_STATUS register is only one example, other IRQ control
registers also share the same scheme. On top of GLOBAL_SYNC_STATUS,
let's clean up those as well.
To keep things simple, Let's atomize the IRQ rmw ops via a single
driver-wide spinlock. Due to the small scope of this lock, it is
unlikely to cause noticeable overhead on top of all the existing locking
within the IRQ set/handle paths.
Since DM is responsible for locking, wrap dc_interrupt_set/ack with the
spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all
references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack
instead.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5616
Fixes: c87e6635d2db ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DCN42B has no MALL, but MALL capabilities are non-zero.
[How]
Zero out MALL capabilities in the dcn42b bounding box.
Reviewed-by: Matthew Stewart <matthew.stewart2@amd.com>
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Gabe Teeger <gabe.teeger@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DCN42B has no MALL, but the resource file advertised MALL and CAB
sizes. SubVP was also enabled even though its phantom surfaces
are allocated in MALL.
[How]
Drop the MALL and SubVP caps, the dml2_options svp_pstate and
mall_cfg setup, and the add_phantom_pipes and
calculate_mall_ways_from_bytes callbacks. Disable SubVP.
Reviewed-by: Matthew Stewart <matthew.stewart2@amd.com>
Signed-off-by: Gabe Teeger <gabe.teeger@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why&How]
dcn30_dpp_cm.c carries the full MIT license text but no SPDX tag. Add
the SPDX-License-Identifier line so the file matches the rest of the
tree.
Reviewed-by: Jun Lei <jun.lei@amd.com>
Signed-off-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
struct dccg has no instance identifier, unlike other DC hardware
blocks. Debug and tracing helpers need one to identify the block.
[How]
Add an inst member to struct dccg and initialize it to 0 in every
dccgX_create(), since there is one DCCG instance per ASIC.
Reviewed-by: Jun Lei <jun.lei@amd.com>
Signed-off-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
