[PATCH 6/7] drm/amdkfd: Cleanup DQM ASIC-specific ops

From: Yong Zhao Remove empty initialize function. Rename register_process to update_qpd to avoid confusion with the non-ASIC-specific register_process. Shorten ops_asic_specific to asic_ops. Signed-off-by: Yong Zhao Signed-off-by: Felix Kuehling

[PATCH 0/7] More KFD fixes and cleanups

Another pass through a diff between our internal branch and upstream yielded a few more fixes and cleanups that were previously missed. Ben Goz (1): drm/amdkfd: Register/Deregister process on qpd resolution Felix Kuehling (1): drm/amdkfd: Minor cleanups Jay Cornwall (1): drm/amdkfd:

[PATCH 1/7] drm/amdkfd: Clean up the data structure in kfd_process

From: Yong Zhao A list of per-process queues is maintained in the kfd_process_queue_manager, so the queues array in kfd_process is redundant and in fact unused. Signed-off-by: Yong Zhao Signed-off-by: Felix Kuehling ---

[PATCH 3/7] drm/amdkfd: Avoid calling amd_iommu_unbind_pasid() when suspending

From: Yong Zhao When kfd suspending on APU, we do not need to call amd_iommu_unbind_pasid(), because pasid will be unbound automatically when power goes off. On the other hand, calling amd_iommu_unbind_pasid() will trigger kfd_process_iommu_unbind_callback() if the process is

[PATCH 5/7] drm/amdkfd: Register/Deregister process on qpd resolution

From: Ben Goz Process registration needs to happen on each device. So use per-device queue lists to determine when to register/deregister the process. Signed-off-by: Ben Goz Signed-off-by: Felix Kuehling ---

[PATCH 2/7] drm/amdkfd: Disable CP/SDMA ring/doorbell in MQD

From: Jay Cornwall The MQD represents an inactive context and should not have ring or doorbell enable bits set. Doing so interferes with HWS which streams the MQD onto the HQD. If enable bits are set this activates the ring or doorbell before the HQD is fully configured.

[PATCH 4/7] drm/amdkfd: Fix debug unregister procedure on process termination

From: Yair Shachar Take the dbgmgr lock and unregister before destroying the debug manager. Do this before destroying the queues. Signed-off-by: Yair Shachar Signed-off-by: Felix Kuehling ---

RE: [PATCH 5/7] drm/amdgpu: don't disable MSI for GPU virtual function

Can you try call pci_disable_device once you found init failed, and make sure it is called before re-init -Original Message- From: Ding, Pixel Sent: 2017年10月24日 9:31 To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Xiao, Jack Cc: Sun, Gary

RE: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops

Okay, I missed that part, Free to add my RB -Original Message- From: Ding, Pixel Sent: 2017年10月24日 9:33 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Cc: Sun, Gary ; Li, Bingley Subject: Re: [PATCH 6/7] drm/amdgpu/virt: add

Re: [PATCH 5/7] drm/amdgpu: don't disable MSI for GPU virtual function

Sorry for the misunderstanding. Will test with similar fix instead of 5248e3d9 directly later. — Sincerely Yours, Pixel On 24/10/2017, 9:31 AM, "Ding, Pixel" wrote: >Tested with 5248e3d9, however issue is still reproduced in reinit case. > >+Jack, >To bypass MSI

Re: [PATCH 2/5] drm/amdgpu: nuke amdgpu_ttm_is_bound()

On 2017年10月23日 22:26, Christian König wrote: Why I prefer to keep is_bound for naming is we only can get gpu offset after gtt is bound not check if node is allocated. No, it is just the other way around. When the TTM is bound it doesn't mean we can get the GPU offset because it can be that

Re: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops

This is for retry init. If the driver fails before late_init, the IRQ handler is not registered then. We need to know if the FLR is done at this point. I think maybe we also can leverage this interface to handle some special cases in future. Any concern about it? — Sincerely Yours, Pixel

Re: [PATCH 5/7] drm/amdgpu: don't disable MSI for GPU virtual function

Tested with 5248e3d9, however issue is still reproduced in reinit case. +Jack, To bypass MSI enable/disable for reinit, any comment? — Sincerely Yours, Pixel On 23/10/2017, 6:57 PM, "Liu, Monk" wrote: >Please check commit "5248e3d9", your issue should already be fixed

Re: [PATCH] drm/amd/amdgpu: Remove workaround check for UVD6 on APUs

Reviewed-by: Leo Liu On 10/23/2017 01:34 PM, Alex Deucher wrote: On Mon, Oct 23, 2017 at 1:03 PM, Tom St Denis wrote: On APUs the uvd6 driver was skipping proper suspend/resume routines resulting in a broken state upon resume. Signed-off-by: Tom St

