1. 17 Nov, 2022 2 commits
  2. 13 Sep, 2022 2 commits
  3. 10 Aug, 2022 2 commits
  4. 25 Jul, 2022 2 commits
  5. 03 Jun, 2022 1 commit
  6. 26 May, 2022 1 commit
  7. 25 Mar, 2022 1 commit
  8. 15 Mar, 2022 2 commits
  9. 18 Jan, 2022 2 commits
  10. 28 Oct, 2021 2 commits
  11. 06 Oct, 2021 1 commit
  12. 06 Aug, 2021 1 commit
    • Rodrigo Siqueira's avatar
      drm/amd/display: Move specific DCN2x code that uses FPU to DML · c8b3538d
      Rodrigo Siqueira authored
      
      
      The display core files rely on FPU, which requires to be compiled with
      special flags. Ideally, we don't want these FPU operations spread around
      the DC code; nevertheless, it happens in the current source. This commit
      introduces a new directory inside DML for centralizing shared DCN
      functions that require FPU and have been used outside DML. For
      illustrating this process of transferring FPU functions to the DML
      folder, this commit moves one of the functions
      dcn20_populate_dml_writeback_from_context) that require FPU access to a
      single shared file. Notice that this is the first part of the work, and
      it does not fix the FPU issue yet; we still need other patches for
      achieving the complete FPU isolation.
      
      Changes since V3:
      - Jun: Instead of creating a new directory to keep the FPU code, let's
      make the DML folder the only part that requires FPU access. Drop
      fpu_operation folder.
      - Christian: Fix function code style.
      
      Changes since V2:
      - Christian: Remove unnecessary wrapper.
      - lkp: Add missing prototype.
      - Only compile the FPU operations if the DCN option is enabled.
      
      Change since V1:
      - Update documentation and rebase.
      
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Anson Jacob <Anson.Jacob@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Hersen Wu <hersenxs.wu@amd.com>
      Cc: Aric Cyr <aric.cyr@amd.com>
      Cc: Jun Lei <jun.lei@amd.com>
      Cc: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
      Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: Rodrigo Siqueira's avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c8b3538d
  13. 01 Jul, 2021 1 commit
    • Reka Norman's avatar
      drm/amd/display: Respect CONFIG_FRAME_WARN=0 in dml Makefile · 25f178bb
      Reka Norman authored
      
      
      Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
      warnings. This is useful for example in KASAN builds. Make the dml
      Makefile respect this config.
      
      Fixes the following build warnings with CONFIG_KASAN=y and
      CONFIG_FRAME_WARN=0:
      
      drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3642:6:
      warning: stack frame size of 2216 bytes in function
      'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
      drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3957:6:
      warning: stack frame size of 2568 bytes in function
      'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
      
      Reviewed-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: Reka Norman's avatarReka Norman <rekanorman@google.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      25f178bb
  14. 22 Jun, 2021 1 commit
  15. 04 Jun, 2021 1 commit
  16. 06 Jan, 2021 1 commit
    • Alex Deucher's avatar
      drm/amdgpu/display: drop DCN support for aarch64 · c241ed2f
      Alex Deucher authored
      
      
      From Ard:
      
      "Simply disabling -mgeneral-regs-only left and right is risky, given that
      the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
      and GCC is known to use SIMD registers for spilling, and may invent
      other uses of the FP/SIMD register file that have nothing to do with the
      floating point code in question. Note that putting kernel_neon_begin()
      and kernel_neon_end() around the code that does use FP is not sufficient
      here, the problem is in all the other code that may be emitted with
      references to SIMD registers in it.
      
      So the only way to do this properly is to put all floating point code in
      a separate compilation unit, and only compile that unit with
      -mgeneral-regs-only."
      
      Disable support until the code can be properly refactored to support this
      properly on aarch64.
      
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Reported-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c241ed2f
  17. 05 Jan, 2021 1 commit
    • Alex Deucher's avatar
      drm/amdgpu/display: drop DCN support for aarch64 · 88d5cb25
      Alex Deucher authored
      
      
      From Ard:
      
      "Simply disabling -mgeneral-regs-only left and right is risky, given that
      the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
      and GCC is known to use SIMD registers for spilling, and may invent
      other uses of the FP/SIMD register file that have nothing to do with the
      floating point code in question. Note that putting kernel_neon_begin()
      and kernel_neon_end() around the code that does use FP is not sufficient
      here, the problem is in all the other code that may be emitted with
      references to SIMD registers in it.
      
      So the only way to do this properly is to put all floating point code in
      a separate compilation unit, and only compile that unit with
      -mgeneral-regs-only."
      
      Disable support until the code can be properly refactored to support this
      properly on aarch64.
      
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Reported-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      88d5cb25
  18. 04 Nov, 2020 2 commits
  19. 10 Aug, 2020 1 commit
  20. 01 Jul, 2020 1 commit
  21. 21 May, 2020 1 commit
  22. 20 May, 2020 1 commit
  23. 18 Dec, 2019 1 commit
  24. 13 Nov, 2019 3 commits
  25. 30 Oct, 2019 3 commits
    • Nick Desaulniers's avatar
      drm/amdgpu: enable -msse2 for GCC 7.1+ users · e8a170ff
      Nick Desaulniers authored
      A final attempt at enabling sse2 for GCC users.
      
      Orininally attempted in:
      commit 10117450 ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
      
      Reverted due to "reported instability" in:
      commit 193392ed ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
      
      Re-added just for Clang in:
      commit 0f0727d9 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
      
      The original report didn't have enough information to know if the GPF
      was due to misalignment, but I suspect that it was. (The missing
      information was the disassembly of the function at the bottom of the
      trace, to see if the instruction pointer pointed to an instruction with
      16B alignment memory operand requirements.  The stack trace does show
      the stack was only 8B but not 16B aligned though, which makes this a
      strong possibility).
      
      Now that the stack misalignment issue has been fixed for users of GCC
      7.1+, reattempt adding -msse2. This matches Clang.
      
      It will likely never be safe to enable this for pre-GCC 7.1 AND use a
      16B aligned stack in these translation units.
      
      This is only a functional change for GCC 7.1+ users, and should be boot
      tested.
      
      Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
      
      
      Signed-off-by: Nick Desaulniers's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      e8a170ff
    • Nick Desaulniers's avatar
      drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+ · 00db2971
      Nick Desaulniers authored
      
      
      GCC earlier than 7.1 errors when compiling code that makes use of
      `double`s and sets a stack alignment outside of the range of [2^4-2^12]:
      
      $ cat foo.c
      double foo(double x, double y) {
        return x + y;
      }
      $ gcc-4.9 -mpreferred-stack-boundary=3 foo.c
      error: -mpreferred-stack-boundary=3 is not between 4 and 12
      
      This is likely why the AMDGPU driver was ever compiled with a different
      stack alignment (and thus different ABI) than the rest of the x86
      kernel. The kernel uses 8B stack alignment, while the driver was using
      16B stack alignment in a few places.
      
      Since GCC 7.1+ doesn't error, fix the ABI mismatch for users of newer
      versions of GCC.
      
      There was discussion about whether to mark the driver broken or not for
      users of GCC earlier than 7.1, but since the driver currently is
      working, don't explicitly break the driver for them here.
      
      Relying on differing stack alignment is unspecified behavior, and
      brittle, and may break in the future.
      
      This patch is no functional change for GCC users earlier than 7.1. It's
      been compile tested on GCC 4.9 and 8.3 to check the correct flags. It
      should be boot tested when built with GCC 7.1+.
      
      -mincoming-stack-boundary= or -mstackrealign may help keep this code
      building for pre-GCC 7.1 users.
      
      The version check for GCC is broken into two conditionals, both because
      cc-ifversion is currently GCC specific, and it simplifies a subsequent
      patch.
      
      Signed-off-by: Nick Desaulniers's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      00db2971
    • Nick Desaulniers's avatar
      drm/amdgpu: fix stack alignment ABI mismatch for Clang · c868868f
      Nick Desaulniers authored
      The x86 kernel is compiled with an 8B stack alignment via
      `-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
      commit d9b0cde9 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported")
      or `-mstack-alignment=8` for Clang. Parts of the AMDGPU driver are
      compiled with 16B stack alignment.
      
      Generally, the stack alignment is part of the ABI. Linking together two
      different translation units with differing stack alignment is dangerous,
      particularly when the translation unit with the smaller stack alignment
      makes calls into the translation unit with the larger stack alignment.
      While 8B aligned stacks are sometimes also 16B aligned, they are not
      always.
      
      Multiple users have reported General Protection Faults (GPF) when using
      the AMDGPU driver compiled with Clang. Clang is placing objects in stack
      slots assuming the stack is 16B aligned, and selecting instructions that
      require 16B aligned memory operands.
      
      At runtime, syscall handlers with 8B aligned stack call into code that
      assumes 16B stack alignment.  When the stack is a multiple of 8B but not
      16B, these instructions result in a GPF.
      
      Remove the code that added compatibility between the differing compiler
      flags, as it will result in runtime GPFs when built with Clang. Cleanups
      for GCC will be sent in later patches in the series.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/735
      
      
      Debugged-by: yshui's avatarYuxuan Shui <yshuiv7@gmail.com>
      Reported-by: Shirish S's avatarShirish S <shirish.s@amd.com>
      Reported-by: yshui's avatarYuxuan Shui <yshuiv7@gmail.com>
      Suggested-by: default avatarAndrew Cooper <andrew.cooper3@citrix.com>
      Signed-off-by: Nick Desaulniers's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c868868f
  26. 04 Sep, 2019 1 commit
    • Masahiro Yamada's avatar
      kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj) · 54b8ae66
      Masahiro Yamada authored
      
      
      Kbuild provides per-file compiler flag addition/removal:
      
        CFLAGS_<basetarget>.o
        CFLAGS_REMOVE_<basetarget>.o
        AFLAGS_<basetarget>.o
        AFLAGS_REMOVE_<basetarget>.o
        CPPFLAGS_<basetarget>.lds
        HOSTCFLAGS_<basetarget>.o
        HOSTCXXFLAGS_<basetarget>.o
      
      The <basetarget> is the filename of the target with its directory and
      suffix stripped.
      
      This syntax comes into a trouble when two files with the same basename
      appear in one Makefile, for example:
      
        obj-y += foo.o
        obj-y += dir/foo.o
        CFLAGS_foo.o := <some-flags>
      
      Here, the <some-flags> applies to both foo.o and dir/foo.o
      
      The real world problem is:
      
        scripts/kconfig/util.c
        scripts/kconfig/lxdialog/util.c
      
      Both files are compiled into scripts/kconfig/mconf, but only the
      latter should be given with the ncurses flags.
      
      It is more sensible to use the relative path to the Makefile, like this:
      
        obj-y += foo.o
        CFLAGS_foo.o := <some-flags>
        obj-y += dir/foo.o
        CFLAGS_dir/foo.o := <other-flags>
      
      At first, I attempted to replace $(basetarget) with $*. The $* variable
      is replaced with the stem ('%') part in a pattern rule. This works with
      most of cases, but does not for explicit rules.
      
      For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
      explicit rules, so $* will be empty, resulting in ignoring the per-file
      AFLAGS.
      
      I introduced a new variable, target-stem, which can be used also from
      explicit rules.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarMarc Zyngier <maz@kernel.org>
      54b8ae66
  27. 29 Aug, 2019 2 commits