blaster4385/linux-IllusionX/drivers/gpu/drm/amd/display/dc/hwss, branch v6.12.1

drm/amd/display: handle nulled pipe context in DCE110's set_drr()

2024-09-18T20:15:09Z

As set_drr() is called from IRQ context, it can happen that the pipe context has been nulled by dc_state_destruct(). Apply the same protection here that is already present for dcn35_set_drr() and dcn10_set_drr(). I.e. fetch the tg pointer first (to avoid a race with dc_state_destruct()), and then check the local copy before using it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Acked-by: Alex Deucher Signed-off-by: Tobias Jakobi Signed-off-by: Alex Deucher

drm/amd/display: Skip to enable dsc if it has been off

2024-09-18T20:15:08Z

[WHY] It makes DSC enable when we commit the stream which need keep power off, and then it will skip to disable DSC if pipe reset at this situation as power has been off. It may cause the DSC unexpected enable on the pipe with the next new stream which doesn't support DSC. [HOW] Check the DSC used on current pipe status when update stream. Skip to enable if it has been off. The operation enable DSC should happen when set power on. Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Reviewed-by: Wenjing Liu Signed-off-by: Zhikai Zhai Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Clean up dsc blocks in accelerated mode

2024-09-18T20:15:07Z

[WHY] DSC on eDP could be enabled during VBIOS post. The enabled DSC may not be disabled when enter to OS, once the system was in second screen only mode before entering to S4. In this case, OS will not send setTimings to reset eDP path again. The enabled DSC HW will make a new stream without DSC cannot output normally if it reused this pipe with enabled DSC. [HOW] In accelerated mode, to clean up DSC blocks if eDP is on link but not active when we are not in fast boot and seamless boot. Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Reviewed-by: Charlene Liu Signed-off-by: Martin Tsai Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: fix typo in the comment

2024-09-18T20:14:27Z

Correctly spelled comments make it easier for the reader to understand the code. Replace 'maxium' with 'maximum' in the comment & replace 'diffculty' with 'difficulty' in the comment & replace 'suppluy' with 'supply' in the comment & replace 'Congiuration' with 'Configuration' in the comment & replace 'eanbled' with 'enabled' in the comment. Signed-off-by: Yan Zhen Signed-off-by: Alex Deucher

drm/amd/display: fix dccg root clock optimization related hang

2024-09-06T21:41:07Z

[Why] enable dpp rcg before we disable dppclk in hw_init cause system hang/reboot [How] we remove dccg rcg related code from init into a separate function and call it after we init pipe Reviewed-by: Nicholas Kazlauskas Signed-off-by: Qili Lu Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher

drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()

2024-09-06T21:40:09Z

dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn35_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn35_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn35_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi Reviewed-by: Harry Wentland Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()

2024-09-06T21:39:02Z

dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn10_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn10_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi Tested-by: Raoul van Rüschen Tested-by: Christopher Snowhill Reviewed-by: Harry Wentland Tested-by: Sefa Eyeoglu Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/amd/display: Fix flickering caused by dccg

2024-09-02T15:39:53Z

Always allow un-gating. Follow legacy workaround for repeated dppclk dto updates Reviewed-by: Muhammad Ahmed Signed-off-by: Hansen Dsouza Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher

Revert "drm/amd/display: Wait for all pending cleared before full update"

2024-09-02T15:37:29Z

This reverts commit f0b7dcf25834afd17df316367dfe5d4c890c713c. It is causing graphics hangs. Reviewed-by: Martin Leung Signed-off-by: Dillon Varone Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher

drm/amd/display: Wait for all pending cleared before full update

2024-08-27T21:52:01Z

[Description] Before every full update we must wait for all pending updates to be cleared - this is particularly important for minimal transitions because if we don't wait for pending cleared, it will be as if there was no minimal transition at all. In OTG we must read 3 different status registers for pending cleared, one specifically for OTG updates, one specifically for OPTC updates, and the last for surface related updates Reviewed-by: Dillon Varone Signed-off-by: Alvin Lee Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher