There are objtool warnings compiled with the latest mainline LLVM:
dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
Here are the call paths:
dc_fixpt_recip()
dc_fixpt_from_fraction()
complete_integer
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/os_types.h | 5 +
1 file changed, 5 inserti
As far as I can tell, with the current existing macro definitions, there
is no better way to do the minimal and proper changes to stop the control
flow if the divisior is zero.
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, it is better
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add SPL_ASSERT_BUG() macro definition
to harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/spl_debug.h | 9 +
1 file chang
Hi, Tiezhu,
On Tue, Jan 14, 2025 at 2:16 PM Tiezhu Yang wrote:
>
> In order to keep the current ability for the aim of debugging and avoid
> printing the warning message twice, add ASSERT_BUG() macro definition to
> harden the callers of division functions.
>
> Signed-off-by: Tiezhu Yang
> ---
>
Hi Gerry,
Am 14.01.25 um 12:03 schrieb Gerry Liu:
2025年1月14日 18:46，Christian König 写道：
Hi Jiang,
Some of the firmware, especially the multimedia ones, keep FW pointers to
buffers in the suspend/resume state.
In other words the firmware needs to be in the exact same location before and
afte
On Tue, 17 Dec 2024 23:58:12 +0100, Mirsad Todorovac wrote:
> The source static analysis tool gave the following advice:
>
> ./fs/xfs/libxfs/xfs_dir2.c:382:15-22: WARNING opportunity for kmemdup
>
> → 382 args->value = kmalloc(len,
>383 GFP_KERNEL | __GFP_NOL
> 2025年1月14日 18:46，Christian König 写道：
>
> Hi Jiang,
>
> Some of the firmware, especially the multimedia ones, keep FW pointers to
> buffers in the suspend/resume state.
>
> In other words the firmware needs to be in the exact same location before and
> after resume. That's why we don't un
When resume on a different SR-IOV vGPU device, the VRAM base addresses
may have changed. So we need to update those cached addresses.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h| 6 --
drivers/gpu/
For virtual machines with AMD SR-IOV vGPUs, following work flow may be
used to support virtual machine hibernation(suspend):
1) suspends a virtual machine with AMD vGPU A.
2) hypervisor dumps guest RAM content to a disk image.
3) hypervisor loads the guest system image from disk.
4) resumes the gue
Introduce helper amdgpu_bo_get_pinned_gpu_addr(), which will be
used to update GPU address of pinned kernel BO during resume.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/am
'commit 6e66dc05b54f ("drm/amdgpu: set the VM pointer to NULL in
amdgpu_job_prepare")' set job->vm as NULL if there is no fence. It will
cause emit switch buffer be skippen if job->vm set as NULL.
Check job rather than vm could solve this problem.
Signed-off-by: Lin.Cao
---
drivers/gpu/drm/amd/
On Tue, 17 Dec 2024 23:58:10 +0100, Mirsad Todorovac wrote:
> The static analyser tool gave the following advice:
>
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity for
> kmemdup
>
> → 1266 tmp = kmalloc(used_size, GFP_KERNEL);
>1267 if (!tmp)
>
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 height alignment in rows
5 bits for log2 offset
Am 14.01.25 um 10:54 schrieb Jiang Liu:
Introduce helper amdgpu_bo_get_pinned_gpu_addr(), which will be
used to update GPU address of pinned kernel BO during resume.
Clear NAK to the whole approach. Pinned means that the address *never*
changes.
Hacks like those here are a complete no-go sin
Hi Jiang,
Some of the firmware, especially the multimedia ones, keep FW pointers
to buffers in the suspend/resume state.
In other words the firmware needs to be in the exact same location
before and after resume. That's why we don't unpin the firmware BOs, but
rather save their content and r
[Public]
> -Original Message-
> From: Liang, Prike
> Sent: Tuesday, January 14, 2025 12:15 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ; Kim,
> Jonathan ; Liang, Prike
> Subject: [PATCH] drm/amdgpu: validate process_context_addr
Hi
Am 14.01.25 um 14:46 schrieb Thomas Zimmermann:
Hi
Am 15.12.24 um 21:53 schrieb Marek Olšák:
The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
Signed-off-by: Marek Olšák
diff --git a/include/uapi/drm/drm_fourcc.h
b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62e..8ec4163
On Mon, Jan 13, 2025 at 8:27 PM Zhang, Jesse(Jie) wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Ping ...
>
Series is:
Reviewed-by: Alex Deucher
> -Original Message-
> From: jesse.zh...@amd.com
> Sent: Friday, January 10, 2025 1:22 PM
> To: amd-gfx@lists.freede
On Tue, Jan 14, 2025 at 9:05 AM SyntheticBird
wrote:
>
> Hello and happy new year to all members of this list.
>
> I know that mailing lists aren't meant for begging for support, but after
> discussing this in another distribution channel, it seems to me like it is
> the only way for me and othe
SVM migration unmap pages from GPU and then update mapping to GPU to
recover page fault. Currently unmap clears the PDE entry for range
length >= huge page and free PTB bo, update mapping to alloc new PT bo.
There is race bug that the freed entry bo maybe still on the pt_free
list, reused when upda
Hi
Am 15.12.24 um 21:53 schrieb Marek Olšák:
The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
Signed-off-by: Marek Olšák
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62e..8ec4163429014 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/
Hello and happy new year to all members of this list.
I know that mailing lists aren't meant for begging for support, but after
discussing this in another distribution channel, it seems to me like it is the
only way for me and other users to grab the attention of a maintainer.
Since 6.12.1, sev
On 01/14/2025 04:29 PM, Huacai Chen wrote:
Hi, Tiezhu,
On Tue, Jan 14, 2025 at 2:16 PM Tiezhu Yang wrote:
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
There are objtool warnings compiled with the latest mainline LLVM:
dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
Here are the call paths:
dc_fixpt_recip()
dc_fixpt_from_fraction()
complete_integer
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add SPL_ASSERT_BUG() macro definition
to harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/spl/spl_debug.h | 11 +++
1 file ch
This patch removes useless NULL pointer checks in functions like
ci_set_private_data_variables_based_on_pptable() and
ci_setup_default_dpm_tables().
The pointers in question are initialized as addresses to existing
structures such as rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk by
utilizing & op
As far as I can tell, with the current existing macro definitions, there
is no better way to do the minimal and proper changes to stop the control
flow if the divisior is zero.
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, it is better
In order to keep the current ability for the aim of debugging and avoid
printing the warning message twice, add ASSERT_BUG() macro definition to
harden the callers of division functions.
Signed-off-by: Tiezhu Yang
---
drivers/gpu/drm/amd/display/dc/os_types.h | 7 +++
1 file changed, 7 inser
On Mon, Jan 13, 2025 at 9:20 PM Wang, Yang(Kevin)
wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 14, 2025 01:08
> To: Deucher, Alexander
> Cc: amd-gfx@lists.freedesktop.org
>
On Tue, Jan 14, 2025 at 5:37 AM Carlos Maiolino wrote:
>
> On Tue, 17 Dec 2024 23:58:10 +0100, Mirsad Todorovac wrote:
> > The static analyser tool gave the following advice:
> >
> > ./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity
> > for kmemdup
> >
> > → 1266
On Tue, Jan 14, 2025 at 09:27:59AM -0500, Alex Deucher wrote:
> On Tue, Jan 14, 2025 at 5:37 AM Carlos Maiolino wrote:
> >
> > On Tue, 17 Dec 2024 23:58:10 +0100, Mirsad Todorovac wrote:
> > > The static analyser tool gave the following advice:
> > >
> > > ./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.
[Public]
> -Original Message-
> From: Lazar, Lijo
> Sent: Friday, January 10, 2025 10:37 PM
> To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
> Cc: Kasiviswanathan, Harish
> Subject: Re: [PATCH] drm/amdgpu: fix gpu recovery disable with per queue reset
>
>
>
> On 1/11/2025 2:53 AM, Kim
I don't see how that fits in the current modifier usage patterns. I'm
not clear how applications are supposed to programmatically "look at the
modifiers of other drivers to find commonalities," nor how that "keeps
"expectations the same as today for simplicity.". I think replacing the
existing
Hi,
On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
Well yes, not just for simplicity, but because everything stops
working if you don't.
> The new linear modifier definition
[AMD Official Use Only - AMD Internal Distribution Only]
I think to resume with different SRIOV vGPUs depends on the hypervisor has the
live migration support . Different Hypervisor have different implementation ,
basically it will call into the host gpu driver in different stage and host
s
This needs to be kerneldoc formatted.
Fixes: 7594874227e1 ("drm/amd/display: add CEC notifier to amdgpu driver")
Reported-by: Stephen Rothwell
Signed-off-by: Alex Deucher
Cc: Kun Liu
---
drivers/gpu/drm/amd/include/amd_shared.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On January 14, 2025 03:39:45 Marek Olšák wrote:
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 h
From: Aurabindo Pillai
Some monitors flicker when subvp is enabled which maybe related to
an uncommon timing they use. To isolate such issues, add a debug
option to help isolate this the issue for debugging.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On Sat, Jan 11, 2025 at 02:57:42PM +0800, Tiezhu Yang wrote:
> Hi Josh and Peter,
>
> On 12/17/2024 09:08 AM, Tiezhu Yang wrote:
> > This version is based on tip/tip.git objtool/core branch [1], add some weak
> > and arch-specific functions to make the generic code more readable, tested
> > with t
From: "jesse.zh...@amd.com"
pmfw now unifies PPSMC_MSG_ResetSDMA definitions for different devices.
PPSMC_MSG_ResetSDMA2 is not needed.
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_ppsmc.h | 1 -
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
From: "jesse.zh...@amd.com"
This patch refactors the firmware version checks in `smu_v13_0_6_reset_sdma`
to support multiple SMU programs with different firmware version thresholds.
Signed-off-by: Jesse Zhang
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 14 +-
1 file ch
From: "jesse.zh...@amd.com"
pmfw unified PPSMC_MSG_ResetSDMA definitions for different devices.
PPSMC_MSG_ResetSDMA2 is not needed.
Signed-off-by: Jesse Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 30 +--
1 file changed, 8 insertions(+), 22 deletions(-)
diff --gi
> 2025年1月15日 02:00，Liu, Shaoyun 写道：
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> I think to resume with different SRIOV vGPUs depends on the hypervisor has
> the live migration support . Different Hypervisor have different
> implementation , basically it will call into
Is this "ignore" something we could do at the core DRM level, instead
of doing it in all drivers? e.g. by silently ignoring user-space requests
to set the property?
It sounds like this codepath still resets the colorspace to sRGB, which
is later overwritten by colorops pulled in the atomic state a
Reviewed-by: Simon Ser
> 2025年1月15日 12:03，Liu, Shaoyun 写道：
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> I might misunderstood your requirement . For live migration, it's transparent
> to the guest. The guest can be in running state (ex. like running some
> compute stuff), hypervisor
On Tue, Jan 14, 2025 at 1:34 PM Faith Ekstrand wrote:
> On January 14, 2025 03:39:45 Marek Olšák wrote:
>
>> I would keep the existing modifier interfaces, API extensions, and
>> expectations the same as today for simplicity.
>>
>> The new linear modifier definition (proposal) will have these fi
When a GPU job times out, the driver attempts to recover by restarting
the scheduler. Previously, the scheduler was restarted with an error
code of 0, which does not distinguish between a full GPU reset and a
queue reset. This patch changes the error code to -ENODATA for queue
resets, while -ECANCE
On Tue, Jan 14, 2025 at 12:55 PM James Jones wrote:
> I don't see how that fits in the current modifier usage patterns. I'm
> not clear how applications are supposed to programmatically "look at the
> modifiers of other drivers to find commonalities," nor how that "keeps
> "expectations the same
MES internal will check CP_MES_MSCRATCH_LO/HI register to set scratch data
location
during ucode start, driver side need to start the MES one by one with different
setting for each pipe
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 43 +++---
1 file
On Tue, Jan 14, 2025 at 3:49 PM Marco Moock wrote:
>
> Hello!
>
> This might be related to
> https://lists.freedesktop.org/archives/amd-gfx/2025-January/118759.html
> As I subscribed just now, I can't reply there and can't get the
> Message-I
>
>description: Motherboard
>product: P
From: Harish Kasiviswanathan
build_grace_period_packet_info is asic helper function that fetches the
correct format. It is the responsibility of the caller to validate the
value.
Signed-off-by: Harish Kasiviswanathan
Signed-off-by: Elena Sakhnovitch
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gf
From: Harish Kasiviswanathan
Set more optimized queue retry timeout for gfx9 family starting with
arcturus.
Signed-off-by: Harish Kasiviswanathan
Signed-off-by: Elena Sakhnovitch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h
From: Harish Kasiviswanathan
Currently, grace period is modified only for gfx943 APU. In the future
this might need to be set for other ASICs too. Either ways, asic
specific values should be handled by asic specific functions.
Signed-off-by: Harish Kasiviswanathan
Signed-off-by: Elena Sakhnovit
On Tue, Jan 14, 2025 at 1:31 PM wrote:
>
> From: Aurabindo Pillai
>
> Some monitors flicker when subvp is enabled which maybe related to
> an uncommon timing they use. To isolate such issues, add a debug
> option to help isolate this the issue for debugging.
>
> Signed-off-by: Aurabindo Pillai
Hello!
This might be related to
https://lists.freedesktop.org/archives/amd-gfx/2025-January/118759.html
As I subscribed just now, I can't reply there and can't get the
Message-I
description: Motherboard
product: Pro A520M-C II
vendor: ASUSTeK COMPUTER INC.
physical id:
[AMD Official Use Only - AMD Internal Distribution Only]
I might misunderstood your requirement . For live migration, it's transparent
to the guest. The guest can be in running state (ex. like running some
compute stuff), hypervisor and gim driver together will handle the GPU HW
state
On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> > I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
>
> Well yes, not just for simplicity, but because everything st
59 matches
Mail list logo
