linux/drivers/gpu/drm/amd/display/dc/dpp/dcn401, branch master

drm/amd/display: Remove unused NUM_ELEMENTS macros

2026-04-03T18:04:49Z

Removes unused NUM_ELEMENTS macros. Discovered while removing cases where ARRAY_SIZE from the header can be used. This also aligns with the array_size.cocci coccinelle check. Suggested-by: Robert P. J. Day Signed-off-by: Linus Probert Signed-off-by: Alex Deucher

drm/amd/display: Fixed Silence complier warnings in dc

2026-03-30T19:12:15Z

[Why] Resolve compiler warnings by marking unused parameters explicitly. [How] In .c and .h function definitions, keep parameter names in signatures and add a line with `(void)param;` in function body Preserved function signatures and avoids breaking code paths that may reference the parameter under conditional compilation. Reviewed-by: Dillon Varone Reviewed-by: Austin Zheng Signed-off-by: Gaghik Khachatrian Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher

drm/amd/display: Rename enum 'pixel_format' to 'dc_pixel_format'

2026-03-23T18:19:14Z

Rename the enum 'pixel_format' to 'dc_pixel_format' to avoid potential name conflicts with the pixel_format struct defined in include/video/pixel_format.h. Signed-off-by: Hou Wenlong Reviewed-by: Alex Hung Signed-off-by: Alex Deucher

drm/amd/display: Sync dcn42 with DC 3.2.373

2026-03-11T17:58:07Z

This patch provides a bulk merge to align driver support for DCN42 with Display Core version 3.2.373. It includes upgrade for: - clk_mgr - dml2/dml21 - optc - hubp - mpc - optc - hwseq Acked-by: Aurabindo Pillai Signed-off-by: Roman Li Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Enable dcn42 DC

2026-02-23T19:28:33Z

Add support for DCN 4.2 in Display Core Signed-off-by: Roman Li Acked-by: Harry Wentland Signed-off-by: Alex Deucher

drm/amd/display: bypass post csc for additional color spaces in dal

2026-02-12T20:16:09Z

[Why] For RGB BT2020 full and limited color spaces, overlay adjustments were applied twice (once by MM and once by DAL). This results in incorrect colours and a noticeable difference between mpo and non-mpo cases. [How] Add RGB BT2020 full and limited color spaces to list that bypasses post csc adjustment. Reviewed-by: Aric Cyr Signed-off-by: Clay King Signed-off-by: Tom Chung Signed-off-by: Alex Deucher

drm/amd/display: DPP low mem pwr related adjustment -Part I

2025-12-16T18:26:06Z

[why] Default low pwr mem state get chagned. SW needs to wake mem up first also need to put back to LS again after use: will do in Part II. Reviewed-by: Leo Chen Signed-off-by: Charlene Liu Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Update cursor offload assignments

2025-10-28T13:58:18Z

[Why & How] - Cursor lines per chunk must be assigned from hubp->att and not hubp->pos (the one in hubp->pos is unassigned) - In DCN401 DPP, cur0_enable in attribute struct must be assigned as this is the field passed to DMU - DCN401 should not program position in driver if offload is enabled Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alvin Lee Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add more DC HW state info to underflow logging

2025-10-28T13:57:44Z

[Why] Debugging underflow issues frequently requires knowing the HW state at the time of underflow. To enable capturing this HW state information, interface functions are needed for the various DC HW blocks. [How] This change adds the interface functions to read HW state for the following DC HW blocks: - HUBBUB - HUBP - DPP - MPC - OPP - DSC - OPTC - DCCG Reviewed-by: George Shen Signed-off-by: Karen Chen Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Driver implementation for cursor offloading to DMU

2025-10-13T18:14:32Z

[Why] We require an interlock between driver and firmware for upcoming features and given that this could possibly happen on any single cursor programming call (and that we can't asynchronously wait for firmware to respond because of it) we'd be regressing cursor performance by at least an extra 40us per call. When we could possibly have cursor update every 20us - 100s from high frequency gaming mice this means that we'd be stuttering or dropping updates and impacting overall cursor performance. We want a solution that can: 1. Interlock between other firmware features 2. Not stall out or require the DMCUB lock for every single update [How] When cursor offloading is enabled and supported by an ASIC driver will route the cursor programming through to DMU as part of the regular DC stream cursor programming interfaces for attributes and position. The atomic pipe programming version will not be updated: this will still follow the existing programming path by keeping track of a field that specifies when the register writes should be deferred to DMU. Cursor locking is not required when cursor offload is in progress since the updates are consolidated and processed by DMU once at the end of the frame in a periodic manner. The shared buffer the firmware queries from is allocated along with the rest of the scratch state region in an area that's accessible by both firmware and driver. The size of the cursor offload (v1) state will not change, but it does have a unique union per ASIC version with room for expansion if needed. When firmware features notifying DMU of DRR updates are not enabled we now send an explicit vtotal min/max update via driver to DMU firmware whenever the vtotal max changes. This is to allow the cursor programming to determine the appropriate latch update point offset from vupdate. Reviewed-by: Dillon Varone Signed-off-by: Nicholas Kazlauskas Signed-off-by: Alex Hung Signed-off-by: Alex Deucher