kernel.git/drivers/gpu/drm/amd/display/dc/dml, branch linux-5.4.y

drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang

2025-06-27T10:02:50Z

commit 7db038d9790eda558dd6c1dde4cdd58b64789c47 upstream. When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-mhard-float' [-Werror,-Wunused-command-line-argument] Similar to commit 84edc2eff827 ("selftest/fpu: avoid clang warning"), just add this flag to GCC builds. Commit 0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") added '-msse2' to prevent clang from emitting software floating point routines. Signed-off-by: Nathan Chancellor Acked-by: Alex Deucher Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add check for granularity in dml ceil/floor helpers

2025-02-01T17:18:45Z

commit 0881fbc4fd62e00a2b8e102725f76d10351b2ea8 upstream. [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. Cc: Mario Limonciello Reviewed-by: Alvin Lee Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Initialize get_bytes_per_element's default to 1

2024-11-08T15:20:39Z

[ Upstream commit 4067f4fa0423a89fb19a30b57231b384d77d2610 ] Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. Signed-off-by: Alex Hung Reviewed-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: fix dml prefetch validation

2021-05-11T12:04:09Z

[ Upstream commit 8ee0fea4baf90e43efe2275de208a7809f9985bc ] Incorrect variable used, missing initialization during validation. Tested-by: Daniel Wheeler Signed-off-by: Dmytro Laktyushkin Reviewed-by: Eric Bernstein Acked-by: Solomon Chiu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: fixup DML dependencies

2020-02-24T07:36:51Z

[ Upstream commit 34ad0230062c39cdcba564d16d122c0fb467a7d6 ] [why] Need to fix DML portability issues to enable SW unit testing around DML [how] Move calcs into dc include folder since multiple components reference it Remove relative paths to external dependencies Signed-off-by: Jun Lei Reviewed-by: Anthony Koo Acked-by: Harry Wentland Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: enable -msse2 for GCC 7.1+ users

2019-10-30T15:56:20Z

A final attempt at enabling sse2 for GCC users. Orininally attempted in: commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") Reverted due to "reported instability" in: commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"") Re-added just for Clang in: commit 0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") The original report didn't have enough information to know if the GPF was due to misalignment, but I suspect that it was. (The missing information was the disassembly of the function at the bottom of the trace, to see if the instruction pointer pointed to an instruction with 16B alignment memory operand requirements. The stack trace does show the stack was only 8B but not 16B aligned though, which makes this a strong possibility). Now that the stack misalignment issue has been fixed for users of GCC 7.1+, reattempt adding -msse2. This matches Clang. It will likely never be safe to enable this for pre-GCC 7.1 AND use a 16B aligned stack in these translation units. This is only a functional change for GCC 7.1+ users, and should be boot tested. Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487 Signed-off-by: Nick Desaulniers Signed-off-by: Alex Deucher

drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+

2019-10-30T15:56:20Z

GCC earlier than 7.1 errors when compiling code that makes use of `double`s and sets a stack alignment outside of the range of [2^4-2^12]: $ cat foo.c double foo(double x, double y) { return x + y; } $ gcc-4.9 -mpreferred-stack-boundary=3 foo.c error: -mpreferred-stack-boundary=3 is not between 4 and 12 This is likely why the AMDGPU driver was ever compiled with a different stack alignment (and thus different ABI) than the rest of the x86 kernel. The kernel uses 8B stack alignment, while the driver was using 16B stack alignment in a few places. Since GCC 7.1+ doesn't error, fix the ABI mismatch for users of newer versions of GCC. There was discussion about whether to mark the driver broken or not for users of GCC earlier than 7.1, but since the driver currently is working, don't explicitly break the driver for them here. Relying on differing stack alignment is unspecified behavior, and brittle, and may break in the future. This patch is no functional change for GCC users earlier than 7.1. It's been compile tested on GCC 4.9 and 8.3 to check the correct flags. It should be boot tested when built with GCC 7.1+. -mincoming-stack-boundary= or -mstackrealign may help keep this code building for pre-GCC 7.1 users. The version check for GCC is broken into two conditionals, both because cc-ifversion is currently GCC specific, and it simplifies a subsequent patch. Signed-off-by: Nick Desaulniers Signed-off-by: Alex Deucher

drm/amdgpu: fix stack alignment ABI mismatch for Clang

2019-10-30T15:56:20Z

The x86 kernel is compiled with an 8B stack alignment via `-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via commit d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported") or `-mstack-alignment=8` for Clang. Parts of the AMDGPU driver are compiled with 16B stack alignment. Generally, the stack alignment is part of the ABI. Linking together two different translation units with differing stack alignment is dangerous, particularly when the translation unit with the smaller stack alignment makes calls into the translation unit with the larger stack alignment. While 8B aligned stacks are sometimes also 16B aligned, they are not always. Multiple users have reported General Protection Faults (GPF) when using the AMDGPU driver compiled with Clang. Clang is placing objects in stack slots assuming the stack is 16B aligned, and selecting instructions that require 16B aligned memory operands. At runtime, syscall handlers with 8B aligned stack call into code that assumes 16B stack alignment. When the stack is a multiple of 8B but not 16B, these instructions result in a GPF. Remove the code that added compatibility between the differing compiler flags, as it will result in runtime GPFs when built with Clang. Cleanups for GCC will be sent in later patches in the series. Link: https://github.com/ClangBuiltLinux/linux/issues/735 Debugged-by: Yuxuan Shui Reported-by: Shirish S Reported-by: Yuxuan Shui Suggested-by: Andrew Cooper Signed-off-by: Nick Desaulniers Signed-off-by: Alex Deucher

drm/amd/display: add 50us buffer as WA for pstate switch in active

2019-10-30T15:56:15Z

Signed-off-by: Jun Lei Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher

drm/amdgpu: display_mode_vba_21: remove uint typedef

2019-10-02T17:58:33Z

The type definition for 'uint' clashes with the generic kernel headers: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:43:22: error: redefinition of typedef 'uint' is a C11 feature [-Werror,-Wtypedef-redefinition] include/linux/types.h:92:23: note: previous definition is here Just remove this type and use plain 'unsigned int' consistently, as it is already use almost everywhere in this file. Fixes: b04641a3f4c5 ("drm/amd/display: Add Renoir DML") Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher