✓ CI.checkpatch: success for drm/xe/guc_pc: Retry and wait longer for GuC PC start

[Patchwork]

== Series Details ==

Series: drm/xe/guc_pc: Retry and wait longer for GuC PC start
URL   : https://patchwork.freedesktop.org/series/145954/
State : success

== 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
cbb4e4a079d89106c2736adc3c7de6f9dc56da07
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 71e3fa4702e06dbde0e28eadd8e9e164c7dc9267
Author: Rodrigo Vivi <rodrigo.vivi at intel.com>
Date:   Thu Mar 6 18:39:06 2025 -0500

    drm/xe/guc_pc: Retry and wait longer for GuC PC start
    
    In a rare situation of thermal limit during resume, GuC can
    be slow and run into delays like this:
    
    xe 0000:00:02.0: [drm] GT1: excessive init time: 667ms! \
                     [status = 0x8002F034, timeouts = 0]
    xe 0000:00:02.0: [drm] GT1: excessive init time: \
                     [freq = 100MHz (req = 800MHz), before = 100MHz, \
                     perf_limit_reasons = 0x1C001000]
    xe 0000:00:02.0: [drm] *ERROR* GT1: GuC PC Start failed
    ------------[ cut here ]------------
    xe 0000:00:02.0: [drm] GT1: Failed to start GuC PC: -EIO
    
    When this happens, it will block entirely the GPU to be used.
    So, let's try and with a huge timeout in the hope it comes back.
    
    Also, let's collect some information on how long it is usually
    taking on situations like this, so perhaps the time can be tuned
    later.
    
    Cc: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
    Cc: Jonathan Cavitt <jonathan.cavitt at intel.com>
    Cc: John Harrison <John.C.Harrison at Intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
+ /mt/dim checkpatch 9796125d0726448924abdb8c73077c7486e3dd3d drm-intel
71e3fa4702e0 drm/xe/guc_pc: Retry and wait longer for GuC PC start