RE: [PATCH] drm/amdgpu: Fix amdgpu_userq_wait_ioctl() warn missing error code 'r'

[AMD Official Use Only - AMD Internal Distribution Only] Reviewed-by: Sunil Khatri -Original Message- From: Yadav, Arvind Sent: Thursday, May 8, 2025 11:50 AM To: Koenig, Christian ; Deucher, Alexander ; Khatri, Sunil ; Paneer Selvam, Arunpravin ; dan.carpen...@linaro.org Cc: amd-gfx@

Re: [PATCH 6/6] drm/amdgpu: fix fence fallback timer expired error

[AMD Official Use Only - AMD Internal Distribution Only] Hi @Chang, HaiJun Thank you for the info. You are right, GFXMSIX_VECT0_ADDR_LO and GFXMSIX_VECT0_CONTROL registers are not restored on resume with new VF. source VF, normal value 0x42000: 0xFEE00138 // GFXMSIX

RE: [PATCH 5/7] drm/amdgpu/userq: implement resets

[Public] > -Original Message- > From: amd-gfx On Behalf Of Zhang, > Jesse(Jie) > Sent: Wednesday, May 7, 2025 1:24 PM > To: Deucher, Alexander ; amd- > g...@lists.freedesktop.org > Cc: Deucher, Alexander ; Koenig, Christian > ; Khatri, Sunil > Subject: RE: [PATCH 5/7] drm/amdgpu/userq: i

[PATCH] drm/amdgpu: Fix amdgpu_userq_wait_ioctl() warn missing error code 'r'

To resolve the warning regarding the missing error code 'r' in amdgpu_userq_wait_ioctl(), assign the value 'r = -EINVAL'. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202505080458.rnv8yfiy-...@intel.com/ Cc: Alex Deucher Cc: Christian König Cc: Su

Re: [RFC v7 00/23] DRM scheduling cgroup controller

On Fri, May 02, 2025 at 01:32:33PM +0100, Tvrtko Ursulin wrote: > Hi all, > > This is another respin of this old work^1 but this version is a total rewrite > and completely changes how the control is done. > > This time round the work builds upon the "fair" DRM scheduler work I have > posted > r

[PATCH v2] drm/amdgpu: Fix NULL dereference in amdgpu_userq_restore_worker

Switch cancel_delayed_work() to cancel_delayed_work_sync() to ensure the delayed work has finished executing before proceeding with resource cleanup. This prevents a potential use-after-free or NULL dereference if the resume_work is still running during finalization. BUG: kernel NULL pointer deref

[PATCH v4 0/7] enable switching to new gpu index for hibernate on SRIOV.

On SRIOV and VM environment, customer may need to switch to new vGPU indexes after hibernate and then resume the VM. For GPUs with XGMI, `vram_start` will change in this case, the FB aperture gpu address of VRAM BOs will also change. These gpu addresses need to be updated when resume. But these ad

[PATCH v4 7/7] drm/amdgpu: remove cached gpu addr: psp_context.cmd_buf_mc_addr

When pdb0 enabled, the cached gpu addr is not compatible with SMU and PSP. It always need to be updated. Remove the cached gpu addr and use local variable instead. Signed-off-by: Samuel Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 1 -

[PATCH v4 4/7] drm/amdgpu: remove cached gpu addr: amdgpu_firmware.fw_buf_mc

When pdb0 enabled, the cached gpu addr is not compatible with SMU and PSP. It always need to be updated. Remove the cached gpu addr and use local variable instead. Signed-off-by: Samuel Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 13 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ucod

[PATCH v4 3/7] drm/amdgpu: enable pdb0 for hibernation on SRIOV

When switching to new GPU index after hibernation and then resume, VRAM offset of each VRAM BO will be changed, and the cached gpu addresses needed to updated. This is to enable pdb0 and switch to use pdb0-based virtual gpu address by default in amdgpu_bo_create_reserved(). since the virtual addre

[PATCH v4 6/7] drm/amdgpu: remove cached gpu addr: psp_context.tmr_mc_addr

When pdb0 enabled, the cached gpu addr is not compatible with SMU and PSP. It always need to be updated. Remove the cached gpu addr and use local variable instead. Signed-off-by: Samuel Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |

[PATCH v4 2/7] drm/amdgpu: update GPU addresses for SMU and PSP

