[AMD Official Use Only - Internal Distribution Only]
Not sure it's same issue as I observed.
If you have an XGMI setup, use the latest drm-next and the PMFW I used on my
XGMI system(I just sent you the vega20_smc.bin through mail). And then give
another attempt.
About the strict time
On Tue, Dec 10, 2019 at 10:55:13AM +0800, Zhu, Changfeng wrote:
> From: changzhu
>
> It may cause timeout waiting for sem acquire in VM flush when using
> invalidate semaphore for picasso. So it needs to avoid using invalidate
> semaphore for piasso.
>
> Change-Id:
From: changzhu
It may cause timeout waiting for sem acquire in VM flush when using
invalidate semaphore for picasso. So it needs to avoid using invalidate
semaphore for piasso.
Change-Id: I6dc552bde180919cd5ba6c81c6d9e3f800043b03
Signed-off-by: changzhu
---
[AMD Official Use Only - Internal Distribution Only]
I'm fine with your solution if synchronization time interval satisfies BACO
requirements and loop test can pass on XGMI system.
Regards,
Ma Le
From: Grodzovsky, Andrey
Sent: Monday, December 9, 2019 11:52 PM
To: Ma, Le ;
Thanks. Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Yintian
> Tao
> Sent: Tuesday, December 10, 2019 1:27 AM
> To: Deucher, Alexander ; Feng, Kenneth
>
> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
> Subject: [PATCH] drm/amd/powerplay: avoid null
I reproduced the issue on my side - i consistently observe amdgpu:
[powerplay] Failed to send message 0x58, response 0x0 - Baco exit
failure - do you know what is the strict time interval within which all
the Baco enter/Exit messages needs to be sent to all the nodes in the hive ?
Andrey
On
forgot to add RB for the series.
Alex
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Monday, December 9, 2019 4:45 PM
To: Liu, Leo ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgpu: fix JPEG instance checking when ctx init
[AMD
Entity currently keeps a copy of run_queue list and modify it in
drm_sched_entity_set_priority(). Entities shouldn't modify run_queue
list. Use drm_gpu_scheduler list instead of drm_sched_rq list
in drm_sched_entity struct. In this way we can select a runqueue based
on entity/ctx's priority for a
entity should not keep copy and maintain sched list for
itself.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
drm_sched_entity_init() takes drm gpu scheduler list instead of
drm_sched_rq list. This makes conversion of drm_sched_rq list
to drm gpu scheduler list unnecessary
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
This sched list can be passed on to entity creation routine
instead of manually creating such sched list on every context creation.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 69 --
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 44
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Leo Liu
Sent: Monday, December 9, 2019 4:10 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Leo
Subject: [PATCH 2/2] drm/amdgpu: fix JPEG instance
Reviewed-by: James Zhu for the series
On 2019-12-09 4:10 p.m., Leo Liu wrote:
The JPEG irq type has been moved to its own structure
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
2 files changed, 2 insertions(+), 2
Fixes: 0388aee76("drm/amdgpu: use the JPEG structure for
general driver support")
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
The JPEG irq type has been moved to its own structure
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
Am 09.12.19 um 19:57 schrieb Luben Tuikov:
This patch fixes the following warnings:
-Wformat=
-Wmaybe-uninitialized
-Wmisleading-indentation
-Wstringop-truncation
-Wunused-function
-Wunused-variable
It also removes forward declarations and moves
global functions to the bottom, keeping locals
at
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.
This behavior is not accurate; actually, we need to return
the actual CRC value when
This patch fixes the following warning:
-Wformat-overflow=
Signed-off-by: Luben Tuikov
---
tests/amdgpu/meson.build | 1 +
tests/amdgpu/ras_tests.c | 41
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tests/amdgpu/meson.build
This patch fixes:
-Wunused-function
v2: Always enable amdgpu_ras_test().
Signed-off-by: Luben Tuikov
---
tests/amdgpu/ras_tests.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/amdgpu/ras_tests.c b/tests/amdgpu/ras_tests.c
index d714be73..f745166b 100644
---
This patch fixes the following warnings:
-Wformat=
-Wmaybe-uninitialized
-Wmisleading-indentation
-Wstringop-truncation
-Wunused-function
-Wunused-variable
It also removes forward declarations and moves
global functions to the bottom, keeping locals
at the top, in ras_tests.c.
Signed-off-by:
because some asics have no smu.ppt_funcs
we need add one check for it otherwise
it will raise null pointer problem.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
On Mon, Dec 9, 2019 at 12:16 PM Tao, Yintian wrote:
>
> Hi Alex
>
> Many thanks for your review. Please see inline comments. I will submit the v3
> patch according to your comment. Thanks again.
>
> Best Regards
> Yintian Tao
>
> -Original Message-
> From: Alex Deucher
> Sent:
Originally, due to the restriction from PSP and SMU, VF has
to send message to hypervisor driver to handle powerplay
change which is complicated and redundant. Currently, SMU
and PSP can support VF to directly handle powerplay
change by itself. Therefore, the old code about the handshake
between
On Mon, Dec 9, 2019 at 5:39 AM Yintian Tao wrote:
>
> Originally, due to the restriction from PSP and SMU, VF has
> to send message to hypervisor driver to handle powerplay
> change which is complicated and redundant. Currently, SMU
> and PSP can support VF to directly handle powerplay
> change
Thanks a lot Ma for trying - I think I have to have my own system to
debug this so I will keep trying enabling XGMI - i still think the is
the right and the generic solution for multiple nodes reset
synchronization and in fact the barrier should also be used for
synchronizing PSP mode 1 XGMI
Yeah, that won't work very well.
During bring-up we also often have the case that we can't correctly
initialize all engines, e.g. only the first SDMA comes up etc.
So better stick with the initial approach of constructing the scheduler
array for each engine type which needs it.
Regards,
On Sun, Dec 8, 2019 at 8:42 PM Evan Quan wrote:
>
> This is needed for coming asic init on performing gpu reset.
>
> V2: use non-asic specific programing way
>
> Change-Id: If3671a24d239e3d288665fadaa2c40c87d5da40b
> Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
> ---
>
I can see one issue with this. I am ignoring/removing changes from
commit 2a84e48e9712ea8591a10dd59d59ccab3d54efd6 drm/amdgpu: Only add rqs
for initialized rings.
I wonder if we can handle that differently.
Regards,
Nirmoy
On 12/9/19 2:56 PM, Nirmoy wrote:
Hi Christian,
I got a
On 12/6/19 7:24 PM, Lyude Paul wrote:
Nice! All I've got is a couple of typos I noticed and one question, this looks
great :)
Thanks! I'll clean it up. The response to the question is below.
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
From: Mikita Lipski
Adding a
Hi Christian,
I got a different idea, a bit more simple let me know what do you think
about it:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 50bab33cba39..8de4de4f7a43 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++
Yes, you need to do this for the SDMA as well but in general that looks
like the idea I had in mind as well.
I would do it like this:
1. Change the special case when you only get one scheduler for an entity
to drop the pointer to the scheduler list.
This way we always use the same
[AMD Official Use Only - Internal Distribution Only]
Hi Andrey,
I tried your patches on my 2P XGMI platform. The baco can work at most time,
and randomly got following error:
[ 1701.542298] amdgpu: [powerplay] Failed to send message 0x25, response 0x0
This error usually means some sync issue
Originally, due to the restriction from PSP and SMU, VF has
to send message to hypervisor driver to handle powerplay
change which is complicated and redundant. Currently, SMU
and PSP can support VF to directly handle powerplay
change by itself. Therefore, the old code about the handshake
between
Originally, due to the restriction from PSP and SMU, VF has
to send message to hypervisor driver to handle powerplay
change which is complicated and redundant. Currently, SMU
and PSP can support VF to directly handle powerplay
change by itself. Therefore, the old code about the handshake
between
34 matches
Mail list logo
