drm/amd/display: Revert HUBP blank behaviour for now

[Why]
Commit "Blank HUBP during pixel data blank for DCN30 v2"
modifies HW behaviour during blank, which might have OS
dependencies. We need to assess the impact on amdgpu_dm
and only re-enable HUBP blanking when all necessary
changes are understood.

[How]
 - revert functional changes
 - leave architectural changes intact

Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This commit is contained in:
Joshua Aberback
2020-10-21 18:44:51 -04:00
committed by Alex Deucher
parent 8edb94562a
commit b15bfd0d86
2 changed files with 3 additions and 26 deletions

View File

@@ -5558,7 +5558,7 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport(
}
}
if (mode_lib->vba.MinActiveDRAMClockChangeMargin > 0) {
if (mode_lib->vba.MinActiveDRAMClockChangeMargin > 0 && PrefetchMode == 0) {
*DRAMClockChangeSupport = dm_dram_clock_change_vactive;
} else if (((mode_lib->vba.SynchronizedVBlank == true || mode_lib->vba.TotalNumberOfActiveOTG == 1 || SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank > 0) && PrefetchMode == 0)) {
*DRAMClockChangeSupport = dm_dram_clock_change_vblank;