Repository navigation
arm64/loong/riscv: consider turning CONFIG_DRM_AMD_DC_FP back on for clang #2138
Description
I reached out to via the issue llvm/llvm-project#41896 (comment) in the llvm repo because the note in the kernel config points to that issue and specifically says that CONFIG_DRM_AMD_DC_FP is disabled, while the issue is not closed (which it is).
I built linux 6.17.1 on Gentoo arm64 llvm-musl-libcxx and amdgpu works, when I enable DRM_AMD_DC_FP (bugs.gentoo.org/964415). I'm not sure if my build has memory efficiency issues, but I definitely don't see "an immediate kernel panic".
I was sent here by nathanchance as per this llvm/llvm-project#41896 (comment):
Please open an issue at https://github.com/ClangBuiltLinux/linux/issues so that we can discussing turning
CONFIG_DRM_AMD_DC_FPback on forclangwith these architectures. I did some very basic quick testing and it seems like arm64 may be safe to re-enable right away whereas LoongArch and RISC-V may need admlport of commit e4479aecf658 ("drm/amd/display: Increase sanitizer frame larger than limit when compile testing with clang").
I kindly ask you to consider turning this feature back on!
--
Somewhat offtopic:
I'd like to provide some feedback on the flag itself: It has been quite hard to figure out, why amdgpu fails with a random error, since nothing in the logs nor the build points towards the fact that DCN based GPU don't work without CONFIG_DRM_AMD_DC_FP. I only got on the right track, once I swapped GPUs and saw that DCE cards work, whilst DCN not. Then I checked all the config items. CONFIG_DRM_AMD_DC_FP is also something that is set automatically, so there was not even a mismatch between requested and set flags. I think it would be great if there was a warning during build and a more meaningful error message from the driver. Something like "amdgpu DC is built without support for DCN (missing DC_FP)" and an error like "amdgpu: amdgpu_device_ip_init failed (no floiting point support)". I know this is technically feedback for upstream, but I'm not sure "how to mailinglist", but I know "how to Github Issue" ;)
Activity
nathanchance commentedon Oct 26, 2025
So the reason
CONFIG_DRM_AMD_DC_FPwas disabled for these architectures is the presence of-Wframe-larger-thanwhen building this code withclangwhen targeting these architectures, which can break the build withCONFIG_WERROR=yorW=e. When I test:with LLVM 21.1.4 and
ARCH=arm64 allmodconfig, I do see build breakage:This is particularly bad because of the sanitizers that get enabled with
allmodconfig, which we could workaround with something liketo mirror what I did in
dml2in commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml2").However, even without the sanitizers enabled, there are still some instances of these warnings
$ make -skj"$(nproc)" ARCH=arm64 LLVM=1 clean defconfig $ scripts/config -m DRM_AMDGPU $ make -skj"$(nproc)" ARCH=arm64 LLVM=1 olddefconfig drivers/gpu/drm/amd/amdgpu/ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3529:6: warning: stack frame size (2736) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] 3529 | void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 warning generated. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1724:6: warning: stack frame size (2336) exceeds limit (2048) in 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than] 1724 | void dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 warning generated. drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6715:12: warning: stack frame size (2272) exceeds limit (2048) in 'dml_core_mode_support' [-Wframe-larger-than] 6715 | dml_bool_t dml_core_mode_support(struct display_mode_lib_st *mode_lib) | ^ 1 warning generated.This would break my arm64 configuration with
or when LTO is disabled:
I can avoid this without any issues since all of my arm64 machines are headless but this will need some consideration before widely enabling this.
The AMD DRM folks use the Freedesktop Gitlab instance for issue tracking if I understand correctly so you could try bringing up this feedback to them there: https://gitlab.freedesktop.org/drm/amd/-/issues
peppergrayxyz commentedon Oct 27, 2025
Thanks for the detailed explanation! I'll reach out to the AMD folks.
What still puzzles me though, is that I see these warnings too, yet everything seems to work:
nathanchance commentedon Oct 27, 2025
It is entirely possible that either
These warnings are more flagging there is a potential problem, rather than a guaranteed one. That is why they are one of the most frustrating to solve, especially in this code because it is imported into the kernel from some internal AMD source that never sees that fixes that we put into the kernel for it.