add amdgpu_bo_fb_aper_addr() and update the cached GPU addresses to use the FB aperture address for SMU and PSP. 2 reasons for this change: 1. when pdb0 is enabled, gpu addr from amdgpu_bo_create_kernel() is GART aperture address, it is not compatible with SMU and PSP, it need to updated to use FB

[PATCH v4 5/7] drm/amdgpu: remove cached gpu addr: ta_mem_context.shared_mc_addr

When pdb0 enabled, the cached gpu addr is not compatible with SMU and PSP. It always need to be updated. Remove the cached gpu addr and use local variable instead. Signed-off-by: Samuel Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 18 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_p

[PATCH v4 1/7] drm/amdgpu: update XGMI info on resume

For virtual machine with vGPUs in SRIOV single device mode and XGMI is enabled, XGMI physical node ids may change when waking up from hiberation with different vGPU devices. So update XGMI info on resume. Signed-off-by: Jiang Liu Signed-off-by: Samuel Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu

Re: [PATCH] drm/amdgpu: Fix NULL dereference in amdgpu_userq_restore_worker

On 5/8/2025 12:36 AM, Alex Deucher wrote: On Wed, May 7, 2025 at 2:38 PM Arvind Yadav wrote: Switch cancel_delayed_work() to cancel_delayed_work_sync() to ensure the delayed work has finished executing before proceeding with resource cleanup. This prevents a potential use-after-free or NULL d

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 2025/5/7 20:56, Christian König wrote: > On 5/7/25 14:49, Sam wrote: >> On 2025/5/7 20:21, Christian König wrote: >>> On 5/7/25 13:03, Sam wrote: On 2025/5/7 18:03, Lazar, Lijo wrote: > On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: >> [AMD Official Use Only - AMD Internal Distr

[PATCH] drm/amdgpu: csa unmap use uninterruptible lock

After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace. Change to use uninterruptible wait lock fix the issue. WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On Wed, May 7, 2025 at 9:45 PM Mario Limonciello wrote: > > On 5/7/2025 2:39 PM, Rafael J. Wysocki wrote: > > On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote: > >> > >> On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote: > >>> On Thu, May 1, 2025 at 11:17 PM Mario Limonciello > >>> wrote: > >>

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote: > > On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote: > > On Thu, May 1, 2025 at 11:17 PM Mario Limonciello > > wrote: > >> > >> From: Mario Limonciello > >> > >> commit 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification > >> callback

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On 5/7/2025 2:39 PM, Rafael J. Wysocki wrote: On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote: On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote: On Thu, May 1, 2025 at 11:17 PM Mario Limonciello wrote: From: Mario Limonciello commit 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notifi

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On Wed, May 7, 2025 at 3:39 PM Rafael J. Wysocki wrote: > > On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote: > > > > On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote: > > > On Thu, May 1, 2025 at 11:17 PM Mario Limonciello > > > wrote: > > >> > > >> From: Mario Limonciello > > >> > > >> com

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote: On Thu, May 1, 2025 at 11:17 PM Mario Limonciello wrote: From: Mario Limonciello commit 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification callback support") introduced a VRAM eviction earlier in the PM sequences when swap was still avail

Re: [RFC 2/2] drm/amd: Use suspend and hibernate post freeze notifications

On Thu, May 1, 2025 at 11:17 PM Mario Limonciello wrote: > > From: Mario Limonciello > > commit 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification > callback support") introduced a VRAM eviction earlier in the PM > sequences when swap was still available for evicting to. This helped > to

Re: [PATCH] drm/amdgpu: Fix NULL dereference in amdgpu_userq_restore_worker

On Wed, May 7, 2025 at 2:38 PM Arvind Yadav wrote: > > Switch cancel_delayed_work() to cancel_delayed_work_sync() to ensure > the delayed work has finished executing before proceeding with > resource cleanup. This prevents a potential use-after-free or > NULL dereference if the resume_work is stil

[PATCH] drm/amdgpu: Fix NULL dereference in amdgpu_userq_restore_worker

Switch cancel_delayed_work() to cancel_delayed_work_sync() to ensure the delayed work has finished executing before proceeding with resource cleanup. This prevents a potential use-after-free or NULL dereference if the resume_work is still running during finalization. BUG: kernel NULL pointer deref

Re: [PATCH v2 3/3] drm/amd: Add per-ring reset for vcn v5.0.0 use

On Tue, May 6, 2025 at 4:50 PM Mario Limonciello wrote: > > If there is a problem requiring a reset of the VCN engine, it is better to > reset the VCN engine rather than the entire GPU. > > Add a reset callback for the ring which will stop and start VCN if an > issue happens. > > Signed-off-by: Ma

[PATCH] drm/amd/display: use drm_dbg_driver() in amdgpu_dm.c

Replace all use of DRM_DEBUG_DRIVER in amdgpu_dm.c with drm_dbg_driver(). The latter prints the instance of the drm device associated with the error which would helpful in debugging scenarios involving multiple GPUs Signed-off-by: Aurabindo Pillai --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.

Re: [PATCH 1/7] Revert "drm/amdgpu: Use generic hdp flush function"

[AMD Official Use Only - AMD Internal Distribution Only] The flush reg is read/write. If the reads are not working on those platforms, I think the writes may be dropped silently. Thanks, Lijo From: Alex Deucher Sent: Wednesday, May 7, 2025 8:43:51 PM To: Deucher

Re: [PATCH 1/7] Revert "drm/amdgpu: Use generic hdp flush function"

On Wed, May 7, 2025 at 12:43 PM Lazar, Lijo wrote: > > [AMD Official Use Only - AMD Internal Distribution Only] > > > The flush reg is read/write. If the reads are not working on those platforms, > I think the writes may be dropped silently. The problem only happens when we remap the register to

Re: [PATCH 1/7] Revert "drm/amdgpu: Use generic hdp flush function"

Ping again on this series? Alex On Tue, May 6, 2025 at 11:17 AM Alex Deucher wrote: > > Ping on this series? This fixes a regression. > > Alex > > On Mon, May 5, 2025 at 9:05 AM Alex Deucher wrote: > > > > This reverts commit 18a878fd8aef0ec21648a3782f55a79790cd4073. > > > > Revert this tempor

Re: [PATCH 1/7] Revert "drm/amdgpu: Use generic hdp flush function"

On 2025-05-06 11:17, Alex Deucher wrote: > Ping on this series? This fixes a regression. > > Alex > > On Mon, May 5, 2025 at 9:05 AM Alex Deucher wrote: >> This reverts commit 18a878fd8aef0ec21648a3782f55a79790cd4073. >> >> Revert this temporarily to make it easier to fix a regression >> in the H

Re: [PATCH 3/3] drm/amd/pm/smu13: Remove unused smu_v3 functions

Applied the series. Thanks! Alex On Tue, May 6, 2025 at 8:33 PM wrote: > > From: "Dr. David Alan Gilbert" > > smu_v13_0_display_clock_voltage_request() and > smu_v13_0_set_min_deep_sleep_dcefclk() were added in 2020 by > commit c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)"

