✗ CI.checkpatch: warning for drm/xe: diagnostics and workaround for GuC TLB invalidation ack stalls on ARL (rev2)

== Series Details ==

Series: drm/xe: diagnostics and workaround for GuC TLB invalidation ack stalls on ARL (rev2)
URL   : https://patchwork.freedesktop.org/series/171539/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
061140b9bc586ae7f40abc1249c97e1cc72d1b9d
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 34edb36f8f11bba53549e0a81459f317a6fac286
Author: Tales A. Mendonça <[email protected]>
Date:   Mon Aug 3 23:14:41 2026 -0300

    drm/xe: Kick GuC while TLB invalidation acks are overdue
    
    On ARL with GuC 70.53.0, TLB invalidation acks intermittently stall:
    the H2G request is consumed from the CTB immediately, but the G2H ack
    only arrives ~2.3s later, tens of milliseconds after the fence timeout
    has fired. During the stall the GPU keeps rendering; only work blocked
    on the invalidation (e.g. Wayland compositors performing buffer
    unmaps) hitches for the full 2.3s. Observed on three machines so far
    (7d51, 7dd1, plus an Arc Pro 130T report), see Link.
    
    Experiments ruled out the obvious suspects:
    
     * GT C6 parking: holding forcewake across the whole GT (C6 residency
       pinned at 0ms) still produced 9 timeouts in a row.
     * Lost interrupt/CT processing on the host: the G2H CTB is empty at
       timeout time; the ack genuinely has not been sent by the firmware.
    
    What does help is poking the GuC while the ack is overdue. Add a
    delayed work that fires XE_TLB_INVAL_KICK_DELAY_MS after an
    invalidation is issued and, while any ack is pending, re-reads the GuC
    status register, flushes the CT fast-path and rings the GuC doorbell
    (xe_guc_notify()), re-arming itself until the ack arrives; the
    existing TDR still bounds the total wait.
    
    Instrumented results from two ARL machines over several days:
    
     * Without kicks: every stall lasts the full ~2.3s and is reported as
       a fence timeout (-ETIME), ~1/hour on a desktop workload.
     * With kicks: the majority of stalls resolve 15-276ms after one of
       the kicks, e.g.:
    
         TLB invalidation ack after kick: seqno=36405 recv=36405, request-to-ack=528ms, last-kick-to-ack=15ms, kicks=2
    
     * A minority of severe episodes ignore 8-9 consecutive doorbells and
       still run to the timeout (worst observed: ack 5996ms after request,
       3.7s after the last kick), suggesting the firmware is internally
       blocked for the whole window rather than missing a wake event.
    
    This is a workaround, not a fix - the root cause looks like a GuC
    firmware issue - but it turns a guaranteed 2.3s stall into a sub-500ms
    hiccup for most occurrences, and the "ack after kick" log documents
    the firmware behavior for further debugging.
    
    Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678
    Signed-off-by: Tales A. Mendonça <[email protected]>
+ /mt/dim checkpatch 4c13a67db118ee0019231dbc1362bcb8115ac660 drm-intel
cc6ee7dbdd9a drm/xe: Capture devcoredump on TLB invalidation timeout
d5341199c3eb drm/xe: Log when a timed out TLB invalidation ack finally arrives
-:24: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#24: 
  TLB invalidation late ack: seqno=10992 recv=10992, request-to-ack=2314ms, timeout-to-ack=45ms

total: 0 errors, 1 warnings, 0 checks, 57 lines checked
34edb36f8f11 drm/xe: Kick GuC while TLB invalidation acks are overdue
-:38: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#38: 
     TLB invalidation ack after kick: seqno=36405 recv=36405, request-to-ack=528ms, last-kick-to-ack=15ms, kicks=2

total: 0 errors, 1 warnings, 0 checks, 194 lines checked