[PATCH] drm/amd/powerplay: add smu message mutex

Add smu message mutex preventing against race condition issue. Signed-off-by: Jack Xiao --- drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 + drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 7 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git

Re: [PATCH v2] dri2: reply to client for WaitMSC request in any case

This looks like a v2 with silightly different semantics? Den mån 3 juni 2019 kl 09:26 skrev Cui, Flora : > > ping... > > commit 47613e8e8f4a5e3b25830e3c015a4a217fcbe469 > Author: Flora Cui > Date: Wed May 29 14:18:50 2019 +0800 > > dri2: reply to client for WaitMSC request in any case > >

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers

Am 03.06.19 um 12:17 schrieb Christian König: Am 01.06.19 um 00:01 schrieb Kuehling, Felix: On 2019-05-31 5:32 p.m., Yang, Philip wrote: On 2019-05-31 3:42 p.m., Kuehling, Felix wrote: On 2019-05-31 1:28 p.m., Yang, Philip wrote: On 2019-05-30 6:36 p.m., Kuehling, Felix wrote:      

[PATCH] drm/amd/powerplay: add smu message mutex

Add smu message mutex preventing against race condition issue. Signed-off-by: Jack Xiao --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 + drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 + drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 7 ++- 3 files changed, 8 insertions(+), 1

RE: [PATCH v2] dri2: reply to client for WaitMSC request in any case

Acked-by: Feifei Xu Regards, Feifei -Original Message- From: amd-gfx On Behalf Of Cui, Flora Sent: 2019年6月3日 15:26 To: Cui, Flora ; Daenzer, Michel ; amd-gfx@lists.freedesktop.org Subject: [PATCH v2] dri2: reply to client for WaitMSC request in any case ping... commit

Re: [PATCH] drm/sched: Fix make htmldocs warnings.

On Thu, May 30, 2019 at 05:04:20PM +0200, Christian König wrote: > Am 29.05.19 um 21:36 schrieb Daniel Vetter: > > On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote: > > > I don't, sorry. > > Should we fix that? Seems like you do plenty of scheduler stuff, so would > > make sense

Re: [PATCH v2] dri2: reply to client for WaitMSC request in any case

Yes. It's v2 and change the behavior slightly. It send reply to client with no wait_info for amdgpu_dri2_deferred_event() would handle the reply differently. 在 6/3/2019 3:59 PM, Ernst Sjöstrand 写道: > This looks like a v2 with silightly different semantics? > > Den mån 3 juni 2019 kl 09:26 skrev

Re: [PATCH] dri2: reply to client for WaitMSC request in any case

On 2019-05-29 8:36 a.m., Cui, Flora wrote: > otherwise client would wait for reply forever and desktop appears hang. > > Signed-off-by: Flora Cui > --- > src/amdgpu_dri2.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/amdgpu_dri2.c b/src/amdgpu_dri2.c > index 44316ac..34353a7

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers

Am 01.06.19 um 00:01 schrieb Kuehling, Felix: On 2019-05-31 5:32 p.m., Yang, Philip wrote: On 2019-05-31 3:42 p.m., Kuehling, Felix wrote: On 2019-05-31 1:28 p.m., Yang, Philip wrote: On 2019-05-30 6:36 p.m., Kuehling, Felix wrote: #if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR) -

[PATCH v2] dri2: reply to client for WaitMSC request in any case

ping... commit 47613e8e8f4a5e3b25830e3c015a4a217fcbe469 Author: Flora Cui Date:   Wed May 29 14:18:50 2019 +0800     dri2: reply to client for WaitMSC request in any case     otherwise client would wait for reply forever and desktop appears hang.     Signed-off-by: Flora Cui diff --git

RE: [PATCH] drm/amd/powerplay: add smu message mutex

Drop it due to a modification was missing. A new patch was sent out. -Original Message- From: Xiao, Jack Sent: Monday, June 03, 2019 2:12 PM To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Zhang, Hawking Cc: Xiao, Jack Subject: [PATCH] drm/amd/powerplay: add smu message mutex

[PATCH] drm/amdgpu: Hardcode reg access using L1 security

Under Vega10 SR-IOV VF, L1 register access mode should be enabled by default as the non-security VF will no longer be supported. Signed-off-by: Trigger Huang --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers

On 2019-06-03 7:23 a.m., Christian König wrote: > Am 03.06.19 um 12:17 schrieb Christian König: >> Am 01.06.19 um 00:01 schrieb Kuehling, Felix: >>> On 2019-05-31 5:32 p.m., Yang, Philip wrote: On 2019-05-31 3:42 p.m., Kuehling, Felix wrote: > On 2019-05-31 1:28 p.m., Yang, Philip

RE: [PATCH 2/2] drm/amd/amdgpu: add RLC firmware to support raven1 refresh

> -Original Message- > From: amd-gfx On Behalf Of > Prike Liang > Sent: 2019年5月31日 21:11 > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander ; Liang, Prike > ; Huang, Ray > Subject: [PATCH 2/2] drm/amd/amdgpu: add RLC firmware to support raven1 > refresh > > Use SMU firmware

RE: [PATCH 1/2] drm/amd/powerplay: add set_power_profile_mode for raven1_refresh

Reviewed-by: Evan Quan > -Original Message- > From: amd-gfx On Behalf Of > Prike Liang > Sent: 2019年5月31日 21:11 > To: amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander ; Huang, Ray > ; Gui, Jack > Subject: [PATCH 1/2] drm/amd/powerplay: add set_power_profile_mode > for

Re: [PATCH] drm/sched: Fix make htmldocs warnings.

On 6/3/19 3:24 AM, Daniel Vetter wrote: > On Thu, May 30, 2019 at 05:04:20PM +0200, Christian König wrote: >> Am 29.05.19 um 21:36 schrieb Daniel Vetter: >>> On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote: I don't, sorry. >>> Should we fix that? Seems like you do plenty

Re: [pull] amdgpu, amdkfd drm-next-5.3

On Thu, May 30, 2019 at 12:09 AM Alex Deucher wrote: > > Hi Dave, Daniel, > > New stuff for 5.3: > - Add new thermal sensors for vega asics > - Various RAS fixes > - Add sysfs interface for memory interface utilization > - Use HMM rather than mmu notifier for user pages > - Expose xgmi topology

[PATCH v16 05/16] arm64: untag user pointers passed to memory syscalls

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. This patch allows tagged pointers to be passed to the following memory syscalls: get_mempolicy, madvise, mbind,

Re: [PATCH v3 5/5] drm: don't block fb changes for async plane updates

On 5/7/19 5:18 PM, Sean Paul wrote: > On Wed, Mar 13, 2019 at 09:20:26PM -0300, Helen Koike wrote: >> In the case of a normal sync update, the preparation of framebuffers (be >> it calling drm_atomic_helper_prepare_planes() or doing setups with >> drm_framebuffer_get()) are performed in the

[PATCH v4 2/5] drm/amd: fix fb references in async update

Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling

[PATCH v4 5/5] drm: don't block fb changes for async plane updates

In the case of a normal sync update, the preparation of framebuffers (be it calling drm_atomic_helper_prepare_planes() or doing setups with drm_framebuffer_get()) are performed in the new_state and the respective cleanups are performed in the old_state. In the case of async updates, the

[PATCH v16 15/16] vfio/type1, arm64: untag user pointers in vaddr_get_pfn

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. vaddr_get_pfn() uses provided user pointers for vma lookups, which can only by done with untagged pointers. Untag

[PATCH v16 10/16] drm/amdgpu, arm64: untag user pointers

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. In amdgpu_gem_userptr_ioctl() and amdgpu_amdkfd_gpuvm.c/init_user_pages() an MMU notifier is set up with a (tagged)

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On Mon, Jun 03, 2019 at 11:24:35AM -0600, Khalid Aziz wrote: > On 6/3/19 11:06 AM, Andrey Konovalov wrote: > > On Mon, Jun 3, 2019 at 7:04 PM Khalid Aziz wrote: > >> Andrey, > >> > >> This patch has now become part of the other patch series Chris Hellwig > >> has sent out - > >>

[PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

To allow arm64 syscalls to accept tagged pointers from userspace, we must untag them when they are passed to the kernel. Since untagging is done in generic parts of the kernel, the untagged_addr macro needs to be defined for all architectures. Define it as a noop for architectures other than

[PATCH v16 02/16] arm64: untag user pointers in access_ok and __uaccess_mask_ptr

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. copy_from_user (and a few other similar functions) are used to copy data from user memory into the kernel memory or

[PATCH v16 00/16] arm64: untag user pointers passed to the kernel

=== Overview arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.

[PATCH v16 04/16] mm: untag user pointers in do_pages_move

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. do_pages_move() is used in the implementation of the move_pages syscall. Untag user pointers in this function.

[PATCH v16 06/16] mm, arm64: untag user pointers in mm/gup.c

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. mm/gup.c provides a kernel interface that accepts user addresses and manipulates user pages directly (for example

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On Mon, Jun 3, 2019 at 7:04 PM Khalid Aziz wrote: > > On 6/3/19 10:55 AM, Andrey Konovalov wrote: > > To allow arm64 syscalls to accept tagged pointers from userspace, we must > > untag them when they are passed to the kernel. Since untagging is done in > > generic parts of the kernel, the

Re: [PATCH v16 12/16] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr()

On Mon, Jun 03, 2019 at 06:55:14PM +0200, Andrey Konovalov wrote: > This patch is a part of a series that extends arm64 kernel ABI to allow to > pass tagged user pointers (with the top byte set to something else other > than 0x00) as syscall arguments. > > ib_uverbs_(re)reg_mr() use provided user

[PATCH 2/5] drm/amdkfd: Only load sdma mqd when queue is active

Also calls load_mqd with current->mm struct. The mm struct is used to read back user wptr of the queue. Change-Id: I0f6d085878358dcd3a413054dbe61d1ca0fdf66d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 - 1 file changed, 4 insertions(+), 1

[PATCH 1/5] drm/amdkfd: Only initialize sdma vm for sdma queues

Don't do the same for compute queues Change-Id: Id5f743ca10c2b761590bfe18cab2f802d3c04d2d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH 3/5] drm/amdkfd: Refactor create_queue_nocpsch

This is prepare work to fix a circular lock dependency. No logic change Change-Id: I4e0ee918260e7780de972dd71f4ce787b4f6dde9 Signed-off-by: Oak Zeng --- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 171 +++-- 1 file changed, 58 insertions(+), 113 deletions(-) diff --git

[PATCH 4/5] drm/amdkfd: Fix a circular lock dependency

The idea to break the circular lock dependency is to move init_mqd out of lock protection of dqm lock in callstack #1 below. There is no need to. [ 59.510149] [drm] Initialized amdgpu 3.30.0 20150101 for :04:00.0 on minor 0 [ 513.604034]

[PATCH 5/5] drm/amdkfd: Fix sdma queue allocate race condition

SDMA queue allocation requires the dqm lock as it modify the global dqm members. Introduce functions to allocate/deallocate in locked/unlocked circumstance. Change-Id: Id3084524c5f65d9629b12cf6b4862a7516945cb1 Signed-off-by: Oak Zeng --- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 34

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On 6/3/19 10:55 AM, Andrey Konovalov wrote: > To allow arm64 syscalls to accept tagged pointers from userspace, we must > untag them when they are passed to the kernel. Since untagging is done in > generic parts of the kernel, the untagged_addr macro needs to be defined > for all architectures. >

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On 6/3/19 11:06 AM, Andrey Konovalov wrote: > On Mon, Jun 3, 2019 at 7:04 PM Khalid Aziz wrote: >> Andrey, >> >> This patch has now become part of the other patch series Chris Hellwig >> has sent out - >> . Can >> you coordinate

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On 6/3/19 11:29 AM, Christoph Hellwig wrote: > On Mon, Jun 03, 2019 at 11:24:35AM -0600, Khalid Aziz wrote: >> On 6/3/19 11:06 AM, Andrey Konovalov wrote: >>> On Mon, Jun 3, 2019 at 7:04 PM Khalid Aziz wrote: Andrey, This patch has now become part of the other patch series Chris

RE: [PATCH 1/4] drm/amdkfd: Fix sdma queue allocate race condition

Hi Felix, See comment inline [Oak] Regards, Oak -Original Message- From: Kuehling, Felix Sent: Friday, May 31, 2019 5:50 PM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Zhao, Yong ; Freehill, Chris ; Liu, Alex Subject: Re: [PATCH 1/4] drm/amdkfd: Fix sdma queue allocate race

[PATCH v16 09/16] fs, arm64: untag user pointers in fs/userfaultfd.c

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. userfaultfd code use provided user pointers for vma lookups, which can only by done with untagged pointers. Untag

[PATCH v16 08/16] fs, arm64: untag user pointers in copy_mount_options

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. In copy_mount_options a user address is being subtracted from TASK_SIZE. If the address is lower than TASK_SIZE, the

[PATCH v16 13/16] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. videobuf_dma_contig_user_get() uses provided user pointers for vma lookups, which can only by done with untagged

[PATCH v16 12/16] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr()

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. ib_uverbs_(re)reg_mr() use provided user pointers for vma lookups (through e.g. mlx4_get_umem_mr()), which can only

[PATCH v4 0/5] drm: Fix fb changes for async updates

Hello, I'm re-sending this series with the acked by in the msm patch and updating the docs in the last patch, the rest is the same. v3 link: https://patchwork.kernel.org/project/dri-devel/list/?series=91353 Thanks! Helen Changes in v4: - add acked by tag - update docs in atomic_async_update

[PATCH v16 11/16] drm/radeon, arm64: untag user pointers in radeon_gem_userptr_ioctl

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. In radeon_gem_userptr_ioctl() an MMU notifier is set up with a (tagged) userspace pointer. The untagged address

[PATCH v16 14/16] tee, arm64: untag user pointers in tee_shm_register

This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. tee_shm_register()->optee_shm_unregister()->check_mem_type() uses provided user pointers for vma lookups (via

[PATCH] drm/amd/display: Add connector debugfs for "output_bpc"

[Why] This will be useful for verifying whether we enter the correct output color depth from IGT. [How] Locks the connector and associated CRTC if available and outputs the current and maximum output bpc values. Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Current: 8 Maximum: 10

[PATCH v2] drm/amd/display: Add connector debugfs for "output_bpc"

[Why] This will be useful for verifying whether we enter the correct output color depth from IGT. [How] Locks the connector and associated CRTC if available and outputs the current and maximum output bpc values. Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Current: 8 Maximum: 10 v2:

Re: [PATCH 4/5] drm/amdkfd: Fix a circular lock dependency

allocate_vmid, allocate_hqd and allocate_sdma_queue all work on data in the DQM structure. So it seems these need to be protected by the DQM lock. allocate_doorbell doesn't need the DQM lock because its data structures are in the process_device structure, which is protected by the process

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers v3

On 2019-06-03 5:02 p.m., Kuehling, Felix wrote: > On 2019-06-03 2:44 p.m., Yang, Philip wrote: >> HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver >> path. The old hmm APIs are deprecated and will be removed in future. >> >> Below are changes in driver: >> >> 1. Change

Re: [PATCH 3/5] drm/amdkfd: Refactor create_queue_nocpsch

On 2019-06-03 1:51 p.m., Zeng, Oak wrote: > This is prepare work to fix a circular lock dependency. > No logic change > > Change-Id: I4e0ee918260e7780de972dd71f4ce787b4f6dde9 > Signed-off-by: Oak Zeng > --- > .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 171 > +++-- >

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers v3

On 2019-06-03 2:44 p.m., Yang, Philip wrote: > HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver > path. The old hmm APIs are deprecated and will be removed in future. > > Below are changes in driver: > > 1. Change hmm_vma_fault to hmm_range_register and hmm_range_fault which >

Re: [PATCH] drm/amdgpu: use new HMM APIs and helpers v3

[+Jerome] On 2019-06-03 7:20 p.m., Yang, Philip wrote: > > On 2019-06-03 5:02 p.m., Kuehling, Felix wrote: >> On 2019-06-03 2:44 p.m., Yang, Philip wrote: >>> HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver >>> path. The old hmm APIs are deprecated and will be removed in

[PATCH] drm/amdgpu: use new HMM APIs and helpers v3

HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver path. The old hmm APIs are deprecated and will be removed in future. Below are changes in driver: 1. Change hmm_vma_fault to hmm_range_register and hmm_range_fault which supports range with multiple vmas, remove the multiple

Re: [PATCH 2/7] drm/dp_mst: Register AUX devices for MST ports

On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote: > Hey, sorry for my late response! > > On 2019-05-16 5:40 p.m., Lyude Paul wrote: > > > >if (old_pdt != port->pdt && !port->input) { > > > @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct > > > drm_dp_mst_branch > > >

Re: [PATCH v4 2/5] drm/amd: fix fb references in async update

On 6/3/19 1:56 PM, Helen Koike wrote: > Async update callbacks are expected to set the old_fb in the new_state > so prepare/cleanup framebuffers are balanced. > > Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new > fb and put the old fb) is not required, as it's taken

[PATCH] drm/amdgpu: add pmu counters

add performance monitoring unit (pmu) counters. Change-Id: I4d0480b8aaa8086a28b6a79a60322b060e1aa73e Signed-off-by: Jonathan Kim --- drivers/gpu/drm/amd/amdgpu/Makefile| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 + drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c| 353

Re: [PATCH 2/7] drm/dp_mst: Register AUX devices for MST ports

On Mon, 2019-06-03 at 15:25 -0400, Lyude Paul wrote: > On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote: > > Hey, sorry for my late response! > > > > On 2019-05-16 5:40 p.m., Lyude Paul wrote: > > > > > >if (old_pdt != port->pdt && !port->input) { > > > > @@ -1220,6 +1268,8 @@

[PATCH v2 2/2] drm/amd/amdgpu: add RLC firmware to support raven1 refresh

Use SMU firmware version to indentify the raven1 refresh device and then load homologous RLC FW. Change-Id: I7aaa67d8b59cfec03355d9199f7fb2c30ce39856 Signed-off-by: Prike Liang Suggested-by: Huang Rui Reviewed-by: Huang Rui --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++-

[PATCH 1/6] drm/amdkfd: Only initialize sdma vm for sdma queues

Don't do the same for compute queues Change-Id: Id5f743ca10c2b761590bfe18cab2f802d3c04d2d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH 5/6] drm/amdkfd: Fix a circular lock dependency

The idea to break the circular lock dependency is to move allocate_mqd out of dqm lock protection. See callstack #1 below. [ 59.510149] [drm] Initialized amdgpu 3.30.0 20150101 for :04:00.0 on minor 0 [ 513.604034] == [ 513.604205]

[PATCH 4/6] drm/amdkfd: Separate mqd allocation and initialization

Introduce a new mqd allocation interface and split the original init_mqd function into two functions: allocate_mqd and init_mqd. This is preparation work to fix a circular lock dependency. Change-Id: I26e53ee1abcdd688ad11d35b433da77e3fa1bee7 Signed-off-by: Oak Zeng ---

[PATCH 3/6] drm/amdkfd: Refactor create_queue_nocpsch

This is prepare work to fix a circular lock dependency. No logic change Change-Id: I4e0ee918260e7780de972dd71f4ce787b4f6dde9 Signed-off-by: Oak Zeng --- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 171 +++-- 1 file changed, 57 insertions(+), 114 deletions(-) diff --git

RE: [PATCH 4/5] drm/amdkfd: Fix a circular lock dependency

Thank you Felix for the catch. Let's do it the cleanest way. Another reason to separate allocate_mqd from init_mqd is, the current init_mqd is actually allocate_and_init_mqd. If we separate it into two functions, the function name makes more sense. Regards, Oak -Original Message-

[PATCH 2/6] drm/amdkfd: Only load sdma mqd when queue is active

Also calls load_mqd with current->mm struct. The mm struct is used to read back user wptr of the queue. Change-Id: I0f6d085878358dcd3a413054dbe61d1ca0fdf66d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 - 1 file changed, 4 insertions(+), 1

RE: [PATCH] drm/amd/powerplay: add smu message mutex

> -Original Message- > From: amd-gfx On Behalf Of Xiao, > Jack > Sent: Monday, June 03, 2019 3:02 PM > To: amd-gfx@lists.freedesktop.org; Deucher, Alexander > ; Zhang, Hawking > > Cc: Xiao, Jack > Subject: [PATCH] drm/amd/powerplay: add smu message mutex > > Add smu message mutex