Causes flickering or white screens in some configurations.
Disable it for now until we can fix the issue.

Cc: roman.li@amd.com
Cc: yifan1.zhang@amd.com
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.1.x

Causes flickering or white screens in some configurations.
Disable it for now until we can fix the issue.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
Cc: roman.li@amd.com
Cc: yifan1.zhang@amd.com
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NYifan Zhang <yifan1.zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.1.x

Currently, we run into a number of WARN()s when attempting to unload the
amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from
calling drm_encoder_cleanup() too early. So, to fix this we can stop
calling drm_encoder_cleanup() from amdgpu_dm_fini() and instead have it
be called from amdgpu_dm_encoder_destroy(). Also, we don't need to free
in amdgpu_dm_encoder_destroy() since mst_encoders[] isn't explicitly
allocated by the slab allocator.

Fixes: f74367e4 ("drm/amdgpu/display: create fake mst encoders ahead of time (v4)")
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Code in get_output_color_space depends on knowing the pixel encoding to
determine whether to pick between eg. COLOR_SPACE_SRGB or
COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.

v2: Fixed patch being accidentally based on a personal feature branch, oops!

Fixes: ea117312 ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded")
Reviewed-by: NMelissa Wen <mwen@igalia.com>
Signed-off-by: NJoshua Ashton <joshua@froggi.es>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[Why]
Setting scaling does not correctly update CRTC state. As a result
dc stream state's src (composition area) && dest (addressable area)
was not calculated as expected. This causes set scaling doesn's work.

[How]
Correctly update CRTC state when setting scaling property.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Tested-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nhongao <hongao@uniontech.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This reverts commit de05abe6.

The bug referenced below was bisected to this commit. There has been no
activity toward fixing it in 3 months, so let's revert for now.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2162Signed-off-by: NMichel Dänzer <mdaenzer@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

On desktop APUs amdgpu doesn't create a native backlight device
as no eDP panels are found.  However if the BIOS has reported
backlight control methods in the ACPI tables then an acpi_video0
backlight device will be made 8 seconds after boot.

This has manifested in a power slider on a number of desktop APUs
ranging from Ryzen 5000 through Ryzen 7000 on various motherboard
manufacturers. To avoid this, report to the acpi video detection
that the system does not have any panel connected in the native
driver.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1783786Reported-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add display SG support for DCN 3.1.4.
Signed-off-by: NYifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Currently, userspace doesn't have a way to communicate selective updates
to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer
than DCN301, convert DRM damage clips to dc dirty rectangles and fill
them into dirty_rects in fill_dc_dirty_rects().
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This fixes DMCU initialization in APU GPU passthrough.  The
DMCU needs the GPU physical address, not the CPU physical
address.  This ends up working out on bare metal because
we always use the physical address, but doesn't work in
passthrough because the addresses are different.
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
This fix was intended for improving on coding style but in the process
uncovers a race condition, which explains why we are getting incorrect
length in DPIA AUX replies. Due to the call path of DPIA AUX going from
DC back to DM layer then again into DC and the added complexities on top
of current DC AUX implementation, a proper fix to rely on current dc_lock
to address the race condition is difficult without a major overhual
on how DPIA AUX is implemented.

[How]
- Add a mutex dpia_aux_lock to protect DPIA AUX transfers
- Remove DMUB_ASYNC_TO_SYNC_ACCESS_* codes and rely solely on
  aux_return_code_type for error reporting and handling
- Separate SET_CONFIG from DPIA AUX transfer because they have quiet
  different processing logic
- Remove unnecessary type casting to and from void * type
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NJasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
First MST sideband message returns AUX_RET_ERROR_HPD_DISCON
on certain intel platform. Aux transaction considered failure
if HPD unexpected pulled low. The actual aux transaction success
in such case, hence do not return error.

[how]
Not returning error when AUX_RET_ERROR_HPD_DISCON detected
on the first sideband message.

v2: squash in fix (Alex)
Reviewed-by: NJerry Zuo <Jerry.Zuo@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NTsung-hua Lin <Tsung-hua.Lin@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
First MST sideband message returns AUX_RET_ERROR_HPD_DISCON
on certain intel platform. Aux transaction considered failure
if HPD unexpected pulled low. The actual aux transaction success
in such case, hence do not return error.

[how]
Not returning error when AUX_RET_ERROR_HPD_DISCON detected
on the first sideband message.

