<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu/drm/amd, branch v7.2-rc6</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>drm/amd/display: Exit idle optimizations before programming</title>
<updated>2026-07-29T22:21:24+00:00</updated>
<author>
<name>Leo Li</name>
<email>sunpeng.li@amd.com</email>
</author>
<published>2026-07-28T17:02:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8419331e64d92a8de5fc4feef0e305f201fb8b33'/>
<id>8419331e64d92a8de5fc4feef0e305f201fb8b33</id>
<content type='text'>
[Why]

We need to exit PSR/IPS before programming. Before calling DC for
programming in amdgpu_dm_commit_planes(), there's a
vblank_control_workqueue flush. This waits for IPS and PSR exit. (See
drm_vblank_on/off() &gt; amdgpu_dm_crtc_set_vblank() --queue_work()-&gt;
amdgpu_dm_crtc_vblank_control_worker())

Prior to the tagged "Fixes:" change, drm_vblank_get() was called before
the workqueue flush. This ordering ensures that PSR exit occurred before
programming. After the "Fixes:" change, drm_vblank_get() is called after
the workqueue flush, leading to programming while idle optimizations are
still active. This can lead to incorrect flip_pending detection used by
vblank event delivery.

[How]

Split the vblank_get() component of `dm_arm_vblank_event()` into
`dm_arm_vblank_event_pre_programming()`, which is called before
programming. Call it before the vblank_control_workqueue flush.

Includes a drive-by cleanup of prepare_flip_isr(): the only caller is
dm_arm_vblank_event() and it's simple enough to roll-in.

v2: Fix checkpatch formatting warning on
    drm_arm_vblank_event_pre_programming() arg alignment.

Fixes: 48ab86360af1 ("drm/amd/display: check GRPH_FLIP status before sending event")
Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141#note_3583205
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5527
Assisted-by: Codex:gpt-5.6-sol
Assisted-by: Claude:opus-5
Suggested-by: David Weber &lt;weber.aulendorf@gmail.com&gt;
Signed-off-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Mario Limonciello (AMD) &lt;superm1@kernel.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 05984e29520a28c27f5a2388742c957a6a87ee7a)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Why]

We need to exit PSR/IPS before programming. Before calling DC for
programming in amdgpu_dm_commit_planes(), there's a
vblank_control_workqueue flush. This waits for IPS and PSR exit. (See
drm_vblank_on/off() &gt; amdgpu_dm_crtc_set_vblank() --queue_work()-&gt;
amdgpu_dm_crtc_vblank_control_worker())

Prior to the tagged "Fixes:" change, drm_vblank_get() was called before
the workqueue flush. This ordering ensures that PSR exit occurred before
programming. After the "Fixes:" change, drm_vblank_get() is called after
the workqueue flush, leading to programming while idle optimizations are
still active. This can lead to incorrect flip_pending detection used by
vblank event delivery.

[How]

Split the vblank_get() component of `dm_arm_vblank_event()` into
`dm_arm_vblank_event_pre_programming()`, which is called before
programming. Call it before the vblank_control_workqueue flush.

Includes a drive-by cleanup of prepare_flip_isr(): the only caller is
dm_arm_vblank_event() and it's simple enough to roll-in.

v2: Fix checkpatch formatting warning on
    drm_arm_vblank_event_pre_programming() arg alignment.

Fixes: 48ab86360af1 ("drm/amd/display: check GRPH_FLIP status before sending event")
Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141#note_3583205
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5527
Assisted-by: Codex:gpt-5.6-sol
Assisted-by: Claude:opus-5
Suggested-by: David Weber &lt;weber.aulendorf@gmail.com&gt;
Signed-off-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Mario Limonciello (AMD) &lt;superm1@kernel.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 05984e29520a28c27f5a2388742c957a6a87ee7a)
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/pm: hide pp_table sysfs on APUs</title>
<updated>2026-07-29T22:20:29+00:00</updated>
<author>
<name>Yang Wang</name>
<email>kevinyang.wang@amd.com</email>
</author>
<published>2026-07-29T07:56:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a65f5179d3f0c93da31b450aeb416eaa22f1912b'/>
<id>a65f5179d3f0c93da31b450aeb416eaa22f1912b</id>
<content type='text'>
APUs use firmware-owned DPM tables and do not support replacement through
pp_table. Generic callbacks can nevertheless expose the sysfs file and
accept an upload before resetting the power management stack.

