<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm, branch linux-6.6.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.6.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.6.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-04T12:21:20Z</updated>
<entry>
<title>drm/i915/wakeref: clean up INTEL_WAKEREF_PUT_* flag macros</title>
<updated>2026-03-04T12:21:20Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2025-12-15T12:09:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=18845fb30921dc2bacbbb2ad6113d5fd4d0ceb17'/>
<id>urn:sha1:18845fb30921dc2bacbbb2ad6113d5fd4d0ceb17</id>
<content type='text'>
[ Upstream commit 524696a19e34598c9173fdd5b32fb7e5d16a91d3 ]

Commit 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently
discarded") started emitting warnings for cases that were previously
silently discarded. One such case is in intel_wakeref.h:

Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype
  for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC()
  instead

Arguably kernel-doc should be able to handle this, as it's valid C, but
having the flags defined between the function declarator and the body is
just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from
there, making kernel-doc's life easier.

While at it, reduce the unnecessary abstraction levels by removing the
enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity.

Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Tested-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://patch.msgid.link/20251215120908.3515578-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()</title>
<updated>2026-03-04T12:21:15Z</updated>
<author>
<name>Sunday Clement</name>
<email>Sunday.Clement@amd.com</email>
</author>
<published>2026-02-02T17:41:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4857c37c7ba9aa38b9a4c694e8bd8d0091c87940'/>
<id>urn:sha1:4857c37c7ba9aa38b9a4c694e8bd8d0091c87940</id>
<content type='text'>
[ Upstream commit 8a70a26c9f34baea6c3199a9862ddaff4554a96d ]

The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8
bytes via memset without checking the buffer size parameter. This allows
unprivileged userspace to trigger an out-of bounds kernel memory write
by passing a small buffer, leading to  potential privilege
escalation.

Signed-off-by: Sunday Clement &lt;Sunday.Clement@amd.com&gt;
Reviewed-by: Alexander Deucher &lt;Alexander.Deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Remove conditional for shaper 3DLUT power-on</title>
<updated>2026-03-04T12:20:58Z</updated>
<author>
<name>Alex Hung</name>
<email>alex.hung@amd.com</email>
</author>
<published>2026-02-05T05:05:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=61bd8787c605914475bf65bca8c798010e2f13be'/>
<id>urn:sha1:61bd8787c605914475bf65bca8c798010e2f13be</id>
<content type='text'>
[ Upstream commit 1b38a87b8f8020e8ef4563e7752a64182b5a39b9 ]

[Why]
Shaper programming has high chance to fail on first time after
power-on or reboot. This can be verified by running IGT's kms_colorop.

[How]
Always power on the shaper and 3DLUT before programming by
removing the debug flag of low power mode.

Reviewed-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Ray Wu &lt;ray.wu@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/radeon: Add HAINAN clock adjustment</title>
<updated>2026-03-04T12:20:57Z</updated>
<author>
<name>decce6</name>
<email>decce6@proton.me</email>
</author>
<published>2026-02-10T07:26:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6a997eb806446610c6b8c3fbf2cd796407c1cf55'/>
<id>urn:sha1:6a997eb806446610c6b8c3fbf2cd796407c1cf55</id>
<content type='text'>
[ Upstream commit 908d318f23d6b5d625bea093c5fc056238cdb7ff ]

This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from
850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This
patch is for radeon.

Signed-off-by: decce6 &lt;decce6@proton.me&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Add HAINAN clock adjustment</title>
<updated>2026-03-04T12:20:57Z</updated>
<author>
<name>decce6</name>
<email>decce6@proton.me</email>
</author>
<published>2026-02-10T07:24:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5b9af0342402c964ec3a1032c05a29cfee564e1d'/>
<id>urn:sha1:5b9af0342402c964ec3a1032c05a29cfee564e1d</id>
<content type='text'>
[ Upstream commit 49fe2c57bdc0acff9d2551ae337270b6fd8119d9 ]

This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from
850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This
patch is for amdgpu.

Signed-off-by: decce6 &lt;decce6@proton.me&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Adjust usleep_range in fence wait</title>
<updated>2026-03-04T12:20:57Z</updated>
<author>
<name>Ce Sun</name>
<email>cesun102@amd.com</email>
</author>
<published>2026-02-10T07:32:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d2e92247b24a8e0f1675deee3d522c3ea22b8db6'/>
<id>urn:sha1:d2e92247b24a8e0f1675deee3d522c3ea22b8db6</id>
<content type='text'>
[ Upstream commit 3ee1c72606bd2842f0f377fd4b118362af0323ae ]

Tune the sleep interval in the PSP fence wait loop from 10-100us to
60-100us.This adjustment results in an overall wait window of 1.2s
(60us * 20000 iterations) to 2 seconds (100us * 20000 iterations),
which guarantees that we can retrieve the correct fence value

Signed-off-by: Ce Sun &lt;cesun102@amd.com&gt;
Reviewed-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Avoid updating surface with the same surface under MPO</title>
<updated>2026-03-04T12:20:57Z</updated>
<author>
<name>Wayne Lin</name>
<email>Wayne.Lin@amd.com</email>
</author>
<published>2026-01-23T06:47:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=068dee782c8c069c11ee7d4d25581f8d7d89c3d4'/>
<id>urn:sha1:068dee782c8c069c11ee7d4d25581f8d7d89c3d4</id>
<content type='text'>
[ Upstream commit 1a38ded4bc8ac09fd029ec656b1e2c98cc0d238c ]

