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

[Estela ad Astra]

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 at 60Hz, 2560x1440 at 60Hz, 1920*1080 at 60Hz

Dual-screen: 3840x2160 at 60Hz on DP plus 2560x1440 at 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20221028/0c509308/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20221028/0c509308/attachment-0001.sig>