Skip to content
GitLab
  1. 17 Nov, 2022 2 commits
  3. 13 Sep, 2022 2 commits
  5. 10 Aug, 2022 2 commits
  7. 25 Jul, 2022 2 commits
  9. 03 Jun, 2022 1 commit
  11. 26 May, 2022 1 commit
  13. 25 Mar, 2022 1 commit
  15. 15 Mar, 2022 2 commits
  17. 18 Jan, 2022 2 commits
  19. 28 Oct, 2021 2 commits
  21. 06 Oct, 2021 1 commit
  23. 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
  25. 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
  27. 22 Jun, 2021 1 commit
  29. 04 Jun, 2021 1 commit
  31. 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
  33. 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
  35. 04 Nov, 2020 2 commits
  37. 10 Aug, 2020 1 commit
  39. 01 Jul, 2020 1 commit
  41. 21 May, 2020 1 commit
  43. 20 May, 2020 1 commit
  45. 18 Dec, 2019 1 commit
  47. 13 Nov, 2019 3 commits
  49. 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
  51. 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
  53. 29 Aug, 2019 2 commits