Re: [PATCH] drm/amd/amdgpu: Remove workaround check for UVD6 on APUs

On Mon, Oct 23, 2017 at 1:03 PM, Tom St Denis wrote: > On APUs the uvd6 driver was skipping proper suspend/resume routines resulting > in a broken state upon resume. > > Signed-off-by: Tom St Denis Acked-by: Alex Deucher >

[PATCH] drm/amd/amdgpu: Remove workaround check for UVD6 on APUs

On APUs the uvd6 driver was skipping proper suspend/resume routines resulting in a broken state upon resume. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git

Re: uvd failed to resume during suspend

On 10/23/2017 12:06 PM, Tom St Denis wrote: This diff: diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c index 71299c67c517..d4a6b97d20e7 100644 --- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c @@ -566,7 +566,7

RE: [PATCH] drm/amdgpu/psp: Use %p for printing pointers

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Michel Dänzer > Sent: Monday, October 23, 2017 10:46 AM > To: amd-gfx@lists.freedesktop.org > Subject: [PATCH] drm/amdgpu/psp: Use %p for printing pointers > > From: Michel Dänzer

RE: [PATCH 2/7] drm/amdgpu: add init_log param to control logs in exclusive mode

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Pixel Ding > Sent: Monday, October 23, 2017 6:03 AM > To: amd-gfx@lists.freedesktop.org > Cc: Sun, Gary; Ding, Pixel; Li, Bingley > Subject: [PATCH 2/7] drm/amdgpu: add init_log param to

RE: [PATCH 4/7] drm/amdgpu/virt: add function to check MMIO accessing

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Pixel Ding > Sent: Monday, October 23, 2017 6:03 AM > To: amd-gfx@lists.freedesktop.org > Cc: Sun, Gary; Ding, Pixel; Li, Bingley > Subject: [PATCH 4/7] drm/amdgpu/virt: add function to check

RE: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Pixel Ding > Sent: Monday, October 23, 2017 6:04 AM > To: amd-gfx@lists.freedesktop.org > Cc: Sun, Gary; Ding, Pixel; Li, Bingley > Subject: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt

RE: [PATCH 1/7] drm/amdgpu: release VF exclusive accessing after hw_init

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Pixel Ding > Sent: Monday, October 23, 2017 6:03 AM > To: amd-gfx@lists.freedesktop.org > Cc: Sun, Gary; Ding, Pixel; Li, Bingley > Subject: [PATCH 1/7] drm/amdgpu: release VF exclusive

RE: [PATCH 3/7] drm/amdgpu: avoid soft lockup when waiting for RLC serdes

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Pixel Ding > Sent: Monday, October 23, 2017 6:03 AM > To: amd-gfx@lists.freedesktop.org > Cc: Sun, Gary; Ding, Pixel; Li, Bingley > Subject: [PATCH 3/7] drm/amdgpu: avoid soft lockup when

Re: uvd failed to resume during suspend

This diff: diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c index 71299c67c517..d4a6b97d20e7 100644 --- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c @@ -566,7 +566,7 @@ static int uvd_v6_0_suspend(void *handle)

RE: [PATCH] drm/ttm:fix memory leak due to individualize

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Christian König > Sent: Monday, October 23, 2017 3:06 AM > To: Liu, Monk; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/ttm:fix memory leak due to individualize > > Am 23.10.2017

Re: [PATCH 7/7] drm/amdgpu: retry init if it fails due to exclusive mode timeout

On 2017-10-23 06:03 AM, Pixel Ding wrote: From: pding The exclusive mode has real-time limitation in reality, such like being done in 300ms. It's easy observed if running many VF/VMs in single host with heavy CPU workload. If we find the init fails due to exclusive mode

Re: [PATCH] drm/amdgpu/psp: Use %p for printing pointers

Am 23.10.2017 um 16:45 schrieb Michel Dänzer: From: Michel Dänzer The compiler was warning: In file included from drivers/gpu/drm//amd/amdgpu/amdgpu.h:45:0, from drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27: drivers/gpu/drm//amd/amdgpu/psp_v10_0.c: In

[PATCH] drm/amdgpu/psp: Use %p for printing pointers

From: Michel Dänzer The compiler was warning: In file included from drivers/gpu/drm//amd/amdgpu/amdgpu.h:45:0, from drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27: drivers/gpu/drm//amd/amdgpu/psp_v10_0.c: In function ‘psp_v10_0_cmd_submit’:

Re: uvd failed to resume during suspend

On 23/10/17 09:27 AM, Tom St Denis wrote: Doing a suspend during playback results in the uvd not resuming when waking up with drm-next as the kernel. Trying with cg_mask=pg_mask=0 It hangs on decode start. I've attached the readout of the ring which looks normal. Initially I thought maybe

uvd failed to resume during suspend