Treat pp_table as unsupported on APUs. Use the same platform check in the
get and set paths to hide the file and reject uploads.

Fixes: 289921b03fe5 ("drm/amd/powerplay: implement sysfs of pp_table for smu11 (v2)")
Signed-off-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Reviewed-by: Kenneth Feng &lt;kenneth.feng@amd.com&gt;
Reviewed-by: Asad Kamal &lt;asad.kamal@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 74f28db2db69777cd2f059d50fe34e365ddd5add)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
APUs use firmware-owned DPM tables and do not support replacement through
pp_table. Generic callbacks can nevertheless expose the sysfs file and
accept an upload before resetting the power management stack.

Treat pp_table as unsupported on APUs. Use the same platform check in the
get and set paths to hide the file and reject uploads.

Fixes: 289921b03fe5 ("drm/amd/powerplay: implement sysfs of pp_table for smu11 (v2)")
Signed-off-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Reviewed-by: Kenneth Feng &lt;kenneth.feng@amd.com&gt;
Reviewed-by: Asad Kamal &lt;asad.kamal@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 74f28db2db69777cd2f059d50fe34e365ddd5add)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: use proper context for logging</title>
<updated>2026-07-29T00:01:24+00:00</updated>
<author>
<name>Jiri Slaby (SUSE)</name>
<email>jirislaby@kernel.org</email>
</author>
<published>2026-07-23T04:25:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=114b42507b6a23d9d24e24e4ef165233332c64d4'/>
<id>114b42507b6a23d9d24e24e4ef165233332c64d4</id>
<content type='text'>
The same as the rest of the code, get_ss_info_from_atombios() uses
calc_pll_cs-&gt;ctx-&gt;logger for logging. But calc_pll_cs-&gt;ctx is
initialized only later in calc_pll_max_vco_construct(). Therefore, any
output using DC_LOG_SYNC() leads to a NULL pointer deference in
get_ss_info_from_atombios().

According to Sashiko, the very same problem exists in
dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too.

To avoid accessing the NULL context, use clk_src-&gt;base.ctx-&gt;logger
everywhere. That context in base is initialized earlier in
dce110_clk_src_construct() and dce112_clk_src_construct(). Before
get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions
above are actually called. This is done by redefining DC_LOGGER to
CTX-&gt;logger.

Before:
dce110_clk_src_construct() did:
 -&gt; sets clk_src-&gt;base.ctx = ctx;
 -&gt; ss_info_from_atombios_create()
   -&gt; get_ss_info_from_atombios()   &lt;- uses calc_pll_cs-&gt;ctx  # BOOM
 -&gt; calc_pll_max_vco_construct()    &lt;- sets calc_pll_cs-&gt;ctx

After:
dce110_clk_src_construct() does:
 -&gt; sets clk_src-&gt;base.ctx = ctx;
 -&gt; ss_info_from_atombios_create()
   -&gt; get_ss_info_from_atombios()   &lt;- uses clk_src-&gt;base.ctx