v2: squash in fix (Alex)
Reviewed-by: NJerry Zuo <Jerry.Zuo@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NTsung-hua Lin <Tsung-hua.Lin@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.

V2:
* Address Wayne's comments (fix another bunch of spots where we weren't
  passing down return codes)
Signed-off-by: NLyude Paul <lyude@redhat.com>
Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.

V2:
* Address Wayne's comments (fix another bunch of spots where we weren't
  passing down return codes)
Signed-off-by: NLyude Paul <lyude@redhat.com>
Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use ip versions (10,3,1) to match the GPU after Vangogh switched to use IP
discovery path.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NPerry Yuan <Perry.Yuan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Some DPIA AUX replies have incorrect data length from original request.
This could lead to overwriting of destination buffer if reply length is
larger, which could cause invalid access to stack since many destination
buffers are declared as local variables.

[How]
Check for invalid length from DPIA AUX replies and trigger a retry if
reply length is not the same as original request. A DRM_WARN() dmesg log
is also produced.
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NTom Chung <chiahsuan.chung@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x

[Why]
Since introduction of patch "Query DPIA HPD status.", link detection at
boot could be accessing DPIA AUX, which will not succeed until
DMUB outbox messaging is enabled and results in below dmesg logs:

[  160.840227] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!

[How]
Enable DMUB outbox messaging before link detection at boot time.
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NTom Chung <chiahsuan.chung@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x

[Why]
Some DPIA AUX replies have incorrect data length from original request.
This could lead to overwriting of destination buffer if reply length is
larger, which could cause invalid access to stack since many destination
buffers are declared as local variables.

[How]
Check for invalid length from DPIA AUX replies and trigger a retry if
reply length is not the same as original request. A DRM_WARN() dmesg log
is also produced.
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NTom Chung <chiahsuan.chung@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x

[Why]
Since introduction of patch "Query DPIA HPD status.", link detection at
boot could be accessing DPIA AUX, which will not succeed until
DMUB outbox messaging is enabled and results in below dmesg logs:

[  160.840227] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!

[How]
Enable DMUB outbox messaging before link detection at boot time.
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NTom Chung <chiahsuan.chung@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x

There are several places where we don't want to check
if a particular asic could support DC, but rather, if
DC is enabled.  Set a flag if DC is enabled and check
for that rather than if a device supports DC or not.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Currently, we are calling fill_dc_dirty_rects() even if PSR isn't
supported by the relevant link in amdgpu_dm_commit_planes(), this is
undesirable especially because when drm.debug is enabled we are printing
messages in fill_dc_dirty_rects() that are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Currently, we are calling fill_dc_dirty_rects() even if PSR isn't
supported by the relevant link in amdgpu_dm_commit_planes(), this is
undesirable especially because when drm.debug is enabled we are printing
messages in fill_dc_dirty_rects() that are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
	* fix commit description (Christian)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-5-tzimmermann@suse.de

Ignore cable ID for DP2 receivers that does not support the feature.
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

As of commit 09a5df6c ("drm/amd/display: Fix multi-display support
for idle opt workqueue"), vblank_lock is no longer being used. So, don't
init it in amdgpu_dm_init() and remove it from struct
amdgpu_display_manager.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since, the quirk is handled in the DRM core now, we can use that value
instead of the internal value.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Invalidate unsupported 420 modes on HDMI TMDS. HDMI TMDS does not
support ODM. Any modes that are horizontally wider than 4096, cannot be
supported via TMDS. So they must be filtered out and should not pass
validation.

[How]
Create fake plane for the new stream, and validate global state by going
through dml validation routine.
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
For FreeSync HDR, native color space flag in AMD VSIF(BT.709) should be
used when intepreting content and color space flag in VSC or AVI
infoFrame should be ignored. However, it turned out some userspace
application still use color flag in VSC or AVI infoFrame which is
incorrect.

[How]
Transfer function is used when building the VSC and AVI infoFrame. Set
colorimetry to BT.709 when all the following match:

1. Pixel format is YCbCr;
2. In FreeSync 2 HDR, color is COLOR_SPACE_2020_YCBCR;
3. Transfer function is TRANSFER_FUNC_GAMMA_22;
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Reviewed-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NMa Hanghong <hanghong.ma@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Porting secure display feature from DCN10 to DCN21. Support single
display for now and will extend to multiple displays.

[How]
- use workqueue to offload works for dmub or dmcu firmware
- after receiving ROI update from userspace, set skip_frame_cnt to 1
- refactor amdgpu_dm_crtc_handle_crc_window_irq()
- disable PSR before activating secure_display on a crtc
- check if secure_display is activated before enabling psr
- only work for single display for now.
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlan Liu <HaoPing.Liu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Ignore cable ID for DP2 receivers that does not support the feature.
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The connector->override_edid flag is strictly for EDID override debugfs
management, and drivers have no business using it.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Xinhui Pan <Xinhui.Pan@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c901869ff8a4e3aebc4abec99c7dd7b4c224f6e6.1666614699.git.jani.nikula@intel.com

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NThomas Zimmermann <tzimemrmann@suse.de>
Acked-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org

After commit 8799c0be ("drm/amd/display: Fix vblank refcount in vrr
transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
misplaced brace, along the lines of:

  In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
                   from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41:
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level:
  ./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’
    864 |         for ((__i) = 0;                                                 \
        |         ^~~
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’
   8317 |         for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~

Move the brace within the #ifdef so that the file can be built with or
without CONFIG_DEBUG_FS.

Fixes: 8799c0be ("drm/amd/display: Fix vblank refcount in vrr transition")
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Before enabling new crtc, stream_count in dc_state does not sync with
that in drm_atomic_state. Validating dsc in such case would leave newly
added stream not jointly participating in dsc optimization with existing
streams, but simply using default initialized vcpi all the time which
gives wrong dsc determination decision.

Consider the scenaio where one 4k60 connected to the dock under dp-alt mode.
Since dp-alt mode is 2-lane setup, stream 1 consumes 63 slots with dsc needed.
Then hook up a second 4k60 to the dock.
stream 2 connected with 65 slot initialized by default without dsc.  dsc
pre validate will not jointly optimize stream 2 with stream 1 before
crtc 2 added into the dc_state. That leads to stream 2 not getting dsc
optimization, and trigger atomic_check failure all the time, as 65 > 63
limit.

After getting all new crtcs added into the state, stream_count in
dc_state correctly reflect that in drm_atomic_state which comes up with
correct dsc decision.

Fixes: 71be4b16 ("drm/amd/display: dsc validate fail not pass to atomic check")
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NQingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Tested-by: NMark Broadworth <mark.broadworth@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

manage_dm_interrupts disable/enable vblank using drm_crtc_vblank_off/on
which causes drm_crtc_vblank_get in vrr_transition to fail, and later
when drm_crtc_vblank_put is called the refcount on vblank will be messed
up. Therefore move the call to after manage_dm_interrupts.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1247
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1380Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NYunxiang Li <Yunxiang.Li@amd.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[Why]
DCN 3.1.4 supports DPIA.

[How]
 - Set dpia_supported flag for dcn314 in dmub_hw_init()
 - Remove comment that becomes irrelevant after this change.
Signed-off-by: NRoman Li <roman.li@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 6.0.x

[Why]

DC makes use of layer_index (zpos) when picking the HW plane to enable
HW cursor on. However, some compositors will not attach zpos information
to each DRM plane. Consequently, in amdgpu, we default layer_index to 0
and do not update it.

This causes said DC logic to enable HW cursor on all planes of the same
layer_index, which manifests as a double cursor issue if one of the
planes is scaled (and hence scaling the cursor as well).

[How]

Use DRM core helpers to calculate a normalized_zpos value for each
drm_plane_state under each crtc, within the atomic state.

This helper will first consider existing zpos values, and if
identical/unset, fallback to plane ID ordering.

The normalized_zpos is then passed to dc_plane_info during atomic check
for later use by the cursor logic.
Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: NWayne Lin <wayne.lin@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

DC makes use of layer_index (zpos) when picking the HW plane to enable
HW cursor on. However, some compositors will not attach zpos information
to each DRM plane. Consequently, in amdgpu, we default layer_index to 0
and do not update it.

This causes said DC logic to enable HW cursor on all planes of the same
layer_index, which manifests as a double cursor issue if one of the
planes is scaled (and hence scaling the cursor as well).

[How]

Use DRM core helpers to calculate a normalized_zpos value for each
drm_plane_state under each crtc, within the atomic state.

This helper will first consider existing zpos values, and if
identical/unset, fallback to plane ID ordering.

The normalized_zpos is then passed to dc_plane_info during atomic check
for later use by the cursor logic.
Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: NWayne Lin <wayne.lin@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>