Doing a suspend during playback results in the uvd not resuming when waking up with drm-next as the kernel. Tom [0.00] Linux version 4.13.0-rc5+ (root@carrizo) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC)) #37 SMP Thu Oct 12 07:12:29 EDT 2017 [0.00] Command line:

Re: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky: Switch from kfifo to SPSC queue. Bug: Kfifo is limited at size, during GPU reset it would fill up to limit and the pushing thread (producer) would wait for the scheduler worker to consume the items in the fifo while holding reservation lock on a

Re: [PATCH 2/3] drm/amdgpu: Add SPSC queue to scheduler.

Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky: It is intended to sabstitute the bounded fifo we are currently using. Signed-off-by: Andrey Grodzovsky Two style nit picks below, with those fixed the patch is Reviewed-by: Christian König

Re: [PATCH 1/3] drm/amdgpu: Avoid accessing job->entity after the job is scheduled.

Am 20.10.2017 um 15:32 schrieb Andrey Grodzovsky: Bug: amdgpu_job_free_cb was accessing s_job->s_entity when the allocated amdgpu_ctx (and the entity inside it) were already deallocated from amdgpu_cs_parser_fini. Fix: Save job's priority on it's creation instead of accessing it from s_entity

Re: [PATCH 5/5] drm/amdgpu:cleanup job reset routine(v2)

Am 23.10.2017 um 07:46 schrieb Monk Liu: merge the setting guilty on context into this function to avoid implement extra routine. v2: go through entity list and compare the fence_ctx before operate on the entity, otherwise the entity may be just a wild pointer Change-Id:

Re: [PATCH libdrm 1/2] headers: Sync amdgpu_drm.h with drm-next

Both patches: Reviewed-by: Nicolai Hähnle On 20.10.2017 16:57, Andres Rodriguez wrote: Generated using make headers_install from: airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ... Signed-off-by: Andres Rodriguez ---

