kernel/drivers/gpu/drm/amd/display/dc/hubp, branch linux-rolling-stable

drm/amd/display: Fix wrong x_pos and y_pos for cursor offload

2026-03-04T12:19:51Z

[ Upstream commit c02288724b98cbc018231200891d66578f83f848 ] [Why] The hubp401_cursor_set_position function programs a different value than it stores for use with cursor offload. This can cause a desync when switching between cursor programming paths. [How] We do the translation to destination space currently twice: once in the HWSS layer, and then again in the HUBP layer since we never store the translated result. HUBP expects to program the pos->x and pos->y directly for other ASIC, so follow that pattern here as well. Reviewed-by: Alvin Lee Signed-off-by: Nicholas Kazlauskas Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

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: Rename dml2 to dml2_0 folder

2025-10-28T13:57:39Z

[Why] dml2 folder contains all logic for all versions of DML2 This is currently DML2.0 and DML2.1. Rename dml2 to dml2_0 folder to reflect this better (dml2_0 for DML2.0). [How] Rename dml2 to dml2_0 folder and update dml2 references to use dml2_0 folder. Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: waynelin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Update DCN401 path for cursor offload

2025-10-20T22:21:30Z

[Description] The DCN401 cursor offload path needs to take into account use_mall_for_cursor, and also need to ensure the dcn32 function assigns the cursor cache fields (DCN401 uses the dcn32 implementation). Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alvin Lee Signed-off-by: Aurabindo Pillai 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

drm/amd/display: Remove inaccessible URL

2025-10-13T18:14:32Z

[WHAT] Remove inaccessible link. Reviewed-by: Joshua Aberback Signed-off-by: Clay King Signed-off-by: Alex Hung Signed-off-by: Alex Deucher

drm/amd/display: Adding interface to log hw state when underflow happens

2025-08-04T18:40:32Z

[why] Will help us better debug underflow issues. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Muhammad Ahmed Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Fixing hubp programming of 3dlut fast load

2025-08-04T18:40:24Z

[why] HUBP needs to know the size of the lut's destination in MPC. This is currently defaulted to 17, and needs to be set for specific lut size. [how] Define and apply the missing hubp field. Taking this opportunity to consolidate the programming of 3dlut into a hubp and mpc function. Reviewed-by: Krunoslav Kovac Signed-off-by: Reza Amini Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: MPC basic allocation logic and TMZ

2025-07-15T18:07:51Z

[WHY & HOW] Adding basic logic to allocate unused RMCM block and TMZ support. Reviewed-by: Krunoslav Kovac Signed-off-by: Yihan Zhu Signed-off-by: Ivan Lipski Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher