Re: [PATCH] drm/amdgpu: use native mode for dp aux transfer
Hi Zhenneng,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v5.19 next-20220811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Zhenneng-Li/drm-amdgpu-use-native-mode-for-dp-aux-transfer/20220811-193443
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20220812/202208120737.jg7nkugc-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/1098c6fecb4292d634dbdccff9e720400dc7138d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Zhenneng-Li/drm-amdgpu-use-native-mode-for-dp-aux-transfer/20220811-193443
git checkout 1098c6fecb4292d634dbdccff9e720400dc7138d
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
drivers/gpu/drm/amd/amdgpu/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c:73:10: warning: no previous
>> prototype for 'venus_mm_rreg_slow' [-Wmissing-prototypes]
73 | uint32_t venus_mm_rreg_slow(struct amdgpu_device *adev, uint32_t reg)
| ^~
>> drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c:84:6: warning: no previous
>> prototype for 'venus_mm_wreg_slow' [-Wmissing-prototypes]
84 | void venus_mm_wreg_slow(struct amdgpu_device *adev, uint32_t reg,
uint32_t v)
| ^~
vim +/venus_mm_rreg_slow +73 drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c
69
70 #define R100_MM_INDEX 0x
71 #define R100_MM_DATA 0x0004
72 #define AMDGPU_MIN_MMIO_SIZE 0x1
> 73 uint32_t venus_mm_rreg_slow(struct amdgpu_device *adev, uint32_t reg)
74 {
75 unsigned long flags;
76 uint32_t ret;
77
78 spin_lock_irqsave(>mmio_idx_lock, flags);
79 writel(reg, ((void __iomem *)adev->rmmio) + R100_MM_INDEX);
80 ret = readl(((void __iomem *)adev->rmmio) + R100_MM_DATA);
81 spin_unlock_irqrestore(>mmio_idx_lock, flags);
82 return ret;
83 }
> 84 void venus_mm_wreg_slow(struct amdgpu_device *adev, uint32_t reg,
uint32_t v)
85 {
86 unsigned long flags;
87
88 spin_lock_irqsave(>mmio_idx_lock, flags);
89 writel(reg, ((void __iomem *)adev->rmmio) + R100_MM_INDEX);
90 writel(v, ((void __iomem *)adev->rmmio) + R100_MM_DATA);
91 spin_unlock_irqrestore(>mmio_idx_lock, flags);
92 }
93 static inline uint32_t venus_mm_rreg(struct amdgpu_device *adev,
uint32_t reg,
94 bool always_indirect)
95 {
96 /* The mmio size is 64kb at minimum. Allows the if to be
optimized out. */
97 if ((reg < adev->rmmio_size || reg < AMDGPU_MIN_MMIO_SIZE) &&
!always_indirect)
98 return readl(((void __iomem *)adev->rmmio) + reg);
99 else
100 return venus_mm_rreg_slow(adev, reg);
101 }
102 static inline void venus_mm_wreg(struct amdgpu_device *adev, uint32_t
reg, uint32_t v,
103 bool always_indirect)
104 {
105 if ((reg < adev->rmmio_size || reg < AMDGPU_MIN_MMIO_SIZE) &&
!always_indirect)
106 writel(v, ((void __iomem *)adev->rmmio) + reg);
107 else
108 venus_mm_wreg_slow(adev, reg, v);
109 }
110
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH] drm/amd/display: Remove unused code
On 2022-08-11 17:49, Alex Deucher wrote:
On Thu, Aug 11, 2022 at 5:11 PM Rodrigo Siqueira
wrote:
We have some old code associated with DML, which we had plans to use,
but at some point, we just moved away from it. This commit removes the
dml_wrapper* files since they are not used anymore.
Reported-by: Magali Lemes
Signed-off-by: Rodrigo Siqueira
Acked-by: Alex Deucher
Applied to amd-staging-drm-next.
Thanks,
Siqueira
---
.../gpu/drm/amd/display/dc/dml/dml_wrapper.c | 1884 -
.../display/dc/dml/dml_wrapper_translation.c | 284 ---
2 files changed, 2168 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
delete mode 100644
drivers/gpu/drm/amd/display/dc/dml/dml_wrapper_translation.c
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
b/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
deleted file mode 100644
index b4b51e51fc25..
--- a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
+++ /dev/null
@@ -1,1884 +0,0 @@
-/*
- * Copyright 2017 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#include "resource.h"
-#include "core_types.h"
-#include "dsc.h"
-#include "clk_mgr.h"
-
-#ifndef DC_LOGGER_INIT
-#define DC_LOGGER_INIT
-#undef DC_LOG_WARNING
-#define DC_LOG_WARNING
-#endif
-
-#define DML_WRAPPER_TRANSLATION_
-#include "dml_wrapper_translation.c"
-#undef DML_WRAPPER_TRANSLATION_
-
-static bool is_dual_plane(enum surface_pixel_format format)
-{
- return format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN || format ==
SURFACE_PIXEL_FORMAT_GRPH_RGBE_ALPHA;
-}
-
-static void build_clamping_params(struct dc_stream_state *stream)
-{
- stream->clamping.clamping_level = CLAMPING_FULL_RANGE;
- stream->clamping.c_depth = stream->timing.display_color_depth;
- stream->clamping.pixel_encoding = stream->timing.pixel_encoding;
-}
-
-static void get_pixel_clock_parameters(
- const struct pipe_ctx *pipe_ctx,
- struct pixel_clk_params *pixel_clk_params)
-{
- const struct dc_stream_state *stream = pipe_ctx->stream;
-
- /*TODO: is this halved for YCbCr 420? in that case we might want to move
-* the pixel clock normalization for hdmi up to here instead of doing it
-* in pll_adjust_pix_clk
-*/
- pixel_clk_params->requested_pix_clk_100hz =
stream->timing.pix_clk_100hz;
- pixel_clk_params->encoder_object_id = stream->link->link_enc->id;
- pixel_clk_params->signal_type = pipe_ctx->stream->signal;
- pixel_clk_params->controller_id = pipe_ctx->stream_res.tg->inst + 1;
- /* TODO: un-hardcode*/
- pixel_clk_params->requested_sym_clk = LINK_RATE_LOW *
- LINK_RATE_REF_FREQ_IN_KHZ;
- pixel_clk_params->flags.ENABLE_SS = 0;
- pixel_clk_params->color_depth =
- stream->timing.display_color_depth;
- pixel_clk_params->flags.DISPLAY_BLANKED = 1;
- pixel_clk_params->flags.SUPPORT_YCBCR420 =
(stream->timing.pixel_encoding ==
- PIXEL_ENCODING_YCBCR420);
- pixel_clk_params->pixel_encoding = stream->timing.pixel_encoding;
- if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR422) {
- pixel_clk_params->color_depth = COLOR_DEPTH_888;
- }
- if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR420) {
- pixel_clk_params->requested_pix_clk_100hz =
pixel_clk_params->requested_pix_clk_100hz / 2;
- }
- if (stream->timing.timing_3d_format ==
TIMING_3D_FORMAT_HW_FRAME_PACKING)
- pixel_clk_params->requested_pix_clk_100hz *= 2;
-
-}
-
-static void resource_build_bit_depth_reduction_params(struct dc_stream_state
*stream,
- struct bit_depth_reduction_params *fmt_bit_depth)
-{
- enum dc_dither_option option = stream->dither_option;
- enum dc_pixel_encoding
Re: [PATCH v2] drm/amd/display: Fix a compilation failure on PowerPC caused by FPU code
On 2022-08-11 17:49, Alex Deucher wrote:
On Thu, Aug 11, 2022 at 3:56 PM Rodrigo Siqueira
wrote:
We got a report from Stephen/Michael that the PowerPC build was failing
with the following error:
ld: drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o uses hard float,
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o uses soft float
ld: failed to merge target specific data of file
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o
This error happened because of the function optc3_set_vrr_m_const. This
function expects a double as a parameter in a code that is not allowed
to have FPU operations. After further investigation, it became clear
that optc3_set_vrr_m_const was never invoked, so we can safely drop this
function and fix the ld issue.
Changes since V1:
- Drop optc3_fpu_set_vrr_m_const since it is unused.
FWIW, I upstreamed v1 already. Can you rebase your v2 changes on that?
Hi Alex,
I guess the v1 was not merged into the amd-staging-drm-next. I just
applied the v1 there (waiting for CI result).
I also sent this patch:
https://lore.kernel.org/amd-gfx/cadnq5_oiqwc7reg8cj_s6ukhobv0zge-+9wo1cexojk+7zw...@mail.gmail.com/T/#t
Thanks
Siqueira
Alex
Cc: Alex Deucher
Cc: Melissa Wen
Cc: Maíra Canal
Reported-by: Stephen Rothwell
Reported-by: Michael Ellerman
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_optc.c | 8 --
.../gpu/drm/amd/display/dc/dcn30/dcn30_optc.h | 3 -
.../gpu/drm/amd/display/dc/dcn32/dcn32_optc.c | 1 -
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.c | 77 ---
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.h | 3 -
.../amd/display/dc/inc/hw/timing_generator.h | 2 -
6 files changed, 94 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
index d072997477dd..1782b9c26cf4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
@@ -184,14 +184,6 @@ void optc3_set_dsc_config(struct timing_generator *optc,
REG_UPDATE(OTG_V_SYNC_A_CNTL, OTG_V_SYNC_MODE, 0);
}
-void optc3_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg)
-{
- DC_FP_START();
- optc3_fpu_set_vrr_m_const(optc, vtotal_avg);
- DC_FP_END();
-}
-
void optc3_set_odm_bypass(struct timing_generator *optc,
const struct dc_crtc_timing *dc_crtc_timing)
{
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
index 33bd12f5dc17..dd45a5499b07 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
@@ -329,9 +329,6 @@ void optc3_lock_doublebuffer_enable(struct timing_generator
*optc);
void optc3_lock_doublebuffer_disable(struct timing_generator *optc);
-void optc3_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg);
-
void optc3_set_drr_trigger_window(struct timing_generator *optc,
uint32_t window_start, uint32_t window_end);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
index 9861be1dc063..1fad7b48bd5b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
@@ -281,7 +281,6 @@ static struct timing_generator_funcs dcn32_tg_funcs = {
.lock_doublebuffer_enable = optc3_lock_doublebuffer_enable,
.lock_doublebuffer_disable = optc3_lock_doublebuffer_disable,
.enable_optc_clock = optc1_enable_optc_clock,
- .set_vrr_m_const = optc3_set_vrr_m_const,
.set_drr = optc32_set_drr,
.get_last_used_drr_vtotal = optc2_get_last_used_drr_vtotal,
.set_vtotal_min_max = optc3_set_vtotal_min_max,
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
index e1e92daba668..814374b1016c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
@@ -177,83 +177,6 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_0_soc = {
.urgent_latency_adjustment_fabric_clock_reference_mhz = 1000,
};
-
-void optc3_fpu_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg)
-{
- struct optc *optc1 = DCN10TG_FROM_TG(optc);
- double vtotal_min, vtotal_max;
- double ratio, modulo, phase;
- uint32_t vblank_start;
- uint32_t v_total_mask_value = 0;
-
- dc_assert_fp_enabled();
-
- /* Compute VTOTAL_MIN and VTOTAL_MAX, so that
-* VOTAL_MAX - VTOTAL_MIN = 1
-*/
- v_total_mask_value = 16;
- vtotal_min = dcn_bw_floor(vtotal_avg);
- vtotal_max = dcn_bw_ceil(vtotal_avg);
-
- /* Check that bottom VBLANK is at least 2 lines tall when
[PATCH] drm/amd/display: Drop unused code
After removing some code for fixing the PowerPC compilation, we had some
leftover functions that are not used anymore. This commit drops
optc3_fpu_set_vrr_m_const since we don't need it anymore.
Signed-off-by: Rodrigo Siqueira
---
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.c | 77 ---
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.h | 3 -
2 files changed, 80 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
index e1e92daba668..814374b1016c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
@@ -177,83 +177,6 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_0_soc = {
.urgent_latency_adjustment_fabric_clock_reference_mhz = 1000,
};
-
-void optc3_fpu_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg)
-{
- struct optc *optc1 = DCN10TG_FROM_TG(optc);
- double vtotal_min, vtotal_max;
- double ratio, modulo, phase;
- uint32_t vblank_start;
- uint32_t v_total_mask_value = 0;
-
- dc_assert_fp_enabled();
-
- /* Compute VTOTAL_MIN and VTOTAL_MAX, so that
-* VOTAL_MAX - VTOTAL_MIN = 1
-*/
- v_total_mask_value = 16;
- vtotal_min = dcn_bw_floor(vtotal_avg);
- vtotal_max = dcn_bw_ceil(vtotal_avg);
-
- /* Check that bottom VBLANK is at least 2 lines tall when running with
-* VTOTAL_MIN. Note that VTOTAL registers are defined as 'total number
-* of lines in a frame - 1'.
-*/
- REG_GET(OTG_V_BLANK_START_END, OTG_V_BLANK_START,
- _start);
- ASSERT(vtotal_min >= vblank_start + 1);
-
- /* Special case where the average frame rate can be achieved
-* without using the DTO
-*/
- if (vtotal_min == vtotal_max) {
- REG_SET(OTG_V_TOTAL, 0, OTG_V_TOTAL, (uint32_t)vtotal_min);
-
- optc->funcs->set_vtotal_min_max(optc, 0, 0);
- REG_SET(OTG_M_CONST_DTO0, 0, OTG_M_CONST_DTO_PHASE, 0);
- REG_SET(OTG_M_CONST_DTO1, 0, OTG_M_CONST_DTO_MODULO, 0);
- REG_UPDATE_3(OTG_V_TOTAL_CONTROL,
- OTG_V_TOTAL_MIN_SEL, 0,
- OTG_V_TOTAL_MAX_SEL, 0,
- OTG_SET_V_TOTAL_MIN_MASK_EN, 0);
- return;
- }
-
- ratio = vtotal_max - vtotal_avg;
- modulo = 65536.0 * 65536.0 - 1.0; /* 2^32 - 1 */
- phase = ratio * modulo;
-
- /* Special cases where the DTO phase gets rounded to 0 or
-* to DTO modulo
-*/
- if (phase <= 0 || phase >= modulo) {
- REG_SET(OTG_V_TOTAL, 0, OTG_V_TOTAL,
- phase <= 0 ?
- (uint32_t)vtotal_max : (uint32_t)vtotal_min);
- REG_SET(OTG_V_TOTAL_MIN, 0, OTG_V_TOTAL_MIN, 0);
- REG_SET(OTG_V_TOTAL_MAX, 0, OTG_V_TOTAL_MAX, 0);
- REG_SET(OTG_M_CONST_DTO0, 0, OTG_M_CONST_DTO_PHASE, 0);
- REG_SET(OTG_M_CONST_DTO1, 0, OTG_M_CONST_DTO_MODULO, 0);
- REG_UPDATE_3(OTG_V_TOTAL_CONTROL,
- OTG_V_TOTAL_MIN_SEL, 0,
- OTG_V_TOTAL_MAX_SEL, 0,
- OTG_SET_V_TOTAL_MIN_MASK_EN, 0);
- return;
- }
- REG_UPDATE_6(OTG_V_TOTAL_CONTROL,
- OTG_V_TOTAL_MIN_SEL, 1,
- OTG_V_TOTAL_MAX_SEL, 1,
- OTG_SET_V_TOTAL_MIN_MASK_EN, 1,
- OTG_SET_V_TOTAL_MIN_MASK, v_total_mask_value,
- OTG_VTOTAL_MID_REPLACING_MIN_EN, 0,
- OTG_VTOTAL_MID_REPLACING_MAX_EN, 0);
- REG_SET(OTG_V_TOTAL, 0, OTG_V_TOTAL, (uint32_t)vtotal_min);
- optc->funcs->set_vtotal_min_max(optc, vtotal_min, vtotal_max);
- REG_SET(OTG_M_CONST_DTO0, 0, OTG_M_CONST_DTO_PHASE, (uint32_t)phase);
- REG_SET(OTG_M_CONST_DTO1, 0, OTG_M_CONST_DTO_MODULO, (uint32_t)modulo);
-}
-
void dcn30_fpu_populate_dml_writeback_from_context(
struct dc *dc, struct resource_context *res_ctx,
display_e2e_pipe_params_st *pipes)
{
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.h
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.h
index cab864095ce7..e3b6ad6a8784 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.h
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.h
@@ -29,9 +29,6 @@
#include "core_types.h"
#include "dcn20/dcn20_optc.h"
-void optc3_fpu_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg);
-
void dcn30_fpu_populate_dml_writeback_from_context(
struct dc *dc, struct resource_context *res_ctx,
display_e2e_pipe_params_st *pipes);
--
2.35.1
Re: [PATCH] drm/amd/display: Remove unused code
On Thu, Aug 11, 2022 at 5:11 PM Rodrigo Siqueira
wrote:
>
> We have some old code associated with DML, which we had plans to use,
> but at some point, we just moved away from it. This commit removes the
> dml_wrapper* files since they are not used anymore.
>
> Reported-by: Magali Lemes
> Signed-off-by: Rodrigo Siqueira
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/display/dc/dml/dml_wrapper.c | 1884 -
> .../display/dc/dml/dml_wrapper_translation.c | 284 ---
> 2 files changed, 2168 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
> delete mode 100644
> drivers/gpu/drm/amd/display/dc/dml/dml_wrapper_translation.c
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
> b/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
> deleted file mode 100644
> index b4b51e51fc25..
> --- a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
> +++ /dev/null
> @@ -1,1884 +0,0 @@
> -/*
> - * Copyright 2017 Advanced Micro Devices, Inc.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice shall be included in
> - * all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
> - *
> - * Authors: AMD
> - *
> - */
> -
> -#include "resource.h"
> -#include "core_types.h"
> -#include "dsc.h"
> -#include "clk_mgr.h"
> -
> -#ifndef DC_LOGGER_INIT
> -#define DC_LOGGER_INIT
> -#undef DC_LOG_WARNING
> -#define DC_LOG_WARNING
> -#endif
> -
> -#define DML_WRAPPER_TRANSLATION_
> -#include "dml_wrapper_translation.c"
> -#undef DML_WRAPPER_TRANSLATION_
> -
> -static bool is_dual_plane(enum surface_pixel_format format)
> -{
> - return format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN || format ==
> SURFACE_PIXEL_FORMAT_GRPH_RGBE_ALPHA;
> -}
> -
> -static void build_clamping_params(struct dc_stream_state *stream)
> -{
> - stream->clamping.clamping_level = CLAMPING_FULL_RANGE;
> - stream->clamping.c_depth = stream->timing.display_color_depth;
> - stream->clamping.pixel_encoding = stream->timing.pixel_encoding;
> -}
> -
> -static void get_pixel_clock_parameters(
> - const struct pipe_ctx *pipe_ctx,
> - struct pixel_clk_params *pixel_clk_params)
> -{
> - const struct dc_stream_state *stream = pipe_ctx->stream;
> -
> - /*TODO: is this halved for YCbCr 420? in that case we might want to
> move
> -* the pixel clock normalization for hdmi up to here instead of doing
> it
> -* in pll_adjust_pix_clk
> -*/
> - pixel_clk_params->requested_pix_clk_100hz =
> stream->timing.pix_clk_100hz;
> - pixel_clk_params->encoder_object_id = stream->link->link_enc->id;
> - pixel_clk_params->signal_type = pipe_ctx->stream->signal;
> - pixel_clk_params->controller_id = pipe_ctx->stream_res.tg->inst + 1;
> - /* TODO: un-hardcode*/
> - pixel_clk_params->requested_sym_clk = LINK_RATE_LOW *
> - LINK_RATE_REF_FREQ_IN_KHZ;
> - pixel_clk_params->flags.ENABLE_SS = 0;
> - pixel_clk_params->color_depth =
> - stream->timing.display_color_depth;
> - pixel_clk_params->flags.DISPLAY_BLANKED = 1;
> - pixel_clk_params->flags.SUPPORT_YCBCR420 =
> (stream->timing.pixel_encoding ==
> - PIXEL_ENCODING_YCBCR420);
> - pixel_clk_params->pixel_encoding = stream->timing.pixel_encoding;
> - if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR422) {
> - pixel_clk_params->color_depth = COLOR_DEPTH_888;
> - }
> - if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR420) {
> - pixel_clk_params->requested_pix_clk_100hz =
> pixel_clk_params->requested_pix_clk_100hz / 2;
> - }
> - if (stream->timing.timing_3d_format ==
> TIMING_3D_FORMAT_HW_FRAME_PACKING)
> - pixel_clk_params->requested_pix_clk_100hz *= 2;
> -
> -}
> -
> -static void resource_build_bit_depth_reduction_params(struct dc_stream_state
> *stream,
> - struct
Re: [PATCH v2] drm/amd/display: Fix a compilation failure on PowerPC caused by FPU code
On Thu, Aug 11, 2022 at 3:56 PM Rodrigo Siqueira
wrote:
>
> We got a report from Stephen/Michael that the PowerPC build was failing
> with the following error:
>
> ld: drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o uses hard float,
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o uses soft float
> ld: failed to merge target specific data of file
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o
>
> This error happened because of the function optc3_set_vrr_m_const. This
> function expects a double as a parameter in a code that is not allowed
> to have FPU operations. After further investigation, it became clear
> that optc3_set_vrr_m_const was never invoked, so we can safely drop this
> function and fix the ld issue.
>
> Changes since V1:
> - Drop optc3_fpu_set_vrr_m_const since it is unused.
FWIW, I upstreamed v1 already. Can you rebase your v2 changes on that?
Alex
>
> Cc: Alex Deucher
> Cc: Melissa Wen
> Cc: Maíra Canal
> Reported-by: Stephen Rothwell
> Reported-by: Michael Ellerman
> Signed-off-by: Rodrigo Siqueira
> ---
> .../gpu/drm/amd/display/dc/dcn30/dcn30_optc.c | 8 --
> .../gpu/drm/amd/display/dc/dcn30/dcn30_optc.h | 3 -
> .../gpu/drm/amd/display/dc/dcn32/dcn32_optc.c | 1 -
> .../drm/amd/display/dc/dml/dcn30/dcn30_fpu.c | 77 ---
> .../drm/amd/display/dc/dml/dcn30/dcn30_fpu.h | 3 -
> .../amd/display/dc/inc/hw/timing_generator.h | 2 -
> 6 files changed, 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
> b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
> index d072997477dd..1782b9c26cf4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
> @@ -184,14 +184,6 @@ void optc3_set_dsc_config(struct timing_generator *optc,
> REG_UPDATE(OTG_V_SYNC_A_CNTL, OTG_V_SYNC_MODE, 0);
> }
>
> -void optc3_set_vrr_m_const(struct timing_generator *optc,
> - double vtotal_avg)
> -{
> - DC_FP_START();
> - optc3_fpu_set_vrr_m_const(optc, vtotal_avg);
> - DC_FP_END();
> -}
> -
> void optc3_set_odm_bypass(struct timing_generator *optc,
> const struct dc_crtc_timing *dc_crtc_timing)
> {
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
> b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
> index 33bd12f5dc17..dd45a5499b07 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
> @@ -329,9 +329,6 @@ void optc3_lock_doublebuffer_enable(struct
> timing_generator *optc);
>
> void optc3_lock_doublebuffer_disable(struct timing_generator *optc);
>
> -void optc3_set_vrr_m_const(struct timing_generator *optc,
> - double vtotal_avg);
> -
> void optc3_set_drr_trigger_window(struct timing_generator *optc,
> uint32_t window_start, uint32_t window_end);
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> index 9861be1dc063..1fad7b48bd5b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
> @@ -281,7 +281,6 @@ static struct timing_generator_funcs dcn32_tg_funcs = {
> .lock_doublebuffer_enable = optc3_lock_doublebuffer_enable,
> .lock_doublebuffer_disable = optc3_lock_doublebuffer_disable,
> .enable_optc_clock = optc1_enable_optc_clock,
> - .set_vrr_m_const = optc3_set_vrr_m_const,
> .set_drr = optc32_set_drr,
> .get_last_used_drr_vtotal = optc2_get_last_used_drr_vtotal,
> .set_vtotal_min_max = optc3_set_vtotal_min_max,
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
> index e1e92daba668..814374b1016c 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
> @@ -177,83 +177,6 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_0_soc = {
> .urgent_latency_adjustment_fabric_clock_reference_mhz = 1000,
> };
>
> -
> -void optc3_fpu_set_vrr_m_const(struct timing_generator *optc,
> - double vtotal_avg)
> -{
> - struct optc *optc1 = DCN10TG_FROM_TG(optc);
> - double vtotal_min, vtotal_max;
> - double ratio, modulo, phase;
> - uint32_t vblank_start;
> - uint32_t v_total_mask_value = 0;
> -
> - dc_assert_fp_enabled();
> -
> - /* Compute VTOTAL_MIN and VTOTAL_MAX, so that
> -* VOTAL_MAX - VTOTAL_MIN = 1
> -*/
> - v_total_mask_value = 16;
> - vtotal_min = dcn_bw_floor(vtotal_avg);
> - vtotal_max = dcn_bw_ceil(vtotal_avg);
> -
> - /* Check that bottom VBLANK is at least 2 lines tall when running with
> -* VTOTAL_MIN. Note that VTOTAL registers are defined as 'total number
> -* of lines in a frame - 1'.
> -
[PATCH] drm/amd/display: Remove unused code
We have some old code associated with DML, which we had plans to use,
but at some point, we just moved away from it. This commit removes the
dml_wrapper* files since they are not used anymore.
Reported-by: Magali Lemes
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/dml/dml_wrapper.c | 1884 -
.../display/dc/dml/dml_wrapper_translation.c | 284 ---
2 files changed, 2168 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_wrapper_translation.c
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
b/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
deleted file mode 100644
index b4b51e51fc25..
--- a/drivers/gpu/drm/amd/display/dc/dml/dml_wrapper.c
+++ /dev/null
@@ -1,1884 +0,0 @@
-/*
- * Copyright 2017 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#include "resource.h"
-#include "core_types.h"
-#include "dsc.h"
-#include "clk_mgr.h"
-
-#ifndef DC_LOGGER_INIT
-#define DC_LOGGER_INIT
-#undef DC_LOG_WARNING
-#define DC_LOG_WARNING
-#endif
-
-#define DML_WRAPPER_TRANSLATION_
-#include "dml_wrapper_translation.c"
-#undef DML_WRAPPER_TRANSLATION_
-
-static bool is_dual_plane(enum surface_pixel_format format)
-{
- return format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN || format ==
SURFACE_PIXEL_FORMAT_GRPH_RGBE_ALPHA;
-}
-
-static void build_clamping_params(struct dc_stream_state *stream)
-{
- stream->clamping.clamping_level = CLAMPING_FULL_RANGE;
- stream->clamping.c_depth = stream->timing.display_color_depth;
- stream->clamping.pixel_encoding = stream->timing.pixel_encoding;
-}
-
-static void get_pixel_clock_parameters(
- const struct pipe_ctx *pipe_ctx,
- struct pixel_clk_params *pixel_clk_params)
-{
- const struct dc_stream_state *stream = pipe_ctx->stream;
-
- /*TODO: is this halved for YCbCr 420? in that case we might want to move
-* the pixel clock normalization for hdmi up to here instead of doing it
-* in pll_adjust_pix_clk
-*/
- pixel_clk_params->requested_pix_clk_100hz =
stream->timing.pix_clk_100hz;
- pixel_clk_params->encoder_object_id = stream->link->link_enc->id;
- pixel_clk_params->signal_type = pipe_ctx->stream->signal;
- pixel_clk_params->controller_id = pipe_ctx->stream_res.tg->inst + 1;
- /* TODO: un-hardcode*/
- pixel_clk_params->requested_sym_clk = LINK_RATE_LOW *
- LINK_RATE_REF_FREQ_IN_KHZ;
- pixel_clk_params->flags.ENABLE_SS = 0;
- pixel_clk_params->color_depth =
- stream->timing.display_color_depth;
- pixel_clk_params->flags.DISPLAY_BLANKED = 1;
- pixel_clk_params->flags.SUPPORT_YCBCR420 =
(stream->timing.pixel_encoding ==
- PIXEL_ENCODING_YCBCR420);
- pixel_clk_params->pixel_encoding = stream->timing.pixel_encoding;
- if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR422) {
- pixel_clk_params->color_depth = COLOR_DEPTH_888;
- }
- if (stream->timing.pixel_encoding == PIXEL_ENCODING_YCBCR420) {
- pixel_clk_params->requested_pix_clk_100hz =
pixel_clk_params->requested_pix_clk_100hz / 2;
- }
- if (stream->timing.timing_3d_format ==
TIMING_3D_FORMAT_HW_FRAME_PACKING)
- pixel_clk_params->requested_pix_clk_100hz *= 2;
-
-}
-
-static void resource_build_bit_depth_reduction_params(struct dc_stream_state
*stream,
- struct bit_depth_reduction_params *fmt_bit_depth)
-{
- enum dc_dither_option option = stream->dither_option;
- enum dc_pixel_encoding pixel_encoding =
- stream->timing.pixel_encoding;
-
- memset(fmt_bit_depth, 0, sizeof(*fmt_bit_depth));
-
- if (option == DITHER_OPTION_DEFAULT) {
-
Re: [PATCH 2/8] drm/amd/display: Introduce KUnit tests to the bw_fixed library
On 11/08/2022 04:34, David Gow wrote: On Thu, Aug 11, 2022 at 8:40 AM Tales Aparecida wrote: From: Maíra Canal KUnit unifies the test structure and provides helper tools that simplify the development of tests. Basic use case allows running tests as regular processes, which makes easier to run unit tests on a development machine and to integrate the tests in a CI system. This commit introduces a unit test to the bw_fixed library, which performs a lot of the mathematical operations involving fixed-point arithmetic and the conversion of integers to fixed-point representation inside the Display Mode Library. As fixed-point representation is the base foundation of the DML calcs operations, this unit tests intend to assure the proper functioning of the basic mathematical operations of fixed-point arithmetic, such as multiplication, conversion from fractional to fixed-point number, and more. You can run it with: ./tools/testing/kunit/kunit.py run \ --arch=x86_64 \ --kunitconfig=drivers/gpu/drm/amd/display/tests/ Signed-off-by: Maíra Canal Co-developed-by: Magali Lemes Signed-off-by: Magali Lemes Co-developed-by: Tales Aparecida Signed-off-by: Tales Aparecida --- Not directly related to this patch, but I get a whole stack of warnings about the definition of MIN_I64 causing integer overflow: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/../../../tests/dc/dml/calcs/bw_fixed_test.c:214:31: note: in expansion of macro ‘MIN_I64’ 214 | KUNIT_EXPECT_EQ(test, MIN_I64 + 1, res.value); | ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19: warning: integer overflow in expression ‘-9223372036854775808’ of type ‘long long int’ results in ‘-9223372036854775808’ [-Woverflow] 30 | (int64_t)(-(1LL << 63)) | ^ This seems to fix it (I'll re-send it out as a separate patch so gmail doesn't mangle it once I'm a bit more convinced it's the best implementation): Thanks! We were aware of this warnings, in fact there was a patch fixing this that got dropped in the last minute to expedite its review as a standalone patch, I'm sorry I didn't mention it in the cover letter. To make amends I've sent your approach to the mailing list, hope you don't mind! https://lore.kernel.org/all/20220811204327.411709-1-tales.aparec...@gmail.com/ --- 8< --- From 84e84664873dc9e98dff5ee9f74d95872e6cd423 Mon Sep 17 00:00:00 2001 From: David Gow Date: Thu, 11 Aug 2022 15:21:02 +0800 Subject: [PATCH] drm/amd/display: MIN_I64 definition causes overflow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The definition of MIN_I64 in bw_fixed.c can cause gcc to whinge about integer overflow, because it is treated as a positive value, which is then negated. The temporary postive value is not necessarily representable. This causes the following warning: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19: warning: integer overflow in expression ‘-9223372036854775808’ of type ‘long long int’ results in ‘-9223372036854775808’ [-Woverflow] 30 | (int64_t)(-(1LL << 63)) | ^ Writing out (INT_MIN - 1) - 1 works instead. Signed-off-by: David Gow --- drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c index fbe8d0661396..3850f7f0f679 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c @@ -26,12 +26,12 @@ #include "bw_fixed.h" -#define MIN_I64 \ - (int64_t)(-(1LL << 63)) - #define MAX_I64 \ (int64_t)((1ULL << 63) - 1) +#define MIN_I64 \ + (-MAX_I64 - 1) + #define FRACTIONAL_PART_MASK \ ((1ULL << BW_FIXED_BITS_PER_FRACTIONAL_PART) - 1) -- 2.37.1.595.g718a3a8f04-goog --- 8< --- Otherwise, this test seems to okay. I'll review it (and the series) more properly over then next few days. Cheers, -- David Thanks for reviewing, Tales
[PATCH 2/2] drm/amd/display: fix minor codestyle problems
Fixes five checkpatch warnings:
CHECK: Please don't use multiple blank lines
+
+
ERROR: Macros with complex values should be enclosed in parentheses
+#define MAX_I64 \
+ (int64_t)((1ULL << 63) - 1)
WARNING: Missing a blank line after declarations
+ struct bw_fixed res;
+ ASSERT(value < BW_FIXED_MAX_I32 && value > BW_FIXED_MIN_I32);
ERROR: that open brace { should be on the previous line
+ do
+ {
ERROR: that open brace { should be on the previous line
+ if (remainder >= arg2_value)
+ {
Signed-off-by: Tales Aparecida
---
drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c
b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c
index 2d46bc527b21..3aa8dd0acd5e 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c
@@ -25,9 +25,8 @@
#include "dm_services.h"
#include "bw_fixed.h"
-
#define MAX_I64 \
- (int64_t)((1ULL << 63) - 1)
+ ((int64_t)((1ULL << 63) - 1))
#define MIN_I64 \
(-MAX_I64 - 1)
@@ -49,6 +48,7 @@ static uint64_t abs_i64(int64_t arg)
struct bw_fixed bw_int_to_fixed_nonconst(int64_t value)
{
struct bw_fixed res;
+
ASSERT(value < BW_FIXED_MAX_I32 && value > BW_FIXED_MIN_I32);
res.value = value << BW_FIXED_BITS_PER_FRACTIONAL_PART;
return res;
@@ -78,14 +78,12 @@ struct bw_fixed bw_frc_to_fixed(int64_t numerator, int64_t
denominator)
{
uint32_t i = BW_FIXED_BITS_PER_FRACTIONAL_PART;
- do
- {
+ do {
remainder <<= 1;
res_value <<= 1;
- if (remainder >= arg2_value)
- {
+ if (remainder >= arg2_value) {
res_value |= 1;
remainder -= arg2_value;
}
--
2.37.0
[PATCH 1/2] drm/amd/display: fix overflow on MIN_I64 definition
From: David Gow The definition of MIN_I64 in bw_fixed.c can cause gcc to whinge about integer overflow, because it is treated as a positive value, which is then negated. The temporary positive value is not necessarily representable. This causes the following warning: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19: warning: integer overflow in expression ‘-9223372036854775808’ of type ‘long long int’ results in ‘-9223372036854775808’ [-Woverflow] 30 | (int64_t)(-(1LL << 63)) | ^ Writing out (-MAX_I64 - 1) works instead. Signed-off-by: David Gow Signed-off-by: Tales Aparecida --- drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c index 6ca288fb5fb9..2d46bc527b21 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c @@ -26,12 +26,12 @@ #include "bw_fixed.h" -#define MIN_I64 \ - (int64_t)(-(1LL << 63)) - #define MAX_I64 \ (int64_t)((1ULL << 63) - 1) +#define MIN_I64 \ + (-MAX_I64 - 1) + #define FRACTIONAL_PART_MASK \ ((1ULL << BW_FIXED_BITS_PER_FRACTIONAL_PART) - 1) -- 2.37.0
[PATCH 0/2] drm/amd/display: fix MIN_I64 overflow on bw_fixed.c
Hi, This series fixes an error accused by GCC and some checkpatch warnings. The first patch of this series fixes an error reported and fixed by David Gow (thanks!) at [1], where the macro MIN_I64 was used for the first time and warned about an integer overflow. The fix uses a similar syntax from include/vdso/limits.h To cause the error you can either apply that series or, for example, define a global variable: int64_t min_i64 = MIN_I64; The second patch fix lesser warnings in the same file. Thanks for the review! [1] https://lore.kernel.org/amd-gfx/CABVgOSmkeybnR2sGEEgn1Cb0cR2eKxW=vhxkhjc5xcuhaxs...@mail.gmail.com/ David Gow (1): drm/amd/display: fix overflow on MIN_I64 definition Tales Aparecida (1): drm/amd/display: fix minor codestyle problems .../gpu/drm/amd/display/dc/dml/calcs/bw_fixed.c| 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) base-commit: 1a60172c97fd2b51151cf17483f372bb61246c0b -- 2.37.0
[PATCH v2] drm/amd/display: Fix a compilation failure on PowerPC caused by FPU code
We got a report from Stephen/Michael that the PowerPC build was failing
with the following error:
ld: drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o uses hard float,
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o uses soft float
ld: failed to merge target specific data of file
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.o
This error happened because of the function optc3_set_vrr_m_const. This
function expects a double as a parameter in a code that is not allowed
to have FPU operations. After further investigation, it became clear
that optc3_set_vrr_m_const was never invoked, so we can safely drop this
function and fix the ld issue.
Changes since V1:
- Drop optc3_fpu_set_vrr_m_const since it is unused.
Cc: Alex Deucher
Cc: Melissa Wen
Cc: Maíra Canal
Reported-by: Stephen Rothwell
Reported-by: Michael Ellerman
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_optc.c | 8 --
.../gpu/drm/amd/display/dc/dcn30/dcn30_optc.h | 3 -
.../gpu/drm/amd/display/dc/dcn32/dcn32_optc.c | 1 -
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.c | 77 ---
.../drm/amd/display/dc/dml/dcn30/dcn30_fpu.h | 3 -
.../amd/display/dc/inc/hw/timing_generator.h | 2 -
6 files changed, 94 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
index d072997477dd..1782b9c26cf4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
@@ -184,14 +184,6 @@ void optc3_set_dsc_config(struct timing_generator *optc,
REG_UPDATE(OTG_V_SYNC_A_CNTL, OTG_V_SYNC_MODE, 0);
}
-void optc3_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg)
-{
- DC_FP_START();
- optc3_fpu_set_vrr_m_const(optc, vtotal_avg);
- DC_FP_END();
-}
-
void optc3_set_odm_bypass(struct timing_generator *optc,
const struct dc_crtc_timing *dc_crtc_timing)
{
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
index 33bd12f5dc17..dd45a5499b07 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
@@ -329,9 +329,6 @@ void optc3_lock_doublebuffer_enable(struct timing_generator
*optc);
void optc3_lock_doublebuffer_disable(struct timing_generator *optc);
-void optc3_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg);
-
void optc3_set_drr_trigger_window(struct timing_generator *optc,
uint32_t window_start, uint32_t window_end);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
index 9861be1dc063..1fad7b48bd5b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c
@@ -281,7 +281,6 @@ static struct timing_generator_funcs dcn32_tg_funcs = {
.lock_doublebuffer_enable = optc3_lock_doublebuffer_enable,
.lock_doublebuffer_disable = optc3_lock_doublebuffer_disable,
.enable_optc_clock = optc1_enable_optc_clock,
- .set_vrr_m_const = optc3_set_vrr_m_const,
.set_drr = optc32_set_drr,
.get_last_used_drr_vtotal = optc2_get_last_used_drr_vtotal,
.set_vtotal_min_max = optc3_set_vtotal_min_max,
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
index e1e92daba668..814374b1016c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/dcn30_fpu.c
@@ -177,83 +177,6 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_0_soc = {
.urgent_latency_adjustment_fabric_clock_reference_mhz = 1000,
};
-
-void optc3_fpu_set_vrr_m_const(struct timing_generator *optc,
- double vtotal_avg)
-{
- struct optc *optc1 = DCN10TG_FROM_TG(optc);
- double vtotal_min, vtotal_max;
- double ratio, modulo, phase;
- uint32_t vblank_start;
- uint32_t v_total_mask_value = 0;
-
- dc_assert_fp_enabled();
-
- /* Compute VTOTAL_MIN and VTOTAL_MAX, so that
-* VOTAL_MAX - VTOTAL_MIN = 1
-*/
- v_total_mask_value = 16;
- vtotal_min = dcn_bw_floor(vtotal_avg);
- vtotal_max = dcn_bw_ceil(vtotal_avg);
-
- /* Check that bottom VBLANK is at least 2 lines tall when running with
-* VTOTAL_MIN. Note that VTOTAL registers are defined as 'total number
-* of lines in a frame - 1'.
-*/
- REG_GET(OTG_V_BLANK_START_END, OTG_V_BLANK_START,
- _start);
- ASSERT(vtotal_min >= vblank_start + 1);
-
- /* Special case where the average frame rate can be achieved
-* without using the DTO
-*/
- if (vtotal_min == vtotal_max) {
- REG_SET(OTG_V_TOTAL, 0, OTG_V_TOTAL,
Re: [PATCH v2 1/3] Documentation/gpu: Add info table for ASICs
Hi Kent, First of all, thanks for your feedback. See my comments inline. On 2022-08-11 12:02, Russell, Kent wrote: [AMD Official Use Only - General] I noticed that you added DCE and VCE/UVD prefixes in the columns, but not GC or SDMA. E.g. CHIP DCE GC VCE SDMA BONAIREDCE 8 7VCE 2 / UVD 4.21 Are you referencing when I added it in some specific lines? If so, I added it because we may have a different architecture for the same area. For example, DCE is our old display architecture, and we replaced it with DCN. That's why I added DCE/DCN in the label, and in the ASIC description, I specify if it is a DCE or DCN. For consistency, should we drop the DCE/VCE/UVD prefixes and add a separate UVD column, so it's just: Iirc UVD is the previous version of VCE; in that case, I think they should be grouped. Or is UVD a different component? CHIP DCE GC VCEUVD SDMA BONAIRE8 7 VCE 2 4.2 1 ? I know that from a compute perspective, I'd like to have the columns represent the fields, so there's less to parse through, but I am not a display guy so the DCE/VCE/UVD relationship is a mystery to me. Also, for VG10 you have SDMA 4.0.0, but Polaris it's SDMA 3 . Again, just consistency with trailing decimals. I don't know if that's just because we didn't do point releases on SDMA <4 or whatnot, but it's something I observed. I also don't know if we have a good reason for not using the decimal part, but I can add it to all components if it makes sense. Maybe Alex know? Thanks Siqueira I am not staunchly steadfast one way or another, I just wanted to hear rationale for it. Especially if we're maintaining it going forward, and for when someone inevitably starts parsing it via automated script and needs consistency. If you're confident in the format and can justify it, then that's sufficient for me. Kent -Original Message- From: Siqueira, Rodrigo Sent: Thursday, August 11, 2022 11:48 AM To: amd-gfx@lists.freedesktop.org Cc: Wentland, Harry ; Kazlauskas, Nicholas ; Lakha, Bhawanpreet ; Wu, Hersen ; Hung, Alex ; Pelloux-Prayer, Pierre-Eric ; Li, Sun peng (Leo) ; Simon Ser ; Pekka Paalanen ; Sean Paul ; Mark Yacoub ; Pierre-Loup ; Michel Dänzer ; Russell, Kent Subject: [PATCH v2 1/3] Documentation/gpu: Add info table for ASICs Amdgpu driver is used in an extensive range of devices, and each ASIC has some specific configuration. As a result of this variety, sometimes it is hard to identify the correct block that might cause the issue. This commit expands the amdgpu kernel-doc to alleviate this issue by introducing one ASIC table that describes dGPU and another one that shares the APU info. Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Cc: Hersen Wu Cc: Alex Hung Cc: Pierre-Eric Pelloux-Prayer Cc: Leo Li Cc: Simon Ser Cc: Pekka Paalanen Cc: Sean Paul Cc: Mark Yacoub Cc: Pierre-Loup Cc: Michel Dänzer Cc: Kent Russell Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/apu-asic-info-table.csv| 8 +++ .../gpu/amdgpu/dgpu-asic-info-table.csv | 24 +++ Documentation/gpu/amdgpu/driver-misc.rst | 17 + 3 files changed, 49 insertions(+) create mode 100644 Documentation/gpu/amdgpu/apu-asic-info-table.csv create mode 100644 Documentation/gpu/amdgpu/dgpu-asic-info-table.csv diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv new file mode 100644 index ..98c6988e424e --- /dev/null +++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv @@ -0,0 +1,8 @@ +Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version +Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3 +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0 +Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2 +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1 +SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1 +Ryzen 5000 series, GREEN SARDINE, DCN 2.1, 9.3, VCN 2.2, 4.1.1 +Ryzen 6000 Zen, YELLOW CARP, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3 diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv new file mode 100644 index ..84617aa35dab --- /dev/null +++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv @@ -0,0 +1,24 @@ +Product Name, Code Reference, DCN/DCE version, GC version, VCN version, SDMA version +AMD Radeon (TM) HD 8500M/ 8600M /M200 /M320 /M330 /M335 Series, HAINAN, --, 6, --, -- +AMD Radeon HD 7800 /7900 /FireGL Series, TAHITI, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon R7 (TM|HD) M265 /M370 /8500M /8600 /8700 /8700M, OLAND, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon
[PATCH v2] drm/amdkfd: Try to schedule bottom half on same core
On systems that support SMT (hyperthreading) schedule the bottom half of
the KFD interrupt handler on the same core. This makes it possible to
reserve a core for interrupt handling and have the bottom half run on
that same core.
On systems without SMT, pick another core in the same NUMA node, as
before.
Use for_each_cpu_wrap instead of open-coding it.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index f5853835f03a..4d1284714e7a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "kfd_priv.h"
#include "kfd_device_queue_manager.h"
#include "kfd_pm4_headers_vi.h"
@@ -801,13 +802,24 @@ static inline void kfd_queue_work(struct workqueue_struct
*wq,
struct work_struct *work)
{
int cpu, new_cpu;
+ const struct cpumask *mask = NULL;
cpu = new_cpu = smp_processor_id();
- do {
- new_cpu = cpumask_next(new_cpu, cpu_online_mask) % nr_cpu_ids;
- if (cpu_to_node(new_cpu) == numa_node_id())
+
+#if defined(CONFIG_SCHED_SMT)
+ /* CPU threads in the same core */
+ mask = cpu_smt_mask(cpu);
+#endif
+ if (!mask || cpumask_weight(mask) <= 1)
+ /* CPU threads in the same NUMA node */
+ mask = cpu_cpu_mask(cpu);
+ /* Pick the next online CPU thread in the same core or NUMA node */
+ for_each_cpu_wrap(cpu, mask, cpu+1) {
+ if (cpu != new_cpu && cpu_online(cpu)) {
+ new_cpu = cpu;
break;
- } while (cpu != new_cpu);
+ }
+ }
queue_work_on(new_cpu, wq, work);
}
--
2.32.0
Re: [PATCH v2] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
On Thu, Aug 11, 2022 at 2:00 PM Hamza Mahfooz wrote:
>
> Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
> Fixes the following build errors on arm64:
> ERROR: modpost: "dc_dsc_get_policy_for_timing"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
> validation")
> Reported-by: Anders Roxell
> Signed-off-by: Hamza Mahfooz
Reviewed-by: Alex Deucher
> ---
> v2: Fix WERROR build failure by guarding unused variables
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index ef6c94cd852b..ce6929224a6e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -1387,8 +1387,6 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
> return (ret == 0);
> }
>
> -#endif
> -
> static unsigned int kbps_from_pbn(unsigned int pbn)
> {
> unsigned int kbps = pbn;
> @@ -1416,17 +1414,19 @@ static bool is_dsc_common_config_possible(struct
> dc_stream_state *stream,
>
> return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
> }
> +#endif /* CONFIG_DRM_AMD_DC_DCN */
>
> enum dc_status dm_dp_mst_is_port_support_mode(
> struct amdgpu_dm_connector *aconnector,
> struct dc_stream_state *stream)
> {
> + int bpp, pbn, branch_max_throughput_mps = 0;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> struct dc_link_settings cur_link_settings;
> unsigned int end_to_end_bw_in_kbps = 0;
> unsigned int upper_link_bw_in_kbps = 0, down_link_bw_in_kbps = 0;
> unsigned int max_compressed_bw_in_kbps = 0;
> struct dc_dsc_bw_range bw_range = {0};
> - int bpp, pbn, branch_max_throughput_mps = 0;
>
> /*
> * check if the mode could be supported if DSC pass-through is
> supported
> @@ -1461,13 +1461,16 @@ enum dc_status dm_dp_mst_is_port_support_mode(
> return DC_FAIL_BANDWIDTH_VALIDATE;
> }
> } else {
> +#endif
> /* check if mode could be supported within full_pbn */
> bpp =
> convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
> pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
> bpp, false);
>
> if (pbn > aconnector->port->full_pbn)
> return DC_FAIL_BANDWIDTH_VALIDATE;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> }
> +#endif
>
> /* check is mst dsc output bandwidth branch_overall_throughput_0_mps
> */
> switch (stream->timing.pixel_encoding) {
> --
> 2.37.1
>
Re: [PATCH v2] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
On Thu, 11 Aug 2022 at 20:00, Hamza Mahfooz wrote:
>
> Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
> Fixes the following build errors on arm64:
> ERROR: modpost: "dc_dsc_get_policy_for_timing"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
> validation")
> Reported-by: Anders Roxell
> Signed-off-by: Hamza Mahfooz
Thank you for the quick fix.
Tested-by: Anders Roxell
Cheers,
Anders
> ---
> v2: Fix WERROR build failure by guarding unused variables
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index ef6c94cd852b..ce6929224a6e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -1387,8 +1387,6 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
> return (ret == 0);
> }
>
> -#endif
> -
> static unsigned int kbps_from_pbn(unsigned int pbn)
> {
> unsigned int kbps = pbn;
> @@ -1416,17 +1414,19 @@ static bool is_dsc_common_config_possible(struct
> dc_stream_state *stream,
>
> return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
> }
> +#endif /* CONFIG_DRM_AMD_DC_DCN */
>
> enum dc_status dm_dp_mst_is_port_support_mode(
> struct amdgpu_dm_connector *aconnector,
> struct dc_stream_state *stream)
> {
> + int bpp, pbn, branch_max_throughput_mps = 0;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> struct dc_link_settings cur_link_settings;
> unsigned int end_to_end_bw_in_kbps = 0;
> unsigned int upper_link_bw_in_kbps = 0, down_link_bw_in_kbps = 0;
> unsigned int max_compressed_bw_in_kbps = 0;
> struct dc_dsc_bw_range bw_range = {0};
> - int bpp, pbn, branch_max_throughput_mps = 0;
>
> /*
> * check if the mode could be supported if DSC pass-through is
> supported
> @@ -1461,13 +1461,16 @@ enum dc_status dm_dp_mst_is_port_support_mode(
> return DC_FAIL_BANDWIDTH_VALIDATE;
> }
> } else {
> +#endif
> /* check if mode could be supported within full_pbn */
> bpp =
> convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
> pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
> bpp, false);
>
> if (pbn > aconnector->port->full_pbn)
> return DC_FAIL_BANDWIDTH_VALIDATE;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> }
> +#endif
>
> /* check is mst dsc output bandwidth branch_overall_throughput_0_mps
> */
> switch (stream->timing.pixel_encoding) {
> --
> 2.37.1
>
Re: [PATCH v2] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
On Thu, Aug 11, 2022 at 7:00 PM Hamza Mahfooz wrote:
>
> Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
> Fixes the following build errors on arm64:
> ERROR: modpost: "dc_dsc_get_policy_for_timing"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
> validation")
> Reported-by: Anders Roxell
> Signed-off-by: Hamza Mahfooz
Thanks, fixes the build failure for me,
Tested-by: Sudip Mukherjee
--
Regards
Sudip
[PATCH v2] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
Fixes the following build errors on arm64:
ERROR: modpost: "dc_dsc_get_policy_for_timing"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dc_dsc_compute_bandwidth_range"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
validation")
Reported-by: Anders Roxell
Signed-off-by: Hamza Mahfooz
---
v2: Fix WERROR build failure by guarding unused variables
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index ef6c94cd852b..ce6929224a6e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -1387,8 +1387,6 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
return (ret == 0);
}
-#endif
-
static unsigned int kbps_from_pbn(unsigned int pbn)
{
unsigned int kbps = pbn;
@@ -1416,17 +1414,19 @@ static bool is_dsc_common_config_possible(struct
dc_stream_state *stream,
return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
}
+#endif /* CONFIG_DRM_AMD_DC_DCN */
enum dc_status dm_dp_mst_is_port_support_mode(
struct amdgpu_dm_connector *aconnector,
struct dc_stream_state *stream)
{
+ int bpp, pbn, branch_max_throughput_mps = 0;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
struct dc_link_settings cur_link_settings;
unsigned int end_to_end_bw_in_kbps = 0;
unsigned int upper_link_bw_in_kbps = 0, down_link_bw_in_kbps = 0;
unsigned int max_compressed_bw_in_kbps = 0;
struct dc_dsc_bw_range bw_range = {0};
- int bpp, pbn, branch_max_throughput_mps = 0;
/*
* check if the mode could be supported if DSC pass-through is supported
@@ -1461,13 +1461,16 @@ enum dc_status dm_dp_mst_is_port_support_mode(
return DC_FAIL_BANDWIDTH_VALIDATE;
}
} else {
+#endif
/* check if mode could be supported within full_pbn */
bpp =
convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
bpp, false);
if (pbn > aconnector->port->full_pbn)
return DC_FAIL_BANDWIDTH_VALIDATE;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
}
+#endif
/* check is mst dsc output bandwidth branch_overall_throughput_0_mps */
switch (stream->timing.pixel_encoding) {
--
2.37.1
Re: build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
On Thu, Aug 11, 2022 at 6:16 PM Alex Deucher wrote:
>
> On Thu, Aug 11, 2022 at 1:11 PM Sudip Mukherjee (Codethink)
> wrote:
> >
> > Hi All,
> >
> > Not sure if it has been reported, builds of riscv, alpha, s390, arm,
> > arm64, xtensa, mips, csky allmodconfig have failed to build next-20220811
> > with the error:
> >
> > ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > ERROR: modpost: "dc_dsc_get_policy_for_timing"
> > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> >
> > git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC
> > pass-through during mode validation")
> > And, reverting that commit has fixed the build failure.
> >
> > I will be happy to test any patch or provide any extra log if needed.
>
> https://patchwork.freedesktop.org/patch/497116/
Thanks, that has fixed this failure. But it has now caused these new
errors resulting in a build failure.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:
In function 'dm_dp_mst_is_port_support_mode':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1427:32:
error: unused variable 'bw_range' [-Werror=unused-variable]
1427 | struct dc_dsc_bw_range bw_range = {0};
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1426:22:
error: unused variable 'max_compressed_bw_in_kbps'
[-Werror=unused-variable]
1426 | unsigned int max_compressed_bw_in_kbps = 0;
| ^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1425:49:
error: unused variable 'down_link_bw_in_kbps'
[-Werror=unused-variable]
1425 | unsigned int upper_link_bw_in_kbps = 0,
down_link_bw_in_kbps = 0;
| ^~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1425:22:
error: unused variable 'upper_link_bw_in_kbps'
[-Werror=unused-variable]
1425 | unsigned int upper_link_bw_in_kbps = 0,
down_link_bw_in_kbps = 0;
| ^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1424:22:
error: unused variable 'end_to_end_bw_in_kbps'
[-Werror=unused-variable]
1424 | unsigned int end_to_end_bw_in_kbps = 0;
| ^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:1423:33:
error: unused variable 'cur_link_settings' [-Werror=unused-variable]
1423 | struct dc_link_settings cur_link_settings;
--
Regards
Sudip
RE: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, August 4, 2022 5:55 AM
> To: Jouni Högander ; dri-
> de...@lists.freedesktop.org; intel-...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Siqueira, Rodrigo ; Li, Roman
> ; Manasi Navare ; Mika
> Kahola ; Jouni Högander
> ; Wentland, Harry
>
> Subject: Re: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance
> calculation function
>
> On Tue, 19 Jul 2022, Jouni Högander wrote:
> > Luminance range calculation was split out into drm_edid.c and is now
> > part of edid parsing. Rely on values calculated during edid parsing
> > and use these for caps->aux_max_input_signal and caps-
> >aux_min_input_signal.
>
> Harry, I'll merge patches 1 & 3 in this series through drm-misc-next, because
> I
> think they're good to go, and fix stuff in i915.
>
> Can I get your rb/ack to merge this patch as well, or do you want to take this
> later via your tree?
You can take this via drm-misc.
Acked-by: Alex Deucher
>
> BR,
> Jani.
>
>
> >
> > v2: Use values calculated during edid parsing
> >
> > Cc: Roman Li
> > Cc: Rodrigo Siqueira
> > Cc: Harry Wentland
> > Cc: Lyude Paul
> > Cc: Mika Kahola
> > Cc: Jani Nikula
> > Cc: Manasi Navare
> > Signed-off-by: Jouni Högander
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35
> > +++
> > 1 file changed, 4 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 3e83fed540e8..eb7abdeb8653 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs
> > amdgpu_dm_mode_config_helperfuncs = {
> >
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> > *aconnector) {
> > - u32 max_avg, min_cll, max, min, q, r;
> > struct amdgpu_dm_backlight_caps *caps;
> > struct amdgpu_display_manager *dm;
> > struct drm_connector *conn_base;
> > struct amdgpu_device *adev;
> > struct dc_link *link = NULL;
> > - static const u8 pre_computed_values[] = {
> > - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> > - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> > + struct drm_luminance_range_info *luminance_range;
> > int i;
> >
> > if (!aconnector || !aconnector->dc_link) @@ -2933,8 +2930,6 @@
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> *aconnector)
> > caps = >backlight_caps[i];
> > caps->ext_caps = >dc_link->dpcd_sink_ext_caps;
> > caps->aux_support = false;
> > - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> > - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
> >
> > if (caps->ext_caps->bits.oled == 1 /*||
> > caps->ext_caps->bits.sdr_aux_backlight_control == 1 || @@
> > -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> > else if (amdgpu_backlight == 1)
> > caps->aux_support = true;
> >
> > - /* From the specification (CTA-861-G), for calculating the maximum
> > -* luminance we need to use:
> > -* Luminance = 50*2**(CV/32)
> > -* Where CV is a one-byte value.
> > -* For calculating this expression we may need float point precision;
> > -* to avoid this complexity level, we take advantage that CV is divided
> > -* by a constant. From the Euclids division algorithm, we know that
> CV
> > -* can be written as: CV = 32*q + r. Next, we replace CV in the
> > -* Luminance expression and get 50*(2**q)*(2**(r/32)), hence we
> just
> > -* need to pre-compute the value of r/32. For pre-computing the
> values
> > -* We just used the following Ruby line:
> > -* (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> > -* The results of the above expressions can be verified at
> > -* pre_computed_values.
> > -*/
> > - q = max_avg >> 5;
> > - r = max_avg % 32;
> > - max = (1 << q) * pre_computed_values[r];
> > -
> > - // min luminance: maxLum * (CV/255)^2 / 100
> > - q = DIV_ROUND_CLOSEST(min_cll, 255);
> > - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> > -
> > - caps->aux_max_input_signal = max;
> > - caps->aux_min_input_signal = min;
> > + luminance_range = _base->display_info.luminance_range;
> > + caps->aux_min_input_signal = luminance_range->min_luminance;
> > + caps->aux_max_input_signal = luminance_range->max_luminance;
> > }
> >
> > void amdgpu_dm_update_connector_after_detect(
>
> --
> Jani Nikula, Intel Open Source Graphics Center
build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
Hi All,
Not sure if it has been reported, builds of riscv, alpha, s390, arm,
arm64, xtensa, mips, csky allmodconfig have failed to build next-20220811
with the error:
ERROR: modpost: "dc_dsc_compute_bandwidth_range"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dc_dsc_get_policy_for_timing"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through
during mode validation")
And, reverting that commit has fixed the build failure.
I will be happy to test any patch or provide any extra log if needed.
--
Regards
Sudip
Re: build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
On Thu, Aug 11, 2022 at 1:11 PM Sudip Mukherjee (Codethink)
wrote:
>
> Hi All,
>
> Not sure if it has been reported, builds of riscv, alpha, s390, arm,
> arm64, xtensa, mips, csky allmodconfig have failed to build next-20220811
> with the error:
>
> ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost: "dc_dsc_get_policy_for_timing"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC
> pass-through during mode validation")
> And, reverting that commit has fixed the build failure.
>
> I will be happy to test any patch or provide any extra log if needed.
https://patchwork.freedesktop.org/patch/497116/
Alex
>
>
> --
> Regards
> Sudip
Re: [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote: > > > On 8/3/22 15:56, jim.cro...@gmail.com wrote: > > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie wrote: > >> > > > >> Hi Jason, Greg, DRM-folk, > >> > >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' > >> means either DISJOINT (like drm debug categories), or VERBOSE (like > >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in > >> drivers i915, amdgpu, nouveau. > >> > > > > This revision fell over, on a conflict with something in drm-MUMBLE > > > > Error: patch > > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > > > not applied > > Applying: dyndbg: fix static_branch manipulation > > Applying: dyndbg: fix module.dyndbg handling > > Applying: dyndbg: show both old and new in change-info > > Applying: dyndbg: reverse module walk in cat control > > Applying: dyndbg: reverse module.callsite walk in cat control > > Applying: dyndbg: use ESCAPE_SPACE for cat control > > Applying: dyndbg: let query-modname override actual module name > > Applying: dyndbg: add test_dynamic_debug module > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > > > Jason, > > those above are decent maintenance patches, particularly the drop export. > > It would be nice to trim this unused api this cycle. > > Hi Jim, > > Agreed - I was thinking the same thing. Feel free to add > Acked-by: Jason Baron to those first 9. Does Greg KH usually pick up dyndbg patches or someone else or do I need to do something? Would be great to get some movement here since -rc1 goes out and merging will restart next week. -Daniel > > > > > > > Applying: dyndbg: add class_id to pr_debug callsites > > Applying: dyndbg: add __pr_debug_cls for testing > > Applying: dyndbg: add DECLARE_DYNDBG_CLASSMAP > > Applying: kernel/module: add __dyndbg_classes section > > Applying: dyndbg: add ddebug_attach_module_classes > > Applying: dyndbg: validate class FOO by checking with module > > Applying: dyndbg: add drm.debug style bitmap support > > Applying: dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes > > Applying: doc-dyndbg: describe "class CLASS_NAME" query support > > Applying: doc-dyndbg: edit dynamic-debug-howto for brevity, audience > > Applying: drm_print: condense enum drm_debug_category > > Applying: drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. > > Applying: drm_print: interpose drm_*dbg with forwarding macros > > Applying: drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro > > Using index info to reconstruct a base tree... > > M drivers/gpu/drm/Kconfig > > M drivers/gpu/drm/Makefile > > Falling back to patching base and 3-way merge... > > Auto-merging drivers/gpu/drm/Makefile > > Auto-merging drivers/gpu/drm/Kconfig > > CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig > > error: Failed to merge in the changes. > > > > > > Before I resend, I should sort out that possible conflict > > which tree is patchwork applied upon ? > > > > or was it just transient ? after 5.19 I rebased a copy onto > > drm-next/drm-next, > > and there was nothing to fix - I will revisit presently.. > > > Not sure, if it's a minor conflict maybe Greg KH can sort it when > he pulls it in? If not yeah might be important to rebase first...Greg? > > Thanks, > > -Jason -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/amdgpu: fix reset domain xgmi hive info reference leak
On 2022-08-11 11:34, Kim, Jonathan wrote:
[Public]
-Original Message-
From: Kuehling, Felix
Sent: August 11, 2022 11:19 AM
To: amd-gfx@lists.freedesktop.org; Kim, Jonathan
Subject: Re: [PATCH] drm/amdgpu: fix reset domain xgmi hive info reference
leak
Am 2022-08-11 um 09:42 schrieb Jonathan Kim:
When an xgmi node is added to the hive, it takes another hive
reference for its reset domain.
This extra reference was not dropped on device removal from the
hive so drop it.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 1b108d03e785..560bf1c98f08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -731,6 +731,9 @@ int amdgpu_xgmi_remove_device(struct
amdgpu_device *adev)
mutex_unlock(>hive_lock);
amdgpu_put_xgmi_hive(hive);
+ /* device is removed from the hive so remove its reset domain
reference */
+ if (adev->reset_domain && adev->reset_domain == hive-
reset_domain)
+ amdgpu_put_xgmi_hive(hive);
This is some messed up reference counting. If you need an extra
reference from the reset_domain to the hive, that should be owned by the
reset_domain and dropped when the reset_domain is destroyed. And it's
only one reference for the reset_domain, not one reference per adev in
the reset_domain.
Cc'ing Andrey.
What you're saying seems to make more sense to me, but what I got from an
offline conversation with Andrey
was that the reset domain reference per device was intentional.
Maybe Andrey can comment here.
What you're doing here looks like every adev that's in a reset_domain of
its hive has two references to the hive. And if you're dropping the
extra reference here, it still leaves the reset_domain with a dangling
pointer to a hive that may no longer exist. So this extra reference is
kind of pointless.
reset_domain doesn't have any references to the hive, the hive has a
reference to reset_domain
Yes. Currently one reference is fetched from the device's lifetime on the hive
and the other is from the
per-device reset domain.
Snippet from amdgpu_device_ip_init:
/**
* In case of XGMI grab extra reference for reset domain for this
device
*/
if (adev->gmc.xgmi.num_physical_nodes > 1) {
if (amdgpu_xgmi_add_device(adev) == 0) { <- [JK] reference is
fetched here
amdgpu_xgmi_add_device calls amdgpu_get_xgmi_hive and only on the first
time amdgpu_get_xgmi_hive is called and hive is actually allocated and
initialized will we proceed
to creating the reset domain either from scratch (first creation of the
hive) or by taking reference from adev (see [1])
[1] -
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c#L394
struct amdgpu_hive_info *hive =
amdgpu_get_xgmi_hive(adev); <- [JK] then here again
So here I don't see how an extra reference to reset_domain is taken if
amdgpu_get_xgmi_hive returns early since the hive already created and
exists in the global hive container ?
Johantan - can u please show the exact flow how recount leak on
reset_domain is happening ?
Andrey
if (!hive->reset_domain ||
!amdgpu_reset_get_reset_domain(hive->reset_domain)) {
r = -ENOENT;
goto init_failed;
}
/* Drop the early temporary reset domain we created
for device */
amdgpu_reset_put_reset_domain(adev->reset_domain);
adev->reset_domain = hive->reset_domain;
}
}
One of these never gets dropped so a leak happens.
So either the extra reference has to be dropped on device removal from the hive
or from what you've mentioned,
the reset_domain reference fetch should be fixed to grab at the
hive/reset_domain level.
Thanks,
Jon
Regards,
Felix
adev->hive = NULL;
if (atomic_dec_return(>number_devices) == 0) {
Re: [PATCH] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
On Thu, Aug 11, 2022 at 12:24 PM Hamza Mahfooz wrote:
>
> Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
> Fixes the following build errors on arm64:
> ERROR: modpost: "dc_dsc_get_policy_for_timing"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
> validation")
> Reported-by: Anders Roxell
> Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index ef6c94cd852b..0c52c0867211 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -1387,8 +1387,6 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
> return (ret == 0);
> }
>
> -#endif
> -
> static unsigned int kbps_from_pbn(unsigned int pbn)
> {
> unsigned int kbps = pbn;
> @@ -1416,6 +1414,7 @@ static bool is_dsc_common_config_possible(struct
> dc_stream_state *stream,
>
> return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
> }
> +#endif /* CONFIG_DRM_AMD_DC_DCN */
>
> enum dc_status dm_dp_mst_is_port_support_mode(
> struct amdgpu_dm_connector *aconnector,
> @@ -1428,6 +1427,7 @@ enum dc_status dm_dp_mst_is_port_support_mode(
> struct dc_dsc_bw_range bw_range = {0};
> int bpp, pbn, branch_max_throughput_mps = 0;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> /*
> * check if the mode could be supported if DSC pass-through is
> supported
> * AND check if there enough bandwidth available to support the mode
> @@ -1461,13 +1461,16 @@ enum dc_status dm_dp_mst_is_port_support_mode(
> return DC_FAIL_BANDWIDTH_VALIDATE;
> }
> } else {
> +#endif
> /* check if mode could be supported within full_pbn */
> bpp =
> convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
> pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
> bpp, false);
>
> if (pbn > aconnector->port->full_pbn)
> return DC_FAIL_BANDWIDTH_VALIDATE;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> }
> +#endif
>
> /* check is mst dsc output bandwidth branch_overall_throughput_0_mps
> */
> switch (stream->timing.pixel_encoding) {
> --
> 2.37.1
>
[PATCH] drm/amd/display: fix DSC related non-x86/PPC64 compilation issue
Need to protect DSC code with CONFIG_DRM_AMD_DC_DCN.
Fixes the following build errors on arm64:
ERROR: modpost: "dc_dsc_get_policy_for_timing"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dc_dsc_compute_bandwidth_range"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Fixes: 0087990a9f57 ("drm/amd/display: consider DSC pass-through during mode
validation")
Reported-by: Anders Roxell
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index ef6c94cd852b..0c52c0867211 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -1387,8 +1387,6 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
return (ret == 0);
}
-#endif
-
static unsigned int kbps_from_pbn(unsigned int pbn)
{
unsigned int kbps = pbn;
@@ -1416,6 +1414,7 @@ static bool is_dsc_common_config_possible(struct
dc_stream_state *stream,
return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
}
+#endif /* CONFIG_DRM_AMD_DC_DCN */
enum dc_status dm_dp_mst_is_port_support_mode(
struct amdgpu_dm_connector *aconnector,
@@ -1428,6 +1427,7 @@ enum dc_status dm_dp_mst_is_port_support_mode(
struct dc_dsc_bw_range bw_range = {0};
int bpp, pbn, branch_max_throughput_mps = 0;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
/*
* check if the mode could be supported if DSC pass-through is supported
* AND check if there enough bandwidth available to support the mode
@@ -1461,13 +1461,16 @@ enum dc_status dm_dp_mst_is_port_support_mode(
return DC_FAIL_BANDWIDTH_VALIDATE;
}
} else {
+#endif
/* check if mode could be supported within full_pbn */
bpp =
convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
bpp, false);
if (pbn > aconnector->port->full_pbn)
return DC_FAIL_BANDWIDTH_VALIDATE;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
}
+#endif
/* check is mst dsc output bandwidth branch_overall_throughput_0_mps */
switch (stream->timing.pixel_encoding) {
--
2.37.1
[PATCH AUTOSEL 4.9 02/12] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 197b157b73d0..0cb6eeb77b5f 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 4.14 02/14] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index ac467b80edc7..18a914752a32 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -749,7 +749,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 4.14 03/14] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 197b157b73d0..0cb6eeb77b5f 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 4.19 03/14] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 197b157b73d0..0cb6eeb77b5f 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 4.19 02/14] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 27d8e7dd2d06..733d9ff08c62 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -750,7 +750,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.4 08/25] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.4 07/25] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index b2b076606f54..cb7ef7ea7138 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -757,7 +757,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.10 29/46] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index 31a13daf4289..7172ec9a11d2 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3308,7 +3308,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.10 14/46] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index e738c7ae66ec..73bf38f513be 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.10 10/46] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index e5c4271e64ed..ac56d1dec214 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -758,7 +758,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.10 11/46] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.10 09/46] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index 3d778760a3b5..7289752d44ad 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1376,11 +1376,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.10 08/46] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index d617e98afb76..c6418462ecb0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -279,12 +279,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, >mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
>mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(>aux, DP_DP13_DPCD_REV,
_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(>aux,
DP_DPCD_REV, _rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.15 60/69] drm/amdkfd: Correct mmu_notifier_get failure handling
From: Philip Yang [ Upstream commit 0593ad215359d51514c1e6c81ce28ea598efed6b ] If process has signal pending, mmu_notifier_get_locked fails and calls ops->free_notifier, kfd_process_free_notifier will schedule kfd_process_wq_release as process refcount is 1, but process structure is already freed. This use after free bug causes system crash with different backtrace. The fix is to increase process refcount and then decrease the refcount after mmu_notifier_get success. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 21ec8a18cad2..bc502c378281 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -1340,6 +1340,11 @@ static struct kfd_process *create_process(const struct task_struct *thread) hash_add_rcu(kfd_processes_table, >kfd_processes, (uintptr_t)process->mm); + /* Avoid free_notifier to start kfd_process_wq_release if +* mmu_notifier_get failed because of pending signal. +*/ + kref_get(>ref); + /* MMU notifier registration must be the last call that can fail * because after this point we cannot unwind the process creation. * After this point, mmu_notifier_put will trigger the cleanup by @@ -1352,6 +1357,7 @@ static struct kfd_process *create_process(const struct task_struct *thread) } BUG_ON(mn != >mmu_notifier); + kfd_unref_process(process); get_task_struct(process->lead_thread); return process; -- 2.35.1
RE: [PATCH v2 1/3] Documentation/gpu: Add info table for ASICs
[AMD Official Use Only - General] I noticed that you added DCE and VCE/UVD prefixes in the columns, but not GC or SDMA. E.g. CHIP DCE GC VCE SDMA BONAIRE DCE 8 7VCE 2 / UVD 4.21 For consistency, should we drop the DCE/VCE/UVD prefixes and add a separate UVD column, so it's just: CHIP DCE GC VCEUVD SDMA BONAIRE 8 7 VCE 2 4.2 1 ? I know that from a compute perspective, I'd like to have the columns represent the fields, so there's less to parse through, but I am not a display guy so the DCE/VCE/UVD relationship is a mystery to me. Also, for VG10 you have SDMA 4.0.0, but Polaris it's SDMA 3 . Again, just consistency with trailing decimals. I don't know if that's just because we didn't do point releases on SDMA <4 or whatnot, but it's something I observed. I am not staunchly steadfast one way or another, I just wanted to hear rationale for it. Especially if we're maintaining it going forward, and for when someone inevitably starts parsing it via automated script and needs consistency. If you're confident in the format and can justify it, then that's sufficient for me. Kent > -Original Message- > From: Siqueira, Rodrigo > Sent: Thursday, August 11, 2022 11:48 AM > To: amd-gfx@lists.freedesktop.org > Cc: Wentland, Harry ; Kazlauskas, Nicholas > ; Lakha, Bhawanpreet > ; Wu, Hersen ; > Hung, Alex ; Pelloux-Prayer, Pierre-Eric eric.pelloux-pra...@amd.com>; Li, Sun peng (Leo) ; > Simon Ser ; Pekka Paalanen > ; Sean Paul ; Mark > Yacoub ; Pierre-Loup > ; Michel Dänzer > ; Russell, Kent > Subject: [PATCH v2 1/3] Documentation/gpu: Add info table for ASICs > > Amdgpu driver is used in an extensive range of devices, and each ASIC > has some specific configuration. As a result of this variety, sometimes > it is hard to identify the correct block that might cause the issue. > This commit expands the amdgpu kernel-doc to alleviate this issue by > introducing one ASIC table that describes dGPU and another one that > shares the APU info. > > Cc: Harry Wentland > Cc: Nicholas Kazlauskas > Cc: Bhawanpreet Lakha > Cc: Hersen Wu > Cc: Alex Hung > Cc: Pierre-Eric Pelloux-Prayer > Cc: Leo Li > Cc: Simon Ser > Cc: Pekka Paalanen > Cc: Sean Paul > Cc: Mark Yacoub > Cc: Pierre-Loup > Cc: Michel Dänzer > Cc: Kent Russell > Signed-off-by: Rodrigo Siqueira > --- > .../gpu/amdgpu/apu-asic-info-table.csv| 8 +++ > .../gpu/amdgpu/dgpu-asic-info-table.csv | 24 +++ > Documentation/gpu/amdgpu/driver-misc.rst | 17 + > 3 files changed, 49 insertions(+) > create mode 100644 Documentation/gpu/amdgpu/apu-asic-info-table.csv > create mode 100644 Documentation/gpu/amdgpu/dgpu-asic-info-table.csv > > diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv > b/Documentation/gpu/amdgpu/apu-asic-info-table.csv > new file mode 100644 > index ..98c6988e424e > --- /dev/null > +++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv > @@ -0,0 +1,8 @@ > +Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN > version, SDMA version > +Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3 > +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, > RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0 > +Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2 > +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, > RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1 > +SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1 > +Ryzen 5000 series, GREEN SARDINE, DCN 2.1, 9.3, VCN 2.2, 4.1.1 > +Ryzen 6000 Zen, YELLOW CARP, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3 > diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv > b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv > new file mode 100644 > index ..84617aa35dab > --- /dev/null > +++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv > @@ -0,0 +1,24 @@ > +Product Name, Code Reference, DCN/DCE version, GC version, VCN version, > SDMA version > +AMD Radeon (TM) HD 8500M/ 8600M /M200 /M320 /M330 /M335 Series, > HAINAN, --, 6, --, -- > +AMD Radeon HD 7800 /7900 /FireGL Series, TAHITI, DCE 6, 6, VCE 1 / UVD 3, -- > +AMD Radeon R7 (TM|HD) M265 /M370 /8500M /8600 /8700 /8700M, OLAND, > DCE 6, 6, VCE 1 / UVD 3, -- > +AMD Radeon (TM) (HD|R7) 7800 /7970 /8800 /8970 /370/ Series, PITCAIRN, > DCE 6, 6, VCE 1 / UVD 3, -- > +AMD Radeon (TM|R7|R9|HD) E8860 /M360 /7700 /7800 /8800 /9000(M) > /W4100 Series, VERDE, DCE 6, 6, VCE 1 / UVD 3, -- > +AMD Radeon HD M280X /M380 /7700 /8950 /W5100, BONAIRE, DCE 8, 7, VCE > 2 / UVD 4.2, 1 > +AMD Radeon (R9|TM) 200 /390 /W8100 /W9100 Series, HAWAII, DCE 8, 7, VCE > 2 / UVD 4.2, 1 > +AMD Radeon (TM) R(5|7) M315 /M340 /M360, TOPAZ, *, 8, --, 2 > +AMD Radeon (TM) R9 200 /380 /W7100 /S7150 /M390 /M395 Series, TONGA, > DCE 10, 8, VCE 3 / UVD 5, 3 > +AMD Radeon
[PATCH AUTOSEL 5.15 44/69] drm/amd/display: Guard against ddc_pin being NULL for AUX
From: Nicholas Kazlauskas
[ Upstream commit bc19909f19fdc8253d720d11c948935786fbfa08 ]
[Why]
In the case where we don't support DMUB aux but we have DPIA links
in the configuration we might try to message AUX using the legacy
path - where DDC pin is NULL. This causes a NULL pointer dereference.
[How]
Guard against NULL DDC pin, return a failure for aux engine acquire.
Reviewed-by: Michael Strauss
Acked-by: Rodrigo Siqueira
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 3c3347341103..ae9c0df1a844 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -563,6 +563,11 @@ int dce_aux_transfer_raw(struct ddc_service *ddc,
memset(_req, 0, sizeof(aux_req));
memset(_rep, 0, sizeof(aux_rep));
+ if (ddc_pin == NULL) {
+ *operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
+ return -1;
+ }
+
aux_engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
if (!acquire(aux_engine, ddc_pin)) {
*operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
--
2.35.1
[PATCH AUTOSEL 5.15 43/69] drm/amdgpu: skip whole ras bad page framework on sriov
From: "Stanley.Yang" [ Upstream commit e0e146d5567317d6ba7d0169bed55d1d9ea05a61 ] It should not init whole ras bad page framework on sriov guest side due to it is handled on host side. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 96a8fd0ca1df..adea3bfb0760 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -1964,7 +1964,7 @@ int amdgpu_ras_recovery_init(struct amdgpu_device *adev) bool exc_err_limit = false; int ret; - if (!con) + if (!con || amdgpu_sriov_vf(adev)) return 0; /* Allow access to RAS EEPROM via debugfs, when the ASIC -- 2.35.1
[PATCH AUTOSEL 5.15 41/69] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index 93f31e4aeecb..c55eb137bd81 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3142,7 +3142,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.15 36/69] amdgpu/pm: Fix possible array out-of-bounds if SCLK levels != 2
From: Darren Powell
[ Upstream commit ceb180361e3851007547c55035cd1de03f108f75 ]
[v2]
simplified fix after Lijo's feedback
removed clocks.num_levels from calculation of loop count
removed unsafe accesses to shim table freq_values
retained corner case output only min,now if
clocks.num_levels == 1 && now > min
[v1]
added a check to populate and use SCLK shim table freq_values only
if using dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL or
AMD_DPM_FORCED_LEVEL_PERF_DETERMINISM
removed clocks.num_levels from calculation of shim table size
removed unsafe accesses to shim table freq_values
output gfx_table values if using other dpm levels
added check for freq_match when using freq_values for when now == min_clk
== Test ==
LOGFILE=aldebaran-sclk.test.log
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
lspci -nn | grep "VGA\|Display" > $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk"
for f in $FILES
do
echo === $f === >> $LOGFILE
cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 34 +++
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index d0c6b864d00a..b82ef1e10018 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -729,7 +729,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
struct smu_13_0_dpm_table *single_dpm_table;
struct smu_dpm_context *smu_dpm = >smu_dpm;
struct smu_13_0_dpm_context *dpm_context = NULL;
- uint32_t display_levels;
+ int display_levels;
uint32_t freq_values[3] = {0};
uint32_t min_clk, max_clk;
@@ -761,7 +761,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
return ret;
}
- display_levels = clocks.num_levels;
+ display_levels = (clocks.num_levels == 1) ? 1 : 2;
min_clk = pstate_table->gfxclk_pstate.curr.min;
max_clk = pstate_table->gfxclk_pstate.curr.max;
@@ -771,30 +771,20 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
/* fine-grained dpm has only 2 levels */
if (now > min_clk && now < max_clk) {
- display_levels = clocks.num_levels + 1;
+ display_levels++;
freq_values[2] = max_clk;
freq_values[1] = now;
}
- /*
-* For DPM disabled case, there will be only one clock level.
-* And it's safe to assume that is always the current clock.
-*/
- if (display_levels == clocks.num_levels) {
- for (i = 0; i < clocks.num_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i],
- (clocks.num_levels == 1) ?
- "*" :
- (aldebaran_freqs_in_same_level(
-freq_values[i], now) ?
-"*" :
-""));
- } else {
- for (i = 0; i < display_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i], i == 1 ? "*" :
"");
- }
+ for (i = 0; i < display_levels; i++)
+ size += sysfs_emit_at(buf, size, "%d: %uMhz %s\n", i,
+ freq_values[i],
+ (display_levels == 1) ?
+ "*" :
+ (aldebaran_freqs_in_same_level(
+freq_values[i], now) ?
+"*" :
+""));
break;
--
2.35.1
[PATCH AUTOSEL 5.15 20/69] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index 1f4095b26409..c5f6c11de7e5 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.15 17/69] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.15 16/69] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index a36a4f2c76b0..774fabde21c3 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -829,7 +829,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.15 15/69] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index 9f8d7f92300b..3c7229befaaa 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1405,11 +1405,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.15 12/69] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 652cf108b3c2..424f4cfc0e04 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -335,12 +335,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, >mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
>mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(>aux, DP_DP13_DPCD_REV,
_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(>aux,
DP_DPCD_REV, _rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.15 11/69] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index c1532930169b..ac8442f6f4da 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -639,10 +639,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index aa8403bc4c83..0dac025f8f02 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -72,6 +72,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
[PATCH AUTOSEL 5.18 83/93] drm/amdkfd: Process notifier release callback don't take mutex
From: Philip Yang
[ Upstream commit 74097f9fd2f5ebdae04fcba59da345386415cbf3 ]
Move process queues cleanup to deferred work kfd_process_wq_release, to
avoid potential deadlock circular locking warning:
WARNING: possible circular locking dependency detected
the existing dependency chain (in reverse order) is:
-> #2
((work_completion)(>deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x343/0x4a0
svm_range_list_lock_and_flush_work+0x39/0xc0
svm_range_set_attr+0xe8/0x1080 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #1 (>lock#2){+.+.}-{3:3}:
__mutex_lock+0xa4/0x940
amdgpu_amdkfd_gpuvm_acquire_process_vm+0x2e3/0x590
kfd_process_device_init_vm+0x61/0x200 [amdgpu]
kfd_ioctl_acquire_vm+0x83/0xb0 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (>mutex){+.+.}-{3:3}:
__lock_acquire+0x1365/0x23d0
lock_acquire+0xc9/0x2e0
__mutex_lock+0xa4/0x940
kfd_process_notifier_release+0x96/0xe0 [amdgpu]
__mmu_notifier_release+0x94/0x210
exit_mmap+0x35/0x1f0
mmput+0x63/0x120
svm_range_deferred_list_work+0x177/0x2c0 [amdgpu]
process_one_work+0x2a4/0x600
worker_thread+0x39/0x3e0
kthread+0x16d/0x1a0
Possible unsafe locking scenario:
CPU0CPU1
lock((work_completion)(>deferred_list_work));
lock(>lock#2);
lock((work_completion)(>deferred_list_work));
lock(>mutex);
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 19d4089a0b1c..3f2383db1b73 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -,6 +,15 @@ static void kfd_process_wq_release(struct work_struct
*work)
struct kfd_process *p = container_of(work, struct kfd_process,
release_work);
+ kfd_process_dequeue_from_all_devices(p);
+ pqm_uninit(>pqm);
+
+ /* Signal the eviction fence after user mode queues are
+* destroyed. This allows any BOs to be freed without
+* triggering pointless evictions or waiting for fences.
+*/
+ dma_fence_signal(p->ef);
+
kfd_process_remove_sysfs(p);
kfd_iommu_unbind_process(p);
@@ -1175,20 +1184,8 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
cancel_delayed_work_sync(>eviction_work);
cancel_delayed_work_sync(>restore_work);
- mutex_lock(>mutex);
-
- kfd_process_dequeue_from_all_devices(p);
- pqm_uninit(>pqm);
-
/* Indicate to other users that MM is no longer valid */
p->mm = NULL;
- /* Signal the eviction fence after user mode queues are
-* destroyed. This allows any BOs to be freed without
-* triggering pointless evictions or waiting for fences.
-*/
- dma_fence_signal(p->ef);
-
- mutex_unlock(>mutex);
mmu_notifier_put(>mmu_notifier);
}
--
2.35.1
[PATCH AUTOSEL 5.18 82/93] drm/amdkfd: Correct mmu_notifier_get failure handling
From: Philip Yang [ Upstream commit 0593ad215359d51514c1e6c81ce28ea598efed6b ] If process has signal pending, mmu_notifier_get_locked fails and calls ops->free_notifier, kfd_process_free_notifier will schedule kfd_process_wq_release as process refcount is 1, but process structure is already freed. This use after free bug causes system crash with different backtrace. The fix is to increase process refcount and then decrease the refcount after mmu_notifier_get success. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 59c04b2d383b..19d4089a0b1c 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -1397,6 +1397,11 @@ static struct kfd_process *create_process(const struct task_struct *thread) hash_add_rcu(kfd_processes_table, >kfd_processes, (uintptr_t)process->mm); + /* Avoid free_notifier to start kfd_process_wq_release if +* mmu_notifier_get failed because of pending signal. +*/ + kref_get(>ref); + /* MMU notifier registration must be the last call that can fail * because after this point we cannot unwind the process creation. * After this point, mmu_notifier_put will trigger the cleanup by @@ -1409,6 +1414,7 @@ static struct kfd_process *create_process(const struct task_struct *thread) } BUG_ON(mn != >mmu_notifier); + kfd_unref_process(process); get_task_struct(process->lead_thread); return process; -- 2.35.1
[PATCH AUTOSEL 5.18 67/93] drm/amdgpu: Call trace info was found in dmesg when loading amdgpu
From: lin cao
[ Upstream commit 748262eb400e809aa13e3485f4983c3db3d0ebb3 ]
In the case of SRIOV, the register smnMp1_PMI_3_FIFO will get an invalid
value which will cause the "shift out of bound". In Ubuntu22.04, this
issue will be checked an related call trace will be reported in dmesg.
Signed-off-by: lin cao
Reviewed-by: Jingwen Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 7a1e225fb823..971a9712fa63 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -758,6 +758,7 @@ static void sienna_cichlid_stb_init(struct smu_context
*smu);
static int sienna_cichlid_init_smc_tables(struct smu_context *smu)
{
+ struct amdgpu_device *adev = smu->adev;
int ret = 0;
ret = sienna_cichlid_tables_init(smu);
@@ -768,7 +769,8 @@ static int sienna_cichlid_init_smc_tables(struct
smu_context *smu)
if (ret)
return ret;
- sienna_cichlid_stb_init(smu);
+ if (!amdgpu_sriov_vf(adev))
+ sienna_cichlid_stb_init(smu);
return smu_v11_0_init_smc_tables(smu);
}
--
2.35.1
[PATCH AUTOSEL 5.18 63/93] drm/amdgpu: fix file permissions on some files
From: Alex Deucher [ Upstream commit 0a94608f0f7de9b1135ffea3546afe68eafef57f ] Drop execute. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085 Reviewed-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h| 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h | 0 6 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h old mode 100755 new mode 100644 -- 2.35.1
[PATCH AUTOSEL 5.18 54/93] drm/amd/display: disable otg toggle w/a on boot
From: Dmytro Laktyushkin
[ Upstream commit 8a077d9caa3a274de36ee2fe7b608041f5690343 ]
This w/a has a bad interaction with seamless boot toggling an
active stream. Most panels recover, however some fail leading
to display corruption.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by: Dmytro Laktyushkin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index 2918ad07d489..8f8680e89a8f 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -173,11 +173,14 @@ static void dcn315_update_clocks(struct clk_mgr
*clk_mgr_base,
}
if (should_set_clock(safe_to_lower, new_clocks->dispclk_khz,
clk_mgr_base->clks.dispclk_khz)) {
- dcn315_disable_otg_wa(clk_mgr_base, true);
+ /* No need to apply the w/a if we haven't taken over from bios
yet */
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, true);
clk_mgr_base->clks.dispclk_khz = new_clocks->dispclk_khz;
dcn315_smu_set_dispclk(clk_mgr, clk_mgr_base->clks.dispclk_khz);
- dcn315_disable_otg_wa(clk_mgr_base, false);
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, false);
update_dispclk = true;
}
--
2.35.1
[PATCH v2 2/3] Documentation/gpu: Add an explanation about the DCN pipeline
In the DCN code, we constantly talk about hardware pipeline, pipeline, or even just pipes, which is a concept that is not obvious to everyone. For this reason, this commit expands the DCN overview explanation by adding a new section that describes what a pipeline is from the DCN perspective. Changes since V1: - Rewrite the first paragraph that describes AMD hardware pipeline. Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Cc: Hersen Wu Cc: Alex Hung Cc: Pierre-Eric Pelloux-Prayer Cc: Leo Li Cc: Simon Ser Cc: Pekka Paalanen Cc: Sean Paul Cc: Mark Yacoub Cc: Pierre-Loup Cc: Michel Dänzer Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/display/dcn-overview.rst | 59 + .../amdgpu/display/pipeline_4k_no_split.svg | 958 +++ .../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 + 3 files changed, 2079 insertions(+) create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.svg diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst index f98624d7828e..9fea6500448b 100644 --- a/Documentation/gpu/amdgpu/display/dcn-overview.rst +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -124,6 +124,65 @@ depth format), bit-depth reduction/dithering would kick in. In OPP, we would also apply a regamma function to introduce the gamma removed earlier back. Eventually, we output data in integer format at DIO. +AMD Hardware Pipeline +- + +When discussing graphics on Linux, the **pipeline** term can sometimes be +overloaded with multiple meanings, so it is important to define what we mean +when we say **pipeline**. In the DCN driver, we use the term **hardware +pipeline** or **pipeline** or just **pipe** as an abstraction to indicate a +sequence of DCN blocks instantiated to address some specific configuration. DC +core treats DCN blocks as individual resources, meaning we can build a pipeline +by taking resources for all individual hardware blocks to compose one pipeline. +In actuality, we can't connect an arbitrary block from one pipe to a block from +another pipe; they are routed linearly, except for DSC, which can be +arbitrarily assigned as needed. We have this pipeline concept for trying to +optimize bandwidth utilization. + +.. kernel-figure:: pipeline_4k_no_split.svg + +Additionally, let's take a look at parts of the DTN log (see +'Documentation/gpu/amdgpu/display/dc-debug.rst' for more information) since +this log can help us to see part of this pipeline behavior in real-time:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 38402160 + [ 1]: 0h 0h 0 0 + [ 2]: 0h 0h 0 0 + [ 3]: 0h 0h 0 0 + [ 4]: 0h 0h 0 0 + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + +The first thing to notice from the diagram and DTN log it is the fact that we +have different clock domains for each part of the DCN blocks. In this example, +we have just a single **pipeline** where the data flows from DCHUB to DIO, as +we intuitively expect. Nonetheless, DCN is flexible, as mentioned before, and +we can split this single pipe differently, as described in the below diagram: + +.. kernel-figure:: pipeline_4k_split.svg + +Now, if we inspect the DTN log again we can see some interesting changes:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 19202160 ... + ... + [ 4]: 0h 0h 0 0 ... + [ 5]: 8h 81h 19202160 ... + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + [ 5]: 0h 5h ... + +From the above example, we now split the display pipeline into two vertical +parts of 1920x2160 (i.e., 3440x2160), and as a result, we could reduce the +clock frequency in the DPP part. This is not only useful for saving power but +also to better handle the required throughput. The idea to keep in mind here is +that the pipe configuration can vary a lot according to the display +configuration, and it is the DML's responsibility to set up all required +configuration parameters for multiple scenarios supported by our hardware. + Global Sync --- diff --git a/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg new file mode 100644 index ..5fa289d99fcd --- /dev/null +++ b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg @@ -0,0 +1,958 @@ + + + +http://purl.org/dc/elements/1.1/; + xmlns:cc="http://creativecommons.org/ns#; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg="http://www.w3.org/2000/svg; + xmlns="http://www.w3.org/2000/svg; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; + width="1055.4928" + height="404.60379" +
[PATCH v2 3/3] Documentation/gpu: Add Multiplane Overlay doc
Multiple plane overlay is a feature supported by AMD hardware, but it has specific details that deserve proper documentation. This commit introduces a documentation that describes some of the features, limitations, and use cases for this feature. Part of this documentation came from some discussion in the public upstream [1][2]. [1]. https://lore.kernel.org/amd-gfx/3qY-QeukF_Q_MJeIXAuBjO4szbS4jRtqkTifXnbnN3bp88SxVodFQRpah3mIIVJq24DUkF6g0rOGdCmSqTvVxx9LCGEItmzLw8uWU44jtXE=@emersion.fr/ [2]. https://lore.kernel.org/amd-gfx/864e45d0-c14b-3b12-0f5b-9d26a9cb4...@amd.com/ Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Cc: Hersen Wu Cc: Alex Hung Cc: Pierre-Eric Pelloux-Prayer Cc: Simon Ser Cc: Pekka Paalanen Cc: Sean Paul Cc: Mark Yacoub Cc: Leo Li Cc: Pierre-Loup Cc: Michel Dänzer Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/display/index.rst| 1 + .../gpu/amdgpu/display/mpo-cursor.svg | 435 ++ .../gpu/amdgpu/display/mpo-overview.rst | 242 ++ .../multi-display-hdcp-mpo-less-pipe-ex.svg | 220 + .../amdgpu/display/multi-display-hdcp-mpo.svg | 171 +++ .../single-display-mpo-multi-video.svg| 339 ++ .../gpu/amdgpu/display/single-display-mpo.svg | 266 +++ 7 files changed, 1674 insertions(+) create mode 100644 Documentation/gpu/amdgpu/display/mpo-cursor.svg create mode 100644 Documentation/gpu/amdgpu/display/mpo-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo.svg diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index c1fb2fb3c710..f8a4f53d70d8 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -28,4 +28,5 @@ table of content: display-manager.rst dc-debug.rst dcn-overview.rst + mpo-overview.rst dc-glossary.rst diff --git a/Documentation/gpu/amdgpu/display/mpo-cursor.svg b/Documentation/gpu/amdgpu/display/mpo-cursor.svg new file mode 100644 index ..9d9de76847c3 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-cursor.svg @@ -0,0 +1,435 @@ + + + +http://purl.org/dc/elements/1.1/; + xmlns:cc="http://creativecommons.org/ns#; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg="http://www.w3.org/2000/svg; + xmlns="http://www.w3.org/2000/svg; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; + width="160.5318mm" + height="65.443306mm" + viewBox="0 0 160.5318 65.443308" + version="1.1" + id="svg843" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="mpo-cursor.svg"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage; /> + + + + + + + + Cursor + + + + Plane 1 + + + + Plane 2 + + + + +CRTC + + + +Cursor + + + +Plane 1 + + + +Plane 2 + + + +CRTC + + DRM + AMD Hardware + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst new file mode 100644 index ..0499aa92d08d --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst @@ -0,0 +1,242 @@ + +Multiplane Overlay (MPO) + + +.. note:: You will get more from this page if you have already read the + 'Documentation/gpu/amdgpu/display/dcn-overview.rst'. + + +Multiplane Overlay (MPO) allows for multiple framebuffers to be composited via +fixed-function hardware in the display controller rather than using graphics or +compute shaders for composition. This can yield some power savings if it means +the graphics/compute pipelines can be put into low-power states. In summary, +MPO can bring the following benefits: + +* Decreased GPU and CPU workload - no composition shaders needed, no extra + buffer copy needed, GPU can remain idle. +* Plane independent page flips - No need to be tied to global compositor + page-flip present rate, reduced latency, independent timing. + +.. note:: Keep in mind that MPO is all about power-saving; if you want to learn + more about power-save in the display context, check the link:
[PATCH v2 1/3] Documentation/gpu: Add info table for ASICs
Amdgpu driver is used in an extensive range of devices, and each ASIC has some specific configuration. As a result of this variety, sometimes it is hard to identify the correct block that might cause the issue. This commit expands the amdgpu kernel-doc to alleviate this issue by introducing one ASIC table that describes dGPU and another one that shares the APU info. Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Cc: Hersen Wu Cc: Alex Hung Cc: Pierre-Eric Pelloux-Prayer Cc: Leo Li Cc: Simon Ser Cc: Pekka Paalanen Cc: Sean Paul Cc: Mark Yacoub Cc: Pierre-Loup Cc: Michel Dänzer Cc: Kent Russell Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/apu-asic-info-table.csv| 8 +++ .../gpu/amdgpu/dgpu-asic-info-table.csv | 24 +++ Documentation/gpu/amdgpu/driver-misc.rst | 17 + 3 files changed, 49 insertions(+) create mode 100644 Documentation/gpu/amdgpu/apu-asic-info-table.csv create mode 100644 Documentation/gpu/amdgpu/dgpu-asic-info-table.csv diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv new file mode 100644 index ..98c6988e424e --- /dev/null +++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv @@ -0,0 +1,8 @@ +Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version +Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3 +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0 +Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2 +Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1 +SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1 +Ryzen 5000 series, GREEN SARDINE, DCN 2.1, 9.3, VCN 2.2, 4.1.1 +Ryzen 6000 Zen, YELLOW CARP, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3 diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv new file mode 100644 index ..84617aa35dab --- /dev/null +++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv @@ -0,0 +1,24 @@ +Product Name, Code Reference, DCN/DCE version, GC version, VCN version, SDMA version +AMD Radeon (TM) HD 8500M/ 8600M /M200 /M320 /M330 /M335 Series, HAINAN, --, 6, --, -- +AMD Radeon HD 7800 /7900 /FireGL Series, TAHITI, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon R7 (TM|HD) M265 /M370 /8500M /8600 /8700 /8700M, OLAND, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon (TM) (HD|R7) 7800 /7970 /8800 /8970 /370/ Series, PITCAIRN, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon (TM|R7|R9|HD) E8860 /M360 /7700 /7800 /8800 /9000(M) /W4100 Series, VERDE, DCE 6, 6, VCE 1 / UVD 3, -- +AMD Radeon HD M280X /M380 /7700 /8950 /W5100, BONAIRE, DCE 8, 7, VCE 2 / UVD 4.2, 1 +AMD Radeon (R9|TM) 200 /390 /W8100 /W9100 Series, HAWAII, DCE 8, 7, VCE 2 / UVD 4.2, 1 +AMD Radeon (TM) R(5|7) M315 /M340 /M360, TOPAZ, *, 8, --, 2 +AMD Radeon (TM) R9 200 /380 /W7100 /S7150 /M390 /M395 Series, TONGA, DCE 10, 8, VCE 3 / UVD 5, 3 +AMD Radeon (FirePro) (TM) R9 Fury Series, FIJI, DCE 10, 8, VCE 3 / UVD 6, 3 +Radeon RX 470 /480 /570 /580 /590 Series - AMD Radeon (TM) (Pro WX) 5100 /E9390 /E9560 /E9565 /V7350 /7100 /P30PH, POLARIS10, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3 +Radeon (TM) (RX|Pro WX) E9260 /460 /V5300X /550 /560(X) Series, POLARIS11, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3 +Radeon (RX/Pro) 500 /540(X) /550 /640 /WX2100 /WX3100 /WX200 Series, POLARIS12, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3 +Radeon (RX|TM) (PRO|WX) Vega /MI25 /V320 /V340L /8200 /9100 /SSG MxGPU, VEGA10, DCE 12, 9.0.1, VCE 4.0.0 / UVD 7.0.0, 4.0.0 +AMD Radeon (Pro) VII /MI50 /MI60, VEGA20, DCE 12, 9.4.0, VCE 4.1.0 / UVD 7.2.0, 4.2.0 +MI100, ARCTURUS, *, 9.4.1, VCN 2.5.0, 4.2.2 +MI200, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0 +AMD Radeon (RX|Pro) 5600(M|XT) /5700 (M|XT|XTB) /W5700, NAVI10, DCN 2.0.0, 10.1.10, VCN 2.0.0, 5.0.0 +AMD Radeon (Pro) 5300 /5500XTB/5500(XT|M) /W5500M /W5500, NAVI14, DCN 2.0.0, 10.1.1, VCN 2.0.2, 5.0.2 +AMD Radeon RX 6800(XT) /6900(XT) /W6800, SIENNA_CICHLID, DCN 3.0.0, 10.3.0, VCN 3.0.0, 5.2.0 +AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0.0, 5.2.2 +AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4 +AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5 diff --git a/Documentation/gpu/amdgpu/driver-misc.rst b/Documentation/gpu/amdgpu/driver-misc.rst index e3d6b2fa2493..1800543d45f7 100644 --- a/Documentation/gpu/amdgpu/driver-misc.rst +++ b/Documentation/gpu/amdgpu/driver-misc.rst @@ -32,6 +32,23 @@ unique_id .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: unique_id +Accelerated Processing Units (APU) Info +--- + +.. csv-table:: + :header-rows: 1 + :widths: 3, 2, 2, 1, 1, 1 + :file: ./apu-asic-info-table.csv + +Discrete GPU Info
[PATCH v2 0/3] Expand amdgpu documentation
This patchset introduces some new AMDGPU documentation. You will find: 1. A CSV table that maps which component version is part of some ASIC families. This can be useful to narrow down bugs; 2. Some explanation about AMD Display Pipeline; 3. An explanation of Multiple Plane Overlay, which can be useful for userspace applications. Since we have some diagrams, I recommend applying these patches and building the documentation to have a better experience. In this new version, I just rebased this patchset with the latest code from amd-staging-drm-next, and I also changed patch 2. Thanks Siqueira Rodrigo Siqueira (3): Documentation/gpu: Add info table for ASICs Documentation/gpu: Add an explanation about the DCN pipeline Documentation/gpu: Add Multiplane Overlay doc .../gpu/amdgpu/apu-asic-info-table.csv|8 + .../gpu/amdgpu/dgpu-asic-info-table.csv | 24 + .../gpu/amdgpu/display/dcn-overview.rst | 59 + Documentation/gpu/amdgpu/display/index.rst|1 + .../gpu/amdgpu/display/mpo-cursor.svg | 435 +++ .../gpu/amdgpu/display/mpo-overview.rst | 242 .../multi-display-hdcp-mpo-less-pipe-ex.svg | 220 .../amdgpu/display/multi-display-hdcp-mpo.svg | 171 +++ .../amdgpu/display/pipeline_4k_no_split.svg | 958 +++ .../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 + .../single-display-mpo-multi-video.svg| 339 ++ .../gpu/amdgpu/display/single-display-mpo.svg | 266 + Documentation/gpu/amdgpu/driver-misc.rst | 17 + 13 files changed, 3802 insertions(+) create mode 100644 Documentation/gpu/amdgpu/apu-asic-info-table.csv create mode 100644 Documentation/gpu/amdgpu/dgpu-asic-info-table.csv create mode 100644 Documentation/gpu/amdgpu/display/mpo-cursor.svg create mode 100644 Documentation/gpu/amdgpu/display/mpo-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo.svg -- 2.35.1
[PATCH AUTOSEL 5.18 53/93] drm/amd/display: Fix dmub soft hang for PSR 1
From: Fangzhi Zuo [ Upstream commit 22676bc500c27d987a0b42cbe162aebf783f1c38 ] [Why] Unexpected change of aux hw mapping causes dmub soft hang when initiate aux transation at wrong aux channel. ddc_channel stands for hw dp aux index which is from vbios, but link_index is pure software concept for link count depending on which link is probed first. They are not interchangeable. dmub aux transaction could pass if happens eDP link_index gets the same value as vbios ddc_channel, e.g., ddc_channel = 1, link_index = 1 if they gets different, e.g., ddc_channel = 2, link_index = 0, overwrite ddc_channel with link_index will have wrong ddc channel being used for aux transaction in dmub PSR, cause aux transaction soft hang. [How] ddc_channel mapping to each link is determined by vbios and further parsed in dc. Such info. should not be touched in any kind, otherwise the mapping is screwed up leading to aux transaction timeout. Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index a2575195c4e0..1991a8a4826e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8563,7 +8563,7 @@ static int amdgpu_dm_i2c_xfer(struct i2c_adapter *i2c_adap, if (dc_submit_i2c( ddc_service->ctx->dc, - ddc_service->ddc_pin->hw_info.ddc_channel, + ddc_service->link->link_index, )) result = num; @@ -8599,8 +8599,6 @@ create_i2c(struct ddc_service *ddc_service, snprintf(i2c->base.name, sizeof(i2c->base.name), "AMDGPU DM i2c hw bus %d", link_index); i2c_set_adapdata(>base, i2c); i2c->ddc_service = ddc_service; - if (i2c->ddc_service->ddc_pin) - i2c->ddc_service->ddc_pin->hw_info.ddc_channel = link_index; return i2c; } -- 2.35.1
[PATCH AUTOSEL 5.18 52/93] drm/amd/display: Guard against ddc_pin being NULL for AUX
From: Nicholas Kazlauskas
[ Upstream commit bc19909f19fdc8253d720d11c948935786fbfa08 ]
[Why]
In the case where we don't support DMUB aux but we have DPIA links
in the configuration we might try to message AUX using the legacy
path - where DDC pin is NULL. This causes a NULL pointer dereference.
[How]
Guard against NULL DDC pin, return a failure for aux engine acquire.
Reviewed-by: Michael Strauss
Acked-by: Rodrigo Siqueira
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 8e814000db62..5620a3345e4d 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -573,6 +573,11 @@ int dce_aux_transfer_raw(struct ddc_service *ddc,
memset(_req, 0, sizeof(aux_req));
memset(_rep, 0, sizeof(aux_rep));
+ if (ddc_pin == NULL) {
+ *operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
+ return -1;
+ }
+
aux_engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
if (!acquire(aux_engine, ddc_pin)) {
*operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
--
2.35.1
[PATCH AUTOSEL 5.18 51/93] drm/amdgpu: skip whole ras bad page framework on sriov
From: "Stanley.Yang" [ Upstream commit e0e146d5567317d6ba7d0169bed55d1d9ea05a61 ] It should not init whole ras bad page framework on sriov guest side due to it is handled on host side. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 3f96dadf2698..7506b0b9c2cb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -2062,7 +2062,7 @@ int amdgpu_ras_recovery_init(struct amdgpu_device *adev) bool exc_err_limit = false; int ret; - if (!con) + if (!con || amdgpu_sriov_vf(adev)) return 0; /* Allow access to RAS EEPROM via debugfs, when the ASIC -- 2.35.1
[PATCH AUTOSEL 5.18 47/93] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index 83fbea2df410..b12a46c4e872 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3205,7 +3205,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.18 41/93] amdgpu/pm: Fix possible array out-of-bounds if SCLK levels != 2
From: Darren Powell
[ Upstream commit ceb180361e3851007547c55035cd1de03f108f75 ]
[v2]
simplified fix after Lijo's feedback
removed clocks.num_levels from calculation of loop count
removed unsafe accesses to shim table freq_values
retained corner case output only min,now if
clocks.num_levels == 1 && now > min
[v1]
added a check to populate and use SCLK shim table freq_values only
if using dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL or
AMD_DPM_FORCED_LEVEL_PERF_DETERMINISM
removed clocks.num_levels from calculation of shim table size
removed unsafe accesses to shim table freq_values
output gfx_table values if using other dpm levels
added check for freq_match when using freq_values for when now == min_clk
== Test ==
LOGFILE=aldebaran-sclk.test.log
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
lspci -nn | grep "VGA\|Display" > $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk"
for f in $FILES
do
echo === $f === >> $LOGFILE
cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 34 +++
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 7f998f24af81..b57750cb27c4 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -733,7 +733,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
struct smu_13_0_dpm_table *single_dpm_table;
struct smu_dpm_context *smu_dpm = >smu_dpm;
struct smu_13_0_dpm_context *dpm_context = NULL;
- uint32_t display_levels;
+ int display_levels;
uint32_t freq_values[3] = {0};
uint32_t min_clk, max_clk;
@@ -765,7 +765,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
return ret;
}
- display_levels = clocks.num_levels;
+ display_levels = (clocks.num_levels == 1) ? 1 : 2;
min_clk = pstate_table->gfxclk_pstate.curr.min;
max_clk = pstate_table->gfxclk_pstate.curr.max;
@@ -775,30 +775,20 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
/* fine-grained dpm has only 2 levels */
if (now > min_clk && now < max_clk) {
- display_levels = clocks.num_levels + 1;
+ display_levels++;
freq_values[2] = max_clk;
freq_values[1] = now;
}
- /*
-* For DPM disabled case, there will be only one clock level.
-* And it's safe to assume that is always the current clock.
-*/
- if (display_levels == clocks.num_levels) {
- for (i = 0; i < clocks.num_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i],
- (clocks.num_levels == 1) ?
- "*" :
- (aldebaran_freqs_in_same_level(
-freq_values[i], now) ?
-"*" :
-""));
- } else {
- for (i = 0; i < display_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i], i == 1 ? "*" :
"");
- }
+ for (i = 0; i < display_levels; i++)
+ size += sysfs_emit_at(buf, size, "%d: %uMhz %s\n", i,
+ freq_values[i],
+ (display_levels == 1) ?
+ "*" :
+ (aldebaran_freqs_in_same_level(
+freq_values[i], now) ?
+"*" :
+""));
break;
--
2.35.1
[PATCH AUTOSEL 5.18 24/93] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index 1f4095b26409..c5f6c11de7e5 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.18 19/93] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.18 18/93] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f563284a7fac..6c9cc0061a8d 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -830,7 +830,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.18 17/93] drm/amd/display: Reduce frame size in the bouding box for DCN20
From: Rodrigo Siqueira
[ Upstream commit c55300ad4a1814bac9191a4d2c7b0d74273aec7c ]
GCC throw warnings for the function dcn20_update_bounding_box due to its
frame size that looks like this:
error: the frame size of 1936 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
This commit fixes this issue by eliminating an intermediary variable
that creates a large array.
Cc: Stephen Rothwell
Cc: Hamza Mahfooz
Cc: Aurabindo Pillai
Reviewed-by: Harry Wentland
Reviewed-by: Alex Deucher
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 38 +--
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index f93af45aeab4..c758f84baaf5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1430,21 +1430,20 @@ void dcn20_calculate_wm(
void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_st *bb,
struct pp_smu_nv_clock_table *max_clocks, unsigned int
*uclk_states, unsigned int num_states)
{
- struct _vcs_dpi_voltage_scaling_st
calculated_states[DC__VOLTAGE_STATES];
- int i;
int num_calculated_states = 0;
int min_dcfclk = 0;
+ int i;
dc_assert_fp_enabled();
if (num_states == 0)
return;
- memset(calculated_states, 0, sizeof(calculated_states));
+ memset(bb->clock_limits, 0, sizeof(bb->clock_limits));
- if (dc->bb_overrides.min_dcfclk_mhz > 0)
+ if (dc->bb_overrides.min_dcfclk_mhz > 0) {
min_dcfclk = dc->bb_overrides.min_dcfclk_mhz;
- else {
+ } else {
if (ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev))
min_dcfclk = 310;
else
@@ -1455,36 +1454,35 @@ void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_s
for (i = 0; i < num_states; i++) {
int min_fclk_required_by_uclk;
- calculated_states[i].state = i;
- calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
+ bb->clock_limits[i].state = i;
+ bb->clock_limits[i].dram_speed_mts = uclk_states[i] * 16 / 1000;
// FCLK:UCLK ratio is 1.08
min_fclk_required_by_uclk = div_u64(((unsigned long
long)uclk_states[i]) * 1080,
100);
- calculated_states[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
+ bb->clock_limits[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
- calculated_states[i].socclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
- max_clocks->socClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].socclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
+ max_clocks->socClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dcfclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
- max_clocks->dcfClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].dcfclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
+ max_clocks->dcfClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dispclk_mhz =
max_clocks->displayClockInKhz / 1000;
- calculated_states[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
- calculated_states[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
+ bb->clock_limits[i].dispclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
- calculated_states[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
+ bb->clock_limits[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
num_calculated_states++;
}
- calculated_states[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].fabricclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].dcfclk_mhz =
max_clocks->dcfClockInKhz / 1000;
+ bb->clock_limits[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
+
[PATCH AUTOSEL 5.18 16/93] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index b627c41713cc..76decaed5acd 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1412,11 +1412,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.18 12/93] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index d864cae1af67..bcbb6f6f8c82 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -363,12 +363,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, >mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
>mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(>aux, DP_DP13_DPCD_REV,
_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(>aux,
DP_DPCD_REV, _rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.18 11/93] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 2ba9f528c0fe..f1f11b3c205f 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -657,10 +657,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 312c68172689..ce2f70134669 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -74,6 +74,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
[PATCH AUTOSEL 5.19 092/105] drm/amdkfd: Process notifier release callback don't take mutex
From: Philip Yang
[ Upstream commit 74097f9fd2f5ebdae04fcba59da345386415cbf3 ]
Move process queues cleanup to deferred work kfd_process_wq_release, to
avoid potential deadlock circular locking warning:
WARNING: possible circular locking dependency detected
the existing dependency chain (in reverse order) is:
-> #2
((work_completion)(>deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x343/0x4a0
svm_range_list_lock_and_flush_work+0x39/0xc0
svm_range_set_attr+0xe8/0x1080 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #1 (>lock#2){+.+.}-{3:3}:
__mutex_lock+0xa4/0x940
amdgpu_amdkfd_gpuvm_acquire_process_vm+0x2e3/0x590
kfd_process_device_init_vm+0x61/0x200 [amdgpu]
kfd_ioctl_acquire_vm+0x83/0xb0 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (>mutex){+.+.}-{3:3}:
__lock_acquire+0x1365/0x23d0
lock_acquire+0xc9/0x2e0
__mutex_lock+0xa4/0x940
kfd_process_notifier_release+0x96/0xe0 [amdgpu]
__mmu_notifier_release+0x94/0x210
exit_mmap+0x35/0x1f0
mmput+0x63/0x120
svm_range_deferred_list_work+0x177/0x2c0 [amdgpu]
process_one_work+0x2a4/0x600
worker_thread+0x39/0x3e0
kthread+0x16d/0x1a0
Possible unsafe locking scenario:
CPU0CPU1
lock((work_completion)(>deferred_list_work));
lock(>lock#2);
lock((work_completion)(>deferred_list_work));
lock(>mutex);
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index b8b185e242d3..9ad293fb95af 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1114,6 +1114,15 @@ static void kfd_process_wq_release(struct work_struct
*work)
struct kfd_process *p = container_of(work, struct kfd_process,
release_work);
+ kfd_process_dequeue_from_all_devices(p);
+ pqm_uninit(>pqm);
+
+ /* Signal the eviction fence after user mode queues are
+* destroyed. This allows any BOs to be freed without
+* triggering pointless evictions or waiting for fences.
+*/
+ dma_fence_signal(p->ef);
+
kfd_process_remove_sysfs(p);
kfd_iommu_unbind_process(p);
@@ -1178,20 +1187,8 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
cancel_delayed_work_sync(>eviction_work);
cancel_delayed_work_sync(>restore_work);
- mutex_lock(>mutex);
-
- kfd_process_dequeue_from_all_devices(p);
- pqm_uninit(>pqm);
-
/* Indicate to other users that MM is no longer valid */
p->mm = NULL;
- /* Signal the eviction fence after user mode queues are
-* destroyed. This allows any BOs to be freed without
-* triggering pointless evictions or waiting for fences.
-*/
- dma_fence_signal(p->ef);
-
- mutex_unlock(>mutex);
mmu_notifier_put(>mmu_notifier);
}
--
2.35.1
[PATCH AUTOSEL 5.19 091/105] drm/amdkfd: Correct mmu_notifier_get failure handling
From: Philip Yang [ Upstream commit 0593ad215359d51514c1e6c81ce28ea598efed6b ] If process has signal pending, mmu_notifier_get_locked fails and calls ops->free_notifier, kfd_process_free_notifier will schedule kfd_process_wq_release as process refcount is 1, but process structure is already freed. This use after free bug causes system crash with different backtrace. The fix is to increase process refcount and then decrease the refcount after mmu_notifier_get success. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index e3d64ec8c353..b8b185e242d3 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -1404,6 +1404,11 @@ static struct kfd_process *create_process(const struct task_struct *thread) hash_add_rcu(kfd_processes_table, >kfd_processes, (uintptr_t)process->mm); + /* Avoid free_notifier to start kfd_process_wq_release if +* mmu_notifier_get failed because of pending signal. +*/ + kref_get(>ref); + /* MMU notifier registration must be the last call that can fail * because after this point we cannot unwind the process creation. * After this point, mmu_notifier_put will trigger the cleanup by @@ -1416,6 +1421,7 @@ static struct kfd_process *create_process(const struct task_struct *thread) } BUG_ON(mn != >mmu_notifier); + kfd_unref_process(process); get_task_struct(process->lead_thread); return process; -- 2.35.1
[PATCH AUTOSEL 5.19 075/105] drm/amdgpu: Call trace info was found in dmesg when loading amdgpu
From: lin cao
[ Upstream commit 748262eb400e809aa13e3485f4983c3db3d0ebb3 ]
In the case of SRIOV, the register smnMp1_PMI_3_FIFO will get an invalid
value which will cause the "shift out of bound". In Ubuntu22.04, this
issue will be checked an related call trace will be reported in dmesg.
Signed-off-by: lin cao
Reviewed-by: Jingwen Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 78f3d9e722bb..4db7e32efd08 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -886,6 +886,7 @@ static void sienna_cichlid_stb_init(struct smu_context
*smu);
static int sienna_cichlid_init_smc_tables(struct smu_context *smu)
{
+ struct amdgpu_device *adev = smu->adev;
int ret = 0;
ret = sienna_cichlid_tables_init(smu);
@@ -896,7 +897,8 @@ static int sienna_cichlid_init_smc_tables(struct
smu_context *smu)
if (ret)
return ret;
- sienna_cichlid_stb_init(smu);
+ if (!amdgpu_sriov_vf(adev))
+ sienna_cichlid_stb_init(smu);
return smu_v11_0_init_smc_tables(smu);
}
--
2.35.1
[PATCH AUTOSEL 5.19 070/105] drm/amdgpu: fix file permissions on some files
From: Alex Deucher [ Upstream commit 0a94608f0f7de9b1135ffea3546afe68eafef57f ] Drop execute. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085 Reviewed-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h| 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h | 0 6 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h old mode 100755 new mode 100644 -- 2.35.1
[PATCH AUTOSEL 5.19 064/105] drm/amdgpu: Fix one list corruption when create queue fails
From: xinhui pan
[ Upstream commit cc3cb791f19ad0c4f951f38c98aa513b042ab329 ]
Queue would be freed when create_queue_cpsch fails
So lets do queue cleanup otherwise various list and memory issues
happen.
Signed-off-by: xinhui pan
Reviewed-by: Philip Yang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index e017b4240472..06417c7abca4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1666,14 +1666,13 @@ static int create_queue_cpsch(struct
device_queue_manager *dqm, struct queue *q,
if (q->properties.is_active) {
increment_queue_count(dqm, qpd, q);
- if (!dqm->dev->shared_resources.enable_mes) {
+ if (!dqm->dev->shared_resources.enable_mes)
retval = execute_queues_cpsch(dqm,
-
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
- } else {
+ KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES,
0);
+ else
retval = add_queue_mes(dqm, q, qpd);
- if (retval)
- goto cleanup_queue;
- }
+ if (retval)
+ goto cleanup_queue;
}
/*
--
2.35.1
[PATCH AUTOSEL 5.19 060/105] drm/amd/display: disable otg toggle w/a on boot
From: Dmytro Laktyushkin
[ Upstream commit 8a077d9caa3a274de36ee2fe7b608041f5690343 ]
This w/a has a bad interaction with seamless boot toggling an
active stream. Most panels recover, however some fail leading
to display corruption.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by: Dmytro Laktyushkin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index f4381725b210..36b0cd47c1c7 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -173,11 +173,14 @@ static void dcn315_update_clocks(struct clk_mgr
*clk_mgr_base,
}
if (should_set_clock(safe_to_lower, new_clocks->dispclk_khz,
clk_mgr_base->clks.dispclk_khz)) {
- dcn315_disable_otg_wa(clk_mgr_base, true);
+ /* No need to apply the w/a if we haven't taken over from bios
yet */
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, true);
clk_mgr_base->clks.dispclk_khz = new_clocks->dispclk_khz;
dcn315_smu_set_dispclk(clk_mgr, clk_mgr_base->clks.dispclk_khz);
- dcn315_disable_otg_wa(clk_mgr_base, false);
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, false);
update_dispclk = true;
}
--
2.35.1
[PATCH AUTOSEL 5.19 059/105] drm/amd/display: Fix dmub soft hang for PSR 1
From: Fangzhi Zuo [ Upstream commit 22676bc500c27d987a0b42cbe162aebf783f1c38 ] [Why] Unexpected change of aux hw mapping causes dmub soft hang when initiate aux transation at wrong aux channel. ddc_channel stands for hw dp aux index which is from vbios, but link_index is pure software concept for link count depending on which link is probed first. They are not interchangeable. dmub aux transaction could pass if happens eDP link_index gets the same value as vbios ddc_channel, e.g., ddc_channel = 1, link_index = 1 if they gets different, e.g., ddc_channel = 2, link_index = 0, overwrite ddc_channel with link_index will have wrong ddc channel being used for aux transaction in dmub PSR, cause aux transaction soft hang. [How] ddc_channel mapping to each link is determined by vbios and further parsed in dc. Such info. should not be touched in any kind, otherwise the mapping is screwed up leading to aux transaction timeout. Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3087dd1a1856..a6efd5c1fa2a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8538,7 +8538,7 @@ static int amdgpu_dm_i2c_xfer(struct i2c_adapter *i2c_adap, if (dc_submit_i2c( ddc_service->ctx->dc, - ddc_service->ddc_pin->hw_info.ddc_channel, + ddc_service->link->link_index, )) result = num; @@ -8574,8 +8574,6 @@ create_i2c(struct ddc_service *ddc_service, snprintf(i2c->base.name, sizeof(i2c->base.name), "AMDGPU DM i2c hw bus %d", link_index); i2c_set_adapdata(>base, i2c); i2c->ddc_service = ddc_service; - if (i2c->ddc_service->ddc_pin) - i2c->ddc_service->ddc_pin->hw_info.ddc_channel = link_index; return i2c; } -- 2.35.1
RE: [PATCH] drm/amdgpu: fix reset domain xgmi hive info reference leak
[Public]
> -Original Message-
> From: Kuehling, Felix
> Sent: August 11, 2022 11:19 AM
> To: amd-gfx@lists.freedesktop.org; Kim, Jonathan
> Subject: Re: [PATCH] drm/amdgpu: fix reset domain xgmi hive info reference
> leak
>
> Am 2022-08-11 um 09:42 schrieb Jonathan Kim:
> > When an xgmi node is added to the hive, it takes another hive
> > reference for its reset domain.
> >
> > This extra reference was not dropped on device removal from the
> > hive so drop it.
> >
> > Signed-off-by: Jonathan Kim
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > index 1b108d03e785..560bf1c98f08 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > @@ -731,6 +731,9 @@ int amdgpu_xgmi_remove_device(struct
> amdgpu_device *adev)
> > mutex_unlock(>hive_lock);
> >
> > amdgpu_put_xgmi_hive(hive);
> > + /* device is removed from the hive so remove its reset domain
> reference */
> > + if (adev->reset_domain && adev->reset_domain == hive-
> >reset_domain)
> > + amdgpu_put_xgmi_hive(hive);
>
> This is some messed up reference counting. If you need an extra
> reference from the reset_domain to the hive, that should be owned by the
> reset_domain and dropped when the reset_domain is destroyed. And it's
> only one reference for the reset_domain, not one reference per adev in
> the reset_domain.
Cc'ing Andrey.
What you're saying seems to make more sense to me, but what I got from an
offline conversation with Andrey
was that the reset domain reference per device was intentional.
Maybe Andrey can comment here.
>
> What you're doing here looks like every adev that's in a reset_domain of
> its hive has two references to the hive. And if you're dropping the
> extra reference here, it still leaves the reset_domain with a dangling
> pointer to a hive that may no longer exist. So this extra reference is
> kind of pointless.
Yes. Currently one reference is fetched from the device's lifetime on the hive
and the other is from the
per-device reset domain.
Snippet from amdgpu_device_ip_init:
/**
* In case of XGMI grab extra reference for reset domain for this device
*/
if (adev->gmc.xgmi.num_physical_nodes > 1) {
if (amdgpu_xgmi_add_device(adev) == 0) { <- [JK] reference is
fetched here
struct amdgpu_hive_info *hive =
amdgpu_get_xgmi_hive(adev); <- [JK] then here again
if (!hive->reset_domain ||
!amdgpu_reset_get_reset_domain(hive->reset_domain))
{
r = -ENOENT;
goto init_failed;
}
/* Drop the early temporary reset domain we created for
device */
amdgpu_reset_put_reset_domain(adev->reset_domain);
adev->reset_domain = hive->reset_domain;
}
}
One of these never gets dropped so a leak happens.
So either the extra reference has to be dropped on device removal from the hive
or from what you've mentioned,
the reset_domain reference fetch should be fixed to grab at the
hive/reset_domain level.
Thanks,
Jon
>
> Regards,
>Felix
>
>
> > adev->hive = NULL;
> >
> > if (atomic_dec_return(>number_devices) == 0) {
[PATCH AUTOSEL 5.19 058/105] drm/amd/display: Guard against ddc_pin being NULL for AUX
From: Nicholas Kazlauskas
[ Upstream commit bc19909f19fdc8253d720d11c948935786fbfa08 ]
[Why]
In the case where we don't support DMUB aux but we have DPIA links
in the configuration we might try to message AUX using the legacy
path - where DDC pin is NULL. This causes a NULL pointer dereference.
[How]
Guard against NULL DDC pin, return a failure for aux engine acquire.
Reviewed-by: Michael Strauss
Acked-by: Rodrigo Siqueira
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 9e39cd7b203e..49d3145ae8fb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -572,6 +572,11 @@ int dce_aux_transfer_raw(struct ddc_service *ddc,
memset(_req, 0, sizeof(aux_req));
+ if (ddc_pin == NULL) {
+ *operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
+ return -1;
+ }
+
aux_engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
if (!acquire(aux_engine, ddc_pin)) {
*operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
--
2.35.1
[PATCH AUTOSEL 5.19 057/105] drm/amdgpu: skip whole ras bad page framework on sriov
From: "Stanley.Yang" [ Upstream commit e0e146d5567317d6ba7d0169bed55d1d9ea05a61 ] It should not init whole ras bad page framework on sriov guest side due to it is handled on host side. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index dac202ae864d..465e7921bba1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -2148,7 +2148,7 @@ int amdgpu_ras_recovery_init(struct amdgpu_device *adev) bool exc_err_limit = false; int ret; - if (!con) + if (!con || amdgpu_sriov_vf(adev)) return 0; /* Allow access to RAS EEPROM via debugfs, when the ASIC -- 2.35.1
[PATCH AUTOSEL 5.19 052/105] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index e3a62873c0e7..ffe496131635 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3242,7 +3242,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.19 045/105] amdgpu/pm: Fix possible array out-of-bounds if SCLK levels != 2
From: Darren Powell
[ Upstream commit ceb180361e3851007547c55035cd1de03f108f75 ]
[v2]
simplified fix after Lijo's feedback
removed clocks.num_levels from calculation of loop count
removed unsafe accesses to shim table freq_values
retained corner case output only min,now if
clocks.num_levels == 1 && now > min
[v1]
added a check to populate and use SCLK shim table freq_values only
if using dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL or
AMD_DPM_FORCED_LEVEL_PERF_DETERMINISM
removed clocks.num_levels from calculation of shim table size
removed unsafe accesses to shim table freq_values
output gfx_table values if using other dpm levels
added check for freq_match when using freq_values for when now == min_clk
== Test ==
LOGFILE=aldebaran-sclk.test.log
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
lspci -nn | grep "VGA\|Display" > $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk"
for f in $FILES
do
echo === $f === >> $LOGFILE
cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 34 +++
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index fb130409309c..f6ff7942e1b7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -739,7 +739,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
struct smu_13_0_dpm_table *single_dpm_table;
struct smu_dpm_context *smu_dpm = >smu_dpm;
struct smu_13_0_dpm_context *dpm_context = NULL;
- uint32_t display_levels;
+ int display_levels;
uint32_t freq_values[3] = {0};
uint32_t min_clk, max_clk;
@@ -771,7 +771,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
return ret;
}
- display_levels = clocks.num_levels;
+ display_levels = (clocks.num_levels == 1) ? 1 : 2;
min_clk = pstate_table->gfxclk_pstate.curr.min;
max_clk = pstate_table->gfxclk_pstate.curr.max;
@@ -781,30 +781,20 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
/* fine-grained dpm has only 2 levels */
if (now > min_clk && now < max_clk) {
- display_levels = clocks.num_levels + 1;
+ display_levels++;
freq_values[2] = max_clk;
freq_values[1] = now;
}
- /*
-* For DPM disabled case, there will be only one clock level.
-* And it's safe to assume that is always the current clock.
-*/
- if (display_levels == clocks.num_levels) {
- for (i = 0; i < clocks.num_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i],
- (clocks.num_levels == 1) ?
- "*" :
- (aldebaran_freqs_in_same_level(
-freq_values[i], now) ?
-"*" :
-""));
- } else {
- for (i = 0; i < display_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i], i == 1 ? "*" :
"");
- }
+ for (i = 0; i < display_levels; i++)
+ size += sysfs_emit_at(buf, size, "%d: %uMhz %s\n", i,
+ freq_values[i],
+ (display_levels == 1) ?
+ "*" :
+ (aldebaran_freqs_in_same_level(
+freq_values[i], now) ?
+"*" :
+""));
break;
--
2.35.1
[PATCH AUTOSEL 5.19 044/105] drm/amdkfd: Free queue after unmap queue success
From: Philip Yang
[ Upstream commit ab8529b0cdb271d9b222cbbddb2641f3fca5df8f ]
After queue unmap or remove from MES successfully, free queue sysfs
entries, doorbell and remove from queue list. Otherwise, application may
destroy queue again, cause below kernel warning or crash backtrace.
For outstanding queues, either application forget to destroy or failed
to destroy, kfd_process_notifier_release will remove queue sysfs
entries, kfd_process_wq_release will free queue doorbell.
v2: decrement_queue_count for MES queue
refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 3053 at lib/refcount.c:28
Call Trace:
kobject_put+0xd6/0x1a0
kfd_procfs_del_queue+0x27/0x30 [amdgpu]
pqm_destroy_queue+0xeb/0x240 [amdgpu]
kfd_ioctl_destroy_queue+0x32/0x70 [amdgpu]
kfd_ioctl+0x27d/0x500 [amdgpu]
do_syscall_64+0x35/0x80
WARNING: CPU: 2 PID: 3053 at
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:400
Call Trace:
deallocate_doorbell.isra.0+0x39/0x40 [amdgpu]
destroy_queue_cpsch+0xb3/0x270 [amdgpu]
pqm_destroy_queue+0x108/0x240 [amdgpu]
kfd_ioctl_destroy_queue+0x32/0x70 [amdgpu]
kfd_ioctl+0x27d/0x500 [amdgpu]
general protection fault, probably for non-canonical address
0xdead0108:
Call Trace:
pqm_destroy_queue+0xf0/0x200 [amdgpu]
kfd_ioctl_destroy_queue+0x2f/0x60 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
Signed-off-by: Philip Yang
Reviewed-by: Graham Sider
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 28 +++
.../amd/amdkfd/kfd_process_queue_manager.c| 2 +-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index e1797657b04c..e017b4240472 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1873,6 +1873,22 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
}
+ if (q->properties.is_active) {
+ if (!dqm->dev->shared_resources.enable_mes) {
+ retval = execute_queues_cpsch(dqm,
+
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
+ if (retval == -ETIME)
+ qpd->reset_wavefronts = true;
+ } else {
+ retval = remove_queue_mes(dqm, q, qpd);
+ }
+
+ if (retval)
+ goto failed_unmap_queue;
+
+ decrement_queue_count(dqm, qpd, q);
+ }
+
mqd_mgr = dqm->mqd_mgrs[get_mqd_type_from_queue_type(
q->properties.type)];
@@ -1886,17 +1902,6 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
list_del(>list);
qpd->queue_count--;
- if (q->properties.is_active) {
- if (!dqm->dev->shared_resources.enable_mes) {
- decrement_queue_count(dqm, qpd, q);
- retval = execute_queues_cpsch(dqm,
-
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
- if (retval == -ETIME)
- qpd->reset_wavefronts = true;
- } else {
- retval = remove_queue_mes(dqm, q, qpd);
- }
- }
/*
* Unconditionally decrement this counter, regardless of the queue's
@@ -1913,6 +1918,7 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
return retval;
+failed_unmap_queue:
failed_try_destroy_debugged_queue:
dqm_unlock(dqm);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index dc00484ff484..99f2a6412201 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -419,7 +419,6 @@ int pqm_destroy_queue(struct process_queue_manager *pqm,
unsigned int qid)
}
if (pqn->q) {
- kfd_procfs_del_queue(pqn->q);
dqm = pqn->q->device->dqm;
retval = dqm->ops.destroy_queue(dqm, >qpd, pqn->q);
if (retval) {
@@ -439,6 +438,7 @@ int pqm_destroy_queue(struct process_queue_manager *pqm,
unsigned int qid)
if (dev->shared_resources.enable_mes)
amdgpu_amdkfd_free_gtt_mem(dev->adev,
pqn->q->gang_ctx_bo);
+ kfd_procfs_del_queue(pqn->q);
uninit_queue(pqn->q);
}
--
2.35.1
[PATCH AUTOSEL 5.19 025/105] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index 1f4095b26409..c5f6c11de7e5 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.19 020/105] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.19 018/105] drm/amd/display: Reduce frame size in the bouding box for DCN20
From: Rodrigo Siqueira
[ Upstream commit c55300ad4a1814bac9191a4d2c7b0d74273aec7c ]
GCC throw warnings for the function dcn20_update_bounding_box due to its
frame size that looks like this:
error: the frame size of 1936 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
This commit fixes this issue by eliminating an intermediary variable
that creates a large array.
Cc: Stephen Rothwell
Cc: Hamza Mahfooz
Cc: Aurabindo Pillai
Reviewed-by: Harry Wentland
Reviewed-by: Alex Deucher
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 38 +--
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index f79dd40f8d81..48df4f225ac7 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1428,21 +1428,20 @@ void dcn20_calculate_wm(
void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_st *bb,
struct pp_smu_nv_clock_table *max_clocks, unsigned int
*uclk_states, unsigned int num_states)
{
- struct _vcs_dpi_voltage_scaling_st
calculated_states[DC__VOLTAGE_STATES];
- int i;
int num_calculated_states = 0;
int min_dcfclk = 0;
+ int i;
dc_assert_fp_enabled();
if (num_states == 0)
return;
- memset(calculated_states, 0, sizeof(calculated_states));
+ memset(bb->clock_limits, 0, sizeof(bb->clock_limits));
- if (dc->bb_overrides.min_dcfclk_mhz > 0)
+ if (dc->bb_overrides.min_dcfclk_mhz > 0) {
min_dcfclk = dc->bb_overrides.min_dcfclk_mhz;
- else {
+ } else {
if (ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev))
min_dcfclk = 310;
else
@@ -1453,36 +1452,35 @@ void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_s
for (i = 0; i < num_states; i++) {
int min_fclk_required_by_uclk;
- calculated_states[i].state = i;
- calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
+ bb->clock_limits[i].state = i;
+ bb->clock_limits[i].dram_speed_mts = uclk_states[i] * 16 / 1000;
// FCLK:UCLK ratio is 1.08
min_fclk_required_by_uclk = div_u64(((unsigned long
long)uclk_states[i]) * 1080,
100);
- calculated_states[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
+ bb->clock_limits[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
- calculated_states[i].socclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
- max_clocks->socClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].socclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
+ max_clocks->socClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dcfclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
- max_clocks->dcfClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].dcfclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
+ max_clocks->dcfClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dispclk_mhz =
max_clocks->displayClockInKhz / 1000;
- calculated_states[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
- calculated_states[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
+ bb->clock_limits[i].dispclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
- calculated_states[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
+ bb->clock_limits[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
num_calculated_states++;
}
- calculated_states[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].fabricclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].dcfclk_mhz =
max_clocks->dcfClockInKhz / 1000;
+ bb->clock_limits[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
+
[PATCH AUTOSEL 5.19 019/105] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 8c01a7f0e027..84843b3b3aef 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -833,7 +833,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.19 017/105] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index ec6aa8d8b251..8b2c15a3cd92 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1412,11 +1412,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.19 016/105] drm/amd/display: Correct min comp buffer size
From: Duncan Ma
[ Upstream commit 0c56705d8aae9696348cc320b71d531ede001b79 ]
[Why]
In 3-way mpo pipes, there is a case that we
overbook the CRB buffer size. At rare instances,
overbooking the crb will cause underflow. This only
happens when det_size changes dynamically
based on pipe_cnt.
[How]
Set min compbuff size to 1 segment when preparing BW.
Reviewed-by: Dmytro Laktyushkin
Acked-by: Hamza Mahfooz
Signed-off-by: Duncan Ma
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
index 54db2eca9e6b..1b02f0ebe957 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
@@ -201,7 +201,7 @@ struct _vcs_dpi_ip_params_st dcn3_15_ip = {
.hostvm_max_page_table_levels = 2,
.rob_buffer_size_kbytes = 64,
.det_buffer_size_kbytes = DCN3_15_DEFAULT_DET_SIZE,
- .min_comp_buffer_size_kbytes = DCN3_15_MIN_COMPBUF_SIZE_KB,
+ .min_comp_buffer_size_kbytes = 64,
.config_return_buffer_size_in_kbytes = 1024,
.compressed_buffer_segment_size_in_kbytes = 64,
.meta_fifo_size_in_kentries = 32,
@@ -297,6 +297,7 @@ struct _vcs_dpi_ip_params_st dcn3_16_ip = {
.hostvm_max_page_table_levels = 2,
.rob_buffer_size_kbytes = 64,
.det_buffer_size_kbytes = DCN3_16_DEFAULT_DET_SIZE,
+ .min_comp_buffer_size_kbytes = 64,
.config_return_buffer_size_in_kbytes = 1024,
.compressed_buffer_segment_size_in_kbytes = 64,
.meta_fifo_size_in_kentries = 32,
--
2.35.1
[PATCH AUTOSEL 5.19 012/105] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2b9b095e5f03..1c02d873950d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -361,12 +361,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, >mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
>mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(>aux, DP_DP13_DPCD_REV,
_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(>aux,
DP_DPCD_REV, _rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.19 011/105] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 2ba9f528c0fe..f1f11b3c205f 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -657,10 +657,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 1d4f0c45b536..f941aa107dc6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -74,6 +74,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
Re: [PATCH] drm/amdgpu: fix reset domain xgmi hive info reference leak
Am 2022-08-11 um 09:42 schrieb Jonathan Kim:
When an xgmi node is added to the hive, it takes another hive
reference for its reset domain.
This extra reference was not dropped on device removal from the
hive so drop it.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 1b108d03e785..560bf1c98f08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -731,6 +731,9 @@ int amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
mutex_unlock(>hive_lock);
amdgpu_put_xgmi_hive(hive);
+ /* device is removed from the hive so remove its reset domain reference
*/
+ if (adev->reset_domain && adev->reset_domain == hive->reset_domain)
+ amdgpu_put_xgmi_hive(hive);
This is some messed up reference counting. If you need an extra
reference from the reset_domain to the hive, that should be owned by the
reset_domain and dropped when the reset_domain is destroyed. And it's
only one reference for the reset_domain, not one reference per adev in
the reset_domain.
What you're doing here looks like every adev that's in a reset_domain of
its hive has two references to the hive. And if you're dropping the
extra reference here, it still leaves the reset_domain with a dangling
pointer to a hive that may no longer exist. So this extra reference is
kind of pointless.
Regards,
Felix
adev->hive = NULL;
if (atomic_dec_return(>number_devices) == 0) {
Re: [PATCH] drm/amdkfd: Try to schedule bottom half on same core
Am 2022-08-10 um 19:41 schrieb Felix Kuehling:
On systems that support SMT (hyperthreading) schedule the bottom half of
the KFD interrupt handler on the same core. This makes it possible to
reserve a core for interrupt handling and have the bottom half run on
that same core.
On systems without SMT, pick another core in the same NUMA node, as
before.
Use for_each_cpu_wrap instead of open-coding it.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index f5853835f03a..5b12ae69a301 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "kfd_priv.h"
#include "kfd_device_queue_manager.h"
#include "kfd_pm4_headers_vi.h"
@@ -801,13 +802,24 @@ static inline void kfd_queue_work(struct workqueue_struct
*wq,
struct work_struct *work)
{
int cpu, new_cpu;
+ const struct cpumask *mask = NULL;
cpu = new_cpu = smp_processor_id();
- do {
- new_cpu = cpumask_next(new_cpu, cpu_online_mask) % nr_cpu_ids;
- if (cpu_to_node(new_cpu) == numa_node_id())
+
+#if defined(CONFIG_SCHED_SMT)
+ /* CPU threads in the same core */
+ mask = cpu_smt_mask(cpu);
+#endif
+ if (!mask || cpumask_weight(mask) <= 1) {
There is a stray { here, left over from when I removed some
instrumentation and switched branches. I'll fix that before submitting.
Regards,
Felix
+ /* CPU threads in the same NUMA node */
+ mask = cpu_cpu_mask(cpu);
+ /* Pick the next online CPU thread in the same core or NUMA node */
+ for_each_cpu_wrap(cpu, mask, cpu+1) {
+ if (cpu != new_cpu && cpu_online(cpu)) {
+ new_cpu = cpu;
break;
- } while (cpu != new_cpu);
+ }
+ }
queue_work_on(new_cpu, wq, work);
}
Re: [Patch V3] drm/amdgpu: Increase tlb flush timeout for sriov
On Thu, Aug 11, 2022 at 10:16 AM Liu, Shaoyun wrote:
>
> [AMD Official Use Only - General]
>
> From HW point of view , the maximum VF number can reach 16 instead of 12 .
> Although currently no product will use the 16 VFs together, not sure about
> the future.
> You can added Acked-by me. I will let Alex & Christion decide whether accept
> this change.
>
I'll let you two sort out the timeout, but the rest of the patch looks
good to me.
Acked-by: Alex Deucher
> Regards
> Shaoyun.liu
>
>
>
> -Original Message-
> From: amd-gfx On Behalf Of Dusica
> Milinkovic
> Sent: Thursday, August 11, 2022 6:01 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Milinkovic, Dusica
> Subject: [Patch V3] drm/amdgpu: Increase tlb flush timeout for sriov
>
> [Why]
> During multi-vf executing benchmark (Luxmark) observed kiq error timeout.
> It happenes because all of VFs do the tlb invalidation at the same time.
> Although each VF has the invalidate register set, from hardware side the
> invalidate requests are queue to execute.
>
> [How]
> In case of 12 VF increase timeout on 12*100ms
>
> Signed-off-by: Dusica Milinkovic
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 5a639c857bd0..79bb6fd83094 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -320,7 +320,7 @@ enum amdgpu_kiq_irq {
> AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
> AMDGPU_CP_KIQ_IRQ_LAST
> };
> -
> +#define SRIOV_USEC_TIMEOUT 120 /* wait 12 * 100ms for SRIOV */
> #define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
> #define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */
> #define MAX_KIQ_REG_TRY 1000
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> index 9ae8cdaa033e..f513e2c2e964 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
> @@ -419,6 +419,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
> amdgpu_device *adev,
> uint32_t seq;
> uint16_t queried_pasid;
> bool ret;
> + u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
> +adev->usec_timeout;
> struct amdgpu_ring *ring = >gfx.kiq.ring;
> struct amdgpu_kiq *kiq = >gfx.kiq;
>
> @@ -437,7 +438,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
> amdgpu_device *adev,
>
> amdgpu_ring_commit(ring);
> spin_unlock(>gfx.kiq.ring_lock);
> - r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
> + r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
> if (r < 1) {
> dev_err(adev->dev, "wait for kiq fence error:
> %ld.\n", r);
> return -ETIME;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index ab89d91975ab..4603653916f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -896,6 +896,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
> amdgpu_device *adev,
> uint32_t seq;
> uint16_t queried_pasid;
> bool ret;
> + u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
> +adev->usec_timeout;
> struct amdgpu_ring *ring = >gfx.kiq.ring;
> struct amdgpu_kiq *kiq = >gfx.kiq;
>
> @@ -935,7 +936,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
> amdgpu_device *adev,
>
> amdgpu_ring_commit(ring);
> spin_unlock(>gfx.kiq.ring_lock);
> - r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
> + r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
> if (r < 1) {
> dev_err(adev->dev, "wait for kiq fence error:
> %ld.\n", r);
> up_read(>reset_domain->sem);
> --
> 2.25.1
>
RE: [Patch V3] drm/amdgpu: Increase tlb flush timeout for sriov
[AMD Official Use Only - General]
>From HW point of view , the maximum VF number can reach 16 instead of 12 .
>Although currently no product will use the 16 VFs together, not sure about
>the future.
You can added Acked-by me. I will let Alex & Christion decide whether accept
this change.
Regards
Shaoyun.liu
-Original Message-
From: amd-gfx On Behalf Of Dusica
Milinkovic
Sent: Thursday, August 11, 2022 6:01 AM
To: amd-gfx@lists.freedesktop.org
Cc: Milinkovic, Dusica
Subject: [Patch V3] drm/amdgpu: Increase tlb flush timeout for sriov
[Why]
During multi-vf executing benchmark (Luxmark) observed kiq error timeout.
It happenes because all of VFs do the tlb invalidation at the same time.
Although each VF has the invalidate register set, from hardware side the
invalidate requests are queue to execute.
[How]
In case of 12 VF increase timeout on 12*100ms
Signed-off-by: Dusica Milinkovic
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5a639c857bd0..79bb6fd83094 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -320,7 +320,7 @@ enum amdgpu_kiq_irq {
AMDGPU_CP_KIQ_IRQ_DRIVER0 = 0,
AMDGPU_CP_KIQ_IRQ_LAST
};
-
+#define SRIOV_USEC_TIMEOUT 120 /* wait 12 * 100ms for SRIOV */
#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */
#define MAX_KIQ_REG_TRY 1000
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index 9ae8cdaa033e..f513e2c2e964 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
@@ -419,6 +419,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
+adev->usec_timeout;
struct amdgpu_ring *ring = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >gfx.kiq;
@@ -437,7 +438,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(>gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
return -ETIME;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index ab89d91975ab..4603653916f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -896,6 +896,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
uint32_t seq;
uint16_t queried_pasid;
bool ret;
+ u32 usec_timeout = amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT :
+adev->usec_timeout;
struct amdgpu_ring *ring = >gfx.kiq.ring;
struct amdgpu_kiq *kiq = >gfx.kiq;
@@ -935,7 +936,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct
amdgpu_device *adev,
amdgpu_ring_commit(ring);
spin_unlock(>gfx.kiq.ring_lock);
- r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
+ r = amdgpu_fence_wait_polling(ring, seq, usec_timeout);
if (r < 1) {
dev_err(adev->dev, "wait for kiq fence error: %ld.\n",
r);
up_read(>reset_domain->sem);
--
2.25.1
Re: [PATCH] drm/amdgpu: use native mode for dp aux transfer
On Thu, Aug 11, 2022 at 7:32 AM Zhenneng Li wrote: > > When using amdgpu for e8860, the monitor sometimes haven't any signal, > and the kernel reports some errors: > [ 17.317302][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] > *ERROR* channel eq failed: 5 tries > [ 17.326963][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] > *ERROR* channel eq failed > But if I use radeon for e8860, everything are always normal, the reason is > that radeon use native mode and amdgpu use atombios mode > when init dp aux, so when I use native mode for amdgpu, everything > are always normal. > > Signed-off-by: Zhenneng Li > Change-Id: Ia9a2be3ab03e56b1c8337fdbf713461196fbc58f > --- > drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 5 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c | 273 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 + > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 + > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +- > 7 files changed, 290 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile > b/drivers/gpu/drm/amd/amdgpu/Makefile > index 3e0e2eb7e235..2913cf46f848 100644 > --- a/drivers/gpu/drm/amd/amdgpu/Makefile > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile > @@ -58,7 +58,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \ > amdgpu_vm_sdma.o amdgpu_discovery.o amdgpu_ras_eeprom.o amdgpu_nbio.o > \ > amdgpu_umc.o smu_v11_0_i2c.o amdgpu_fru_eeprom.o amdgpu_rap.o \ > amdgpu_fw_attestation.o amdgpu_securedisplay.o \ > - amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o > + amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o > amdgpu_dp_auxch.o > > amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 30ce6bb6fa77..15e0288b1997 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -238,6 +238,8 @@ extern int amdgpu_num_kcq; > #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024) > extern int amdgpu_vcnfw_log; > > +extern int amdgpu_auxch; > + > #define AMDGPU_VM_MAX_NUM_CTX 4096 > #define AMDGPU_SG_THRESHOLD(256*1024*1024) > #define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */ > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > index 9ba4817a9148..68c8d79e2937 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > @@ -49,7 +49,10 @@ static struct amdgpu_i2c_bus_rec > amdgpu_atombios_get_bus_rec_for_i2c_gpio(ATOM_G > > memset(, 0, sizeof(struct amdgpu_i2c_bus_rec)); > > - i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); > + if (amdgpu_auxch) > + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex) > * 4; > + else > + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); You can drop this change if you convert your aux code to use dword aligned register addresses. > i2c.mask_data_reg = le16_to_cpu(gpio->usDataMaskRegisterIndex); > i2c.en_clk_reg = le16_to_cpu(gpio->usClkEnRegisterIndex); > i2c.en_data_reg = le16_to_cpu(gpio->usDataEnRegisterIndex); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > new file mode 100644 > index ..22078f1ca936 > --- /dev/null > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > @@ -0,0 +1,273 @@ > +/* > + * Copyright 2015 Red Hat Inc. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + * > + *
[PATCH] drm/amdgpu: fix reset domain xgmi hive info reference leak
When an xgmi node is added to the hive, it takes another hive
reference for its reset domain.
This extra reference was not dropped on device removal from the
hive so drop it.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 1b108d03e785..560bf1c98f08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -731,6 +731,9 @@ int amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
mutex_unlock(>hive_lock);
amdgpu_put_xgmi_hive(hive);
+ /* device is removed from the hive so remove its reset domain reference
*/
+ if (adev->reset_domain && adev->reset_domain == hive->reset_domain)
+ amdgpu_put_xgmi_hive(hive);
adev->hive = NULL;
if (atomic_dec_return(>number_devices) == 0) {
--
2.25.1
Re: [PATCH 7/8] drm/amd/display: Introduce KUnit tests to dc_dmub_srv library
On 8/11/22 04:37, David Gow wrote:
On Thu, Aug 11, 2022 at 8:41 AM Tales Aparecida
wrote:
From: Maíra Canal
Add unit test to the SubVP feature in order to avoid possible
regressions and assure the code robustness.
Signed-off-by: Maíra Canal
Signed-off-by: Tales Aparecida
---
FYI: This seems to have a dependency issue. See below.
Otherwise, I haven't had a chance to review it properly yet, but I'll
try to take a closer look over the next few days.
Cheers,
-- David
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 4 +
.../amd/display/tests/dc/dc_dmub_srv_test.c | 285 ++
2 files changed, 289 insertions(+)
create mode 100644 drivers/gpu/drm/amd/display/tests/dc/dc_dmub_srv_test.c
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index 2d61c2a91cee..f5dd1f69840e 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -809,3 +809,7 @@ void dc_dmub_srv_log_diagnostic_data(struct dc_dmub_srv
*dc_dmub_srv)
diag_data.is_cw0_enabled,
diag_data.is_cw6_enabled);
}
+
+#if IS_ENABLED(CONFIG_AMD_DC_BASICS_KUNIT_TEST)
+#include "../tests/dc/dc_dmub_srv_test.c"
+#endif
diff --git a/drivers/gpu/drm/amd/display/tests/dc/dc_dmub_srv_test.c
b/drivers/gpu/drm/amd/display/tests/dc/dc_dmub_srv_test.c
new file mode 100644
index ..051079cbf65e
--- /dev/null
+++ b/drivers/gpu/drm/amd/display/tests/dc/dc_dmub_srv_test.c
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: MIT
+/*
+ * KUnit tests for dc_dmub_srv.c
+ *
+ * Copyright (C) 2022, Maíra Canal
+ */
+
+#include
+#include "dc_dmub_srv.h"
+
+struct populate_subvp_cmd_drr_info_test_case {
+ const char *desc;
+ struct dc *dc;
+ struct pipe_ctx *subvp_pipe;
+ struct pipe_ctx *vblank_pipe;
+ const u8 drr_in_use;
+ const u8 drr_window_size_ms;
+ const u16 min_vtotal_supported;
+ const u16 max_vtotal_supported;
+ const u8 use_ramping;
+};
+
+struct populate_subvp_cmd_drr_info_test_case
populate_subvp_cmd_drr_info_cases[] = {
+ {
+ .desc = "Same Clock Frequency",
+ .dc = &(struct dc) {
+ .caps = {
+ .subvp_prefetch_end_to_mall_start_us = 0,
+ }
+ },
+ .subvp_pipe = &(struct pipe_ctx) {
+ .stream = &(struct dc_stream_state) {
+ .timing = {
+ .h_total = 2784,
+ .v_addressable = 1080,
+ .pix_clk_100hz = 1855800,
+ },
+ .mall_stream_config = {
+ .paired_stream = &(struct
dc_stream_state) {
+ .timing = {
+ .h_total = 3600,
+ .v_total = ,
+ .v_addressable = 1080,
+ .v_front_porch = 3,
+ .pix_clk_100hz =
1855800,
+ },
+ },
+ },
+ },
+ },
+ .vblank_pipe = &(struct pipe_ctx) {
+ .stream = &(struct dc_stream_state) {
+ .timing = {
+ .h_total = 2784,
+ .v_total = ,
+ .v_addressable = 1080,
+ .pix_clk_100hz = 1855800,
+ },
+ },
+ },
+ .drr_in_use = true,
+ .use_ramping = false,
+ .drr_window_size_ms = 4,
+ .min_vtotal_supported = 2540,
+ .max_vtotal_supported = 2619,
+ },
+ {
+ .desc = "Same Clock Frequency with Prefetch End to Mall Start",
+ .dc = &(struct dc) {
+ .caps = {
+ .subvp_prefetch_end_to_mall_start_us = 500,
+ }
+ },
+ .subvp_pipe = &(struct pipe_ctx) {
+ .stream = &(struct dc_stream_state) {
+ .timing = {
+ .h_total = 2784,
+ .v_addressable = 1080,
+ .pix_clk_100hz = 1855800,
+ },
+ .mall_stream_config = {
+ .paired_stream =
