| Age | Commit message (Collapse) | Author |
|---|
|
When adding the GSP unload capability, we introduced `BootUnloadGuard`
to automatically call `Gsp::unload` whenever an error occurred during
the boot process, in order to try to reset the GSP to a valid state.
This approach is not well-suited to the errors that may occur in HALs:
by definition, an error occurring in the HAL means that the GSP is not
booted; yet the first thing that `Gsp::unload` does is queue a shutdown
message to the GSP, which will inevitably result in a timeout when done
from a HAL.
Furthermore, `BootUnloadGuard` is problematic because it holds
additional references to the boot context, notably the `Falcon`s. These
extra references stand in the way of making some of the `Falcon`'s
methods mutable, since those methods would require exclusive access. As
this behavior is only needed in one place, introducing dedicated types
for it is distracting and unnecessary.
Thus, remove `BootUnloadGuard` and adopt a two-level error handling
strategy:
- HALs are free to handle their errors as they see fit (most likely, by
running their unload bundle if it is ready by the time of the error),
- `Gsp::boot` uses a `ScopeGuard` that runs `Gsp::unload`, since the
GSP should be up and running by the time `GspHal::boot` has returned.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-3-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The sequence is currently stored in the `GspSequencer` even though its
lifetime is limited to `GspSequencer::run`. This object-oriented design
does not play well with the borrow-checker, as `GspSequencer::iter`
borrows the `GspSequencer`, which makes it difficult to introduce
mutable references in `GspBootContext`, as we want to do in order to
make the `Falcon` references mutable.
Thus, store the sequence locally in `GspSequencer::run`, and move
iterator creation to `GspSeqIter::new` so it no longer needs to borrow
the whole `GspSequencer`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-2-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
`GspBootContext` contains all the resources currently carried by
`GspSequencerParams`, so replace the latter with the former for better
integration with the boot process and less code.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-1-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
xe_pt_update_ops_init() fails to reset current_op to 0. On the
vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside
the xe_validation_guard() / drm_exec_until_all_locked() loop. When
that loop retries due to lock contention or OOM eviction
(drm_exec_retry_on_contention() / xe_validation_retry_on_oom()),
xe_pt_update_ops_prepare() runs again on the same vops, and each
call to bind_op_prepare() increments current_op without resetting it.
After N retries current_op exceeds the array size allocated by
xe_vma_ops_alloc(), causing an out-of-bounds write into
SLUB-poisoned memory and a subsequent UAF crash in
xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind.
Also reset needs_svm_lock and needs_invalidation which are derived in
the same prepare pass and would otherwise cause wrong migrate ops
selection and redundant TLB invalidation on retry.
Fix this by resetting current_op, needs_svm_lock and needs_invalidation
in xe_pt_update_ops_init().
v2 (Matt):
- Add details in commit message.
- Add Fixes tag and Cc to stable@vger.kernel.org
Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job")
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Cc: stable@vger.kernel.org
Assisted-by: GitHub-Copilot:claude-sonnet-4.6
Signed-off-by: Zongyao Bai <zongyao.bai@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260714232433.2737533-1-zongyao.bai@intel.com
|
|
tc_aux_transfer() clamps an AUX read to the payload limit:
size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size);
After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:
if (size)
size = FIELD_GET(AUX_BYTES, auxstatus);
AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.
The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge:
ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer").
Fixes: 12dfe7c4d9c5 ("drm/bridge: tc358767: Use reported AUX transfer size")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260701064440.1541418-1-maoyixie.tju@gmail.com
|
|
Starting on LNL the WOPCM size is 8MB instead of 4, so we need to avoid
using the [0, 8MB) range of the GGTT as that can be unaccessible from
the microcontrollers.
Note that the proper long-term fix here is to read the WOPCM size from
the HW, but that is a more serious rework that would be difficult to
backport, so we can do that as a follow-up.
Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260713221758.3285744-2-daniele.ceraolospurio@intel.com
|
|
Implement the MES gang contex alloc and free heplers.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Some AMD APU multi-function devices expose an integrated USB xHCI
controller. In some circumstances (such as larger VRAM), the PM core
can resume can fail when the xHCI controller is resuming in parallel
with the GPU/display function.
On affected systems, the xHCI controller can complete pci_pm_resume
and start resuming USB devices while the GPU is still in its much
longer resume path. This race condition leads to USB device resume
failures followed by:
xhci_hcd ...: xHCI host not responding to stop endpoint command
xhci_hcd ...: HC died; cleaning up
Create a device link from any xHCI controller sharing the same PCIe
root port as the APU display function. The link uses DL_FLAG_STATELESS
and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before
the xHCI controller begins resuming USB devices.
This device link is done specifically in amdgpu so that if the
platform firmware has been modified such that this issue doesn't happen
the version can be detected and the workaround skipped.
Suggested-by: Aaron Ma <aaron.ma@canonical.com>
Reported-by: mrh@frame.work
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Alexander F <superveridical@gmail.com>
Tested-by: Francis DB <francisdb@gmail.com>
Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DCN42B enables DML2 and DML21 by default and defines
dcn42b_prepare_mcache_programming(), but the resource function table only
wires the callback when CONFIG_DRM_AMD_DC_DML21 is defined.
There is no in-tree Kconfig symbol named DRM_AMD_DC_DML21, so the
preprocessor always removes the callback entry. Sibling DCN42 and DCN401
resource tables wire their prepare_mcache_programming callbacks
unconditionally, and the core DC code already checks whether the callback
pointer is present before calling it.
Remove the stale guard so DCN42B exposes the callback relation that its
source and DML21 build world already provide.
This is an RFC patch draft from static conditional callback legality
auditing. It needs AMD display maintainer review before submission as a
final fix.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In dm_update_crtc_state(), the skip_modeset path releases new_stream
via dc_stream_release() but does not set the pointer to NULL.
If a later error (e.g., color management failure) triggers the fail
label, the error path calls dc_stream_release() again on the same
dangling pointer, causing a double release and potential use-after-free.
Fix this by setting new_stream to NULL after the initial release.
Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
link_dp_irq_handler.c includes "link_dp_panel_replay.h" twice. Drop the
redundant second include; this is a non-functional cleanup flagged by
scripts/checkincludes.pl.
Fixes: 1e5cd4adfc54 ("drm/amd/display: move panel replay out from edp")
Signed-off-by: Anas Khan <anxkhn28@gmail.com>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
dccg35_set_hdmistreamclk_src_new() updates HDMISTREAMCLK_CNTL but
passes DPSTREAMCLK0_SRC_SEL as the field identifier in the second
REG_UPDATE_2 slot.
The current behavior is harmless on DCN3.5 because both fields share the
same bit layout, but it is still incorrect and could break on future
hardware revisions.
Fixes: d36771a03412 ("drm/amd/display: Add DCCG DIO, HPO, OPP, and OPTC support for FRL")
Signed-off-by: Dyllan Kobal <dyllan.kobal@zetier.com>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The final check of hubp for NULL covers all remaining lines of code, since
the value of hubp does not change until the end of the method.
This check is redundant because hubp1 is already dereferenced within the
macro.
If it were NULL, the program would have already failed to proceed.
Remove the left part of the expression with the logical "&&".
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: be1fb44389ca ("drm/amd/display: Check null pointers before used").
Signed-off-by: Gleb Markov <markov.gi@npc-ksb.ru>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
mod_power_create()
kfree() safely handles NULL pointers, so there is no need to check for
NULL before calling kfree().
Remove redundant NULL check.
Found by Coccinelle ifnullfree script.
Signed-off-by: Ziran Zhang <zhangcoder@yeah.net>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that
advertises AUX/DPCD backlight control, so amdgpu's automatic detection
(amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight
path has no effect: brightness writes are accepted but the panel level
never changes, the display is stuck at a fixed brightness and
max_brightness is reported as a bogus 511000. As a result neither the
desktop brightness slider nor the brightness hotkeys do anything.
Forcing PWM backlight (amdgpu.backlight=0) restores working control:
max_brightness becomes 65535 and the level tracks writes. This has long
been applied by users as a manual kernel-parameter workaround.
Extend the generic panel backlight quirk with a force_pwm flag, add an
entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu
disable AUX backlight (use PWM) when the quirk matches and the user
lets the driver auto-select the backlight type.
Signed-off-by: Alessandro Rinaldi <ale@alerinaldi.it>
Tested-by: Alessandro Rinaldi <ale@alerinaldi.it>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use the X86_MATCH_VENDOR_FAM() and X86_MATCH_VENDOR_FAM_MODEL() macros
to make the quirks for dynamic speed switching more scalable.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260713172431.1599801-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The change referenced by the Fixes tag releases the HIQ SDMA MQD trunk
buffer when device_queue_manager_init() fails after it has been
allocated.
However, the same failure path can also be reached after
init_mqd_managers() has succeeded. At that point dqm->mqd_mgrs[] contains
per-type MQD manager objects owned by the device queue manager. The
normal teardown path frees those objects from uninitialize(), but the
initialization error path only frees dqm itself.
Free the MQD managers from the initialization error path as well. This is
safe for earlier failures because dqm is zeroed when allocated and
init_mqd_managers() clears the entries it rolls back internally.
Fixes: b7cccc8286bb ("drm/amdkfd: fix a memory leak in device_queue_manager_init()")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Allow using multiple SDMA schedulers only on GPUs where
we are allowed to do concurrent VM flushes.
This consideration is necessary because all GART windows
are mapped in VMID 0 (the kernel VMID) so each buffer
entity would flush VMID 0 concurrently.
Practically this means that we can't use multiple SDMA
engines for TTM on GFX6-8 and Navi 1x.
Fixes: 01c836788b37 ("drm/amdgpu: pass all the sdma scheds to amdgpu_mman")
Fixes: e4029f7a9474 ("drm/amdgpu: only use working sdma schedulers for ttm")
Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_dm_audio_eld_notify() is currently only called in atomic commits.
This results in the state of the HDA driver never getting updated when
an audio sink is removed and an atomic commit never comes. (eg the HDMI
audio jack switch in ALSA stays 'on' after the HDMI cable is
disconnected if no other display is connected to cause the compositor to
submit an atomic commit)
Call amdgpu_dm_audio_eld_notify() in
amdgpu_dm_update_connector_after_detect() when a sink is no longer
available to ensure that the HDA driver always gets notified on
disconnect regardless of atomic commits.
Assisted-by: Copilot:claude-sonnet-4.6
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
While at it, remove redundant error message - request_firmware() will
log a failure anyway.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Make the lines greppable by removing an extra EOL and report the
status only once - after the reply is detected.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The XGMI reset-on-init path can run while the device is still at the
minimal init level, such as during an NPS memory partition switch. In
that flow the normal RAS IP block hw_init is skipped, so unified RAS
is not enabled when the early CPER initialization is attempted, leaving
CPER disabled for the rest of the device's lifetime.
Resume RAS after the XGMI reset-on-init completes. Once the RAS manager
resume succeeds, the RAS resume wrapper performs deferred CPER
initialization, keeping the path a no-op for devices where CPER was
already initialized.
Keep the deferred CPER retry and its debugfs registration together in
the CPER helper. The normal debugfs ring walk skips the CPER ring until
CPER is enabled, so the ring debugfs entry is created either by the
deferred helper when debugfs is already available or by the normal
debugfs walk.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There were two mistakes in the previous implementation:
The check for AutomaticDCTransition should be inverted.
We recently learned that the kernel should send
PPSMC_MSG_RunningOnAC when the flag is set, and not the
other way around.
The clocks also need to be recomputed, because the code in
the smu7_apply_state_adjust_rules() function selects
different limits on AC and DC.
Fixes: 96da0d86614e ("drm/amd/pm/smu7: Notify SMU7 of DC->AC switch")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
3 fields in struct amd_ip_funcs have been deleted, so also delete the
kernel-doc comments for them to avoid warnings:
WARNING: ../drivers/gpu/drm/amd/include/amd_shared.h:481 Excess struct member 'check_soft_reset' description in 'amd_ip_funcs'
WARNING: ../drivers/gpu/drm/amd/include/amd_shared.h:481 Excess struct member 'pre_soft_reset' description in 'amd_ip_funcs'
WARNING: ../drivers/gpu/drm/amd/include/amd_shared.h:481 Excess struct member 'post_soft_reset' description in 'amd_ip_funcs'
Fixes: 947e46eb2fb9 ("drm/amdgpu: Delete check_soft_reset() from amd_ip_funcs")
Fixes: b7500532e12b ("drm/amdgpu: Delete pre/post_soft_reset() from amd_ip_funcs")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We can't print the IP block name when the IP block is NULL.
Note that it should never be NULL, the only way that
can happen is when amdgpu_ip_from_ring() is missing the
given ring type. The check is just there to be sure.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202607031711.yLwFhGfp-lkp@intel.com/
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Simple KMS helpers are deprecated because they introduce an unnecessary
intermediate layer between atomic modesetting and the DRM driver.
Inline the functionality of drm_simple_encoder_init() to remove
dependencies on these deprecated helpers.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit 055a40c32f3a ("drm/amd/pm: Use uploaded size for legacy custom
PPTable") changed pp_dpm_set_pp_table() to kmemdup the uploaded buffer
directly and set soft_pp_table_size to the uploaded size. As a result
soft_pp_table now points to an allocation completely outside adev->bios,
making the pp_end > bios_end check in pp_entries_max() likely true for
custom PP tables — returning 0 and breaking PP table overrides via sysfs.
Fixes: c42871ba4833 ("drm/amdgpu/pm: add pp_entries_max() helper")
Reported-by: John Olender <john.olender@gmail.com>
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Tested-by: John Olender <john.olender@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Widen pcie_bandwidth_inst from U32 to U64 to be consistent with
the smu_v13_0_6 definition.
v2: Remove percent conversion (Lijo)
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Update two cases in the smu_v13_0_6 GPU metrics accumulated
counter field definition
Widen the following fields from U32 to U64 to prevent counter
wrap-around and match smu_v15_0_8 field sizes:
- prochot_residency_acc
- ppt_residency_acc
- socket_thm_residency_acc
- vr_thm_residency_acc
- hbm_thm_residency_acc
- gfx_activity_acc
- mem_activity_acc
- pcie_nak_sent_count_acc
- pcie_nak_rcvd_count_acc
- pcie_lc_perf_other_end_recovery
Correct the unit annotation from PERCENT to NONE for accumulated
counter fields which are dimensionless hardware counters and carry
no inherent unit:
- gfx_activity_acc
- mem_activity_acc
- pcie_bandwidth_acc
- gfx_busy_acc
v2: remove percent unit (Lijo)
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Setup the MES_API_QUERY_MES__GET_CTX_ARRAY_SIZE MES firmware
command request, and get the MES11 process/gang contex size.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
In mes_v11_0_unmap_legacy_queue(), set
remove_queue_after_reset=1 for RESET_QUEUES.
The queue may already be MMIO-reset. This flag
tells MES to drop internal queue state directly
instead of issuing another CP unmap flow, reducing
timeout risk during recovery.
Reviewed-by: Amber Lin <amber.lin@amd.com>
Suggested-by: Shaoyun Liu <shaoyun.liu@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
AMD Ryzen Pinnacle Ridge (Zen+, family 0x17 model 0x08) CPUs have
PCI controllers that don't support PCIe dynamic speed switching,
causing system freezes during GPU initialization when enabled.
Disable dynamic speed switching when this CPU is detected.
Assisted-by: Claude:sonnet
Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5436
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Link: https://patch.msgid.link/20260709031520.841611-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We need the fence to reemit the gds switch or spm update
after a queue reset.
Fixes: a17ef941212b ("drm/amdgpu: rework ring reset backup and reemit v9")
Cc: timur.kristof@gmail.com
Cc: christian.koenig@amd.com
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add jpeg_busy and vcn_busy population to smu_v15_0_8 gpu metrics
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There were two mistakes in the previous implementation:
The check for ATOM_PP_PLATFORM_CAP_HARDWAREDC should be
inverted. We recently learned that the kernel should send
PPSMC_MSG_RunningOnAC when the flag is set, and not the
other way around.
The clocks also need to be recomputed, because the code in
the si_apply_state_adjust_rules() function selects different
limits on AC and DC.
Fixes: 2d071f6457af ("drm/amd/pm/si: Notify the SMC when switching to AC")
Tested-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When DPM is turned off with the amdgpu.dpm=0 module parameter,
the thermal work queue isn't initialized so we shouldn't
schedule any work on it.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The KUnit exported helpers
amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers()
amdgpu_dm_plane_fill_gfx12_plane_attributes_from_modifiers()
exceed MODULE_NAME_LEN and cause modpost to fail with:
ERROR: modpost: too long symbol
"amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers"
Shorten the helper names while preserving their functionality.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Link: https://lore.kernel.org/all/fde3656e-9e22-4e4c-937f-7e8cb918da6b@linux.ibm.com/
Signed-off-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital
DIG stream encoders plus one analog DAC encoder. When assigning a stream
encoder for a second DisplayPort MST stream, if the preferred digital
encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()
falls back to the first free pool entry. That entry may be the analog
encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.
The subsequent atomic commit then dereferences NULL function pointers in
link_set_dpms_on() and crashes.
Skip encoders without dp_set_stream_attribute when the stream uses a DP
signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST
fallback path instead of checking only the link connector signal.
Tested on:
- GPU: AMD Radeon R7 260X (Bonaire / DCE8)
- Board: Supermicro C9X299-PG300
- Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot
- Kernel: 7.1.3 (issue observed since 6.19)
- Result: kernel oops without patch; dual monitors stable with patch
Signed-off-by: Andriy Korud <a.korud@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5162
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Always set native cursor mode when the CRTC is disabled,
to make sure it doesn't cause atomic commits to fail when
they are trying to disable the CRTC.
Fixes: 41af6215cdbc ("drm/amd/display: Reject cursor plane on DCE when scaled differently than primary")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5432
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Michel Dänzer <michel.daenzer@mailbox.org>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The old radeon driver has a documented workaround in ci_dpm.c
which claims that Bonaire 0x6658 with old memory controller
firmware is unstable with MCLK DPM, so as a precaution I
disabled MCLK DPM on this ASIC in amdgpu.
Note that the old MC firmware is not actually used with
amdgpu, but in theory it's possible that the VBIOS sets
up the ASIC with an old MC firmware that is already running
when amdgpu initializes (in which case amdgpu doesn't
load its own firmware).
What I expected to happen is that the GPU would simply use
its maximum memory clock, and indeed this is what seemed
to happen according to amdgpu_pm_info which reads the
current MCLK value from the SMU.
However, some users reported a huge perf regression
and upon a closer look it seems that the GPU seems to
not actually use the highest MCLK value, despite the SMU
reporting that it does.
Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
because that still hangs if we enable it.
Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When compiling the AMDGPU display driver for 32-bit architectures,
the linker reports undefined reference to `__udivdi3` in functions
get_dp_dto_frequency_100hz() and dcn401_get_dp_dto_frequency_100hz().
This is because the code uses 64-bit division (/) on 32-bit systems,
which GCC cannot handle directly and instead tries to call the missing
__udivdi3 helper function.
Replace the raw division with div_u64(), the kernel's standard 64-bit
division helper, to avoid the link error.
Signed-off-by: Linlin Yang <yanglinlin@kylinos.cn>
Reported-by: k2ci <kernel-bot@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Currently the contents of IBs are abruptly cut off and don't
show the full contents. This patch makes sure to reserve
space for those contents too so they may be printed.
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>
|
|
These are in the dmesg logs but are missing from devcoredumps.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Now that proper fixes have been found, let's revert this workaround.
This reverts commit a1fc7bf6677eb547167cb72b3bcafdc34b976692.
Tested-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
After unifying DCN interrupt sources under VUPDATE_NO_LOCK, we have two
remaining issues to clean up:
1. On DCN, flip completion is now delivered from VUPDATE_NO_LOCK
(dm_crtc_high_irq_handler) instead of GRPH_PFLIP. But VUPDATE_NO_LOCK
fires every frame, regardless of whether a flip has latched.
2. There is a window during commit where a flip is armed (pflip_status =
SUBMITTED) but not yet programmed into HW. If the VUPDATE_NO_LOCK
fires in that window, its handler would deliver a flip event to
userspace before HW has latched to it. If userspace then renders to
what it believes is now the back buffer (but HW is still latched to
it!), it will cause display corruption. This issue seemed to have
been introduced by:
commit 1159898a88db ("drm/amd/display: Handle commit plane with no FB.")
Enabling replay or psr extended the duration of this window, and
hence made corruption more likely to be observed.
[How]
* Move acrtc->event/pflip_status arming to after
update_planes_and_stream_adapter() has programmed the flip into HW.
This closes the window where pflip_status is SUBMITTED but the flip is
not yet programmed.
* Add dc_get_flip_pending_on_otg(), which reads the HUBP flip-pending
status straight from HW for the pipe(s) bound to an OTG instance. It
is keyed only by otg_inst and does not take or mutate a
dc_plane_state, so it is safe to call from the OTG interrupt handler
without racing a concurrent commit that may be modifying plane state.
* Optimistically query for flip-pending after programming, in the event
that HW latched to the new fb between programming start and arming
event. If it latched, send the vblank event immediately, rather than
wait for the next vblank IRQ.
* In the VUPDATE_NO_LOCK handler, only deliver flip completion once
dc_get_flip_pending_on_otg() reports the flip is no longer pending.
Otherwise leave the flip armed and retry on the next vupdate.
* For DCE, maintain the existing behavior of arming flips before
programming, and relying on GRPH_FLIP to fire at HW latch.
v2:
* Drop flip_programmed completion object, instead move
event/pflip_status arming after programming.
* For DCN, optimistically query for flip pending immediately after
programming, and if it latched, send event right away.
v3:
* Fix event timestamps on optimistic flip latch detection, where it's
possible for it to run *before* the vupdate IRQ updates the timestamp.
* Add more docstrings for DCN vblank handling.
* Clean up if conditions in dm_arm_vblank_event().
* Code style cleanup on braces surrounding multi-line statements.
Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations")
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141
Assisted-by: Copilot:claude-opus-4.8
Tested-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The VFCT path accepted whatever kmemdup() returned without checking
that the copied image is a valid VBIOS. Every other radeon BIOS
fetch path verifies the 0x55 0xaa signature before trusting the
image; the VFCT path is the odd one out.
Check the signature after copying the image and reject it (freeing
the buffer) if it does not match, matching the amdgpu VFCT path
which validates via check_atom_bios().
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260708193518.702584-6-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On systems where PCI bus renumbering occurs (e.g. pci=realloc,
resource conflicts), the runtime bus number may differ from the
BIOS POST bus number recorded in the VFCT table. This causes
radeon_acpi_vfct_bios() to fail finding the VBIOS even though
the correct device entry exists.
Introduce radeon_acpi_vfct_match() which treats the bus number
as a soft filter: vendor/device/function identity is the hard
requirement, while exact bus match is the preferred path. When
bus numbers disagree but device identity matches, accept the
VFCT entry and log a dev_notice for diagnostics. This mirrors the
equivalent amdgpu change.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260708193518.702584-5-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Clean up radeon_acpi_vfct_bios() logging:
- Replace DRM_ERROR with dev_warn tied to the PCI device
- Use unsigned int rather than bare unsigned for the offset
A malformed or missing VFCT table is not fatal: radeon falls back
to the other BIOS fetch methods, so warn rather than error on these
paths.
The goto out label is retained: acpi_get_table() takes a reference on
the table (incrementing its validation_count and mapping it), which
must be released with a paired acpi_put_table() on every exit path.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260708193518.702584-4-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