Closes: https://bugzilla.suse.com/show_bug.cgi?id=1271175
Closes: https://lore.kernel.org/all/a9ee54e6-2413-4156-9bde-d528ae3c63a3@kernel.org/
Fixes: 1296423bf23c ("drm/amd/display: define DC_LOGGER for logger")
Reviewed-by: Bhawanpreet Lakha &lt;bhawanpreet.lakha@amd.com&gt;
Signed-off-by: Jiri Slaby (SUSE) &lt;jirislaby@kernel.org&gt;
Cc: Lakha, Bhawanpreet &lt;Bhawanpreet.Lakha@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Leo Li &lt;sunpeng.li@amd.com&gt;
Cc: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Christian König" &lt;christian.koenig@amd.com&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Simona Vetter &lt;simona@ffwll.ch&gt;
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The same as the rest of the code, get_ss_info_from_atombios() uses
calc_pll_cs-&gt;ctx-&gt;logger for logging. But calc_pll_cs-&gt;ctx is
initialized only later in calc_pll_max_vco_construct(). Therefore, any
output using DC_LOG_SYNC() leads to a NULL pointer deference in
get_ss_info_from_atombios().

According to Sashiko, the very same problem exists in
dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too.

To avoid accessing the NULL context, use clk_src-&gt;base.ctx-&gt;logger
everywhere. That context in base is initialized earlier in
dce110_clk_src_construct() and dce112_clk_src_construct(). Before
get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions
above are actually called. This is done by redefining DC_LOGGER to
CTX-&gt;logger.

Before:
dce110_clk_src_construct() did:
 -&gt; sets clk_src-&gt;base.ctx = ctx;
 -&gt; ss_info_from_atombios_create()
   -&gt; get_ss_info_from_atombios()   &lt;- uses calc_pll_cs-&gt;ctx  # BOOM
 -&gt; calc_pll_max_vco_construct()    &lt;- sets calc_pll_cs-&gt;ctx

After:
dce110_clk_src_construct() does:
 -&gt; sets clk_src-&gt;base.ctx = ctx;
 -&gt; ss_info_from_atombios_create()
   -&gt; get_ss_info_from_atombios()   &lt;- uses clk_src-&gt;base.ctx

Closes: https://bugzilla.suse.com/show_bug.cgi?id=1271175
Closes: https://lore.kernel.org/all/a9ee54e6-2413-4156-9bde-d528ae3c63a3@kernel.org/
Fixes: 1296423bf23c ("drm/amd/display: define DC_LOGGER for logger")
Reviewed-by: Bhawanpreet Lakha &lt;bhawanpreet.lakha@amd.com&gt;
Signed-off-by: Jiri Slaby (SUSE) &lt;jirislaby@kernel.org&gt;
Cc: Lakha, Bhawanpreet &lt;Bhawanpreet.Lakha@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Leo Li &lt;sunpeng.li@amd.com&gt;
Cc: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Christian König" &lt;christian.koenig@amd.com&gt;
Cc: David Airlie &lt;airlied@gmail.com&gt;
Cc: Simona Vetter &lt;simona@ffwll.ch&gt;
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: cap GTT size to physical RAM on APUs</title>
<updated>2026-07-29T00:01:16+00:00</updated>
<author>
<name>Harkirat Gill</name>
<email>harkirat.gill@amd.com</email>
</author>
<published>2026-07-27T18:37:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5e70f6804b4d6256058c360b10e044ee04ea4a4e'/>
<id>5e70f6804b4d6256058c360b10e044ee04ea4a4e</id>
<content type='text'>
On APUs, the GTT pool is backed by system RAM, but its size is not bound
to the non-carveout memory that actually backs it. A user can end up
with GTT + VRAM exceeding total physical memory through the following
sequence:

 - Have a large non-carveout memory space (~128GB) and accordingly set a
   large GTT (~100GB) via the ttm module parameter.
 - Lower the non-carveout memory space in BIOS by increasing the UMA
   Frame Buffer Size (VRAM) to 64GB.
 - The previously set GTT value (~100GB) persists, even though the new
   non-carveout space (64GB) can no longer back it.

This leads to a case where kernel reports GTT (100GB) + VRAM (64GB)
despite the sum being greater than total physical memory (128GB).

Cap the GTT size to totalram_pages() on APUs. totalram_pages() already
excludes the VRAM carveout, so the resulting GTT can never exceed the
system RAM that actually backs it.