[Why &amp; How]
Although it's dummy updates of surface update for committing stream
updates, we should not have dummy_updates[j].surface all indicating
to the same surface under multiple surfaces case. Otherwise,
copy_surface_update_to_plane() in update_planes_and_stream_state()
will update to the same surface only.

Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Signed-off-by: Tom Chung &lt;chiahsuan.chung@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release</title>
<updated>2026-03-04T12:20:41Z</updated>
<author>
<name>Ludovic Desroches</name>
<email>ludovic.desroches@microchip.com</email>
</author>
<published>2025-10-24T16:14:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ac2d898da5095d46bd1ff8585fdd753d58ad91e7'/>
<id>urn:sha1:ac2d898da5095d46bd1ff8585fdd753d58ad91e7</id>
<content type='text'>
[ Upstream commit bc847787233277a337788568e90a6ee1557595eb ]

The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying
the atmel_hlcdc_plane state structure without properly duplicating the
drm_plane_state. In particular, state-&gt;commit remained set to the old
state commit, which can lead to a use-after-free in the next
drm_atomic_commit() call.

Fix this by calling
__drm_atomic_helper_duplicate_plane_state(), which correctly clones
the base drm_plane_state (including the -&gt;commit pointer).

It has been seen when closing and re-opening the device node while
another DRM client (e.g. fbdev) is still attached:

=============================================================================
BUG kmalloc-64 (Not tainted): Poison overwritten
-----------------------------------------------------------------------------

0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b
FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b
Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0
pid=29
 drm_atomic_helper_setup_commit+0x1e8/0x7bc
 drm_atomic_helper_commit+0x3c/0x15c
 drm_atomic_commit+0xc0/0xf4
 drm_framebuffer_remove+0x4cc/0x5a8
 drm_mode_rmfb_work_fn+0x6c/0x80
 process_one_work+0x12c/0x2cc
 worker_thread+0x2a8/0x400
 kthread+0xc0/0xdc
 ret_from_fork+0x14/0x28
Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0
pid=169
 drm_atomic_helper_commit_hw_done+0x100/0x150
 drm_atomic_helper_commit_tail+0x64/0x8c
 commit_tail+0x168/0x18c
 drm_atomic_helper_commit+0x138/0x15c
 drm_atomic_commit+0xc0/0xf4
 drm_atomic_helper_set_config+0x84/0xb8
 drm_mode_setcrtc+0x32c/0x810
 drm_ioctl+0x20c/0x488
 sys_ioctl+0x14c/0xc20
 ret_fast_syscall+0x0/0x54
Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0
flags=0x200(workingset|zone=0)
Object 0xc611b340 @offset=832 fp=0xc611b7c0

Signed-off-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Reviewed-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130dc3@microchip.com
Signed-off-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts</title>
<updated>2026-03-04T12:20:41Z</updated>
<author>
<name>Ludovic Desroches</name>
<email>ludovic.desroches@microchip.com</email>
</author>
<published>2025-11-20T10:38:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80b8b0df370fe056d4d66bcf33aa5c30d204bf0c'/>
<id>urn:sha1:80b8b0df370fe056d4d66bcf33aa5c30d204bf0c</id>
<content type='text'>
[ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ]

Don’t reject the commit when the source rectangle has fractional parts.
This can occur due to scaling: drm_atomic_helper_check_plane_state() calls
drm_rect_clip_scaled(), which may introduce fractional parts while
computing the clipped source rectangle. This does not imply the commit is
invalid, so we should accept it instead of discarding it.

Signed-off-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Reviewed-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@microchip.com
Signed-off-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback</title>
<updated>2026-03-04T12:20:41Z</updated>
<author>
<name>Ludovic Desroches</name>
<email>ludovic.desroches@microchip.com</email>
</author>
<published>2025-10-24T16:14:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ec40702029b08ee8d5f5b03303d64a10e74a957b'/>
<id>urn:sha1:ec40702029b08ee8d5f5b03303d64a10e74a957b</id>
<content type='text'>
[ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ]

After several commits, the slab memory increases. Some drm_crtc_commit
objects are not freed. The atomic_destroy_state callback only put the
framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function
to put all the objects that are no longer needed.

It has been seen after hours of usage of a graphics application or using
kmemleak:

unreferenced object 0xc63a6580 (size 64):
  comm "egt_basic", pid 171, jiffies 4294940784
  hex dump (first 32 bytes):
    40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6  @P4..........e:.
    8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6  .e:......e:..e:.
  backtrace (crc c25aa925):
    kmemleak_alloc+0x34/0x3c
    __kmalloc_cache_noprof+0x150/0x1a4
    drm_atomic_helper_setup_commit+0x1e8/0x7bc
    drm_atomic_helper_commit+0x3c/0x15c
    drm_atomic_commit+0xc0/0xf4
    drm_atomic_helper_set_config+0x84/0xb8
    drm_mode_setcrtc+0x32c/0x810
    drm_ioctl+0x20c/0x488
    sys_ioctl+0x14c/0xc20
    ret_fast_syscall+0x0/0x54

Signed-off-by: Ludovic Desroches &lt;ludovic.desroches@microchip.com&gt;
Reviewed-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com
Signed-off-by: Manikandan Muralidharan &lt;manikandan.m@microchip.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
