RE: [PATCH v3] drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap

[Wang, Beyond]

[AMD Official Use Only - General]



Issue: during evict or validate happened on amdgpu_bo, the 'from' and
'to' is always same in ftrace event of amdgpu_bo_move

where calling the 'trace_amdgpu_bo_move', the comment says move_notify
is called before move happens, but actually it is called after move
happens, here the new_mem is same as bo->resource

Fix: move trace_amdgpu_bo_move from move_notify to amdgpu_bo_move

Signed-off-by: Wang, Beyond wang.bey...@amd.com
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  5 +++--
3 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 7416799750c1..1870775d582c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1282,19 +1282,15 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void 
*buffer,
  * amdgpu_bo_move_notify - notification about a memory move
  * @bo: pointer to a buffer object
  * @evict: if this move is evicting the buffer from the graphics address space
- * @new_mem: new information of the bufer object
  *
  * Marks the corresponding _bo buffer object as invalid, also performs
  * bookkeeping.
  * TTM driver callback which is called when ttm moves a buffer.
  */
-void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
-  bool evict,
-  struct ttm_resource *new_mem)
+void amdgpu_bo_move_notify(struct ttm_buffer_object *bo, bool evict)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct amdgpu_bo *abo;
-   struct ttm_resource *old_mem = bo->resource;

if (!amdgpu_bo_is_amdgpu_bo(bo))
return;
@@ -1313,13 +1309,6 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
-
-   /* update statistics */
-   if (!new_mem)
-   return;
-
-   /* move_notify is called before move happens */
-   trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type);
}

void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 876acde6b10a..dee2c577427e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -360,9 +360,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void 
*metadata,
int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void *buffer,
   size_t buffer_size, uint32_t *metadata_size,
   uint64_t *flags);
-void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
-  bool evict,
-  struct ttm_resource *new_mem);
+void amdgpu_bo_move_notify(struct ttm_buffer_object *bo, bool evict);
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);
vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 41ed6a3e5a06..f0fffbf2bdd5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -576,10 +576,11 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
return r;
}

+   trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type);
out:
/* update statistics */
atomic64_add(bo->base.size, >num_bytes_moved);
-   amdgpu_bo_move_notify(bo, evict, new_mem);
+   amdgpu_bo_move_notify(bo, evict);
return 0;
}

