New proposed sequence for HUBP blanking causes regressions where the
hardware would fail to enter blank which triggers an assert in the new
sequence. This change brings back the old sequence.
Fixes: 985faf2c4e ("drm/amd/display: New sequence for HUBP blank")
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Currently we use the maximum possible cursor cache size when deciding if we
should attempt to enable MALL, but this prevents us from enabling the
feature for certain key use cases.
[How]
- consider cursor bpp when calculating if the cursor fits
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
DCN30 has a bug where blanking HUBP blocks pstate allow unless
HUBP_DISABLE is toggled afterwards.
[HOW]
Create a HW sequence for blanking HUBP.
1. Wait for enter VBLANK
2. Set HUBP_BLANK
3. Make sure HUBP_IN_BLANK = 1
4. Toggle HUBP_DISABLE on and off to perform soft reset
All existing calls to hubp->funcs->set_blank should be replaced with
this new sequence.
In wait_for_mpcc_disconnect, only blank the pipe being disconnected, and
leave all other pipes unmodified.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[How]
- use dc interface instead of hwss interface in cursor functions, to keep
dc->idle_optimizations_allowed updated
- add dc interface to check if idle optimizations might apply to a plane
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Prior commit "Blank HUBP during pixel data blank for DCN30"
missed the call to set_disp_pattern_generator from
set_crtc_test_pattern, which re-exposed the issue for which
we initially blocked active-only p-state switching.
[How]
- remove dcn30_blank_pixel_data, set dcn30 back to dcn20 version
- new hwss funciton set_disp_pattern_generator
- dcn20 version just calls opp_set_disp_pattern_generator
- dcn30 version implements the HUBP blank
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
There are some timings for which we support p-state
switching in active, but not in blank. There was a
previous issue where a timing that had active-only
support would hang a p-state request when we were in
an extended blanking period. The workaround for that
issue was to block active-only p-state switching,
but that resulted in a lack of p-state support for
some common timings such as 1440p60. We want to fix
that issue properly by un-blocking p-state requests
while the display is blanked, so that we can re-enable
active-only p-state switching.
[How]
- new version of blank_pixel_data for DCN30
- call hubp->set_blank from dcn30_blank_pixel_data
- blank every hubp in the mpcc tree, and odm tree
- on blank enable, wait until the next frame before blanking HUBP
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>
[Why]
During driver unload, it is expected that p-state switching is supported.
If it's not supported, PMFW will hang due to a forced p-state switch. Even
if the current timing does not support p-state normally, we still want to
force allow because the worst that can happen is underflow. This will
match Navi10 behaviour.
[How]
- new hubbub func to control the force pstate register
- force allow when releasing display ownership
- registers are inaccessible after due to m_cgs.hwNotAvailable
- explicitly disable force signal during hw_init
- if driver is disabled and re-enabled, register not cleared otherwise
Also, remove DCN3 part of dcn10_init_hw, we will not be going back to it.
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
