[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240527155123.3863983-2-sashal@kernel.org>
Date: Mon, 27 May 2024 11:50:03 -0400
From: Sasha Levin <sashal@...nel.org>
To: linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@....com>,
Duncan Ma <duncan.ma@....com>,
Wayne Lin <wayne.lin@....com>,
Daniel Wheeler <daniel.wheeler@....com>,
Alex Deucher <alexander.deucher@....com>,
Sasha Levin <sashal@...nel.org>,
harry.wentland@....com,
sunpeng.li@....com,
Rodrigo.Siqueira@....com,
christian.koenig@....com,
Xinhui.Pan@....com,
airlied@...il.com,
daniel@...ll.ch,
chiahsuan.chung@....com,
samson.tam@....com,
dillon.varone@....com,
alvin.lee2@....com,
jinze.xu@....com,
Qingqing.Zhuo@....com,
cruise.hung@....com,
amd-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org
Subject: [PATCH AUTOSEL 6.9 02/23] drm/amd/display: Workaround register access in idle race with cursor
From: Nicholas Kazlauskas <nicholas.kazlauskas@....com>
[ Upstream commit b5b6d6251579a29dafdad25f4bc7f3ff7bfd2c86 ]
[Why]
Cursor update can be pre-empted by a request for setting target flip
submission.
This causes an issue where we're in the middle of the exit sequence
trying to log to DM, but the pre-emption starts another DMCUB
command submission that requires being out of idle.
The DC lock aqusition can fail, and depending on the DM/OS interface
it's possible that the function inserted into this thread must not fail.
This means that lock aqusition must be skipped and exit *must* occur.
[How]
Modify when we consider idle as active. Consider it exited only once
the exit has fully finished.
Consider it as entered prior to actual notification.
Since we're on the same core/thread the cached values are coherent
and we'll see that we still need to exit. Once the cursor update resumes
it'll continue doing the double exit but this won't cause a functional
issue, just a (potential) redundant operation.
Reviewed-by: Duncan Ma <duncan.ma@....com>
Acked-by: Wayne Lin <wayne.lin@....com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@....com>
Tested-by: Daniel Wheeler <daniel.wheeler@....com>
Signed-off-by: Alex Deucher <alexander.deucher@....com>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 23 +++++++++++++++-----
1 file changed, 17 insertions(+), 6 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 6083b1dcf050a..a72e849eced3f 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -1340,16 +1340,27 @@ void dc_dmub_srv_apply_idle_power_optimizations(const struct dc *dc, bool allow_
* Powering up the hardware requires notifying PMFW and DMCUB.
* Clearing the driver idle allow requires a DMCUB command.
* DMCUB commands requires the DMCUB to be powered up and restored.
- *
- * Exit out early to prevent an infinite loop of DMCUB commands
- * triggering exit low power - use software state to track this.
*/
- dc_dmub_srv->idle_allowed = allow_idle;
- if (!allow_idle)
+ if (!allow_idle) {
dc_dmub_srv_exit_low_power_state(dc);
- else
+ /*
+ * Idle is considered fully exited only after the sequence above
+ * fully completes. If we have a race of two threads exiting
+ * at the same time then it's safe to perform the sequence
+ * twice as long as we're not re-entering.
+ *
+ * Infinite command submission is avoided by using the
+ * dm_execute_dmub_cmd submission instead of the "wake" helpers.
+ */
+ dc_dmub_srv->idle_allowed = false;
+ } else {
+ /* Consider idle as notified prior to the actual submission to
+ * prevent multiple entries. */
+ dc_dmub_srv->idle_allowed = true;
+
dc_dmub_srv_notify_idle(dc, allow_idle);
+ }
}
bool dc_wake_and_execute_dmub_cmd(const struct dc_context *ctx, union dmub_rb_cmd *cmd,
--
2.43.0
Powered by blists - more mailing lists