Skip to content

Commit 85e4d92

Browse files
bnilawargregkh
authored andcommitted
drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout
[ Upstream commit 22ef43c ] In case if g2h worker doesn't get opportunity to within specified timeout delay then flush the g2h worker explicitly. v2: - Describe change in the comment and add TODO (Matt B/John H) - Add xe_gt_warn on fence done after G2H flush (John H) v3: - Updated the comment with root cause - Clean up xe_gt_warn message (John H) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1620 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2902 Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241017111410.2553784-2-badal.nilawar@intel.com (cherry picked from commit e515272) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Stable-dep-of: 55e8a3f ("drm/xe: Move LNL scheduling WA to xe_device.h") Signed-off-by: Sasha Levin <sashal@kernel.org>
1 parent e5a6d36 commit 85e4d92

1 file changed

Lines changed: 18 additions & 0 deletions

File tree

drivers/gpu/drm/xe/xe_guc_ct.c

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -888,6 +888,24 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
888888

889889
ret = wait_event_timeout(ct->g2h_fence_wq, g2h_fence.done, HZ);
890890

891+
/*
892+
* Occasionally it is seen that the G2H worker starts running after a delay of more than
893+
* a second even after being queued and activated by the Linux workqueue subsystem. This
894+
* leads to G2H timeout error. The root cause of issue lies with scheduling latency of
895+
* Lunarlake Hybrid CPU. Issue dissappears if we disable Lunarlake atom cores from BIOS
896+
* and this is beyond xe kmd.
897+
*
898+
* TODO: Drop this change once workqueue scheduling delay issue is fixed on LNL Hybrid CPU.
899+
*/
900+
if (!ret) {
901+
flush_work(&ct->g2h_worker);
902+
if (g2h_fence.done) {
903+
xe_gt_warn(gt, "G2H fence %u, action %04x, done\n",
904+
g2h_fence.seqno, action[0]);
905+
ret = 1;
906+
}
907+
}
908+
891909
/*
892910
* Ensure we serialize with completion side to prevent UAF with fence going out of scope on
893911
* the stack, since we have no clue if it will fire after the timeout before we can erase

0 commit comments

Comments
 (0)