From: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
To: <amd-gfx@lists.freedesktop.org>
Cc: Harry Wentland <harry.wentland@amd.com>,
Leo Li <sunpeng.li@amd.com>,
Rodrigo Siqueira <rodrigo.siqueira@amd.com>,
Hamza Mahfooz <hamza.mahfooz@amd.com>,
Aurabindo Pillai <aurabindo.pillai@amd.com>,
"Roman Li" <roman.li@amd.com>, Wayne Lin <wayne.lin@amd.com>,
Tom Chung <chiahsuan.chung@amd.com>,
Fangzhi Zuo <jerry.zuo@amd.com>,
Zaeem Mohamed <zaeem.mohamed@amd.com>,
Solomon Chiu <solomon.chiu@amd.com>,
Daniel Wheeler <daniel.wheeler@amd.com>,
Josip Pavic <Josip.Pavic@amd.com>, Aric Cyr <aric.cyr@amd.com>
Subject: [PATCH 13/26] drm/amd/display: Clear update flags after update has been applied
Date: Thu, 3 Oct 2024 17:33:31 -0600 [thread overview]
Message-ID: <20241003233509.210919-14-Rodrigo.Siqueira@amd.com> (raw)
In-Reply-To: <20241003233509.210919-1-Rodrigo.Siqueira@amd.com>
From: Josip Pavic <Josip.Pavic@amd.com>
[Why]
Since the surface/stream update flags aren't cleared after applying
updates, those same updates may be applied again in a future call to
update surfaces/streams for surfaces/streams that aren't actually part
of that update (i.e. applying an update for one surface/stream can
trigger unintended programming on a different surface/stream).
For example, when an update results in a call to
program_front_end_for_ctx, that function may call program_pipe on all
pipes. If there are surface update flags that were never cleared on the
surface some pipe is attached to, then the same update will be
programmed again.
[How]
Clear the surface and stream update flags after applying the updates.
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 45 ++++++++++++++++++------
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 981d9a327daf..7b239cbfbb4a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -5129,11 +5129,26 @@ static bool update_planes_and_stream_v3(struct dc *dc,
return true;
}
+static void clear_update_flags(struct dc_surface_update *srf_updates,
+ int surface_count, struct dc_stream_state *stream)
+{
+ int i;
+
+ if (stream)
+ stream->update_flags.raw = 0;
+
+ for (i = 0; i < surface_count; i++)
+ if (srf_updates[i].surface)
+ srf_updates[i].surface->update_flags.raw = 0;
+}
+
bool dc_update_planes_and_stream(struct dc *dc,
struct dc_surface_update *srf_updates, int surface_count,
struct dc_stream_state *stream,
struct dc_stream_update *stream_update)
{
+ bool ret = false;
+
dc_exit_ips_for_hw_access(dc);
/*
* update planes and stream version 3 separates FULL and FAST updates
@@ -5150,10 +5165,16 @@ bool dc_update_planes_and_stream(struct dc *dc,
* features as they are now transparent to the new sequence.
*/
if (dc->ctx->dce_version >= DCN_VERSION_4_01)
- return update_planes_and_stream_v3(dc, srf_updates,
+ ret = update_planes_and_stream_v3(dc, srf_updates,
surface_count, stream, stream_update);
- return update_planes_and_stream_v2(dc, srf_updates,
+ else
+ ret = update_planes_and_stream_v2(dc, srf_updates,
surface_count, stream, stream_update);
+
+ if (ret)
+ clear_update_flags(srf_updates, surface_count, stream);
+
+ return ret;
}
void dc_commit_updates_for_stream(struct dc *dc,
@@ -5163,6 +5184,8 @@ void dc_commit_updates_for_stream(struct dc *dc,
struct dc_stream_update *stream_update,
struct dc_state *state)
{
+ bool ret = false;
+
dc_exit_ips_for_hw_access(dc);
/* TODO: Since change commit sequence can have a huge impact,
* we decided to only enable it for DCN3x. However, as soon as
@@ -5170,17 +5193,17 @@ void dc_commit_updates_for_stream(struct dc *dc,
* the new sequence for all ASICs.
*/
if (dc->ctx->dce_version >= DCN_VERSION_4_01) {
- update_planes_and_stream_v3(dc, srf_updates, surface_count,
+ ret = update_planes_and_stream_v3(dc, srf_updates, surface_count,
stream, stream_update);
- return;
- }
- if (dc->ctx->dce_version >= DCN_VERSION_3_2) {
- update_planes_and_stream_v2(dc, srf_updates, surface_count,
+ } else if (dc->ctx->dce_version >= DCN_VERSION_3_2) {
+ ret = update_planes_and_stream_v2(dc, srf_updates, surface_count,
stream, stream_update);
- return;
- }
- update_planes_and_stream_v1(dc, srf_updates, surface_count, stream,
- stream_update, state);
+ } else
+ ret = update_planes_and_stream_v1(dc, srf_updates, surface_count, stream,
+ stream_update, state);
+
+ if (ret)
+ clear_update_flags(srf_updates, surface_count, stream);
}
uint8_t dc_get_current_stream_count(struct dc *dc)
--
2.45.2
next prev parent reply other threads:[~2024-10-03 23:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 23:33 [PATCH 00/26] DC Patches October 3rd, 2024 Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 01/26] drm/amd/display: Unify blank_phantom and blank_pixel_data Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 02/26] drm/amd/display: skip disable CRTC in seemless bootup case Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 03/26] drm/amd/display: Flip All Planes Under OTG Master When Flip Immediate Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 04/26] drm/amd/display: Revert commit Update Interface to Check UCLK DPM Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 05/26] drm/amd/display: force TBT4 dock dsc on Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 06/26] drm/amd/display: Assign socclk in dml Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 07/26] drm/amd/display: Fix garbage or black screen when resetting otg Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 08/26] drm/amd/display: Display lost signal on playing video Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 09/26] drm/amd/display: Noitfy DMCUB of D0/D3 state in hardware init Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 10/26] drm/amd/display: Fix low black values by increasing error Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 11/26] drm/amd/display: Remove programming outstanding updates for dcn35 Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 12/26] drm/amd/display: update sr_exit latency for z8 Rodrigo Siqueira
2024-10-03 23:33 ` Rodrigo Siqueira [this message]
2024-10-04 12:56 ` [PATCH 13/26] drm/amd/display: Clear update flags after update has been applied Melissa Wen
2024-10-04 18:20 ` Matthew Schwartz
2024-10-03 23:33 ` [PATCH 14/26] drm/amd/display: fix a memleak issue when driver is removed Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 15/26] drm/amd/display: calculate final viewport before TAP optimization Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 16/26] drm/amd/display: Align static screen idle worker with IPX mode Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 17/26] drm/amd/display: Skip Invalid Streams from DSC Policy Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 18/26] drm/amd/display: Allow Latency Increase For Last Strategy Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 19/26] drm/amd/display: Move Link Encoder Assignment Out Of dc_global_validate Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 20/26] drm/amd/display: Update Interface to Check UCLK DPM Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 21/26] drm/amd/display: Add DMUB debug offset Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 22/26] drm/amd/display: Remove unnecessary assignments Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 23/26] drm/amd/display: Remove redundant assignments Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 24/26] drm/amd/display: Initialize replay_config var Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 25/26] drm/amd/display: Initialize new backlight_level_params structure Rodrigo Siqueira
2024-10-03 23:33 ` [PATCH 26/26] drm/amd/display: 3.2.304 Rodrigo Siqueira
2024-10-04 15:05 ` [PATCH 00/26] DC Patches October 3rd, 2024 Wheeler, Daniel
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=20241003233509.210919-14-Rodrigo.Siqueira@amd.com \
--to=rodrigo.siqueira@amd.com \
--cc=Josip.Pavic@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=aric.cyr@amd.com \
--cc=aurabindo.pillai@amd.com \
--cc=chiahsuan.chung@amd.com \
--cc=daniel.wheeler@amd.com \
--cc=hamza.mahfooz@amd.com \
--cc=harry.wentland@amd.com \
--cc=jerry.zuo@amd.com \
--cc=roman.li@amd.com \
--cc=solomon.chiu@amd.com \
--cc=sunpeng.li@amd.com \
--cc=wayne.lin@amd.com \
--cc=zaeem.mohamed@amd.com \
/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