Skip to content

Commit e515272

Browse files
bnilawarmbrost05
authored andcommitted
drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout
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 <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Matthew Auld <[email protected]> Cc: John Harrison <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Acked-by: Matthew Brost <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
1 parent 76eb09c commit e515272

File tree

1 file changed

+18
-0
lines changed

1 file changed

+18
-0
lines changed

drivers/gpu/drm/xe/xe_guc_ct.c

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

10191019
ret = wait_event_timeout(ct->g2h_fence_wq, g2h_fence.done, HZ);
10201020

1021+
/*
1022+
* Occasionally it is seen that the G2H worker starts running after a delay of more than
1023+
* a second even after being queued and activated by the Linux workqueue subsystem. This
1024+
* leads to G2H timeout error. The root cause of issue lies with scheduling latency of
1025+
* Lunarlake Hybrid CPU. Issue dissappears if we disable Lunarlake atom cores from BIOS
1026+
* and this is beyond xe kmd.
1027+
*
1028+
* TODO: Drop this change once workqueue scheduling delay issue is fixed on LNL Hybrid CPU.
1029+
*/
1030+
if (!ret) {
1031+
flush_work(&ct->g2h_worker);
1032+
if (g2h_fence.done) {
1033+
xe_gt_warn(gt, "G2H fence %u, action %04x, done\n",
1034+
g2h_fence.seqno, action[0]);
1035+
ret = 1;
1036+
}
1037+
}
1038+
10211039
/*
10221040
* Ensure we serialize with completion side to prevent UAF with fence going out of scope on
10231041
* the stack, since we have no clue if it will fire after the timeout before we can erase

0 commit comments

Comments
 (0)