RE: [PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops

I don't see this is a necessary patch, driver already have the implement to check if VF FLR is completed or not, see "xgpu_ai/vi_mailbox_flr_work()" Driver won't do gpu reset until this function received the NOTIFICATION_CMPL message Do you have any particular reason to add this wait_reset ?

RE: [PATCH 5/7] drm/amdgpu: don't disable MSI for GPU virtual function

Please check commit "5248e3d9", your issue should already be fixed by that patch, please verify -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Pixel Ding Sent: 2017年10月23日 18:04 To: amd-gfx@lists.freedesktop.org Cc: Sun, Gary

Re: [PATCH 2/3] drm/amdgpu: Add SPSC queue to scheduler.

On 2017-10-23 12:06 AM, Liu, Monk wrote: If the deadlock issue could be solved I don't see why we give up kfifo and switch to SPSC .. The deadlock is solved because we don't block anymore waiting for consumer to dequeue items from the queue - which can only be achieved with not

[PATCH 7/7] drm/amdgpu: retry init if it fails due to exclusive mode timeout

From: pding The exclusive mode has real-time limitation in reality, such like being done in 300ms. It's easy observed if running many VF/VMs in single host with heavy CPU workload. If we find the init fails due to exclusive mode timeout, try it again. Signed-off-by: pding

[PATCH 3/7] drm/amdgpu: avoid soft lockup when waiting for RLC serdes

From: pding Normally all waiting get timeout if there's one. Release the lock and return immediately when timeout happens. Signed-off-by: pding --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 ++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 6 ++ 2

[PATCH 6/7] drm/amdgpu/virt: add wait_reset virt ops

From: pding Driver can use this interface to check if there's a function level reset done in hypervisor. Signed-off-by: pding --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 16 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 2 ++

[PATCH 5/7] drm/amdgpu: don't disable MSI for GPU virtual function

From: pding After calling pci_disable_msi() and pci_enable_msi(), VF can't receive interrupt anymore. This may introduce problems in module reloading or retrying init. Signed-off-by: pding --- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 ++--- 1 file

[PATCH 4/7] drm/amdgpu/virt: add function to check MMIO accessing

From: pding MMIO space can be blocked on virtualised device. Add this function to check if MMIO is blocked or not. Todo: need a reliable method such like communation with hypervisor. Signed-off-by: pding --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 5

[PATCH 1/7] drm/amdgpu: release VF exclusive accessing after hw_init

The subsequent operations don't need exclusive accessing hardware. Signed-off-by: Pixel Ding --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git

[PATCH 2/7] drm/amdgpu: add init_log param to control logs in exclusive mode

From: pding When this VF stays in exclusive mode for long, other VFs will be impacted. The redundant messages causes exclusive mode timeout when they're redirected. That is a normal use case for cloud service to redirect guest log to virtual serial port. Introduce init_log

Init timing changes for SRIOV VF

This is the second patch series merged or reimplemented from SRIOV branch. It changes the init time consuming. Exclusive mode means that a VF occupies hardware and other VFs need to wait until this VF releases exclusive mode. The timing of exclusive mode is limited to avoid starvation causing

RE: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

I read the source again, looks like I misunderstand your point, let me clear it again: 1, the cs_submit deadlock can be resolved by moving eu_fence_buffer() 2, in GEM_VA IOCTL, the reservation lock is hold in the very beginning, and vm_update_directories() need that lock held till all related

Re: [PATCH 2/5] drm/amdgpu: nuke amdgpu_ttm_is_bound()

Yes, I see the checking in backend_bind:     if (!amdgpu_gtt_mgr_is_allocated(bo_mem))     return 0; OK, then my only concern is your ’instead‘ assumes amdgpu_gtt_mgr_is_allocated means gart is bound, how about: bool amdgpu_gtt_is_bound(struct ttm_tt *ttm) {     return

Re: [PATCH 5/5] drm/amdgpu:cleanup job reset routine(v2)

The series is Reviewed-by: Chunming Zhou On 2017年10月23日 13:46, Monk Liu wrote: merge the setting guilty on context into this function to avoid implement extra routine. v2: go through entity list and compare the fence_ctx before operate on the entity, otherwise the entity

Re: [PATCH 2/5] drm/amdgpu: nuke amdgpu_ttm_is_bound()

Am 23.10.2017 um 09:33 schrieb Chunming Zhou: using ttm->state == tt_bound seems make more sense. That won't work. We set ttm->state = tt_bound even when we haven't allocated GART space. That's also a reason why I wanted to remove it, the name is confusing. Christian. On 2017年10月20日

RE: [PATCH 3/5] drm/amdgpu:implement guilty pointer

Yeah, already did so, please check the amd-gfx -Original Message- From: Koenig, Christian Sent: 2017年10月23日 15:17 To: Liu, Monk ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 3/5] drm/amdgpu:implement guilty pointer Am 23.10.2017 um 06:26 schrieb Liu, Monk: >

RE: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

Let's make it clear enough: > That won't work. All VM updates must be completed while the reservation > object lock is still held, otherwise you run into possible concurrent VM > updates. All VM updates will be represented as fence which will be hook in the sync object, and after we push job

Re: [PATCH 2/5] drm/amdgpu: nuke amdgpu_ttm_is_bound()

using ttm->state == tt_bound seems make more sense. On 2017年10月20日 17:20, Christian König wrote: From: Christian König use amdgpu_gtt_mgr_is_allocated() instead. Signed-off-by: Christian König ---

Re: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

For VM updates, the situation is same as commands submission, deadlock can also be solved by moving ttm_eu_fence_buffer_objects() ahead of push_job() That won't work. All VM updates must be completed while the reservation object lock is still held, otherwise you run into possible concurrent VM

RE: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

For VM updates, the situation is same as commands submission, deadlock can also be solved by moving ttm_eu_fence_buffer_objects() ahead of push_job() For TTM buffers moves can we pardon gpu_reset routine and wait till the TTM moves complete ? -Original Message- From: Christian König

Re: [PATCH 3/5] drm/amdgpu:implement guilty pointer

Am 23.10.2017 um 06:26 schrieb Liu, Monk: Don't set this directly, make it a parameter of amd_sched_entity_init(). And please split up the patches differently. First all changes to the scheduler, including the guilty marking. Then the changes to amdgpu. [ML] that way the first patch will

Re: [PATCH] drm/amd/scheduler:fix duplicate operation in entity fini

Am 23.10.2017 um 08:00 schrieb Monk Liu: no need to manually cleanup job and fence after sched_fence_finish(), they are auto handled by the callback Change-Id: I9da26064c9e73c178949663bed1e490539e95e41 Signed-off-by: Monk Liu Reviewed-by: Christian König

Re: [PATCH 3/3] drm/amdgpu: Fix deadlock during GPU reset.

We discussed that as well, problem is that this won't be sufficient. We push to the kfifo not only during command submission, but also for VM updates and TTM buffers moves. So we can still deadlock because of them. Regards, Christian. Am 23.10.2017 um 05:03 schrieb Liu, Monk: Why not use a

Re: [PATCH] drm/ttm:fix memory leak due to individualize

Am 23.10.2017 um 04:31 schrieb Monk Liu: Change-Id: I6d06b81b8b894775e55e495e96f3c999b83cf2be Signed-off-by: Monk Liu Reviewed-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH] drm/amd/scheduler:fix duplicate operation in entity fini

no need to manually cleanup job and fence after sched_fence_finish(), they are auto handled by the callback Change-Id: I9da26064c9e73c178949663bed1e490539e95e41 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 3 +-- 1 file changed, 1 insertion(+), 2