Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

Am 28.02.20 um 06:08 schrieb Luben Tuikov: On 2020-02-27 4:40 p.m., Nirmoy Das wrote: implement drm_sched_entity_modify_sched() which can modify existing sched_list with a different one. This is going to be helpful when userspace changes priority of a ctx/entity then driver can switch to

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > > > Hi all, > > > > You might have read the short take in the X.org board meeting minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

Am 28.02.20 um 04:29 schrieb Luben Tuikov: On 2020-02-26 3:37 p.m., Nirmoy Das wrote: init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high priority and 1st queue to normal priority. Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +

[PATCH] drm/amdgpu: clean wptr on wb when gpu recovery

The TDR will be randomly failed due to compute ring test failure. If the compute ring wptr & 0x7ff(ring_buf_mask) is 0x100 then after map mqd the compute ring rptr will be synced with 0x100. And the ring test packet size is also 0x100. Then after invocation of amdgpu_ring_commit, the cp will not

RE: [PATCH] drm/amdgpu: Write blocked CP registers using RLC on VF

Reviewed-by: Monk Liu _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: amd-gfx On Behalf Of Rohit Khaire Sent: Wednesday, February 26, 2020 10:45 AM To: amd-gfx@lists.freedesktop.org Cc: Khaire, Rohit Subject: [PATCH] drm/amdgpu:

Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

On 2020-02-27 4:40 p.m., Nirmoy Das wrote: > implement drm_sched_entity_modify_sched() which can modify existing > sched_list with a different one. This is going to be helpful when > userspace changes priority of a ctx/entity then driver can switch to > corresponding hw shced list for that

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

Please add proper lock in smu_set_soft_freq_range() then. You can do necessary modification to existing code paths. Otherwise without lock protection, you may run into race condition on the new debugfs intrace(amdgpu_debugfs_sclk_set) called by multiple instances. -Original Message-

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

[AMD Official Use Only - Internal Distribution Only] Hi Evan, No lock is created for smu_set_soft_freq_range() in this code path. But some other sysfs interfaces calling smu_set_soft_freq_range() indirectly have created lock in middle function to protect smu_set_soft_freq_range() as critical

Re: [RFC PATCH 3/4] drm/amdgpu: change hw sched list on ctx priority override

On 2020-02-27 4:40 p.m., Nirmoy Das wrote: > Switch to appropriate sched list for an entity on priority override. > > Signed-off-by: Nirmoy Das > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 54 - > 1 file changed, 53 insertions(+), 1 deletion(-) > > diff --git

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On 2020-02-26 3:37 p.m., Nirmoy Das wrote: > We were changing compute ring priority while rings were being used > before every job submission which is not recommended. This patch > recreates entity with higher/normal priority sched list when user > changes ctx's priority. > > high/normal priority

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

Please confirm whether smu_set_soft_freq_range() is properly lock protected. -Original Message- From: Chengming Gui Sent: Friday, February 28, 2020 10:37 AM To: amd-gfx@lists.freedesktop.org Cc: Quan, Evan ; Feng, Kenneth ; Xu, Feifei ; Gui, Jack Subject: [PATCH 2/2] drm/amdgpu: Add

