Skip to content

L
linux
Switch branch/tag
  1. 24 Oct, 2022 27 commits
  3. 21 Oct, 2022 3 commits
  5. 18 Oct, 2022 5 commits
  7. 17 Oct, 2022 5 commits
    • Hamza Mahfooz's avatar
      drm/amd/display: add an ASSERT() to irq service functions · b3372fa7
      Hamza Mahfooz authored 
      Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues, for instance we
have had reports of this condition being triggered when removing a
secondary display that is setup in mirror mode and is connected using
usb-c. So, to have access to more detailed debugging information, add an
ASSERT() to dal_irq_service_ack() and dal_irq_service_set() that only
triggers when we encounter an unimplemented function.
Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
Signed-off-by: default avatarHamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      b3372fa7
    • Nathan Chancellor's avatar
      drm/amdkfd: Fix type of reset_type parameter in hqd_destroy() callback · e299b00a
      Nathan Chancellor authored 
      When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with
an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp():

  [   12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu] (target: hqd_destroy_v10_3+0x0/0x260 [amdgpu]; expected type: 0x8594d794)

Clang's kernel Control Flow Integrity (kCFI) makes sure that all
indirect call targets have a type that exactly matches the function
pointer prototype. In this case, hqd_destroy()'s third parameter,
reset_type, should have a type of 'uint32_t' but every implementation of
this callback has a third parameter type of 'enum kfd_preempt_type'.

Update the function pointer prototype to match reality so that there is
no more CFI violation.

Link: https://github.com/ClangBuiltLinux/linux/issues/1738Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      e299b00a
    • Fabio M. De Francesco's avatar
      drm/amd/amdgpu: Replace kmap() with kmap_local_page() · a2c55426
      Fabio M. De Francesco authored 
      kmap() is being deprecated in favor of kmap_local_page().

There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.

With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
the tasks can be preempted and, when they are scheduled to run again, the
kernel virtual addresses are restored and are still valid.

Since its use in amdgpu/amdgpu_ttm.c is safe, it should be preferred.

Therefore, replace kmap() with kmap_local_page() in amdgpu/amdgpu_ttm.c.
Suggested-by: default avatarIra Weiny <ira.weiny@intel.com>
Acked-by: default avatarChristian König <christian.koenig@amd.com>
Signed-off-by: default avatarFabio M. De Francesco <fmdefrancesco@gmail.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a2c55426
    • Fabio M. De Francesco's avatar
      drm/radeon: Replace kmap() with kmap_local_page() · cdabbde1
      Fabio M. De Francesco authored 
      The use of kmap() is being deprecated in favor of kmap_local_page().

There are two main problems with kmap(): (1) It comes with an overhead as
the mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.

With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
the tasks can be preempted and, when they are scheduled to run again, the
kernel virtual addresses are restored and still valid.

Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read().

Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
Suggested-by: default avatarIra Weiny <ira.weiny@intel.com>
Signed-off-by: default avatarFabio M. De Francesco <fmdefrancesco@gmail.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      cdabbde1
    • Guenter Roeck's avatar
      drm/amd/display: Increase frame size limit for display_mode_vba_util_32.o · 45950d88
      Guenter Roeck authored 
      Building 32-bit images may fail with the following error.

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
	In function ‘dml32_UseMinimumDCFCLK’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1:
	error: the frame size of 1096 bytes is larger than 1024 bytes

This is seen when building i386:allmodconfig with any of the following
compilers.

	gcc (Debian 12.2.0-3) 12.2.0
	gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

The problem is not seen if the compiler supports GCC_PLUGIN_LATENT_ENTROPY
because in that case CONFIG_FRAME_WARN is already set to 2048 even for
32-bit builds.

dml32_UseMinimumDCFCLK() was introduced with commit dda4fb85
("drm/amd/display: DML changes for DCN32/321"). It declares a large
number of local variables. Increase the frame size for the affected
file to 2048, similar to other files in the same directory, to enable
32-bit build tests with affected compilers.

Fixes: dda4fb85 ("drm/amd/display: DML changes for DCN32/321")
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reported-by: default avatarŁukasz Bartosik <ukaszb@google.com>
Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      45950d88
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7