[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 additional DMI entries
v3: squash in static fix
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Acked-by: NSolomon Chiu <solomon.chiu@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Changes from "Fix for dmub outbox notification enable" need to land
in DM or DMUB outbox notification would be disabled.

[How]
Enable outbox notification only after interrupt are enabled and IRQ
handlers registered. Any pending notification will be sent by DMUB
once outbox notification is enabled.

Fixes: ed720870 ("drm/amd/display: Fix for dmub outbox notification enable")
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NSolomon Chiu <solomon.chiu@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Seems to break hibernation.  Disable for now until we can root
cause it.

Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216119Acked-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Recently we introduced a patch for fixing an MST issue, but it caused a
regression on Club 3D since we could not set a refresh rate higher than
60Hz. This commit fixes this issue by adding a proper check after
validating the stream.

Fixes: f04d275d ("drm/amd/display: add mst port output bw check")
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Unexpected change of aux hw mapping causes dmub soft hang when
initiate aux transation at wrong aux channel.

ddc_channel stands for hw dp aux index which is from vbios,
but link_index is pure software concept for link count depending on which link
is probed first. They are not interchangeable.

dmub aux transaction could pass if happens eDP link_index gets
the same value as vbios ddc_channel, e.g., ddc_channel = 1, link_index = 1
if they gets different, e.g., ddc_channel = 2, link_index = 0, overwrite
ddc_channel with link_index will have wrong ddc channel being used for aux
transaction in dmub PSR, cause aux transaction soft hang.

[How]
ddc_channel mapping to each link is determined by vbios and further
parsed in dc. Such info. should not be touched in any kind, otherwise
the mapping is screwed up leading to aux transaction timeout.
Reviewed-by: NAurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
Expose a new dc debug mask enum to force a subviewport memory clock switch
to facilitate easy testing.
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
Some userspace expect a backwards compatible modifier on DCN32/321. For
hardware with num_pipes more than 16, we expose the most efficient
modifier first. As a fall back method, we need to expose slightly inefficient
modifier AMD_FMT_MOD_TILE_GFX9_64K_R_X after the best option.

Also set the number of packers to fixed value as required per hardware
documentation. This value is cached during hardware initialization and
can be read through the base driver.
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 5089c4a8.

This breaks validation and enumeration of display capable modifiers.

The early return true means the rest of the validation code never gets
executed, and we need that to enumerate the right modifiers to userspace
for the format.

The modifiers that are in the initial list generated for a plane are the
superset for all formats and we need the proper checks in this function
to filter some of them out for formats with which they're invalid to be
used.

Furthermore, the safety contract here is that we validate the incoming
modifiers to ensure the kernel can handle them and the display hardware
can handle them. This includes e.g. rejecting multi-plane images with DCC.

Note that the legacy swizzle mechanism allows encoding more swizzles, and
at fb creation time we convert them to modifiers and reject those with
no corresponding modifiers. If we are seeing rejections I'm happy to
help define modifiers that correspond to those, or if absolutely needed
implement a fallback path to allow for less strict validation of the
legacy path.

However, I'd like to revert this patch, since any of these is going to
be a significant rework of the patch, and I'd rather not the regression
gets into a release or forgotten in the meantime.
Reviewed-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 92020e81.

This causes stuttering and timeouts with DMCUB for some users
so revert it until we understand why and safely enable it
to save power.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1887Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>

The DRM_AMDGPU Kconfig code contains:

	select BACKLIGHT_CLASS_DEVICE

So the condition these ifdefs test for is always true, drop them.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
when connect one 4k@144hz dp to dsc mst hub, 4k@144hz mode is in valid
mode list. but some mst hub port output bandwidth does not support
4k@144hz.

[How]
add mst port output bandwidth checks, include full_pbn, branch max
throughput mps.
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NJerry Zuo <Jerry.Zuo@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nhersen wu <hersenxs.wu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Observe that we have several problems while releasing remote dc_sink
under mst cases.

- When unplug mst branch device from the source, we now try to free all
  remote dc_sinks in dm_helpers_dp_mst_stop_top_mgr(). However, there are
  bugs while we're releasing dc_sinks here. First of all,
  link->remote_sinks[] array get shuffled within
  dc_link_remove_remote_sink(). As the result, increasing the array index
  within the releasing loop is wrong. Secondly, it tries to call
  dc_sink_release() to release the dc_sink of the same aconnector every
  time in the loop. Which can't release dc_sink of all aconnector in the
  mst topology.
- There is no code path for us to release remote dc_sink for disconnected
  sst monitor which unplug event is notified by CSN sideband message. Which
  means we'll use stale dc_sink data to represent later on connected
  monitor. Also, has chance to break the maximum remote dc_sink number
  constraint.

[How]
Distinguish unplug event of mst scenario into 2 cases.

* Unplug sst/legacy stream sink off the mst topology
- Release related remote dc_sink in detec_ctx().

* Unplug mst branch device off the mst topology
- Release related remote dc_sink in early_unregister()
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NAurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 3c4d55c9.

Revert the commit because:
- It's incomplete of the function dm_set_dpms_off() for mst case.  For
  stream sinks whithin the same mst topology, they share the same dc_link.
  dm_set_dpms_off() tries to update one mst stream only which is
  incomplete.
- Setting dpms off should be triggered by usermode. Besdies, it seems
  usermode does release relevant resource for mst & non-mst case when
  unplug connecotr now.
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NAurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 035f5496.

The reverted commit was trying to fix side effect brought by
commit 3c4d55c9 ("drm/amd/display: turn DPMS off on connector unplug")

However,
* This reverted commit will have mst case never call dm_set_dpms_off()
  which conflicts the idea of original commit 3c4d55c9 ("drm/amd/display: turn DPMS off on connector unplug")
  That's due to dm_crtc_state is always null since the input parameter
  aconnector is the root device (source) of mst topology.  It's not an
  end stream sink within the mst topology.
* Setting dpms off should be triggered by usermode. Besdies, it seems
  usermode does release relevant resource for mst & non-mst case when
  unplug connecotr now. Which means we no longer need both commits now:
  commit 3c4d55c9 ("drm/amd/display: turn DPMS off on connector unplug")
  commit 035f5496 ("drm/amd/display: Add flag to detect dpms force off during HPD")
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NAurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why] when 4k@144hz dp connect to dp1.4 dsc mst hub, requested
bandwidth exceeds caps of dsc hub. but dsc bw valid functions,
increase_dsc_bpp, try_disable_dsc, pre_validate_dsc,
compute_mst_dsc_configs_for_state, do not return false to
atomic check. this cause user mode initiate mode set to kernel,
then cause kernel assert, system hang.

[How] dsc bandwidth valid functions return pass or fail to atomic
check.
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Nhersen wu <hersenxs.wu@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
There are cases where swizzle modes are set but modifiers arent. For
such a userspace, we need not check modifiers while checking
compatibilty in the drm hook for checking plane format.

Ignore checking modifiers but check the DCN generation for the
supported swizzle mode.

v2: squash in unused variable removal (Alex)
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: NMarek Olšák <marek.olsak@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
For OLED eDP the Display Manager uses max_cll value as a limit
for brightness control.
max_cll defines the content light luminance for individual pixel.
Whereas max_fall defines frame-average level luminance.
The user may not observe the difference in brightness in between
max_fall and max_cll.
That negatively impacts the user experience.

[How]
Use max_fall value instead of max_cll as a limit for brightness control.
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: NRoman Li <roman.li@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]

For additional power savings, PSR SU (also referred to as PSR2) can be
enabled on eDP panels with PSR SU support.

PSR2 saves more power compared to PSR1 by allowing more opportunities
for the display hardware to be shut down. In comparison to PSR1, Shut
down can now occur in-between frames, as well as in display regions
where there is no visible update. In otherwords, it allows for some
display hw components to be enabled only for a **selectively updated**
region of the visible display. Hence PSR SU.

[HOW]

To define the SU region, support from the OS is required. OS needs to
inform driver of damaged regions that need to be flushed to the eDP
panel. Today, such support is lacking in most compositors.

Therefore, an in-between solution is to implement PSR SU for MPO and
cursor scenarios. The plane bounds can be used to define the damaged
region to be flushed to panel. This is achieved by:

* Leveraging dm_crtc_state->mpo_requested flag to identify when MPO is
  enabled.
* If MPO is enabled, only add updated plane bounds to dirty region.
  Determine plane update by either:
    * Existence of drm damaged clips attached to the plane (added by a
      damage-aware compositor)
    * Change in fb id (flip)
    * Change in plane bounds (position and dimensions)
* If cursor is enabled, the old_pos and new_pos of cursor plus cursor
  size is used as damaged regions(*).

(*) Cursor updates follow a different code path through DC. PSR SU for
cursor is already implemented in DC, and the only thing required to
enable is to set DC_PSR_VERSION_SU_1 on the eDP link. See
dcn10_dmub_update_cursor_data().
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

GFX11 IP introduces new tiling mode. Various combinations of DCC
settings are possible and the most preferred settings must be exposed
for optimal use of the hardware.

add_gfx11_modifiers() is based on recommendation from Marek for the
preferred tiling modifier that are most efficient for the hardware.

v2: microtiling fix noticed by Marek
v3: keep Z tiling check
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add Display Manager specific changes for DCN3.2.x.  DM
handles the interaction between the core DC modesetting
code and the drm modesetting infrastructure.
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix spelling typo in comments.
Reported-by: Nk2ci <kernel-bot@kylinos.cn>
Signed-off-by: Npengfuyuan <pengfuyuan@kylinos.cn>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

why:
lut pipeline will be hooked up differently in some asics
need to add new interfaces

how:
add them
Reviewed-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: NJasdeep Dhillon <jdhillon@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NMartin <martin.leung@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

According to the KMS man page, there is a
"Coverage" alpha blend mode that assumes the
pixel color values have NOT been pre-multiplied
and will be done when the actual blending to
the background color values happens.

Previously, this mode hasn't been enabled
in our driver and it was assumed that all
normal overlay planes are pre-multiplied
by default.

When a 3rd party app is used to input a image
in a specific format, e.g. PNG, as a source
of a overlay plane to blend with the background
primary plane, the pixel color values are not
pre-multiplied. So by adding "Coverage" blend
mode, our driver will support those cases.

Issue fixed: Overlay plane alpha channel blending is incorrect
Issue tracker: https://gitlab.freedesktop.org/drm/amd/-/issues/1769

Reference:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties

Adding Coverage support also enables IGT
kms_plane_alpha_blend Coverage subtests:
1. coverage-7efc
2. coverage-vs-premult-vs-constant

Changes
1. Add DRM_MODE_BLEND_COVERAGE blend mode capability
2. Add "pre_multiplied_alpha" flag for Coverage case
3. Read the correct flag and set the DCN MPCC
pre_multiplied register bit (only on overlay plane)

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1769Signed-off-by: NSung Joon Kim <Sungjoon.Kim@amd.com>
Reviewed-by: NMelissa Wen <mwen@igalia.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
access.

Fixes: e27c41d5 ("drm/amd/display: Support for DMUB HPD interrupt handling")
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Eliminate the follow smatch warning:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9687
amdgpu_dm_atomic_commit_tail() warn: inconsistent indenting.
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
CONFIG_DRM_AMD_DC_DCN is used by pass the compilation failures, but DC
code should be OS-agnostic.

This patch fixes it by removing unnecessasry CONFIG_DRM_AMD_DC_DCN
in amdgpu_dm directory.
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NStylon Wang <stylon.wang@amd.com>
Signed-off-by: NAlex Hung <alex.hung@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Move DRM's HMDI helpers into the display/ subdirectoy and add it
to DRM's display helpers. Update all affected drivers. No functional
changes.

The HDMI helpers were implemented in the EDID and connector code, but
are actually unrelated. With the move to the display-helper library, we
can remove the dependency on drm_edid.{c,h} in some driver's HDMI source
files.

Several of the HDMI helpers remain in EDID code because both share parts
of their implementation internally. With better refractoring of the EDID
code, those HDMI helpers could be moved into the display-helper library
as well.