RE: [PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary sclk value for navi14"

Reviewed-by: Evan Quan -Original Message- From: Chengming Gui Sent: Friday, February 28, 2020 10:37 AM To: amd-gfx@lists.freedesktop.org Cc: Quan, Evan ; Feng, Kenneth ; Xu, Feifei ; Gui, Jack Subject: [PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary sclk value

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

On 2020-02-26 3:37 p.m., Nirmoy Das wrote: > init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high > priority > and 1st queue to normal priority. > > Signed-off-by: Nirmoy Das > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 + >

Re: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

Hi, I got feedback from Linux team and they simply don't want to change. I believe that it would work for bare metal as well. Jiange From: Deucher, Alexander Sent: Thursday, February 27, 2020 10:23 PM To: Zhao, Jiange ; amd-gfx@lists.freedesktop.org Cc: Deng,

RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

Thanks. But could you help to confirm whether this is correctly protected by "mutex_lock(>mutex)"? -Original Message- From: Hersen Wu Sent: Thursday, February 27, 2020 11:54 PM To: amd-gfx@lists.freedesktop.org Cc: Quan, Evan ; Feng, Kenneth ; Wu, Hersen Subject: [PATCH 2/2]

[PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

add debugfs interface amdgpu_force_sclk to set arbitrary sclk for navi14 Signed-off-by: Chengming Gui --- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 44 ++ drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 3 ++ 2 files changed, 47 insertions(+) diff --git

[PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary sclk value for navi14"

Revert this commit and than add debugfs interface to replace this to meet the specitic requirement. This reverts commit 3107269204f8e18f389080673f7848b420970aa5. --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 42 --- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 9

Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services

On 02/27/2020 05:00 PM, Tom Stellard wrote: > On 02/27/2020 01:27 PM, Daniel Vetter wrote: >> Hi all, >> >> You might have read the short take in the X.org board meeting minutes >> already, here's the long version. >> >> The good news: gitlab.fd.o has become very popular with our >> communities,

Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services

On 02/27/2020 01:27 PM, Daniel Vetter wrote: > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially includes

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

On 2020-02-27 5:10 p.m., Luben Tuikov wrote: > On 2020-02-27 6:47 a.m., Christian König wrote: >> Am 27.02.20 um 12:38 schrieb Huang Rui: >>> Since 6643ba1 frame control packets are only issued in presence of secure >>> IB(s). >>> This causes hangs on some hardware (eg: Raven1). This patch

Re: gitlab.fd.o financial situation and impact on services

On Thu, Feb 27, 2020 at 10:27:04PM +0100, Daniel Vetter wrote: > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This

Re: gitlab.fd.o financial situation and impact on services

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter wrote: > > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

On 2020-02-27 6:47 a.m., Christian König wrote: > Am 27.02.20 um 12:38 schrieb Huang Rui: >> Since 6643ba1 frame control packets are only issued in presence of secure >> IB(s). >> This causes hangs on some hardware (eg: Raven1). This patch restores the >> unconditionnal frame control packets

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[AMD Official Use Only - Internal Distribution Only] Yes I missed gfx_v10_0.c. I will resend a updated one tomorrow. Regards, Nirmoy Get Outlook for Android From: Alex Deucher Sent: Thursday, February 27, 2020 10:50:35 PM To: Nirmoy Das

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

On Thu, Feb 27, 2020 at 4:48 PM Alex Deucher wrote: > > On Thu, Feb 27, 2020 at 4:37 PM Nirmoy Das wrote: > > > > We were changing compute ring priority while rings were being used > > before every job submission which is not recommended. This patch > > sets compute queue priority at mqd

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

On Thu, Feb 27, 2020 at 4:37 PM Nirmoy Das wrote: > > We were changing compute ring priority while rings were being used > before every job submission which is not recommended. This patch > sets compute queue priority at mqd initialization for gfx8 and gfx9. > > Policy: Enable high priority

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

On 2/27/20 10:40 PM, Nirmoy Das wrote: We were changing compute ring priority while rings were being used before every job submission which is not recommended. This patch sets compute queue priority at mqd initialization for gfx8 and gfx9. Policy: Enable high priority compute queues only if

[RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

We were changing compute ring priority while rings were being used before every job submission which is not recommended. This patch sets compute queue priority at mqd initialization for gfx8 and gfx9. Policy: Enable high priority compute queues only if gpu has >1 MEC, if so PIPE0 and PIPE1 will

[RFC PATCH 4/4] drm/amdgpu: remove unused functions

amdgpu statically set priority for compute queues at initialization so remove all the functions responsible changing compute queue priority dynamically Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 7

[RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

implement drm_sched_entity_modify_sched() which can modify existing sched_list with a different one. This is going to be helpful when userspace changes priority of a ctx/entity then driver can switch to corresponding hw shced list for that priority Signed-off-by: Nirmoy Das ---

[RFC PATCH 3/4] drm/amdgpu: change hw sched list on ctx priority override

Switch to appropriate sched list for an entity on priority override. Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 54 - 1 file changed, 53 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

On Thu, Feb 27, 2020 at 4:15 PM Luben Tuikov wrote: > > On 2020-02-27 6:56 a.m., Huang Rui wrote: > > On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote: > >> Since commit "Move to a per-IB secure flag (TMZ)", > >> we've been seeing hangs in GFX. Ray H. pointed out > >> by sending a

gitlab.fd.o financial situation and impact on services

Hi all, You might have read the short take in the X.org board meeting minutes already, here's the long version. The good news: gitlab.fd.o has become very popular with our communities, and is used extensively. This especially includes all the CI integration. Modern development process and

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

On 2020-02-27 6:56 a.m., Huang Rui wrote: > On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote: >> Since commit "Move to a per-IB secure flag (TMZ)", >> we've been seeing hangs in GFX. Ray H. pointed out >> by sending a patch that we need to send FRAME >> CONTROL stop/start

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On 2/27/20 10:02 PM, Alex Deucher wrote: On Thu, Feb 27, 2020 at 3:28 PM Nirmoy wrote: On 2/27/20 3:35 PM, Alex Deucher wrote: We shouldn't be changing this at runtime. We need to set up the queue priority at init time and then schedule to the appropriate quueue at runtime. We set the

Re: [PATCH v3 0/3] Implement SMU message register protection

On Thu, Feb 27, 2020 at 4:01 PM Matt Coffin wrote: > > > > On 2/27/20 1:49 PM, Alex Deucher wrote: > > > BTW, I think you had another change to clean up some of the navi10 > > code, care to send that one out too? > > > > Alex > > That was in there just since I was doing some debugging related to

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On Thu, Feb 27, 2020 at 3:28 PM Nirmoy wrote: > > > On 2/27/20 3:35 PM, Alex Deucher wrote: > > We shouldn't be changing this at runtime. We need to set up the queue > > priority at init time and then schedule to the appropriate quueue at > > runtime. We set the pipe/queue priority in the mqd

Re: [PATCH v3 0/3] Implement SMU message register protection

On 2/27/20 1:49 PM, Alex Deucher wrote: > BTW, I think you had another change to clean up some of the navi10 > code, care to send that one out too? > > Alex That was in there just since I was doing some debugging related to https://gitlab.freedesktop.org/drm/amd/issues/1053 and voltage

Re: [PATCH v3 0/3] Implement SMU message register protection

On Wed, Feb 26, 2020 at 6:16 PM Matt Coffin wrote: > > Sorry for the extra email, but the mutex_init got lost when I was rebasing. > Oops. > > This patchset adds a message lock to lock access to the SMU message > communication registers to prevent concurrent access. > > v2: Separate navi10

Re: [PATCH 1/2] drm/amdgpu: remove unused variable

[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Yong Zhao From: amd-gfx on behalf of Alex Deucher Sent: Thursday, February 27, 2020 3:14 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH 1/2] drm/amdgpu: remove

Re: [PATCH 2/2] drm/amdgpu/gfx: fix indentation in new rlc spm code

series Reviewed-by:Nirmoy Das On 2/27/20 9:14 PM, Alex Deucher wrote: fixes warnings with -Wmisleading-indentation. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On 2/27/20 3:35 PM, Alex Deucher wrote: We shouldn't be changing this at runtime. We need to set up the queue priority at init time and then schedule to the appropriate quueue at runtime. We set the pipe/queue priority in the mqd (memory queue descriptor). When we init the rings we

[PATCH 2/2] drm/amdgpu/gfx: fix indentation in new rlc spm code

fixes warnings with -Wmisleading-indentation. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 6 +++--- 4 files

[PATCH 1/2] drm/amdgpu: remove unused variable

Fixes a warning. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index bec4337156a7..b3e32969eb7f 100644 ---

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

Hi Harry Ok, back from various other emergencies and deadlines, sorry for the late reply. I also fixed my e-mail address - it was mistyped, causing all these delivery failures :/ On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote: > > On 2020-01-09 4:13 p.m., Mario Kleiner wrote: > > On Thu,

RE: [PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

> -Original Message- > From: amd-gfx On Behalf Of Liu, > Zhan > Sent: 2020/February/27, Thursday 1:40 PM > To: Melissa Wen ; Wentland, Harry > ; Li, Sun peng (Leo) ; > Deucher, Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > ; Rodrigo Siqueira

Re: [PATCH] drm/amdgpu: stop allocating PDs/PTs with the eviction lock held

On 2020-02-27 9:28, Christian König wrote: Hi Felix, so coming back to this after two weeks of distraction. Am 14.02.20 um 22:12 schrieb Felix Kuehling: Now you allow eviction of page tables while you allocate page tables. Isn't the whole point of the eviction lock to prevent page table

RE: [PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

> -Original Message- > From: amd-gfx On Behalf Of > Melissa Wen > Sent: 2020/February/26, Wednesday 5:08 PM > To: Wentland, Harry ; Li, Sun peng (Leo) > ; Deucher, Alexander > ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > ; Rodrigo Siqueira > Cc:

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

Hi Rodrigo, On 02/27, Rodrigo Siqueira wrote: > Hi Melissa, > > First of all, thank you very much for this patchset; in general, > everything looks good to me. > > I noticed that your patchset does not apply because you made your > changes based on `drm-misc-next`; when you send patches to

Re: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

On Thu, Feb 27, 2020 at 10:54 AM Hersen Wu wrote: > > This interface is for dGPU Navi1x. Linux dc-pplib interface depends > on window driver dc implementation. > > For Navi1x, clock settings of dcn watermarks are fixed. the settings > should be passed to smu during boot up and resume from s3.

[PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

This interface is for dGPU Navi1x. Linux dc-pplib interface depends on window driver dc implementation. For Navi1x, clock settings of dcn watermarks are fixed. the settings should be passed to smu during boot up and resume from s3. boot up: dc calculate dcn watermark clock settings within

Re: [PATCH] drm/amdgpu: stop allocating PDs/PTs with the eviction lock held

Hi Felix, so coming back to this after two weeks of distraction. Am 14.02.20 um 22:12 schrieb Felix Kuehling: Now you allow eviction of page tables while you allocate page tables. Isn't the whole point of the eviction lock to prevent page table evictions while manipulating page tables? Or

Re: [PATCH] drm/amdgpu: stop disable the scheduler during HW fini

[AMD Public Use] Looks good to me. Reviewed-by: Alex Deucher From: Christian König Sent: Thursday, February 27, 2020 9:50 AM To: Das, Nirmoy ; amd-gfx@lists.freedesktop.org ; Deucher, Alexander Subject: Re: [PATCH] drm/amdgpu: stop disable the scheduler during

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

Hi Melissa, First of all, thank you very much for this patchset; in general, everything looks good to me. I noticed that your patchset does not apply because you made your changes based on `drm-misc-next`; when you send patches to amdgpu, use the following repository:

Re: [PATCH 1/2] drm/amd/display: dc_link: code clean up on enable_link_dp function

Hi, First of all, thank you for your patch. I just have one tiny comment inline. On 02/26, Melissa Wen wrote: > Coding style clean up on enable_link_dp function as suggested by > checkpatch.pl: > > CHECK: Lines should not end with a '(' > WARNING: line over 80 characters > WARNING: suspect

[PATCH] drm/amdgpu: don't enable runtime pm on navi12

BACO for power savings is not supported on navi12. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c index

Re: [PATCH] drm/amdgpu: stop disable the scheduler during HW fini

Alex any comment on this? Am 25.02.20 um 14:16 schrieb Nirmoy: Acked-by: Nirmoy Das On 2/25/20 2:07 PM, Christian König wrote: When we stop the HW for example for GPU reset we should not stop the front-end scheduler. Otherwise we run into intermediate failures during command submission. The

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

Am 27.02.20 um 15:26 schrieb Yintian Tao: If we release drm_device before amdgpu_driver_unload_kms, then it will raise the error below. Therefore, we need to place it before amdgpu_driver_unload_kms. [ 43.055736] Memory manager not clean during takedown. [ 43.055777] WARNING: CPU: 1 PID:

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

On Thu, Feb 27, 2020 at 9:26 AM Yintian Tao wrote: > > If we release drm_device before amdgpu_driver_unload_kms, > then it will raise the error below. Therefore, we need to > place it before amdgpu_driver_unload_kms. > [ 43.055736] Memory manager not clean during takedown. > [ 43.055777]

Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

On Thu, Feb 27, 2020 at 7:46 AM Yintian Tao wrote: > > drm_minor_unregister will invoke drm_debugfs_cleanup > to clean all the child node under primary minor node. > We don't need to invoke amdgpu_debugfs_fini and > amdgpu_debugfs_regs_cleanup to clean agian. > Otherwise, it will raise the NULL

Re: [PATCH] drm/amdgpu: miss to remove pp_sclk file

On Thu, Feb 27, 2020 at 9:11 AM Yintian Tao wrote: > > Miss to remove pp_sclk file > > Signed-off-by: Yintian Tao Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c >

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On Thu, Feb 27, 2020 at 5:08 AM Christian König wrote: > > Am 26.02.20 um 21:37 schrieb Nirmoy Das: > > We were changing compute ring priority while rings were being used > > before every job submission which is not recommended. This patch > > recreates entity with higher/normal priority sched

[PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

If we release drm_device before amdgpu_driver_unload_kms, then it will raise the error below. Therefore, we need to place it before amdgpu_driver_unload_kms. [ 43.055736] Memory manager not clean during takedown. [ 43.055777] WARNING: CPU: 1 PID: 2807 at

RE: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

Many thanks. I will put it after pci_* functions. -Original Message- From: Christian König Sent: 2020年2月27日 22:21 To: Tao, Yintian ; Koenig, Christian ; Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: release drm_device after

Re: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

[AMD Public Use] Is there any reason to not just use this for bare metal as well? Alex From: amd-gfx on behalf of jianzh Sent: Thursday, February 27, 2020 6:21 AM To: amd-gfx@lists.freedesktop.org Cc: Deng, Emily ; Zhao, Jiange ; Liu, Monk Subject: [PATCH]

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

Am 27.02.20 um 12:58 schrieb Yintian Tao: If we release drm_device before amdgpu_driver_unload_kms, then it will raise the error below. Therefore, we need to place it before amdgpu_driver_unload_kms. [ 43.055736] Memory manager not clean during takedown. [ 43.055777] WARNING: CPU: 1 PID:

Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

Am 27.02.20 um 13:46 schrieb Yintian Tao: drm_minor_unregister will invoke drm_debugfs_cleanup to clean all the child node under primary minor node. We don't need to invoke amdgpu_debugfs_fini and amdgpu_debugfs_regs_cleanup to clean agian. Otherwise, it will raise the NULL pointer like below. [

RE: [PATCH] drm/amdgpu: miss to remove pp_sclk file

Hi Christian Thanks a lot for your review Hi Alex Can you help to review it? Thanks in advance. Best Regards Yintian Tao -Original Message- From: Koenig, Christian Sent: 2020年2月27日 22:18 To: Tao, Yintian ; Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org Subject: Re:

Re: [PATCH] drm/amdgpu: miss to remove pp_sclk file

Am 27.02.20 um 15:11 schrieb Yintian Tao: Miss to remove pp_sclk file Signed-off-by: Yintian Tao Looks reasonable to me, but Alex can probably better judge. Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] drm/amdgpu: miss to remove pp_sclk file

Miss to remove pp_sclk file Signed-off-by: Yintian Tao --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c index 9deff8cc9723..a43fc1c8ffd0 100644 ---

Re: [PATCH] drm/amdgpu: Initialize SPM_VMID with 0xf

Am 27.02.20 um 14:25 schrieb Jacob He: SPM_VMID is a global resource, SPM access the video memory according to SPM_VMID. The initial valude of SPM_VMID is 0 which is used by kernel. That means UMD can overwrite the memory of VMID0 by enabling SPM, that is really dangerous. Initialize SPM_VMID

[PATCH] drm/amdgpu: Initialize SPM_VMID with 0xf

SPM_VMID is a global resource, SPM access the video memory according to SPM_VMID. The initial valude of SPM_VMID is 0 which is used by kernel. That means UMD can overwrite the memory of VMID0 by enabling SPM, that is really dangerous. Initialize SPM_VMID with 0xf, it messes up other user mode

[PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

drm_minor_unregister will invoke drm_debugfs_cleanup to clean all the child node under primary minor node. We don't need to invoke amdgpu_debugfs_fini and amdgpu_debugfs_regs_cleanup to clean agian. Otherwise, it will raise the NULL pointer like below. [ 45.046029] BUG: unable to handle kernel

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

On Thu, Feb 27, 2020 at 07:47:17PM +0800, Koenig, Christian wrote: > Am 27.02.20 um 12:38 schrieb Huang Rui: > > Since 6643ba1 frame control packets are only issued in presence of secure > > IB(s). > > This causes hangs on some hardware (eg: Raven1). This patch restores the > > unconditionnal

RE: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

Hi Christian Thanks for your suggestion. I will remove all cleanup/fini code as well. Best Regards Yintian Tao -Original Message- From: Koenig, Christian Sent: 2020年2月27日 19:54 To: Tao, Yintian ; Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu:

[PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

If we release drm_device before amdgpu_driver_unload_kms, then it will raise the error below. Therefore, we need to place it before amdgpu_driver_unload_kms. [ 43.055736] Memory manager not clean during takedown. [ 43.055777] WARNING: CPU: 1 PID: 2807 at

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote: > Since commit "Move to a per-IB secure flag (TMZ)", > we've been seeing hangs in GFX. Ray H. pointed out > by sending a patch that we need to send FRAME > CONTROL stop/start back-to-back, every time we > flip the TMZ flag as per each

Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

If we do this we should probably make nails with heads and remove the whole cleanup/fini code as well. Christian. Am 27.02.20 um 12:50 schrieb Yintian Tao: drm_minor_unregister will invoke drm_debugfs_cleanup to clean all the child node under primary minor node. We don't need to invoke

[PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

drm_minor_unregister will invoke drm_debugfs_cleanup to clean all the child node under primary minor node. We don't need to invoke amdgpu_debugfs_fini and amdgpu_debugfs_regs_cleanup to clean agian. Otherwise, it will raise the NULL pointer like below. [ 45.046029] BUG: unable to handle kernel

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

Am 27.02.20 um 12:38 schrieb Huang Rui: Since 6643ba1 frame control packets are only issued in presence of secure IB(s). This causes hangs on some hardware (eg: Raven1). This patch restores the unconditionnal frame control packets issuing, that's to keep the per-IB logic regarding the secure

[PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

Since 6643ba1 frame control packets are only issued in presence of secure IB(s). This causes hangs on some hardware (eg: Raven1). This patch restores the unconditionnal frame control packets issuing, that's to keep the per-IB logic regarding the secure flag. Fixes: 6643ba1 drm/amdgpu: Move to a

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

Am 27.02.20 um 11:26 schrieb Nirmoy: On 2/27/20 11:08 AM, Christian König wrote:   scheds = adev->sdma.sdma_sched; @@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct amdgpu_ctx *ctx,   return fence;   }   +static void amdgpu_ctx_hw_priority_override(struct

[PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

Navi12 VK CTS subtest timestamp.calibrated.dev_domain_test failed because mmRLC_CAPTURE_GPU_CLOCK_COUNT register cannot be written in VF due to security policy. Solution: use a VF-accessible timestamp register pair mmGOLDEN_TSC_COUNT_LOWER/UPPER for SRIOV case. Signed-off-by: jianzh ---

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

On 2/27/20 11:08 AM, Christian König wrote:   scheds = adev->sdma.sdma_sched; @@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct amdgpu_ctx *ctx,   return fence;   }   +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx, +  

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

Am 26.02.20 um 21:37 schrieb Nirmoy Das: We were changing compute ring priority while rings were being used before every job submission which is not recommended. This patch recreates entity with higher/normal priority sched list when user changes ctx's priority. high/normal priority sched list

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

Found two issues : On 2/26/20 9:37 PM, Nirmoy Das wrote: +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx, + const u32 hw_ip, + enum drm_sched_priority priority) +{ + int i; + +

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

Am 27.02.20 um 10:57 schrieb Nirmoy: On 2/27/20 5:44 AM, Alex Deucher wrote: On Wed, Feb 26, 2020 at 3:34 PM Nirmoy Das wrote: init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high priority and 1st queue to normal priority. Signed-off-by: Nirmoy Das ---  

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

On 2/27/20 5:44 AM, Alex Deucher wrote: On Wed, Feb 26, 2020 at 3:34 PM Nirmoy Das wrote: init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high priority and 1st queue to normal priority. Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +