[AMD Official Use Only - AMD Internal Distribution Only]
From: Chen, Xiaogang
Sent: Tuesday, January 7, 2025 8:20 AM
To: Yang, Philip ; Deng, Emily ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Fix partial migrate issue
On 1/6/2025 5:50 PM, Philip Yang wrote:
On 2025-01
[AMD Official Use Only - AMD Internal Distribution Only]
From: Chen, Xiaogang
Sent: Monday, January 6, 2025 11:27 PM
To: Deng, Emily ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Fix partial migrate issue
On 1/2/2025 6:06 PM, Emily Deng wrote:
For partial migrate from ram
[AMD Official Use Only - AMD Internal Distribution Only]
From: Yang, Philip
Sent: Tuesday, January 7, 2025 7:51 AM
To: Deng, Emily ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Fix partial migrate issue
On 2025-01-02 19:06, Emily Deng wrote:
For partial migrate from ram to
[AMD Official Use Only - AMD Internal Distribution Only]
>-Original Message-
>From: Kuehling, Felix
>Sent: Tuesday, January 7, 2025 4:53 AM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdkfd: Fix partial migrate issue
>
>
>On 2025-01-05 20:45, Deng, Emily wr
On 2025-01-02 19:06, Emily Deng wrote:
For partial migrate from ram to vram, the migrate->cpages is not
equal to migrate->npages, should use migrate->npages to check all needed
migrate pages which could be copied or not.
And only need to set those pages could be m
On 1/6/2025 5:50 PM, Philip Yang wrote:
On 2025-01-02 19:06, Emily Deng wrote:
For partial migrate from ram to vram, the migrate->cpages is not
equal to migrate->npages, should use migrate->npages to check all needed
migrate pages which could be copied or not.
And only need to set those page
[AMD Official Use Only - AMD Internal Distribution Only]
Ping
How about this? Currently it is easily to reproduce the issue on our
environment. We need this change to fix it.
Emily Deng
Best Wishes
>-Original Message-
>From: amd-gfx On Behalf Of Deng, Emily
>Sent: Monday, January
The fields are marked as reserved in atom_firmware_info_v3_1,
but thet contain valid data in all of the vbios images I've
looked at so add parse these fields as per
atom_firmware_info_v3_2. The offsets are the same and the
reset of the structure is the same.
Signed-off-by: Alex Deucher
---
driv
On 2025-01-05 20:45, Deng, Emily wrote:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Kuehling, Felix
Sent: Saturday, January 4, 2025 7:10 AM
To: Deng, Emily ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Fix partial migrate issue
This was leftover from when amdgpu was forked from radeon.
The function is empty so drop it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/d
On Fri, Jan 03, 2025 at 08:21:43AM +, Koenig, Christian wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Shuai,
>
> setting gpu_recovery=0 is not even remotely related to RAS. If that
> option affects RAS behavior in any way then that is a bug.
>
> The purpose of sett
Hi Matthew,
Ping?
Regards,
Arun.
On 12/26/2024 12:31 PM, Arunpravin Paneer Selvam wrote:
- Added a testcase to verify the multiroot force merge fini.
- Added a new field in_use to track the mm freed status.
v2:(Matthew)
- Add kunit_fail_current_test() when WARN_ON is true.
Signed-off-by:
Added debug logging to provide insights into KGD/KFD scheduling, cleaner
shader emission, and isolation processes.
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 30 +
drivers/gpu/drm/amd/amdgpu/amd
gfx12 derivatives will have substantially different trap handler
implementations from gfx10/gfx11. Add a separate source file for
gfx12+ and remove unneeded conditional code.
No functional change.
v2: Revert copyright date to 2018, minor comment fixes
Signed-off-by: Jay Cornwall
Cc: Lancelot Si
On Sun, Dec 29, 2024 at 01:58:19PM +0100, Andrey Albershteyn wrote:
> On 2024-12-18 16:35:21, Darrick J. Wong wrote:
> > On Tue, Dec 17, 2024 at 11:58:12PM +0100, Mirsad Todorovac wrote:
> > > The source static analysis tool gave the following advice:
> > >
> > > ./fs/xfs/libxfs/xfs_dir2.c:382:15-
At the momemt we only expose the i2c buses used by the driver
for displays or EEPROMs. However, some OEMs/AIBs use extra i2c
buses for things like RGB controls. Expose the extra i2c buses in
case the OEM uses one of them.
Alex Deucher (10):
drm/amd/display/dm: drop extra parameters to create_i2
link_index can be fetched from the ddc_service; no need for a separate
parameter. res is not used.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
Expose the OEM i2c bus on boards that support it.
This bus is used for OEM specific features like RGB, etc.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7
2 files changed, 42 inserti
No functional change. Rework the code to allow for
adding some additional i2c buses in conjunction with DC
in the future.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c| 8
drivers/gpu/drm/amd/amdgpu/am
DC supports SW i2c as well. Drop the check.
Signed-off-by: Alex Deucher
---
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/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.
Use the value pulled from the vbios just like newer chips.
Signed-off-by: Alex Deucher
---
.../dc/resource/dce120/dce120_resource.c| 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dce120/dce120_resource.c
b/drivers/gpu/drm/am
This is the i2c bus used by OEMs for board specific i2c features
like RGB.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link_exports.c | 6 ++
drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/d
It uses the VGADCC bus. DC doesn't use this bus, so it
is safe to add it here.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 32
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 13 +++-
Allow the creation of an OEM i2c bus and use the proper
DC helpers for that case.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
2 files changed, 21 insertions(+), 9 deletions(-)
diff
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Monday, January 6, 2025 11:59 PM
To: Feng, Kenneth
Cc: amd-gfx@lists.freedesktop.org; Pillai, Aurabindo
; Deucher, Alexander
Subject: Re: [PATCH 1/2] drm/amd/pm: add the interface to se
On 2024-12-31 13:42, Mischa Baars wrote:
>
> In the meantime I also checked the framerate synchronization through
> glxgears at different resolutions and framerates. This does function
> as expected. Although I haven't yet inspected the glxgears source
> codes in detail, the OpenGL double bufferin
On Mon, Jan 6, 2025 at 1:32 AM Tim Huang wrote:
>
> The RB bitmap should be global active RB bitmap &
> active RB bitmap based on active SA.
>
> Signed-off-by: Tim Huang
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 7 +--
> 1 file changed, 5 inser
[AMD Official Use Only - AMD Internal Distribution Only]
Just for my personal edification, do we need __func__ for *_dbg calls? We can
already add the function name when enabling dyndbg with +f , and the messages
are unique here so there's no real need for an identifier. Just wondering if my
as
Made changes to the doorbell mapping func more generic,
by taking parameters that vary based on IPs and/or usecase
into db_info structure.
Signed-off-by: Saleemkhan Jamadar
]
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 27 +++
.../gpu/drm/amd/include/amdgpu_userqueue.h
Alex Deucher wrote:
> On Mon, Dec 23, 2024 at 4:08 AM Siva Mahadevan wrote:
> >
> > #regzbot introduced: 99a02eab8
> >
> > Observed behaviour:
> > linux-stable v6.12.5 has a regression on my thinkpad e495 where
> > suspend/resume of the laptop results in my backlight brightness settings
> > to b
On 2025-01-05 23:31, Pierre Asselin wrote:
Alex Deucher wrote:
Please file a ticket here:
https://gitlab.freedesktop.org/drm/amd/-/issues
and attach your full dmesg output and we'll take a look.
See https://gitlab.freedesktop.org/drm/amd/-/issues/3879 .
Sorry for the stray email earlier.
--P
Alex Deucher wrote:
> On Mon, Dec 23, 2024 at 4:08 AM Siva Mahadevan wrote:
> >
> > #regzbot introduced: 99a02eab8
> >
> > Observed behaviour:
> > linux-stable v6.12.5 has a regression on my thinkpad e495 where
> > suspend/resume of the laptop results in my backlight brightness settings
> > to b
> 2025年1月5日 13:22，Shuo Liu 写道：
>
> Hi Gerry,
>
> On Sun 5.Jan'25 at 10:45:29 +0800, Jiang Liu wrote:
>> Fix possible resource leakage on error recovery path in function
>> kgd2kfd_device_init().
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 9 +
>
Hey,
On 06/01/2025 12:37, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
Ping?
Just got back from time off. I already slapped an r-b here:
https://lore.kernel.org/dri-devel/aa27455c-04b8-494c-a3b5-c4385a774...@intel.com/
Regards,
Arun.
On 12/26/2024 12:31 PM, Arunpravin Paneer Selvam wrot
SPL_ASSERT() is actually SPL_ASSERT_WARN() according to the macro
definition in drivers/gpu/drm/amd/display/dc/spl/spl_debug.h, just
replace the macro name SPL_ASSERT() with explicit SPL_ASSERT_WARN()
to avoid ambiguous.
Here is the one-line script:
sed -i "s/\/SPL_ASSERT_WARN/g" `grep SPL_ASSE
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
VCN and VPE have different offset range, update the doorbell
offset range repsectively.
Doorbell size for VCN and VPE is 32bit.
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_userqueue.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm
This structure basically used to the populate the doorbell
information that is required to be mapped.
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/include/amdgpu_userqueue.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/include/amdgpu_userqueue.h
b/
Hi,
Why:
The current implementation of doorbell mapping does not handle the
IP specific doorbell size and offset range. Multiple doorbell
allocation when requested cannot be allocated due hard use of
"struct amdgpu_usermode_queue" parameters. But these parameters vary
for each request of doorbell
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
On 2025-01-06 04:45, Dmitry Baryshkov wrote:
> On Mon, 6 Jan 2025 at 10:55, Maxime Ripard wrote:
>>
>> On Mon, Jan 06, 2025 at 12:47:07AM +0200, Dmitry Baryshkov wrote:
>>> On Sat, Dec 14, 2024 at 03:37:04PM +0200, Dmitry Baryshkov wrote:
While working on the generic mode_valid() implement
On 1/2/2025 6:06 PM, Emily Deng wrote:
For partial migrate from ram to vram, the migrate->cpages is not
equal to migrate->npages, should use migrate->npages to check all needed
migrate pages which could be copied or not.
And only need to set those pages could be migrated to migrate->dst[i], or
On Wed, Dec 25, 2024 at 3:08 AM Kenneth Feng wrote:
>
> add the interface to set and save the bootup workload type
>
> Signed-off-by: Kenneth Feng
> ---
> drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 27 +++
> drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 3 +++
> drivers/g
Applied. Thanks!
On Thu, Dec 19, 2024 at 6:46 PM Nathan Chancellor wrote:
>
> Commit 24909d9ec7c3 ("drm/amd/display: Overwriting dualDPP UBF values
> before usage") added a new warning in dml2/display_mode_core.c when
> building allmodconfig with clang:
>
> drivers/gpu/drm/amd/amdgpu/../displa
For partial migrate from ram to vram, the migrate->cpages is not
equal to migrate->npages, should use migrate->npages to check all needed
migrate pages which could be copied or not.
And only need to set those pages could be migrated to migrate->dst[i], or
the migrate_vma_pages will migrate the wro
refill the ucode bo during psp resume for SRIOV, otherwise ucode load
will fail after VM hibernation and fb clean.
Signed-off-by: Victor Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu
On Mon, Jan 06, 2025 at 12:47:07AM +0200, Dmitry Baryshkov wrote:
> On Sat, Dec 14, 2024 at 03:37:04PM +0200, Dmitry Baryshkov wrote:
> > While working on the generic mode_valid() implementation for the HDMI
> > Connector framework I noticed that unlike other DRM objects
> > drm_connector accepts n
Hi
Am 05.01.25 um 23:47 schrieb Dmitry Baryshkov:
On Sat, Dec 14, 2024 at 03:37:04PM +0200, Dmitry Baryshkov wrote:
While working on the generic mode_valid() implementation for the HDMI
Connector framework I noticed that unlike other DRM objects
drm_connector accepts non-const pointer to struc
On Mon, 6 Jan 2025 at 10:55, Maxime Ripard wrote:
>
> On Mon, Jan 06, 2025 at 12:47:07AM +0200, Dmitry Baryshkov wrote:
> > On Sat, Dec 14, 2024 at 03:37:04PM +0200, Dmitry Baryshkov wrote:
> > > While working on the generic mode_valid() implementation for the HDMI
> > > Connector framework I noti
On 26/12/2024 07:01, Arunpravin Paneer Selvam wrote:
- Added a testcase to verify the multiroot force merge fini.
- Added a new field in_use to track the mm freed status.
I guess this is out of date now?
v2:(Matthew)
- Add kunit_fail_current_test() when WARN_ON is true.
Signed-off-by: Ar
52 matches
Mail list logo
