On 7/16/2025 2:54 AM, Mario Limonciello wrote:
From: Mario Limonciello
Some of the IOCTL messages can be called for different GPUs and it might
not be obvious which one called them from a problem. Using the drm_*()
macros the correct device will be shown in the messages.
Signed-off-by: Mario
/products/graphics/desktops/radeon/9000-series/amd-radeon-rx-9060xt.html
https://www.amd.com/en/products/graphics/desktops/radeon/9000-series/amd-radeon-rx-9060xt-8gb.html
These should have Link: prefixes.
Reviewed-by: Mario Limonciello
Signed-off-by: Alex Deucher
---
Documentation/gpu/amdgpu
On 7/28/2025 11:07 PM, Alex Deucher wrote:
Add MP1 for APUs and MP0 and MP1 details for dGPUs.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3905
Signed-off-by: Alex Deucher
Reviewed-by: Mario Limonciello
---
.../gpu/amdgpu/amd-hardware-list-info.rst | 4 +-
.../gpu
From: Mario Limonciello
If the SCLK limits have been set before S3 they will not
be restored. The limits are however cached in the driver and so
they can be restored by running a commit sequence during resume.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 10
From: Mario Limonciello
The power limit will be cached in smu->current_power_limit but
if the ASIC goes into S3 this value won't be restored.
Restore the value during SMU resume.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 6 ++
1 file ch
From: Mario Limonciello
If userspace has programmed a custom power limit and/or custom clock
table the state will not be maintained across an S3 suspend cycle.
The values are already cached, so restore them in the resume sequence.
Mario Limonciello (2):
drm/amd: Restore cached power limit
From: Mario Limonciello
This reverts commit 66abb996999de0d440a02583a6e70c2c24deab45.
This broke custom brightness curves but it wasn't obvious because
of other related changes. Custom brightness curves are always
from a 0-255 input signal. The correct fix was to fix the default
value whic
On 7/20/25 7:59 PM, Lauri Tirkkonen wrote:
DIV_ROUND_CLOSEST(x, 100) returns either 0 or 1 if 0
Cc: sta...@vger.kernel.org
Thanks so much!
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
From: Mario Limonciello
The compositor can directly control ABM, but sysfs should be blocked
when this happens. Ensure that sysfs writes fail at that time.
To avoid potential test failures, ensure that sysfs control is enabled
at the start of all other tests.
Signed-off-by: Mario Limonciello
From: Mario Limonciello
Signed-off-by: Mario Limonciello
---
tests/amdgpu/amd_abm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index 97813d80f..f55b055f9 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -20,7 +20,6
From: Mario Limonciello
The compositor can set the ABM level directly, so rename the function
to clarify which method is being used.
Signed-off-by: Mario Limonciello
---
tests/amdgpu/amd_abm.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tests
From: Mario Limonciello
After the Display Next 2025 hackfest a patch series was introduced to
allow the compositor to control ABM. sysfs writes are blocked when set.
Add support for testing that the writes really are blocked.
Link:
https://lore.kernel.org/amd-gfx/20250718192045.2091650-1-supe
On 7/20/25 4:36 AM, Lauri Tirkkonen wrote:
DIV_ROUND_CLOSEST(x, 100) returns either 0 or 1 if 0
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/
On 7/19/25 10:25 AM, Mario Limonciello wrote:
On 7/18/25 9:12 PM, Lauri Tirkkonen wrote:
On Fri, Jul 18 2025 20:14:08 -0500, Mario Limonciello wrote:
OK, I think we need to do two things to figure out what's going on.
1) Let's shift over to 6.16-rc6. Once we've got
On 7/19/25 12:02 PM, Felix Richter wrote:
On 7/19/25 14:23, Mario Limonciello wrote:
On 7/19/25 5:10 AM, Felix Richter wrote:
Thanks for the reply.
I am aware that i can read and `edid` via sysfs from the drm device.
I did not know about `drm_info` but from a quick look at it I don&#
On 7/18/25 9:12 PM, Lauri Tirkkonen wrote:
On Fri, Jul 18 2025 20:14:08 -0500, Mario Limonciello wrote:
OK, I think we need to do two things to figure out what's going on.
1) Let's shift over to 6.16-rc6. Once we've got a handle on the situation
there we can iron out if
s thread and agree it's an issue with similar
symptoms.
On 7/18/25 20:02, Mario Limonciello wrote:
At least to me, this issue sounds like a case that multiple entities
are trying to communicate with the panel at the same time.
By setting dcdebugmask=0x10 what you're essentially d
On 7/18/25 8:03 PM, Lauri Tirkkonen wrote:
On Fri, Jul 18 2025 12:13:30 -0500, Mario Limonciello wrote:
On 7/18/2025 9:36 AM, Lauri Tirkkonen wrote:
On Fri, Jul 18 2025 08:10:06 -0500, Mario Limonciello wrote:
Do you by chance have an OLED panel? I believe what's going on is
From: Mario Limonciello
commit 0887054d14ae2 ("drm/amd: Drop abm_level property") dropped the
abm level property in favor of sysfs control. Since then there have
been discussions that compositors showed an interest in modifying
a vendor specific property instead.
So re-introduce the
From: Mario Limonciello
During the 2025 Display Next Hackfest the topic from the 2024 display
next hackfest about what to do with adaptive backlight modulation was
revisited.
The general consensus was that the 2024 proposed solution [1] although
functional was not desirable because it was a
On 7/17/2025 2:42 PM, Felix Richter wrote:
Hi,
just tested that this Bug still exists in kernel version 6.16-rc6. The
example trigger from my previous mail still works triggering screen
freezing shortly after invocation.
I also learned that setting kernel param `amdgpu.dcdebugmask=0x10` work
On 7/18/2025 9:36 AM, Lauri Tirkkonen wrote:
On Fri, Jul 18 2025 08:10:06 -0500, Mario Limonciello wrote:
Do you by chance have an OLED panel? I believe what's going on is that
userspace is writing zero or near zero and on OLED panels with older kernels
this means non-visible.
Yes, th
On 7/18/25 2:29 AM, Lauri Tirkkonen wrote:
Hi,
I hit this regression on the stable kernel on Alpine with a Lenovo Yoga
Slim 7 Pro 17ACH5. During early boot, when the amdgpu module gets
loaded, backlight brightness is set to zero, resulting in a black
screen (and nothing in userspace is runnin
Thanks for looking.
On 7/17/25 4:55 PM, Bjorn Helgaas wrote:
On Mon, Jun 16, 2025 at 12:50:16PM -0500, Mario Limonciello wrote:
From: Mario Limonciello
For the suspend flow PCIe ports that have downstream devices are put into
the appropriate D3 state when children are not in D0. For the
nce happens:
dc_create()
->dc_construct_ctx()
If dc_construct_ctx() fails then it jumps to a label that calls
dc_destruct(). So if the context wasn't set up then yeah there could be
a NULL pointer deref.
So to me this makes sense.
Reviewed-by: Mario Limonciello
Harry, do you agree?
From: Mario Limonciello
Some of the IOCTL messages can be called for different GPUs and it might
not be obvious which one called them from a problem. Using the drm_*()
macros the correct device will be shown in the messages.
Signed-off-by: Mario Limonciello
---
v2:
* use adev_to_drm (Lijo
Some of the IOCTL messages can be called for different GPUs and it might
not be obvious which one called them from a problem. Using the drm_*()
macros the correct device will be shown in the messages.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 20
On 7/12/25 3:11 AM, Rafael J. Wysocki wrote:
On Fri, Jul 11, 2025 at 11:25 PM Randy Dunlap wrote:
On 7/11/25 2:10 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20250710:
on x86_64, when
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
ERROR: mod
On 7/10/2025 4:25 PM, ivan.lip...@amd.com wrote:
From: Charlene Liu
[why]
dc has some code out of sync:
dc_commit_updates_for_stream handles v1/v2/v3,
but dc_update_planes_and_stream makes v1 asic to use v2.
as a reression fix: limit clear_update_flags to dcn32 or newer asic.
regression
ne
ux-next
* add Tested-by for patch 5
The merge options are either:
* the linux-pm changes go to linux-pm and an immutable branch for drm to
merge
* everything goes through amd-staging-drm-next (and an amdgpu PR to drm
later)
* everything goes through drm-misc-next
Mario Limonciello thi
On 7/10/2025 8:20 AM, Christian König wrote:
On 10.07.25 14:13, Mario Limonciello wrote:
On 7/10/2025 2:23 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since it is
not involved in writing the hibernation image. Skip resume in this case
can reduce the
,
this can save 50 minutes.
Signed-off-by: Samuel Zhang
Tested-by: Mario Limonciello
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd
.
Tested-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4f8632737574..b24c420983ef 100644
--- a/drivers/gpu/drm/amd
On 7/9/2025 6:05 AM, Samuel Zhang wrote:
This new api is used for hibernation to move GTT BOs to shmem after
VRAM eviction. shmem will be flushed to swap disk later to reduce
the system memory usage for hibernation.
Signed-off-by: Samuel Zhang
Reviewed-by: Christian König
---
drivers/gpu/drm
On 7/9/2025 6:05 AM, Samuel Zhang wrote:
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has failed.
* error case 2: restoration from a hibernation image has failed.
For normal case, it is ca
On 7/9/2025 6:05 AM, Samuel Zhang wrote:
When hibernate with data center dGPUs, huge number of VRAM data will be
moved to shmem during dev_pm_ops.prepare(). These shmem pages take a lot
of system memory so that there's no enough free memory for creating the
hibernation image. This will cause hibe
On 7/8/2025 12:08 PM, Zhang, GuoQing (Sam) wrote:
On 2025/7/8 22:40, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since
it is
not involved in writing the hibernation image. Skip resume in this case
can reduce
On 7/8/2025 12:07 PM, Zhang, GuoQing (Sam) wrote:
On 2025/7/8 22:36, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since it is
not involved in writing the hibernation image. Skip resume in this case
can reduce the hibernation time.
On VM with 8 * 192GB VRAM dGPUs, 98% VRAM usage and 1.7TB system memory,
thi
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has failed.
* error case 2: restoration from a hibernation image has failed.
For normal case, it is ca
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
Modern data center dGPUs are usually equipped with very large VRAM. On
server with such dGPUs(192GB VRAM * 8) and 2TB system memory, hibernate
will fail due to no enough free memory.
The root cause is that during hibernation all VRAM memory get evicted to
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
When hibernate with data center dGPUs, huge number of VRAM data will be
moved to shmem during dev_pm_ops.prepare(). These shmem pages take a lot
of system memory so that there's no enough free memory for creating the
hibernation image. This will cause hibe
On 7/7/2025 3:03 PM, Alex Deucher wrote:
Start and stop can fail, so add checks.
Fixes: b8b6e6f1654d ("drm/amd: Add per-ring reset for vcn v4.0.0 use")
Signed-off-by: Alex Deucher
Cc: Mario Limonciello
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/vcn_
On 7/7/2025 3:03 PM, Alex Deucher wrote:
Start and stop can fail, so add checks.
Fixes: d1a46cdd0053 ("drm/amd: Add per-ring reset for vcn v4.0.5 use")
Signed-off-by: Alex Deucher
Cc: Mario Limonciello
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/vcn_v4
On 7/7/2025 3:03 PM, Alex Deucher wrote:
Start and stop can fail, so add checks.
Fixes: b54695dae995 ("drm/amd: Add per-ring reset for vcn v5.0.0 use")
Signed-off-by: Alex Deucher
Cc: Mario Limonciello
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/vcn_v5
On 7/6/2025 10:28 PM, Lazar, Lijo wrote:
On 7/7/2025 2:04 AM, Mario Limonciello wrote:
On 7/4/2025 6:12 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since it
is not involved in writing the hibernation image. Skip resume in this
case can reduce the
hat/
from ISP V4L2 driver and calls the amdgpu internal functions
amdgpu_bo_create_isp_user() and amdgpu_bo_create_kernel() to
alloc/free GART buffers.
Signed-off-by: Pratap Nirujogi
No need to respin for the typo above if this is the only feedback.
Reviewed-by: Mario Limonciello
---
Changes
On 7/4/2025 6:12 AM, Samuel Zhang wrote:
This new api is used for hibernation to move GTT BOs to shmem after
VRAM eviction. shmem will be flushed to swap disk later to reduce
the system memory usage for hibernation.
Signed-off-by: Samuel Zhang
---
drivers/gpu/drm/ttm/ttm_device.c | 29 +++
On 7/4/2025 6:12 AM, Samuel Zhang wrote:
When hibernate with data center dGPUs, huge number of VRAM BOs evicted
to GTT and takes too much system memory. This will cause hibernation
fail due to insufficient memory for creating the hibernation image.
Move GTT BOs to shmem in KMD, then shmem to swa
On 7/4/2025 6:12 AM, Samuel Zhang wrote:
https://github.com/torvalds/linux/blob/v6.14/Documentation/power/pci.rst?plain=1#L588
Per this kernel doc, dev_pm_ops.thaw() is called mainly for resume
Proper way to do this is to put the URL in a 'Link' tag above your SoB.
That being said I don't thin
On 7/4/2025 6:12 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since it
is not involved in writing the hibernation image. Skip resume in this
case can reduce the hibernation time.
Since you have the measurements would you mind including them in the
commi
On 7/3/25 10:29, Rafael J. Wysocki wrote:
On Mon, Jun 16, 2025 at 7:50 PM Mario Limonciello wrote:
From: Mario Limonciello
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered
On 6/27/2025 3:17 PM, Pratap Nirujogi wrote:
Accessing amdgpu internal data structures "struct amdgpu_device"
and "struct amdgpu_bo" in ISP V4L2 driver to alloc/free GART
buffers is not recommended.
Add new amdgpu_isp helper functions thats takes opaque params
from ISP V4L2 driver and calls the
On 6/27/2025 2:13 PM, Pratap Nirujogi wrote:
Accessing amdgpu internal data structures "struct amdgpu_device"
and "struct amdgpu_bo" in ISP V4L2 driver to alloc/free GART
buffers is not recommended.
Add new amdgpu_isp helper functions thats takes opaque params
from ISP V4L2 driver and calls the
-frequencies etc.) required for camera to work on AMD ISP4
based targets.
Signed-off-by: Pratap Nirujogi
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.c | 11
From: Mario Limonciello
drm_*() macros can show the device a message came from.
Reviewed-by: Lijo Lazar
Cc: Alexandre Demers
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
diff
From: Mario Limonciello
legacy-pm, kv-dpm and si-dpm have prints while changing power states
that don't have a level and thus are printed by default. These are
not useful at runtime for most people, so decrease them to debug.
Reported-by: Alexandre Demers
Closes: https://gitlab.freedeskto
From: Mario Limonciello
drm_*() macros can show the device a message came from.
Reviewed-by: Lijo Lazar
Cc: Alexandre Demers
Signed-off-by: Mario Limonciello
---
.../gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c| 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff
From: Mario Limonciello
drm_*() macros can show the device a message came from.
Cc: Alexandre Demers
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm
From: Mario Limonciello
legacy-pm, kv-dpm and si-dpm have prints while changing power states
that don't have a level and thus are printed by default. These are
not useful at runtime for most people, so decrease them to debug.
Reported-by: Alexandre Demers
Closes: https://gitlab.freedeskto
From: Mario Limonciello
drm_*() macros can show the device a message came from.
Cc: Alexandre Demers
Signed-off-by: Mario Limonciello
---
.../gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c| 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm
On 6/24/2025 12:42 AM, Werner Sembach wrote:
Hi Mario,
Am 23.06.25 um 21:42 schrieb Limonciello, Mario:
On 6/23/25 2:13 PM, Rodrigo Siqueira wrote:
On 06/23, Werner Sembach wrote:
gentle bump
Am 09.04.25 um 18:27 schrieb Werner Sembach:
The display backlight on TUXEDO Polaris AMD Gen2 and G
[Why]
Brightness programming may involve a conversion of a user requested
brightness against what was in a custom brightness curve. The values
might not match what a user programmed.
[How]
Add a new trace event to show specific converted brightness values.
Signed-off-by: Mario Limonciello
the change for max brightness of 0x only applies to devices
supporting DC, use existing DC define MAX_BACKLIGHT_LEVEL.
Fixes: 16dc8bc27c2aa ("drm/amd/display: Export full brightness range to
userspace")
Signed-off-by: Mario Limonciello
---
v2:
* Use DC define instead
---
drivers
c2aa ("drm/amd/display: Export full brightness range to
userspace")
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu
From: Mario Limonciello
During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.
To accomplish this a new optional DRM property is being introduced called
"
From: Mario Limonciello
When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.
When the `power_saving_policy` property is set to bit mask
"Require l
From: Mario Limonciello
The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.
This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the
From: Mario Limonciello
The `complete` callback should be described in kernel doc.
Reported-by: Stephen Rothwell
Closes:
https://lore.kernel.org/linux-next/20250619205931.41cf9...@canb.auug.org.au/
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
1 file
| 60 --
9 files changed, 264 insertions(+), 42 deletions(-)
Reviewed-by: Mario Limonciello
On 6/19/2025 4:58 AM, Du, Bin wrote:
Thanks Mario, will fix in the next version and pls see some of my comments
On 6/19/2025 12:17 AM, Mario Limonciello wrote:
+Alex
+amd-gfx
On 6/18/2025 4:19 AM, Bin Du wrote:
ISP firmware controls ISP HW pipeline using dedicated embedded processor
called
On 6/18/2025 6:55 PM, Baoquan He wrote:
On 06/18/25 at 11:12am, Peter Zijlstra wrote:
On Wed, Jun 18, 2025 at 10:51:23AM +0200, Peter Zijlstra wrote:
On Tue, Jun 17, 2025 at 09:12:12PM -0500, Mario Limonciello wrote:
How about if we reset before the kexec? There is a symbol for drivers to
From: Mario Limonciello
legacy-pm has prints while changing power states that don't have
a level and thus are printed by default. These are not useful at
runtime for most people, so decrease them to debug.
Reported-by: Alexandre Demers
Closes: https://gitlab.freedesktop.org/drm/amd/-/i
+Alex
+amd-gfx
On 6/18/2025 4:19 AM, Bin Du wrote:
ISP firmware controls ISP HW pipeline using dedicated embedded processor
called ccpu.
The communication between ISP FW and driver is using commands and
response messages sent through the ring buffer. Command buffers support
either global setting
On 6/18/2025 4:26 AM, Peter Zijlstra wrote:
On Wed, Jun 18, 2025 at 11:12:32AM +0200, Peter Zijlstra wrote:
On Wed, Jun 18, 2025 at 10:51:23AM +0200, Peter Zijlstra wrote:
On Tue, Jun 17, 2025 at 09:12:12PM -0500, Mario Limonciello wrote:
How about if we reset before the kexec? There is a
On 6/18/2025 4:05 AM, Christian König wrote:
On 6/18/25 10:51, Peter Zijlstra wrote:
On Tue, Jun 17, 2025 at 09:12:12PM -0500, Mario Limonciello wrote:
How about if we reset before the kexec? There is a symbol for drivers to
use to know they're about to go through kexec to do $T
On 6/17/2025 6:42 PM, Alex Hung wrote:
Hi,
Thanks for reporting. Can you please create a bug at https://
gitlab.freedesktop.org/drm/amd/-/issues/ for issue tracking and log
collection.
On 6/12/25 08:08, g...@tuxedocomputers.com wrote:
Hi,
I have discovered that two small form factor deskto
On 6/16/2025 9:54 AM, Peter Zijlstra wrote:
On Mon, Jun 16, 2025 at 01:51:21PM +0200, Christian König wrote:
Hi Peter,
On 6/16/25 11:39, Peter Zijlstra wrote:
Hi guys,
My (Intel Sapphire Rapids) workstation has a RX 7800 XT and when I kexec
a bunch of times, the amdgpu driver gets upset and b
From: Mario Limonciello
commit 017fbb6690c22 ("drm/amdgpu/discovery: check ip_discovery fw file
available") added support for reading an amdgpu IP discovery bin file
for some specific products. If it's not found then it will fallback to
hardcoded values. However if it's not f
On 6/16/25 9:53 PM, Alex Deucher wrote:
On Mon, Jun 16, 2025 at 4:21 PM Mario Limonciello wrote:
From: Mario Limonciello
In order to discover whether a GPU is part of a dGPU or APU userspace has
to do some mental gymnastics or heuristics. Add a sysfs file that clearly
indicates to
From: Mario Limonciello
For the suspend flow PCIe ports that have downstream devices are put into
the appropriate D3 state when children are not in D0. For the hibernate
flow, PCIe ports with downstream devices stay in D0 however. This can
lead to PCIe ports that are remained powered on
From: Mario Limonciello
In order to discover whether a GPU is part of a dGPU or APU userspace has
to do some mental gymnastics or heuristics. Add a sysfs file that clearly
indicates to userspace.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 16
From: Mario Limonciello
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered off.
There have been some localized changes[1] to PCI core to help these issues,
but they have had
From: Mario Limonciello
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Signed-off-by: Mario Limonciello
---
v3:
https://lore.kernel.org/linux-pm/20250609024619.407257-1
From: Mario Limonciello
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Signed-off-by: Mario Limonciello
---
v3:
* New patch
*
https://lore.kernel.org/linux-pm
From: Mario Limonciello
Normally resources are evicted on dGPUs at suspend or hibernate and
on APUs at hibernate. These steps are unnecessary when using the S4
callbacks to put the system into S5.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
From: Mario Limonciello
When the system is powered off the kernel will call device_shutdown()
which will issue callbacks into PCI core to wake up a device and call
it's shutdown() callback. This will leave devices in ACPI D0 which can
cause some devices to misbehave with spurious wakeup
On 6/13/25 10:27 PM, Lazar, Lijo wrote:
On 6/14/2025 3:11 AM, Mario Limonciello wrote:
From: Mario Limonciello
commit 017fbb6690c22 ("drm/amdgpu/discovery: check ip_discovery fw file
available") added support for reading an amdgpu IP discovery bin file
for some specific product
On 6/13/2025 4:41 PM, Mario Limonciello wrote:
From: Mario Limonciello
commit 017fbb6690c22 ("drm/amdgpu/discovery: check ip_discovery fw file
available") added support for reading an amdgpu IP discovery bin file
for some specific products. If it's not found then it will fallba
From: Mario Limonciello
commit 017fbb6690c22 ("drm/amdgpu/discovery: check ip_discovery fw file
available") added support for reading an amdgpu IP discovery bin file
for some specific products. If it's not found then it will fallback to
hardcoded values. However if it's not f
On 6/13/2025 12:42 PM, Melissa Wen wrote:
On 06/13, Mario Limonciello wrote:
On 6/13/2025 7:58 AM, Melissa Wen wrote:
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
v3:
- remove uneccessary
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
Reviewed-by: Mario Limonciello
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
This is a pretty old commit. It's landed now a while,
audio caps.
Signed-off-by: Melissa Wen
Reviewed-by: Mario Limonciello
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 22 ++-
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd
.
Signed-off-by: Melissa Wen
Reviewed-by: Mario Limonciello
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm
On 6/13/2025 9:58 AM, Melissa Wen wrote:
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Can you put changelog below cutlist (---)?
Signed-off-by: Rodrigo Siqueira
Co-dev
On 6/13/2025 9:58 AM, Melissa Wen wrote:
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
I don't think th
On 6/13/2025 9:58 AM, Melissa Wen wrote:
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it
On 6/13/2025 9:58 AM, Melissa Wen wrote:
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
On 6/13/2025 7:58 AM, Melissa Wen wrote:
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
v3:
- remove uneccessary include (jani)
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/am
1 - 100 of 1263 matches
Mail list logo
