--- /dev/null
+From 62e5a7e2333a9f5395f6a9db766b7b06c949fe7a Mon Sep 17 00:00:00 2001
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Date: Tue, 12 Oct 2021 10:04:03 -0400
+Subject: drm/amd/display: Fix surface optimization regression on Carrizo
+
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+
+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 <tom.stdenis@amd.com>
+Tested-by: Tom St Denis <tom.stdenis@amd.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Mario Limonciello <Mario.Limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
+ }
--- /dev/null
+From 34316c1e561db0b24e341029f04a5a5bead9a7bc Mon Sep 17 00:00:00 2001
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Date: Thu, 19 Aug 2021 16:36:09 -0400
+Subject: drm/amd/display: Optimize bandwidth on following fast update
+
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+
+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 <bhawanpreet.lakha@amd.com>
+Acked-by: Mikita Lipski <mikita.lipski@amd.com>
+Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Mario Limonciello <Mario.Limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From 791255ca9fbe38042cfd55df5deb116dc11fef18 Mon Sep 17 00:00:00 2001
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Date: Fri, 10 Dec 2021 15:04:05 -0800
+Subject: drm/amd/display: Reset DMCUB before HW init
+
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+
+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 <Aurabindo.Pillai@amd.com>
+Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 +
--- /dev/null
+From 204e6ceaa1035cb7b92b156517e88842ebb4c7ff Mon Sep 17 00:00:00 2001
+From: Sungjong Seo <sj1557.seo@samsung.com>
+Date: Wed, 8 Jun 2022 00:05:21 +0900
+Subject: exfat: use updated exfat_chain directly during renaming
+
+From: Sungjong Seo <sj1557.seo@samsung.com>
+
+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 <wangyugui@e16-tech.com>
+Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com>
+Tested-by: Wang Yugui <wangyugui@e16-tech.com>
+Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
