Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 2月, 2022 1 次提交
  3. 30 12月, 2021 2 次提交
  5. 29 12月, 2021 1 次提交
  7. 02 12月, 2021 1 次提交
  9. 23 11月, 2021 1 次提交
  11. 18 11月, 2021 1 次提交
  13. 29 10月, 2021 2 次提交
  15. 07 10月, 2021 1 次提交
  17. 05 10月, 2021 1 次提交
  19. 28 9月, 2021 1 次提交
  21. 24 9月, 2021 2 次提交
    • J
      drm/amd/display: Fix dynamic encoder reassignment · 0d4b4253
      由 Jimmy Kizito 提交于 
      [Why]
Incorrect encoder assignments were being used while applying a new state
to hardware.

(1) When committing a new state to hardware requires resetting the
back-end, the encoder assignments of the current or old state should be
used when disabling the back-end; and the encoder assignments for the
next or new state should be used when re-enabling the back-end.

(2) Link training on hot plug could take over an encoder already in use
by another stream without first disabling it.

[How]

(1) Introduce a resource context 'link_enc_cfg_context' which includes:
- a mode to indicate when transitioning from current to next state.
- transient encoder assignments to use during this state transition.

Update the encoder configuration interface to respond to queries about
encoder assignment based on the mode of operation.

(2) Check if an encoder is already in use before attempting to perform
link training on hot plug.
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NJimmy Kizito <Jimmy.Kizito@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      0d4b4253
    • H
      drm/amd/display: Pass display_pipe_params_st as const in DML · 22667e6e
      由 Harry Wentland 提交于 
      [Why]
This neither needs to be on the stack nor passed by value
to each function call. In fact, when building with clang
it seems to break the Linux's default 1024 byte stack
frame limit.

[How]
We can simply pass this as a const pointer.

This patch fixes these Coverity IDs
Addresses-Coverity-ID: 1424031: ("Big parameter passed by value")
Addresses-Coverity-ID: 1423970: ("Big parameter passed by value")
Addresses-Coverity-ID: 1423941: ("Big parameter passed by value")
Addresses-Coverity-ID: 1451742: ("Big parameter passed by value")
Addresses-Coverity-ID: 1451887: ("Big parameter passed by value")
Addresses-Coverity-ID: 1454146: ("Big parameter passed by value")
Addresses-Coverity-ID: 1454152: ("Big parameter passed by value")
Addresses-Coverity-ID: 1454413: ("Big parameter passed by value")
Addresses-Coverity-ID: 1466144: ("Big parameter passed by value")
Addresses-Coverity-ID: 1487237: ("Big parameter passed by value")
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Fixes: 3fe617cc ("Enable '-Werror' by default for all kernel builds")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: amd-gfx@lists.freedesktop.org
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Xinhui Pan <Xinhui.Pan@amd.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: llvm@lists.linux.dev
Acked-by: NChristian König <christian.koenig@amd.com>
Build-tested-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      22667e6e
  23. 15 9月, 2021 1 次提交
  25. 02 9月, 2021 2 次提交
  27. 06 8月, 2021 2 次提交
    • R
      drm/amd/display: Add DC_FP helper to check FPU state · 0ea7ee82
      由 Rodrigo Siqueira 提交于 
      To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface from other files, the compiler
might enable the use of FPU before we call DC_FP_START. Nevertheless, it
is the programmer's responsibility to invoke DC_FP_START/END in the
correct place. To highlight situations where developers forgot to use
the FP protection before calling the DC FPU interface functions, we
introduce a helper that checks if the function is invoked under FP
protection. If not, it will trigger a kernel warning.

Changes cince V3:
- Rebase

Changes cince V2 (Christian):
- Do not use this_cpu_* between get/put_cpu_ptr().
- In the kernel documentation, better describe restrictions.
- Make dc_assert_fp_enabled trigger the ASSERT message.

Changes since V1:
- Remove fp_enable variables
- Rename dc_is_fp_enabled to dc_assert_fp_enabled
- Replace wrong variable type

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: Nkernel test robot <lkp@intel.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      0ea7ee82
    • R
      drm/amd/display: Move specific DCN2x code that uses FPU to DML · c8b3538d
      由 Rodrigo Siqueira 提交于 
      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: Nkernel test robot <lkp@intel.com>
Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      c8b3538d
  29. 23 7月, 2021 3 次提交
  31. 22 7月, 2021 3 次提交
  33. 23 6月, 2021 1 次提交
  35. 09 6月, 2021 2 次提交
  37. 05 6月, 2021 1 次提交
  39. 03 6月, 2021 1 次提交
  41. 28 5月, 2021 2 次提交
    • M
      drm/amd/display: Add support for SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616. · 050cd3d6
      由 Mario Kleiner 提交于 
      Add the necessary format definition, bandwidth and pixel size mappings,
prescaler setup, and pixelformat selection, following the logic
already present for SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616.

The new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 is implemented as the
old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616 format, but with swapped
red <-> green color channel, by use of the hardware xbar.

Please note that on the DCN 1/2/3 display engines, the pixelformat
in hubp and dpp setup for the old SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616
and the new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 was changed from
format id 22 to id 26. See amd/include/navi10_enum.h for the meaning
of the id's.

For format 22, the display engine read the framebuffer in 16 bpc format,
but truncated to the 12 bpc actually supported by later pipeline stages.
However, the engine took the 12 LSB of each color component for
truncation, which is incompatible with rendering at least under Vulkan,
where content is 16 bit wide, and a 12 MSB alignment would be appropriate,
if any. Format 20 for ARGB16161616_12MSB does work, but even better, we
can choose format 26 for ARGB16161616_UNORM, keeping all 16 bits around
until later stages of the display pipeline.

This allows to directly consume what the rendering hw produces under
Vulkan for swapchain format VK_FORMAT_R16G16B16A16_UNORM, as tested
with a patched version of the current AMD open-source amdvlk driver
which maps swapchain format VK_FORMAT_R16G16B16A16_UNORM onto
DRM_FORMAT_XBGR16161616.

The old id 22 would cause colorful pixeltrash to be displayed instead.

Tested under DCN-1.0 and DCE-11.2.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      050cd3d6
    • D
      drm/amd/display: fix odm scaling · 6566cae7
      由 Dmytro Laktyushkin 提交于 
      There are two issues with scaling calculations, odm recout
calculation and matching viewport to actual recout.

This change fixes both issues. Odm recout calculation via
special casing and viewport matching issue by reworking
the viewport calcualtion to use scaling ratios and recout
to derrive the required offset and size.
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NQingqing Zhuo <qingqing.zhuo@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6566cae7
  43. 22 5月, 2021 1 次提交
  45. 29 4月, 2021 1 次提交
  47. 16 4月, 2021 1 次提交
  49. 10 4月, 2021 4 次提交
  51. 24 3月, 2021 1 次提交