<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hello. I have tested it on a Phytium D2000 platform with RX 5500 XT. Distro: Arch Linux ARM Kernel: Linux 6.0.5-1-phytium aarch64 (patched, <a class="moz-txt-link-freetext" href="https://github.com/saeziae/pkgbuild-linux-phytium">https://github.com/saeziae/pkgbuild-linux-phytium</a> ) Plug and unplug: OK on all ports. Resolutions tested: 3840x2160@60Hz, 2560x1440@60Hz, 1920*1080@60Hz Dual-screen: 3840x2160@60Hz on DP plus 2560x1440@60Hz on HDMI. Graphic applications: glxgears. 1080P video on MPV (VAAPI). Minecraft. IGT test: Most tests went well, with a few error logs. <blockquote>> cat kms_flip.log| grep FAIL Dynamic subtest A-HDMI-A1: FAIL (0.201s) Subtest absolute-wf_vblank: FAIL (29.571s) Dynamic subtest A-HDMI-A1: FAIL (0.172s) Subtest blocking-absolute-wf_vblank: FAIL (29.537s) Dynamic subtest A-HDMI-A1: FAIL (0.257s) Subtest blocking-absolute-wf_vblank-interruptible: FAIL (29.458s) </blockquote> Photos and video clips: <a class="moz-txt-link-freetext" href="https://t.me/esteladaily/334">https://t.me/esteladaily/334</a> Thank you for all you guys' excellent work. <div class="moz-cite-prefix">On 27/10/2022 22:29, Rodrigo Siqueira wrote: </div> <blockquote type="cite" cite="mid:8eb69dfb-ae35-dbf2-3f82-e8cc00e5389a@amd.com">Hi Ao/Arnd/Stephen/Nathan, Ao, Thanks a lot for this new patch. Since you have an ARM64 + AMD GPU, could you also run a couple of tests in your setup? If so, this is a good set of tests imho: 1. Check plug and unplug displays (let says 5x) 2. Change resolutions 3. (most wanted test) Could you run some IGT tests? About IGT, this is the official repository: <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/drm/igt-gpu-tools">https://gitlab.freedesktop.org/drm/igt-gpu-tools</a> It should be easy to run IGT in your system. Follow a brief summary: 1. Install dependencies (maybe I missed something) Debian apt install flex bison pkg-config x11proto-dri2-dev python-docutils valgrind peg libpciaccess-dev libkmod-dev libprocps-dev libunwind-dev libdw-dev zlib1g-dev liblzma-dev libcairo-dev libpixman-1-dev libudev-dev libgsl-dev libasound2-dev libjson-c-dev libcurl4-openssl-dev libxrandr-dev libxv-dev meson libdrm-dev qemu-user qemu-user-static ArchLinux pacman -S gcc flex bison pkg-config libpciaccess kmod procps-ng libunwind libdwarf zlib xz cairo pixman libudev0-shim gsl alsa-lib xmlrpc-c json-c curl libxrandr libxv xorgproto python-docutils valgrind peg meson libdrm libtool make autoconf automake gtk-doc python-docutils git vim sudo 2. Build IGT meson build && ninja -C build 3. Turn off your GUI (You must run IGT without any GUI) sudo systemctl isolate multi-user.target After run this command, you should see the TTY. 4. Try to run this IGT test sudo ./build/tests/kms_flip And let me know if this test looks ok for you. On 10/27/22 06:52, Arnd Bergmann wrote: <blockquote type="cite">On Thu, Oct 27, 2022, at 02:25, Ao Zhong wrote: <blockquote type="cite">After moving all FPU code to the DML folder, we can enable DCN support for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the code in the DML folder that needs to use hardware FPU, and add a control mechanism for ARM Neon. </blockquote> </blockquote> I recommend you to add the following info in your commit: 1. System that you use to validate this change (CPU name, monitor, distro, wayland/X, etc). 2. Describe the set of tests that you tried. <blockquote type="cite"> <blockquote type="cite"> Signed-off-by: Ao Zhong <a class="moz-txt-link-rfc2396E" href="mailto:hacc1225@gmail.com"><hacc1225@gmail.com></a> </blockquote> There have been problems with stack frame overflows on this code in the past, how much have you tested this with random configurations to see if we still hit them in corner cases on arm64 that may not show up on x86 or powerpc? I would expect to see a few more of them for every new architecture port. </blockquote> Hi Arnd, We followed your suggestion to isolate all FPU code inside a single place (DML), and we recently completed most of this task. As a result, all FPU flags are only used in the DML code. I guess we might have issues in other non-x86 platforms, but this is something that we can improve over time, and from Ao message, it looks like that DCN is working on ARM. At this point, my main concern is that enabling ARM64 may causes some compilation issues that we did not reproduce yet. I cross-compiled amd-staging-drm-next + this patch with aarch64-linux-gnu-gcc version 12.2.0 and everything looks fine. Nathan/Stephen, Maybe I'm wrong, but I think you have access to some sort of CI that tests multiple builds with different compiles and configs, right? Is it possible to check this patch + amd-staging-drm-next in the CI to help us to anticipate any compilation issue if we merge this change? Or should we merge it and wait until it gets merged on the mainline? In case of a problem, we can easily revert a small patch like this, right? Thanks Siqueira <blockquote type="cite"> <blockquote type="cite">index d0c6cf61c676..3cdd109189e0 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -33,6 +33,12 @@ ifdef CONFIG_PPC64 dml_ccflags := -mhard-float -maltivec endif +ifdef CONFIG_ARM64 +ifdef CONFIG_DRM_AMD_DC_DCN +dml_rcflags_arm64 := -mgeneral-regs-only +endif +endif + </blockquote> <blockquote type="cite"> CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calcs.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_auto.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := $(dml_ccflags) -Wno-tautological-compare -CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags) +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags) $(dml_rcflags_arm64) </blockquote> Why do you need separate $(dml_rcflags) and $(dml_rcflags_arm64) rather than adding -mgeneral-regs-only to $(dml_rcflags) directly? Arnd </blockquote> </blockquote> </body> </html>