v3:
	* fix Kconfig dependencies (Javier)
v2:
	* reduce HDMI helpers to avoid exporting functions (Jani)
	* fix include statements (Jani, Javier)
	* update Kconfig symbols
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-8-tzimmermann@suse.de

Move DRM's HDCP helper library into the display/ subdirectory and add
it to DRM's display helpers. Split the header file into core and helpers.
Update all affected drivers. No functional changes.

v3:
	* fix Kconfig dependencies
v2:
	* fix include statements (Jani, Javier)
	* update Kconfig symbols
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-7-tzimmermann@suse.de

Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.

Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The new directory's name is aligned with this convention.

v2:
	* update commit message (Javier)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de

We just need to reserve one BO here, no need for using ttm_eu to reserve
multiple BOs.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220419141915.122157-2-christian.koenig@amd.com

This change adds the dma_resv_usage enum and allows us to specify why a
dma_resv object is queried for its containing fences.

Additional to that a dma_resv_usage_rw() helper function is added to aid
retrieving the fences for a read or write userspace submission.

This is then deployed to the different query functions of the dma_resv
object and all of their users. When the write paratermer was previously
true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise.

v2: add KERNEL/OTHER in separate patch
v3: some kerneldoc suggestions by Daniel
v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in
    the rebase pointed out by Bas.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-2-christian.koenig@amd.com

[Why]
comparing pwm bl values (coverted) with user brightness(converted)
levels in commit_tail leads to continuous setting of backlight via dmub
as they don't to match.
This leads overdrive in queuing of commands to DMCU that sometimes lead
to depending on load on DMCU fw:

"[drm:dc_dmub_srv_wait_idle] *ERROR* Error waiting for DMUB idle: status=3"

[How]
Store last successfully set backlight value and compare with it instead
of pwm reads which is not what we should compare with.
Signed-off-by: NShirish S <shirish.s@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()

[How]
Use link type as indicator for mst link.
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NAlex Hung <alex.hung@amd.com>
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
comparing pwm bl values (coverted) with user brightness(converted)
levels in commit_tail leads to continuous setting of backlight via dmub
as they don't to match.
This leads overdrive in queuing of commands to DMCU that sometimes lead
to depending on load on DMCU fw:

"[drm:dc_dmub_srv_wait_idle] *ERROR* Error waiting for DMUB idle: status=3"

[How]
Store last successfully set backlight value and compare with it instead
of pwm reads which is not what we should compare with.
Signed-off-by: NShirish S <shirish.s@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()

[How]
Use link type as indicator for mst link.
Reviewed-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NAlex Hung <alex.hung@amd.com>
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

ATOMIC and DRIVER log categories do not typically contain per-frame log
messages. This patch re-classifies some messages in amd to chattier
categories to keep ATOMIC/DRIVER quiet.
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.

Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.

Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.

@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}

@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)

@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)

@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@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>

These on stack copies of the modes appear to be pointless.
Just look at the originals directly.

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
Cc: Nikola Cornij <nikola.cornij@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
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>

Enable scatter/gather display for DCN 3.1.6.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The issue only occurs during the GPU reset code path.

We first backup the current state prior to commiting 0 streams
internally from DM to DC. This state backup contains valid link
encoder assignments.

DC will clear the link encoder assignments as part of current state
(but not the backup, since it was a copied before the commit) and
free the extra stream reference it held.

DC requires that the link encoder assignments remain cleared/invalid
prior to commiting. Since the backup still has valid assignments we
call the interface post reset to clear them. This routine also
releases the extra reference that the link encoder interface held -
resulting in a double free (and eventually a NULL pointer dereference).

[How]
We'll have to do a full DC commit anyway after GPU reset because
the stream count previously went to 0.

We don't need to retain the assignment that we had backed up, so
just copy off of the now clean current state assignment after the
reset has occcurred with the new link_enc_cfg_copy() interface.

Fixes: 6d63fcc2 ("drm/amd/display: Reset link encoder assignments for GPU reset")
Reviewed-by: NJimmy Kizito <Jimmy.Kizito@amd.com>
Acked-by: NAlan Liu <HaoPing.Liu@amd.com>
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>