<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu.h, branch v6.18.21</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>drm/amd/display: Add an hdmi_hpd_debounce_delay_ms module</title>
<updated>2026-02-26T22:59:47+00:00</updated>
<author>
<name>Ivan Lipski</name>
<email>ivan.lipski@amd.com</email>
</author>
<published>2026-01-13T22:29:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a488528a7182b62d55b0c9a67358f04d089500e0'/>
<id>a488528a7182b62d55b0c9a67358f04d089500e0</id>
<content type='text'>
commit 6a681cd9034587fe3550868bacfbd639d1c6891f upstream.

[Why&amp;How]
Right now, the HDMI HPD filter is enabled by default at 1500ms.

We want to disable it by default, as most modern displays with HDMI do
not require it for DPMS mode.

The HPD can instead be enabled as a driver parameter with a custom delay
value in ms (up to 5000ms).

Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Reviewed-by: Mario Limonciello (AMD) &lt;superm1@kernel.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.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 6a681cd9034587fe3550868bacfbd639d1c6891f upstream.

[Why&amp;How]
Right now, the HDMI HPD filter is enabled by default at 1500ms.

We want to disable it by default, as most modern displays with HDMI do
not require it for DPMS mode.

The HPD can instead be enabled as a driver parameter with a custom delay
value in ms (up to 5000ms).

Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Reviewed-by: Mario Limonciello (AMD) &lt;superm1@kernel.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: block CE CS if not explicitely allowed by module option</title>
<updated>2025-10-13T18:14:14+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2025-09-22T12:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8f74c70be57527d7b79e2ecf6de1a154d148254d'/>
<id>8f74c70be57527d7b79e2ecf6de1a154d148254d</id>
<content type='text'>
The Constant Engine found on gfx6-gfx10 HW has been a notorious source of
problems.

RADV never used it in the first place, radeonsi only used it for a few
releases around 2017 for gfx6-gfx9 before dropping support for it as
well.

While investigating another problem I just recently found that submitting
to the CE seems to be completely broken on gfx9 for quite a while.

Since nobody complained about that problem it most likely means that
nobody is using any of the affected radeonsi versions on current Linux
kernels any more.

So to potentially phase out the support for the CE and eliminate another
source of problems block submitting CE IBs unless it is enabled again
using a debug flag.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Constant Engine found on gfx6-gfx10 HW has been a notorious source of
problems.

RADV never used it in the first place, radeonsi only used it for a few
releases around 2017 for gfx6-gfx9 before dropping support for it as
well.

While investigating another problem I just recently found that submitting
to the CE seems to be completely broken on gfx9 for quite a while.

Since nobody complained about that problem it most likely means that
nobody is using any of the affected radeonsi versions on current Linux
kernels any more.

So to potentially phase out the support for the CE and eliminate another
source of problems block submitting CE IBs unless it is enabled again
using a debug flag.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: Add generic capability class</title>
<updated>2025-09-15T20:55:41+00:00</updated>
<author>
<name>Lijo Lazar</name>
<email>lijo.lazar@amd.com</email>
</author>
<published>2025-09-04T12:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1f9ba8ea04efa0e4366eac2d2ebf2deff167bf14'/>
<id>1f9ba8ea04efa0e4366eac2d2ebf2deff167bf14</id>
<content type='text'>
Define a utility macro for defining capabilities and their attributes.
Capability attributes are read-only, write-only, read-write.

Signed-off-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Acked-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Define a utility macro for defining capabilities and their attributes.
Capability attributes are read-only, write-only, read-write.

Signed-off-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Acked-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/pm: Remove unneeded legacy DPM related code.</title>
<updated>2025-09-15T20:52:50+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2025-09-09T14:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=156db7d353286b7bfd7f43f548a4046a97fe67c6'/>
<id>156db7d353286b7bfd7f43f548a4046a97fe67c6</id>
<content type='text'>
This code isn't needed anymore as we collect the same information
into pm_display_cfg instead.

Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This code isn't needed anymore as we collect the same information
into pm_display_cfg instead.

Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu/ttm: Allocate/Free 4K MMIO_REMAP Singleton</title>
<updated>2025-09-15T20:52:24+00:00</updated>
<author>
<name>Srinivasan Shanmugam</name>
<email>srinivasan.shanmugam@amd.com</email>
</author>
<published>2025-08-28T13:48:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2a7a794eb82c37014ea95f7f58ebeff73ef72858'/>
<id>2a7a794eb82c37014ea95f7f58ebeff73ef72858</id>
<content type='text'>
Add mmio_remap bookkeeping to amdgpu_device and introduce
amdgpu_ttm_mmio_remap_bo_init()/fini() to manage a kernel-owned,
one-page (4K) BO in AMDGPU_GEM_DOMAIN_MMIO_REMAP.

