[PATCH RESEND 1/1] drm/amd/display: add DCN support for ARM64

[Ao Zhong]

Hi Rodrigo,

I have done these tests.

CPU: Kunpeng 920 3211k x24 TSV110 Core

GPU: AMD RX 6400

Monitor on DP: Mi Curved Gaming Monitor 34" (support FreeSync and 3440x1440 at 144Hz on DP)

Monitor on HDMI: a cheap 1080P HDMI capture card (ID: 534d:2109)

Distro: Gentoo with Linux 6.0.5 kernel

Desktop Environment: KDE Plasma

KDE-Plasma-Version: 5.25.5

KDE-Frameworks-Version: 5.99.0

Qt-Version: 5.15.5

Graphics Platform: wayland

I tried to plug and unplug the monitor frequently and quickly on both HDMI and DP port.

Both port works very well. I've also tried various different resolutions on my monitor with no issues.

But I can't set my monitor's refresh rate to 144Hz at 3440x1440. With X11, the 144Hz option won't show up

in the system settings, even xrandr won't show this mode. But with wayland, I can set the refresh rate to 144Hz,

but it results in a black screen. Interestingly, under wayland, if I set the refresh rate to 120Hz, the system works

fine, and the monitor shows that the current refresh rate is 120Hz, but if I restart the system, after re-entering the

desktop, the monitor shows that the current refresh rate is 144Hz. Under X11, the current refresh rate showed

by the monitor is the same as that in system settings. I don't know if that is a hardware limitation of the rx6400

or a software bug.

Am 27.10.22 um 16:29 schrieb Rodrigo Siqueira:
> 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 at gmail.com>
>>
>> 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