Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
  a module, select ACPI_VIDEO and its deps if ACPI is enabled.
  When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
  the stubs from acpi/video.h will be used.

Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
  adjust the Kconfig changes to match this.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

[Why & How]

It's useful to disable MPO when debugging or testing. Therefore, add a
dcdebugmask option to disable MPO.
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]

Being able to configure visual confirm at boot or in cmdline is helpful
when debugging.

[How]

Add a module parameter to configure DC visual confirm, which works the
same way as the equivalent debugfs entry.
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DCN 3.1.4 uses dmub not dmcu. Attempt to identify
dmcu firmware for dcn314 results in dm init error:
"Unsupported ASIC type"

[How]
Add dcn314 to the list of asics that don't require dmcu
Signed-off-by: NRoman Li <roman.li@amd.com>
Reviewed-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]
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and DC. As a result, this file becomes very large since
it comprises multiple abstractions such as CRTC manipulation.

[How]
This commit extracts the CRTC code to its specific file named
amdgpu_dm_crtc. This change does not change anything inside the
functions; the only exception is converting some static functions to a
global function.

v2: fix ifdef merge mix up (Alex)
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NAlan Liu <HaoPing.Liu@amd.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and DC. As a result, this file becomes very large since
it comprises multiple abstractions such as plane manipulation.

[How]
This commit extracts the plane code to its specific file named
amdgpu_dm_plane. This change does not change anything inside the
functions; the only exception is converting some static functions to a
global function.
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NAlan Liu <HaoPing.Liu@amd.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@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>
Cc: stable@vger.kernel.org

Add support for DCN 3.1.4 in Display Manager
Signed-off-by: NRoman Li <roman.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Requires enabling the vblank machinery for them.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2030Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NMichel Dänzer <mdaenzer@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Requires enabling the vblank machinery for them.

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

Check the value of per_pixel_alpha to decide whether the Coverage pixel
blend mode is applicable or not.

Fixes: 76818cdd ("drm/amd/display: add Coverage blend mode for overlay plane")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NMelissa Wen <mwen@igalia.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 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>
Cc: stable@vger.kernel.org

Check the value of per_pixel_alpha to decide whether the Coverage pixel
blend mode is applicable or not.

Fixes: 76818cdd ("drm/amd/display: add Coverage blend mode for overlay plane")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NMelissa Wen <mwen@igalia.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
Add a field to store the NBIO IP offset for use with runtime offset
calculation
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NSolomon Chiu <solomon.chiu@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
Add a field to store the DCN IP offset for use with runtime offset
calculation

This offset is indexed using reg*_BASE_IDX for the corresponding
group of registers. For example, address of DIG_BE_CNTL instance 0 is
calculated like: dcn_reg_offsets[regDIG0_DIG_BE_CNTL_BASE_IDX] +
regDIG0_DIG_BE_CNTL.

{dcn,nbio}_reg_offsets are used only for the ASICs for which runtime
initializaion of offsets are enabled through the modified SR* macros
that contain an additional REG_STRUCT element in the macro definition.

DCN3.5+ will fail dc_create() if {dcn,nbio}_reg_offsets are null. They
are applicable starting with DCN32/321 and are not used for ASICs
upstreamed before them. ASICs before DCN32/321 will not contain any
computation that involves {dcn,nbio}_reg_offsets. For them, the
address/offset computation is done during compile time.

This is evident from the BASE_INNER definition for compile time vs run
time initialization:

Compile time init: #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg
Run time init:     #define BASE_INNER(seg) ctx->dcn_reg_offsets[seg]

BASE_INNER macro is local to each dcnxx_resource.c and hence different
ASICs can have either runtime or compile time initialization of offsets.

The computation of offset is done for registers all at once during
driver load and hence it does not introduce any performance overhead
during normal operation.
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: NSolomon Chiu <solomon.chiu@amd.com>
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
There is chance we change dc state while calling dc_link_detect().
As the result of that, grab the dm.dc_lock before detecting link.
Reviewed-by: NHersen Wu <hersen.wu@amd.com>
Acked-by: NSolomon Chiu <solomon.chiu@amd.com>
Signed-off-by: NWayne Lin <Wayne.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 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>

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 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>
Cc: stable@vger.kernel.org

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>

Fixes this warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9143:27: warning: variable 'abo' set but not used [-Wunused-but-set-variable]

Fixes: 047de3f1 ("drm/amdgpu: switch DM to atomic fence helpers v2")
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220616203538.649041-1-alexander.deucher@amd.com

drm_crtc.h has no need for drm_blend.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_blend.h.

Quite a few placs do currently depend on drm_blend.h without
actually including it directly. All of those need to be fixed
up.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-4-ville.syrjala@linux.intel.comAcked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>

amdgpu_dm_crtc_late_register() is only used when CONFIG_DEBUG_FS
is enabled so make it dependent on that.

Fixes: 4cd79f61 ("drm/amd/display: Move connector debugfs to drm")
Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lists.freedesktop.org/archives/dri-devel/2022-June/359496.htmlSigned-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615210019.28943-1-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>
Cc: stable@vger.kernel.org

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