Bookkeeping:
  - adev-&gt;rmmio_remap.bo : kernel-owned singleton BO

The BO is allocated during TTM init when a remap bus address is available
(adev-&gt;rmmio_remap.bus_addr) and PAGE_SIZE &lt;= AMDGPU_GPU_PAGE_SIZE (4K),
and freed during TTM fini.

v2:
 - Check mmio_remap bus address (adev-&gt;rmmio_remap.bus_addr) instead of
   rmmio_base. (Alex)
 - Skip quietly if PAGE_SIZE &gt; AMDGPU_GPU_PAGE_SIZE or no bus address
   (no warn). (Alex)
 - Use `amdgpu_bo_create()` (not *_kernel) - Only with this The object
   is stored in adev-&gt;mmio_remap.bo and will later be exposed to
   userspace via a GEM handle. (Christian)

v3:
 - Remove obvious comment before amdgpu_ttm_mmio_remap_bo_fini() call.
   (Alex)

v4:
 - Squash bookkeeping into this patch (Christian)

Suggested-by: Christian König &lt;christian.koenig@amd.com&gt;
Suggested-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Srinivasan Shanmugam &lt;srinivasan.shanmugam@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add mmio_remap bookkeeping to amdgpu_device and introduce
amdgpu_ttm_mmio_remap_bo_init()/fini() to manage a kernel-owned,
one-page (4K) BO in AMDGPU_GEM_DOMAIN_MMIO_REMAP.

Bookkeeping:
  - adev-&gt;rmmio_remap.bo : kernel-owned singleton BO

The BO is allocated during TTM init when a remap bus address is available
(adev-&gt;rmmio_remap.bus_addr) and PAGE_SIZE &lt;= AMDGPU_GPU_PAGE_SIZE (4K),
and freed during TTM fini.

v2:
 - Check mmio_remap bus address (adev-&gt;rmmio_remap.bus_addr) instead of
   rmmio_base. (Alex)
 - Skip quietly if PAGE_SIZE &gt; AMDGPU_GPU_PAGE_SIZE or no bus address
   (no warn). (Alex)
 - Use `amdgpu_bo_create()` (not *_kernel) - Only with this The object
   is stored in adev-&gt;mmio_remap.bo and will later be exposed to
   userspace via a GEM handle. (Christian)

v3:
 - Remove obvious comment before amdgpu_ttm_mmio_remap_bo_fini() call.
   (Alex)

v4:
 - Squash bookkeeping into this patch (Christian)

Suggested-by: Christian König &lt;christian.koenig@amd.com&gt;
Suggested-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Srinivasan Shanmugam &lt;srinivasan.shanmugam@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: Remove volatile from amdgpu and amdgpu_ih headers</title>
<updated>2025-09-15T20:51:18+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>siqueira@igalia.com</email>
</author>
<published>2025-09-08T23:15:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=897025300721eb9b585c9b90ae531a5f3ee29022'/>
<id>897025300721eb9b585c9b90ae531a5f3ee29022</id>
<content type='text'>
Remove the unnecessary use of volatile in some of the amdgpu.h and
amdgpu_ih.h headers.

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the unnecessary use of volatile in some of the amdgpu.h and
amdgpu_ih.h headers.

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: Remove volatile from ring manipulation</title>
<updated>2025-09-15T20:51:15+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>siqueira@igalia.com</email>
</author>
<published>2025-09-08T23:15:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f307cfb91734b36bde2597552971553d91838048'/>
<id>f307cfb91734b36bde2597552971553d91838048</id>
<content type='text'>
None of the pointer operations handled by the ring file requires
volatile, for this reason, this commit removes all occurrences of
volatile associated with rings.

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
None of the pointer operations handled by the ring file requires
volatile, for this reason, this commit removes all occurrences of
volatile associated with rings.

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;siqueira@igalia.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu/amdkfd: Avoid a couple hundred -Wflex-array-member-not-at-end warnings</title>
<updated>2025-09-02T21:36:20+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavoars@kernel.org</email>
</author>
<published>2025-08-29T09:58:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1e6d36e15b8873fc3ade8b714d35d69efd5e1427'/>
<id>1e6d36e15b8873fc3ade8b714d35d69efd5e1427</id>
<content type='text'>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.

