stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, Aric Cyr <aric.cyr@amd.com>,
	Qingqing Zhuo <qingqing.zhuo@amd.com>,
	Daniel Wheeler <daniel.wheeler@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: [PATCH 6.1 03/11] drm/amd/display: Do not update DRR while BW optimizations pending
Date: Mon,  3 Jul 2023 20:54:22 +0200	[thread overview]
Message-ID: <20230703184519.217176801@linuxfoundation.org> (raw)
In-Reply-To: <20230703184519.121965745@linuxfoundation.org>

From: Aric Cyr <aric.cyr@amd.com>

commit 32953485c558cecf08f33fbfa251e80e44cef981 upstream.

[why]
While bandwidth optimizations are pending, it's possible a pstate change
will occur.  During this time, VSYNC handler should not also try to update
DRR parameters causing pstate hang

[how]
Do not adjust DRR if optimize bandwidth is set.

Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@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 |   48 ++++++++++++++++++-------------
 1 file changed, 29 insertions(+), 19 deletions(-)

--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -401,6 +401,13 @@ bool dc_stream_adjust_vmin_vmax(struct d
 {
 	int i;
 
+	/*
+	 * Don't adjust DRR while there's bandwidth optimizations pending to
+	 * avoid conflicting with firmware updates.
+	 */
+	if (dc->optimized_required || dc->wm_optimized_required)
+		return false;
+
 	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;
@@ -2021,27 +2028,33 @@ 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
+	/*
+	 * Only relevant for DCN behavior where we can guarantee the optimization
+	 * is safe to apply - retain the legacy behavior for DCE.
+	 */
+
+	if (dc->ctx->dce_version < DCE_VERSION_MAX)
 		TRACE_DCE_CLOCK_STATE(&context->bw_ctx.bw.dce);
+	else {
+		TRACE_DCN_CLOCK_STATE(&context->bw_ctx.bw.dcn.clk);
 
-	if (is_flip_pending_in_pipes(dc, context))
-		return;
+		if (is_flip_pending_in_pipes(dc, context))
+			return;
 
-	for (i = 0; i < dc->res_pool->pipe_count; i++)
-		if (context->res_ctx.pipe_ctx[i].stream == NULL ||
-		    context->res_ctx.pipe_ctx[i].plane_state == NULL) {
-			context->res_ctx.pipe_ctx[i].pipe_idx = i;
-			dc->hwss.disable_plane(dc, &context->res_ctx.pipe_ctx[i]);
-		}
+		for (i = 0; i < dc->res_pool->pipe_count; i++)
+			if (context->res_ctx.pipe_ctx[i].stream == NULL ||
+					context->res_ctx.pipe_ctx[i].plane_state == NULL) {
+				context->res_ctx.pipe_ctx[i].pipe_idx = i;
+				dc->hwss.disable_plane(dc, &context->res_ctx.pipe_ctx[i]);
+			}
 
-	process_deferred_updates(dc);
+		process_deferred_updates(dc);
 
-	dc->hwss.optimize_bandwidth(dc, context);
+		dc->hwss.optimize_bandwidth(dc, context);
 
-	if (dc->debug.enable_double_buffered_dsc_pg_support)
-		dc->hwss.update_dsc_pg(dc, context, true);
+		if (dc->debug.enable_double_buffered_dsc_pg_support)
+			dc->hwss.update_dsc_pg(dc, context, true);
+	}
 
 	dc->optimized_required = false;
 	dc->wm_optimized_required = false;
@@ -3866,12 +3879,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 && dc_ctx->dce_version >= DCE_VERSION_MAX) {
+	} else if (update_type == UPDATE_TYPE_FAST) {
 		/*
 		 * 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);
 	}



  parent reply	other threads:[~2023-07-03 18:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 18:54 [PATCH 6.1 00/11] 6.1.38-rc1 review Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 01/11] xtensa: fix lock_mm_and_find_vma in case VMA not found Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 02/11] drm/amd/display: Remove optimization for VRR updates Greg Kroah-Hartman
2023-07-03 18:54 ` Greg Kroah-Hartman [this message]
2023-07-03 18:54 ` [PATCH 6.1 04/11] PCI/ACPI: Validate acpi_pci_set_power_state() parameter Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 05/11] PCI/ACPI: Call _REG when transitioning D-states Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 06/11] execve: always mark stack as growing down during early stack setup Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 07/11] nubus: Partially revert proc_create_single_data() conversion Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 08/11] perf symbols: Symbol lookup with kcore can fail if multiple segments match stext Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 09/11] scripts/tags.sh: Resolve gtags empty index generation Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 10/11] docs: Set minimal gtags / GNU GLOBAL version to 6.6.5 Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 11/11] drm/amdgpu: Validate VM ioctl flags Greg Kroah-Hartman
2023-07-03 23:02 ` [PATCH 6.1 00/11] 6.1.38-rc1 review ogasawara takeshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230703184519.217176801@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=aric.cyr@amd.com \
    --cc=daniel.wheeler@amd.com \
    --cc=mario.limonciello@amd.com \
    --cc=patches@lists.linux.dev \
    --cc=qingqing.zhuo@amd.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).