Mario Limonciello writes:
> On 12/14/2023 10:36, Kalle Valo wrote:
>
>> Hans de Goede writes:
>>
>>> Hi Wifi and AMDGPU maintainers,
>>>
>>> Here is a pull-request for the platform-drivers-x86 parts of:
>>>
>>> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com
[AMD Official Use Only - General]
Reviewed-by: Yifan Zhang
-Original Message-
From: Ma, Li
Sent: Friday, December 15, 2023 11:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Feng, Kenneth
; Zhang, Yifan ; Yu, Lang
; Ma, Li
Subject: [PATCH v2] drm/amd/swsmu: remove du
[AMD Official Use Only - General]
Reviewed-by: Kenneth Feng
-Original Message-
From: Ma, Li
Sent: Friday, December 15, 2023 11:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Feng, Kenneth
; Zhang, Yifan ; Yu, Lang
; Ma, Li
Subject: [PATCH v2] drm/amd/swsmu: remove
There is a repeated define of smu v14_0_0 driver if version, so delete
one in driver if header.
Signed-off-by: Li Ma
---
.../drm/amd/pm/swsmu/inc/pmfw_if/smu14_driver_if_v14_0_0.h | 5 -
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v14_0.h | 2 +-
2 files changed, 1 insertion(+), 6
On 12/14/2023 03:53, Huang, Tim wrote:
[Public]
Hi Mario,
-Original Message-
From: Limonciello, Mario
Sent: Thursday, December 14, 2023 4:31 AM
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario ; sta...@vger.kernel.org; Huang,
Tim
Subject: [PATCH v2] drm/amd: Add a workaround
DMABuf imports in compute VMs are not wrapped in a kgd_mem object on the
process_info->kfd_bo_list. There is no explicit KFD API call to validate
them or add eviction fences to them.
This patch automatically validates and fences dymanic DMABuf imports when
they are added to a compute VM. Revalidat
This is not strictly a change in the IOCTL API. This version bump is meant
to indicate to user mode the presence of a number of changes and fixes
that enable the management of VA mappings in compute VMs using the GEM_VA
ioctl for DMABufs exported from KFD.
Signed-off-by: Felix Kuehling
---
inclu
[Public]
Hi all,
This week this patchset was tested on the following systems:
* Lenovo ThinkBook T13s Gen4 with AMD Ryzen 5 6600U
* MSI Gaming X Trio RX 6800
* Gigabyte Gaming OC RX 7900 XTX
These systems were tested on the following display/connection types:
* eD
Some issues have been raised that appear to be tied to PSR-SU.
To allow users to confirm they're tied to PSR-SU without turning off
PSR entirely introduce a new debug mask:
amdgpu.dcdebugmask=0x200
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 ++
It is reported that on a Topaz dGPU the kernel emits:
amdgpu: can't get the mac of 5
This is because there is no definition for max levels of VDDGFX
declared for SMU71 or SMU7. There is however an unused definition of
VDDNB. Use this to return the max levels for VDDGFX.
Link: https://gitl
On 2023-12-14 16:40, Felix Kuehling wrote:
Fence slot reservation should bet done by the caller and not here.
The caller doesn't necessarily have the BO list to create all those
fences. The whole point of doing this in the VM code was, to use the
"BO lists" maintained by the VM state machin
On 2023-12-13 09:30, Christian König wrote:
Am 06.12.23 um 22:44 schrieb Felix Kuehling:
DMABuf imports in compute VMs are not wrapped in a kgd_mem object on the
process_info->kfd_bo_list. There is no explicit KFD API call to validate
them or add eviction fences to them.
This patch automatica
On 2023-12-14 08:42, Arunpravin Paneer Selvam wrote:
Add clear page support in vram memory region.
v1:(Christian)
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
On Thu, Dec 14, 2023 at 3:06 PM Ori Messinger wrote:
>
> GFXOFF was previously disabled as a temporary workaround for GFX11
> due to issues in some compute applications.
> This patch re-enables GFXOFF for GFX version 11.
>
> V2: keep GFXOFF disabled on GFX11 if MES KIQ is below version 64.
>
> Sig
[Public]
> -Original Message-
> From: Melissa Wen
> Sent: Thursday, December 14, 2023 2:45 PM
> To: Wentland, Harry ; Li, Sun peng (Leo)
> ; Siqueira, Rodrigo ;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch
> Cc: kernel test robot ; amd-gf
On 2023-12-14 10:06, Alex Deucher wrote:
On Thu, Dec 14, 2023 at 9:24 AM Liu, Shaoyun wrote:
[AMD Official Use Only - General]
The gmc flush tlb function is used on both baremetal and sriov. But the
function amdgpu_virt_kiq_reg_write_reg_wait is defined in amdgpu_virt.c with
name 'v
On 2023-12-14 13:58, Philip Yang wrote:
On gfx943 APU there is VRAM and page migration,
Is there a "no" missing here?
queue CWSR area, svm
range with always mapped flag, is not mapped to GPU correctly. This
works fine if retry fault on CWSR area can be recovered, but could cause
deadlock
GFXOFF was previously disabled as a temporary workaround for GFX11
due to issues in some compute applications.
This patch re-enables GFXOFF for GFX version 11.
V2: keep GFXOFF disabled on GFX11 if MES KIQ is below version 64.
Signed-off-by: Ori Messinger
---
drivers/gpu/drm/amd/amdgpu/amdgpu_am
warning: expecting prototype for drm_crtc_additional_color_mgmt().
Prototype was for dm_crtc_additional_color_mgmt() instead
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312141801.o9ebcxt9-...@intel.com/
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/disp
On 12/14/2023 03:21, Christian König wrote:
Am 13.12.23 um 20:44 schrieb Alex Deucher:
On Wed, Dec 13, 2023 at 2:32 PM Mario Limonciello
wrote:
On 12/13/2023 13:12, Mario Limonciello wrote:
On 12/13/2023 13:07, Alex Deucher wrote:
On Wed, Dec 13, 2023 at 1:00 PM Mario Limonciello
wrote:
So
On 12/14, Alex Deucher wrote:
> It takes the plane state rather than the crtc state.
>
> Fixes: aba8b76baabd ("drm/amd/display: add plane shaper LUT support")
> Reported-by: Stephen Rothwell
> Signed-off-by: Alex Deucher
> Cc: Melissa Wen
> Cc: harry.wentl...@amd.com
> ---
> drivers/gpu/drm/am
On 2023-12-13 22:19, Jonathan Kim wrote:
Fix up on mes process context flush to prevent non-mes devices from
spamming error messages or running into undefined behaviour during
process termination.
Fixes: 73204d028eb5 ("drm/amdkfd: fix mes set shader debugger process
management")
Signed-off-by
On gfx943 APU there is VRAM and page migration, queue CWSR area, svm
range with always mapped flag, is not mapped to GPU correctly. This
works fine if retry fault on CWSR area can be recovered, but could cause
deadlock if there is another retry fault recover waiting for CWSR to
finish.
Fix this by
[AMD Official Use Only - General]
Jon Kim sent out the same patch ("drm/amdkfd: only flush mes process context if
mes support is there") yesterday.
> -Original Message-
> From: amd-gfx On Behalf Of Eric
> Huang
> Sent: Thursday, December 14, 2023 1:39 PM
> To: amd-gfx@lists.freedesktop.
On 2023-12-14 13:38, Eric Huang wrote:
The field adev->mes.funcs is NULL in function amdgpu_mes_flush_shader_debugger
on non-mes asics, add mes enabling check for call this func to
resolve the error.
Signed-off-by: Eric Huang
---
Reviewed-by: Philip Yang
The field adev->mes.funcs is NULL in function amdgpu_mes_flush_shader_debugger
on non-mes asics, add mes enabling check for call this func to
resolve the error.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deleti
The SW CTF handler assumes that the read_sensor() call always succeeds
and has updated `hotspot_tmp`, but this may not be guaranteed.
For example some of the read_sensor() callbacks will return 0 when a RAS
interrupt is triggered in which case `hotspot_tmp` won't be updated.
Adjust the logic to c
Applied. Thanks!
On Thu, Dec 14, 2023 at 12:20 PM Zhipeng Lu wrote:
>
> The amdgpu_free_extended_power_table is called in every error-handling
> paths of amdgpu_parse_extended_power_table. However, after the following
> call chain of returning:
>
> amdgpu_parse_extended_power_table
> |-> kv_dp
Applied. Thanks!
On Thu, Dec 14, 2023 at 11:59 AM Zhipeng Lu wrote:
>
> When radeon_bo_create and radeon_vm_clear_bo fail, the vm->page_tables
> allocated before need to be freed. However, neither radeon_vm_init
> itself nor its caller have done such deallocation.
>
> Fixes: 6d2f2944e95e ("drm/r
Applied. Thanks!
On Thu, Dec 14, 2023 at 11:57 AM Zhipeng Lu wrote:
>
> When ps allocated by kzalloc equals to NULL, kv_parse_power_table
> frees adev->pm.dpm.ps that allocated before. However, after the control
> flow goes through the following call chains:
>
> kv_parse_power_table
> |-> kv_d
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev->pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
|-> kv_dpm_init
|-> kv_dpm_sw_init
|-> kv_dpm_fini
The adev->pm.dpm.p
When radeon_bo_create and radeon_vm_clear_bo fail, the vm->page_tables
allocated before need to be freed. However, neither radeon_vm_init
itself nor its caller have done such deallocation.
Fixes: 6d2f2944e95e ("drm/radeon: use normal BOs for the page tables v4")
Signed-off-by: Zhipeng Lu
---
dri
The amdgpu_free_extended_power_table is called in every error-handling
paths of amdgpu_parse_extended_power_table. However, after the following
call chain of returning:
amdgpu_parse_extended_power_table
|-> kv_dpm_init / si_dpm_init
(the only two caller of amdgpu_parse_extended_power_table
Applied. Thanks!
On Thu, Dec 14, 2023 at 10:59 AM Zhipeng Lu wrote:
>
> When the allocation of
> adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
> amdgpu_free_extended_power_table is called to free some fields of adev.
> However, when the control flow returns to si_dpm_sw_init,
On 12/14/2023 10:36, Kalle Valo wrote:
Hans de Goede writes:
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
From my pov the pdx86 bits are ready and the
plat
Hans de Goede writes:
> Hi Wifi and AMDGPU maintainers,
>
> Here is a pull-request for the platform-drivers-x86 parts of:
>
> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
>
> From my pov the pdx86 bits are ready and the
> platform-drivers-x86-amd-wbrf-v6.8
When the allocation of
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
amdgpu_free_extended_power_table is called to free some fields of adev.
However, when the control flow returns to si_dpm_sw_init, it goes to
label dpm_failed and calls si_dpm_fini, which calls
amdgpu_free_extend
[AMD Official Use Only - General]
I remembered we try to use kiq directly send the invalidation packet to mec FW
with pasid as parameter since it's FW control the VMID and PASID mapping ,
but during some test , it shows performance drop compare to driver directly
get the vmid/pasid mapping
It takes the plane state rather than the crtc state.
Fixes: aba8b76baabd ("drm/amd/display: add plane shaper LUT support")
Reported-by: Stephen Rothwell
Signed-off-by: Alex Deucher
Cc: Melissa Wen
Cc: harry.wentl...@amd.com
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 2 +-
1
Applied. Thanks!
On Wed, Dec 13, 2023 at 8:02 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c:1418:2-3: Unneeded semicolon
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7743
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/pm/swsmu
On Thu, Dec 14, 2023 at 9:24 AM Liu, Shaoyun wrote:
>
> [AMD Official Use Only - General]
>
> The gmc flush tlb function is used on both baremetal and sriov. But the
> function amdgpu_virt_kiq_reg_write_reg_wait is defined in amdgpu_virt.c with
> name 'virt' make it appear as a SRIOV onl
[AMD Official Use Only - General]
The gmc flush tlb function is used on both baremetal and sriov. But the
function amdgpu_virt_kiq_reg_write_reg_wait is defined in amdgpu_virt.c with
name 'virt' make it appear as a SRIOV only function, this sounds confusion .
Will it make more sense to
Add clear page support in vram memory region.
v1:(Christian)
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
-
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared
On 2023-12-14 11:31, Christian König wrote:
> Am 13.12.23 um 16:46 schrieb Michel Dänzer:
>> From a security PoV, the kernel should never return uncleared memory to (at
>> least unprivileged) user space. This series seems like a big step in that
>> direction.
>
> Well please take a look at the M
Am 13.12.23 um 16:46 schrieb Michel Dänzer:
From a security PoV, the kernel should never return uncleared memory to (at
least unprivileged) user space. This series seems like a big step in that
direction.
Well please take a look at the MAP_UNINITIALIZED flag for mmap(). We
even have the fun
Am 13.12.23 um 21:31 schrieb Mario Limonciello:
Some systems with MP1 13.0.4 or 13.0.11 have a firmware bug that
causes the first MES packet after resume to fail. Typically this
packet is used to flush the TLB when GART is enabled.
This issue is fixed in newer firmware, but as OEMs may not ro
There is a repeated define of smu v14_0_0 driver if version, so delete
one and relocate the other define.
Signed-off-by: Li Ma
---
.../gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu14_driver_if_v14_0_0.h | 2 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v14_0.h| 2 +-
2 files changed, 2 in
[Public]
Hi Mario,
-Original Message-
From: Limonciello, Mario
Sent: Thursday, December 14, 2023 4:31 AM
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario ; sta...@vger.kernel.org;
Huang, Tim
Subject: [PATCH v2] drm/amd: Add a workaround for GFX11 systems that fail to
flush TL
Am 13.12.23 um 20:44 schrieb Alex Deucher:
On Wed, Dec 13, 2023 at 2:32 PM Mario Limonciello
wrote:
On 12/13/2023 13:12, Mario Limonciello wrote:
On 12/13/2023 13:07, Alex Deucher wrote:
On Wed, Dec 13, 2023 at 1:00 PM Mario Limonciello
wrote:
Some systems with MP1 13.0.4 or 13.0.11 have a
On 2023-12-11 6:23 AM, Michael Ellerman wrote:
> Hi Samuel,
>
> Thanks for trying to clean all this up.
>
> One problem below.
>
> Samuel Holland writes:
>> Now that all previously-supported architectures select
>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
>> of t
Samuel Holland writes:
> On 2023-12-11 6:23 AM, Michael Ellerman wrote:
>> Hi Samuel,
>>
>> Thanks for trying to clean all this up.
>>
>> One problem below.
>>
>> Samuel Holland writes:
>>> Now that all previously-supported architectures select
>>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can de
./drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c:1418:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7743
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
53 matches
Mail list logo