Move the conflicting declarations to the end of the corresponding
structures. Notice that `struct dev_pagemap` is a flexible structure,
this is a structure that contains a flexible-array member.

struct dev_pagemap always has room for at least one range. amdgpu only
uses a single range. Therefore no change are needed to the allocation
of struct amdgpu_device.

Fix 283 of the following type of warnings:
    283 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:111:28: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
Signed-off-by: Felix Kuehling &lt;felix.kuehling@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;felix.kuehling@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.

Move the conflicting declarations to the end of the corresponding
structures. Notice that `struct dev_pagemap` is a flexible structure,
this is a structure that contains a flexible-array member.

struct dev_pagemap always has room for at least one range. amdgpu only
uses a single range. Therefore no change are needed to the allocation
of struct amdgpu_device.

Fix 283 of the following type of warnings:
    283 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:111:28: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
Signed-off-by: Felix Kuehling &lt;felix.kuehling@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;felix.kuehling@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: remove redundant AMDGPU_HAS_VRAM</title>
<updated>2025-08-27T17:57:48+00:00</updated>
<author>
<name>Yifan Zhang</name>
<email>yifan1.zhang@amd.com</email>
</author>
<published>2025-08-20T06:55:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e68197aa2bbf658a95a927db01c2933c8125bf17'/>
<id>e68197aa2bbf658a95a927db01c2933c8125bf17</id>
<content type='text'>
AMDGPU_HAS_VRAM is redundant with is_app_apu, as both refer to
APUs with no carve-out. Since AMDGPU_HAS_VRAM only occurs once,
remove AMDGPU_HAS_VRAM definition. The tmr allocation can be covered
with AMDGPU_GEM_DOMAIN_GTT | AMDGPU_GEM_DOMAIN_VRAM in both vram and
non vram ASICs.

Signed-off-by: Yifan Zhang &lt;yifan1.zhang@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
AMDGPU_HAS_VRAM is redundant with is_app_apu, as both refer to
APUs with no carve-out. Since AMDGPU_HAS_VRAM only occurs once,
remove AMDGPU_HAS_VRAM definition. The tmr allocation can be covered
with AMDGPU_GEM_DOMAIN_GTT | AMDGPU_GEM_DOMAIN_VRAM in both vram and
non vram ASICs.

Signed-off-by: Yifan Zhang &lt;yifan1.zhang@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: Save and restore switch state</title>
<updated>2025-08-11T15:12:53+00:00</updated>
<author>
<name>Lijo Lazar</name>
<email>lijo.lazar@amd.com</email>
</author>
<published>2025-06-28T05:20:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1dd2fa0e00f17b909ff0fab92c1c48c2d7911c15'/>
<id>1dd2fa0e00f17b909ff0fab92c1c48c2d7911c15</id>
<content type='text'>
During a DPC error kernel waits for the link to be active before
notifying downstream devices. On certain platforms with Broadcom switch
in synthetiic mode, switch responds with values even though the link is
not fully ready. The config space restoration done by pcie port driver
for SWUS/DS of dGPU is thus not effective as the switch is still doing
internal enumeration.

As a workaround, save state of SWUS/DS device in driver. Add additional
check to see if link is active and restore the values during DPC error
callbacks.

Signed-off-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Reviewed-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During a DPC error kernel waits for the link to be active before
notifying downstream devices. On certain platforms with Broadcom switch
in synthetiic mode, switch responds with values even though the link is
not fully ready. The config space restoration done by pcie port driver
for SWUS/DS of dGPU is thus not effective as the switch is still doing
internal enumeration.

As a workaround, save state of SWUS/DS device in driver. Add additional
check to see if link is active and restore the values during DPC error
callbacks.

Signed-off-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Reviewed-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
