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, https://github.com/saeziae/pkgbuild-linux-phytium
)
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.
> 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)
Photos and video clips: https://t.me/esteladaily/334
Thank you for all you guys' excellent work.
On 27/10/2022 22:29, Rodrigo Siqueira
wrote:
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:
https://gitlab.freedesktop.org/drm/igt-gpu-tools
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:
On Thu, Oct 27, 2022, at 02:25, Ao Zhong wrote:
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.
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.
Signed-off-by: Ao Zhong <hacc1225@xxxxxxxxx>
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.
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
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
+
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)
Why do you need separate $(dml_rcflags) and $(dml_rcflags_arm64)
rather than adding -mgeneral-regs-only to $(dml_rcflags) directly?
Arnd
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
