linux-stable.git/drivers/gpu, branch v6.18.49

drm/xe/guc_ads: use uncached mapping for UM queue BO

2026-09-02T12:31:46+00:00

commit 8d5134ae4177fa4f5a9bc8e71e6656cfc2852882 upstream.

On Pre-Xe3p platform, the GAM write the UM queue through DPA using UC.
if GuC reads the queue via GGTT (WB), stale data may be observed
when the cacheline has been polluted by another agent.

To match the GAM's UC writes, configure the GuC mapping as UC as well.

Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun 
Cc: Matthew Auld 
Cc:  # v6.12+
Signed-off-by: Jia Yao 
Reviewed by: Matthew Auld 
Signed-off-by: Matthew Auld 
Link: https://patch.msgid.link/20260804165057.129529-4-jia.yao@intel.com
(cherry picked from commit 8d5134ae4177fa4f5a9bc8e71e6656cfc2852882)
Signed-off-by: Thomas Hellström 
Signed-off-by: Sasha Levin

drm/xe/guc_ads: allocate UM queues in VRAM on dGFX

2026-09-02T12:31:46+00:00

commit f342810a141f8a7e8b3786a6e4b6c0695a078a74 upstream.

On iGPU, the UM queue BO is allocated in system memory. On dGFX, the BO
was previously created in system memory and later reallocated in
xe_guc_realloc_post_hwconfig().  Allocate the UM queue BO directly in
VRAM on dGFX, where it is ultimately required.

Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun 
Cc: Matthew Auld 
Cc:  # v6.12+
Signed-off-by: Jia Yao 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
Link: https://patch.msgid.link/20260804165057.129529-3-jia.yao@intel.com
(cherry picked from commit f342810a141f8a7e8b3786a6e4b6c0695a078a74)
Signed-off-by: Thomas Hellström 
Signed-off-by: Sasha Levin

drm/xe/guc_ads: allocate UM queues in a separate BO

2026-09-02T12:31:46+00:00

commit 99b01815957bd7d848420cb697f79ed11f7f215c upstream.

Move the UM queues into a dedicated BO (ads->um_queue_bo) and avoid
CPU memset operations on it, which eliminates the CPU as a potential
cacheline-polluting agent and helps maintain consistency between GAM
writes and GuC reads.

We also need to ensure the base_dpa for the queue is contiguous on hw
where this is used instead of a GGTT address. Another good reason to
split this out to a separate BO.

Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun 
Cc: Matthew Auld 
Cc:  # v6.12+
Signed-off-by: Jia Yao 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
Link: https://patch.msgid.link/20260804165057.129529-2-jia.yao@intel.com
(cherry picked from commit 99b01815957bd7d848420cb697f79ed11f7f215c)
Signed-off-by: Thomas Hellström 
Signed-off-by: Sasha Levin

drm/xe: Fix DPT allocation paths.

2026-08-27T12:32:51+00:00

commit fc648757908304aedbad74f74bf58192aec383db upstream.

Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.

On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.

Using stolen may also result in random system hangs under load.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc:  # v6.12+
Reviewed-by: Matthew Auld 
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst 
Acked-by: Matthew Brost  #teams
(cherry picked from commit a196406a3831291598fe8e73245914f7acffdfe0)
Signed-off-by: Thomas Hellström 
[ adapted `pin_params->alignment` to `alignment` and renamed `XE_BO_FLAG_FORCE_WC` to `XE_BO_FLAG_SCANOUT` for the pre-rename flag name ]
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Set surface-framebuffer GEM objects

2026-08-23T12:27:10+00:00

commit 9942d36a73c2d46c52fdd6f37cf698f3cb09ce5c upstream.

Set struct drm_framebuffer.obj[0] to the allocated GEM buffer object
for surface framebuffers. Avoids a NULL-pointer deref in the client's
vmap helpers.

[   22.640191] Console: switching to colour frame buffer device 160x50
[   22.641788] Oops: general protection fault, probably for
  non-canonical address 0xdffffc000000001f: 0000 [#1] SMP KASAN NOPTI
[   22.641795] KASAN: null-ptr-deref in range
[0x00000000000000f8-0x00000000000000ff]
[...]
[   22.641809] Hardware name: VMware, Inc. VMware20,1/440BX Desktop
  Reference Platform, BIOS VMW201.00V.24928539.B64.2508260915 08/26/2025
[   22.641812] Workqueue: events drm_fb_helper_damage_work
[   22.641824] RIP: 0010:drm_gem_lock+0x25/0x50
[   22.641831] Code: 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 b8
  00 00 00 00 00 fc ff df 53 48 89 fb 48 81 c7 f8 00 00 00 48 89 fa 48
  c1 ea 03 <80> 3c 02 00 75 0f 48 8b bb f8 00 00 00 31 f6 5b e9 16 2e 15
  01 e8
[...]
[   22.641889] Call Trace:
[   22.641891]  
[   22.641894]  drm_client_buffer_vmap_local+0x78/0x140
[   22.641903]  drm_fbdev_ttm_helper_fb_dirty+0x20c/0x510 [drm_ttm_helper]
[   22.641913]  ? __pfx_drm_fbdev_ttm_helper_fb_dirty+0x10/0x10 [drm_ttm_helper]
[   22.641918]  ? __raw_spin_lock_irqsave+0x8c/0xf0
[   22.641924]  ? __pfx___raw_spin_lock_irqsave+0x10/0x10
[   22.641928]  ? __pfx_mutex_lock+0x10/0x10
[   22.641936]  drm_fb_helper_fb_dirty+0x29a/0x5e0
[   22.641942]  ? __pfx_drm_fb_helper_fb_dirty+0x10/0x10
[...]

Signed-off-by: Thomas Zimmermann 
Fixes: ea39f2e66e61 ("drm/client: Deprecate struct drm_client_buffer.gem")
Reported-by: Ian Forbes 
Closes: https://lore.kernel.org/dri-devel/CAO6MGtjg8PiRiSLomJQRBduTBSC0WkqX67tEZwA9qwOgRzchpw@mail.gmail.com/
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Simona Vetter 
Cc: dri-devel@lists.freedesktop.org
Tested-by: Ian Forbes 
Reviewed-by: Jocelyn Falempe 
Reviewed-by: Zack Rusin 
Link: https://patch.msgid.link/20251104103611.167821-1-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman

drm/log: Fix infinite loop when scale is too large for display

2026-08-23T12:27:10+00:00

[ Upstream commit f4f2bba28df9b9aaa00262a462139dbbcdc38d9f ]

When scale is large enough that scaled_font exceeds the display
dimensions, rows or columns become 0. A columns value of 0 causes
an infinite loop in drm_log_draw_kmsg_record() because the loop
never decrements len.

Check for zero rows/columns in drm_log_setup_modeset() and return
an error, cleaning up the already allocated buffer to avoid a leak.

Fixes: 8a4b913df427 ("drm/log: Add integer scaling support")
Signed-off-by: Shixiong Ou 
Reviewed-by: Jocelyn Falempe 
Link: https://patch.msgid.link/20260729084815.692944-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe 
Signed-off-by: Sasha Levin

drm/client: Remove drm_client_framebuffer_delete()

2026-08-23T12:27:09+00:00

[ Upstream commit 3e3153325fd3693d0f9fe235c4afbcd68ef102e1 ]

Release client buffers with drm_client_buffer_delete() instead of
drm_client_framebuffer_delete(). The latter is just a tiny wrapper
around the former.

Move the test for !buffer into drm_client_buffer_delete(), although
all callers appear to always have a valid pointer.

v2:
- test for !buffer before deref-ing pointer (Jocelyn, Dan)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Tested-by: Francesco Valla 
Link: https://patch.msgid.link/20251027121042.143588-6-tzimmermann@suse.de
Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display")
Signed-off-by: Sasha Levin

drm/client: Deprecate struct drm_client_buffer.gem

2026-08-23T12:27:09+00:00

[ Upstream commit ea39f2e66e61035e203530977a3df428345d03e2 ]

The client buffer's framebuffer holds a reference and pointer on
each of its GEM buffer objects. Thus the field gem in the client-
buffer struct is not necessary. Deprecated the field and convert
the client-buffer helpers to use the framebuffer's objects.

In drm_client_buffer_delete(), do a possible vunmap before releasing
the framebuffer. Otherwise we'd eventually release the framebuffer
before unmaping its buffer objects.

v2:
- avoid dependency on CONFIG_DRM_KMS_HELPER

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Tested-by: Francesco Valla 
Link: https://patch.msgid.link/20251027121042.143588-5-tzimmermann@suse.de
Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display")
Signed-off-by: Sasha Levin

drm/client: Inline drm_client_buffer_addfb() and _rmfb()

2026-08-23T12:27:09+00:00

[ Upstream commit 7cc0f6171b9f93da2815d95d4410f14583cba58f ]

Creating and deleting a client buffer always creates and deletes
the underlying DRM framebuffer. Inline the helper functions into
their callers.

With the _addfb code being inlined into drm_client_buffer_create(),
clean up the function's error rollback to release the framebuffer's
handle and GEM buffer object as needed.

Move the _rmfb code into drm_client_buffer_delete() rather than its
current location in drm_client_framebuffer_delete(). The former is
now the inverse of drm_client_buffer_create(). Makes no difference
for cleaning up. Also prepares for the removal of
drm_client_framebuffer_delete().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Tested-by: Francesco Valla 
Link: https://patch.msgid.link/20251027121042.143588-4-tzimmermann@suse.de
Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display")
Signed-off-by: Sasha Levin

drm/client: Move dumb-buffer handling to drm_client_framebuffer_create()

2026-08-23T12:27:09+00:00

[ Upstream commit 2d262a483c7a128e50cdb64a0ec20c6d78df66cc ]

Dumb-buffer creation within the client code is asymetrically balanced
across drm_client_buffer_create() and drm_client_framebuffer_create().
Put all dumb-buffer code into drm_client_framebuffer_create() and leave
client-buffer initialization to drm_client_buffer_create(). Clarifies
responsibility between these functions.

Apart form the architectural improvements, drm_client_buffer_create()
can now be exported if needed by clients. The client will be able to
initialize buffers that have been created from other interfaces than
dumb buffers.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Tested-by: Francesco Valla 
Link: https://patch.msgid.link/20251027121042.143588-3-tzimmermann@suse.de
Stable-dep-of: f4f2bba28df9 ("drm/log: Fix infinite loop when scale is too large for display")
Signed-off-by: Sasha Levin