@@ -1852,7 +1853,7 @@ static int amdgpu_ttm_access_memory(struct 
ttm_buffer_object *bo,
static void
amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
{
-   amdgpu_bo_move_notify(bo, false, NULL);
+   amdgpu_bo_move_notify(bo, false);
}

static struct ttm_device_funcs amdgpu_bo_driver = {
--
2.34.1

[PATCH] drm/amd/pm: add power save mode workload for smu 13.0.10

[Kenneth Feng]

add power save mode workload for smu 13.0.10, so that in compute mode,
pmfw will add 35mv voltage margin since some applications requres higher
voltages.

Signed-off-by: Kenneth Feng 
---
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 23 +++
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index a24aa886c636..231122622a9c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -2545,16 +2545,19 @@ static int smu_v13_0_0_set_power_profile_mode(struct 
smu_context *smu,
 
workload_mask = 1 << workload_type;
 
-   /* Add optimizations for SMU13.0.0.  Reuse the power saving profile */
-   if (smu->power_profile_mode == PP_SMC_POWER_PROFILE_COMPUTE &&
-   (amdgpu_ip_version(smu->adev, MP1_HWIP, 0) == IP_VERSION(13, 0, 0)) 
&&
-   ((smu->adev->pm.fw_version == 0x004e6601) ||
-(smu->adev->pm.fw_version >= 0x004e7400))) {
-   workload_type = smu_cmn_to_asic_specific_index(smu,
-  
CMN2ASIC_MAPPING_WORKLOAD,
-  
PP_SMC_POWER_PROFILE_POWERSAVING);
-   if (workload_type >= 0)
-   workload_mask |= 1 << workload_type;
+   /* Add optimizations for SMU13.0.0/10.  Reuse the power saving profile 
*/
+   if (smu->power_profile_mode == PP_SMC_POWER_PROFILE_COMPUTE) {
+   if ((amdgpu_ip_version(smu->adev, MP1_HWIP, 0) == 
IP_VERSION(13, 0, 0) &&
+   ((smu->adev->pm.fw_version == 0x004e6601) ||
+   (smu->adev->pm.fw_version >= 0x004e7300))) ||
+   (amdgpu_ip_version(smu->adev, MP1_HWIP, 0) == 
IP_VERSION(13, 0, 10) &&
+smu->adev->pm.fw_version >= 0x00504500)) {
+   workload_type = smu_cmn_to_asic_specific_index(smu,
+   
   CMN2ASIC_MAPPING_WORKLOAD,
+   
   PP_SMC_POWER_PROFILE_POWERSAVING);
+   if (workload_type >= 0)
+   workload_mask |= 1 << workload_type;
+   }
}
 
return smu_cmn_send_smc_msg_with_param(smu,
-- 
2.34.1

Re: [PATCH v2] drm/radeon: Prevent multiple debug error lines on suspend

[Christian König]

Am 13.12.23 um 00:31 schrieb Woody Suwalski:
Fix to avoid multiple debug error lines printed on every suspend by 
Radeon driver's debugfs.


radeon_debugfs_init() calls debugfs_create_file() for every ring.

This results in printing multiple error lines to the screen and dmesg 
similar to this:


[   92.378726] debugfs: File 'radeon_ring_gfx' in directory 
':00:01.0' already present!
[   92.378732] debugfs: File 'radeon_ring_cp1' in directory 
':00:01.0' already present!
[   92.378734] debugfs: File 'radeon_ring_cp2' in directory 
':00:01.0' already present!
[   92.378737] debugfs: File 'radeon_ring_dma1' in directory 
':00:01.0' already present!
[   92.378739] debugfs: File 'radeon_ring_dma2' in directory 
':00:01.0' already present!
[   92.380775] debugfs: File 'radeon_ring_uvd' in directory 
':00:01.0' already present!
[   92.406620] debugfs: File 'radeon_ring_vce1' in directory 
':00:01.0' already present!
[   92.406624] debugfs: File 'radeon_ring_vce2' in directory 
':00:01.0' already present!



Patch v1: The fix was to run lookup() for the file before trying to 
(re)create that debug file.
Patch v2: Call the radeon_debugfs_init() only once when radeon ring is 
initialized (as suggested  by Christian K. - thanks)


Signed-off-by: Woody Suwalski 


Reviewed-by: Christian König 

Thanks for the help,
Christian.



diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c

index e6534fa9f1fb..38048593bb4a 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -413,6 +413,7 @@ int radeon_ring_init(struct radeon_device *rdev, 
struct radeon_ring *ring, unsig

         dev_err(rdev->dev, "(%d) ring map failed\n", r);
         return r;
     }
+        radeon_debugfs_ring_init(rdev, ring);
 }
 ring->ptr_mask = (ring->ring_size / 4) - 1;
 ring->ring_free_dw = ring->ring_size / 4;
@@ -421,7 +422,6 @@ int radeon_ring_init(struct radeon_device *rdev, 
struct radeon_ring *ring, unsig

     ring->next_rptr_gpu_addr = rdev->wb.gpu_addr + index;
     ring->next_rptr_cpu_addr = >wb.wb[index/4];
 }
-    radeon_debugfs_ring_init(rdev, ring);
 radeon_ring_lockup_update(rdev, ring);
 return 0;
 }

[PATCH 25/25] drm/amd/display: 3.2.265

[Wayne Lin]

From: Aric Cyr 

This DC patchset brings improvements in multiple areas. In summary, we 
highlight:

- change static screen wait frame_count for ips
- Fix hang/underflow when transitioning to ODM4:1
- Only clear symclk otg flag for HDMI
- Fix lightup regression with DP2 single display configs
- Refactor phantom resource allocation
- Refactor dc_state interface
- Wake DMCUB before executing GPINT commands
- Wake DMCUB before sending a command
- Refactor DMCUB enter/exit idle interface
- enable dcn35 idle power optimization
- fix usb-c connector_type
- add debug option for ExtendedVBlank DLG adjust
- Set test_pattern_changed update flag on pipe enable
- dereference variable before checking for zero
- get dprefclk ss info from integration info table
- skip error logging when DMUB is inactive from S3
- make flip_timestamp_in_us a 64-bit variable
- Add case for dcn35 to support usb4 dmub hpd event
- Add function for dumping clk registers
- Unify optimize_required flags and VRR adjustments
- Revert using channel_width as 2 for vram table 3.0
- remove HPO PG in driver side
- do not send commands to DMUB if DMUB is inactive from S3

Acked-by: Wayne Lin 
Signed-off-by: Aric Cyr 
---
 drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index f622f4f0e1a0..3ca72c097aa1 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -51,7 +51,7 @@ struct aux_payload;
 struct set_config_cmd_payload;
 struct dmub_notification;
 
-#define DC_VER "3.2.264"
+#define DC_VER "3.2.265"
 
 #define MAX_SURFACES 3
 #define MAX_PLANES 6
-- 
2.37.3

[PATCH 24/25] drm/amd/display: [FW Promotion] Release 0.0.197.0

[Wayne Lin]

From: Anthony Koo 

 - Remove unused dmub_fw_boot_options flag

Acked-by: Wayne Lin 
Signed-off-by: Anthony Koo 
---
 drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h 
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
index 3c092064c72e..c64b6c848ef7 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
@@ -653,7 +653,7 @@ union dmub_fw_boot_options {
uint32_t gpint_scratch8: 1; /* 1 if GPINT is in scratch8*/
uint32_t usb4_cm_version: 1; /**< 1 CM support */
uint32_t dpia_hpd_int_enable_supported: 1; /* 1 if dpia hpd int 
enable supported */
-   uint32_t usb4_dpia_bw_alloc_supported: 1; /* 1 if USB4 dpia BW 
allocation supported */
+   uint32_t reserved0: 1;
uint32_t disable_clk_ds: 1; /* 1 if disallow dispclk_ds and 
dppclk_ds*/
uint32_t disable_timeout_recovery : 1; /* 1 if timeout recovery 
should be disabled */
uint32_t ips_pg_disable: 1; /* 1 to disable ONO domains power 
gating*/
-- 
2.37.3

[PATCH 23/25] drm/amd/display: change static screen wait frame_count for ips

[Wayne Lin]

From: Allen Pan 

[Why]
the original wait for 2 static frames before enter static screen
was not good enough for IPS-enabled case since enter/exit takes more time.

[How]
Changed logic for hardcoded wait frame values.

Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Allen Pan 
---
 drivers/gpu/drm/amd/display/dc/dc.h   |  1 +
 .../gpu/drm/amd/display/dc/dcn35/dcn35_init.c |  2 +-
 .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c   | 41 +++
 .../amd/display/dc/hwss/dcn35/dcn35_hwseq.h   |  4 ++
 .../dc/resource/dcn35/dcn35_resource.c|  3 +-
 5 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index a270b4bf7b95..f622f4f0e1a0 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -982,6 +982,7 @@ struct dc_debug_options {
unsigned int ips2_entry_delay_us;
bool disable_timeout;
bool disable_extblankadj;
+   unsigned int static_screen_wait_frames;
 };
 
 struct gpu_info_soc_bounding_box_v1_0;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_init.c 
b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_init.c
index d594905eb246..a630aa77dcec 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_init.c
@@ -68,7 +68,7 @@ static const struct hw_sequencer_funcs dcn35_funcs = {
.prepare_bandwidth = dcn35_prepare_bandwidth,
.optimize_bandwidth = dcn35_optimize_bandwidth,
.update_bandwidth = dcn20_update_bandwidth,
-   .set_drr = dcn10_set_drr,
+   .set_drr = dcn35_set_drr,
.get_position = dcn10_get_position,
.set_static_screen_control = dcn30_set_static_screen_control,
.setup_stereo = dcn10_setup_stereo,
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
index 582852ed21fb..ad710b4036de 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
@@ -1312,3 +1312,44 @@ uint32_t dcn35_get_idle_state(const struct dc *dc)
 
return 0;
 }
+
+void dcn35_set_drr(struct pipe_ctx **pipe_ctx,
+   int num_pipes, struct dc_crtc_timing_adjust adjust)
+{
+   int i = 0;
+   struct drr_params params = {0};
+   // DRR set trigger event mapped to OTG_TRIG_A (bit 11) for manual 
control flow
+   unsigned int event_triggers = 0x800;
+   // Note DRR trigger events are generated regardless of whether num 
frames met.
+   unsigned int num_frames = 2;
+
+   params.vertical_total_max = adjust.v_total_max;
+   params.vertical_total_min = adjust.v_total_min;
+   params.vertical_total_mid = adjust.v_total_mid;
+   params.vertical_total_mid_frame_num = adjust.v_total_mid_frame_num;
+
+   for (i = 0; i < num_pipes; i++) {
+   if ((pipe_ctx[i]->stream_res.tg != NULL) && 
pipe_ctx[i]->stream_res.tg->funcs) {
+   struct dc_crtc_timing *timing = 
_ctx[i]->stream->timing;
+   struct dc *dc = pipe_ctx[i]->stream->ctx->dc;
+
+   if (dc->debug.static_screen_wait_frames) {
+   unsigned int frame_rate = timing->pix_clk_100hz 
/ (timing->h_total * timing->v_total);
+
+   if (frame_rate >= 120 && dc->caps.ips_support &&
+   dc->config.disable_ips != 
DMUB_IPS_DISABLE_ALL) {
+   /*ips enable case*/
+   num_frames = 2 * (frame_rate % 60);
+   }
+   }
+   if (pipe_ctx[i]->stream_res.tg->funcs->set_drr)
+   pipe_ctx[i]->stream_res.tg->funcs->set_drr(
+   pipe_ctx[i]->stream_res.tg, );
+   if (adjust.v_total_max != 0 && adjust.v_total_min != 0)
+   if 
(pipe_ctx[i]->stream_res.tg->funcs->set_static_screen_control)
+   
pipe_ctx[i]->stream_res.tg->funcs->set_static_screen_control(
+   pipe_ctx[i]->stream_res.tg,
+   event_triggers, num_frames);
+   }
+   }
+}
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h
index b7bafe7fe2fd..fd66316e33de 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.h
@@ -86,4 +86,8 @@ void dcn35_dsc_pg_control(
 
 void dcn35_set_idle_state(const struct dc *dc, bool allow_idle);
 uint32_t dcn35_get_idle_state(const struct dc *dc);
+
+void dcn35_set_drr(struct pipe_ctx **pipe_ctx,
+   int num_pipes, struct 

[PATCH 22/25] drm/amd/display: Fix hang/underflow when transitioning to ODM4:1

[Wayne Lin]

From: Ilya Bakoulin 

[Why]
Under some circumstances, disabling an OPTC and attempting to reclaim
its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs
not being properly disconnected from the disabled OPTC.

[How]
Ensure that all OPPs are unassigned from an OPTC when it gets disabled.

Reviewed-by: Alvin Lee 
Acked-by: Wayne Lin 
Signed-off-by: Ilya Bakoulin 
---
 drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c | 7 +++
 drivers/gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c 
b/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
index a2c4db2cebdd..91ea0d4da06a 100644
--- a/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
@@ -172,6 +172,13 @@ static bool optc32_disable_crtc(struct timing_generator 
*optc)
REG_UPDATE(OTG_CONTROL,
OTG_MASTER_EN, 0);
 
+   REG_UPDATE_5(OPTC_DATA_SOURCE_SELECT,
+   OPTC_SEG0_SRC_SEL, 0xf,
+   OPTC_SEG1_SRC_SEL, 0xf,
+   OPTC_SEG2_SRC_SEL, 0xf,
+   OPTC_SEG3_SRC_SEL, 0xf,
+   OPTC_NUM_OF_INPUT_SEGMENT, 0);
+
REG_UPDATE(CONTROL,
VTG0_ENABLE, 0);
 
diff --git a/drivers/gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c 
b/drivers/gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c
index a4a39f1638cf..08a59cf449ca 100644
--- a/drivers/gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c
@@ -144,6 +144,13 @@ static bool optc35_disable_crtc(struct timing_generator 
*optc)
REG_UPDATE(OTG_CONTROL,
OTG_MASTER_EN, 0);
 
+   REG_UPDATE_5(OPTC_DATA_SOURCE_SELECT,
+   OPTC_SEG0_SRC_SEL, 0xf,
+   OPTC_SEG1_SRC_SEL, 0xf,
+   OPTC_SEG2_SRC_SEL, 0xf,
+   OPTC_SEG3_SRC_SEL, 0xf,
+   OPTC_NUM_OF_INPUT_SEGMENT, 0);
+
REG_UPDATE(CONTROL,
VTG0_ENABLE, 0);
 
-- 
2.37.3

[PATCH 21/25] drm/amd/display: Only clear symclk otg flag for HDMI

[Wayne Lin]

From: Alvin Lee 

[Description]
There is a corner case where the symclk otg flag is cleared
when disabling the phantom pipe for subvp (because the phantom
and main pipe share the same link). This is undesired because
we need the maintain the correct symclk otg flag state for
the main pipe.

For now only clear the flag only for HDMI signal type, since
it's only set for HDMI signal type (phantom is virtual). The
ideal solution is to not clear it if the stream is phantom but
currently there's a bug that doesn't allow us to do this. Once
this issue is fixed the proper fix can be implemented.

Reviewed-by: Samson Tam 
Acked-by: Wayne Lin 
Signed-off-by: Alvin Lee 
---
 drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 3 ++-
 drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c   | 3 ++-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
index 05d0e218bfb2..b943d47583e5 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c
@@ -2124,7 +2124,8 @@ static void dce110_reset_hw_ctx_wrap(
BREAK_TO_DEBUGGER();
}

pipe_ctx_old->stream_res.tg->funcs->disable_crtc(pipe_ctx_old->stream_res.tg);
-   
pipe_ctx_old->stream->link->phy_state.symclk_ref_cnts.otg = 0;
+   if 
(dc_is_hdmi_tmds_signal(pipe_ctx_old->stream->signal))
+   
pipe_ctx_old->stream->link->phy_state.symclk_ref_cnts.otg = 0;
pipe_ctx_old->plane_res.mi->funcs->free_mem_input(
pipe_ctx_old->plane_res.mi, 
dc->current_state->stream_count);
 
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
index 632aa091b6b6..1c5e3bb6f0ee 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
@@ -1058,7 +1058,8 @@ static void dcn10_reset_back_end_for_pipe(
if (pipe_ctx->stream_res.tg->funcs->set_drr)
pipe_ctx->stream_res.tg->funcs->set_drr(
pipe_ctx->stream_res.tg, NULL);
-   pipe_ctx->stream->link->phy_state.symclk_ref_cnts.otg = 0;
+   if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+   pipe_ctx->stream->link->phy_state.symclk_ref_cnts.otg = 
0;
}
 
for (i = 0; i < dc->res_pool->pipe_count; i++)
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index 88fe102f8288..0dfcb3cdcd20 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -2624,7 +2624,8 @@ static void dcn20_reset_back_end_for_pipe(
 * the case where the same symclk is shared across multiple otg
 * instances
 */
-   link->phy_state.symclk_ref_cnts.otg = 0;
+   if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+   link->phy_state.symclk_ref_cnts.otg = 0;
if (link->phy_state.symclk_state == SYMCLK_ON_TX_OFF) {
link_hwss->disable_link_output(link,
_ctx->link_res, 
pipe_ctx->stream->signal);
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
index 994250b6f2ef..260860c259f3 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c
@@ -524,7 +524,8 @@ static void dcn31_reset_back_end_for_pipe(
if (pipe_ctx->stream_res.tg->funcs->set_odm_bypass)
pipe_ctx->stream_res.tg->funcs->set_odm_bypass(
pipe_ctx->stream_res.tg, 
_ctx->stream->timing);
-   pipe_ctx->stream->link->phy_state.symclk_ref_cnts.otg = 0;
+   if (dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal))
+   pipe_ctx->stream->link->phy_state.symclk_ref_cnts.otg = 0;
 
if (pipe_ctx->stream_res.tg->funcs->set_drr)
pipe_ctx->stream_res.tg->funcs->set_drr(
-- 
2.37.3

[PATCH 19/25] drm/amd/display: Refactor phantom resource allocation

[Wayne Lin]

From: Dillon Varone 

[WHY?]
Phantom streams and planes were previously not referenced explcitly on creation.

[HOW?]
To reduce memory management complexity, add an additional phantom streams and 
planes
reference into dc_state, and move mall_stream_config to stream_status inside
the state to make it safe to modify in shallow copies. Also consildates any 
logic
that is affected by this change to dc_state.

Reviewed-by: Nicholas Kazlauskas 
Reviewed-by: Jun Lei 
Acked-by: Wayne Lin 
Signed-off-by: Dillon Varone 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   9 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c  |  91 +---
 .../drm/amd/display/dc/core/dc_hw_sequencer.c |  11 +-
 .../gpu/drm/amd/display/dc/core/dc_resource.c | 128 +-
 .../gpu/drm/amd/display/dc/core/dc_state.c| 428 --
 .../gpu/drm/amd/display/dc/core/dc_stream.c   |  13 +-
 drivers/gpu/drm/amd/display/dc/dc.h   |  18 +-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  |   7 +-
 drivers/gpu/drm/amd/display/dc/dc_state.h |   6 +-
 .../gpu/drm/amd/display/dc/dc_state_priv.h|  15 +-
 drivers/gpu/drm/amd/display/dc/dc_stream.h|  30 +-
 .../gpu/drm/amd/display/dc/dc_stream_priv.h   |   2 +
 .../display/dc/dcn32/dcn32_resource_helpers.c |  65 ---
 .../drm/amd/display/dc/dml/dcn32/dcn32_fpu.c  |   6 +-
 .../amd/display/dc/dml2/dml2_mall_phantom.c   |  30 +-
 .../drm/amd/display/dc/dml2/dml2_wrapper.h|   5 +-
 .../amd/display/dc/hwss/dce110/dce110_hwseq.c |   7 +-
 .../amd/display/dc/hwss/dcn10/dcn10_hwseq.c   |  25 +-
 .../amd/display/dc/hwss/dcn10/dcn10_hwseq.h   |   7 +-
 .../amd/display/dc/hwss/dcn20/dcn20_hwseq.c   |  27 +-
 .../amd/display/dc/hwss/dcn20/dcn20_hwseq.h   |   2 +-
 .../amd/display/dc/hwss/dcn201/dcn201_hwseq.c |   8 +-
 .../amd/display/dc/hwss/dcn201/dcn201_hwseq.h |   2 +-
 .../amd/display/dc/hwss/dcn32/dcn32_hwseq.c   |  42 +-
 .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c   |   8 +-
 .../amd/display/dc/hwss/dcn35/dcn35_hwseq.h   |   2 +-
 .../drm/amd/display/dc/hwss/hw_sequencer.h|   8 +-
 .../display/dc/hwss/hw_sequencer_private.h|   1 +
 .../gpu/drm/amd/display/dc/inc/core_types.h   |  20 +-
 .../gpu/drm/amd/display/dc/inc/hw/hw_shared.h |   1 +
 .../dc/resource/dcn32/dcn32_resource.c|  85 
 .../dc/resource/dcn32/dcn32_resource.h|  14 -
 .../dc/resource/dcn321/dcn321_resource.c  |   4 -
 33 files changed, 578 insertions(+), 549 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 186f3e3eb6c8..d60a751ff1d1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2606,12 +2606,10 @@ static enum dc_status 
amdgpu_dm_commit_zero_streams(struct dc *dc)
 
memset(del_streams, 0, sizeof(del_streams));
 
-   context = dc_state_create(dc);
+   context = dc_state_create_current_copy(dc);
if (context == NULL)
goto context_alloc_fail;
 
-   dc_resource_state_copy_construct_current(dc, context);
-
/* First remove from context all streams */
for (i = 0; i < context->stream_count; i++) {
struct dc_stream_state *stream = context->streams[i];
@@ -2921,7 +2919,6 @@ static int dm_resume(void *handle)
dc_state_release(dm_state->context);
dm_state->context = dc_state_create(dm->dc);
/* TODO: Remove dc_state->dccg, use dc->dccg directly. */
-   dc_resource_state_construct(dm->dc, dm_state->context);
 
/* Before powering on DC we need to re-initialize DMUB. */
dm_dmub_hw_resume(adev);
@@ -4049,14 +4046,12 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
if (!state)
return -ENOMEM;
 
-   state->context = dc_state_create(adev->dm.dc);
+   state->context = dc_state_create_current_copy(adev->dm.dc);
if (!state->context) {
kfree(state);
return -ENOMEM;
}
 
-   dc_resource_state_copy_construct_current(adev->dm.dc, state->context);
-
drm_atomic_private_obj_init(adev_to_drm(adev),
>dm.atomic_obj,
>base,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index f5250022b98e..630a55b2c1d4 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1046,8 +1046,6 @@ static bool dc_construct(struct dc *dc,
if (!create_link_encoders(dc))
goto fail;
 
-   dc_resource_state_construct(dc, dc->current_state);
-
return true;
 
 fail:
@@ -1120,7 +1118,7 @@ static void dc_update_viusal_confirm_color(struct dc *dc, 
struct dc_state *conte
 static void disable_dangling_plane(struct dc *dc, struct dc_state *context)
 {
int i, j;
-   struct dc_state *dangling_context = dc_state_create(dc);
+   struct 

[PATCH 20/25] drm/amd/display: Fix lightup regression with DP2 single display configs

[Wayne Lin]

From: Michael Strauss 

[WHY]
Previous fix for multiple displays downstream of DP2 MST hub caused regression

[HOW]
Match sink IDs instead of sink struct addresses

Reviewed-by: Nicholas Kazlauskas 
Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Michael Strauss 
---
 drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c 
b/drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c
index 9156e2ea55f5..8c0794af5ade 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c
@@ -161,6 +161,14 @@ bool is_dp2p0_output_encoder(const struct pipe_ctx 
*pipe_ctx)
if (pipe_ctx->stream == NULL)
return false;
 
+   /* Count MST hubs once by treating only 1st remote sink in topology as 
an encoder */
+   if (pipe_ctx->stream->link && pipe_ctx->stream->link->remote_sinks[0]) {
+   return (pipe_ctx->stream_res.hpo_dp_stream_enc &&
+   pipe_ctx->link_res.hpo_dp_link_enc &&
+   dc_is_dp_signal(pipe_ctx->stream->signal) &&
+   (pipe_ctx->stream->link->remote_sinks[0]->sink_id == 
pipe_ctx->stream->sink->sink_id));
+   }
+
return (pipe_ctx->stream_res.hpo_dp_stream_enc &&
pipe_ctx->link_res.hpo_dp_link_enc &&
dc_is_dp_signal(pipe_ctx->stream->signal));
-- 
2.37.3

[PATCH 17/25] drm/amd/display: Wake DMCUB before executing GPINT commands

[Wayne Lin]

From: Nicholas Kazlauskas 

[Why]
DMCUB can be in idle when we attempt to interface with the HW through
the GPINT mailbox resulting in a system hang.

[How]
Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
sequence.

If the GPINT executes successfully then DMCUB will be put back into
sleep after the optional response is returned.

It functions similar to the inbox command interface.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: sta...@vger.kernel.org
Reviewed-by: Hansen Dsouza 
Acked-by: Wayne Lin 
Signed-off-by: Nicholas Kazlauskas 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 29 ++--
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 72 ++-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h  | 11 +++
 drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 19 ++---
 4 files changed, 77 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 98b41ec7288e..68a846323912 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -2976,7 +2976,6 @@ static int dmub_trace_mask_set(void *data, u64 val)
struct amdgpu_device *adev = data;
struct dmub_srv *srv = adev->dm.dc->ctx->dmub_srv->dmub;
enum dmub_gpint_command cmd;
-   enum dmub_status status;
u64 mask = 0x;
u8 shift = 0;
u32 res;
@@ -3003,13 +3002,7 @@ static int dmub_trace_mask_set(void *data, u64 val)
break;
}
 
-   status = dmub_srv_send_gpint_command(srv, cmd, res, 30);
-
-   if (status == DMUB_STATUS_TIMEOUT)
-   return -ETIMEDOUT;
-   else if (status == DMUB_STATUS_INVALID)
-   return -EINVAL;
-   else if (status != DMUB_STATUS_OK)
+   if (!dc_wake_and_execute_gpint(adev->dm.dc->ctx, cmd, res, 
NULL, DM_DMUB_WAIT_TYPE_WAIT))
return -EIO;
 
usleep_range(100, 1000);
@@ -3026,7 +3019,6 @@ static int dmub_trace_mask_show(void *data, u64 *val)
enum dmub_gpint_command cmd = DMUB_GPINT__GET_TRACE_BUFFER_MASK_WORD0;
struct amdgpu_device *adev = data;
struct dmub_srv *srv = adev->dm.dc->ctx->dmub_srv->dmub;
-   enum dmub_status status;
u8 shift = 0;
u64 raw = 0;
u64 res = 0;
@@ -3036,23 +3028,12 @@ static int dmub_trace_mask_show(void *data, u64 *val)
return -EINVAL;
 
while (i < 4) {
-   status = dmub_srv_send_gpint_command(srv, cmd, 0, 30);
-
-   if (status == DMUB_STATUS_OK) {
-   status = dmub_srv_get_gpint_response(srv, (u32 *) );
-
-   if (status == DMUB_STATUS_INVALID)
-   return -EINVAL;
-   else if (status != DMUB_STATUS_OK)
-   return -EIO;
-   } else if (status == DMUB_STATUS_TIMEOUT) {
-   return -ETIMEDOUT;
-   } else if (status == DMUB_STATUS_INVALID) {
-   return -EINVAL;
-   } else {
+   uint32_t response;
+
+   if (!dc_wake_and_execute_gpint(adev->dm.dc->ctx, cmd, 0, 
, DM_DMUB_WAIT_TYPE_WAIT_WITH_REPLY))
return -EIO;
-   }
 
+   raw = response;
usleep_range(100, 1000);
 
cmd++;
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 fea13bcd4dc7..4b93e7a529d5 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -301,17 +301,11 @@ bool dc_dmub_srv_optimized_init_done(struct dc_dmub_srv 
*dc_dmub_srv)
 bool dc_dmub_srv_notify_stream_mask(struct dc_dmub_srv *dc_dmub_srv,
unsigned int stream_mask)
 {
-   struct dmub_srv *dmub;
-   const uint32_t timeout = 30;
-
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
 
-   dmub = dc_dmub_srv->dmub;
-
-   return dmub_srv_send_gpint_command(
-  dmub, DMUB_GPINT__IDLE_OPT_NOTIFY_STREAM_MASK,
-  stream_mask, timeout) == DMUB_STATUS_OK;
+   return dc_wake_and_execute_gpint(dc_dmub_srv->ctx, 
DMUB_GPINT__IDLE_OPT_NOTIFY_STREAM_MASK,
+stream_mask, NULL, 
DM_DMUB_WAIT_TYPE_WAIT);
 }
 
 bool dc_dmub_srv_is_restore_required(struct dc_dmub_srv *dc_dmub_srv)
@@ -1126,25 +1120,20 @@ bool dc_dmub_check_min_version(struct dmub_srv *srv)
 void dc_dmub_srv_enable_dpia_trace(const struct dc *dc)
 {
struct dc_dmub_srv *dc_dmub_srv = dc->ctx->dmub_srv;
-   struct dmub_srv *dmub;
-   enum dmub_status status;
-   static const uint32_t timeout_us = 30;
 
if (!dc_dmub_srv || 

[PATCH 16/25] drm/amd/display: Wake DMCUB before sending a command

[Wayne Lin]

From: Nicholas Kazlauskas 

[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.

[How]
For functions that execute within a DC context or DC lock we can
wrap the direct calls to dm_execute_dmub_cmd/list with code that
exits idle power optimizations and reallows once we're done with
the command submission on success.

For DM direct submissions the DM will need to manage the enter/exit
sequencing manually.

We cannot invoke a DMCUB command directly within the DM execution
helper or we can deadlock.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: sta...@vger.kernel.org
Reviewed-by: Hansen Dsouza 
Acked-by: Wayne Lin 
Signed-off-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 .../drm/amd/display/dc/bios/command_table2.c  | 12 ++---
 .../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c  |  2 +-
 .../dc/clk_mgr/dcn314/dcn314_clk_mgr.c|  2 +-
 .../dc/clk_mgr/dcn315/dcn315_clk_mgr.c|  2 +-
 .../dc/clk_mgr/dcn316/dcn316_clk_mgr.c|  2 +-
 .../display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c  | 12 ++---
 .../drm/amd/display/dc/core/dc_hw_sequencer.c |  2 +-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 53 ---
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h  | 40 ++
 drivers/gpu/drm/amd/display/dc/dc_helper.c|  6 +--
 .../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c | 14 ++---
 .../drm/amd/display/dc/dce/dmub_hw_lock_mgr.c |  2 +-
 .../gpu/drm/amd/display/dc/dce/dmub_outbox.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 14 ++---
 .../gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c |  2 +-
 .../display/dc/dcn31/dcn31_dio_link_encoder.c |  4 +-
 .../amd/display/dc/dcn31/dcn31_panel_cntl.c   |  4 +-
 .../amd/display/dc/hwss/dcn21/dcn21_hwseq.c   |  4 +-
 .../amd/display/dc/hwss/dcn30/dcn30_hwseq.c   |  8 +--
 .../amd/display/dc/hwss/dcn31/dcn31_hwseq.c   |  4 +-
 .../amd/display/dc/hwss/dcn32/dcn32_hwseq.c   |  6 +--
 .../dc/link/protocols/link_dp_capability.c|  2 +-
 .../display/dc/link/protocols/link_dp_dpia.c  |  3 +-
 25 files changed, 143 insertions(+), 63 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 0954d7057a9b..34780bcde59c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10860,7 +10860,7 @@ static bool dm_edid_parser_send_cea(struct 
amdgpu_display_manager *dm,
input->cea_total_length = total_length;
memcpy(input->payload, data, length);
 
-   res = dm_execute_dmub_cmd(dm->dc->ctx, , 
DM_DMUB_WAIT_TYPE_WAIT_WITH_REPLY);
+   res = dc_wake_and_execute_dmub_cmd(dm->dc->ctx, , 
DM_DMUB_WAIT_TYPE_WAIT_WITH_REPLY);
if (!res) {
DRM_ERROR("EDID CEA parser failed\n");
return false;
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c 
b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
index ab0adabf9dd4..293a919d605d 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
@@ -123,7 +123,7 @@ static void encoder_control_dmcub(
sizeof(cmd.digx_encoder_control.header);
cmd.digx_encoder_control.encoder_control.dig.stream_param = *dig;
 
-   dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
+   dc_wake_and_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
 }
 
 static enum bp_result encoder_control_digx_v1_5(
@@ -259,7 +259,7 @@ static void transmitter_control_dmcub(
sizeof(cmd.dig1_transmitter_control.header);
cmd.dig1_transmitter_control.transmitter_control.dig = *dig;
 
-   dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
+   dc_wake_and_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
 }
 
 static enum bp_result transmitter_control_v1_6(
@@ -321,7 +321,7 @@ static void transmitter_control_dmcub_v1_7(
sizeof(cmd.dig1_transmitter_control.header);
cmd.dig1_transmitter_control.transmitter_control.dig_v1_7 = *dig;
 
-   dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
+   dc_wake_and_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
 }
 
 static enum bp_result transmitter_control_v1_7(
@@ -429,7 +429,7 @@ static void set_pixel_clock_dmcub(
sizeof(cmd.set_pixel_clock.header);
cmd.set_pixel_clock.pixel_clock.clk = *clk;
 
-   dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
+   dc_wake_and_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
 }
 
 static enum bp_result set_pixel_clock_v7(
@@ -796,7 +796,7 @@ static void enable_disp_power_gating_dmcub(
sizeof(cmd.enable_disp_power_gating.header);
cmd.enable_disp_power_gating.power_gating.pwr = *pwr;
 
-   dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
+   

[PATCH 15/25] drm/amd/display: Refactor DMCUB enter/exit idle interface

[Wayne Lin]

From: Nicholas Kazlauskas 

[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.

[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.

Fixing this issue involves the following:

1. Using a software state to track whether or not we need to start
   the process to exit idle or notify idle.

It's possible for the hardware to have exited an idle state without
driver knowledge, but entering one is always restricted to a driver
allow - which makes the SW state vs HW state mismatch issue purely one
of optimization, which should seldomly be hit, if at all.

2. Refactor any instances of exit/notify idle to use a single wrapper
   that maintains this SW state.

This works simialr to dc_allow_idle_optimizations, but works at the
DMCUB level and makes sure the state is marked prior to any notify/exit
idle so we don't enter an infinite loop.

3. Make sure we exit out of idle prior to sending any commands or
   waiting for DMCUB idle.

This patch takes care of 1/2. A future patch will take care of wrapping
DMCUB command submission with calls to this new interface.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: sta...@vger.kernel.org
Reviewed-by: Hansen Dsouza 
Acked-by: Wayne Lin 
Signed-off-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  4 +-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 37 ++-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h  |  6 ++-
 .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c   |  8 +---
 4 files changed, 43 insertions(+), 12 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 84efa9e7c951..0954d7057a9b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2854,7 +2854,7 @@ static int dm_resume(void *handle)
bool need_hotplug = false;
 
if (dm->dc->caps.ips_support) {
-   dc_dmub_srv_exit_low_power_state(dm->dc);
+   dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false);
}
 
if (amdgpu_in_reset(adev)) {
@@ -8968,7 +8968,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
if (new_con_state->crtc &&
new_con_state->crtc->state->active &&

drm_atomic_crtc_needs_modeset(new_con_state->crtc->state)) {
-   dc_dmub_srv_exit_low_power_state(dm->dc);
+   
dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false);
break;
}
}
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 eb6f5640f19a..ccfe2b6046fd 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -1162,6 +1162,9 @@ bool dc_dmub_srv_is_hw_pwr_up(struct dc_dmub_srv 
*dc_dmub_srv, bool wait)
struct dc_context *dc_ctx = dc_dmub_srv->ctx;
enum dmub_status status;
 
+   if (!dc_dmub_srv || !dc_dmub_srv->dmub)
+   return true;
+
if (dc_dmub_srv->ctx->dc->debug.dmcub_emulation)
return true;
 
@@ -1183,7 +1186,7 @@ bool dc_dmub_srv_is_hw_pwr_up(struct dc_dmub_srv 
*dc_dmub_srv, bool wait)
return true;
 }
 
-void dc_dmub_srv_notify_idle(const struct dc *dc, bool allow_idle)
+static void dc_dmub_srv_notify_idle(const struct dc *dc, bool allow_idle)
 {
union dmub_rb_cmd cmd = {0};
 
@@ -1207,7 +1210,7 @@ void dc_dmub_srv_notify_idle(const struct dc *dc, bool 
allow_idle)
dm_execute_dmub_cmd(dc->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
 }
 
-void dc_dmub_srv_exit_low_power_state(const struct dc *dc)
+static void dc_dmub_srv_exit_low_power_state(const struct dc *dc)
 {
const uint32_t max_num_polls = 1;
uint32_t allow_state = 0;
@@ -1220,6 +1223,9 @@ void dc_dmub_srv_exit_low_power_state(const struct dc *dc)
if (!dc->idle_optimizations_allowed)
return;
 
+   if (!dc->ctx->dmub_srv || !dc->ctx->dmub_srv->dmub)
+   return;
+
if (dc->hwss.get_idle_state &&
dc->hwss.set_idle_state &&
dc->clk_mgr->funcs->exit_low_power_state) {
@@ -1296,3 +1302,30 @@ void dc_dmub_srv_set_power_state(struct dc_dmub_srv 
*dc_dmub_srv, enum dc_acpi_c
else
dmub_srv_set_power_state(dmub, DMUB_POWER_STATE_D3);
 }
+
+void dc_dmub_srv_apply_idle_power_optimizations(const struct dc *dc, bool 
allow_idle)
+{
+   struct dc_dmub_srv *dc_dmub_srv = dc->ctx->dmub_srv;
+
+   if (!dc_dmub_srv || !dc_dmub_srv->dmub)
+   return;
+
+   if (dc_dmub_srv->idle_allowed == allow_idle)
+   return;
+
+   /*
+* Entering a low power state requires 

[PATCH 14/25] drm/amd/display: enable dcn35 idle power optimization

[Wayne Lin]

From: Roman Li 

[Why]
Idle power optimization was disabled on dcn35 by default.

[How]
Enable by setting disable_idle_power_optimizations to false.

Reviewed-by: Nicholas Kazlauskas 
Acked-by: Wayne Lin 
Signed-off-by: Roman Li 
---
 drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c 
b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
index 4e1db842b98c..04225cdc1904 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
@@ -766,7 +766,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.enable_hpo_pg_support = false,
.enable_legacy_fast_update = true,
.enable_single_display_2to1_odm_policy = false,
-   .disable_idle_power_optimizations = true,
+   .disable_idle_power_optimizations = false,
.dmcub_emulation = false,
.disable_boot_optimizations = false,
.disable_unbounded_requesting = false,
-- 
2.37.3

[PATCH 13/25] drm/amd/display: fix usb-c connector_type

[Wayne Lin]

From: Allen Pan 

[why]
BIOS switches to use USB-C connector type 0x18, but VBIOS's
objectInfo table not supported yet. driver needs to patch it
based on enc_cap from system integration info table.

Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Allen Pan 
---
 .../gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c| 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c
index f91e08895275..da94e5309fba 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c
@@ -256,6 +256,10 @@ void dcn35_link_encoder_construct(
enc10->base.features.flags.bits.IS_UHBR10_CAPABLE = 
bp_cap_info.DP_UHBR10_EN;
enc10->base.features.flags.bits.IS_UHBR13_5_CAPABLE = 
bp_cap_info.DP_UHBR13_5_EN;
enc10->base.features.flags.bits.IS_UHBR20_CAPABLE = 
bp_cap_info.DP_UHBR20_EN;
+   if (bp_cap_info.DP_IS_USB_C) {
+   /*BIOS not switch to use CONNECTOR_ID_USBC = 24 yet*/
+   enc10->base.features.flags.bits.DP_IS_USB_C = 1;
+   }
 
} else {
DC_LOG_WARNING("%s: Failed to get encoder_cap_info from VBIOS 
with error code %d!\n",
@@ -264,4 +268,5 @@ void dcn35_link_encoder_construct(
}
if (enc10->base.ctx->dc->debug.hdmi20_disable)
enc10->base.features.flags.bits.HDMI_6GB_EN = 0;
+
 }
-- 
2.37.3

[PATCH 12/25] drm/amd/display: add debug option for ExtendedVBlank DLG adjust

[Wayne Lin]

From: Muhammad Ahmed 

[why & how]
Add new option for debug usage

Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Muhammad Ahmed 
---
 drivers/gpu/drm/amd/display/dc/dc.h | 1 +
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index c87ec3e0a8cf..ce00a6eeb164 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -979,6 +979,7 @@ struct dc_debug_options {
unsigned int ips2_eval_delay_us;
unsigned int ips2_entry_delay_us;
bool disable_timeout;
+   bool disable_extblankadj;
 };
 
 struct gpu_info_soc_bounding_box_v1_0;
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index 2c8eff815ec1..72c580ec650c 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -2221,7 +2221,8 @@ void dcn20_optimize_bandwidth(
dc->clk_mgr,
context,
true);
-   if (context->bw_ctx.bw.dcn.clk.zstate_support == 
DCN_ZSTATE_SUPPORT_ALLOW) {
+   if (context->bw_ctx.bw.dcn.clk.zstate_support == 
DCN_ZSTATE_SUPPORT_ALLOW &&
+   !dc->debug.disable_extblankadj) {
for (i = 0; i < dc->res_pool->pipe_count; ++i) {
struct pipe_ctx *pipe_ctx = 
>res_ctx.pipe_ctx[i];
 
-- 
2.37.3

[PATCH 11/25] drm/amd/display: Set test_pattern_changed update flag on pipe enable

[Wayne Lin]

From: George Shen 

[Why]
In certain cases, ODM pipe split can occur while stream already has test
pattern enabled. The new pipe used in the ODM combine config must be
configured to output the test pattern in this case.

[How]
If the stream is configured to output test pattern, then set the
test_pattern_changed update flag for the new pipe when it gets enabled.

Reviewed-by: Alvin Lee 
Acked-by: Wayne Lin 
Signed-off-by: George Shen 
---
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index 5bb5e2960276..2c8eff815ec1 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -1400,6 +1400,10 @@ static void dcn20_detect_pipe_changes(struct pipe_ctx 
*old_pipe, struct pipe_ctx
new_pipe->update_flags.bits.scaler = 1;
new_pipe->update_flags.bits.viewport = 1;
new_pipe->update_flags.bits.det_size = 1;
+   if (new_pipe->stream->test_pattern.type != 
DP_TEST_PATTERN_VIDEO_MODE &&
+   new_pipe->stream_res.test_pattern_params.width 
!= 0 &&
+   new_pipe->stream_res.test_pattern_params.height 
!= 0)
+   new_pipe->update_flags.bits.test_pattern_changed = 1;
if (!new_pipe->top_pipe && !new_pipe->prev_odm_pipe) {
new_pipe->update_flags.bits.odm = 1;
new_pipe->update_flags.bits.global_sync = 1;
-- 
2.37.3

[PATCH 10/25] drm/amd/display: dereference variable before checking for zero

[Wayne Lin]

From: Josip Pavic 

[Why]
Driver incorrectly checks if pointer variable OutBpp is null instead of
if the value being pointed to is zero.

[How]
Dereference OutBpp before checking for a value of zero.

Reviewed-by: Chaitanya Dhere 
Acked-by: Wayne Lin 
Signed-off-by: Josip Pavic 
---
 drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c 
b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
index 180f8a98a361..b95bf27f2fe2 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
@@ -5420,7 +5420,7 @@ static void CalculateOutputLink(
*OutBpp = TruncToValidBPP((1 - 
Downspreading / 100) * 13500, OutputLinkDPLanes, HTotal, HActive, 
PixelClockBackEnd, ForcedOutputLinkBPP, LinkDSCEnable, Output,

OutputFormat, DSCInputBitPerComponent, NumberOfDSCSlices, 
(dml_uint_t)AudioSampleRate, AudioSampleLayout, ODMModeNoDSC, ODMModeDSC, 
RequiredSlots);
 
-   if (OutBpp == 0 && PHYCLKD32PerState < 
2 / 32 && DSCEnable == dml_dsc_enable_if_necessary && ForcedOutputLinkBPP 
== 0) {
+   if (*OutBpp == 0 && PHYCLKD32PerState < 
2 / 32 && DSCEnable == dml_dsc_enable_if_necessary && ForcedOutputLinkBPP 
== 0) {
*RequiresDSC = true;
LinkDSCEnable = true;
*OutBpp = TruncToValidBPP((1 - 
Downspreading / 100) * 13500, OutputLinkDPLanes, HTotal, HActive, 
PixelClockBackEnd, ForcedOutputLinkBPP, LinkDSCEnable, Output,
-- 
2.37.3

[PATCH 09/25] drm/amd/display: get dprefclk ss info from integration info table

[Wayne Lin]

From: Charlene Liu 

[why & how]
we have two SSC_En:
we get ssc_info from dce_info for MPLL_SSC_EN.
we used to call VBIOS cmdtbl's smu_info's SS persentage for DPRECLK SS info,
is used for DP AUDIO and VBIOS' smu_info table was from 
systemIntegrationInfoTable.

since dcn35 VBIOS removed smu_info, driver need to use integrationInfotable 
directly.

Reviewed-by: Nicholas Kazlauskas 
Acked-by: Wayne Lin 
Signed-off-by: Charlene Liu 
---
 .../drm/amd/display/dc/bios/bios_parser2.c| 19 ++-
 .../display/include/grph_object_ctrl_defs.h   |  2 ++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index fcd65a2057ad..960c4b4f6ddf 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1014,13 +1014,20 @@ static enum bp_result get_ss_info_v4_5(
DC_LOG_BIOS("AS_SIGNAL_TYPE_HDMI ss_percentage: %d\n", 
ss_info->spread_spectrum_percentage);
break;
case AS_SIGNAL_TYPE_DISPLAY_PORT:
-   ss_info->spread_spectrum_percentage =
+   if (bp->base.integrated_info) {
+   DC_LOG_BIOS("gpuclk_ss_percentage (unit of 0.001 
percent): %d\n", bp->base.integrated_info->gpuclk_ss_percentage);
+   ss_info->spread_spectrum_percentage =
+   
bp->base.integrated_info->gpuclk_ss_percentage;
+   ss_info->type.CENTER_MODE =
+   
bp->base.integrated_info->gpuclk_ss_type;
+   } else {
+   ss_info->spread_spectrum_percentage =
disp_cntl_tbl->dp_ss_percentage;
-   ss_info->spread_spectrum_range =
+   ss_info->spread_spectrum_range =
disp_cntl_tbl->dp_ss_rate_10hz * 10;
-   if (disp_cntl_tbl->dp_ss_mode & ATOM_SS_CENTRE_SPREAD_MODE)
-   ss_info->type.CENTER_MODE = true;
-
+   if (disp_cntl_tbl->dp_ss_mode & 
ATOM_SS_CENTRE_SPREAD_MODE)
+   ss_info->type.CENTER_MODE = true;
+   }
DC_LOG_BIOS("AS_SIGNAL_TYPE_DISPLAY_PORT ss_percentage: %d\n", 
ss_info->spread_spectrum_percentage);
break;
case AS_SIGNAL_TYPE_GPU_PLL:
@@ -2813,6 +2820,8 @@ static enum bp_result get_integrated_info_v2_2(
info->ma_channel_number = info_v2_2->umachannelnumber;
info->dp_ss_control =
le16_to_cpu(info_v2_2->reserved1);
+   info->gpuclk_ss_percentage = info_v2_2->gpuclk_ss_percentage;
+   info->gpuclk_ss_type = info_v2_2->gpuclk_ss_type;
 
for (i = 0; i < NUMBER_OF_UCHAR_FOR_GUID; ++i) {
info->ext_disp_conn_info.gu_id[i] =
diff --git a/drivers/gpu/drm/amd/display/include/grph_object_ctrl_defs.h 
b/drivers/gpu/drm/amd/display/include/grph_object_ctrl_defs.h
index bc96d0211360..813463ffe15c 100644
--- a/drivers/gpu/drm/amd/display/include/grph_object_ctrl_defs.h
+++ b/drivers/gpu/drm/amd/display/include/grph_object_ctrl_defs.h
@@ -417,6 +417,8 @@ struct integrated_info {
/* V2.1 */
struct edp_info edp1_info;
struct edp_info edp2_info;
+   uint32_t gpuclk_ss_percentage;
+   uint32_t gpuclk_ss_type;
 };
 
 /*
-- 
2.37.3

[PATCH 08/25] drm/amd/display: skip error logging when DMUB is inactive from S3

[Wayne Lin]

From: Samson Tam 

[Why]
On resume from S3, while DMUB is inactive, DMUB queue and execute
calls will not work.  Skip reporting errors in these scenarios

[How]
Add new return code during DMUB queue and execute calls when DMUB
is in S3 state. Skip logging errors in these scenarios

Reviewed-by: Alvin Lee 
Acked-by: Wayne Lin 
Signed-off-by: Samson Tam 
---
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 34 +--
 drivers/gpu/drm/amd/display/dmub/dmub_srv.h   |  1 +
 .../gpu/drm/amd/display/dmub/src/dmub_srv.c   |  4 +--
 3 files changed, 27 insertions(+), 12 deletions(-)

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 1a4d615ccdec..eb6f5640f19a 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -140,7 +140,10 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct dc_dmub_srv 
*dc_dmub_srv,
 
if (status == DMUB_STATUS_QUEUE_FULL) {
/* Execute and wait for queue to become empty again. */
-   dmub_srv_cmd_execute(dmub);
+   status = dmub_srv_cmd_execute(dmub);
+   if (status == DMUB_STATUS_POWER_STATE_D3)
+   return false;
+
dmub_srv_wait_for_idle(dmub, 10);
 
/* Requeue the command. */
@@ -148,16 +151,20 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct 
dc_dmub_srv *dc_dmub_srv,
}
 
if (status != DMUB_STATUS_OK) {
-   DC_ERROR("Error queueing DMUB command: status=%d\n", 
status);
-   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   if (status != DMUB_STATUS_POWER_STATE_D3) {
+   DC_ERROR("Error queueing DMUB command: 
status=%d\n", status);
+   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   }
return false;
}
}
 
status = dmub_srv_cmd_execute(dmub);
if (status != DMUB_STATUS_OK) {
-   DC_ERROR("Error starting DMUB execution: status=%d\n", status);
-   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   if (status != DMUB_STATUS_POWER_STATE_D3) {
+   DC_ERROR("Error starting DMUB execution: status=%d\n", 
status);
+   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   }
return false;
}
 
@@ -218,7 +225,10 @@ bool dc_dmub_srv_cmd_run_list(struct dc_dmub_srv 
*dc_dmub_srv, unsigned int coun
 
if (status == DMUB_STATUS_QUEUE_FULL) {
/* Execute and wait for queue to become empty again. */
-   dmub_srv_cmd_execute(dmub);
+   status = dmub_srv_cmd_execute(dmub);
+   if (status == DMUB_STATUS_POWER_STATE_D3)
+   return false;
+
dmub_srv_wait_for_idle(dmub, 10);
 
/* Requeue the command. */
@@ -226,16 +236,20 @@ bool dc_dmub_srv_cmd_run_list(struct dc_dmub_srv 
*dc_dmub_srv, unsigned int coun
}
 
if (status != DMUB_STATUS_OK) {
-   DC_ERROR("Error queueing DMUB command: status=%d\n", 
status);
-   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   if (status != DMUB_STATUS_POWER_STATE_D3) {
+   DC_ERROR("Error queueing DMUB command: 
status=%d\n", status);
+   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   }
return false;
}
}
 
status = dmub_srv_cmd_execute(dmub);
if (status != DMUB_STATUS_OK) {
-   DC_ERROR("Error starting DMUB execution: status=%d\n", status);
-   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   if (status != DMUB_STATUS_POWER_STATE_D3) {
+   DC_ERROR("Error starting DMUB execution: status=%d\n", 
status);
+   dc_dmub_srv_log_diagnostic_data(dc_dmub_srv);
+   }
return false;
}
 
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h 
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index d1a4ed6f5916..c78c9224ab60 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -86,6 +86,7 @@ enum dmub_status {
DMUB_STATUS_TIMEOUT,
DMUB_STATUS_INVALID,
DMUB_STATUS_HW_FAILURE,
+   DMUB_STATUS_POWER_STATE_D3
 };
 
 /* enum dmub_asic - dmub asic identifier */
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c 
b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 53ac1c66dd86..9ad738805320 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++ 

[PATCH 07/25] drm/amd/display: make flip_timestamp_in_us a 64-bit variable

[Wayne Lin]

From: Josip Pavic 

[Why]
This variable currently overflows after about 71 minutes. This doesn't
cause any known functional issues but it does make debugging more
difficult.

[How]
Make it a 64-bit variable.

Reviewed-by: Aric Cyr 
Acked-by: Wayne Lin 
Signed-off-by: Josip Pavic 
---
 drivers/gpu/drm/amd/display/dc/dc_hw_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
index e2a3aa8812df..811474f4419b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hw_types.h
@@ -244,7 +244,7 @@ enum pixel_format {
 #define DC_MAX_DIRTY_RECTS 3
 struct dc_flip_addrs {
struct dc_plane_address address;
-   unsigned int flip_timestamp_in_us;
+   unsigned long long flip_timestamp_in_us;
bool flip_immediate;
/* TODO: add flip duration for FreeSync */
bool triplebuffer_flips;
-- 
2.37.3

[PATCH 06/25] drm/amd/display: Add case for dcn35 to support usb4 dmub hpd event

[Wayne Lin]

From: Wayne Lin 

[Why & how]
Refactor dc_is_dmub_outbox_supported() a bit and add case for dcn35 to
register dmub outbox notification irq to handle usb4 relevant hpd event.

Reviewed-by: Roman Li 
Reviewed-by: Jun Lei 
Signed-off-by: Wayne Lin 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 26 
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 0d42074f33a6..445f87fa0eac 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -5089,18 +5089,28 @@ void 
dc_mclk_switch_using_fw_based_vblank_stretch_shut_down(struct dc *dc)
  */
 bool dc_is_dmub_outbox_supported(struct dc *dc)
 {
-   /* DCN31 B0 USB4 DPIA needs dmub notifications for interrupts */
-   if (dc->ctx->asic_id.chip_family == FAMILY_YELLOW_CARP &&
-   dc->ctx->asic_id.hw_internal_rev == YELLOW_CARP_B0 &&
-   !dc->debug.dpia_debug.bits.disable_dpia)
-   return true;
+   switch (dc->ctx->asic_id.chip_family) {
 
-   if (dc->ctx->asic_id.chip_family == AMDGPU_FAMILY_GC_11_0_1 &&
-   !dc->debug.dpia_debug.bits.disable_dpia)
-   return true;
+   case FAMILY_YELLOW_CARP:
+   /* DCN31 B0 USB4 DPIA needs dmub notifications for interrupts */
+   if (dc->ctx->asic_id.hw_internal_rev == YELLOW_CARP_B0 &&
+   !dc->debug.dpia_debug.bits.disable_dpia)
+   return true;
+   break;
+
+   case AMDGPU_FAMILY_GC_11_0_1:
+   case AMDGPU_FAMILY_GC_11_5_0:
+   if (!dc->debug.dpia_debug.bits.disable_dpia)
+   return true;
+   break;
+
+   default:
+   break;
+   }
 
/* dmub aux needs dmub notifications to be enabled */
return dc->debug.enable_dmub_aux_for_legacy_ddc;
+
 }
 
 /**
-- 
2.37.3

[PATCH 05/25] drm/amd/display: Add function for dumping clk registers

[Wayne Lin]

From: Johnson Chen 

[why]
Allow devs to check raw clk register values by dumping them on the log

[how]
Add clk register dump implementation

Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Johnson Chen 
---
 .../display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c  |  7 +++
 .../gpu/drm/amd/display/dc/inc/hw/clk_mgr.h   | 19 +++
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c
index 8d4c0b209872..789091f3bdc8 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c
@@ -50,6 +50,7 @@
 #include "dc_dmub_srv.h"
 #include "link.h"
 #include "logger_types.h"
+
 #undef DC_LOGGER
 #define DC_LOGGER \
clk_mgr->base.base.ctx->logger
@@ -417,9 +418,8 @@ bool dcn35_are_clock_states_equal(struct dc_clocks *a,
 }
 
 static void dcn35_dump_clk_registers(struct clk_state_registers_and_bypass 
*regs_and_bypass,
-   struct clk_mgr *clk_mgr_base, struct clk_log_info *log_info)
+   struct clk_mgr_dcn35 *clk_mgr)
 {
-
 }
 
 static struct clk_bw_params dcn35_bw_params = {
@@ -986,7 +986,6 @@ void dcn35_clk_mgr_construct(
struct dccg *dccg)
 {
struct dcn35_smu_dpm_clks smu_dpm_clks = { 0 };
-   struct clk_log_info log_info = {0};
clk_mgr->base.base.ctx = ctx;
clk_mgr->base.base.funcs = _funcs;
 
@@ -1039,7 +1038,7 @@ void dcn35_clk_mgr_construct(
dcn35_bw_params.wm_table = ddr5_wm_table;
}
/* Saved clocks configured at boot for debug purposes */
-   dcn35_dump_clk_registers(_mgr->base.base.boot_snapshot, 
_mgr->base.base, _info);
+   dcn35_dump_clk_registers(_mgr->base.base.boot_snapshot, clk_mgr);
 
clk_mgr->base.base.dprefclk_khz = 
dcn35_smu_get_dprefclk(_mgr->base);
clk_mgr->base.base.clks.ref_dtbclk_khz = 60;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h
index fa9614bcb160..cbba39d251e5 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h
@@ -62,6 +62,25 @@ struct dcn3_clk_internal {
uint32_t CLK4_CLK0_CURRENT_CNT; //fclk
 };
 
+struct dcn35_clk_internal {
+   int dummy;
+   uint32_t CLK1_CLK0_CURRENT_CNT; //dispclk
+   uint32_t CLK1_CLK1_CURRENT_CNT; //dppclk
+   uint32_t CLK1_CLK2_CURRENT_CNT; //dprefclk
+   uint32_t CLK1_CLK3_CURRENT_CNT; //dcfclk
+   uint32_t CLK1_CLK4_CURRENT_CNT; //dtbclk
+   //uint32_t CLK1_CLK5_CURRENT_CNT; //dpiaclk
+   //uint32_t CLK1_CLK6_CURRENT_CNT; //srdbgclk
+   uint32_t CLK1_CLK3_DS_CNTL; //dcf_deep_sleep_divider
+   uint32_t CLK1_CLK3_ALLOW_DS;//dcf_deep_sleep_allow
+
+   uint32_t CLK1_CLK0_BYPASS_CNTL; //dispclk bypass
+   uint32_t CLK1_CLK1_BYPASS_CNTL; //dppclk bypass
+   uint32_t CLK1_CLK2_BYPASS_CNTL; //dprefclk bypass
+   uint32_t CLK1_CLK3_BYPASS_CNTL; //dcfclk bypass
+   uint32_t CLK1_CLK4_BYPASS_CNTL; //dtbclk bypass
+};
+
 struct dcn301_clk_internal {
int dummy;
uint32_t CLK1_CLK0_CURRENT_CNT; //dispclk
-- 
2.37.3

[PATCH 04/25] drm/amd/display: Unify optimize_required flags and VRR adjustments

[Wayne Lin]

From: Aric Cyr 

[why]
There is only a single call to dc_post_update_surfaces_to_stream so
there is no need to have two flags to control it. Unifying this to a
single flag allows dc_stream_adjust_vmin_vmax to skip actual
programming when there is no change required.

[how]
Remove wm_optimze_required flag and set only optimize_required in its
place.  Then in dc_stream_adjust_vmin_vmax, check that the stream timing
range matches the requested one and skip programming if they are equal.

Reviewed-by: Jun Lei 
Acked-by: Wayne Lin 
Signed-off-by: Aric Cyr 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 14 +-
 drivers/gpu/drm/amd/display/dc/dc.h|  1 -
 drivers/gpu/drm/amd/display/dc/dc_stream.h |  2 --
 .../drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c|  2 +-
 .../drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c|  8 
 5 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 9d3925603979..0d42074f33a6 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -409,9 +409,12 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc,
 * avoid conflicting with firmware updates.
 */
if (dc->ctx->dce_version > DCE_VERSION_MAX)
-   if (dc->optimized_required || dc->wm_optimized_required)
+   if (dc->optimized_required)
return false;
 
+   if (!memcmp(>adjust, adjust, sizeof(*adjust)))
+   return true;
+
stream->adjust.v_total_max = adjust->v_total_max;
stream->adjust.v_total_mid = adjust->v_total_mid;
stream->adjust.v_total_mid_frame_num = adjust->v_total_mid_frame_num;
@@ -2223,7 +2226,6 @@ void dc_post_update_surfaces_to_stream(struct dc *dc)
}
 
dc->optimized_required = false;
-   dc->wm_optimized_required = false;
 }
 
 static void init_state(struct dc *dc, struct dc_state *context)
@@ -2743,8 +2745,6 @@ enum surface_update_type 
dc_check_update_surfaces_for_stream(
} else if (memcmp(>current_state->bw_ctx.bw.dcn.clk, 
>clk_mgr->clks, offsetof(struct dc_clocks, prev_p_state_change_support)) != 
0) {
dc->optimized_required = true;
}
-
-   dc->optimized_required |= dc->wm_optimized_required;
}
 
return type;
@@ -2952,9 +2952,6 @@ static void copy_stream_update_to_stream(struct dc *dc,
if (update->vrr_active_fixed)
stream->vrr_active_fixed = *update->vrr_active_fixed;
 
-   if (update->crtc_timing_adjust)
-   stream->adjust = *update->crtc_timing_adjust;
-
if (update->dpms_off)
stream->dpms_off = *update->dpms_off;
 
@@ -4401,8 +4398,7 @@ static bool full_update_required(struct dc *dc,
stream_update->mst_bw_update ||
stream_update->func_shaper ||
stream_update->lut3d_func ||
-   stream_update->pending_test_pattern ||
-   stream_update->crtc_timing_adjust))
+   stream_update->pending_test_pattern))
return true;
 
if (stream) {
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 2c85f8ee682f..c87ec3e0a8cf 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -1026,7 +1026,6 @@ struct dc {
 
/* Require to optimize clocks and bandwidth for added/removed planes */
bool optimized_required;
-   bool wm_optimized_required;
bool idle_optimizations_allowed;
bool enable_c20_dtm_b0;
 
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h 
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index 4ac48c346a33..27118e672754 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -130,7 +130,6 @@ union stream_update_flags {
uint32_t wb_update:1;
uint32_t dsc_changed : 1;
uint32_t mst_bw : 1;
-   uint32_t crtc_timing_adjust : 1;
uint32_t fams_changed : 1;
} bits;
 
@@ -342,7 +341,6 @@ struct dc_stream_update {
struct dc_3dlut *lut3d_func;
 
struct test_pattern *pending_test_pattern;
-   struct dc_crtc_timing_adjust *crtc_timing_adjust;
 };
 
 bool dc_is_stream_unchanged(
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
index cdb903116eb7..0d9e41315f84 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c
@@ -3068,7 +3068,7 @@ void dcn10_prepare_bandwidth(
context,
false);
 
-   dc->wm_optimized_required = hubbub->funcs->program_watermarks(hubbub,
+   

[PATCH 03/25] drm/amd/display: Revert " drm/amd/display: Use channel_width = 2 for vram table 3.0"

[Wayne Lin]

From: Alvin Lee 

[Description]
Revert commit 8c5660987ee1 ("drm/amd/display: Use channel_width = 2 for vram 
table 3.0")
Because the issue is being fixed from VBIOS side.

Reviewed-by: Samson Tam 
Acked-by: Wayne Lin 
Signed-off-by: Alvin Lee 
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 875a064bb9a5..fcd65a2057ad 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -2386,13 +2386,7 @@ static enum bp_result get_vram_info_v30(
return BP_RESULT_BADBIOSTABLE;
 
info->num_chans = info_v30->channel_num;
-   /* As suggested by VBIOS we should always use
-* dram_channel_width_bytes = 2 when using VRAM
-* table version 3.0. This is because the channel_width
-* param in the VRAM info table is changed in 7000 series and
-* no longer represents the memory channel width.
-*/
-   info->dram_channel_width_bytes = 2;
+   info->dram_channel_width_bytes = (1 << info_v30->channel_width) / 8;
 
return result;
 }
-- 
2.37.3

[PATCH 02/25] drm/amd/display: remove HPO PG in driver side

[Wayne Lin]

From: Muhammad Ahmed 

[why & how]
Add config to make HPO PG handled in dmubfw ips entry/exit

Reviewed-by: Charlene Liu 
Acked-by: Wayne Lin 
Signed-off-by: Muhammad Ahmed 
---
 drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c 
b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
index 4eb744f1bc9f..4e1db842b98c 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
@@ -718,6 +718,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_dpp_power_gate = true,
.disable_hubp_power_gate = true,
.disable_optc_power_gate = true, /*should the same as above two*/
+   .disable_hpo_power_gate = true, /*dmubfw force domain25 on*/
.disable_clock_gate = false,
.disable_dsc_power_gate = true,
.vsr_support = true,
-- 
2.37.3

[PATCH 01/25] drm/amd/display: do not send commands to DMUB if DMUB is inactive from S3

[Wayne Lin]

From: Samson Tam 

[Why]
On resume from S3, may get apply_idle_optimizations call while DMUB
is inactive which will just time out.

[How]
Set and track power state in dmub_srv and check power state before
sending commands to DMUB.  Add interface in both dmub_srv and
dc_dmub_srv

Reviewed-by: Nicholas Kazlauskas 
Acked-by: Wayne Lin 
Signed-off-by: Samson Tam 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +++
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 14 +
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h  |  2 ++
 drivers/gpu/drm/amd/display/dmub/dmub_srv.h   | 21 +++
 .../gpu/drm/amd/display/dmub/src/dmub_srv.c   | 15 +
 5 files changed, 55 insertions(+)

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 9cce2e7b9208..84efa9e7c951 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2685,6 +2685,7 @@ static int dm_suspend(void *handle)
hpd_rx_irq_work_suspend(dm);
 
dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D3);
+   dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, 
DC_ACPI_CM_POWER_STATE_D3);
 
return 0;
 }
@@ -2880,6 +2881,7 @@ static int dm_resume(void *handle)
if (r)
DRM_ERROR("DMUB interface failed to initialize: 
status=%d\n", r);
 
+   dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, 
DC_ACPI_CM_POWER_STATE_D0);
dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0);
 
dc_resume(dm->dc);
@@ -2930,6 +2932,7 @@ static int dm_resume(void *handle)
}
 
/* power on hardware */
+   dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, 
DC_ACPI_CM_POWER_STATE_D0);
dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0);
 
/* program HPD filter */
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 53400cc05b5b..1a4d615ccdec 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -1268,3 +1268,17 @@ void dc_dmub_srv_exit_low_power_state(const struct dc 
*dc)
ASSERT(0);
 }
 
+void dc_dmub_srv_set_power_state(struct dc_dmub_srv *dc_dmub_srv, enum 
dc_acpi_cm_power_state powerState)
+{
+   struct dmub_srv *dmub;
+
+   if (!dc_dmub_srv)
+   return;
+
+   dmub = dc_dmub_srv->dmub;
+
+   if (powerState == DC_ACPI_CM_POWER_STATE_D0)
+   dmub_srv_set_power_state(dmub, DMUB_POWER_STATE_D0);
+   else
+   dmub_srv_set_power_state(dmub, DMUB_POWER_STATE_D3);
+}
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h 
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
index d4a60f53faab..c25ce7546f71 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h
@@ -102,4 +102,6 @@ void dc_dmub_srv_subvp_save_surf_addr(const struct 
dc_dmub_srv *dc_dmub_srv, con
 bool dc_dmub_srv_is_hw_pwr_up(struct dc_dmub_srv *dc_dmub_srv, bool wait);
 void dc_dmub_srv_notify_idle(const struct dc *dc, bool allow_idle);
 void dc_dmub_srv_exit_low_power_state(const struct dc *dc);
+
+void dc_dmub_srv_set_power_state(struct dc_dmub_srv *dc_dmub_srv, enum 
dc_acpi_cm_power_state powerState);
 #endif /* _DMUB_DC_SRV_H_ */
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h 
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index df63aa8f01e9..d1a4ed6f5916 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -150,6 +150,13 @@ enum dmub_memory_access_type {
DMUB_MEMORY_ACCESS_DMA
 };
 
+/* enum dmub_power_state type - to track DC power state in dmub_srv */
+enum dmub_srv_power_state_type {
+   DMUB_POWER_STATE_UNDEFINED = 0,
+   DMUB_POWER_STATE_D0 = 1,
+   DMUB_POWER_STATE_D3 = 8
+};
+
 /**
  * struct dmub_region - dmub hw memory region
  * @base: base address for region, must be 256 byte aligned
@@ -485,6 +492,8 @@ struct dmub_srv {
/* Feature capabilities reported by fw */
struct dmub_feature_caps feature_caps;
struct dmub_visual_confirm_color visual_confirm_color;
+
+   enum dmub_srv_power_state_type power_state;
 };
 
 /**
@@ -889,6 +898,18 @@ enum dmub_status dmub_srv_clear_inbox0_ack(struct dmub_srv 
*dmub);
  */
 void dmub_srv_subvp_save_surf_addr(struct dmub_srv *dmub, const struct 
dc_plane_address *addr, uint8_t subvp_index);
 
+/**
+ * dmub_srv_set_power_state() - Track DC power state in dmub_srv
+ * @dmub: The dmub service
+ * @power_state: DC power state setting
+ *
+ * Store DC power state in dmub_srv.  If dmub_srv is in D3, then don't send 
messages to DMUB
+ *
+ * Return:
+ *   void
+ */
+void dmub_srv_set_power_state(struct dmub_srv *dmub, enum 
dmub_srv_power_state_type dmub_srv_power_state);
+
 #if defined(__cplusplus)
 }
 #endif
diff --git 

[PATCH 00/25] DC Patches for Dec 18, 2023

[Wayne Lin]

This DC patchset brings improvements in multiple areas. In summary, we 
highlight:

- change static screen wait frame_count for ips
- Fix hang/underflow when transitioning to ODM4:1
- Only clear symclk otg flag for HDMI
- Fix lightup regression with DP2 single display configs
- Refactor phantom resource allocation
- Refactor dc_state interface
- Wake DMCUB before executing GPINT commands
- Wake DMCUB before sending a command
- Refactor DMCUB enter/exit idle interface
- enable dcn35 idle power optimization
- fix usb-c connector_type
- add debug option for ExtendedVBlank DLG adjust
- Set test_pattern_changed update flag on pipe enable
- dereference variable before checking for zero
- get dprefclk ss info from integration info table
- skip error logging when DMUB is inactive from S3
- make flip_timestamp_in_us a 64-bit variable
- Add case for dcn35 to support usb4 dmub hpd event
- Add function for dumping clk registers
- Unify optimize_required flags and VRR adjustments
- Revert using channel_width as 2 for vram table 3.0
- remove HPO PG in driver side
- do not send commands to DMUB if DMUB is inactive from S3

Cc: Daniel Wheeler 
---

Allen Pan (2):
  drm/amd/display: fix usb-c connector_type
  drm/amd/display: change static screen wait frame_count for ips

Alvin Lee (2):
  drm/amd/display: Revert " drm/amd/display: Use channel_width = 2 for
vram table 3.0"
  drm/amd/display: Only clear symclk otg flag for HDMI

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.197.0

Aric Cyr (2):
  drm/amd/display: Unify optimize_required flags and VRR adjustments
  drm/amd/display: 3.2.265

Charlene Liu (1):
  drm/amd/display: get dprefclk ss info from integration info table

Dillon Varone (2):
  drm/amd/display: Refactor dc_state interface
  drm/amd/display: Refactor phantom resource allocation

George Shen (1):
  drm/amd/display: Set test_pattern_changed update flag on pipe enable

Ilya Bakoulin (1):
  drm/amd/display: Fix hang/underflow when transitioning to ODM4:1

Johnson Chen (1):
  drm/amd/display: Add function for dumping clk registers

Josip Pavic (2):
  drm/amd/display: make flip_timestamp_in_us a 64-bit variable
  drm/amd/display: dereference variable before checking for zero

Michael Strauss (1):
  drm/amd/display: Fix lightup regression with DP2 single display
configs

Muhammad Ahmed (2):
  drm/amd/display: remove HPO PG in driver side
  drm/amd/display: add debug option for ExtendedVBlank DLG adjust

Nicholas Kazlauskas (3):
  drm/amd/display: Refactor DMCUB enter/exit idle interface
  drm/amd/display: Wake DMCUB before sending a command
  drm/amd/display: Wake DMCUB before executing GPINT commands

Roman Li (1):
  drm/amd/display: enable dcn35 idle power optimization

Samson Tam (2):
  drm/amd/display: do not send commands to DMUB if DMUB is inactive from
S3
  drm/amd/display: skip error logging when DMUB is inactive from S3

Wayne Lin (1):
  drm/amd/display: Add case for dcn35 to support usb4 dmub hpd event

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  59 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  29 +-
 drivers/gpu/drm/amd/display/dc/Makefile   |   2 +-
 .../drm/amd/display/dc/bios/bios_parser2.c|  27 +-
 .../drm/amd/display/dc/bios/command_table2.c  |  12 +-
 .../gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c  |   3 +-
 .../display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c  |   2 +-
 .../dc/clk_mgr/dcn314/dcn314_clk_mgr.c|   2 +-
 .../dc/clk_mgr/dcn315/dcn315_clk_mgr.c|   2 +-
 .../dc/clk_mgr/dcn316/dcn316_clk_mgr.c|   2 +-
 .../display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c  |   9 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c  | 300 ++
 .../drm/amd/display/dc/core/dc_hw_sequencer.c |  19 +-
 .../gpu/drm/amd/display/dc/core/dc_resource.c | 418 +
 .../gpu/drm/amd/display/dc/core/dc_state.c| 861 ++
 .../gpu/drm/amd/display/dc/core/dc_stream.c   |  46 +-
 .../gpu/drm/amd/display/dc/core/dc_surface.c  |   6 +-
 drivers/gpu/drm/amd/display/dc/dc.h   |  33 +-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c  | 244 -
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h  |  59 +-
 drivers/gpu/drm/amd/display/dc/dc_helper.c|   6 +-
 drivers/gpu/drm/amd/display/dc/dc_hw_types.h  |   2 +-
 drivers/gpu/drm/amd/display/dc/dc_plane.h |  38 +
 .../gpu/drm/amd/display/dc/dc_plane_priv.h|  34 +
 drivers/gpu/drm/amd/display/dc/dc_state.h |  78 ++
 .../gpu/drm/amd/display/dc/dc_state_priv.h| 102 +++
 drivers/gpu/drm/amd/display/dc/dc_stream.h|  76 +-
 .../gpu/drm/amd/display/dc/dc_stream_priv.h   |  37 +
 drivers/gpu/drm/amd/display/dc/dc_types.h |   5 +
 .../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c |  14 +-
 .../drm/amd/display/dc/dce/dmub_hw_lock_mgr.c |   2 +-
 .../gpu/drm/amd/display/dc/dce/dmub_outbox.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c |  33 +-
 .../gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c |   2 +-
 .../display/dc/dcn31/dcn31_dio_link_encoder.c |   4 +-
 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Kim, Jonathan]

[Public]

Again, MES only knows to flush if there was something enqueued in the first 
place.
SET_SHADER dictates what's on the process list.
SET_SHADER can be the last call prior to process termination with nothing 
enqueued, hence no MES auto flush occurs.

MES doesn't block anything on the flush flag request.
The driver guarantees that flush is only done on process termination after 
device dequeue, whether there were queues or not.
MES has no idea what an invalid context is.
It just has a value stored in its linked list that's associated with a driver 
allocated BO that no longer exists after process termination.

If you're still not sure about this solution, then this should be discussed 
offline with the MES team.
We're not going to gain ground discussing this here.  The solution has already 
been merged.
Feel free to propose a better solution if you're not satisfied with this one.

Jon

From: Liu, Shaoyun 
Sent: Tuesday, December 12, 2023 11:08 PM
To: Kim, Jonathan ; Huang, JinHuiEric 
; amd-gfx@lists.freedesktop.org
Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process management


[Public]

You try to add one new interface to inform mes about the context flush after 
driver side finish process termination , from my understanding, mes already 
know the process context need to be purged after all the related queues been 
removed even without this notification. What do you expect mes to do about this 
context flush flag ? Mes should block this process context for next set_sched 
command? Mes can achieve  this by ignore the set_sched command with trap 
disable parameter on an invalid process context .

Shaoyun.liu

Get Outlook for iOS

From: Kim, Jonathan mailto:jonathan@amd.com>>
Sent: Tuesday, December 12, 2023 8:19:09 PM
To: Liu, Shaoyun mailto:shaoyun@amd.com>>; Huang, 
JinHuiEric mailto:jinhuieric.hu...@amd.com>>; 
amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Wong, Alice mailto:shiwei.w...@amd.com>>; Kuehling, 
Felix mailto:felix.kuehl...@amd.com>>; Kasiviswanathan, 
Harish mailto:harish.kasiviswanat...@amd.com>>
Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Public]

> -Original Message-
> From: Liu, Shaoyun mailto:shaoyun@amd.com>>
> Sent: Tuesday, December 12, 2023 7:08 PM
> To: Kim, Jonathan mailto:jonathan@amd.com>>; Huang, 
> JinHuiEric
> mailto:jinhuieric.hu...@amd.com>>; 
> amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice mailto:shiwei.w...@amd.com>>; Kuehling, 
> Felix
> mailto:felix.kuehl...@amd.com>>; Kasiviswanathan, 
> Harish
> mailto:harish.kasiviswanat...@amd.com>>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> I see,  so the  problem is after process context , set_shader been  called 
> with
> disable parameter,  do you know the  reason why  MES re-added the
> process context into the  list ?

Because MES has no idea what disable means.

All it knows is that without the flush flag, set_shader should update the 
necessary per-VMID (process) registers as requested by the driver, which 
requires persistent per-process HW settings so that potential future waves can 
inherit those settings i.e. ADD_QUEUE.skip_process_ctx_clear is set (why 
ADD_QUEUE auto clears the process context otherwise is another long story, 
basically an unsolvable MES cache bug problem).

Common use case example:
add_queue -> set_shader call either transiently stalls the SPI per-VMID or 
transiently dequeues the HWS per-VMID depending on the request settings -> 
fulfils the per-VMID register write updates -> resumes process queues so that 
potential waves on those queues inherit new debug settings.

You can't do this kind of operation at the queue level alone.

The problem that this patch solves (along with the MES FW upgrade) is an 
unfortunate quirk of having to operate between process (debug requests) and 
queue space (non-debug requests).
Old HWS used to operate at the per-process level via MAP_PROCESS so it was a 
lot easier to balance debug versus non-debug requests back then (but it was 
also lot less efficient performance wise).

Jon

>
> Shaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan mailto:jonathan@amd.com>>
> Sent: Tuesday, December 12, 2023 6:07 PM
> To: Liu, Shaoyun mailto:shaoyun@amd.com>>; Huang, 
> JinHuiEric
> mailto:jinhuieric.hu...@amd.com>>; 
> amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice mailto:shiwei.w...@amd.com>>; Kuehling, 
> Felix
> mailto:felix.kuehl...@amd.com>>; Kasiviswanathan, 
> Harish
> mailto:harish.kasiviswanat...@amd.com>>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, 

Re: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Liu, Shaoyun]

[Public]

You try to add one new interface to inform mes about the context flush after 
driver side finish process termination , from my understanding, mes already 
know the process context need to be purged after all the related queues been 
removed even without this notification. What do you expect mes to do about this 
context flush flag ? Mes should block this process context for next set_sched 
command? Mes can achieve  this by ignore the set_sched command with trap 
disable parameter on an invalid process context .

Shaoyun.liu

Get Outlook for iOS

From: Kim, Jonathan 
Sent: Tuesday, December 12, 2023 8:19:09 PM
To: Liu, Shaoyun ; Huang, JinHuiEric 
; amd-gfx@lists.freedesktop.org 

Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 7:08 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> I see,  so the  problem is after process context , set_shader been  called 
> with
> disable parameter,  do you know the  reason why  MES re-added the
> process context into the  list ?

Because MES has no idea what disable means.

All it knows is that without the flush flag, set_shader should update the 
necessary per-VMID (process) registers as requested by the driver, which 
requires persistent per-process HW settings so that potential future waves can 
inherit those settings i.e. ADD_QUEUE.skip_process_ctx_clear is set (why 
ADD_QUEUE auto clears the process context otherwise is another long story, 
basically an unsolvable MES cache bug problem).

Common use case example:
add_queue -> set_shader call either transiently stalls the SPI per-VMID or 
transiently dequeues the HWS per-VMID depending on the request settings -> 
fulfils the per-VMID register write updates -> resumes process queues so that 
potential waves on those queues inherit new debug settings.

You can't do this kind of operation at the queue level alone.

The problem that this patch solves (along with the MES FW upgrade) is an 
unfortunate quirk of having to operate between process (debug requests) and 
queue space (non-debug requests).
Old HWS used to operate at the per-process level via MAP_PROCESS so it was a 
lot easier to balance debug versus non-debug requests back then (but it was 
also lot less efficient performance wise).

Jon

>
> Shaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 6:07 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 5:44 PM
> > To: Kim, Jonathan ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > Do you mean SET_SHADER_DEBUGER can  be called before ADD_QUEUE ?
> I
> > think  even in that  situation MES should still be able to handle it
> > as long as MES already  remove the process context from its list , MES
> > will treat the process context as a new item. I still don't understand why
> MES haven't
> > purged the  process context from the list after process termination .   Will
> > debug queue itself  also use the add/remove queue interface  and  is
> > it possible the debug queue itself from the  old process  still not be
> > removed ?
>
> SET_SHADER_DEBUGGER can be called independently from ADD_QUEUE.
> The process list is updated on either on SET_SHADER_DEBUGGER or
> ADD_QUEUE.
> e.g. runtime_enable (set_shader) -> add_queue -> remove_queue (list
> purged) -> runtime_disable (set_shader process re-added) -> process
> termination (stale list) or debug attach (set_shader) -> add_queue ->
> remove_queue (list purged) -> debug detach (set_shader process re-added) -
> >process termination (stale list)
>
> MES has no idea what process termination means.  The new flag is a proxy
> for this.
> There are reasons for process settings to take place prior to queue add
> (debugger, gfx11 cwsr workaround, core dump etc need this).
>
> I'm not sure what kernel/debug queues have to do with this.
> By that argument, the list should be purged.
>
> Jon
>
> >
> > Shaoyun.liu
> >
> > -Original Message-
> > From: Kim, Jonathan 
> > Sent: Tuesday, December 12, 2023 4:48 PM
> > To: Liu, Shaoyun ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, 

[PATCH 1/2] drm/amd/pm: support return vpe clock table

[Peyton Lee]

pm supports return vpe clock table and soc clock table

Signed-off-by: Peyton Lee 
---
 drivers/gpu/drm/amd/display/dc/dm_pp_smu.h|  2 ++
 drivers/gpu/drm/amd/pm/amdgpu_dpm.c   | 10 ++
 drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |  1 +
 .../drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c  | 20 +++
 4 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h 
b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
index 4440d08743aa..bd7ba0a25198 100644
--- a/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
+++ b/drivers/gpu/drm/amd/display/dc/dm_pp_smu.h
@@ -247,6 +247,7 @@ struct pp_smu_funcs_nv {
 #define PP_SMU_NUM_MEMCLK_DPM_LEVELS  4
 #define PP_SMU_NUM_DCLK_DPM_LEVELS8
 #define PP_SMU_NUM_VCLK_DPM_LEVELS8
+#define PP_SMU_NUM_VPECLK_DPM_LEVELS  8
 
 struct dpm_clock {
   uint32_t  Freq;// In MHz
@@ -262,6 +263,7 @@ struct dpm_clocks {
struct dpm_clock MemClocks[PP_SMU_NUM_MEMCLK_DPM_LEVELS];
struct dpm_clock VClocks[PP_SMU_NUM_VCLK_DPM_LEVELS];
struct dpm_clock DClocks[PP_SMU_NUM_DCLK_DPM_LEVELS];
+   struct dpm_clock VPEClocks[PP_SMU_NUM_VPECLK_DPM_LEVELS];
 };
 
 
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
index 97b40c5fa1ff..6627ee07d52d 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
@@ -616,6 +616,16 @@ void amdgpu_dpm_enable_jpeg(struct amdgpu_device *adev, 
bool enable)
  enable ? "enable" : "disable", ret);
 }
 
+void amdgpu_dpm_enable_vpe(struct amdgpu_device *adev, bool enable)
+{
+   int ret = 0;
+
+   ret = amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_VPE, 
!enable);
+   if (ret)
+   DRM_ERROR("Dpm %s vpe failed, ret = %d.\n",
+ enable ? "enable" : "disable", ret);
+}
+
 int amdgpu_pm_load_smu_firmware(struct amdgpu_device *adev, uint32_t 
*smu_version)
 {
const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h 
b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
index d76b0a60db44..3047ffe7f244 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
@@ -445,6 +445,7 @@ void amdgpu_dpm_compute_clocks(struct amdgpu_device *adev);
 void amdgpu_dpm_enable_uvd(struct amdgpu_device *adev, bool enable);
 void amdgpu_dpm_enable_vce(struct amdgpu_device *adev, bool enable);
 void amdgpu_dpm_enable_jpeg(struct amdgpu_device *adev, bool enable);
+void amdgpu_dpm_enable_vpe(struct amdgpu_device *adev, bool enable);
 int amdgpu_pm_load_smu_firmware(struct amdgpu_device *adev, uint32_t 
*smu_version);
 int amdgpu_dpm_handle_passthrough_sbr(struct amdgpu_device *adev, bool enable);
 int amdgpu_dpm_send_hbm_bad_pages_num(struct amdgpu_device *adev, uint32_t 
size);
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c
index 94ccdbfd7090..47fdbae4adfc 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c
@@ -1085,6 +1085,25 @@ static int smu_v14_0_0_set_umsch_mm_enable(struct 
smu_context *smu,
   0, NULL);
 }
 
+static int smu_14_0_0_get_dpm_table(struct smu_context *smu, struct dpm_clocks 
*clock_table)
+{
+   DpmClocks_t *clk_table = smu->smu_table.clocks_table;
+   uint8_t idx;
+
+   /* Only the Clock information of SOC and VPE is copied to provide VPE 
DPM settings for use. */
+   for (idx = 0; idx < NUM_SOCCLK_DPM_LEVELS; idx++) {
+   clock_table->SocClocks[idx].Freq = (idx < 
clk_table->NumSocClkLevelsEnabled) ? clk_table->SocClocks[idx]:0;
+   clock_table->SocClocks[idx].Vol = 0;
+   }
+
+   for (idx = 0; idx < NUM_VPE_DPM_LEVELS; idx++) {
+   clock_table->VPEClocks[idx].Freq = (idx < 
clk_table->VpeClkLevelsEnabled) ? clk_table->VPEClocks[idx]:0;
+   clock_table->VPEClocks[idx].Vol = 0;
+   }
+
+   return 0;
+}
+
 static const struct pptable_funcs smu_v14_0_0_ppt_funcs = {
.check_fw_status = smu_v14_0_check_fw_status,
.check_fw_version = smu_v14_0_check_fw_version,
@@ -1115,6 +1134,7 @@ static const struct pptable_funcs smu_v14_0_0_ppt_funcs = 
{
.set_gfx_power_up_by_imu = smu_v14_0_set_gfx_power_up_by_imu,
.dpm_set_vpe_enable = smu_v14_0_0_set_vpe_enable,
.dpm_set_umsch_mm_enable = smu_v14_0_0_set_umsch_mm_enable,
+   .get_dpm_clock_table = smu_14_0_0_get_dpm_table,
 };
 
 static void smu_v14_0_0_set_smu_mailbox_registers(struct smu_context *smu)
-- 
2.34.1

[PATCH 2/2] drm/amdgpu/vpe: enable vpe dpm

[Peyton Lee]

enable vpe dpm

Signed-off-by: Peyton Lee 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c | 250 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.h |  12 ++
 drivers/gpu/drm/amd/amdgpu/vpe_v6_1.c   |  15 ++
 3 files changed, 277 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c
index e81579708e96..2020ddb4182a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c
@@ -26,6 +26,7 @@
 #include "amdgpu.h"
 #include "amdgpu_ucode.h"
 #include "amdgpu_vpe.h"
+#include "amdgpu_smu.h"
 #include "soc15_common.h"
 #include "vpe_v6_1.h"
 
@@ -33,8 +34,186 @@
 /* VPE CSA resides in the 4th page of CSA */
 #define AMDGPU_CSA_VPE_OFFSET  (4096 * 3)
 
+/* 1 second timeout */
+#define VPE_IDLE_TIMEOUT   msecs_to_jiffies(1000)
+
+#define VPE_MAX_DPM_LEVEL  4
+#define FIXED1_8_BITS_PER_FRACTIONAL_PART  8
+#define GET_PRATIO_INTEGER_PART(x) ((x) >> 
FIXED1_8_BITS_PER_FRACTIONAL_PART)
+
 static void vpe_set_ring_funcs(struct amdgpu_device *adev);
 
+static inline uint16_t div16_u16_rem(uint16_t dividend, uint16_t divisor, 
uint16_t *remainder)
+{
+   *remainder = dividend % divisor;
+   return dividend / divisor;
+}
+
+static inline uint16_t complete_integer_division_u16(
+   uint16_t dividend,
+   uint16_t divisor,
+   uint16_t *remainder)
+{
+   return div16_u16_rem(dividend, divisor, (uint16_t *)remainder);
+}
+
+static uint16_t vpe_u1_8_from_fraction(uint16_t numerator, uint16_t 
denominator)
+{
+   bool arg1_negative = numerator < 0;
+   bool arg2_negative = denominator < 0;
+
+   uint16_t arg1_value = (uint16_t)(arg1_negative ? -numerator : 
numerator);
+   uint16_t arg2_value = (uint16_t)(arg2_negative ? -denominator : 
denominator);
+
+   uint16_t remainder;
+
+   /* determine integer part */
+   uint16_t res_value = complete_integer_division_u16(
+   arg1_value, arg2_value, );
+
+   if (res_value > 127 /* CHAR_MAX */)
+   return 0;
+
+   /* determine fractional part */
+   {
+   unsigned int i = FIXED1_8_BITS_PER_FRACTIONAL_PART;
+
+   do {
+   remainder <<= 1;
+
+   res_value <<= 1;
+
+   if (remainder >= arg2_value) {
+   res_value |= 1;
+   remainder -= arg2_value;
+   }
+   } while (--i != 0);
+   }
+
+   /* round up LSB */
+   {
+   uint16_t summand = (remainder << 1) >= arg2_value;
+
+   if ((res_value + summand) > 32767 /* SHRT_MAX */)
+   return 0;
+
+   res_value += summand;
+   }
+
+   if (arg1_negative ^ arg2_negative)
+   res_value = -res_value;
+
+   return res_value;
+}
+
+static uint16_t vpe_internal_get_pratio(uint16_t from_frequency, uint16_t 
to_frequency)
+{
+   uint16_t pratio = vpe_u1_8_from_fraction(from_frequency, to_frequency);
+
+   if (GET_PRATIO_INTEGER_PART(pratio) > 1)
+   pratio = 0;
+
+   return pratio;
+}
+
+/*
+ * VPE has 4 DPM levels from level 0 (lowerest) to 3 (highest),
+ * VPE FW will dynamically decide which level should be used according to 
current loading.
+ *
+ * Get VPE and SOC clocks from PM, and select the appropriate four clock 
values,
+ * calculate the ratios of adjusting from one clock to another.
+ * The VPE FW can then request the appropriate frequency from the PMFW.
+ */
+int amdgpu_vpe_configure_dpm(struct amdgpu_vpe *vpe)
+{
+   struct amdgpu_device *adev = vpe->ring.adev;
+   uint32_t dpm_ctl;
+
+   if (adev->pm.dpm_enabled) {
+   struct dpm_clocks clock_table = { 0 };
+   struct dpm_clock *VPEClks;
+   struct dpm_clock *SOCClks;
+   uint32_t idx;
+   uint32_t pratio_vmax_vnorm = 0, pratio_vnorm_vmid = 0, 
pratio_vmid_vmin = 0;
+   uint16_t pratio_vmin_freq = 0, pratio_vmid_freq = 0, 
pratio_vnorm_freq = 0, pratio_vmax_freq = 0;
+
+   dpm_ctl = RREG32(vpe_get_reg_offset(vpe, 0, 
vpe->regs.dpm_enable));
+   dpm_ctl |= 1; /* DPM enablement */
+   WREG32(vpe_get_reg_offset(vpe, 0, vpe->regs.dpm_enable), 
dpm_ctl);
+
+   /* Get VPECLK and SOCCLK */
+   if (amdgpu_dpm_get_dpm_clock_table(adev, _table)) {
+   dev_dbg(adev->dev, "%s: get clock failed!\n", __func__);
+   goto disable_dpm;
+   }
+
+   SOCClks = clock_table.SocClocks;
+   VPEClks = clock_table.VPEClocks;
+
+   /* vpe dpm only cares 4 levels. */
+   for (idx = 0; idx < VPE_MAX_DPM_LEVEL; idx++) {
+   uint32_t soc_dpm_level;
+   uint32_t min_freq;
+
+   if (idx == 0)
+ 

[PATCH v2] drm/amdgpu: fix ftrace event amdgpu_bo_move always move

[Wang, Beyond]

[AMD Official Use Only - General]


Issue: during evict or validate happened on amdgpu_bo, the 'from' and
'to' is always same in ftrace event of amdgpu_bo_move

where calling the 'trace_amdgpu_bo_move', the comment says move_notify
is called before move happens, but actually it is called after move
happens, here the new_mem is same as bo->resource

Fix: move trace_amdgpu_bo_move from move_notify to amdgpu_bo_move

Signed-off-by: Wang, Beyond wang.bey...@amd.com
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  5 +++--
3 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 7416799750c1..1870775d582c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1282,19 +1282,15 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void 
*buffer,
  * amdgpu_bo_move_notify - notification about a memory move
  * @bo: pointer to a buffer object
  * @evict: if this move is evicting the buffer from the graphics address space
- * @new_mem: new information of the bufer object
  *
  * Marks the corresponding _bo buffer object as invalid, also performs
  * bookkeeping.
  * TTM driver callback which is called when ttm moves a buffer.
  */
-void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
-  bool evict,
-  struct ttm_resource *new_mem)
+void amdgpu_bo_move_notify(struct ttm_buffer_object *bo, bool evict)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct amdgpu_bo *abo;
-   struct ttm_resource *old_mem = bo->resource;

if (!amdgpu_bo_is_amdgpu_bo(bo))
return;
@@ -1313,13 +1309,6 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
-
-   /* update statistics */
-   if (!new_mem)
-   return;
-
-   /* move_notify is called before move happens */
-   trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type);
}

void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 876acde6b10a..dee2c577427e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -360,9 +360,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void 
*metadata,
int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void *buffer,
   size_t buffer_size, uint32_t *metadata_size,
   uint64_t *flags);
-void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
-  bool evict,
-  struct ttm_resource *new_mem);
+void amdgpu_bo_move_notify(struct ttm_buffer_object *bo, bool evict);
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);
vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 41ed6a3e5a06..f0fffbf2bdd5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -576,10 +576,11 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
return r;
}

+   trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type);
out:
/* update statistics */
atomic64_add(bo->base.size, >num_bytes_moved);
-   amdgpu_bo_move_notify(bo, evict, new_mem);
+   amdgpu_bo_move_notify(bo, evict);
return 0;
}

@@ -1852,7 +1853,7 @@ static int amdgpu_ttm_access_memory(struct 
ttm_buffer_object *bo,
static void
amdgpu_bo_delete_mem_notify(struct ttm_buffer_object *bo)
{
-   amdgpu_bo_move_notify(bo, false, NULL);
+   amdgpu_bo_move_notify(bo, false);
}

static struct ttm_device_funcs amdgpu_bo_driver = {
--
2.34.1

Re: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"

[Mario Limonciello]

On 12/12/2023 18:08, Oliver Schmidt wrote:

Hi Wayne,

On 12.12.23 17:06, Mario Limonciello wrote:

I looked through your bugs related to this and I didn't see a reference to the
specific docking station model.
The logs mentioned "Thinkpad dock" but no model.
Could you share more about it so that AMD can try to reproduce it?


Yes, it is a ThinkPad Ultra Dockingstation, part number 40AJ0135EU, see also
https://support.lenovo.com/us/en/solutions/pd500173-thinkpad-ultra-docking-station-overview-and-service-parts



By chance do you have access to any other dock or monitor combinations 
that you can conclude it only happens on this dock or only a certain 
monitor, or only a certain monitor connected to this dock?



Best regards,
Oliver

On 12.12.23 17:06, Mario Limonciello wrote:

On 12/12/2023 04:10, Lin, Wayne wrote:

[Public]

Hi Mario,

Thanks for the help.
My feeling is like this problem probably relates to specific dock. Need time
to take
further look.


Oliver,

I looked through your bugs related to this and I didn't see a reference to the
specific docking station model.
The logs mentioned "Thinkpad dock" but no model.

Could you share more about it so that AMD can try to reproduce it?



Since reverting solves the issue now, feel free to add:
Acked-by: Wayne Lin 


Sure, thanks.



Thanks,
Wayne


-Original Message-
From: Limonciello, Mario 
Sent: Tuesday, December 12, 2023 12:15 AM
To: amd-gfx@lists.freedesktop.org; Wentland, Harry

Cc: Linux Regressions ; sta...@vger.kernel.org;
Wheeler, Daniel ; Lin, Wayne
; Oliver Schmidt 
Subject: Re: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"

Ping on this one.

On 12/5/2023 13:54, Mario Limonciello wrote:

This reverts commit ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a.

Reports are that this causes problems with external monitors after
wake up from suspend, which is something it was directly supposed to help.

Cc: Linux Regressions 
Cc: sta...@vger.kernel.org
Cc: Daniel Wheeler 
Cc: Wayne Lin 
Reported-by: Oliver Schmidt 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218211
Link:
https://forum.manjaro.org/t/problems-with-external-monitor-wake-up-aft
er-suspend/151840
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3023
Signed-off-by: Mario Limonciello 
---
    .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 93 +++--

--

    1 file changed, 13 insertions(+), 80 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 c146dc9cba92..1ba58e4ecab3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2363,62 +2363,14 @@ static int dm_late_init(void *handle)
  return detect_mst_link_for_all_connectors(adev_to_drm(adev));
    }

-static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr
*mgr) -{
-   int ret;
-   u8 guid[16];
-   u64 tmp64;
-
-   mutex_lock(>lock);
-   if (!mgr->mst_primary)
-   goto out_fail;
-
-   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
-   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
-    DP_MST_EN |
-    DP_UP_REQ_EN |
-    DP_UPSTREAM_IS_SRC);
-   if (ret < 0) {
-   drm_dbg_kms(mgr->dev, "mst write failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   /* Some hubs forget their guids after they resume */
-   ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
-   if (ret != 16) {
-   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   if (memchr_inv(guid, 0, 16) == NULL) {
-   tmp64 = get_jiffies_64();
-   memcpy([0], , sizeof(u64));
-   memcpy([8], , sizeof(u64));
-
-   ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
-
-   if (ret != 16) {
-   drm_dbg_kms(mgr->dev, "check mstb guid failed -

undocked during suspend?\n");

-   goto out_fail;
-   }
-   }
-
-   memcpy(mgr->mst_primary->guid, guid, 16);
-
-out_fail:
-   mutex_unlock(>lock);
-}
-
    static void s3_handle_mst(struct drm_device *dev, bool suspend)
    {
  struct amdgpu_dm_connector *aconnector;
  struct drm_connector *connector;
  struct drm_connector_list_iter iter;
  struct drm_dp_mst_topology_mgr *mgr;
+   int ret;
+   bool need_hotplug = false;

  drm_connector_list_iter_begin(dev, );
  drm_for_each_connector_iter(connector, ) { @@ -2444,15
+2396,18 @@ static void s3_handle_mst(struct drm_device *dev, bool

suspend)

  if (!dp_is_lttpr_present(aconnector->dc_link))
  try_to_configure_aux_timeout(aconnector-
dc_link->ddc,
LINK_AUX_DEFAULT_TIMEOUT_PERIOD);

-   /* TODO: move 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Kim, Jonathan]

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 7:08 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> I see,  so the  problem is after process context , set_shader been  called 
> with
> disable parameter,  do you know the  reason why  MES re-added the
> process context into the  list ?

Because MES has no idea what disable means.

All it knows is that without the flush flag, set_shader should update the 
necessary per-VMID (process) registers as requested by the driver, which 
requires persistent per-process HW settings so that potential future waves can 
inherit those settings i.e. ADD_QUEUE.skip_process_ctx_clear is set (why 
ADD_QUEUE auto clears the process context otherwise is another long story, 
basically an unsolvable MES cache bug problem).

Common use case example:
add_queue -> set_shader call either transiently stalls the SPI per-VMID or 
transiently dequeues the HWS per-VMID depending on the request settings -> 
fulfils the per-VMID register write updates -> resumes process queues so that 
potential waves on those queues inherit new debug settings.

You can't do this kind of operation at the queue level alone.

The problem that this patch solves (along with the MES FW upgrade) is an 
unfortunate quirk of having to operate between process (debug requests) and 
queue space (non-debug requests).
Old HWS used to operate at the per-process level via MAP_PROCESS so it was a 
lot easier to balance debug versus non-debug requests back then (but it was 
also lot less efficient performance wise).

Jon

>
> Shaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 6:07 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 5:44 PM
> > To: Kim, Jonathan ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > Do you mean SET_SHADER_DEBUGER can  be called before ADD_QUEUE ?
> I
> > think  even in that  situation MES should still be able to handle it
> > as long as MES already  remove the process context from its list , MES
> > will treat the process context as a new item. I still don't understand why
> MES haven't
> > purged the  process context from the list after process termination .   Will
> > debug queue itself  also use the add/remove queue interface  and  is
> > it possible the debug queue itself from the  old process  still not be
> > removed ?
>
> SET_SHADER_DEBUGGER can be called independently from ADD_QUEUE.
> The process list is updated on either on SET_SHADER_DEBUGGER or
> ADD_QUEUE.
> e.g. runtime_enable (set_shader) -> add_queue -> remove_queue (list
> purged) -> runtime_disable (set_shader process re-added) -> process
> termination (stale list) or debug attach (set_shader) -> add_queue ->
> remove_queue (list purged) -> debug detach (set_shader process re-added) -
> >process termination (stale list)
>
> MES has no idea what process termination means.  The new flag is a proxy
> for this.
> There are reasons for process settings to take place prior to queue add
> (debugger, gfx11 cwsr workaround, core dump etc need this).
>
> I'm not sure what kernel/debug queues have to do with this.
> By that argument, the list should be purged.
>
> Jon
>
> >
> > Shaoyun.liu
> >
> > -Original Message-
> > From: Kim, Jonathan 
> > Sent: Tuesday, December 12, 2023 4:48 PM
> > To: Liu, Shaoyun ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > > -Original Message-
> > > From: Liu, Shaoyun 
> > > Sent: Tuesday, December 12, 2023 4:45 PM
> > > To: Kim, Jonathan ; Huang, JinHuiEric
> > > ; amd-gfx@lists.freedesktop.org
> > > Cc: Wong, Alice ; Kuehling, Felix
> > > ; Kasiviswanathan, Harish
> > > 
> > > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > > management
> > >
> > > [Public]
> > >
> > > Shouldn't the driver side  remove all the remaining  queues for the
> > > process during  process termination ?  If all the  queues been
> > > removed for the process ,  MES should purge the  process context
> > > automatically , otherwise it's bug inside MES .
> >
> > That's only if there were queues added to begin with.
> >
> > Jon
> >
> > >
> > > Regard
> 

RE: [PATCH v2 03/23] drm/amdkfd: enable pc sampling query

[Yat Sin, David]

[AMD Official Use Only - General]

> -Original Message-
> From: Zhu, James 
> Sent: Thursday, December 7, 2023 5:54 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Greathouse, Joseph
> ; Yat Sin, David ;
> Zhu, James 
> Subject: [PATCH v2 03/23] drm/amdkfd: enable pc sampling query
>
> From: David Yat Sin 
>
> Enable pc sampling to query system capability.
>
> Co-developed-by: James Zhu 
> Signed-off-by: James Zhu 
> Signed-off-by: David Yat Sin 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c | 54
> +++-
>  1 file changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c
> index a7e78ff42d07..49fecbc7013e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c
> @@ -25,10 +25,62 @@
>  #include "amdgpu_amdkfd.h"
>  #include "kfd_pc_sampling.h"
>
> +struct supported_pc_sample_info {
> + uint32_t ip_version;
> + const struct kfd_pc_sample_info *sample_info; };
> +
> +const struct kfd_pc_sample_info sample_info_hosttrap_9_0_0 = {
> + 0, 1, ~0ULL, 0, KFD_IOCTL_PCS_METHOD_HOSTTRAP,
> +KFD_IOCTL_PCS_TYPE_TIME_US };
> +
> +struct supported_pc_sample_info supported_formats[] = {
> + { IP_VERSION(9, 4, 1), _info_hosttrap_9_0_0 },
> + { IP_VERSION(9, 4, 2), _info_hosttrap_9_0_0 }, };
> +
>  static int kfd_pc_sample_query_cap(struct kfd_process_device *pdd,
>   struct kfd_ioctl_pc_sample_args
> __user *user_args)  {
> - return -EINVAL;
> + uint64_t sample_offset;
> + int num_method = 0;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(supported_formats); i++)
> + if (KFD_GC_VERSION(pdd->dev) ==
> supported_formats[i].ip_version)
> + num_method++;
> +
> + if (!num_method) {
> + pr_debug("PC Sampling not supported on GC_HWIP:0x%x.",
> + pdd->dev->adev->ip_versions[GC_HWIP][0]);
> + return -EOPNOTSUPP;
> + }
> +
> + if (!user_args->sample_info_ptr) {
Should be:
if (!user_args->sample_info_ptr || !user_args->num_sample_info) {

> + user_args->num_sample_info = num_method;
> + return 0;
> + }
> +
> + if (user_args->num_sample_info < num_method) {
> + user_args->num_sample_info = num_method;
> + pr_debug("Sample info buffer is not large enough, "
> +  "ASIC requires space for %d kfd_pc_sample_info
> entries.", num_method);
> + return -ENOSPC;
> + }
> +
> + sample_offset = user_args->sample_info_ptr;

If there is another active PC Sampling session that is active, I thought we 
were planning to have code to
return a reduced list with only the methods that are compatible with the 
current active session. Did we
decide to drop this behavior?

Regards,
David

> + for (i = 0; i < ARRAY_SIZE(supported_formats); i++) {
> + if (KFD_GC_VERSION(pdd->dev) ==
> supported_formats[i].ip_version) {
> + int ret = copy_to_user((void __user *) sample_offset,
> + supported_formats[i].sample_info,
> sizeof(struct kfd_pc_sample_info));
> + if (ret) {
> + pr_debug("Failed to copy PC sampling info to
> user.");
> + return -EFAULT;
> + }
> + sample_offset += sizeof(struct kfd_pc_sample_info);
> + }
> + }
> +
> + return 0;
>  }
>
>  static int kfd_pc_sample_start(struct kfd_process_device *pdd)
> --
> 2.25.1

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Liu, Shaoyun]

[Public]

I see,  so the  problem is after process context , set_shader been  called with 
disable parameter,  do you know the  reason why  MES re-added the  process 
context into the  list ?

Shaoyun.liu

-Original Message-
From: Kim, Jonathan 
Sent: Tuesday, December 12, 2023 6:07 PM
To: Liu, Shaoyun ; Huang, JinHuiEric 
; amd-gfx@lists.freedesktop.org
Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 5:44 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> Do you mean SET_SHADER_DEBUGER can  be called before ADD_QUEUE ?  I
> think  even in that  situation MES should still be able to handle it
> as long as MES already  remove the process context from its list , MES
> will treat the process context as a new item. I still don't understand why 
> MES haven't
> purged the  process context from the list after process termination .   Will
> debug queue itself  also use the add/remove queue interface  and  is
> it possible the debug queue itself from the  old process  still not be
> removed ?

SET_SHADER_DEBUGGER can be called independently from ADD_QUEUE.
The process list is updated on either on SET_SHADER_DEBUGGER or ADD_QUEUE.
e.g. runtime_enable (set_shader) -> add_queue -> remove_queue (list purged) -> 
runtime_disable (set_shader process re-added) -> process termination (stale 
list) or debug attach (set_shader) -> add_queue -> remove_queue (list purged) 
-> debug detach (set_shader process re-added) ->process termination (stale list)

MES has no idea what process termination means.  The new flag is a proxy for 
this.
There are reasons for process settings to take place prior to queue add 
(debugger, gfx11 cwsr workaround, core dump etc need this).

I'm not sure what kernel/debug queues have to do with this.
By that argument, the list should be purged.

Jon

>
> Shaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 4:48 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 4:45 PM
> > To: Kim, Jonathan ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > Shouldn't the driver side  remove all the remaining  queues for the
> > process during  process termination ?  If all the  queues been
> > removed for the process ,  MES should purge the  process context
> > automatically , otherwise it's bug inside MES .
>
> That's only if there were queues added to begin with.
>
> Jon
>
> >
> > Regard
> > Sshaoyun.liu
> >
> > -Original Message-
> > From: Kim, Jonathan 
> > Sent: Tuesday, December 12, 2023 4:33 PM
> > To: Liu, Shaoyun ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > > -Original Message-
> > > From: Liu, Shaoyun 
> > > Sent: Tuesday, December 12, 2023 4:00 PM
> > > To: Huang, JinHuiEric ; Kim, Jonathan
> > > ; amd-gfx@lists.freedesktop.org
> > > Cc: Wong, Alice ; Kuehling, Felix
> > > ; Kasiviswanathan, Harish
> > > 
> > > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger
> > > process management
> > >
> > > [AMD Official Use Only - General]
> > >
> > > Does this requires the  new MES FW for this process_ctx_flush
> > > requirement ?  Can driver side add logic to guaranty when  call
> > > SET_SHADER_DEBUGGER, the process address  is always valid ?
> >
> > Call to flush on old fw is a NOP so it's harmless in that case.
> > Full solution will still require a new MES version as this is a
> > workaround on corner cases and not a new feature i.e. we can't stop
> > ROCm from running on old fw.
> > The process address is always valid from the driver side.  It's the
> > MES side of things that gets stale as mentioned in the description
> > (passed value to MES is reused with new BO but MES doesn't refresh).
> > i.e. MES auto refreshes it's process list assuming process queues
> > were all drained but driver can't guarantee that SET_SHADER_DEBUGGER
> (which
> > adds to MES's process list) will get called after queues get added
> > (in fact it's a requirements that it can be called at any time).
> > We can 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Kim, Jonathan]

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 5:44 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> Do you mean SET_SHADER_DEBUGER can  be called before ADD_QUEUE ?  I
> think  even in that  situation MES should still be able to handle it as long 
> as
> MES already  remove the process context from its list , MES will treat the
> process context as a new item. I still don't understand why MES haven't
> purged the  process context from the list after process termination .   Will
> debug queue itself  also use the add/remove queue interface  and  is it
> possible the debug queue itself from the  old process  still not be
> removed ?

SET_SHADER_DEBUGGER can be called independently from ADD_QUEUE.
The process list is updated on either on SET_SHADER_DEBUGGER or ADD_QUEUE.
e.g. runtime_enable (set_shader) -> add_queue -> remove_queue (list purged) -> 
runtime_disable (set_shader process re-added) -> process termination (stale 
list)
or debug attach (set_shader) -> add_queue -> remove_queue (list purged) -> 
debug detach (set_shader process re-added) ->process termination (stale list)

MES has no idea what process termination means.  The new flag is a proxy for 
this.
There are reasons for process settings to take place prior to queue add 
(debugger, gfx11 cwsr workaround, core dump etc need this).

I'm not sure what kernel/debug queues have to do with this.
By that argument, the list should be purged.

Jon

>
> Shaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 4:48 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 4:45 PM
> > To: Kim, Jonathan ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > Shouldn't the driver side  remove all the remaining  queues for the
> > process during  process termination ?  If all the  queues been removed
> > for the process ,  MES should purge the  process context automatically
> > , otherwise it's bug inside MES .
>
> That's only if there were queues added to begin with.
>
> Jon
>
> >
> > Regard
> > Sshaoyun.liu
> >
> > -Original Message-
> > From: Kim, Jonathan 
> > Sent: Tuesday, December 12, 2023 4:33 PM
> > To: Liu, Shaoyun ; Huang, JinHuiEric
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [Public]
> >
> > > -Original Message-
> > > From: Liu, Shaoyun 
> > > Sent: Tuesday, December 12, 2023 4:00 PM
> > > To: Huang, JinHuiEric ; Kim, Jonathan
> > > ; amd-gfx@lists.freedesktop.org
> > > Cc: Wong, Alice ; Kuehling, Felix
> > > ; Kasiviswanathan, Harish
> > > 
> > > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > > management
> > >
> > > [AMD Official Use Only - General]
> > >
> > > Does this requires the  new MES FW for this process_ctx_flush
> > > requirement ?  Can driver side add logic to guaranty when  call
> > > SET_SHADER_DEBUGGER, the process address  is always valid ?
> >
> > Call to flush on old fw is a NOP so it's harmless in that case.
> > Full solution will still require a new MES version as this is a
> > workaround on corner cases and not a new feature i.e. we can't stop
> > ROCm from running on old fw.
> > The process address is always valid from the driver side.  It's the
> > MES side of things that gets stale as mentioned in the description
> > (passed value to MES is reused with new BO but MES doesn't refresh).
> > i.e. MES auto refreshes it's process list assuming process queues were
> > all drained but driver can't guarantee that SET_SHADER_DEBUGGER
> (which
> > adds to MES's process list) will get called after queues get added (in
> > fact it's a requirements that it can be called at any time).
> > We can attempt to defer calls these calls in the KFD, considering all cases.
> > But that would be a large shift in debugger/runtime_enable/KFD code,
> > which is already complicated and could get buggy plus it would not be
> > intuitive at all as to why we're doing this.
> > I think a single flag set to flush MES on process termination is a
> > simpler compromise that shows the limitation in a more obvious way.
> >
> > Thanks,
> >
> > Jon
> >
> >
> > >
> > > Regards
> > > Shaoyun.liu
> > >
> > >
> > > 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Liu, Shaoyun]

[Public]

Do you mean SET_SHADER_DEBUGER can  be called before ADD_QUEUE ?  I think  even 
in that  situation MES should still be able to handle it as long as MES already 
 remove the process context from its list , MES will treat the  process context 
as a new item. I still don't understand why MES haven't  purged the  process 
context from the list after process termination .   Will debug queue itself  
also use the add/remove queue interface  and  is it possible the debug queue 
itself from the  old process  still not be  removed ?

Shaoyun.liu

-Original Message-
From: Kim, Jonathan 
Sent: Tuesday, December 12, 2023 4:48 PM
To: Liu, Shaoyun ; Huang, JinHuiEric 
; amd-gfx@lists.freedesktop.org
Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 4:45 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> Shouldn't the driver side  remove all the remaining  queues for the
> process during  process termination ?  If all the  queues been removed
> for the process ,  MES should purge the  process context automatically
> , otherwise it's bug inside MES .

That's only if there were queues added to begin with.

Jon

>
> Regard
> Sshaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 4:33 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 4:00 PM
> > To: Huang, JinHuiEric ; Kim, Jonathan
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [AMD Official Use Only - General]
> >
> > Does this requires the  new MES FW for this process_ctx_flush
> > requirement ?  Can driver side add logic to guaranty when  call
> > SET_SHADER_DEBUGGER, the process address  is always valid ?
>
> Call to flush on old fw is a NOP so it's harmless in that case.
> Full solution will still require a new MES version as this is a
> workaround on corner cases and not a new feature i.e. we can't stop
> ROCm from running on old fw.
> The process address is always valid from the driver side.  It's the
> MES side of things that gets stale as mentioned in the description
> (passed value to MES is reused with new BO but MES doesn't refresh).
> i.e. MES auto refreshes it's process list assuming process queues were
> all drained but driver can't guarantee that SET_SHADER_DEBUGGER (which
> adds to MES's process list) will get called after queues get added (in
> fact it's a requirements that it can be called at any time).
> We can attempt to defer calls these calls in the KFD, considering all cases.
> But that would be a large shift in debugger/runtime_enable/KFD code,
> which is already complicated and could get buggy plus it would not be
> intuitive at all as to why we're doing this.
> I think a single flag set to flush MES on process termination is a
> simpler compromise that shows the limitation in a more obvious way.
>
> Thanks,
>
> Jon
>
>
> >
> > Regards
> > Shaoyun.liu
> >
> >
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Eric Huang
> > Sent: Tuesday, December 12, 2023 12:49 PM
> > To: Kim, Jonathan ; amd-
> > g...@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> >
> > On 2023-12-11 16:16, Jonathan Kim wrote:
> > > MES provides the driver a call to explicitly flush stale process
> > > memory within the MES to avoid a race condition that results in a
> > > fatal memory violation.
> > >
> > > When SET_SHADER_DEBUGGER is called, the driver passes a memory
> > address
> > > that represents a process context address MES uses to keep track
> > > of future per-process calls.
> > >
> > > Normally, MES will purge its process context list when the last
> > > queue has been removed.  The driver, however, can call
> > > SET_SHADER_DEBUGGER regardless of whether a queue has been added
> or not.
> > >
> > > If SET_SHADER_DEBUGGER has been called with no queues as the last
> > > call prior to process termination, the passed process context
> > > address will still reside within MES.
> > >
> > > On a new process call to SET_SHADER_DEBUGGER, the driver may end
> up
> > > passing an identical process context address value (based on
> > > per-process 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Kim, Jonathan]

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 4:45 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> Shouldn't the driver side  remove all the remaining  queues for the process
> during  process termination ?  If all the  queues been removed for the
> process ,  MES should purge the  process context automatically , otherwise
> it's bug inside MES .

That's only if there were queues added to begin with.

Jon

>
> Regard
> Sshaoyun.liu
>
> -Original Message-
> From: Kim, Jonathan 
> Sent: Tuesday, December 12, 2023 4:33 PM
> To: Liu, Shaoyun ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [Public]
>
> > -Original Message-
> > From: Liu, Shaoyun 
> > Sent: Tuesday, December 12, 2023 4:00 PM
> > To: Huang, JinHuiEric ; Kim, Jonathan
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> > [AMD Official Use Only - General]
> >
> > Does this requires the  new MES FW for this process_ctx_flush
> > requirement ?  Can driver side add logic to guaranty when  call
> > SET_SHADER_DEBUGGER, the process address  is always valid ?
>
> Call to flush on old fw is a NOP so it's harmless in that case.
> Full solution will still require a new MES version as this is a workaround on
> corner cases and not a new feature i.e. we can't stop ROCm from running on
> old fw.
> The process address is always valid from the driver side.  It's the MES side 
> of
> things that gets stale as mentioned in the description (passed value to MES
> is reused with new BO but MES doesn't refresh).
> i.e. MES auto refreshes it's process list assuming process queues were all
> drained but driver can't guarantee that SET_SHADER_DEBUGGER (which
> adds to MES's process list) will get called after queues get added (in fact 
> it's
> a requirements that it can be called at any time).
> We can attempt to defer calls these calls in the KFD, considering all cases.
> But that would be a large shift in debugger/runtime_enable/KFD code,
> which is already complicated and could get buggy plus it would not be
> intuitive at all as to why we're doing this.
> I think a single flag set to flush MES on process termination is a simpler
> compromise that shows the limitation in a more obvious way.
>
> Thanks,
>
> Jon
>
>
> >
> > Regards
> > Shaoyun.liu
> >
> >
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Eric Huang
> > Sent: Tuesday, December 12, 2023 12:49 PM
> > To: Kim, Jonathan ; amd-
> > g...@lists.freedesktop.org
> > Cc: Wong, Alice ; Kuehling, Felix
> > ; Kasiviswanathan, Harish
> > 
> > Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process
> > management
> >
> >
> > On 2023-12-11 16:16, Jonathan Kim wrote:
> > > MES provides the driver a call to explicitly flush stale process
> > > memory within the MES to avoid a race condition that results in a
> > > fatal memory violation.
> > >
> > > When SET_SHADER_DEBUGGER is called, the driver passes a memory
> > address
> > > that represents a process context address MES uses to keep track of
> > > future per-process calls.
> > >
> > > Normally, MES will purge its process context list when the last
> > > queue has been removed.  The driver, however, can call
> > > SET_SHADER_DEBUGGER regardless of whether a queue has been added
> or not.
> > >
> > > If SET_SHADER_DEBUGGER has been called with no queues as the last
> > > call prior to process termination, the passed process context
> > > address will still reside within MES.
> > >
> > > On a new process call to SET_SHADER_DEBUGGER, the driver may end
> up
> > > passing an identical process context address value (based on
> > > per-process gpu memory address) to MES but is now pointing to a new
> > > allocated buffer object during KFD process creation.  Since the MES
> > > is unaware of this, access of the passed address points to the stale
> > > object within MES and triggers a fatal memory violation.
> > >
> > > The solution is for KFD to explicitly flush the process context
> > > address from MES on process termination.
> > >
> > > Note that the flush call and the MES debugger calls use the same MES
> > > interface but are separated as KFD calls to avoid conflicting with
> > > each other.
> > >
> > > Signed-off-by: Jonathan Kim 
> > > Tested-by: Alice Wong 
> > Reviewed-by: Eric Huang 
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   | 31
> > +++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h   | 10 +++---
> > >   

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Liu, Shaoyun]

[Public]

Shouldn't the driver side  remove all the remaining  queues for the process 
during  process termination ?  If all the  queues been removed for the process 
,  MES should purge the  process context automatically , otherwise it's bug 
inside MES .

Regard
Sshaoyun.liu

-Original Message-
From: Kim, Jonathan 
Sent: Tuesday, December 12, 2023 4:33 PM
To: Liu, Shaoyun ; Huang, JinHuiEric 
; amd-gfx@lists.freedesktop.org
Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 4:00 PM
> To: Huang, JinHuiEric ; Kim, Jonathan
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [AMD Official Use Only - General]
>
> Does this requires the  new MES FW for this process_ctx_flush
> requirement ?  Can driver side add logic to guaranty when  call
> SET_SHADER_DEBUGGER, the process address  is always valid ?

Call to flush on old fw is a NOP so it's harmless in that case.
Full solution will still require a new MES version as this is a workaround on 
corner cases and not a new feature i.e. we can't stop ROCm from running on old 
fw.
The process address is always valid from the driver side.  It's the MES side of 
things that gets stale as mentioned in the description (passed value to MES is 
reused with new BO but MES doesn't refresh).
i.e. MES auto refreshes it's process list assuming process queues were all 
drained but driver can't guarantee that SET_SHADER_DEBUGGER (which adds to 
MES's process list) will get called after queues get added (in fact it's a 
requirements that it can be called at any time).
We can attempt to defer calls these calls in the KFD, considering all cases.
But that would be a large shift in debugger/runtime_enable/KFD code, which is 
already complicated and could get buggy plus it would not be intuitive at all 
as to why we're doing this.
I think a single flag set to flush MES on process termination is a simpler 
compromise that shows the limitation in a more obvious way.

Thanks,

Jon


>
> Regards
> Shaoyun.liu
>
>
> -Original Message-
> From: amd-gfx  On Behalf Of
> Eric Huang
> Sent: Tuesday, December 12, 2023 12:49 PM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
>
> On 2023-12-11 16:16, Jonathan Kim wrote:
> > MES provides the driver a call to explicitly flush stale process
> > memory within the MES to avoid a race condition that results in a
> > fatal memory violation.
> >
> > When SET_SHADER_DEBUGGER is called, the driver passes a memory
> address
> > that represents a process context address MES uses to keep track of
> > future per-process calls.
> >
> > Normally, MES will purge its process context list when the last
> > queue has been removed.  The driver, however, can call
> > SET_SHADER_DEBUGGER regardless of whether a queue has been added or not.
> >
> > If SET_SHADER_DEBUGGER has been called with no queues as the last
> > call prior to process termination, the passed process context
> > address will still reside within MES.
> >
> > On a new process call to SET_SHADER_DEBUGGER, the driver may end up
> > passing an identical process context address value (based on
> > per-process gpu memory address) to MES but is now pointing to a new
> > allocated buffer object during KFD process creation.  Since the MES
> > is unaware of this, access of the passed address points to the stale
> > object within MES and triggers a fatal memory violation.
> >
> > The solution is for KFD to explicitly flush the process context
> > address from MES on process termination.
> >
> > Note that the flush call and the MES debugger calls use the same MES
> > interface but are separated as KFD calls to avoid conflicting with
> > each other.
> >
> > Signed-off-by: Jonathan Kim 
> > Tested-by: Alice Wong 
> Reviewed-by: Eric Huang 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   | 31
> +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h   | 10 +++---
> >   .../amd/amdkfd/kfd_process_queue_manager.c|  1 +
> >   drivers/gpu/drm/amd/include/mes_v11_api_def.h |  3 +-
> >   4 files changed, 40 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > index e544b823abf6..e98de23250dc 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > @@ -916,6 +916,11 @@ int amdgpu_mes_set_shader_debugger(struct
> amdgpu_device *adev,
> >   op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
> >   op_input.set_shader_debugger.process_context_addr =
> 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Kim, Jonathan]

[Public]

> -Original Message-
> From: Liu, Shaoyun 
> Sent: Tuesday, December 12, 2023 4:00 PM
> To: Huang, JinHuiEric ; Kim, Jonathan
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
> [AMD Official Use Only - General]
>
> Does this requires the  new MES FW for this process_ctx_flush
> requirement ?  Can driver side add logic to guaranty when  call
> SET_SHADER_DEBUGGER, the process address  is always valid ?

Call to flush on old fw is a NOP so it's harmless in that case.
Full solution will still require a new MES version as this is a workaround on 
corner cases and not a new feature i.e. we can't stop ROCm from running on old 
fw.
The process address is always valid from the driver side.  It's the MES side of 
things that gets stale as mentioned in the description (passed value to MES is 
reused with new BO but MES doesn't refresh).
i.e. MES auto refreshes it's process list assuming process queues were all 
drained but driver can't guarantee that SET_SHADER_DEBUGGER (which adds to 
MES's process list) will get called after queues get added (in fact it's a 
requirements that it can be called at any time).
We can attempt to defer calls these calls in the KFD, considering all cases.
But that would be a large shift in debugger/runtime_enable/KFD code, which is 
already complicated and could get buggy plus it would not be intuitive at all 
as to why we're doing this.
I think a single flag set to flush MES on process termination is a simpler 
compromise that shows the limitation in a more obvious way.

Thanks,

Jon


>
> Regards
> Shaoyun.liu
>
>
> -Original Message-
> From: amd-gfx  On Behalf Of Eric
> Huang
> Sent: Tuesday, December 12, 2023 12:49 PM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
> 
> Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process
> management
>
>
> On 2023-12-11 16:16, Jonathan Kim wrote:
> > MES provides the driver a call to explicitly flush stale process
> > memory within the MES to avoid a race condition that results in a
> > fatal memory violation.
> >
> > When SET_SHADER_DEBUGGER is called, the driver passes a memory
> address
> > that represents a process context address MES uses to keep track of
> > future per-process calls.
> >
> > Normally, MES will purge its process context list when the last queue
> > has been removed.  The driver, however, can call SET_SHADER_DEBUGGER
> > regardless of whether a queue has been added or not.
> >
> > If SET_SHADER_DEBUGGER has been called with no queues as the last call
> > prior to process termination, the passed process context address will
> > still reside within MES.
> >
> > On a new process call to SET_SHADER_DEBUGGER, the driver may end up
> > passing an identical process context address value (based on
> > per-process gpu memory address) to MES but is now pointing to a new
> > allocated buffer object during KFD process creation.  Since the MES is
> > unaware of this, access of the passed address points to the stale
> > object within MES and triggers a fatal memory violation.
> >
> > The solution is for KFD to explicitly flush the process context
> > address from MES on process termination.
> >
> > Note that the flush call and the MES debugger calls use the same MES
> > interface but are separated as KFD calls to avoid conflicting with
> > each other.
> >
> > Signed-off-by: Jonathan Kim 
> > Tested-by: Alice Wong 
> Reviewed-by: Eric Huang 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   | 31
> +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h   | 10 +++---
> >   .../amd/amdkfd/kfd_process_queue_manager.c|  1 +
> >   drivers/gpu/drm/amd/include/mes_v11_api_def.h |  3 +-
> >   4 files changed, 40 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > index e544b823abf6..e98de23250dc 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> > @@ -916,6 +916,11 @@ int amdgpu_mes_set_shader_debugger(struct
> amdgpu_device *adev,
> >   op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
> >   op_input.set_shader_debugger.process_context_addr =
> process_context_addr;
> >   op_input.set_shader_debugger.flags.u32all = flags;
> > +
> > + /* use amdgpu mes_flush_shader_debugger instead */
> > + if (op_input.set_shader_debugger.flags.process_ctx_flush)
> > + return -EINVAL;
> > +
> >   op_input.set_shader_debugger.spi_gdbg_per_vmid_cntl =
> spi_gdbg_per_vmid_cntl;
> >   memcpy(op_input.set_shader_debugger.tcp_watch_cntl,
> tcp_watch_cntl,
> >   sizeof(op_input.set_shader_debugger.tcp_watch_cntl));
> > @@ -935,6 +940,32 @@ int amdgpu_mes_set_shader_debugger(struct
> amdgpu_device 

RE: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Liu, Shaoyun]

[AMD Official Use Only - General]

Does this requires the  new MES FW for this process_ctx_flush  requirement ?  
Can driver side add logic to guaranty when  call SET_SHADER_DEBUGGER, the 
process address  is always valid ?

Regards
Shaoyun.liu


-Original Message-
From: amd-gfx  On Behalf Of Eric Huang
Sent: Tuesday, December 12, 2023 12:49 PM
To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
Cc: Wong, Alice ; Kuehling, Felix 
; Kasiviswanathan, Harish 

Subject: Re: [PATCH] drm/amdkfd: fix mes set shader debugger process management


On 2023-12-11 16:16, Jonathan Kim wrote:
> MES provides the driver a call to explicitly flush stale process
> memory within the MES to avoid a race condition that results in a
> fatal memory violation.
>
> When SET_SHADER_DEBUGGER is called, the driver passes a memory address
> that represents a process context address MES uses to keep track of
> future per-process calls.
>
> Normally, MES will purge its process context list when the last queue
> has been removed.  The driver, however, can call SET_SHADER_DEBUGGER
> regardless of whether a queue has been added or not.
>
> If SET_SHADER_DEBUGGER has been called with no queues as the last call
> prior to process termination, the passed process context address will
> still reside within MES.
>
> On a new process call to SET_SHADER_DEBUGGER, the driver may end up
> passing an identical process context address value (based on
> per-process gpu memory address) to MES but is now pointing to a new
> allocated buffer object during KFD process creation.  Since the MES is
> unaware of this, access of the passed address points to the stale
> object within MES and triggers a fatal memory violation.
>
> The solution is for KFD to explicitly flush the process context
> address from MES on process termination.
>
> Note that the flush call and the MES debugger calls use the same MES
> interface but are separated as KFD calls to avoid conflicting with
> each other.
>
> Signed-off-by: Jonathan Kim 
> Tested-by: Alice Wong 
Reviewed-by: Eric Huang 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   | 31 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h   | 10 +++---
>   .../amd/amdkfd/kfd_process_queue_manager.c|  1 +
>   drivers/gpu/drm/amd/include/mes_v11_api_def.h |  3 +-
>   4 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> index e544b823abf6..e98de23250dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
> @@ -916,6 +916,11 @@ int amdgpu_mes_set_shader_debugger(struct amdgpu_device 
> *adev,
>   op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
>   op_input.set_shader_debugger.process_context_addr = 
> process_context_addr;
>   op_input.set_shader_debugger.flags.u32all = flags;
> +
> + /* use amdgpu mes_flush_shader_debugger instead */
> + if (op_input.set_shader_debugger.flags.process_ctx_flush)
> + return -EINVAL;
> +
>   op_input.set_shader_debugger.spi_gdbg_per_vmid_cntl = 
> spi_gdbg_per_vmid_cntl;
>   memcpy(op_input.set_shader_debugger.tcp_watch_cntl, tcp_watch_cntl,
>   sizeof(op_input.set_shader_debugger.tcp_watch_cntl));
> @@ -935,6 +940,32 @@ int amdgpu_mes_set_shader_debugger(struct amdgpu_device 
> *adev,
>   return r;
>   }
>
> +int amdgpu_mes_flush_shader_debugger(struct amdgpu_device *adev,
> +  uint64_t process_context_addr) {
> + struct mes_misc_op_input op_input = {0};
> + int r;
> +
> + if (!adev->mes.funcs->misc_op) {
> + DRM_ERROR("mes flush shader debugger is not supported!\n");
> + return -EINVAL;
> + }
> +
> + op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
> + op_input.set_shader_debugger.process_context_addr = 
> process_context_addr;
> + op_input.set_shader_debugger.flags.process_ctx_flush = true;
> +
> + amdgpu_mes_lock(>mes);
> +
> + r = adev->mes.funcs->misc_op(>mes, _input);
> + if (r)
> + DRM_ERROR("failed to set_shader_debugger\n");
> +
> + amdgpu_mes_unlock(>mes);
> +
> + return r;
> +}
> +
>   static void
>   amdgpu_mes_ring_to_queue_props(struct amdgpu_device *adev,
>  struct amdgpu_ring *ring,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
> index 894b9b133000..7d4f93fea937 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
> @@ -296,9 +296,10 @@ struct mes_misc_op_input {
>   uint64_t process_context_addr;
>   union {
>   struct {
> - uint64_t single_memop : 1;
> - uint64_t single_alu_op : 1;
> - uint64_t reserved: 30;
> + 

Re: [PATCH] drm/amdkfd: fix mes set shader debugger process management

[Eric Huang]

On 2023-12-11 16:16, Jonathan Kim wrote:

MES provides the driver a call to explicitly flush stale process memory
within the MES to avoid a race condition that results in a fatal
memory violation.

When SET_SHADER_DEBUGGER is called, the driver passes a memory address
that represents a process context address MES uses to keep track of
future per-process calls.

Normally, MES will purge its process context list when the last queue
has been removed.  The driver, however, can call SET_SHADER_DEBUGGER
regardless of whether a queue has been added or not.

If SET_SHADER_DEBUGGER has been called with no queues as the last call
prior to process termination, the passed process context address will
still reside within MES.

On a new process call to SET_SHADER_DEBUGGER, the driver may end up
passing an identical process context address value (based on per-process
gpu memory address) to MES but is now pointing to a new allocated buffer
object during KFD process creation.  Since the MES is unaware of this,
access of the passed address points to the stale object within MES and
triggers a fatal memory violation.

The solution is for KFD to explicitly flush the process context address
from MES on process termination.

Note that the flush call and the MES debugger calls use the same MES
interface but are separated as KFD calls to avoid conflicting with each
other.

Signed-off-by: Jonathan Kim 
Tested-by: Alice Wong 

Reviewed-by: Eric Huang 

---
  drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   | 31 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h   | 10 +++---
  .../amd/amdkfd/kfd_process_queue_manager.c|  1 +
  drivers/gpu/drm/amd/include/mes_v11_api_def.h |  3 +-
  4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
index e544b823abf6..e98de23250dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
@@ -916,6 +916,11 @@ int amdgpu_mes_set_shader_debugger(struct amdgpu_device 
*adev,
op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
op_input.set_shader_debugger.process_context_addr = 
process_context_addr;
op_input.set_shader_debugger.flags.u32all = flags;
+
+   /* use amdgpu mes_flush_shader_debugger instead */
+   if (op_input.set_shader_debugger.flags.process_ctx_flush)
+   return -EINVAL;
+
op_input.set_shader_debugger.spi_gdbg_per_vmid_cntl = 
spi_gdbg_per_vmid_cntl;
memcpy(op_input.set_shader_debugger.tcp_watch_cntl, tcp_watch_cntl,
sizeof(op_input.set_shader_debugger.tcp_watch_cntl));
@@ -935,6 +940,32 @@ int amdgpu_mes_set_shader_debugger(struct amdgpu_device 
*adev,
return r;
  }
  
+int amdgpu_mes_flush_shader_debugger(struct amdgpu_device *adev,

+uint64_t process_context_addr)
+{
+   struct mes_misc_op_input op_input = {0};
+   int r;
+
+   if (!adev->mes.funcs->misc_op) {
+   DRM_ERROR("mes flush shader debugger is not supported!\n");
+   return -EINVAL;
+   }
+
+   op_input.op = MES_MISC_OP_SET_SHADER_DEBUGGER;
+   op_input.set_shader_debugger.process_context_addr = 
process_context_addr;
+   op_input.set_shader_debugger.flags.process_ctx_flush = true;
+
+   amdgpu_mes_lock(>mes);
+
+   r = adev->mes.funcs->misc_op(>mes, _input);
+   if (r)
+   DRM_ERROR("failed to set_shader_debugger\n");
+
+   amdgpu_mes_unlock(>mes);
+
+   return r;
+}
+
  static void
  amdgpu_mes_ring_to_queue_props(struct amdgpu_device *adev,
   struct amdgpu_ring *ring,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
index 894b9b133000..7d4f93fea937 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h
@@ -296,9 +296,10 @@ struct mes_misc_op_input {
uint64_t process_context_addr;
union {
struct {
-   uint64_t single_memop : 1;
-   uint64_t single_alu_op : 1;
-   uint64_t reserved: 30;
+   uint32_t single_memop : 1;
+   uint32_t single_alu_op : 1;
+   uint32_t reserved: 29;
+   uint32_t process_ctx_flush: 1;
};
uint32_t u32all;
} flags;
@@ -374,7 +375,8 @@ int amdgpu_mes_set_shader_debugger(struct amdgpu_device 
*adev,
const uint32_t *tcp_watch_cntl,
uint32_t flags,
bool trap_en);
-
+int amdgpu_mes_flush_shader_debugger(struct amdgpu_device 

Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V

[Josh Poimboeuf]

On Mon, Dec 11, 2023 at 11:12:42PM -0800, Christoph Hellwig wrote:
> On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> > Actually tracking all possibly-FPU-tainted functions and their call sites is
> > probably possible, but a much larger task.
> 
> I think objtool should be able to do that reasonably easily, it already
> does it for checking section where userspace address access is enabled
> or not, which is very similar.

Yeah, that might be doable.  I can look into it.

-- 
Josh

Re: [PATCH] drm/amd: Fix a probing order problem on SDMA 2.4

[Alex Deucher]

On Tue, Dec 12, 2023 at 12:37 PM Alex Deucher  wrote:
>
> On Tue, Dec 12, 2023 at 12:30 PM Mario Limonciello
>  wrote:
> >
> > commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
> > early_init for SDMA v2.4") made a fateful mistake in
> > `adev->sdma.num_instances` wasn't declared when sdma_v2_4_init_microcode()
> > was run. This caused probing to fail.
> >
> > Move the declaration to right before sdma_v2_4_init_microcode().
> >
> > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3043
> > Fixes: 751e293f2c99 ("drm/amd: Move microcode init from sw_init to 
> > early_init for SDMA v2.4")
> > Signed-off-by: Mario Limonciello 
>
> FWIW, looks like cik_sdma.c and sdma_v3_0.c never switched their
> microcode init to early init.

Nevermind, I had an old branch checked out.

>
> Reviewed-by: Alex Deucher 
>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
> > b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> > index 45377a175250..8d5d86675a7f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> > @@ -813,12 +813,12 @@ static int sdma_v2_4_early_init(void *handle)
> > struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> > int r;
> >
> > +   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
> > +
> > r = sdma_v2_4_init_microcode(adev);
> > if (r)
> > return r;
> >
> > -   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
> > -
> > sdma_v2_4_set_ring_funcs(adev);
> > sdma_v2_4_set_buffer_funcs(adev);
> > sdma_v2_4_set_vm_pte_funcs(adev);
> > --
> > 2.34.1
> >

Re: [PATCH] drm/amd: Fix a probing order problem on SDMA 2.4

[Alex Deucher]

On Tue, Dec 12, 2023 at 12:30 PM Mario Limonciello
 wrote:
>
> commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
> early_init for SDMA v2.4") made a fateful mistake in
> `adev->sdma.num_instances` wasn't declared when sdma_v2_4_init_microcode()
> was run. This caused probing to fail.
>
> Move the declaration to right before sdma_v2_4_init_microcode().
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3043
> Fixes: 751e293f2c99 ("drm/amd: Move microcode init from sw_init to early_init 
> for SDMA v2.4")
> Signed-off-by: Mario Limonciello 

FWIW, looks like cik_sdma.c and sdma_v3_0.c never switched their
microcode init to early init.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
> b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> index 45377a175250..8d5d86675a7f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> @@ -813,12 +813,12 @@ static int sdma_v2_4_early_init(void *handle)
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> int r;
>
> +   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
> +
> r = sdma_v2_4_init_microcode(adev);
> if (r)
> return r;
>
> -   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
> -
> sdma_v2_4_set_ring_funcs(adev);
> sdma_v2_4_set_buffer_funcs(adev);
> sdma_v2_4_set_vm_pte_funcs(adev);
> --
> 2.34.1
>

[PATCH] drm/amd: Fix a probing order problem on SDMA 2.4

[Mario Limonciello]

commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
early_init for SDMA v2.4") made a fateful mistake in
`adev->sdma.num_instances` wasn't declared when sdma_v2_4_init_microcode()
was run. This caused probing to fail.

Move the declaration to right before sdma_v2_4_init_microcode().

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3043
Fixes: 751e293f2c99 ("drm/amd: Move microcode init from sw_init to early_init 
for SDMA v2.4")
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
index 45377a175250..8d5d86675a7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
@@ -813,12 +813,12 @@ static int sdma_v2_4_early_init(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
int r;
 
+   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
+
r = sdma_v2_4_init_microcode(adev);
if (r)
return r;
 
-   adev->sdma.num_instances = SDMA_MAX_INSTANCE;
-
sdma_v2_4_set_ring_funcs(adev);
sdma_v2_4_set_buffer_funcs(adev);
sdma_v2_4_set_vm_pte_funcs(adev);
-- 
2.34.1

Re: [GIT PULL] mmutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window

[Alex Deucher]

On Tue, Dec 12, 2023 at 11:25 AM Mario Limonciello
 wrote:
>
> On 12/12/2023 03:46, Johannes Berg wrote:
> > On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:
> >> Hi Wifi and AMDGPU maintainers,
> >>
> >> Here is a pull-request for the platform-drivers-x86 parts of:
> >>
> >> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
> >>
> >>  From my pov the pdx86 bits are ready and the 
> >> platform-drivers-x86-amd-wbrf-v6.8-1 tag can be merged by you to merge the 
> >> wifi-subsys resp. the amdgpu driver changes on top.
> >>
> >> This only adds kernel internal API, so if in the future the API needs work 
> >> that can be done.
> >
> > OK, thanks! I've pulled this into wireless-next, and applied the two
> > wireless related patches on top.
> >
> > I guess if AMDGPU does the same, it will combine nicely in 6.8.
> >
> > johannes
>
> Yup, I've pulled the whole series into amd-staging-drm-next for now and
> I expect as long as we have no problems with it reported under our
> testing Alex or Christian will do the same include drm/amd portions of
> it in an upcoming drm-next pull request.

I've pushed out an updated -next branch as well:
https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next

Alex

Re: [GIT PULL] mmutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window

[Mario Limonciello]

On 12/12/2023 03:46, Johannes Berg wrote:

On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:

Hi Wifi and AMDGPU maintainers,

Here is a pull-request for the platform-drivers-x86 parts of:

https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/

 From my pov the pdx86 bits are ready and the 
platform-drivers-x86-amd-wbrf-v6.8-1 tag can be merged by you to merge the 
wifi-subsys resp. the amdgpu driver changes on top.

This only adds kernel internal API, so if in the future the API needs work that 
can be done.


OK, thanks! I've pulled this into wireless-next, and applied the two
wireless related patches on top.

I guess if AMDGPU does the same, it will combine nicely in 6.8.

johannes


Yup, I've pulled the whole series into amd-staging-drm-next for now and 
I expect as long as we have no problems with it reported under our 
testing Alex or Christian will do the same include drm/amd portions of 
it in an upcoming drm-next pull request.


Thanks!

Re: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"

[Mario Limonciello]

On 12/12/2023 04:10, Lin, Wayne wrote:

[Public]

Hi Mario,

Thanks for the help.
My feeling is like this problem probably relates to specific dock. Need time to 
take
further look.


Oliver,

I looked through your bugs related to this and I didn't see a reference 
to the specific docking station model.

The logs mentioned "Thinkpad dock" but no model.

Could you share more about it so that AMD can try to reproduce it?



Since reverting solves the issue now, feel free to add:
Acked-by: Wayne Lin 


Sure, thanks.



Thanks,
Wayne


-Original Message-
From: Limonciello, Mario 
Sent: Tuesday, December 12, 2023 12:15 AM
To: amd-gfx@lists.freedesktop.org; Wentland, Harry

Cc: Linux Regressions ; sta...@vger.kernel.org;
Wheeler, Daniel ; Lin, Wayne
; Oliver Schmidt 
Subject: Re: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"

Ping on this one.

On 12/5/2023 13:54, Mario Limonciello wrote:

This reverts commit ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a.

Reports are that this causes problems with external monitors after
wake up from suspend, which is something it was directly supposed to help.

Cc: Linux Regressions 
Cc: sta...@vger.kernel.org
Cc: Daniel Wheeler 
Cc: Wayne Lin 
Reported-by: Oliver Schmidt 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218211
Link:
https://forum.manjaro.org/t/problems-with-external-monitor-wake-up-aft
er-suspend/151840
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3023
Signed-off-by: Mario Limonciello 
---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 93 +++--

--

   1 file changed, 13 insertions(+), 80 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 c146dc9cba92..1ba58e4ecab3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2363,62 +2363,14 @@ static int dm_late_init(void *handle)
 return detect_mst_link_for_all_connectors(adev_to_drm(adev));
   }

-static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr
*mgr) -{
-   int ret;
-   u8 guid[16];
-   u64 tmp64;
-
-   mutex_lock(>lock);
-   if (!mgr->mst_primary)
-   goto out_fail;
-
-   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
-   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
-DP_MST_EN |
-DP_UP_REQ_EN |
-DP_UPSTREAM_IS_SRC);
-   if (ret < 0) {
-   drm_dbg_kms(mgr->dev, "mst write failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   /* Some hubs forget their guids after they resume */
-   ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
-   if (ret != 16) {
-   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during

suspend?\n");

-   goto out_fail;
-   }
-
-   if (memchr_inv(guid, 0, 16) == NULL) {
-   tmp64 = get_jiffies_64();
-   memcpy([0], , sizeof(u64));
-   memcpy([8], , sizeof(u64));
-
-   ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
-
-   if (ret != 16) {
-   drm_dbg_kms(mgr->dev, "check mstb guid failed -

undocked during suspend?\n");

-   goto out_fail;
-   }
-   }
-
-   memcpy(mgr->mst_primary->guid, guid, 16);
-
-out_fail:
-   mutex_unlock(>lock);
-}
-
   static void s3_handle_mst(struct drm_device *dev, bool suspend)
   {
 struct amdgpu_dm_connector *aconnector;
 struct drm_connector *connector;
 struct drm_connector_list_iter iter;
 struct drm_dp_mst_topology_mgr *mgr;
+   int ret;
+   bool need_hotplug = false;

 drm_connector_list_iter_begin(dev, );
 drm_for_each_connector_iter(connector, ) { @@ -2444,15
+2396,18 @@ static void s3_handle_mst(struct drm_device *dev, bool

suspend)

 if (!dp_is_lttpr_present(aconnector->dc_link))
 try_to_configure_aux_timeout(aconnector-
dc_link->ddc,
LINK_AUX_DEFAULT_TIMEOUT_PERIOD);

-   /* TODO: move resume_mst_branch_status() into

drm mst resume again

-* once topology probing work is pulled out from mst

resume into mst

-* resume 2nd step. mst resume 2nd step should be

called after old

-* state getting restored (i.e.

drm_atomic_helper_resume()).

-*/
-   resume_mst_branch_status(mgr);
+   ret = drm_dp_mst_topology_mgr_resume(mgr, true);
+   if (ret < 0) {
+

   dm_helpers_dp_mst_stop_top_mgr(aconnector->dc_link->ctx,

+   aconnector->dc_link);
+   need_hotplug = true;
+   }
 }
 }
 drm_connector_list_iter_end();
+
+   if (need_hotplug)
+   

Re: Radeon regression in 6.6 kernel

[Alex Deucher]

On Mon, Dec 11, 2023 at 7:28 PM Phillip Susi  wrote:
>
> Phillip Susi  writes:
>
> > And it works, but 6.7-rc5 does not, even though it includes that patch.
> > Here's the syslog from the attempt.  I'll start bisecting again.
>
> I checked out the patch that got merged upstream and it also fails.  I
> looked at the two commits, and I see what happened.  Your original patch
> MOVED the call to amdgpu_ttm_set_buffer_funcs_status().  The one that
> got merged into Linus' tree instead DUPLICATES the call.  Oops?
>

Yeah, I messed up the patch somehow when I applied it.  Fix up already
queued up to add the missing chunk.

Alex

[PATCH] drm/amd: include drm/drm_edid.h only where needed

[Jani Nikula]

Including drm_edid.h from amdgpu_mode.h causes the rebuild of literally
hundreds of files when drm_edid.h is modified, while there are only a
handful of files that actually need to include drm_edid.h.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c| 1 +
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
 6 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 32fe05c810c6..3802ccdf6f55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -32,7 +32,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -51,6 +50,7 @@ struct amdgpu_device;
 struct amdgpu_encoder;
 struct amdgpu_router;
 struct amdgpu_hpd;
+struct edid;
 
 #define to_amdgpu_crtc(x) container_of(x, struct amdgpu_crtc, base)
 #define to_amdgpu_connector(x) container_of(x, struct amdgpu_connector, base)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index db6fc0cb18eb..453a4b786cfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index 3ee219aa2891..7672abe6c140 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -28,6 +28,7 @@
 
 #include 
 
+#include 
 #include 
 #include "amdgpu.h"
 #include "amdgpu_connectors.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index bb666cb7522e..587ee632a3b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 7af277f61cca..f22ec27365bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
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 b599efda3b19..6f8128130b62 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
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "dm_services.h"
 #include "amdgpu.h"
-- 
2.39.2

Re: [GIT PULL] mmutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window

[Johannes Berg]

On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:
> Hi Wifi and AMDGPU maintainers,
> 
> Here is a pull-request for the platform-drivers-x86 parts of:
> 
> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
> 
> From my pov the pdx86 bits are ready and the 
> platform-drivers-x86-amd-wbrf-v6.8-1 tag can be merged by you to merge the 
> wifi-subsys resp. the amdgpu driver changes on top.
> 
> This only adds kernel internal API, so if in the future the API needs work 
> that can be done.

OK, thanks! I've pulled this into wireless-next, and applied the two
wireless related patches on top.

I guess if AMDGPU does the same, it will combine nicely in 6.8.

johannes

[PATCH] drm/radeon: include drm/drm_edid.h only where needed

[Jani Nikula]

Including drm_edid.h from radeon_mode.h causes the rebuild of more than
a hundred files when drm_edid.h is modified, while there are only a
handful of files that actually need to include drm_edid.h.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/radeon/atombios_encoders.c | 1 +
 drivers/gpu/drm/radeon/dce3_1_afmt.c   | 1 +
 drivers/gpu/drm/radeon/dce6_afmt.c | 1 +
 drivers/gpu/drm/radeon/evergreen.c | 1 +
 drivers/gpu/drm/radeon/evergreen_hdmi.c| 1 +
 drivers/gpu/drm/radeon/radeon_atombios.c   | 1 +
 drivers/gpu/drm/radeon/radeon_audio.c  | 1 +
 drivers/gpu/drm/radeon/radeon_audio.h  | 4 +++-
 drivers/gpu/drm/radeon/radeon_combios.c| 1 +
 drivers/gpu/drm/radeon/radeon_encoders.c   | 1 +
 drivers/gpu/drm/radeon/radeon_mode.h   | 2 +-
 11 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 4aca09cab4b8..6e537c5bd295 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -29,6 +29,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
index e8fe239b9d79..324e9b765098 100644
--- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -21,6 +21,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 #include 
+#include 
 
 #include "radeon.h"
 #include "radeon_asic.h"
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
index 4a1d5447eac1..4c06f47453fd 100644
--- a/drivers/gpu/drm/radeon/dce6_afmt.c
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -21,6 +21,7 @@
  *
  */
 #include 
+#include 
 
 #include "dce6_afmt.h"
 #include "radeon.h"
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index f0ae087be914..a424b86008b8 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 5f3078f8ab95..681119c91d94 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -26,6 +26,7 @@
  */
 #include 
 
+#include 
 #include 
 #include "evergreen_hdmi.h"
 #include "radeon.h"
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 85c4bb186203..3596ea4a8b60 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -27,6 +27,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "radeon.h"
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c 
b/drivers/gpu/drm/radeon/radeon_audio.c
index 279bf130a18c..053058c5c1fa 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -26,6 +26,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include "dce6_afmt.h"
 #include "evergreen_hdmi.h"
diff --git a/drivers/gpu/drm/radeon/radeon_audio.h 
b/drivers/gpu/drm/radeon/radeon_audio.h
index 05e67867469b..dacaaa007051 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.h
+++ b/drivers/gpu/drm/radeon/radeon_audio.h
@@ -27,7 +27,9 @@
 
 #include 
 
-#define RREG32_ENDPOINT(block, reg)\
+struct cea_sad;
+
+#define RREG32_ENDPOINT(block, reg)\
radeon_audio_endpoint_rreg(rdev, (block), (reg))
 #define WREG32_ENDPOINT(block, reg, v) \
radeon_audio_endpoint_wreg(rdev, (block), (reg), (v))
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 2620efc7c675..6952b1273b0f 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "radeon.h"
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 9cb6401fe97e..3de3dce9e89d 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -26,6 +26,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 1decdcec0264..59c4db13d90a 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -32,13 +32,13 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
+struct edid;
 struct radeon_bo;
 struct radeon_device;
 
-- 
2.39.2

Re: [PATCH] drm/amd: include drm/drm_edid.h only where needed

[Alex Deucher]

Applied with some minor fixups for our -next tree.

Thanks!

Alex

On Tue, Dec 12, 2023 at 9:10 AM Jani Nikula  wrote:
>
> Including drm_edid.h from amdgpu_mode.h causes the rebuild of literally
> hundreds of files when drm_edid.h is modified, while there are only a
> handful of files that actually need to include drm_edid.h.
>
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c| 1 +
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
>  6 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 32fe05c810c6..3802ccdf6f55 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -32,7 +32,6 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -51,6 +50,7 @@ struct amdgpu_device;
>  struct amdgpu_encoder;
>  struct amdgpu_router;
>  struct amdgpu_hpd;
> +struct edid;
>
>  #define to_amdgpu_crtc(x) container_of(x, struct amdgpu_crtc, base)
>  #define to_amdgpu_connector(x) container_of(x, struct amdgpu_connector, base)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> index db6fc0cb18eb..453a4b786cfc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index 3ee219aa2891..7672abe6c140 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -28,6 +28,7 @@
>
>  #include 
>
> +#include 
>  #include 
>  #include "amdgpu.h"
>  #include "amdgpu_connectors.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index bb666cb7522e..587ee632a3b8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -21,6 +21,7 @@
>   *
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 7af277f61cca..f22ec27365bd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -21,6 +21,7 @@
>   *
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> 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 b599efda3b19..6f8128130b62 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
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "dm_services.h"
>  #include "amdgpu.h"
> --
> 2.39.2
>

Re: [PATCH] drm/radeon: include drm/drm_edid.h only where needed

[Alex Deucher]

Applied.  Thanks!

Alex

On Tue, Dec 12, 2023 at 9:10 AM Jani Nikula  wrote:
>
> Including drm_edid.h from radeon_mode.h causes the rebuild of more than
> a hundred files when drm_edid.h is modified, while there are only a
> handful of files that actually need to include drm_edid.h.
>
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c | 1 +
>  drivers/gpu/drm/radeon/dce3_1_afmt.c   | 1 +
>  drivers/gpu/drm/radeon/dce6_afmt.c | 1 +
>  drivers/gpu/drm/radeon/evergreen.c | 1 +
>  drivers/gpu/drm/radeon/evergreen_hdmi.c| 1 +
>  drivers/gpu/drm/radeon/radeon_atombios.c   | 1 +
>  drivers/gpu/drm/radeon/radeon_audio.c  | 1 +
>  drivers/gpu/drm/radeon/radeon_audio.h  | 4 +++-
>  drivers/gpu/drm/radeon/radeon_combios.c| 1 +
>  drivers/gpu/drm/radeon/radeon_encoders.c   | 1 +
>  drivers/gpu/drm/radeon/radeon_mode.h   | 2 +-
>  11 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 4aca09cab4b8..6e537c5bd295 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -29,6 +29,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
> b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> index e8fe239b9d79..324e9b765098 100644
> --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -21,6 +21,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  #include 
> +#include 
>
>  #include "radeon.h"
>  #include "radeon_asic.h"
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> index 4a1d5447eac1..4c06f47453fd 100644
> --- a/drivers/gpu/drm/radeon/dce6_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
> @@ -21,6 +21,7 @@
>   *
>   */
>  #include 
> +#include 
>
>  #include "dce6_afmt.h"
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index f0ae087be914..a424b86008b8 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 5f3078f8ab95..681119c91d94 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -26,6 +26,7 @@
>   */
>  #include 
>
> +#include 
>  #include 
>  #include "evergreen_hdmi.h"
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
> b/drivers/gpu/drm/radeon/radeon_atombios.c
> index 85c4bb186203..3596ea4a8b60 100644
> --- a/drivers/gpu/drm/radeon/radeon_atombios.c
> +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
> @@ -27,6 +27,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_audio.c 
> b/drivers/gpu/drm/radeon/radeon_audio.c
> index 279bf130a18c..053058c5c1fa 100644
> --- a/drivers/gpu/drm/radeon/radeon_audio.c
> +++ b/drivers/gpu/drm/radeon/radeon_audio.c
> @@ -26,6 +26,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>  #include "dce6_afmt.h"
>  #include "evergreen_hdmi.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_audio.h 
> b/drivers/gpu/drm/radeon/radeon_audio.h
> index 05e67867469b..dacaaa007051 100644
> --- a/drivers/gpu/drm/radeon/radeon_audio.h
> +++ b/drivers/gpu/drm/radeon/radeon_audio.h
> @@ -27,7 +27,9 @@
>
>  #include 
>
> -#define RREG32_ENDPOINT(block, reg)\
> +struct cea_sad;
> +
> +#define RREG32_ENDPOINT(block, reg)\
> radeon_audio_endpoint_rreg(rdev, (block), (reg))
>  #define WREG32_ENDPOINT(block, reg, v) \
> radeon_audio_endpoint_wreg(rdev, (block), (reg), (v))
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 2620efc7c675..6952b1273b0f 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -28,6 +28,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_encoders.c
> index 9cb6401fe97e..3de3dce9e89d 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -26,6 +26,7 @@
>
>  #include 
>
> +#include 
>  #include 
>  #include 
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 1decdcec0264..59c4db13d90a 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -32,13 +32,13 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> +struct edid;
>  struct 

Re: [PATCH] drm/amdgpu: Enable tunneling on high-priority compute queues

[Alex Deucher]

On Fri, Dec 1, 2023 at 7:18 PM Friedrich Vock  wrote:
>
> This improves latency if the GPU is already busy with other work.
> This is useful for VR compositors that submit highly latency-sensitive
> compositing work on high-priority compute queues while the GPU is busy
> rendering the next frame.
>
> Userspace merge request:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26462
>
> Signed-off-by: Friedrich Vock 

Applied with a minor change to bump the driver version as well so
userspace can detect this if necessary.  It shouldn't matter, but
better safe than sorry.

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 10 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   |  3 ++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c   |  3 ++-
>  4 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 9505dc8f9d69..4b923a156c4e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -790,6 +790,7 @@ struct amdgpu_mqd_prop {
> uint64_t eop_gpu_addr;
> uint32_t hqd_pipe_priority;
> uint32_t hqd_queue_priority;
> +   bool allow_tunneling;
> bool hqd_active;
>  };
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> index 231d49132a56..4d98e8879be8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> @@ -620,6 +620,10 @@ static void amdgpu_ring_to_mqd_prop(struct amdgpu_ring 
> *ring,
> struct amdgpu_mqd_prop *prop)
>  {
> struct amdgpu_device *adev = ring->adev;
> +   bool is_high_prio_compute = ring->funcs->type == 
> AMDGPU_RING_TYPE_COMPUTE &&
> +   
> amdgpu_gfx_is_high_priority_compute_queue(adev, ring);
> +   bool is_high_prio_gfx = ring->funcs->type == AMDGPU_RING_TYPE_GFX &&
> +   
> amdgpu_gfx_is_high_priority_graphics_queue(adev, ring);
>
> memset(prop, 0, sizeof(*prop));
>
> @@ -637,10 +641,8 @@ static void amdgpu_ring_to_mqd_prop(struct amdgpu_ring 
> *ring,
>  */
> prop->hqd_active = ring->funcs->type == AMDGPU_RING_TYPE_KIQ;
>
> -   if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE &&
> -amdgpu_gfx_is_high_priority_compute_queue(adev, ring)) ||
> -   (ring->funcs->type == AMDGPU_RING_TYPE_GFX &&
> -amdgpu_gfx_is_high_priority_graphics_queue(adev, ring))) {
> +   prop->allow_tunneling = is_high_prio_compute;
> +   if (is_high_prio_compute || is_high_prio_gfx) {
> prop->hqd_pipe_priority = AMDGPU_GFX_PIPE_PRIO_HIGH;
> prop->hqd_queue_priority = AMDGPU_GFX_QUEUE_PRIORITY_MAXIMUM;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index c8a3bf01743f..73f6d7e72c73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -6593,7 +6593,8 @@ static int gfx_v10_0_compute_mqd_init(struct 
> amdgpu_device *adev, void *m,
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, ENDIAN_SWAP, 1);
>  #endif
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, UNORD_DISPATCH, 0);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TUNNEL_DISPATCH, 0);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TUNNEL_DISPATCH,
> +   prop->allow_tunneling);
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, PRIV_STATE, 1);
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, KMD_QUEUE, 1);
> mqd->cp_hqd_pq_control = tmp;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> index c659ef0f47ce..bdcf96df69e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> @@ -3847,7 +3847,8 @@ static int gfx_v11_0_compute_mqd_init(struct 
> amdgpu_device *adev, void *m,
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, RPTR_BLOCK_SIZE,
> (order_base_2(AMDGPU_GPU_PAGE_SIZE / 4) - 1));
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, UNORD_DISPATCH, 0);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TUNNEL_DISPATCH, 0);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, TUNNEL_DISPATCH,
> +   prop->allow_tunneling);
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, PRIV_STATE, 1);
> tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_CONTROL, KMD_QUEUE, 1);
> mqd->cp_hqd_pq_control = tmp;
> --
> 2.43.0
>

RE: [PATCH] drm/amdgpu: Switch to aca bank for xgmi pcs err cnt

[Yang, Stanley]

[AMD Official Use Only - General]

Reviewed-by: Stanley.Yang 

Regards,
Stanley
> -Original Message-
> From: Zhang, Hawking 
> Sent: Tuesday, December 12, 2023 10:03 PM
> To: amd-gfx@lists.freedesktop.org; Yang, Stanley ;
> Wang, Yang(Kevin) 
> Cc: Zhang, Hawking 
> Subject: [PATCH] drm/amdgpu: Switch to aca bank for xgmi pcs err cnt
>
> Instead of software managed counters.
>
> Signed-off-by: Hawking Zhang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h  | 2 ++
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 6 --
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
> index e51e8918e667..b399f1b62887 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
> @@ -46,6 +46,8 @@
>  #define MCA_REG__STATUS__ERRORCODEEXT(x) MCA_REG_FIELD(x,
> 21, 16)
>  #define MCA_REG__STATUS__ERRORCODE(x)MCA_REG_FIELD(x,
> 15, 0)
>
> +#define MCA_REG__MISC0__ERRCNT(x)MCA_REG_FIELD(x,
> 43, 32)
> +
>  #define MCA_REG__SYND__ERRORINFORMATION(x)   MCA_REG_FIELD(x,
> 17, 0)
>
>  enum amdgpu_mca_ip {
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> index ddd782fbee7a..3998c9b31d07 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> @@ -2537,13 +2537,15 @@ static int
> mca_pcs_xgmi_mca_get_err_count(const struct mca_ras_info *mca_ras, st
> uint32_t *count)
>  {
>   u32 ext_error_code;
> + u32 err_cnt;
>
>   ext_error_code = MCA_REG__STATUS__ERRORCODEEXT(entry-
> >regs[MCA_REG_IDX_STATUS]);
> + err_cnt = MCA_REG__MISC0__ERRCNT(entry-
> >regs[MCA_REG_IDX_MISC0]);
>
>   if (type == AMDGPU_MCA_ERROR_TYPE_UE && ext_error_code == 0)
> - *count = 1;
> + *count = err_cnt;
>   else if (type == AMDGPU_MCA_ERROR_TYPE_CE && ext_error_code
> == 6)
> - *count = 1;
> + *count = err_cnt;
>
>   return 0;
>  }
> --
> 2.17.1

RE: [PATCH] drm/amdgpu: Switch to aca bank for xgmi pcs err cnt

[Wang, Yang(Kevin)]

[AMD Official Use Only - General]

Reviewed-by: Yang Wang 

Best Regards,
Kevin

-Original Message-
From: Zhang, Hawking 
Sent: Tuesday, December 12, 2023 10:03 PM
To: amd-gfx@lists.freedesktop.org; Yang, Stanley ; Wang, 
Yang(Kevin) 
Cc: Zhang, Hawking 
Subject: [PATCH] drm/amdgpu: Switch to aca bank for xgmi pcs err cnt

Instead of software managed counters.

Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h  | 2 ++
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
index e51e8918e667..b399f1b62887 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
@@ -46,6 +46,8 @@
 #define MCA_REG__STATUS__ERRORCODEEXT(x)   MCA_REG_FIELD(x, 21, 16)
 #define MCA_REG__STATUS__ERRORCODE(x)  MCA_REG_FIELD(x, 15, 0)

+#define MCA_REG__MISC0__ERRCNT(x)  MCA_REG_FIELD(x, 43, 32)
+
 #define MCA_REG__SYND__ERRORINFORMATION(x) MCA_REG_FIELD(x, 17, 0)

 enum amdgpu_mca_ip {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index ddd782fbee7a..3998c9b31d07 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -2537,13 +2537,15 @@ static int mca_pcs_xgmi_mca_get_err_count(const struct 
mca_ras_info *mca_ras, st
  uint32_t *count)
 {
u32 ext_error_code;
+   u32 err_cnt;

ext_error_code = 
MCA_REG__STATUS__ERRORCODEEXT(entry->regs[MCA_REG_IDX_STATUS]);
+   err_cnt = MCA_REG__MISC0__ERRCNT(entry->regs[MCA_REG_IDX_MISC0]);

if (type == AMDGPU_MCA_ERROR_TYPE_UE && ext_error_code == 0)
-   *count = 1;
+   *count = err_cnt;
else if (type == AMDGPU_MCA_ERROR_TYPE_CE && ext_error_code == 6)
-   *count = 1;
+   *count = err_cnt;

return 0;
 }
--
2.17.1

[PATCH] drm/amdgpu: Switch to aca bank for xgmi pcs err cnt

[Hawking Zhang]

Instead of software managed counters.

Signed-off-by: Hawking Zhang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h  | 2 ++
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
index e51e8918e667..b399f1b62887 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h
@@ -46,6 +46,8 @@
 #define MCA_REG__STATUS__ERRORCODEEXT(x)   MCA_REG_FIELD(x, 21, 16)
 #define MCA_REG__STATUS__ERRORCODE(x)  MCA_REG_FIELD(x, 15, 0)
 
+#define MCA_REG__MISC0__ERRCNT(x)  MCA_REG_FIELD(x, 43, 32)
+
 #define MCA_REG__SYND__ERRORINFORMATION(x) MCA_REG_FIELD(x, 17, 0)
 
 enum amdgpu_mca_ip {
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index ddd782fbee7a..3998c9b31d07 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -2537,13 +2537,15 @@ static int mca_pcs_xgmi_mca_get_err_count(const struct 
mca_ras_info *mca_ras, st
  uint32_t *count)
 {
u32 ext_error_code;
+   u32 err_cnt;
 
ext_error_code = 
MCA_REG__STATUS__ERRORCODEEXT(entry->regs[MCA_REG_IDX_STATUS]);
+   err_cnt = MCA_REG__MISC0__ERRCNT(entry->regs[MCA_REG_IDX_MISC0]);
 
if (type == AMDGPU_MCA_ERROR_TYPE_UE && ext_error_code == 0)
-   *count = 1;
+   *count = err_cnt;
else if (type == AMDGPU_MCA_ERROR_TYPE_CE && ext_error_code == 6)
-   *count = 1;
+   *count = err_cnt;
 
return 0;
 }
-- 
2.17.1

Re: [PATCH] drm/amdgpu: Enable tunneling on high-priority compute queues

[Michel Dänzer]

On 2023-12-08 18:59, Alex Deucher wrote:
> On Fri, Dec 8, 2023 at 12:27 PM Joshua Ashton  wrote:
>>
>> I heard some musings about dmabuf deadline kernel work recently, but not
>> sure if any of that is applicable to AMD.
> 
> I think something like a workload hint would be more useful.  We did a
> few patch sets to allow userspace to provide a hint to the kernel
> about the workload type so the kernel could adjust the power
> management heuristics accordingly, but there were concerns that the
> UMDs would have to maintain application lists to select which
> heuristic worked best for each application.  Maybe it would be better
> to provide a general classification?  E.g., if the GL or vulkan app
> uses these extensions, it's probably a compute type application vs
> something more graphics-y.  The usual trade-off between power and
> performance.  In general, just letting the firmware pick the clock
> based on perf counters generally seems to work the best.  Maybe a
> general workload hint set by the compositor based on the content type
> it's displaying would be a better option (video vs gaming vs desktop)?

Low clocks can be an issue even for normal desktop workloads, so doubtful that 
this would be a complete solution.


> The deadline stuff doesn't really align well with what we can do with
> our firmware and seems ripe for abuse.  Apps can just ask for high
> clocks all the time which is great for performance, but not great for
> power.

Maybe the firmware power management heuristics could be derived from the system 
power profile and fence deadline? E.g. the power profile defines the upper and 
lower boundaries, the upper boundary is used while there's a pending fence 
deadline, otherwise the lower boundary.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

RE: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"

[Lin, Wayne]

[Public]

Hi Mario,

Thanks for the help.
My feeling is like this problem probably relates to specific dock. Need time to 
take
further look.

Since reverting solves the issue now, feel free to add:
Acked-by: Wayne Lin 

Thanks,
Wayne

> -Original Message-
> From: Limonciello, Mario 
> Sent: Tuesday, December 12, 2023 12:15 AM
> To: amd-gfx@lists.freedesktop.org; Wentland, Harry
> 
> Cc: Linux Regressions ; sta...@vger.kernel.org;
> Wheeler, Daniel ; Lin, Wayne
> ; Oliver Schmidt 
> Subject: Re: [PATCH] Revert "drm/amd/display: Adjust the MST resume flow"
>
> Ping on this one.
>
> On 12/5/2023 13:54, Mario Limonciello wrote:
> > This reverts commit ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a.
> >
> > Reports are that this causes problems with external monitors after
> > wake up from suspend, which is something it was directly supposed to help.
> >
> > Cc: Linux Regressions 
> > Cc: sta...@vger.kernel.org
> > Cc: Daniel Wheeler 
> > Cc: Wayne Lin 
> > Reported-by: Oliver Schmidt 
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218211
> > Link:
> > https://forum.manjaro.org/t/problems-with-external-monitor-wake-up-aft
> > er-suspend/151840
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3023
> > Signed-off-by: Mario Limonciello  > 
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 93 +++--
> --
> >   1 file changed, 13 insertions(+), 80 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 c146dc9cba92..1ba58e4ecab3 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -2363,62 +2363,14 @@ static int dm_late_init(void *handle)
> > return detect_mst_link_for_all_connectors(adev_to_drm(adev));
> >   }
> >
> > -static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr
> > *mgr) -{
> > -   int ret;
> > -   u8 guid[16];
> > -   u64 tmp64;
> > -
> > -   mutex_lock(>lock);
> > -   if (!mgr->mst_primary)
> > -   goto out_fail;
> > -
> > -   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
> > -   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during
> suspend?\n");
> > -   goto out_fail;
> > -   }
> > -
> > -   ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
> > -DP_MST_EN |
> > -DP_UP_REQ_EN |
> > -DP_UPSTREAM_IS_SRC);
> > -   if (ret < 0) {
> > -   drm_dbg_kms(mgr->dev, "mst write failed - undocked during
> suspend?\n");
> > -   goto out_fail;
> > -   }
> > -
> > -   /* Some hubs forget their guids after they resume */
> > -   ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
> > -   if (ret != 16) {
> > -   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during
> suspend?\n");
> > -   goto out_fail;
> > -   }
> > -
> > -   if (memchr_inv(guid, 0, 16) == NULL) {
> > -   tmp64 = get_jiffies_64();
> > -   memcpy([0], , sizeof(u64));
> > -   memcpy([8], , sizeof(u64));
> > -
> > -   ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
> > -
> > -   if (ret != 16) {
> > -   drm_dbg_kms(mgr->dev, "check mstb guid failed -
> undocked during suspend?\n");
> > -   goto out_fail;
> > -   }
> > -   }
> > -
> > -   memcpy(mgr->mst_primary->guid, guid, 16);
> > -
> > -out_fail:
> > -   mutex_unlock(>lock);
> > -}
> > -
> >   static void s3_handle_mst(struct drm_device *dev, bool suspend)
> >   {
> > struct amdgpu_dm_connector *aconnector;
> > struct drm_connector *connector;
> > struct drm_connector_list_iter iter;
> > struct drm_dp_mst_topology_mgr *mgr;
> > +   int ret;
> > +   bool need_hotplug = false;
> >
> > drm_connector_list_iter_begin(dev, );
> > drm_for_each_connector_iter(connector, ) { @@ -2444,15
> > +2396,18 @@ static void s3_handle_mst(struct drm_device *dev, bool
> suspend)
> > if (!dp_is_lttpr_present(aconnector->dc_link))
> > try_to_configure_aux_timeout(aconnector-
> >dc_link->ddc,
> > LINK_AUX_DEFAULT_TIMEOUT_PERIOD);
> >
> > -   /* TODO: move resume_mst_branch_status() into
> drm mst resume again
> > -* once topology probing work is pulled out from mst
> resume into mst
> > -* resume 2nd step. mst resume 2nd step should be
> called after old
> > -* state getting restored (i.e.
> drm_atomic_helper_resume()).
> > -*/
> > -   resume_mst_branch_status(mgr);
> > +   ret = drm_dp_mst_topology_mgr_resume(mgr, true);
> > +   if (ret < 0) {
> > +
>   dm_helpers_dp_mst_stop_top_mgr(aconnector->dc_link->ctx,
> > +   aconnector->dc_link);
> > +   need_hotplug = true;
> > +   

Re: [PATCH 1/1] drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap

[Christian König]

Am 11.12.23 um 05:29 schrieb Wang, Beyond:


[AMD Official Use Only - General]


Subject: [PATCH 1/1] drm/amdgpu: fix ftrace event amdgpu_bo_move 
always move on same heap


Issue: during evict or validate happened on amdgpu_bo, the 'from' and

'to' is always same in ftrace event of amdgpu_bo_move

where calling the 'trace_amdgpu_bo_move', the comment says move_notify

is called before move happens, but actually it is called after move

happens, here the new_mem is same as bo->resource

Fix: pass old_mem instead when calling amdgpu_bo_move_notify



Good catch, but the tracepoint should probably be removed altogether.

amdgpu_bo_move_notify() is more for invalidation the mappings when 
something is moved or released.


We should rather add that to amdgpu_bo_move().

Regards,
Christian.


Signed-off-by: Wang, Beyond wang.bey...@amd.com

---

drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +-

drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  2 +-

drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  2 +-

3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c


index 7416799..0288495 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

@@ -1282,7 +1282,7 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, 
void *buffer,


  * amdgpu_bo_move_notify - notification about a memory move

  * @bo: pointer to a buffer object

  * @evict: if this move is evicting the buffer from the graphics 
address space


- * @new_mem: new information of the bufer object

+ * @old_mem: old information of the buffer object

  *

  * Marks the corresponding _bo buffer object as invalid, also 
performs


  * bookkeeping.

@@ -1290,11 +1290,11 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo 
*bo, void *buffer,


  */

void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,

   bool evict,

-  struct ttm_resource *new_mem)

+  struct ttm_resource *old_mem)

{

    struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);

    struct amdgpu_bo *abo;

-   struct ttm_resource *old_mem = bo->resource;

+   struct ttm_resource *new_mem = bo->resource;

    if (!amdgpu_bo_is_amdgpu_bo(bo))

    return;

@@ -1315,10 +1315,10 @@ void amdgpu_bo_move_notify(struct 
ttm_buffer_object *bo,


atomic64_inc(>num_evictions);

    /* update statistics */

-   if (!new_mem)

+   if (!old_mem || !new_mem)

    return;

-   /* move_notify is called before move happens */

+   /* move_notify is called after move happens in amdgpu_bo_move */

    trace_amdgpu_bo_move(abo, new_mem->mem_type, old_mem->mem_type);

}

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h


index 876acde..88be4b8 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

@@ -362,7 +362,7 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, 
void *buffer,


   uint64_t *flags);

void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,

   bool evict,

-  struct ttm_resource *new_mem);

+  struct ttm_resource *old_mem);

void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);

vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);

void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c


index 41ed6a3..8cc85d3 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

@@ -579,7 +579,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object 
*bo, bool evict,


out:

    /* update statistics */

    atomic64_add(bo->base.size, >num_bytes_moved);

-   amdgpu_bo_move_notify(bo, evict, new_mem);

+   amdgpu_bo_move_notify(bo, evict, old_mem);

    return 0;

}

--

2.34.1

Re: [PATCH 2/2] drm/amdgpu: make an improvement on amdgpu_hmm_range_get_pages

[Christian König]

Am 12.12.23 um 00:43 schrieb Felix Kuehling:


On 2023-12-11 05:38, Christian König wrote:

Am 09.12.23 um 00:01 schrieb James Zhu:

Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.


cond_resched() is usually NAKed upstream since it is a NO-OP in most 
situations.


That's weird, because https://docs.kernel.org/RCU/stallwarn.html 
specifically recommends it to resolve RCU stall warnings. I previously 
told James to use that instead of schedule().


I haven't followed the full discussion and rational about that either, 
could be that the documentation is outdated.


The latest RFC to remove cond_resched() and explaining the background 
can be found here: https://lwn.net/Articles/950581/


Regards,
Christian.



Regards,
  Felix




IIRC there was even a patch set to completely remove it.

Christian.



Signed-off-by: James Zhu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c

index b24eb5821fd1..c77c4eceea46 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
@@ -199,6 +199,7 @@ int amdgpu_hmm_range_get_pages(struct 
mmu_interval_notifier *notifier,

  hmm_range->notifier_seq = mmu_interval_read_begin(notifier);
  r = hmm_range_fault(hmm_range);
  if (unlikely(r)) {
+    cond_resched();
  /*
   * FIXME: This timeout should encompass the retry from
   * mmu_interval_read_retry() as well.
@@ -212,7 +213,6 @@ int amdgpu_hmm_range_get_pages(struct 
mmu_interval_notifier *notifier,

  break;
  hmm_range->hmm_pfns += MAX_WALK_BYTE >> PAGE_SHIFT;
  hmm_range->start = hmm_range->end;
-    schedule();
  } while (hmm_range->end < end);
    hmm_range->start = start;

Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V

[Christoph Hellwig]

On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> Actually tracking all possibly-FPU-tainted functions and their call sites is
> probably possible, but a much larger task.

I think objtool should be able to do that reasonably easily, it already
does it for checking section where userspace address access is enabled
or not, which is very similar.

Re: [RFC PATCH 05/12] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS

[Christoph Hellwig]

On Mon, Dec 11, 2023 at 10:12:27AM -0600, Samuel Holland wrote:
> On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
> 
> Unfortunately, not all of the relevant options can be no-prefixed:

Ok.  That is another good argument for having the obj-fpu += syntax
I proposed.  You might need help from the kbuild maintainers from that
as trying to understand the kbuild magic isn't something I'd expect
from a normal contributor (including myself..).

Re: Radeon regression in 6.6 kernel

[Phillip Susi]

Phillip Susi  writes:

> And it works, but 6.7-rc5 does not, even though it includes that patch.
> Here's the syslog from the attempt.  I'll start bisecting again.

I checked out the patch that got merged upstream and it also fails.  I
looked at the two commits, and I see what happened.  Your original patch
MOVED the call to amdgpu_ttm_set_buffer_funcs_status().  The one that
got merged into Linus' tree instead DUPLICATES the call.  Oops?