Signed-off-by: Harkirat Gill &lt;harkirat.gill@amd.com&gt;
Reviewed-by: David Francis &lt;David.Francis@amd.com&gt;
Assisted-by: Claude:claude-opus-4
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 5dafdd649280c7dc6c22c8f877da3f54fcc441e1)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On APUs, the GTT pool is backed by system RAM, but its size is not bound
to the non-carveout memory that actually backs it. A user can end up
with GTT + VRAM exceeding total physical memory through the following
sequence:

 - Have a large non-carveout memory space (~128GB) and accordingly set a
   large GTT (~100GB) via the ttm module parameter.
 - Lower the non-carveout memory space in BIOS by increasing the UMA
   Frame Buffer Size (VRAM) to 64GB.
 - The previously set GTT value (~100GB) persists, even though the new
   non-carveout space (64GB) can no longer back it.

This leads to a case where kernel reports GTT (100GB) + VRAM (64GB)
despite the sum being greater than total physical memory (128GB).

Cap the GTT size to totalram_pages() on APUs. totalram_pages() already
excludes the VRAM carveout, so the resulting GTT can never exceed the
system RAM that actually backs it.

Signed-off-by: Harkirat Gill &lt;harkirat.gill@amd.com&gt;
Reviewed-by: David Francis &lt;David.Francis@amd.com&gt;
Assisted-by: Claude:claude-opus-4
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 5dafdd649280c7dc6c22c8f877da3f54fcc441e1)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/pm: use milliwatts for GPU power sensors</title>
<updated>2026-07-29T00:01:06+00:00</updated>
<author>
<name>Yang Wang</name>
<email>kevinyang.wang@amd.com</email>
</author>
<published>2026-07-27T04:23:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1849a64165ccc23d3e5fc22b8be19227c21c1871'/>
<id>1849a64165ccc23d3e5fc22b8be19227c21c1871</id>
<content type='text'>
GPU average and input power backends report a mix of whole watts,
milliwatts, Q24.8 watts and decimal-packed fractions. Q24.8 is inherited
from the legacy PowerPlay sensor format. Milliwatts are a more natural unit
for the hwmon and pm_info consumers in amdgpu_pm.c. A common decoder cannot
distinguish these formats, and converting native milliwatts through Q24.8
also loses precision.

Use milliwatts as the internal unit across all PPT and PowerPlay backends.
Decode Q24.8 only at the legacy smu7 input boundary and encode it only for
the raw amdgpu_sensors debugfs interface. This gives hwmon, pm_info and the
sensor ioctl one unambiguous unit while preserving the format used by UMR.

Fixes: 5b79d0482f3c ("drm/amd/pp: Remove struct pp_gpu_power")
Fixes: 01992b121fb6 ("drm/amd/pm: fix amdgpu_pm_info power display units")
Signed-off-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Reviewed-by: Kenneth Feng &lt;kenneth.feng@amd.com&gt;
Reported-by: Lars Nieradzik &lt;l.nieradzik@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 757ba0790bafec47a507e9662bf380f2e027d420)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
GPU average and input power backends report a mix of whole watts,
milliwatts, Q24.8 watts and decimal-packed fractions. Q24.8 is inherited
from the legacy PowerPlay sensor format. Milliwatts are a more natural unit
for the hwmon and pm_info consumers in amdgpu_pm.c. A common decoder cannot
distinguish these formats, and converting native milliwatts through Q24.8
also loses precision.

Use milliwatts as the internal unit across all PPT and PowerPlay backends.
Decode Q24.8 only at the legacy smu7 input boundary and encode it only for
the raw amdgpu_sensors debugfs interface. This gives hwmon, pm_info and the
sensor ioctl one unambiguous unit while preserving the format used by UMR.

Fixes: 5b79d0482f3c ("drm/amd/pp: Remove struct pp_gpu_power")
Fixes: 01992b121fb6 ("drm/amd/pm: fix amdgpu_pm_info power display units")
Signed-off-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Reviewed-by: Kenneth Feng &lt;kenneth.feng@amd.com&gt;
Reported-by: Lars Nieradzik &lt;l.nieradzik@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 757ba0790bafec47a507e9662bf380f2e027d420)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: restore UMD profile pstate after runtime resume</title>
<updated>2026-07-29T00:00:49+00:00</updated>
<author>
<name>Candice Li</name>
<email>candice.li@amd.com</email>
</author>
<published>2026-07-21T13:38:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f931c54b241ce2f36bfc34955aec43a188276b8d'/>
<id>f931c54b241ce2f36bfc34955aec43a188276b8d</id>
<content type='text'>
Runtime suspend runs GFX hw_fini and clears perfmon clock gating while
the UMD profile DPM level remains set in software.  Re-apply stable
pstate after a successful runtime resume when a profile mode is active.

Signed-off-by: Candice Li &lt;candice.li@amd.com&gt;
Reviewed-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Reviewed-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 138531c8850cc247aa12b104bb29ea387bcdcbb1)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Runtime suspend runs GFX hw_fini and clears perfmon clock gating while
the UMD profile DPM level remains set in software.  Re-apply stable
pstate after a successful runtime resume when a profile mode is active.

Signed-off-by: Candice Li &lt;candice.li@amd.com&gt;
Reviewed-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Reviewed-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 138531c8850cc247aa12b104bb29ea387bcdcbb1)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Silence link_dpms I2C retimer failures</title>
<updated>2026-07-29T00:00:42+00:00</updated>
<author>
<name>Alan Swanson</name>
<email>reiver@improbability.net</email>
</author>
<published>2026-07-27T16:01:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8ccb87b1c9be594fc2c36b0a4006a66f08dee1c8'/>
<id>8ccb87b1c9be594fc2c36b0a4006a66f08dee1c8</id>
<content type='text'>
Commit a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C")
had also changed the "Set retimer failed" messages from DC_LOG_DEBUG()
to DC_LOG_ERROR(). This unfortunately can create log spam.

Change those back to DC_LOG_DEBUG() only.

Fixes: a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5520
Signed-off-by: Alan Swanson &lt;reiver@improbability.net&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit da8609eef18b0a3490d0e1fa9440659fadc8194d)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C")
had also changed the "Set retimer failed" messages from DC_LOG_DEBUG()
to DC_LOG_ERROR(). This unfortunately can create log spam.

Change those back to DC_LOG_DEBUG() only.

Fixes: a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5520
Signed-off-by: Alan Swanson &lt;reiver@improbability.net&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit da8609eef18b0a3490d0e1fa9440659fadc8194d)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdkfd: hold event_mutex while checkpointing CRIU events</title>
<updated>2026-07-29T00:00:35+00:00</updated>
<author>
<name>William Palacek</name>
<email>William.Palacek@amd.com</email>
</author>
<published>2026-07-22T15:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ff8bc5a68a9a70bdc38d61a72c7a49c56063f9d2'/>
<id>ff8bc5a68a9a70bdc38d61a72c7a49c56063f9d2</id>
<content type='text'>
kfd_criu_checkpoint_events() counts the entries in p-&gt;event_idr via
kfd_get_num_events(), allocates an array sized to that count, and then
walks the same IDR to fill it. Neither the count nor the walk holds
p-&gt;event_mutex.

The CRIU checkpoint caller holds only p-&gt;mutex. Event create and destroy
(kfd_event_create()/kfd_event_destroy()) take p-&gt;event_mutex and do not
take p-&gt;mutex, so a second thread in the same process can insert or remove
events between the count and the walk. If an event is inserted, the walk
iterates more entries than were counted and writes past the end of the
ev_privs allocation; if an event is removed, the walk dereferences an
entry that is being freed.

