Am 27.10.22 um 02:25 schrieb Ao Zhong:
After moving all FPU code to the DML folder, we can enable DCN support
for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the
code in the DML folder that needs to use hardware FPU, and add a control
mechanism for ARM Neon.
It's nice to see t
Am 26.10.22 um 21:36 schrieb Alex Deucher:
From: Mukul Joshi
Cleanup kfd_dev struct by removing ddev and pdev as both
drm_device and pci_dev can be fetched from amdgpu_device.
Signed-off-by: Mukul Joshi
Tested-by: Amber Lin
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Acked-by
Am 26.10.22 um 21:03 schrieb Mario Limonciello:
If a system does not have swap and memory is under 100% usage,
amdgpu will fail to evict resources. Currently the suspend
carries on proceeding to reset the GPU:
```
[drm] evicting device resources failed
[drm:amdgpu_device_ip_suspend_phase2 [amdg
Update GPU Scheduler maintainer email.
Cc: Alex Deucher
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: AMD Graphics
Cc: Direct Rendering Infrastructure - Development
Signed-off-by: Luben Tuikov
Acked-by: Christian König
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1
Hi Shaoyun,
yes, absolutely. If you say that this is ok then I'm fine with that as well.
Thanks,
Christian.
Am 26.10.22 um 20:13 schrieb Liu, Shaoyun:
[AMD Official Use Only - General]
The SRIOV already has its own reset routine amdgpu_device_reset_sriov, we try
to put the sriov specific se
Hello Alex,
Regarding below patch, I guess we need to pick "8eb402f16d5b drm/amdgpu: Fix
uninitialized warning in mmhub_v2_0_get_clockgating()" together, otherwise,
build will possibly fail. Is it true?
" Lijo Lazar (1):
drm/amdgpu: Remove ATC L2 access for MMHUB 2.1.x"
Regards,
Guchun
Hi Felix,
On 10/27/2022 3:07 AM, Felix Kuehling wrote:
> On 2022-10-26 05:03, Ma Jun wrote:
>> Init and save the base cu processor id for later use
>>
>> Signed-off-by: Ma Jun
>> ---
>> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 20 +---
>> drivers/gpu/drm/amd/amdkfd/kfd_priv.h |
Hi Dave, Daniel,
Fixes for 6.1. Fixes for new IPs and misc other fixes.
The following changes since commit cbc543c59e8e7c8bc8604d6ac3e18a029e3d5118:
Merge tag 'drm-misc-fixes-2022-10-20' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-10-21 09:56:14
+1000)
are available
Hi Rodrigo,
Thanks for your review! This is my first time submitting a patch to the kernel.
I'm not very good at using these tools yet. 😂
Recently I got a Huawei Qingyun W510 (擎云 W510) ARM workstation
from the second-hand market in China. It's SBSA and has a Kunpeng 920 (3211k)
SoC
with 24 Hu
After moving all FPU code to the DML folder, we can enable DCN support
for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the
code in the DML folder that needs to use hardware FPU, and add a control
mechanism for ARM Neon.
Signed-off-by: Ao Zhong
---
drivers/gpu/drm/amd/display/Kc
Hello everyone,
Recently I got a SBSA ARM64 workstation, and try to use it as my daily
drive machine after installing an AMD RX6400 graphics card.
Since the newer AMD GPUs require DCN (Display Core Next) support to work
properly, DCN is not supported on ARM64 platforms. Because some code in
DCN n
From: Jay Cornwall
With corresponding FW change fixes issue where triggering CWSR on a
workgroup with waves in s_barrier wouldn't lead to a back-off and
therefore cause a hang.
Signed-off-by: Jay Cornwall
Tested-by: Graham Sider
---
.../gpu/drm/amd/amdkfd/cwsr_trap_handler.h| 764
On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote:
> Ok, so this is a local customization to what is already a custom BIOS
> for a custom motherboard. There is a lot of custom in that sentence and
> TBH at some point things might become too custom for them to be expected
> to work OOTB
On 2022-10-25 22:00, Yang Li wrote:
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
The patch is
Reviewed-by: Felix Kuehling
I applied to our
Temporary workaround to fix issues observed in some compute applications
when GFXOFF is enabled on GFX11.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gp
From: Mukul Joshi
Cleanup kfd_dev struct by removing ddev and pdev as both
drm_device and pci_dev can be fetched from amdgpu_device.
Signed-off-by: Mukul Joshi
Tested-by: Amber Lin
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
On 2022-10-26 05:03, Ma Jun wrote:
Init and save the base cu processor id for later use
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 20 +---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +++
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/
If a system does not have swap and memory is under 100% usage,
amdgpu will fail to evict resources. Currently the suspend
carries on proceeding to reset the GPU:
```
[drm] evicting device resources failed
[drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block
failed -12
[drm
[AMD Official Use Only - General]
The SRIOV already has its own reset routine amdgpu_device_reset_sriov, we try
to put the sriov specific sequence inside this function. For the rest
part(re-submitting etc ) we should try to have the same behavior as bare-metal.
Can we just don't do the re-su
On 10/26/22 06:01, gehao...@163.com wrote:
From: gehao
In dce6(0,1,4)_create_resource_pool and dce8(0,1)_create_resource_pool
the allocated memory should be released if construct pool fails.
Signed-off-by: gehao
---
drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 3 +++
drivers/
[Public]
> -Original Message-
> From: Hung, Alex
> Sent: Wednesday, October 26, 2022 12:34
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Limonciello, Mario
>
> Cc: Siqueira, Rodrigo ; Hung, Alex
>
> Subject: [PATCH] ACPI: x86: s2idle: Revmoe unused variable hid
This unused variable can cause build failures with allmodconfig, and
therefore it should be removed.
Note: this does not applied to mainline (included in 100a57379380) but
to amd-staging-drm-next only.
Fixes: 6648f8587530 ("ACPI: x86: s2idle: Move _HID handling for AMD systems
into structures")
The problem is that this re-submitting is currently an integral part of
how SRIOV works.
The host can send a function level reset request to the clients when it
sees that some schedule switching didn't worked as expected and in this
case (and only this case) the hardware has actually never sta
This stuff I assume:
https://github.com/RadeonOpenCompute/rocm_smi_lib/tree/master/tests/rocm_smi_test
https://docs.amd.com/bundle/ROCm-System-Management-Interface-Guide/page/ROCm-System-Managment.html#building-tests
Regards
Den ons 26 okt. 2022 kl 17:43 skrev Yury Zhuravlev :
>
>
> On Wed, Oc
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 60eac8672b5b6061ec07499c0f1b79f6d94311ce Add linux-next specific
files for 20221026
Warning reports:
https://lore.kernel.org/linux-mm/202210090954.ptr6m6rj-...@intel.com
https
On 10/26/22 07:13, Ao Zhong wrote:
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_luma = 0;
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_chroma = 0;
these two operations in dcn32/dcn32_resource.c still need to use FPU,
This will cause compilation to fail on ARM64 platforms because
-mgenera
[AMD Official Use Only - General]
The user space shouldn't care about SRIOV or not , I don't think we need to
keep the re-submission for SRIOV as well. The reset from SRIOV could trigger
the host do a whole GPU reset which will have the same issue as bare metal.
Regards
Shaoyun.liu
-
On Wed, Oct 26, 2022 at 11:38 PM Alex Deucher wrote:
> On Wed, Oct 26, 2022 at 5:07 AM Yury Zhuravlev wrote:
> >
> > Hello Asher,
> >
> > Thanks for the information, is it open-source tests? Can I reproduce it?
> >
> > Also, it seems like Radeon Instinct MI25 was released before Radeon RX
> Vega
Re-submitting IBs by the kernel has many problems because pre-
requisite state is not automatically re-created as well. In
other words neither binary semaphores nor things like ring
buffer pointers are in the state they should be when the
hardware starts to work on the IBs again.
Additional to tha
As far as I can see this is not really recoverable since a PCI reset
clears VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev
This interface is not working as it should.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index bb28f31bf
Remove some not implemented function define
Signed-off-by: Christian König
---
include/drm/gpu_scheduler.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index c564be29c5ae..d646ff2fd557 100644
--- a/include/drm/gpu_scheduler.h
+++ b/
This reverts commit e6c6338f393b74ac0b303d567bb918b44ae7ad75.
This feature basically re-submits one job after another to
figure out which one was the one causing a hang.
This is obviously incompatible with gang-submit which requires
that multiple jobs run at the same time. It's also absolutely
no
On Wed, Oct 26, 2022 at 5:07 AM Yury Zhuravlev wrote:
>
> Hello Asher,
>
> Thanks for the information, is it open-source tests? Can I reproduce it?
>
> Also, it seems like Radeon Instinct MI25 was released before Radeon RX Vega,
> is it possible that they have different PowerPlay subsystems?
Sam
Hi,
On 10/26/22 01:40, Matthew Garrett wrote:
> On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
>
>> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
>> drivers/acpi/scan.c:
>>
>> static acpi_status
>> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *contex
From: gehao
In dce6(0,1,4)_create_resource_pool and dce80_create_resource_pool
the allocated memory should be released if construct pool fails.
Signed-off-by: gehao
---
drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 3 +++
drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 2 ++
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_luma = 0;
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_chroma = 0;
these two operations in dcn32/dcn32_resource.c still need to use FPU,
This will cause compilation to fail on ARM64 platforms because
-mgeneral-regs-only is enabled by default to dis
From: gehao
In dce6(0,1,4)_create_resource_pool and dce8(0,1)_create_resource_pool
the allocated memory should be released if construct pool fails.
Signed-off-by: gehao
---
drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c | 3 +++
drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 2
In the process of enabling DCN support for arm64, I found that the
dcn10_resource_construct_fp function in dcn10/dcn10_resource.c still
needs to use FPU. This will cause compilation to fail on ARM64 platforms
because -mgeneral-regs-only is enabled by default to disable the
hardware FPU. So move dcn
Hello Christian,
thank you for your review. I got a warning in checking the first patch with
checkpatch.pl.
I'll fix it in the next version.
---
0001-drm-amd-display-move-remaining-FPU-code-to-dml-folde.patch
--
In the process of enabling DCN support for arm64, I found that the
dcn10_resource_construct_fp function in dcn10/dcn10_resource.c still
needs to use FPU. This will cause compilation to fail on ARM64 platforms
because -mgeneral-regs-only is enabled by default to disable the
hardware FPU. So move dcn
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_luma = 0;
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_chroma = 0;
these two operations in dcn32/dcn32_resource.c still need to use FPU,
This will cause compilation to fail on ARM64 platforms because
-mgeneral-regs-only is enabled by default to dis
Fix the following checkpatch checks in amdgpu_dm.c
CHECK: Prefer kernel type 'u8' over 'uint8_t'
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Prefer kernel type 'u64' over 'uint64_t'
CHECK: Prefer kernel type 's32' over 'int32_t'
Signed-off-by: Srinivasan Shanmugam
---
.../gpu/drm/amd
Hello Jack Xiao,
The patch d0c423b64765: "drm/amdgpu/mes: use ring for kernel queue
submission" from Mar 27, 2020, leads to the following Smatch static
checker warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c:1056 amdgpu_mes_add_ring()
error: format string overflow. buf_size: 16 l
Hello Asher,
Thanks for the information, is it open-source tests? Can I reproduce it?
Also, it seems like Radeon Instinct MI25 was released before Radeon RX
Vega, is it possible that they have different PowerPlay subsystems?
On my Vega56, all these registers from vega20 are working very well.
See
[AMD Official Use Only - General]
The series is Reviewed-by: Jack Xiao
Regards,
Jack
From: Sider, Graham
Sent: Wednesday, 26 October 2022 03:20
To: amd-gfx@lists.freedesktop.org
Cc: Xiao, Jack ; Zhang, Hawking ;
Sider, Graham
Subject: [PATCH 2/2] drm/amdgpu:
For some GPUs with more CUs, the original sibling_map[32]
in struct crat_subtype_cache is not enough
to save the cache information when create the VCRAT table,
so skip filling the struct crat_subtype_cache info instead
fill struct kfd_cache_properties directly to fix this problem.
v2:
- Remove
Init and save the base cu processor id for later use
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 20 +---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +++
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b
Attached is the original test patch rebased on current amd-staging-drm-next.
Can you test if this is enough to make sure that the games start without
crashing by fetching the userptrs?
Thanks in advance,
Christian.
Am 21.10.22 um 14:36 schrieb Mikhail Gavrilov:
On Fri, Oct 21, 2022 at 1:33 P
Am 25.10.22 um 23:17 schrieb Ao Zhong:
In the process of enabling DCN support for arm64, I found that the
dcn10_resource_construct_fp function in dcn10/dcn10_resource.c still
needs to use FPU. This will cause compilation to fail on ARM64 platforms
because -mgeneral-regs-only is enabled by default
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_luma = 0;
pipes[pipe_cnt].pipe.src.dcc_fraction_of_zs_req_chroma = 0;
these two operations in dcn32/dcn32_resource.c still need to use FPU,
This will cause compilation to fail on ARM64 platforms because
-mgeneral-regs-only is enabled by default to dis
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:615: warning: expecting
prototype for setup_subvp_dmub_command(). Prototype was for
populate_subvp_cmd_pipe_info() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2587
Reported-by: Abaci Ro
This symbol is not used outside of dc_link_dp.c, so marks it static.
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5230:16: warning: no
previous prototype for function 'wake_up_aux_channel'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2581
Reported-by: Abaci Robot
Signed-o
"Vlastimil Babka (SUSE)" writes:
> On 9/28/22 14:01, Alistair Popple wrote:
>> This series aims to fix a number of page reference counting issues in
>> drivers dealing with device private ZONE_DEVICE pages. These result in
>> use-after-free type bugs, either from accessing a struct page which n
On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
> drivers/acpi/scan.c:
>
> static acpi_status
> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
> void **return_value)
> {
In the process of enabling DCN support for arm64, I found that the
dcn10_resource_construct_fp function in dcn10/dcn10_resource.c still
needs to use FPU. This will cause compilation to fail on ARM64 platforms
because -mgeneral-regs-only is enabled by default to disable the
hardware FPU. So move dcn
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
change in v2:
According to Felix's suggestion, move the pr_debug up before the
kfd_unref_proce
Hi,
On 10/25/22 22:40, Matthew Garrett wrote:
> On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote:
>
>> Having the native driver come and then go and be replaced
>> with the vendor driver would also be quite inconvenient
>> for these planned changes.
>
> I understand that it would be
58 matches
Mail list logo
