[Intel-xe] ✓ CI.checkpatch: success for drm/xe: fix mem_access for early lrc generation

[Patchwork]

== Series Details ==

Series: drm/xe: fix mem_access for early lrc generation
URL   : https://patchwork.freedesktop.org/series/126882/
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
63c2b6b160bca2df6efc7bc4cea6f442097d7854
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 89abb50977a8aca80b35ed57d3aafc219e0ff5b5
Author: Matthew Auld <matthew.auld at intel.com>
Date:   Fri Nov 24 17:08:31 2023 +0000

    drm/xe: fix mem_access for early lrc generation
    
    We spawn some hw queues during device probe to generate the default LRC
    for every engine type, however the queue destruction step is typically
    async. Queue destruction needs to do stuff like GuC context deregister
    which requires GuC CT, which in turn requires an active mem_access ref.
    The caller during probe is meant to hold the mem_access token, however
    due to the async destruction it might have already been dropped if we
    are unlucky.
    
    Similar to how we already handle migrate VMs for which there is no
    mem_access ref, fix this by keeping the callers token alive, releasing
    it only when destroying the queue. We can treat a NULL vm as indication
    that we need to grab our own extra ref.
    
    Signed-off-by: Matthew Auld <matthew.auld at intel.com>
    Cc: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
    Cc: Matthew Brost <matthew.brost at intel.com>
+ /mt/dim checkpatch 1832821c7e4c5bd24353183f060f1435b2eb7992 drm-intel
89abb5097 drm/xe: fix mem_access for early lrc generation