drm/amd/display: rework recent update PHY state commit

[why]
Original change 594b237b9a07 ("drm/amd/display: Add
interface to track PHY state") was implemented by assuming stream's
dpms off is equiv

drm/amd/display: rework recent update PHY state commit

[why]
Original change 594b237b9a07 ("drm/amd/display: Add
interface to track PHY state") was implemented by assuming stream's
dpms off is equivalent to PHY power off.
This assumption doesn't hold in following situations:
1. MST multiple stream scenario, where multiple streams are sharing the
same PHY output. Toggle dpms off for one of the stream doesn't power
off the PHY due to the presence of other streams.
2. enable stream failure scenario, where enable stream fails due to
failure of link training. This will cause DPMS off is set to false, while
the actual PHY power state is off in certain cases.
Due to the problematic assumption, the logic will skip disabling
other streams for MST multiple stream scenario, therefore PHY is
not actually powered off.

[how]
1. Rework this refactor by moving PHY state update down to hardware
level, where we update PHY state in place when hardware sequencer
is actually changing the power state of the PHY hardware.
2. Reimplement symclk on TX off workaround in place when we are actually
calling transmitter control to power off PHY in dcn32. Note the workaround is
added due to the lack of proper software interface to set TX while keeping
symclk on. We plan to address this interface problem so we can set TX off
only without affecting symclk in future dcn versions.

Fixes: 594b237b9a07 ("drm/amd/display: Add interface to track PHY state")
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Added power down for DCN10

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.

drm/amd/display: Added power down for DCN10

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Derek Lai <Derek.Lai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Added power down for DCN10

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.

drm/amd/display: Added power down for DCN10

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Derek Lai <Derek.Lai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Added power down for DCN10

[ Upstream commit d97e631af2db84c8c9d63abf68d487d0bb559e4c ]

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just l

drm/amd/display: Added power down for DCN10

[ Upstream commit d97e631af2db84c8c9d63abf68d487d0bb559e4c ]

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Derek Lai <Derek.Lai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/amd/display: Refactor visual confirm

[Why + How]
Visual confirm has no asic-specific logic,
so we can refactor and unify these functions
that are currently spread out across multiple
dcn files.

drm/amd/display: Refactor visual confirm

[Why + How]
Visual confirm has no asic-specific logic,
so we can refactor and unify these functions
that are currently spread out across multiple
dcn files.
Add a new hw sequencer interface update_visual_confirm_color,
and a new mpc function pointer set_bg_color.
This will allow visual confirm to updated independently
of MPCC blending updates.

v2: squash in DCN3.1 fixes

Signed-off-by: Wyatt Wood <wyatt.wood@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

Revert "drm/amd/display: Refactor and add visual confirm for HW Flip Queue"

This reverts commit 3ca402375a2197579d1029e7fa9d856847fe0e7b.

Recent visual confirm changes are regressing the driver, ca

Revert "drm/amd/display: Refactor and add visual confirm for HW Flip Queue"

This reverts commit 3ca402375a2197579d1029e7fa9d856847fe0e7b.

Recent visual confirm changes are regressing the driver, causing a
black screen on boot in some green sardine configs, or visual confirm
is not updated at all.

Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Refactor and add visual confirm for HW Flip Queue

[Why]
Visual confirm will indicate if driver is programming
the surface address.
Refactor is required because much of the visual co

drm/amd/display: Refactor and add visual confirm for HW Flip Queue

[Why]
Visual confirm will indicate if driver is programming
the surface address.
Refactor is required because much of the visual confirm
logic is buried deep in the mpcc files.
In addition, visual confirm is not updated during fast updates.

[How]
In order to have visual confirm for driver flips, visual confirm
needs to be updated on every frame, including fast updates.
Add a new hw sequencer interface update_visual_confirm_color,
and a new mpc function pointer set_bg_color.

v2: drop unused variable (Alex)

Signed-off-by: Wyatt Wood <wyatt.wood@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Stylon Wang <stylon.wang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: update DCN to use new surface programming

[Why]
The split pipe config is updated due to antoher stream bandwidth
validataion. Driver doesn't reprogram the split pipe config
to signl

drm/amd/display: update DCN to use new surface programming

[Why]
The split pipe config is updated due to antoher stream bandwidth
validataion. Driver doesn't reprogram the split pipe config
to signle pipe cause SW use signel pipe but HW still use pipe split.

[How]
track global updates and update any hw that isn't
related to current stream being updated.

Signed-off-by: Paul Hsieh <paul.hsieh@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Wayne Lin <Wayne.Lin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add function and debugfs to dump DCC_EN bit

[why]
Currently to view the DCC_EN bit the entire DTN log
must be dumped. A compact method to view the DCC_EN
bit is desirable.

[how]
In

drm/amd/display: Add function and debugfs to dump DCC_EN bit

[why]
Currently to view the DCC_EN bit the entire DTN log
must be dumped. A compact method to view the DCC_EN
bit is desirable.

[how]
Introduce new debugfs interface that only dumps the
DCC_EN bit.

Example usage:
cat /sys/kernel/debug/dri/0/amdgpu_dm_dcc_en

Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Old sequence for HUBP blank

New proposed sequence for HUBP blanking causes regressions where the
hardware would fail to enter blank which triggers an assert in the new
sequence. Thi

drm/amd/display: Old sequence for HUBP blank

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: 985faf2c4ecb60 ("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>

show more ...

drm/amd/display: New sequence for HUBP blank

[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

drm/amd/display: New sequence for HUBP blank

[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>

show more ...

drm/amd/display: Update GSL state if leaving immediate flip

[Why]
We should leave GSL if we're not doing immediate flip no matter if
we're doing pipe split or not

[How]
Check for updating GSL state

drm/amd/display: Update GSL state if leaving immediate flip

[Why]
We should leave GSL if we're not doing immediate flip no matter if
we're doing pipe split or not

[How]
Check for updating GSL state whenever we're not doing
immediate flip

v2: Squash in build fix (Alex)

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: eDP intermittent black screen during PnP

[Why]
We dont's turn off backlight before power off eDP (VDD),
which is a violation of eDP specs.

[How]
Power off eDP backlight before powe

drm/amd/display: eDP intermittent black screen during PnP

[Why]
We dont's turn off backlight before power off eDP (VDD),
which is a violation of eDP specs.

[How]
Power off eDP backlight before power off eDP

Signed-off-by: Peikang Zhang <peikang.zhang@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Disconnect pipe separetely when disable pipe split

[Why]
When changing pixel formats for HDR (e.g. ARGB -> FP16)
there are configurations that change from 2 pipes to 1 pipe.
In thes

drm/amd/display: Disconnect pipe separetely when disable pipe split

[Why]
When changing pixel formats for HDR (e.g. ARGB -> FP16)
there are configurations that change from 2 pipes to 1 pipe.
In these cases, it seems that disconnecting MPCC and doing
a surface update at the same time(after unlocking) causes
some registers to be updated slightly faster than others
after unlocking (e.g. if the pixel format is updated to FP16
before the new surface address is programmed, we get
corruption on the screen because the pixel formats aren't
matching). We separate disconnecting MPCC from the rest
of the pipe programming sequence to prevent this.

[How]
Move MPCC disconnect into separate operation than the
rest of the pipe programming.

Signed-off-by: Alvin Lee <alvin.lee2@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>

show more ...

drm/amd/display: Power down hardware if set mode is not called before timeout

[WHY]
In headless systems, if set mode is not called, hardware will not be
powered down on boot, causing HW/SW discrepan

drm/amd/display: Power down hardware if set mode is not called before timeout

[WHY]
In headless systems, if set mode is not called, hardware will not be
powered down on boot, causing HW/SW discrepancies. Powering down
hardware on boot will ensure SW state is accurate.

[HOW]
Set a timer callback on boot for 10 seconds. If set mode is not called
within that time, power down hardware. Otherwise, do not power down.

Signed-off-by: Sung Lee <sung.lee@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Implement some asic specific abm call backs.

[Why & How]
Implement abm set_pipe call stacks
Have some asics speicifc call stacks for abm.

Signed-off-by: Yongqiang Sun <yongqiang.su

drm/amd/display: Implement some asic specific abm call backs.

[Why & How]
Implement abm set_pipe call stacks
Have some asics speicifc call stacks for abm.

Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Defer cursor lock until after VUPDATE

[Why]
We dropped the delay after changed the cursor functions locking the
entire pipe to locking just the CURSOR registers to fix page flip
stu

drm/amd/display: Defer cursor lock until after VUPDATE

[Why]
We dropped the delay after changed the cursor functions locking the
entire pipe to locking just the CURSOR registers to fix page flip
stuttering - this introduced cursor stuttering instead, and an underflow
issue.

The cursor update can be delayed indefinitely if the cursor update
repeatedly happens right around VUPDATE.

The underflow issue can happen if we do a viewport update on a pipe
on the same frame where a cursor update happens around VUPDATE - the
old cursor registers are retained which can be in an invalid position.

This can cause a pipe hang and indefinite underflow.

[How]
The complex, ideal solution to the problem would be a software
triple buffering mechanism from the DM layer to program only one cursor
update per frame just before VUPDATE.

The simple workaround until we have that infrastructure in place is
this change - bring back the delay until VUPDATE before locking, but
with some corrections to the calculations.

This didn't work for all timings before because the calculation for
VUPDATE was wrong - it was using the offset from VSTARTUP instead and
didn't correctly handle the case where VUPDATE could be in the back
porch.

Add a new hardware sequencer function to use the existing helper to
calculate the real VUPDATE start and VUPDATE end - VUPDATE can last
multiple lines after all.

Change the udelay to incorporate the width of VUPDATE as well.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Defer cursor lock until after VUPDATE

[Why]
We dropped the delay after changed the cursor functions locking the
entire pipe to locking just the CURSOR registers to fix page flip
stu

drm/amd/display: Defer cursor lock until after VUPDATE

[Why]
We dropped the delay after changed the cursor functions locking the
entire pipe to locking just the CURSOR registers to fix page flip
stuttering - this introduced cursor stuttering instead, and an underflow
issue.

The cursor update can be delayed indefinitely if the cursor update
repeatedly happens right around VUPDATE.

The underflow issue can happen if we do a viewport update on a pipe
on the same frame where a cursor update happens around VUPDATE - the
old cursor registers are retained which can be in an invalid position.

This can cause a pipe hang and indefinite underflow.

[How]
The complex, ideal solution to the problem would be a software
triple buffering mechanism from the DM layer to program only one cursor
update per frame just before VUPDATE.

The simple workaround until we have that infrastructure in place is
this change - bring back the delay until VUPDATE before locking, but
with some corrections to the calculations.

This didn't work for all timings before because the calculation for
VUPDATE was wrong - it was using the offset from VSTARTUP instead and
didn't correctly handle the case where VUPDATE could be in the back
porch.

Add a new hardware sequencer function to use the existing helper to
calculate the real VUPDATE start and VUPDATE end - VUPDATE can last
multiple lines after all.

Change the udelay to incorporate the width of VUPDATE as well.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Move panel_cntl specific register from abm to panel_cntl.

[Why]
panel_cntl specific register should be access in panel_cntl object.

[How]
Move these register access from abm to pan

drm/amd/display: Move panel_cntl specific register from abm to panel_cntl.

[Why]
panel_cntl specific register should be access in panel_cntl object.

[How]
Move these register access from abm to panel_cntl.

Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Use cursor locking to prevent flip delays

[Why]
Current locking scheme for cursor can result in a flip missing
its vsync, deferring it for one or more vsyncs. Result is a
potential

drm/amd/display: Use cursor locking to prevent flip delays

[Why]
Current locking scheme for cursor can result in a flip missing
its vsync, deferring it for one or more vsyncs. Result is a
potential for stuttering when cursor is moved.

[How]
Use cursor update lock so that flips are not blocked while cursor
is being programmed.

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Use cursor locking to prevent flip delays

[Why]
Current locking scheme for cursor can result in a flip missing
its vsync, deferring it for one or more vsyncs. Result is a
potential

drm/amd/display: Use cursor locking to prevent flip delays

[Why]
Current locking scheme for cursor can result in a flip missing
its vsync, deferring it for one or more vsyncs. Result is a
potential for stuttering when cursor is moved.

[How]
Use cursor update lock so that flips are not blocked while cursor
is being programmed.

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add set backlight to hw sequencer.

[Why & How]
Add set backlight to hw sequencer, dmu communication will
be handled in hw sequencer for new asics.

Signed-off-by: Yongqiang Sun <yon

drm/amd/display: Add set backlight to hw sequencer.

[Why & How]
Add set backlight to hw sequencer, dmu communication will
be handled in hw sequencer for new asics.

Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: move panel power seq to new panel struct

[Why]
panel power sequencer is currently just sitting in hwseq but it really
it tied to internal panels

[How]
make a new panel struct to co

drm/amd/display: move panel power seq to new panel struct

[Why]
panel power sequencer is currently just sitting in hwseq but it really
it tied to internal panels

[How]
make a new panel struct to contain power sequencer code

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add function pointers for panel related hw functions

[Why]
Make panel backlight and power on/off functions into
hardware specific function pointers

[How]
Add function pointers for

drm/amd/display: Add function pointers for panel related hw functions

[Why]
Make panel backlight and power on/off functions into
hardware specific function pointers

[How]
Add function pointers for panel related hw functions
- is_panel_powered_on
- is_panel_backlight_on

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Added locking for atomic update stream and update planes

[Why]
Screen flickering when HDR switches between FP16 and ARGB2101010

[How]
Moved pipe_control_lock so stream update and p

drm/amd/display: Added locking for atomic update stream and update planes

[Why]
Screen flickering when HDR switches between FP16 and ARGB2101010

[How]
Moved pipe_control_lock so stream update and plane update occur atomically

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Signed-off-by: Lucy Li <lucy.li@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...