[PATCH 1/7] Revert "drm/amdgpu: Use generic hdp flush function"

This reverts commit 18a878fd8aef0ec21648a3782f55a79790cd4073. Revert this temporarily to make it easier to fix a regression in the HDP handling. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_hdp.c | 21 - drivers/gpu/drm/amd/amdgpu/amdgpu_hdp.h | 2 -- d

[PATCH 3/7] drm/amdgpu/hdp5: use memcfg register to post the write for HDP flush

Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: cf424020e040 ("drm/amdgpu/hdp5.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/a

[PATCH 4/7] drm/amdgpu/hdp5.2: use memcfg register to post the write for HDP flush

Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: f756dbac1ce1 ("drm/amdgpu/hdp5.2: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/a

[PATCH 5/7] drm/amdgpu/hdp6: use memcfg register to post the write for HDP flush

Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: abe1cbaec6cf ("drm/amdgpu/hdp6.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/a

[PATCH 6/7] drm/amdgpu/hdp7: use memcfg register to post the write for HDP flush

Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: 689275140cb8 ("drm/amdgpu/hdp7.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/a

[PATCH V2 7/7] Reapply: drm/amdgpu: Use generic hdp flush function

From: Lijo Lazar Except HDP v5.2 all use a common logic for HDP flush. Use a generic function. HDP v5.2 forces NO_KIQ logic, revisit it later. Reapply after fixing up an HDP regression. v2: merge the fix Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- dr

[PATCH 2/7] drm/amdgpu/hdp4: use memcfg register to post the write for HDP flush

Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: c9b8dcabb52a ("drm/amdgpu/hdp4.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/a

Re: [PATCH v2 3/3] drm/amd: Add per-ring reset for vcn v5.0.0 use

This patch series is :- Reviewed-by: Sathishkumar S On 5/7/2025 2:19 AM, Mario Limonciello wrote: If there is a problem requiring a reset of the VCN engine, it is better to reset the VCN engine rather than the entire GPU. Add a reset callback for the ring which will stop and start VCN if an is

Re: [PATCH V9 35/43] drm/amd/display: add 3x4 matrix colorop

Hi Alex, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-exynos/exynos-drm-next] [also build test WARNING on next-20250507] [cannot apply to linus/master drm/drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-misc/drm-misc-next drm-tip

[PATCH] drm/amdkfd: drop warning in event_interrupt_isr_v1*()

Commit ded8b3c36f17 ("drm/amdgpu: properly handle GC vs MM in amdgpu_vmid_mgr_init()") enables all 16 vmids for MMHUB on GC 10 and newer for KGD since there are no KFD resources using MMHUB. With this change, KFD starts seeing MMHUB vmids in it's range with no pasid set. As such there is no need

RE: [PATCH 2/2] drm/amdgpu: log the user queue object PRT mapping

[Public] > From: Koenig, Christian > Sent: Wednesday, May 7, 2025 4:36 PM > To: Liang, Prike ; amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander > Subject: Re: [PATCH 2/2] drm/amdgpu: log the user queue object PRT mapping > > On 5/7/25 09:05, Liang, Prike wrote: > > [Public] > > > >> -O

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 2025/5/7 20:21, Christian König wrote: On 5/7/25 13:03, Sam wrote: On 2025/5/7 18:03, Lazar, Lijo wrote: On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: [AMD Official Use Only - AMD Internal Distribution Only] Please keep in mind that this is not the only scenario addressed by the

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 5/7/25 14:49, Sam wrote: > > On 2025/5/7 20:21, Christian König wrote: >> On 5/7/25 13:03, Sam wrote: >>> On 2025/5/7 18:03, Lazar, Lijo wrote: On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > > >   >> Please

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 5/7/25 13:03, Sam wrote: > > On 2025/5/7 18:03, Lazar, Lijo wrote: >> On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: >>> [AMD Official Use Only - AMD Internal Distribution Only] >>> >>> >>>   Please keep in mind that this is not the only scenario addressed by the driver - for ex: a

Re: [RFC PATCH 2/2] drm/amdgpu/uvd: Ensure vcpu bos are within the uvd segment

On 5/5/25 12:06 PM, John Olender wrote: > On 5/5/25 5:02 AM, Christian König wrote: >>> Simply changing the uvd vcpu bo (and therefore the firmware) to always >>> be allocated in vram does *not* solve #3851. >>> >>> Let me go into a bit of depth about how I arrived at this patch. >>> >>> First, wha

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 2025/5/7 18:03, Lazar, Lijo wrote: On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: [AMD Official Use Only - AMD Internal Distribution Only] Please keep in mind that this is not the only scenario addressed by the driver - for ex: a resume sequence is executed after a device reset. T

Re: [PATCH v3 2/7] drm/amdgpu: update GPU addresses for SMU and PSP

@Koenig, Christian Thank you for the review! @Lazar, Lijo Could you help review this patch? Thank you! Regards Sam On 2025/5/6 20:32, Christian König wrote: On 5/6/25 11:36, Samuel Zhang wrote: add amdgpu_bo_fb_aper_addr() and upd

Re: [PATCH V9 15/43] drm/vkms: Add kunit tests for linear and sRGB LUTs

Hi Alex, kernel test robot noticed the following build errors: [auto build test ERROR on drm-exynos/exynos-drm-next] [also build test ERROR on next-20250507] [cannot apply to linus/master v6.15-rc5] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch

Re: [PATCH v3 1/7] drm/amdgpu: update XGMI physical node id and GMC configs on resume

On 5/7/2025 11:52 AM, Zhang, GuoQing (Sam) wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > > >   > >> Please keep in mind that this is not the only scenario addressed by the > >> driver - for ex: a resume sequence is executed after a device reset. > >> This patch itself

Re: [PATCH v2] drm/amdgpu: fix the indentation

Reviewed-by: Arvind Yadav On 5/7/2025 3:05 PM, Khatri, Sunil wrote: [AMD Official Use Only - AMD Internal Distribution Only] @Yadav, Arvind -Original Message- From: Sunil Khatri Sent: Wednesday, May 7, 2025 3:00 PM To: amd-gfx@lists.freedesktop.org; De

RE: [PATCH v2] drm/amdgpu: fix the indentation

[AMD Official Use Only - AMD Internal Distribution Only] @Yadav, Arvind -Original Message- From: Sunil Khatri Sent: Wednesday, May 7, 2025 3:00 PM To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Koenig, Christian Cc: Dan Carpenter ; Khatri, Sunil

[PATCH v2] drm/amdgpu: fix the indentation

fix the indentation drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:6992 gfx_v11_ip_dump compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 | Reported-by: kernel test robot | Reported-by: Dan Carpenter | Closes: https://lore.kernel.org/r/202505071619.7shtlpng-...@intel.com/ Signed-off-by: Sunil Khatri --- dri

[PATCH v1] drm/amdgpu: fix the indentation

fix the indentation drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:6992 gfx_v11_ip_dump compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 | Reported-by: kernel test robot | Reported-by: Dan Carpenter | Closes: https://lore.kernel.org/r/202505071619.7shtlpng-...@intel.com/ Signed-off-by: Sunil Khatri --- dri

Re: [PATCH 2/2] drm/amdgpu: log the user queue object PRT mapping

On 5/7/25 09:05, Liang, Prike wrote: > [Public] > >> -Original Message- >> From: Koenig, Christian >> Sent: Tuesday, May 6, 2025 10:09 PM >> To: Liang, Prike ; amd-gfx@lists.freedesktop.org >> Cc: Deucher, Alexander >> Subject: Re: [PATCH 2/2] drm/amdgpu: log the user queue object PRT ma

[PATCH 3/3] drm/amd/pm/smu13: Remove unused smu_v3 functions

From: "Dr. David Alan Gilbert" smu_v13_0_display_clock_voltage_request() and smu_v13_0_set_min_deep_sleep_dcefclk() were added in 2020 by commit c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)") but have remained unused. Remove them. smu_v13_0_display_clock_voltage_request() w

[PATCH 1/3] drm/amd/pm/smu7: Remove unused smu7_copy_bytes_from_smc

From: "Dr. David Alan Gilbert" smu7_copy_bytes_from_smc() was added in 2016 by commit 1ff55f465103 ("drm/amd/powerplay: implement smu7_smumgr for asics with smu ip version 7.") but never used. Remove it. Signed-off-by: Dr. David Alan Gilbert --- .../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c

questions about smu_mode2_reset_is_support and smu_v13_0_init_display_count

Hi, I noticed two functions that are unused but I wasn't sure what to do with them: smu_v13_0_init_display_count() isn't called/wired up, where as the v11 version is wired up: drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c 3574: .init_display_count = smu_v11_0_init_display_count, s

[PATCH 0/3] AMD gpu deadcoding (S)

From: "Dr. David Alan Gilbert" Hi, A bunch more deadcode around the AMD GPUs. (I've not done smu_v14 which all looks rather new to me, so perhaps you're still intending to use some of the unused functions). Signed-off-by: Dr. David Alan Gilbert Dr. David Alan Gilbert (3): drm/amd/pm/smu7:

[PATCH 2/3] drm/amd/pm/smu11: Remove unused smu_v11_0_get_dpm_level_range

From: "Dr. David Alan Gilbert" The last use of smu_v11_0_get_dpm_level_range() was removed in 2020 by commit 46a301e14e8a ("drm/amd/powerplay: drop unnecessary Navi1x specific APIs") Remove it. Signed-off-by: Dr. David Alan Gilbert --- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h | 5 --- .

RE: [PATCH 2/2] drm/amdgpu: log the user queue object PRT mapping

[Public] > -Original Message- > From: Koenig, Christian > Sent: Tuesday, May 6, 2025 10:09 PM > To: Liang, Prike ; amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander > Subject: Re: [PATCH 2/2] drm/amdgpu: log the user queue object PRT mapping > > On 5/6/25 15:34, Liang, Prike wrote: