From: Greg Kroah-Hartman Date: Wed, 27 Jul 2022 08:17:12 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v4.9.325~31 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=28d9d9d778ea20ea18f5021d55b0d78615447108;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: drm-amd-display-fix-surface-optimization-regression-on-carrizo.patch drm-amd-display-optimize-bandwidth-on-following-fast-update.patch drm-amd-display-reset-dmcub-before-hw-init.patch exfat-use-updated-exfat_chain-directly-during-renaming.patch --- diff --git a/queue-5.15/drm-amd-display-fix-surface-optimization-regression-on-carrizo.patch b/queue-5.15/drm-amd-display-fix-surface-optimization-regression-on-carrizo.patch new file mode 100644 index 00000000000..b00af283d0d --- /dev/null +++ b/queue-5.15/drm-amd-display-fix-surface-optimization-regression-on-carrizo.patch @@ -0,0 +1,62 @@ +From 62e5a7e2333a9f5395f6a9db766b7b06c949fe7a Mon Sep 17 00:00:00 2001 +From: Nicholas Kazlauskas +Date: Tue, 12 Oct 2021 10:04:03 -0400 +Subject: drm/amd/display: Fix surface optimization regression on Carrizo + +From: Nicholas Kazlauskas + +commit 62e5a7e2333a9f5395f6a9db766b7b06c949fe7a upstream. + +[Why] +DCE legacy optimization path isn't well tested under new DC optimization +flow which can result in underflow occuring when initializing X11 on +Carrizo. + +[How] +Retain the legacy optimization flow for DCE and keep the new one for DCN +to satisfy optimizations being correctly applied for ASIC that can +support it. + +Fixes: 34316c1e561db0 ("drm/amd/display: Optimize bandwidth on following fast update") +Reported-by: Tom St Denis +Tested-by: Tom St Denis +Reviewed-by: Harry Wentland +Signed-off-by: Nicholas Kazlauskas +Signed-off-by: Alex Deucher +Cc: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -2979,8 +2979,13 @@ void dc_commit_updates_for_stream(struct + if (new_pipe->plane_state && new_pipe->plane_state != old_pipe->plane_state) + new_pipe->plane_state->force_full_update = true; + } +- } else if (update_type == UPDATE_TYPE_FAST) { +- /* Previous frame finished and HW is ready for optimization. */ ++ } else if (update_type == UPDATE_TYPE_FAST && dc_ctx->dce_version >= DCE_VERSION_MAX) { ++ /* ++ * Previous frame finished and HW is ready for optimization. ++ * ++ * Only relevant for DCN behavior where we can guarantee the optimization ++ * is safe to apply - retain the legacy behavior for DCE. ++ */ + dc_post_update_surfaces_to_stream(dc); + } + +@@ -3039,6 +3044,12 @@ void dc_commit_updates_for_stream(struct + } + } + ++ /* Legacy optimization path for DCE. */ ++ if (update_type >= UPDATE_TYPE_FULL && dc_ctx->dce_version < DCE_VERSION_MAX) { ++ dc_post_update_surfaces_to_stream(dc); ++ TRACE_DCE_CLOCK_STATE(&context->bw_ctx.bw.dce); ++ } ++ + return; + + } diff --git a/queue-5.15/drm-amd-display-optimize-bandwidth-on-following-fast-update.patch b/queue-5.15/drm-amd-display-optimize-bandwidth-on-following-fast-update.patch new file mode 100644 index 00000000000..4e2aee4745d --- /dev/null +++ b/queue-5.15/drm-amd-display-optimize-bandwidth-on-following-fast-update.patch @@ -0,0 +1,68 @@ +From 34316c1e561db0b24e341029f04a5a5bead9a7bc Mon Sep 17 00:00:00 2001 +From: Nicholas Kazlauskas +Date: Thu, 19 Aug 2021 16:36:09 -0400 +Subject: drm/amd/display: Optimize bandwidth on following fast update + +From: Nicholas Kazlauskas + +commit 34316c1e561db0b24e341029f04a5a5bead9a7bc upstream. + +[Why] +The current call to optimize_bandwidth never occurs because flip is +always pending from the FULL and FAST updates. + +[How] +Optimize on the following flip when it's a FAST update and we know we +aren't going to be modifying the clocks again. + +Reviewed-by: Bhawanpreet Lakha +Acked-by: Mikita Lipski +Signed-off-by: Nicholas Kazlauskas +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Cc: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc.c | 17 ++++++++--------- + 1 file changed, 8 insertions(+), 9 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -1788,6 +1788,11 @@ void dc_post_update_surfaces_to_stream(s + + post_surface_trace(dc); + ++ if (dc->ctx->dce_version >= DCE_VERSION_MAX) ++ TRACE_DCN_CLOCK_STATE(&context->bw_ctx.bw.dcn.clk); ++ else ++ TRACE_DCE_CLOCK_STATE(&context->bw_ctx.bw.dce); ++ + if (is_flip_pending_in_pipes(dc, context)) + return; + +@@ -2974,6 +2979,9 @@ void dc_commit_updates_for_stream(struct + if (new_pipe->plane_state && new_pipe->plane_state != old_pipe->plane_state) + new_pipe->plane_state->force_full_update = true; + } ++ } else if (update_type == UPDATE_TYPE_FAST) { ++ /* Previous frame finished and HW is ready for optimization. */ ++ dc_post_update_surfaces_to_stream(dc); + } + + +@@ -3030,15 +3038,6 @@ void dc_commit_updates_for_stream(struct + pipe_ctx->plane_state->force_full_update = false; + } + } +- /*let's use current_state to update watermark etc*/ +- if (update_type >= UPDATE_TYPE_FULL) { +- dc_post_update_surfaces_to_stream(dc); +- +- if (dc_ctx->dce_version >= DCE_VERSION_MAX) +- TRACE_DCN_CLOCK_STATE(&context->bw_ctx.bw.dcn.clk); +- else +- TRACE_DCE_CLOCK_STATE(&context->bw_ctx.bw.dce); +- } + + return; + diff --git a/queue-5.15/drm-amd-display-reset-dmcub-before-hw-init.patch b/queue-5.15/drm-amd-display-reset-dmcub-before-hw-init.patch new file mode 100644 index 00000000000..0b6722cae00 --- /dev/null +++ b/queue-5.15/drm-amd-display-reset-dmcub-before-hw-init.patch @@ -0,0 +1,42 @@ +From 791255ca9fbe38042cfd55df5deb116dc11fef18 Mon Sep 17 00:00:00 2001 +From: Nicholas Kazlauskas +Date: Fri, 10 Dec 2021 15:04:05 -0800 +Subject: drm/amd/display: Reset DMCUB before HW init + +From: Nicholas Kazlauskas + +commit 791255ca9fbe38042cfd55df5deb116dc11fef18 upstream. + +[Why] +If the firmware wasn't reset by PSP or HW and is currently running +then the firmware will hang or perform underfined behavior when we +modify its firmware state underneath it. + +[How] +Reset DMCUB before setting up cache windows and performing HW init. + +Reviewed-by: Aurabindo Jayamohanan Pillai +Acked-by: Pavle Kotarac +Tested-by: Daniel Wheeler +Signed-off-by: Nicholas Kazlauskas +Signed-off-by: Alex Deucher +Cc: "Limonciello, Mario" +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -1028,6 +1028,11 @@ static int dm_dmub_hw_init(struct amdgpu + return 0; + } + ++ /* Reset DMCUB if it was previously running - before we overwrite its memory. */ ++ status = dmub_srv_hw_reset(dmub_srv); ++ if (status != DMUB_STATUS_OK) ++ DRM_WARN("Error resetting DMUB HW: %d\n", status); ++ + hdr = (const struct dmcub_firmware_header_v1_0 *)dmub_fw->data; + + fw_inst_const = dmub_fw->data + diff --git a/queue-5.15/exfat-use-updated-exfat_chain-directly-during-renaming.patch b/queue-5.15/exfat-use-updated-exfat_chain-directly-during-renaming.patch new file mode 100644 index 00000000000..26eceffcd85 --- /dev/null +++ b/queue-5.15/exfat-use-updated-exfat_chain-directly-during-renaming.patch @@ -0,0 +1,51 @@ +From 204e6ceaa1035cb7b92b156517e88842ebb4c7ff Mon Sep 17 00:00:00 2001 +From: Sungjong Seo +Date: Wed, 8 Jun 2022 00:05:21 +0900 +Subject: exfat: use updated exfat_chain directly during renaming + +From: Sungjong Seo + +commit 204e6ceaa1035cb7b92b156517e88842ebb4c7ff upstream. + +In order for a file to access its own directory entry set, +exfat_inode_info(ei) has two copied values. One is ei->dir, which is +a snapshot of exfat_chain of the parent directory, and the other is +ei->entry, which is the offset of the start of the directory entry set +in the parent directory. + +Since the parent directory can be updated after the snapshot point, +it should be used only for accessing one's own directory entry set. + +However, as of now, during renaming, it could try to traverse or to +allocate clusters via snapshot values, it does not make sense. + +This potential problem has been revealed when exfat_update_parent_info() +was removed by commit d8dad2588add ("exfat: fix referencing wrong parent +directory information after renaming"). However, I don't think it's good +idea to bring exfat_update_parent_info() back. + +Instead, let's use the updated exfat_chain of parent directory diectly. + +Fixes: d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming") +Reported-by: Wang Yugui +Signed-off-by: Sungjong Seo +Tested-by: Wang Yugui +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman +--- + fs/exfat/namei.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/exfat/namei.c ++++ b/fs/exfat/namei.c +@@ -1190,7 +1190,9 @@ static int __exfat_rename(struct inode * + return -ENOENT; + } + +- exfat_chain_dup(&olddir, &ei->dir); ++ exfat_chain_set(&olddir, EXFAT_I(old_parent_inode)->start_clu, ++ EXFAT_B_TO_CLU_ROUND_UP(i_size_read(old_parent_inode), sbi), ++ EXFAT_I(old_parent_inode)->flags); + dentry = ei->entry; + + ep = exfat_get_dentry(sb, &olddir, dentry, &old_bh, NULL); diff --git a/queue-5.15/series b/queue-5.15/series index f173079a171..7bfbc5788d1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -180,3 +180,7 @@ bluetooth-rfcomm-replace-use-of-memcpy_from_msg-with-bt_skb_sendmmsg.patch bluetooth-fix-passing-null-to-ptr_err.patch bluetooth-sco-fix-sco_send_frame-returning-skb-len.patch bluetooth-fix-bt_skb_sendmmsg-not-allocating-partial-chunks.patch +exfat-use-updated-exfat_chain-directly-during-renaming.patch +drm-amd-display-reset-dmcub-before-hw-init.patch +drm-amd-display-optimize-bandwidth-on-following-fast-update.patch +drm-amd-display-fix-surface-optimization-regression-on-carrizo.patch