Hold p-&gt;event_mutex across the count and the walk so both observe a
consistent view of p-&gt;event_idr. The lock is released before
copy_to_user(), which only touches the local buffer. The caller already
holds p-&gt;mutex and the create/destroy paths never take p-&gt;mutex, so the
p-&gt;mutex -&gt; p-&gt;event_mutex order is not inverted and no deadlock is
introduced.

Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events")
Signed-off-by: William Palacek &lt;William.Palacek@amd.com&gt;
Reviewed-by: Alysa Liu &lt;Alysa.Liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kfd_criu_checkpoint_events() counts the entries in p-&gt;event_idr via
kfd_get_num_events(), allocates an array sized to that count, and then
walks the same IDR to fill it. Neither the count nor the walk holds
p-&gt;event_mutex.

The CRIU checkpoint caller holds only p-&gt;mutex. Event create and destroy
(kfd_event_create()/kfd_event_destroy()) take p-&gt;event_mutex and do not
take p-&gt;mutex, so a second thread in the same process can insert or remove
events between the count and the walk. If an event is inserted, the walk
iterates more entries than were counted and writes past the end of the
ev_privs allocation; if an event is removed, the walk dereferences an
entry that is being freed.

Hold p-&gt;event_mutex across the count and the walk so both observe a
consistent view of p-&gt;event_idr. The lock is released before
copy_to_user(), which only touches the local buffer. The caller already
holds p-&gt;mutex and the create/destroy paths never take p-&gt;mutex, so the
p-&gt;mutex -&gt; p-&gt;event_mutex order is not inverted and no deadlock is
introduced.

Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events")
Signed-off-by: William Palacek &lt;William.Palacek@amd.com&gt;
Reviewed-by: Alysa Liu &lt;Alysa.Liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: check if dml21_add_phantom_plane() is successful</title>
<updated>2026-07-29T00:00:28+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2026-02-16T14:32:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=000acb4ce7fb9feba3072ce468ad681f6585cd5d'/>
<id>000acb4ce7fb9feba3072ce468ad681f6585cd5d</id>
<content type='text'>
Verify that the phantom plane was allocated to avoid a later
segfault.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4970
Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources")
Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Signed-off-by: Fangzhi Zuo &lt;jerry.zuo@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Verify that the phantom plane was allocated to avoid a later
segfault.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4970
Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources")
Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Signed-off-by: Fangzhi Zuo &lt;jerry.zuo@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport</title>
<updated>2026-07-29T00:00:20+00:00</updated>
<author>
<name>George Zhang</name>
<email>george.zhang@amd.com</email>
</author>
<published>2026-07-16T21:00:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f327e389c07cfc3a2f6ff54f6214e1a52d457edc'/>
<id>f327e389c07cfc3a2f6ff54f6214e1a52d457edc</id>
<content type='text'>
If a plane reaches calculate_mcache_setting with a zero-area viewport,
calculate_mcache_setting exits early with num_mcaches == 0 and
mvmpg_width/height == 0. This will cause a divide-by-zero panic and can
also cause an underflow on num_mcaches.

Fix this by changing calculate_mcache_setting to bool and adding guards
after each calculate_mcache_row_bytes call. If num_mcaches or
mvmpg_width/height is zero, return a false. Callers will propagate the
failure as a rejected mode, which prevents the panic.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5302
Reviewed-by: Sun peng (Leo) Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Signed-off-by: George Zhang &lt;george.zhang@amd.com&gt;
Signed-off-by: Fangzhi Zuo &lt;jerry.zuo@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da)
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a plane reaches calculate_mcache_setting with a zero-area viewport,
calculate_mcache_setting exits early with num_mcaches == 0 and
mvmpg_width/height == 0. This will cause a divide-by-zero panic and can
also cause an underflow on num_mcaches.

Fix this by changing calculate_mcache_setting to bool and adding guards
after each calculate_mcache_row_bytes call. If num_mcaches or
mvmpg_width/height is zero, return a false. Callers will propagate the
failure as a rejected mode, which prevents the panic.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5302
Reviewed-by: Sun peng (Leo) Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Signed-off-by: George Zhang &lt;george.zhang@amd.com&gt;
Signed-off-by: Fangzhi Zuo &lt;jerry.zuo@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da)
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
</feed>
