summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd
AgeCommit message (Collapse)Author
2025-11-11drm/amdkfd: relax checks for over allocation of save areaJonathan Kim
Over allocation of save area is not fatal, only under allocation is. ROCm has various components that independently claim authority over save area size. Unless KFD decides to claim single authority, relax size checks. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 15bd4958fe38e763bc17b607ba55155254a01f55) Cc: stable@vger.kernel.org
2025-11-11drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1Sathishkumar S
enable parse_cs callback for JPEG5_0_1. Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 547985579932c1de13f57f8bcf62cd9361b9d3d3) Cc: stable@vger.kernel.org
2025-11-11drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BOSultan Alsawaf
When the BO pointer provided to amdgpu_bo_create_kernel() points to non-NULL, amdgpu_bo_create_kernel() takes it as a hint to pin that address rather than allocate a new BO. This functionality is never desired for allocating ISP buffers. A new BO should always be created when isp_kernel_buffer_alloc() is called, per the description for isp_kernel_buffer_alloc(). Ensure this by zeroing *bo right before the amdgpu_bo_create_kernel() call. Fixes: 55d42f616976 ("drm/amd/amdgpu: Add helper functions for isp buffers") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 73c8c29baac7f0c7e703d92eba009008cbb5228e)
2025-11-11drm/amd/display: Allow VRR params change if unsynced with the streamIvan Lipski
[Why] When changing resolution (e.g., 4K → FHD) in mirror/clone mode with certain monitors, the monitor blanks and loses connection due to an early exit in vrr_settings_require_update(). The function only checks if VRR state, fixed refresh target, or min/max refresh rate range has changed. During mode changes, if the calculated min/max refresh values remain the same even though the stream's v_total changed, the function returns early without updating vrr_params.adjust.v_total_min/max, leaving the monitor's VRR timing parameters unsynced with the new mode, causing it to blank out. [How] Explicitly adjust VRR parameters to the stream's nominal v_total when VRR is supported, but inactive. Fixes: 6d31602a9f57 ("drm/amd/display: more liberal vmin/vmax update for freesync") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 607df8248a011524211ee34850345305a1913f9e)
2025-11-11drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_processJesse.Zhang
Fix a potential deadlock caused by inconsistent spinlock usage between interrupt and process contexts in the userq fence driver. The issue occurs when amdgpu_userq_fence_driver_process() is called from both: - Interrupt context: gfx_v11_0_eop_irq() -> amdgpu_userq_fence_driver_process() - Process context: amdgpu_eviction_fence_suspend_worker() -> amdgpu_userq_fence_driver_force_completion() -> amdgpu_userq_fence_driver_process() In interrupt context, the spinlock was acquired without disabling interrupts, leaving it in {IN-HARDIRQ-W} state. When the same lock is acquired in process context, the kernel detects inconsistent locking since the process context acquisition would enable interrupts while holding a lock previously acquired in interrupt context. Kernel log shows: [ 4039.310790] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 4039.310804] kworker/7:2/409 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 4039.310818] ffff9284e1bed000 (&fence_drv->fence_list_lock){?...}-{3:3}, [ 4039.310993] {IN-HARDIRQ-W} state was registered at: [ 4039.311004] lock_acquire+0xc6/0x300 [ 4039.311018] _raw_spin_lock+0x39/0x80 [ 4039.311031] amdgpu_userq_fence_driver_process.part.0+0x30/0x180 [amdgpu] [ 4039.311146] amdgpu_userq_fence_driver_process+0x17/0x30 [amdgpu] [ 4039.311257] gfx_v11_0_eop_irq+0x132/0x170 [amdgpu] Fix by using spin_lock_irqsave()/spin_unlock_irqrestore() to properly manage interrupt state regardless of calling context. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ded3ad780cf97a04927773c4600823b84f7f3cc2) Cc: stable@vger.kernel.org
2025-11-11drm/amdgpu: jump to the correct label on failurePierre-Eric Pelloux-Prayer
drm_sched_entity_init wasn't called yet, so the only thing to do is to release allocated memory. This doesn't fix any bug since entity is zero allocated and drm_sched_entity_fini does nothing in this case. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.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> (cherry picked from commit ec49374ccb8da86b465beaf09c367f3dfd648d8f)
2025-11-11drm/amdgpu: disable peer-to-peer access for DCC-enabled GC12 VRAM surfacesVitaly Prosyak
Certain multi-GPU configurations (especially GFX12) may hit data corruption when a DCC-compressed VRAM surface is shared across GPUs using peer-to-peer (P2P) DMA transfers. Such surfaces rely on device-local metadata and cannot be safely accessed through a remote GPU’s page tables. Attempting to import a DCC-enabled surface through P2P leads to incorrect rendering or GPU faults. This change disables P2P for DCC-enabled VRAM buffers that are contiguous and allocated on GFX12+ hardware. In these cases, the importer falls back to the standard system-memory path, avoiding invalid access to compressed surfaces. Future work could consider optional migration (VRAM→System→VRAM) if a performance regression is observed when `attach->peer2peer = false`. Tested on: - Dual RX 9700 XT (Navi4x) setup - GNOME and Wayland compositor scenarios - Confirmed no corruption after disabling P2P under these conditions v2: Remove check TTM_PL_VRAM & TTM_PL_FLAG_CONTIGUOUS. v3: simplify for upsteam and fix ip version check (Alex) Suggested-by: Christian König <christian.koenig@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> (cherry picked from commit 9dff2bb709e6fbd97e263fd12bf12802d2b5a0cf) Cc: stable@vger.kernel.org
2025-11-11drm/amdkfd: Fix GPU mappings for APU after prefetchHarish Kasiviswanathan
Fix the following corner case:- Consider a 2M huge page SVM allocation, followed by prefetch call for the first 4K page. The whole range is initially mapped with single PTE. After the prefetch, this range gets split to first page + rest of the pages. Currently, the first page mapping is not updated on MI300A (APU) since page hasn't migrated. However, after range split PTE mapping it not valid. Fix this by forcing page table update for the whole range when prefetch is called. Calling prefetch on APU doesn't improve performance. If all it deteriotes. However, functionality has to be supported. v2: Use apu_prefer_gtt as this issue doesn't apply to APUs with carveout VRAM v3: Simplify by setting the flag for all ASICs as it doesn't affect dGPU v4: Remove v2 and v3 changes. Force update_mapping when range is split at a size that is not aligned to prange granularity Suggested-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Philip Yang<Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/vce1: Workaround PLL timeout on FirePro W9000Timur Kristóf
Sometimes the VCE PLL times out waiting for CTLACK/CTLACK2. When it happens, the VCE still works, but much slower. Observed on a Tahiti GPU, but not all: - FirePro W9000 has the issue - Radeon R9 280X not affected - Radeon HD 7990 not affected As a workaround, on the affected chip just don't put the VCE PLL in sleep mode. Leaving the VCE PLL in bypass mode or reset mode both work. Using bypass mode is simpler. 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>
2025-11-11drm/amdgpu/vce1: Enable VCE1 on Tahiti, Pitcairn, Cape Verde GPUsTimur Kristóf
Add the VCE1 IP block to the SI GPUs that have it. Advertise the encoder capabilities corresponding to VCE1, so the userspace applications can detect and use it. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Co-developed-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/pm/si: Hook up VCE1 to SI DPMTimur Kristóf
On SI GPUs, the SMC needs to be aware of whether or not the VCE1 is used. The VCE1 is enabled/disabled through the DPM code. Also print VCE clocks in amdgpu_pm_info. Users can inspect the current power state using: cat /sys/kernel/debug/dri/<card>/amdgpu_pm_info 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>
2025-11-11drm/amdgpu/vce1: Ensure VCPU BO is in lower 32-bit address space (v3)Timur Kristóf
Based on research and ideas by Alexandre and Christian. VCE1 actually executes its code from the VCPU BO. Due to various hardware limitations, the VCE1 requires the VCPU BO to be in the low 32 bit address range. However, VRAM is typically mapped at the high address range, which means the VCPU can't access VRAM through the FB aperture. To solve this, we write a few page table entries to map the VCPU BO in the GART address range. And we make sure that the GART is located at the low address range. That way the VCE1 can access the VCPU BO. v2: - Adjust to v2 of the GART helper commit. - Add empty line to multi-line comment. v3: - Instead of relying on gmc_v6 to set the GART space before GTT, add a new function amdgpu_vce_required_gart_pages() which is called from amdgpu_gtt_mgr_init() directly. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Co-developed-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu: Check if AID is active before accessLijo Lazar
Access XGMI registers only if AID is active. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/vce1: Implement VCE1 IP block (v2)Timur Kristóf
Implement the necessary functionality to support the VCE1. This implementation is based on: - VCE2 code from amdgpu - VCE1 code from radeon (the old driver) - Some trial and error A subsequent commit will ensure correct mapping for the VCPU BO, which will make this actually work. v2: - Use memset_io more. - Use memcpy_toio more. - Remove __func__ from warnings. - Don't reserve and map the VCPU BO anymore. - Add empty line to multi-line comments Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Co-developed-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/vce1: Load VCE1 firmwareTimur Kristóf
Load VCE1 firmware using amdgpu_ucode_request, just like it is done for other VCE versions. All SI chips share the same VCE1 firmware file: vce_1_0_0.bin which will be sent to linux-firmware soon. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Co-developed-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/vce1: Clean up register definitionsTimur Kristóf
The sid.h header contained some VCE1 register definitions, but they were using byte offsets (probably copied from the old radeon driver). Move all of these to the proper VCE1 headers and ensure they are in dword offsets. Also add the register definitions that we need for the firmware validation mechanism in VCE1. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Co-developed-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/vce: Clear VCPU BO, don't unmap/unreserve (v4)Timur Kristóf
The VCPU BO doesn't only contain the VCE firmware but also other ranges that the VCE uses for its stack and data. Let's initialize this to zero to avoid having garbage in the VCPU BO. Additionally, don't unmap/unreserve the VCPU BO. The VCPU BO needs to stay at the same location before and after sleep/resume because the FW code is not relocatable once it's started. 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>
2025-11-11drm/amdgpu/vce: Move firmware load to amdgpu_vce_early_initTimur Kristóf
Try to load the VCE firmware at early_init. When the correct firmware is not found, return -ENOENT. This way, the driver initialization will complete even without VCE, and the GPU will be functional, albeit without video encoding capabilities. This is necessary because we are planning to add support for the VCE1, and AMD hasn't yet publised the correct firmware for this version. So we need to anticipate that users will try to boot amdgpu on SI GPUs without the correct VCE1 firmware present on their system. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/ttm: Use GART helper to map VRAM pages (v2)Timur Kristóf
Use the GART helper function introduced in the previous commit to map the VRAM pages of the transfer window to GART. No functional changes, just code cleanup. Split this into a separate commit to make it easier to bisect, in case there are problems in the future. 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>
2025-11-11drm/amdkfd: relax checks for over allocation of save areaJonathan Kim
Over allocation of save area is not fatal, only under allocation is. ROCm has various components that independently claim authority over save area size. Unless KFD decides to claim single authority, relax size checks. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu: Use DC by default on SI dGPUsTimur Kristóf
Now that DC supports analog connectors, it has reached feature parity with the legacy non-DC display driver on SI dGPUs. Use the DC display driver by default on SI dGPUs, unless it is explicitly disabled using the amdgpu.dc=0 module parameter. DC brings proper support for DP/HDMI audio, DP MST, 10-bit colors, some HDR features, atomic modesetting, etc. Also clarify the comment about what is missing to have full DC support for CIK APUs. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/gart: Add helper to bind VRAM pages (v2)Timur Kristóf
Binds pages that located in VRAM to the GART page table. Useful when a kernel BO is located in VRAM but needs to be accessed from the GART address space, for example to give a kernel BO a 32-bit address when GART is placed in LOW address space. v2: - Refactor function to be more reusable 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>
2025-11-11drm/amdgpu/gmc6: Place gart at low address rangeTimur Kristóf
Instead of using a best-fit algorithm to determine which part of the VMID 0 address space to use for GART, always use the low address range. A subsequent commit will use this to map the VCPU BO in GART for the VCE1 IP block. Split this into a separate patch to make it easier to bisect, in case there are any errors in the future. 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>
2025-11-11drm/amdgpu/userqueue: Remove duplicate amdgpu_reset.h headerJiapeng Chong
./drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c: amdgpu_reset.h is included more than once. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=26930 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu: resume MES scheduling after user queue hang detection and recoveryJesse.Zhang
This patch ensures the Micro-Engine Scheduler (MES) is properly resumed after detecting and recovering from a user queue hang condition. Key changes: 1. Track when a hung user queue is detected using found_hung_queue flag 2. Call amdgpu_mes_resume() to restart MES scheduling after completing the hang recovery process 3. This complements the existing recovery steps (fence force completion and device wedging) by ensuring the scheduler can process new work Without this resume call, the MES scheduler may remain in a paused state even after the hung queue has been handled, preventing newly submitted work from being processed and leading to system stalls. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1Sathishkumar S
enable parse_cs callback for JPEG5_0_1. Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/pm: Remove power2_average nodeAsad Kamal
SOC power consumption is reported by power1_average. power2_cap_default/min/max only represent second level limits and don't represent a different type of power or power consumption by a subsection of the SOC. Therefore power2_average does not serve any purpose and hence removing power2_average sysfs node 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>
2025-11-11drm/amd/pm: Enable ppt1 caps for smu_v13_0_12Asad Kamal
Enable ppt1 caps to fetch and configure ppt1 for smu_v13_0_12 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>
2025-11-11drm/amd/pm: Expose ppt1 limit for gc_v9_5_0Asad Kamal
Expose power2_cap hwmon node for retrieving and configuring ppt1 limit on supported boards for gc_v9_5_0 v2: Remove version check (Lijo) v3: Remove power2_average (Lijo) v4: Put back power2_average, will be removed separately (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>
2025-11-11drm/amd/pm: Add ppt1 support for smu_v13_0_12Asad Kamal
Add support to configure and retrieve ppt1 limit for smu_v13_0_12 v2: Add update_caps function and update ppt1 cap based on max ppt1 value, optimize the return values (Lijo) v3: Add Null ptr check, return not supported in case of invalid level/type (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>
2025-11-11drm/amd/pm: Update pmfw headers for smu_v13_0_12Asad Kamal
Update pmfw headers for smu_v13_0_12 to include ppt1 messages and static parameters 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>
2025-11-11drm/amd/display: Add kdoc params/returns in dc/link detection helpersSrinivasan Shanmugam
The link detection helpers in dc/link/link_detection.c were missing kdoc annotations for parameters and return values. Fixes the below with gcc W=1: ...link_detection.c:872 parameter 'edid_header' not described ...link_detection.c:890 parameter 'link' not described ...link_detection.c:914 parameter 'link' not described ...link_detection.c:1355 parameter 'link' not described ...link_detection.c:1355 parameter 'type' not described Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Fix annotations for connector poll/detect parametersSrinivasan Shanmugam
Adds the missing @aconnector, @connector, and @force descriptions: @aconnector – This is the DM (Display Manager) connector. It gives access to the DRM connector, the DC link, and hotplug/poll state. The code uses it to check the link, update the sink, and manage connector state changes. @connector – This is the main DRM connector given by the DRM core. Inside the detect function, it is converted to amdgpu_dm_connector so we can run DC link detection, either light or full. @force – This flag tells the function whether to run a full detect again. If false, we avoid heavy DAC load detect steps to prevent flicker. If true, we force a re-detect even when we normally skip it. Fixes the below with gcc W=1: function param 'aconnector' not described in 'amdgpu_dm_connector_poll' function param 'force' not described in 'amdgpu_dm_connector_poll' function param 'connector' not described in 'amdgpu_dm_connector_detect' function param 'force' not described in 'amdgpu_dm_connector_detect' Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BOSultan Alsawaf
When the BO pointer provided to amdgpu_bo_create_kernel() points to non-NULL, amdgpu_bo_create_kernel() takes it as a hint to pin that address rather than allocate a new BO. This functionality is never desired for allocating ISP buffers. A new BO should always be created when isp_kernel_buffer_alloc() is called, per the description for isp_kernel_buffer_alloc(). Ensure this by zeroing *bo right before the amdgpu_bo_create_kernel() call. Fixes: 55d42f616976 ("drm/amd/amdgpu: Add helper functions for isp buffers") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Promote DC to 3.2.358Taimur Hassan
Summary: * Enable VRR when unsynced with the stream * Refactor DSC cap calculation for dcn35 * Add debug log for power feature * Fix fill latency issue * Do not initialize LSDMA if it is not supported by DMU Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: [FW Promotion] Release 0.1.35.0Taimur Hassan
Summary for changes in firmware: * Use panel_inst instead of otg_inst when getting fw state * Contrast strength improves when HDR desktop mode * Ensure pipes have no outstanding HUBP requests prior to IPS RCG entry * Check for vm request and vm idle status in IPS1/2 entry sequence Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Refactor HDCP Status Log FormatWenjing Liu
Add missing part for drm/amd/display: fw locality check refactors Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: dynamically clock gate before and after prefetchLeo Chen
[Why] An invalidation request arriving during prefetch can potentially hang the system if dynamic clock gating is enabled and memory power requests are disabled. [How] • Disable clock gating and enable memory power requests for the duration of the prefetch. • Turn on clock gating and disable memory power requests again after prefetch is complete. Limit the scope for DCN35 and DCN42 only. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Revert in_transfer_func_change to MEDDominik Kaszewski
[Why] Last commit accidentally changed handling of in_transfer_func_change from MED to FAST. [How] * Revert the line. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dominik Kaszewski <dominik.kaszewski@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: To support Replay frame skip modeChuntao Tso
[Why & How] The change is to optimize the Replay power saving by reducing the refresh rate with frame skipping mode Reviewed-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Chuntao Tso <chunttso@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Change lock descriptor valuesDominik Kaszewski
[Why] Review of usage scenarios requires dc_lock_descriptor modification. [How] Replace STATE/LINK/STREAM/PLANE with GLOBAL/STREAM/LINK, where the first means all streams to be locked. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dominik Kaszewski <dominik.kaszewski@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: refactor DSC cap calculation for dcn35Mohit Bawa
why: dcn35 currently uses a hardcoded DSC display clock value which is incorrect for some asic types. Newer DCN versions retrieve dsc display clock from clk_mgr. The same can be done for dcn35. how: Refactor the DSC cap calculation using pre-existing logic. Handle ODM combine requirements in dc_dsc.c. Replace hardcoded display clock with actual value retrieved from clk_mgr. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Mohit Bawa <Mohit.Bawa@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Add new SMART POWER OLED interfacesIan Chen
[why && how] To optimize power consumption on certain OLED LED panels by sending MaxCLL per frame to TCON Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Ian Chen <ian.chen@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Add interface to capture power feature status for debug loggingGeorge Shen
[Why] The status of various power features is often important information when debugging certain issues, such as underflow. This info helps to narrow down the potential sources of errors. [How] Add dc interface to capture power feature enablement status. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: George Shen <george.shen@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Allow VRR params change if unsynced with the streamIvan Lipski
[Why] When changing resolution (e.g., 4K → FHD) in mirror/clone mode with certain monitors, the monitor blanks and loses connection due to an early exit in vrr_settings_require_update(). The function only checks if VRR state, fixed refresh target, or min/max refresh rate range has changed. During mode changes, if the calculated min/max refresh values remain the same even though the stream's v_total changed, the function returns early without updating vrr_params.adjust.v_total_min/max, leaving the monitor's VRR timing parameters unsynced with the new mode, causing it to blank out. [How] Explicitly adjust VRR parameters to the stream's nominal v_total when VRR is supported, but inactive. Fixes: 6d31602a9f57 ("drm/amd/display: more liberal vmin/vmax update for freesync") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Fix index bug for fill latencyDillon Varone
[WHY&HOW] This array should be indexed by pstate type followed by plane index. Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/display: Only initialize LSDMA if it is supported in DMUAlvin Lee
Need to check caps flag to determine whether LSDMA is supported in DMU Reviewed-by: Rafal Ostrowski <rafal.ostrowski@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amd/pm: remove unnecessary prints for smu busyGangliang Xie
smu busy is a normal case when calling SMU_MSG_GetBadPageCount, so no need to print error status at each time.Instead, only print error status when timeout given by user is reached. Signed-off-by: Gangliang Xie <ganglxie@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu: optimize timeout implemention in ras_eeprom_update_record_numTao Zhou
The busy status returned by ras_eeprom_update_record_num may not be an error, increase timeout to exclude false busy status. Also add more comments to make the code readable. v2: define a macro for the timeout value. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-11drm/amdgpu: add RAS bad page threshold handling for PMFW manages eepromTao Zhou
Check if bad page threshold is reached and take actions accordingly. v2: remove rma message sent to smu when pmfw manages eeprom. v3: add null pointer check for con. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>