linux-stable.git/include/drm, branch v7.0.13

drm/atomic: track individual colorop updates

2026-06-19T11:47:55+00:00

[ Upstream commit 2e235e2a2784b12b735321e5b42240ca51c49b0f ]

As we do for CRTC color mgmt properties, use color_mgmt_changed flag to
track any value changes in the color pipeline of a given plane, so that
drivers can update color blocks as soon as plane color pipeline or
individual colorop values change. Since we're here, only announce and
track changes to plane COLOR_PIPELINE prop if its value is actually
changing.

Fixes: 8c5ea1745f4c ("drm/colorop: Add BYPASS property")
Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation")
Fixes: 41651f9d42eb ("drm/colorop: Add 1D Curve subtype")
Fixes: 3410108037d5 ("drm/colorop: Add multiplier type")
Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline")
Fixes: e5719e7f1900 ("drm/colorop: Add 3x4 CTM type")
Fixes: 99a4e4f08abe ("drm/colorop: Add 1D Curve Custom LUT type")
Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property")
Reviewed-by: Harry Wentland  #v1
Reviewed-by: Chaitanya Kumar Borah 
Reviewed-by: Alex Hung 
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen 
Signed-off-by: Melissa Wen 
Link: https://patch.msgid.link/20260609110420.1298352-4-mwen@igalia.com
Signed-off-by: Sasha Levin

drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable

2026-06-19T11:47:55+00:00

[ Upstream commit 94ff735296d371045fce163451a3d65e44ac4729 ]

As interpolation props are actually mutable props, any changes should be
handled by drm_colorop_state. Move their enum and make it correctly
behaves as mutable.

Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation")
Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline")
Reviewed-by: Chaitanya Kumar Borah 
Reviewed-by: Alex Hung 
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen 
Signed-off-by: Melissa Wen 
Link: https://patch.msgid.link/20260609110420.1298352-3-mwen@igalia.com
Signed-off-by: Sasha Levin

drm/colorop: Remove read-only comments from interpolation fields

2026-06-19T11:47:55+00:00

[ Upstream commit e480228cf65583040c894bb9cc02e1d5b328cee0 ]

The lut1d_interpolation and lut3d_interpolation fields and their
associated properties were marked as read-only, but userspace
can set them via drm_atomic_colorop_set_property().

Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation")
Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline")
Reviewed-by: Chaitanya Kumar Borah 
Signed-off-by: Alex Hung 
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen 
Signed-off-by: Melissa Wen 
Link: https://patch.msgid.link/20260609110420.1298352-2-mwen@igalia.com
Signed-off-by: Sasha Levin

drm/gem: Make the GEM LRU lock part of drm_device

2026-06-01T15:54:46+00:00

[ Upstream commit 379e8f1ca5e919b130b40d8115d92a536e5f8d7a ]

Recently, a few races have been discovered in the GEM LRU logic, all
of them caused by the fact the LRU lock is accessed through
gem->lru->lock, and that very same lock also protects changes to
gem->lru, leading to situations where gem->lru needs to first be
accessed without the lock held, to then get the lru to access the lock
through and finally take the lock and do the expected operation.

Currently, the only driver making use of this API (MSM) declares a
device-wide lock, and the user we're about to add (panthor) will
do the same. There's no evidence that we will ever have a driver
that wants different pools of LRUs protected by different locks under
the same drm_device. So we're better off moving this lock to drm_device
and always locking it through obj->dev->gem_lru_mutex, or directly
through dev->gem_lru_mutex.

If anyone ever needs more fine-grained locking, this can be revisited
to pass some drm_gem_lru_pool object representing the pool of LRUs
under a specific lock, but for now, the per-device lock seems to be
enough.

Fixes: e7c2af13f811 ("drm/gem: Add LRU/shrinker helper")
Reported-by: Chia-I Wu 
Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86
Reviewed-by: Rob Clark 
Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Reviewed-by: Chia-I Wu 
Link: https://patch.msgid.link/20260518-panthor-shrinker-fixes-v4-1-1920234470d5@collabora.com
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure

2026-05-23T11:09:39+00:00

commit b2ed01e7ad3de80333e9b962a44024b094bc0b2b upstream.

When ttm_tt_swapout() fails, the current code calls
ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail()
to restore the resource's bulk_move membership.

However, ttm_resource_move_to_lru_tail() places the resource at the tail
of the LRU list which, relative to the walk cursor's hitch node (placed
immediately after the resource when it was yielded), puts the resource
*in front of the* the hitch. The next list_for_each_entry_continue() from
the hitch finds the same resource again, causing an infinite loop.

Fix by deferring del_bulk_move to the success path only.

On the success path, TTM_TT_FLAG_SWAPPED has just been set by
ttm_tt_swapout() but the resource is still tracked in the bulk_move range,
so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would
incorrectly skip the removal. Introduce
ttm_resource_del_bulk_move_unevictable() which bypasses that guard.

Reported-by: Jatin Kataria 
Fixes: fc5d96670eb2 ("drm/ttm: Move swapped objects off the manager's LRU list")
Cc: Christian König 
Cc: Matthew Brost 
Cc: 
Cc:  # v6.13+
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Tested-by: Boqun Feng 
Link: https://patch.msgid.link/20260428094442.16985-1-thomas.hellstrom@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

drm/dp: Add definition for Panel Replay full-line granularity

2026-03-04T13:26:08+00:00

DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE
X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line
granularity. Add definition for this.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jouni Högander 
Reviewed-by: Uma Shankar 
Acked-by: Maarten Lankhorst 
Link: https://patch.msgid.link/20260225074221.1744330-1-jouni.hogander@intel.com
(cherry picked from commit b93311673263bb98a200ab1cb6304f969bdada5c)
Signed-off-by: Joonas Lahtinen

drm/pagemap: pass pagemap_addr by reference

2026-02-18T00:39:44+00:00

Passing a structure by value into a function is sometimes problematic,
for a number of reasons. Of of these is a warning from the 32-bit arm
compiler:

drivers/gpu/drm/drm_gpusvm.c: In function '__drm_gpusvm_unmap_pages':
drivers/gpu/drm/drm_gpusvm.c:1152:33: note: parameter passing for argument of type 'struct drm_pagemap_addr' changed in GCC 9.1
 1152 |                                 dpagemap->ops->device_unmap(dpagemap,
      |                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1153 |                                                             dev, *addr);
      |                                                             ~~~~~~~~~~~

This particular problem is harmless since we are not mixing compiler versions
inside of the compiler. However, passing this by reference avoids the warning
along with providing slightly better calling conventions as it avoids an
extra copy on the stack.

Fixes: 75af93b3f5d0 ("drm/pagemap, drm/xe: Support destination migration over interconnect")
Fixes: 2df55d9e66a2 ("drm/xe: Support pcie p2p dma as a fast interconnect")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Thomas Hellström 
Signed-off-by: Thomas Hellström 
Link: https://patch.msgid.link/20260216134644.1025365-1-arnd@kernel.org
Acked-by: Maarten Lankhorst 
(cherry picked from commit 95162db0208aee122d10ac1342fe97a1721cd258)
Signed-off-by: Rodrigo Vivi

BackMerge tag 'v6.19-rc7' into drm-next

2026-01-28T02:44:28+00:00

Linux 6.19-rc7

This is needed for msm and rust trees.

Signed-off-by: Dave Airlie

Merge tag 'drm-misc-next-2026-01-22' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-01-23T02:45:15+00:00

drm-misc-next for 6.20:

Core Changes:
 - buddy: Fix free_trees memory leak, prevent a BUG_ON
 - dma-buf: Start to introduce cgroup memory accounting in heaps, Remove
   sysfs stats, add new tracepoints
 - hdmi: Limit infoframes exposure to userspace based on driver
   capabilities
 - property: Account for property blobs in memcg

Driver Changes:
 - atmel-hlcdc: Switch to drmm resources, Support nomodeset parameter,
   various patches to use newish helpers and fix memory safety bugs
 - hisilicon: Fix various DisplayPort related bugs
 - imagination: Introduce hardware version checks
 - renesas: Fix kernel panic on reboot
 - rockchip: Fix RK3576 HPD interrupt handling, Improve RK3588 HPD
   interrupt handling
 - v3d: Convert to drm logging helpers

 - bridge:
   - Continuation of the refcounting effort
   - new bridge: Algoltek AG6311

 - panel:
   - new panel: Anbernic RG-DS

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patch.msgid.link/20260122-antique-sexy-junglefowl-1bc5a8@houat

drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE

2026-01-22T09:41:18+00:00

CONFIG_DEVICE_PRIVATE is not selected by default by some distros,
for example Fedora, and that leads to a regression in the xe driver
since userptr support gets compiled out.

It turns out that DRM_GPUSVM, which is needed for xe userptr support
compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile
without CONFIG_ZONE_DEVICE.
Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE,
and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and
the xe driver's selection of it, re-enabling xe userptr for those configs.

v2:
- Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set.
- Adjust the drm_pagemap.h header accordingly.

Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm")
Cc: Matthew Auld 
Cc: Himal Prasad Ghimiray 
Cc: Thomas Hellström 
Cc: Matthew Brost 
Cc: "Thomas Hellström" 
Cc: Rodrigo Vivi 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.18+
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
Acked-by: Maarten Lankhorst 
Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com
(cherry picked from commit 1e372b246199ca7a35f930177fea91b557dac16e)
Signed-off-by: Thomas Hellström