linux.git/drivers/gpu/drm/amd/display/dc/dml, branch v5.11

Revert "drm/amd/display: Fixed Intermittent blue screen on OLED panel"

2021-01-14T05:23:01+00:00

commit a861736dae64 ("drm/amd/display: Fixed Intermittent blue screen on OLED panel")

causes power regression for many users. It seems that this change causes
the MCLK to get forced high; this creates a regression for many users
since their devices were not able to drop to a low state after this
change. For this reason, this reverts commit
a861736dae644a0d7abbca0c638ae6aad28feeb8.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1407
Cc: Aurabindo Pillai 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Naveed Ashfaq 
Cc: Hersen Wu 
Cc: Roman Li 
Acked-by: Alex Deucher 
Signed-off-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu/display: drop DCN support for aarch64

2021-01-06T21:24:10+00:00

From Ard:

"Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only."

Disable support until the code can be properly refactored to support this
properly on aarch64.

Acked-by: Will Deacon 
Reported-by: Ard Biesheuvel 
Signed-off-by: Alex Deucher

drm/amd/display: remove unused dml variables

2020-11-16T17:18:55+00:00

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bindu Ramamurthy 
Signed-off-by: Alex Deucher

drm/amd/display: correct dml dsc bpc assignment

2020-11-10T19:25:09+00:00

Signed-off-by: Dmytro Laktyushkin 
Acked-by: Bindu Ramamurthy 
Signed-off-by: Alex Deucher

drm/amd/display: Add fallback to prefetch mode 1 if 0 fails

2020-11-10T19:24:39+00:00

[Why]
In some cases, prefetch mode 0 is unsupported but prefetch 1 is
supported. Due to previous change always forcing prefetch mode to 0, we
are failing bandwidth validation in cases where we should not.

[How]
By default try prefetch mode 0 but in the case validation fails, attempt
to do prefetch mode 1 to see if it is supported.

Signed-off-by: Isabel Zhang 
Acked-by: Bindu Ramamurthy 
Signed-off-by: Alex Deucher

drm/amdgpu/display: FP fixes for DCN3.x (v4)

2020-11-04T22:11:43+00:00

Add proper FP_START/END handling and adjust Makefiles per
previous asics.

v2: fix up harder.
v3: fix clkmgr Makefile for dcn30
v4: fix old gcc handling is only required for x86

Build-tested-by: Nathan Chancellor 
Reviewed-by: Harry Wentland  (v1)
Reviewed-by: Nicholas Kazlauskas  (v1)
Signed-off-by: Alex Deucher

drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3)

2020-11-04T22:11:37+00:00

Avoids confusion in configurations.

v2: fix build when CONFIG_DRM_AMD_DC_DCN is disabled
v3: rebase on latest code

Reviewed-by: Luben Tuikov  (v1)
Signed-off-by: Alex Deucher

drm/amd/display: Revert HUBP blank behaviour for now

2020-11-02T20:31:57+00:00

[Why]
Commit "Blank HUBP during pixel data blank for DCN30 v2"
modifies HW behaviour during blank, which might have OS
dependencies. We need to assess the impact on amdgpu_dm
and only re-enable HUBP blanking when all necessary
changes are understood.

[How]
 - revert functional changes
 - leave architectural changes intact

Signed-off-by: Joshua Aberback 
Reviewed-by: Jun Lei 
Acked-by: Qingqing Zhuo 
Signed-off-by: Alex Deucher

drm/amd/display: Blank HUBP during pixel data blank for DCN30

2020-11-02T20:30:33+00:00

[Why]
There are some timings for which we support p-state
switching in active, but not in blank. There was a
previous issue where a timing that had active-only
support would hang a p-state request when we were in
an extended blanking period. The workaround for that
issue was to block active-only p-state switching,
but that resulted in a lack of p-state support for
some common timings such as 1440p60. We want to fix
that issue properly by un-blocking p-state requests
while the display is blanked, so that we can re-enable
active-only p-state switching.

[How]
 - new version of blank_pixel_data for DCN30
 - call hubp->set_blank from dcn30_blank_pixel_data
 - blank every hubp in the mpcc tree, and odm tree
 - on blank enable, wait until the next frame before blanking HUBP

Signed-off-by: Joshua Aberback 
Reviewed-by: Jun Lei 
Acked-by: Qingqing Zhuo 
Signed-off-by: Alex Deucher

drm/amd/display: allow 18 bit dp output on DCN3

2020-10-30T04:59:49+00:00

We need this to pass dp compliance.

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Chris Park 
Reviewed-by: Nikola Cornij 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher