<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/drm, branch v7.1.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/ttm/pool: back up at native page order</title>
<updated>2026-08-03T09:25:45+00:00</updated>
<author>
<name>Matthew Brost</name>
<email>matthew.brost@intel.com</email>
</author>
<published>2026-07-16T20:13:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=921d6acd57613c0a9585fc7e6283601f4e8c7df5'/>
<id>921d6acd57613c0a9585fc7e6283601f4e8c7df5</id>
<content type='text'>
commit a3fdf74ffa5966e5b4a17f1e9c5687f73bb0d536 upstream.

ttm_pool_split_for_swap() unconditionally splits high-order pool pages
into order-0 pages before backup, so every compound the shrinker
touches is shattered even when the rest of the system would prefer it
stay intact. Under sustained kswapd pressure this fragments memory
enough to drive other parts of MM into recovery loops.

Back up each compound at its native order instead. In
ttm_pool_backup(), hand the full compound to the new
ttm_backup_backup_folio(), which backs up subpages to a contiguous
range of shmem indices and returns the base handle plus the number of
subpages actually backed up (@nr_backed). On full success, free the
compound once at its native order -- no split_page(), no per-4K
refcount juggling.

A per-folio backup can't be made fully atomic under memory pressure:
ttm_backup_backup_folio() must allocate shmem folios before source
subpages can be released, so under true OOM any subpage may fail
while the rest of the compound is still live. Two mechanisms handle
this without regressing reclaim behaviour:

  - alloc_gfp gets __GFP_NOMEMALLOC whenever order &gt; 0 (cleared again
    for order-0), so a high-order backup fails fast with -ENOMEM
    instead of draining kernel reserves, leaving them for other
    allocations under the same pressure.

  - If ttm_backup_backup_folio() still returns a short @nr_backed with
    a valid handle for the successfully-backed prefix, split the
    source compound with ttm_pool_split_for_swap(), free the prefix as
    order-0 pages (already safely in shmem), and retry the remaining
    subpages at order 0, where __GFP_NOMEMALLOC is cleared and
    reserves may be used as a last resort.

This preserves the original split-on-OOM fallback while keeping the
common case fragmentation-free, and preserves the "partial backup is
allowed" contract (shrunken is incremented per subpage backed up).

The restore-side leftover-page split in ttm_pool_restore_commit() is
left as-is: it's unreachable in practice and not worth complicating
the restore state machine to avoid.

Testing: the existing backup_fault_inject point only truncated
tt-&gt;num_pages, which never exercised the reactive split path above
since it never left a compound partially backed up. Wire fault
injection into ttm_backup_backup_folio() itself: past the first
subpage of a compound, synthesize a -ENOMEM in place of
shmem_read_folio_gfp() when should_fail() trips, producing the same
short @nr_pages_backed a real failure would and forcing
ttm_pool_backup() through the split-and-retry path. The fault_attr
stays private to ttm_pool.c; ttm_backup.c reaches it through
ttm_backup_fault_inject_folio(), declared in ttm_pool_internal.h.

While converting the writeback branch to operate on the whole folio,
the unlock condition after shmem_writeout() also changed from `if
(ret)` to `if (ret == AOP_WRITEPAGE_ACTIVATE)`, matching the actual
contract: shmem_writeout()/swap_writeout() only leave the folio locked
when returning AOP_WRITEPAGE_ACTIVATE; any other return (including a
hard error from arch_prepare_to_swap()) means the folio was already
unlocked internally. The old `if (ret)` check would have double-
unlocked in that hard-error case.

Cc: Christian Koenig &lt;christian.koenig@amd.com&gt;
Cc: Huang Rui &lt;ray.huang@amd.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Simona Vetter &lt;simona@ffwll.ch&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages")
Suggested-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Reviewed-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Link: https://patch.msgid.link/20260716201358.4086085-1-matthew.brost@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a3fdf74ffa5966e5b4a17f1e9c5687f73bb0d536 upstream.

ttm_pool_split_for_swap() unconditionally splits high-order pool pages
into order-0 pages before backup, so every compound the shrinker
touches is shattered even when the rest of the system would prefer it
stay intact. Under sustained kswapd pressure this fragments memory
enough to drive other parts of MM into recovery loops.

Back up each compound at its native order instead. In
ttm_pool_backup(), hand the full compound to the new
ttm_backup_backup_folio(), which backs up subpages to a contiguous
range of shmem indices and returns the base handle plus the number of
subpages actually backed up (@nr_backed). On full success, free the
compound once at its native order -- no split_page(), no per-4K
refcount juggling.

A per-folio backup can't be made fully atomic under memory pressure:
ttm_backup_backup_folio() must allocate shmem folios before source
subpages can be released, so under true OOM any subpage may fail
while the rest of the compound is still live. Two mechanisms handle
this without regressing reclaim behaviour:

  - alloc_gfp gets __GFP_NOMEMALLOC whenever order &gt; 0 (cleared again
    for order-0), so a high-order backup fails fast with -ENOMEM
    instead of draining kernel reserves, leaving them for other
    allocations under the same pressure.

  - If ttm_backup_backup_folio() still returns a short @nr_backed with
    a valid handle for the successfully-backed prefix, split the
    source compound with ttm_pool_split_for_swap(), free the prefix as
    order-0 pages (already safely in shmem), and retry the remaining
    subpages at order 0, where __GFP_NOMEMALLOC is cleared and
    reserves may be used as a last resort.

This preserves the original split-on-OOM fallback while keeping the
common case fragmentation-free, and preserves the "partial backup is
allowed" contract (shrunken is incremented per subpage backed up).

The restore-side leftover-page split in ttm_pool_restore_commit() is
left as-is: it's unreachable in practice and not worth complicating
the restore state machine to avoid.

Testing: the existing backup_fault_inject point only truncated
tt-&gt;num_pages, which never exercised the reactive split path above
since it never left a compound partially backed up. Wire fault
injection into ttm_backup_backup_folio() itself: past the first
subpage of a compound, synthesize a -ENOMEM in place of
shmem_read_folio_gfp() when should_fail() trips, producing the same
short @nr_pages_backed a real failure would and forcing
ttm_pool_backup() through the split-and-retry path. The fault_attr
stays private to ttm_pool.c; ttm_backup.c reaches it through
ttm_backup_fault_inject_folio(), declared in ttm_pool_internal.h.

While converting the writeback branch to operate on the whole folio,
the unlock condition after shmem_writeout() also changed from `if
(ret)` to `if (ret == AOP_WRITEPAGE_ACTIVATE)`, matching the actual
contract: shmem_writeout()/swap_writeout() only leave the folio locked
when returning AOP_WRITEPAGE_ACTIVATE; any other return (including a
hard error from arch_prepare_to_swap()) means the folio was already
unlocked internally. The old `if (ret)` check would have double-
unlocked in that hard-error case.

Cc: Christian Koenig &lt;christian.koenig@amd.com&gt;
Cc: Huang Rui &lt;ray.huang@amd.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: Maxime Ripard &lt;mripard@kernel.org&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Simona Vetter &lt;simona@ffwll.ch&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages")
Suggested-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Reviewed-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Link: https://patch.msgid.link/20260716201358.4086085-1-matthew.brost@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05</title>
<updated>2026-08-03T09:25:45+00:00</updated>
<author>
<name>Alessandro Rinaldi</name>
<email>ale@alerinaldi.it</email>
</author>
<published>2026-06-26T14:36:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3665fc7f93f1096dcb771a0f758bccafec04e742'/>
<id>3665fc7f93f1096dcb771a0f758bccafec04e742</id>
<content type='text'>
commit bad177fa75e607e396cd57daaaed881450d7a471 upstream.

The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that
advertises AUX/DPCD backlight control, so amdgpu's automatic detection
(amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight
path has no effect: brightness writes are accepted but the panel level
never changes, the display is stuck at a fixed brightness and
max_brightness is reported as a bogus 511000. As a result neither the
desktop brightness slider nor the brightness hotkeys do anything.

Forcing PWM backlight (amdgpu.backlight=0) restores working control:
max_brightness becomes 65535 and the level tracks writes. This has long
been applied by users as a manual kernel-parameter workaround.

Extend the generic panel backlight quirk with a force_pwm flag, add an
entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu
disable AUX backlight (use PWM) when the quirk matches and the user
lets the driver auto-select the backlight type.

Signed-off-by: Alessandro Rinaldi &lt;ale@alerinaldi.it&gt;
Tested-by: Alessandro Rinaldi &lt;ale@alerinaldi.it&gt;
Reviewed-by: George Zhang &lt;george.zhang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bad177fa75e607e396cd57daaaed881450d7a471 upstream.

The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that
advertises AUX/DPCD backlight control, so amdgpu's automatic detection
(amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight
path has no effect: brightness writes are accepted but the panel level
never changes, the display is stuck at a fixed brightness and
max_brightness is reported as a bogus 511000. As a result neither the
desktop brightness slider nor the brightness hotkeys do anything.

Forcing PWM backlight (amdgpu.backlight=0) restores working control:
max_brightness becomes 65535 and the level tracks writes. This has long
been applied by users as a manual kernel-parameter workaround.

Extend the generic panel backlight quirk with a force_pwm flag, add an
entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu
disable AUX backlight (use PWM) when the quirk matches and the user
lets the driver auto-select the backlight type.

Signed-off-by: Alessandro Rinaldi &lt;ale@alerinaldi.it&gt;
Tested-by: Alessandro Rinaldi &lt;ale@alerinaldi.it&gt;
Reviewed-by: George Zhang &lt;george.zhang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/displayid: fix Tiled Display Topology ID size</title>
<updated>2026-08-03T09:25:40+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-10T14:15:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bcd40ea7788f642eaf68c9539c73dc27f18a9e88'/>
<id>bcd40ea7788f642eaf68c9539c73dc27f18a9e88</id>
<content type='text'>
commit 90c0486a82e27393f9eaf3bb350f51a0bd38cb6b upstream.

The Tiled Display Topology ID of a DisplayID Tiled Display Topology Data
Block consists of three fields:

- Tiled Display Manufacturer/Vendor ID Field (3 bytes)
- Tiled Display Product ID Code Field (2 bytes)
- Tiled Display Serial Number Field (4 bytes)

i.e. a total of 9 bytes, not 8.

The DisplayID Tiled Display Topology ID is used as the tile group
identifier.

Update both struct displayid_tiled_block topology_id member and struct
drm_tile_group group_data member to full 9 bytes.

The group data was missing the last byte of the serial number. I don't
know whether there are known bug reports that might be linked to this,
but it's plausible the last byte could be the differentiating part for
the tile groups, and fewer tile groups might have been created than
intended.

Fixes: b49b55bd4fba ("drm/displayid: add displayid defines and edid extension (v2)")
Fixes: 138f9ebb9755 ("drm: add tile_group support. (v3)")
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: stable@vger.kernel.org # v3.19+
Reviewed-by: Dave Airlie &lt;airlied@redhat.com&gt;
Link: https://patch.msgid.link/20260610141549.555605-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 90c0486a82e27393f9eaf3bb350f51a0bd38cb6b upstream.

The Tiled Display Topology ID of a DisplayID Tiled Display Topology Data
Block consists of three fields:

- Tiled Display Manufacturer/Vendor ID Field (3 bytes)
- Tiled Display Product ID Code Field (2 bytes)
- Tiled Display Serial Number Field (4 bytes)

i.e. a total of 9 bytes, not 8.

The DisplayID Tiled Display Topology ID is used as the tile group
identifier.

Update both struct displayid_tiled_block topology_id member and struct
drm_tile_group group_data member to full 9 bytes.

The group data was missing the last byte of the serial number. I don't
know whether there are known bug reports that might be linked to this,
but it's plausible the last byte could be the differentiating part for
the tile groups, and fewer tile groups might have been created than
intended.

Fixes: b49b55bd4fba ("drm/displayid: add displayid defines and edid extension (v2)")
Fixes: 138f9ebb9755 ("drm: add tile_group support. (v3)")
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: stable@vger.kernel.org # v3.19+
Reviewed-by: Dave Airlie &lt;airlied@redhat.com&gt;
Link: https://patch.msgid.link/20260610141549.555605-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2026-06-12' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes</title>
<updated>2026-06-12T21:52:40+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2026-06-12T21:50:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7c62657a10625e4e113de248d41f543d5a2f3a1a'/>
<id>7c62657a10625e4e113de248d41f543d5a2f3a1a</id>
<content type='text'>
Short summary of fixes pull:

amd:
- track colorop changes correctly

amdxdna:
- fix possible leak of mm_struct

colorop:
- make lut interpolation mutable
- track colorop updates correctly

ivpu:
- fix integer truncation

vc4:
- fix leak in krealloc() error handling

virtio:
- fix dma_fence ref-count leak

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260612081418.GA17001@2a02-2455-9062-2500-e496-5a17-62ba-545e.dyn6.pyur.net
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Short summary of fixes pull:

amd:
- track colorop changes correctly

amdxdna:
- fix possible leak of mm_struct

colorop:
- make lut interpolation mutable
- track colorop updates correctly

ivpu:
- fix integer truncation

vc4:
- fix leak in krealloc() error handling

virtio:
- fix dma_fence ref-count leak

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260612081418.GA17001@2a02-2455-9062-2500-e496-5a17-62ba-545e.dyn6.pyur.net
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/atomic: track individual colorop updates</title>
<updated>2026-06-10T10:13:36+00:00</updated>
<author>
<name>Melissa Wen</name>
<email>mwen@igalia.com</email>
</author>
<published>2026-06-09T10:20:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2e235e2a2784b12b735321e5b42240ca51c49b0f'/>
<id>2e235e2a2784b12b735321e5b42240ca51c49b0f</id>
<content type='text'>
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 &lt;harry.wentland@amd.com&gt; #v1
Reviewed-by: Chaitanya Kumar Borah &lt;chaitanya.kumar.borah@intel.com&gt;
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-4-mwen@igalia.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;harry.wentland@amd.com&gt; #v1
Reviewed-by: Chaitanya Kumar Borah &lt;chaitanya.kumar.borah@intel.com&gt;
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-4-mwen@igalia.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable</title>
<updated>2026-06-10T10:13:35+00:00</updated>
<author>
<name>Melissa Wen</name>
<email>mwen@igalia.com</email>
</author>
<published>2026-06-09T10:20:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94ff735296d371045fce163451a3d65e44ac4729'/>
<id>94ff735296d371045fce163451a3d65e44ac4729</id>
<content type='text'>
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 &lt;chaitanya.kumar.borah@intel.com&gt;
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-3-mwen@igalia.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;chaitanya.kumar.borah@intel.com&gt;
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-3-mwen@igalia.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/colorop: Remove read-only comments from interpolation fields</title>
<updated>2026-06-10T10:13:34+00:00</updated>
<author>
<name>Alex Hung</name>
<email>alex.hung@amd.com</email>
</author>
<published>2026-06-09T10:20:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e480228cf65583040c894bb9cc02e1d5b328cee0'/>
<id>e480228cf65583040c894bb9cc02e1d5b328cee0</id>
<content type='text'>
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 &lt;chaitanya.kumar.borah@intel.com&gt;
Signed-off-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-2-mwen@igalia.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;chaitanya.kumar.borah@intel.com&gt;
Signed-off-by: Alex Hung &lt;alex.hung@amd.com&gt;
Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block")
Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patch.msgid.link/20260609110420.1298352-2-mwen@igalia.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2026-05-21' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes</title>
<updated>2026-05-21T21:01:04+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2026-05-21T21:00:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=71d9e1561aab0a506f6c783a6c3e16042fd27dff'/>
<id>71d9e1561aab0a506f6c783a6c3e16042fd27dff</id>
<content type='text'>
Short summary of fixes pull:

amdxdna:
- remove mmap and export for ubuf

bridge:
- chipone-icn6211: managed bridge cleanup
- lt66121: acquire reset GPIO
- megachips: fix clean up on failed IRQ requests

gem:
- clean up LRU locking

v3d:
- fix UAF in error code paths
- release GEM-object ref on free'd jobs

virtio:
- use uninterruptible resv locking in plane updates

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260521071456.GA14644@localhost.localdomain
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Short summary of fixes pull:

amdxdna:
- remove mmap and export for ubuf

bridge:
- chipone-icn6211: managed bridge cleanup
- lt66121: acquire reset GPIO
- megachips: fix clean up on failed IRQ requests

gem:
- clean up LRU locking

v3d:
- fix UAF in error code paths
- release GEM-object ref on free'd jobs

virtio:
- use uninterruptible resv locking in plane updates

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260521071456.GA14644@localhost.localdomain
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/gem: Make the GEM LRU lock part of drm_device</title>
<updated>2026-05-18T13:16:47+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@collabora.com</email>
</author>
<published>2026-05-18T11:41:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=379e8f1ca5e919b130b40d8115d92a536e5f8d7a'/>
<id>379e8f1ca5e919b130b40d8115d92a536e5f8d7a</id>
<content type='text'>
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-&gt;lru-&gt;lock, and that very same lock also protects changes to
gem-&gt;lru, leading to situations where gem-&gt;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-&gt;dev-&gt;gem_lru_mutex, or directly
through dev-&gt;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 &lt;olvaffe@gmail.com&gt;
Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86
Reviewed-by: Rob Clark &lt;rob.clark@oss.qualcomm.com&gt;
Reviewed-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
Reviewed-by: Steven Price &lt;steven.price@arm.com&gt;
Reviewed-by: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Link: https://patch.msgid.link/20260518-panthor-shrinker-fixes-v4-1-1920234470d5@collabora.com
Signed-off-by: Boris Brezillon &lt;boris.brezillon@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;lru-&gt;lock, and that very same lock also protects changes to
gem-&gt;lru, leading to situations where gem-&gt;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-&gt;dev-&gt;gem_lru_mutex, or directly
through dev-&gt;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 &lt;olvaffe@gmail.com&gt;
Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86
Reviewed-by: Rob Clark &lt;rob.clark@oss.qualcomm.com&gt;
Reviewed-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
Reviewed-by: Steven Price &lt;steven.price@arm.com&gt;
Reviewed-by: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Link: https://patch.msgid.link/20260518-panthor-shrinker-fixes-v4-1-1920234470d5@collabora.com
Signed-off-by: Boris Brezillon &lt;boris.brezillon@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2026-05-15' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes</title>
<updated>2026-05-15T21:56:32+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2026-05-15T21:55:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=396db75a1f7fb7b34b0b6101e3802bc418c4e868'/>
<id>396db75a1f7fb7b34b0b6101e3802bc418c4e868</id>
<content type='text'>
Short summary of fixes pull:

bridge:
- imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup

gma500:
- oaktrail_lvds: fix i2c handling

loongson:
- use managed cleanup for connector polling

panfrost:
- handle results from reservation locking correctly

qaic:
- check for integer overflows in mmap logic

rocket:
- handle results from reservation locking correctly

ttm:
- avoid infinite loop in swap out
- avoid infinite loop in BO shrinking
- convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260515070816.GA88575@2a02-2455-9062-2500-7dec-552d-233d-9fe0.dyn6.pyur.net
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Short summary of fixes pull:

bridge:
- imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup

gma500:
- oaktrail_lvds: fix i2c handling

loongson:
- use managed cleanup for connector polling

panfrost:
- handle results from reservation locking correctly

qaic:
- check for integer overflows in mmap logic

rocket:
- handle results from reservation locking correctly

ttm:
- avoid infinite loop in swap out
- avoid infinite loop in BO shrinking
- convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patch.msgid.link/20260515070816.GA88575@2a02-2455-9062-2500-7dec-552d-233d-9fe0.dyn6.pyur.net
</pre>
</div>
</content>
</entry>
</feed>
