[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Shaoyun.liu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, March 20, 2025 10:23 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/3] drm/amdgpu/mes: warn on une
Replace defines for the ones under smu_6_0_d.h and smu_6_0_sh_mask.h
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 338 +++--
drivers/gpu/drm/amd/pm/legacy-dpm/si_smc.c | 36 +--
2 files changed, 190 insertions(+), 184 deletions(-)
diff --git
It's not used outside of amdgpu_gfx.c.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/a
They will be used later when switching away from sid.h/si_enums.h.
Signed-off-by: Alexandre Demers
---
.../drm/amd/include/asic_reg/smu/smu_6_0_d.h | 44
.../include/asic_reg/smu/smu_6_0_sh_mask.h| 190 +-
2 files changed, 230 insertions(+), 4 deletions(-)
diff --git
The following series is intented to remove duplicated defines, shifts and masks
or
to classify them where they belong. si_enums.h has been used as a garbage can
for anything and everything when moving SI code from radeon to amdgpu.
Where needed, the defines found under sid.h and si_enums.h were
Now that we are using the proper defines, cleanup useless old "substituted"
defines.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/amd/amdgpu/sid.h | 1219 +-
1 file changed, 9 insertions(+), 1210 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sid.h b/dr
Removed unused function mpc401_get_3dlut_fast_load_status.
Signed-off-by: James Flowers
---
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 17 -
.../drm/amd/display/dc/mpc/dcn401/dcn401_mpc.c | 11 ---
.../drm/amd/display/dc/mpc/dcn401/dcn401_mpc.h | 14 -
On 3/28/2025 2:08 AM, Mario Limonciello wrote:
> From: Mario Limonciello
>
> checkpatch.pl complains about unnecessary error messages for failing
> to allocate memory. These aren't needed when the return code is -ENOMEM.
It's not about the error code. It conveys till what stage driver
proceed
This reverts commit fdb90033846e2f23dfaaa01dc47fec7b94704d0e.
Reportedly causing unknown issue in memory management code:
[ 128.047288] amdgpu :65:00.0: amdgpu: Failed to map peer::46:00.0
mem_domain:2
[...]
[ 137.815340] WARNING: CPU: 81 PID: 1006 at drivers/gpu/drm/ttm/ttm_bo.c:613
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Jesse Zhang
-Original Message-
From: amd-gfx On Behalf Of Jonathan Kim
Sent: Thursday, March 27, 2025 11:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Belanger, David ; Kasiviswanathan, Harish
; Kim, Jonathan
Subject:
The udl driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/udl/udl_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/udl/udl_main.
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Thursday, March 27, 2025 10:09 PM
To: Feng, Kenneth
Cc: amd-gfx@lists.freedesktop.org; Wang, Yang(Kevin) ;
Deucher, Alexander ; Wentland, Harry
Subject: Re: [PATCH] drm/amd/display: po
Hi Dave, Simona,
Fixes for 6.15.
The following changes since commit cf05922d63e2ae6a9b1b52ff5236a44c3b29f78c:
Merge tag 'drm-intel-gt-next-2025-03-12' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next (2025-03-25
08:21:07 +1000)
are available in the Git repository at:
https
Time for some thorough CI.
Also, the previous 18 patches could perhaps be replaced by a single
invocation of DYNDBG_CLASSMAP_USE, from a C-file linked into all drm
drivers & helpers. I didn't find such a file, nor a drm-client
linkage item in the Makefile.
Signed-off-by: Jim Cromie
---
drivers
On Thu, 2025-03-20 at 12:52 -0600, Jim Cromie wrote:
> we currently get:
> WARNING: Argument 'name' is not used in function-like macro
> on:
> #define DRM_CLASSMAP_USE(name) /* nothing here */
>
> Following this advice is wrong here, and shouldn't be fixed by
> ignoring args altogether; the m
On Tue, Mar 18, 2025 at 01:03:11PM +0100, Christian König wrote:
> Hi guys,
>
> as partially discussed on the list already amdgpu has a bug in it's gang
> submission code.
>
> Basic problem is to add the correct dependency to the gang leader we
> need to arm the other gang members first, but that
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start") removes the FP context protection of dml2_create(), and it said
"All the DC_FP_START/END should be used before call anything from DML2".
However, dml21_copy() are not protected from their callers, causing such
errors:
From: Mario Limonciello
As the driver uses drm_*() macros to print messages it's not necessary
to include amdgpu a second time in all messages.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12
drivers/gpu/drm/amd/pm/powerplay/inc/pp_debug.
On 3/27/25 21:53, Ingo Molnar wrote:
>
> * Balbir Singh wrote:
>
>>> Yes, turning off CONFIG_HSA_AMD_SVM fixes the issue, the strange memory
>>> resource
>>> afe-aff : :03:00.0
>>> is gone.
>>>
>>> If one would add a max_pyhs_addr argument to devm_request_free_mem_region()
>
From: Mario Limonciello
Messages emitted from amdgpu connector are currently with legacy DRM
macros. These don't show which device they are using. To make messages
clearer in multi-GPU systems adjust to drm_*() macros.
Signed-off-by: Mario Limonciello
---
.../gpu/drm/amd/amdgpu/amdgpu_connecto
From: Mario Limonciello
There is no matching function for amdgpu_ucode_print_imu_hdr().
Drop the prototype.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
b/drivers/gpu
From: Mario Limonciello
Messages emitted from amdgpu_atombios are currently with legacy DRM
macros. These don't show which device they are using. To make messages
clearer in multi-GPU systems adjust to drm_*() macros.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atomb
From: Mario Limonciello
Messages emitted from amdgpu_acpi are not device specific nor DRM
specific, but rather operate on ACPI handles. Adjust the messages
to use ACPI macros instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 22 --
1
From: Mario Limonciello
In order to be able to log messages specific to a GPU, add device
argument into the amdgpu_reset_create_reset_domain() function.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 3 ++-
From: Mario Limonciello
Several commits have gone in various parts of the driver already to
convert from DRM_*() and pr_*() to drm_*() macros, but a lot of places
are also still missing.
This updates a lot more of the driver. Patch 13 is the biggest one,
others are small tidbits and changes to s
From: Mario Limonciello
Messages emitted from amdgpu_ucode are currently with legacy DRM
macros. These don't show which device they are using. To make messages
clearer in multi-GPU systems adjust to drm_*() macros.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
From: Mario Limonciello
The errors for power consumption in amdgpu_acpi_is_s0ix_active() are
under device scope. As they're drm errors, adjust to drm scope.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Mario Limonciello
Messages emitted from atombios parser are currently with legacy DRM
macros. These don't show which device they are using. To make messages
clearer in multi-GPU systems adjust to drm_*() macros.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/atom.c
From: Mario Limonciello
To allow header printing to reflect the correct GPU, pass the device
into all functions.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_
From: Mario Limonciello
Messages emitted in amdgpu_vpe are currently device scope, but as
they are drm driver messages they should be drm scope. Adjust
accordingly.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c | 18 ++
1 file changed, 10 insertio
From: Mario Limonciello
In order for messages from amdgpu_gfx_parse_disable_cu() to be device
specific pass in the device to the function and adjust all callers.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 4 +
From: Mario Limonciello
checkpatch.pl complains about unnecessary error messages for failing
to allocate memory. These aren't needed when the return code is -ENOMEM.
Drop such a message from amdgpu_acpi_enumerate_xcc().
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acp
[Public]
Please add fixes tag, with that
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: Kim, Jonathan
Sent: Thursday, March 27, 2025 11:54 AM
To: amd-gfx@lists.freedesktop.org
Cc: Belanger, David ; Kasiviswanathan, Harish
; Kim, Jonathan
Subject: [PATCH] drm/amdkfd: li
[Public]
> -Original Message-
> From: Charles Han
> Sent: Thursday, March 27, 2025 12:05 AM
> To: Feng, Kenneth ; Deucher, Alexander
> ; Koenig, Christian
> ; airl...@gmail.com; sim...@ffwll.ch;
> s...@itb.spb.ru; Huang, Tim ; Zhang, Jesse(Jie)
> ; li...@treblig.org; Huang, Ray
> ; rex...
On Thu, Feb 13, 2025 at 2:08 AM Charles Han wrote:
>
> Remove the repeated word "the" in docs.
>
> Signed-off-by: Charles Han
Applied. Thanks!
Alex
> ---
> Documentation/gpu/amdgpu/display/dc-debug.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu
Reviewed-by: David Belanger
On 3/27/2025 11:53 AM, Jonathan Kim wrote:
> ASICs post GFX 9 are being flagged as SDMA per queue reset supported
> in the KGD but KFD and scheduler FW currently have no support.
> Limit SDMA queue reset capabilities to GFX 9.
>
> Signed-off-by: Jonathan Kim
> ---
>
From: Harry Wentland
Add kernel doc for AMD color pipeline.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
1 file changed, 102 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
remove workaround code for the early engineering samples
GC v9.4.3 SOCs with revID 0 - GFX 940 & 941 - from driver
Reviewed-by: Lijo Lazar
Signed-off-by: Apurv Mishra
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 14 ++
dr
Classmaps are stored in an elf section/array, but currently are
individually list-linked onto dyndbg's per-module ddebug_table for
operation. This is unnecessary.
Just like dyndbg's descriptors, classes are packed in compile order;
so even with many builtin modules employing multiple classmaps, ea
VFs on some IP verions are unable to access this register directly.
This register must be programmed before PSP ring is setup,
so use PSP VF mailbox directly.
Signed-off-by: Victor Skvortsov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 10
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h|
ASICs post GFX 9 are being flagged as SDMA per queue reset supported
in the KGD but KFD and scheduler FW currently have no support.
Limit SDMA queue reset capabilities to GFX 9.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 6 +++---
1 file changed, 3 insertions(+),
On Thu, Mar 27, 2025 at 12:16 AM Alexandre Demers
wrote:
>
> On Mon, Mar 24, 2025 at 2:21 PM Alex Deucher wrote:
> >
> > On Sat, Mar 22, 2025 at 2:48 PM Alexandre Demers
> > wrote:
> > >
> > > Bring things on a single line and fix spacing.
> > >
> > > Signed-off-by: Alexandre Demers
> > > ---
>
On Thu, Mar 27, 2025 at 10:29 AM Christian König
wrote:
>
> Only use GTT as a fallback if we already have a backing store. This
> prevents evictions when an application constantly allocates and frees new
> memory.
>
> Partially fixes
> https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833
Similar to KFD, prevent runtime pm while user queues are active.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 30 +
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv
Only use GTT as a fallback if we already have a backing store. This
prevents evictions when an application constantly allocates and frees new
memory.
Partially fixes
https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833985.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/
Am 27.03.25 um 13:02 schrieb Bert Karwatzki:
> devm_request_free_mem_region() places resources at the end of the
> physical address space, DIRECT_MAP_PHYSMEM_END. If the the dma mask
> of a pci device is smaller than DIRECT_MAP_PHSYMEM_END then this
> resource is not dma accessible by the device wh
Am 27.03.25 um 10:27 schrieb Prike Liang:
> Before locking and traversing the user queue invalidated BO list,
> it requires ensuring the VM done list is available.
No it doesn't. This patch here is just a no-op.
list_for_each_entry() works perfectly fine on empty lists.
Regards,
Christian.
>
On Thu, Mar 27, 2025 at 4:22 AM Feng, Kenneth wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> -Original Message-
> From: Alex Deucher
> Sent: Wednesday, March 26, 2025 11:08 PM
> To: Feng, Kenneth
> Cc: amd-gfx@lists.freedesktop.org; Wang, Yang(Kevin)
> ; Deucher
Am 27.03.25 um 10:37 schrieb SRINIVASAN SHANMUGAM:
> On 3/27/2025 2:54 PM, Christian König wrote:
> Over all this change doesn't seem to make much sense to me.
> Why exactly is isolation->spearhead not pointing to the dummy kernel job
> we submit?
Does the owner check or gang_subm
On Thu, Mar 27, 2025 at 5:37 AM SRINIVASAN SHANMUGAM
wrote:
>
>
> On 3/27/2025 2:54 PM, Christian König wrote:
>
>
> Over all this change doesn't seem to make much sense to me.
>
> Why exactly is isolation->spearhead not pointing to the dummy kernel job we
> submit?
>
> Does the owner check or ga
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start") removes the FP context protection of dml2_create(), and it said
"All the DC_FP_START/END should be used before call anything from DML2".
However, dml2_validate()/dml21_validate() are not protected from their
callers, ca
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start") removes the FP context protection of dml2_create(), and it said
"All the DC_FP_START/END should be used before call anything from DML2".
However, dml2_init()/dml21_init() are not protected from their callers,
causing su
devm_request_free_mem_region() places resources at the end of the
physical address space, DIRECT_MAP_PHYSMEM_END. If the the dma mask
of a pci device is smaller than DIRECT_MAP_PHSYMEM_END then this
resource is not dma accessible by the device which can cause the
device to fallback to using 32bit d
Reviewed-by: Alex Deucher
On Wed, Mar 26, 2025 at 8:23 AM Flora Cui wrote:
>
> Signed-off-by: Flora Cui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> b/drivers/gpu/drm/amd/amdgpu
Am Mittwoch, dem 26.03.2025 um 15:58 -0700 schrieb Linus Torvalds:
> On Wed, 26 Mar 2025 at 15:00, Bert Karwatzki wrote:
> >
> > As Balbir Singh found out this memory comes from amdkfd
> > (kgd2kfd_init_zone_device()) with CONFIG_HSA_AMD_SVM=y. The memory gets
> > placed
> > by devm_request_free_
* Balbir Singh wrote:
> > Yes, turning off CONFIG_HSA_AMD_SVM fixes the issue, the strange memory
> > resource
> > afe-aff : :03:00.0
> > is gone.
> >
> > If one would add a max_pyhs_addr argument to devm_request_free_mem_region()
> > (which return the resource addr in kgd
* Linus Torvalds wrote:
> On Wed, 26 Mar 2025 at 15:00, Bert Karwatzki wrote:
> >
> > As Balbir Singh found out this memory comes from amdkfd
> > (kgd2kfd_init_zone_device()) with CONFIG_HSA_AMD_SVM=y. The memory gets
> > placed
> > by devm_request_free_mem_region() which places the memory at
[Public]
> From: Alex Deucher
> Sent: Monday, March 24, 2025 10:20 PM
> To: Liang, Prike
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>
> Subject: Re: [PATCH v2 4/4] drm/amdgpu/gfx12: Implement the GFX12 KCQ pipe
> reset
>
> On Mon, Mar 24, 2025 at 8:01 AM Liang, Prike wrote:
> >
>
On 3/27/2025 2:54 PM, Christian König wrote:
Over all this change doesn't seem to make much sense to me.
Why exactly is isolation->spearhead not pointing to the dummy kernel job we
submit?
Does the owner check or gang_submit check in
amdgpu_device_enforce_isolation() fail to set up the spear
On 3/21/2025 06:37, Saleemkhan Jamadar wrote:
Update message to identifiy the vblank initialization fail case
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/displa
Before locking and traversing the user queue invalidated BO list,
it requires ensuring the VM done list is available.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 20 ++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/
>>> Over all this change doesn't seem to make much sense to me.
>>> Why exactly is isolation->spearhead not pointing to the dummy kernel job we
>>> submit?
>> Does the owner check or gang_submit check in
>> amdgpu_device_enforce_isolation() fail to set up the spearhead?
> I'm currently debugging
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Wednesday, March 26, 2025 11:08 PM
To: Feng, Kenneth
Cc: amd-gfx@lists.freedesktop.org; Wang, Yang(Kevin) ;
Deucher, Alexander ; Wentland, Harry
Subject: Re: [PATCH] drm/amd/display: p
Hello,
Now that the freedesktop server migration is almost done, it's time to
turn our attention on the 2025 X.Org Foundation elections, which are
rapidly approaching! We will be forwarding the election schedule and
nominating process to the membership shortly.
Please note that only current membe
The function atomctrl_initialize_mc_reg_table() and
atomctrl_initialize_mc_reg_table_v2_2() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table()
fails to retrieve vram_info, it returns NULL which is later
dereferenced.
Fixes: b3892e2bb519 ("drm/amd/pp: Use ato
Am Dienstag, dem 25.03.2025 um 13:23 +0100 schrieb Christian König:
> Am 25.03.25 um 11:14 schrieb Bert Karwatzki:
> > My /proc/iomem contans two memory areas of 8G size which are
> > belonging to PCI :03:00.0, one of the is the BAR reported by dmesg
> > [ 0.312692] [ T1] pci :03:00.0: BAR
On Wed, 26 Mar 2025 at 15:00, Bert Karwatzki wrote:
>
> As Balbir Singh found out this memory comes from amdkfd
> (kgd2kfd_init_zone_device()) with CONFIG_HSA_AMD_SVM=y. The memory gets placed
> by devm_request_free_mem_region() which places the memory at the end of the
> physical address space (D
On 3/20/2025 7:53 PM, Alex Deucher wrote:
> Warn if the number of pipes exceeds what the MES supports.
>
> Signed-off-by: Alex Deucher
Patches 1,2
Acked-by: Lijo Lazar
Patch 3
Reviewed-by: Lijo Lazar
Thanks,
Lijo
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 23 +
70 matches
Mail list logo
