[PATCH] drm/amd/powerplay: avoid possible buffer overflow

Make sure the clock level enforced is within the allowed ranges in case PP_SCLK and PP_MCLK. Signed-off-by: Young Xiao <92siuy...@gmail.com> --- drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v2] drm/amdgpu/display: Fix reload driver error

Issue: Will have follow error when reload driver: [ 3986.567739] sysfs: cannot create duplicate filename '/devices/pci:00/:00:07.0/drm_dp_aux_dev' [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE 5.0.0-rc1-custom #1 [ 3986.567745] Hardware name: QEMU Standard PC

RE: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer

Hi Christian, I have reverted the before change as your suggestion, and sent this new patch, could you help to review this? Best wishes Emily Deng >-Original Message- >From: amd-gfx On Behalf Of Deng, >Emily >Sent: Wednesday, May 29, 2019 10:52 AM >To:

RE: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer

Ping.. Best wishes Emily Deng >-Original Message- >From: Deng, Emily >Sent: Tuesday, May 28, 2019 6:14 PM >To: Deng, Emily ; amd-gfx@lists.freedesktop.org >Subject: RE: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer > >Ping .. > >Best wishes >Emily Deng > > >

RE: [PATCH] drm/amdgpu: fix ring test failure issue during s3 in vce 3.0

Hi Christian, Your explanation matches my code study and test results. Well, I will remove original read. Shirish and I will re-test it. I will submit it after test done. As for other related code, yes, I assumed there might be similar issues as well. My plan is to create internal ticket and

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Tue, 2019-05-28 at 16:40 +0100, Catalin Marinas wrote: > On Tue, May 28, 2019 at 03:54:11PM +0100, Andrew Murray wrote: > > On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote: > > > On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote: > > > > This patch is a part of a

[PATCH 1/2] mm/hmm.c: support automatic NUMA balancing

From: Philip Yang While the page is migrating by NUMA balancing, HMM failed to detect this condition and still return the old page. Application will use the new page migrated, but driver pass the old page physical address to GPU, this crash the application later. Use pte_protnone(pte) to

[PATCH 0/2] Two HMM patches from MMOTS

These are two important HMM bug fixes to fix the HMM-based userptr implementation. They are alread staged in MMOTS: https://www.ozlabs.org/~akpm/mmots/broken-out/ Kuehling, Felix (1): mm/hmm.c: only set FAULT_FLAG_ALLOW_RETRY for non-blocking Philip Yang (1): mm/hmm.c: support automatic NUMA

[PATCH 2/2] mm/hmm.c: only set FAULT_FLAG_ALLOW_RETRY for non-blocking

From: "Kuehling, Felix" Don't set this flag by default in hmm_vma_do_fault. It is set conditionally just a few lines below. Setting it unconditionally can lead to handle_mm_fault doing a non-blocking fault, returning -EBUSY and unlocking mmap_sem unexpectedly. Link:

[PATCH 1/3] drm/amdkfd: Simplify eviction state logic

Always mark evicted queues with q->properties.is_evicted = true, even queues that are inactive for other reason. This simplifies maintaining the eviction state as it doesn't require updating is_evicted when other queue activation conditions change. On the other hand, we now need to check those

[PATCH 3/3] drm/amdkfd: Implement queue priority controls for gfx9

From: Jay Cornwall Ported from gfx8, no changes in register setup. Signed-off-by: Jay Cornwall Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH 0/3] KFD upstreaming

New feature: queue priorities The eviction state logic change is preparation for some debugger support we're working on but haven't settled on the final ABI yet. Felix Kuehling (1): drm/amdkfd: Simplify eviction state logic Jay Cornwall (1): drm/amdkfd: Implement queue priority controls for

[PATCH 2/3] drm/amdkfd: CP queue priority controls

From: ozeng Translate queue priority into pipe priority and write to MQDs. The priority values are used to perform queue and pipe arbitration. Signed-off-by: Oak Zeng Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 20

Re: [PATCH] drm/amdkfd: Fix a potential circular lock

On 2019-05-28 2:28 p.m., Zeng, Oak wrote: > The idea to break the circular lock dependency is, unlock dqm > temporarily before calling init_mqd in call stack #1 (see below) > > [ 513.604034] == > [ 513.604205] WARNING: possible circular locking

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On Wed, 29 May 2019 at 02:47, Emil Velikov wrote: > > On 2019/05/28, Koenig, Christian wrote: > > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > > On 2019/05/28, Daniel Vetter wrote: > > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > > >> wrote: > > >>> Am 28.05.19 um 09:38 schrieb

Re: [PATCH] drm/amdkfd: Return proper error code for gws alloc API

Reviewed-by: Alex Deucher From: amd-gfx on behalf of Zeng, Oak Sent: Tuesday, May 28, 2019 3:53 PM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix; Zeng, Oak Subject: [PATCH] drm/amdkfd: Return proper error code for gws alloc API Change-Id:

[PATCH] drm/amdkfd: Return proper error code for gws alloc API

Change-Id: Iaa81c6aa5f97e888291771e1aa70b02fccdcb9e0 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +- 3 files changed, 3

[PATCH] drm/amdgpu: fix a race in GPU reset with IB test

Split late_init into two functions, one (do_late_init) which just does the hw init, and late_init which calls do_late_init and schedules the IB test work. Call do_late_init in the GPU reset code to run the init code, but not schedule the IB test code. The IB test code is called directly in the

[PATCH 0/2] drm/amd/display: Add HDR output metadata support for amdgpu

This patch series enables HDR output metadata support in amdgpu using the DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs over DP and HDMI. It's limited to static HDR metadata support for now since that's all the DRM interface supports. It requires a modeset for entering

[PATCH 1/2] drm/amd/display: Expose HDR output metadata for supported connectors

[Why] For userspace to send static HDR metadata to the display we need to attach the property on the connector and send it to DC. [How] The property is attached to HDMI and DP connectors. Since the metadata isn't actually available when creating the connector this isn't a property we can

[PATCH 2/2] drm/amd/display: Only force modesets when toggling HDR

[Why] We can issue HDR static metadata as part of stream updates for non-modesets as long as we force a modeset when entering or exiting HDR. This avoids unnecessary blanking for simple metadata updates. [How] When changing scaling and abm for the stream also check if HDR has changed and send

Re: [PATCH v2 4/4] drm/amdkfd: Check against device cgroup

Hello, On Fri, May 17, 2019 at 08:12:17PM +, Kuehling, Felix wrote: > Patches 1,2,4 will be submitted through amd-staging-drm-next. Patch 3 > goes through the cgroup tree. Patch 4 depends on patch 3. So submitting > patch 4 will need to wait until we rebase amd-staging-drm-next on a new >

Re: [PATCH v2 0/4] AMDKFD (AMD GPU compute) support for device cgroup.

Hello, On Fri, May 17, 2019 at 08:04:42PM +, Kasiviswanathan, Harish wrote: > 1). Documentation for user on how to use device cgroup for amdkfd device. I > have some more information on this in patch 4. I see. Yeah, I just missed that. Thanks. -- tejun

[PATCH] drm/amdkfd: Fix a potential circular lock

The idea to break the circular lock dependency is, unlock dqm temporarily before calling init_mqd in call stack #1 (see below) [ 513.604034] == [ 513.604205] WARNING: possible circular locking dependency detected [ 513.604375] 4.18.0-kfd-root

Re: Quick question for the mobile Raven Ridge auto-rotate function

The FCH team is working on a driver for it and should have something available by August. Alex From: amd-gfx on behalf of Luya Tshimbalanga Sent: Thursday, May 23, 2019 1:34 AM To: amd-gfx@lists.freedesktop.org Subject: Quick question for the mobile Raven

Re: [PATCH 07/10] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2

On Tue, May 28, 2019 at 1:05 PM Sam Ravnborg wrote: > > Hi Christian. > > On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote: > > From: Chunming Zhou > > > > add ticket for display bo, so that it can preempt busy bo. > > > > v2: fix stupid rebase error > > > > Change-Id:

Re: [PATCH 07/10] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2

Hi Christian. On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote: > From: Chunming Zhou > > add ticket for display bo, so that it can preempt busy bo. > > v2: fix stupid rebase error > > Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9 What is this? I do not recall seeing

Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel

On Thu, May 23, 2019 at 02:31:16PM -0700, Kees Cook wrote: > syzkaller already attempts to randomly inject non-canonical and > 0x addresses for user pointers in syscalls in an effort to > find bugs like CVE-2017-5123 where waitid() via unchecked put_user() was > able to write directly

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/28, Koenig, Christian wrote: > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > On 2019/05/28, Daniel Vetter wrote: > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > >> wrote: > >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter: > [SNIP] > > Might be a good idea looking

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote: > On Tue, May 28, 2019 at 04:40:58PM +0100, Catalin Marinas wrote: > > [...] > > > My thoughts on allowing tags (quick look): > > > > brk - no > > [...] > > > mlock, mlock2, munlock - yes > > mmap - no (we may change this with MTE

[PATCH 06/10] drm/ttm: fix busy memory to fail other user v10

BOs on the LRU might be blocked during command submission and cause OOM situations. Avoid this by blocking for the first busy BO not locked by the same ticket as the BO we are searching space for. v10: completely start over with the patch since we didn't handled a whole bunch of corner

[PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3

This avoids OOM situations when we have lots of threads submitting at the same time. v3: apply this to the whole driver, not just CS Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-

[PATCH 09/10] drm/amdgpu: create GDS, GWS and OA in system domain

And only move them in on validation. This allows for better control when multiple processes are fighting over those resources. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH 08/10] drm/amdgpu: drop some validation failure messages

The messages about amdgpu_cs_list_validate are duplicated because the caller will complain into the logs as well and we can also get interrupted by a signal here. Also fix the the caller to not report -EAGAIN from validation. Signed-off-by: Christian König ---

[PATCH 07/10] drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2

From: Chunming Zhou add ticket for display bo, so that it can preempt busy bo. v2: fix stupid rebase error Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9 Signed-off-by: Chunming Zhou Reviewed-by: Christian König --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21

[PATCH 05/10] drm/ttm: immediately move BOs to the new LRU v2

Move BOs which are currently in a lower domain to the new LRU before allocating backing space while validating. This makes sure that we always have enough entries on the LRU to allow for other processes to wait for an operation to complete. v2: generalize the test Signed-off-by: Christian König

[PATCH 04/10] drm/ttm: cleanup ttm_bo_mem_space

We tried this once before, but that turned out to be more complicated than thought. With all the right prerequisites it looks like we can do this now. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 127 ++- 1 file changed, 66 insertions(+), 61

[PATCH 01/10] drm/ttm: Make LRU removal optional v2

We are already doing this for DMA-buf imports and also for amdgpu VM BOs for quite a while now. If this doesn't run into any problems we are probably going to stop removing BOs from the LRU altogether. v2: drop BUG_ON from ttm_bo_add_to_lru Signed-off-by: Christian König ---

[PATCH 02/10] drm/ttm: return immediately in case of a signal

When a signal arrives we should return immediately for handling it and not try other placements first. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[PATCH 03/10] drm/ttm: remove manual placement preference

If drivers don't prefer a system memory placement they should not but it into the placement list first. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

Am 28.05.19 um 18:10 schrieb Emil Velikov: > On 2019/05/28, Daniel Vetter wrote: >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian >> wrote: >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter: [SNIP] > Might be a good idea looking into reverting it partially, so that at > least

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On 2019/05/28, Daniel Vetter wrote: > On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > wrote: > > > > Am 28.05.19 um 09:38 schrieb Daniel Vetter: > > > [SNIP] > > >> Might be a good idea looking into reverting it partially, so that at > > >> least command submission and buffer allocation is

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Tue, May 28, 2019 at 04:40:58PM +0100, Catalin Marinas wrote: [...] > My thoughts on allowing tags (quick look): > > brk - no [...] > mlock, mlock2, munlock - yes > mmap - no (we may change this with MTE but not for TBI) [...] > mprotect - yes I haven't following this discussion

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Tue, May 28, 2019 at 03:54:11PM +0100, Andrew Murray wrote: > On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote: > > On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote: > > > This patch is a part of a series that extends arm64 kernel ABI to allow to > > > pass tagged

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote: > On Mon, May 06, 2019 at 06:30:51PM +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

Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel

Thanks for a lot of valuable input! I've read through all the replies and got somewhat lost. What are the changes I need to do to this series? 1. Should I move untagging for memory syscalls back to the generic code so other arches would make use of it as well, or should I keep the arm64 specific

RX 580 and 5K displays, bandwidth validation failed whith multiple monitors

Hi, I have been facing an issue with my 5K display (iiyama ProLite XB2779QQS-S1). It works fine as long as it is the only active monitor, as soon as I activate another monitor the main one (5k) can't display more than 4k. Debug using "echo 0x4 > /sys/module/drm/parameters/debug" show this

Re: [PATCH 02/12] dma-buf: add dma_buf_(un)map_attachment_locked variants v3

On Mon, 27 May 2019 18:56:20 +0800 Christian Koenig wrote: > Thanks for the comments, but you are looking at a completely outdated > patchset. > > If you are interested in the newest one please ping me and I'm going to CC you > when I send out the next version. > Ping... Thanks Hillf

[PATCH] drm/amd/amdgpu: Remove duplicate including duplicate header

remove duplicate entry of soc15.h. Issue identified by includecheck Signed-off-by: Hariprasad Kelam --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index c763733..d723332

Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote: > /* > * Wrappers to pass the pt_regs argument. > */ > #define sys_personality sys_arm64_personality > +#define sys_mmap_pgoff sys_arm64_mmap_pgoff > +#define sys_mremap sys_arm64_mremap >

Re: [PATCH] drm/amdgpu/display: Fix reload driver error

On 5/28/19 6:28 AM, Emily Deng wrote: > Issue: > Will have follow error when reload driver: > [ 3986.567739] sysfs: cannot create duplicate filename > '/devices/pci:00/:00:07.0/drm_dp_aux_dev' > [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE > 5.0.0-rc1-custom

[PATCH] drm/amdgpu/display: Fix reload driver error

Issue: Will have follow error when reload driver: [ 3986.567739] sysfs: cannot create duplicate filename '/devices/pci:00/:00:07.0/drm_dp_aux_dev' [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE 5.0.0-rc1-custom #1 [ 3986.567745] Hardware name: QEMU Standard PC

RE: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer

Ping .. Best wishes Emily Deng >-Original Message- >From: amd-gfx On Behalf Of Emily >Deng >Sent: Tuesday, May 28, 2019 4:06 PM >To: amd-gfx@lists.freedesktop.org >Cc: Deng, Emily >Subject: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer > >As it will destroy

RE: [PATCH] drm/amdgpu: reserve stollen vram for raven series

> -Original Message- > From: amd-gfx On Behalf Of Cui, > Flora > Sent: Tuesday, May 28, 2019 3:55 PM > To: amd-gfx@lists.freedesktop.org > Cc: Cui, Flora > Subject: [PATCH] drm/amdgpu: reserve stollen vram for raven series > > to avoid screen corruption during modprobe. > > Change-Id:

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On Tue, May 28, 2019 at 10:03 AM Koenig, Christian wrote: > > Am 28.05.19 um 09:38 schrieb Daniel Vetter: > > [SNIP] > >> Might be a good idea looking into reverting it partially, so that at > >> least command submission and buffer allocation is still blocked. > > I thought the issue is a lot

[PATCH] drm/amdgpu:Fix the unpin warning about csb buffer

As it will destroy clear_state_obj, and also will unpin it in the gfx_v9_0_sw_fini, so don't need to call amdgpu_bo_free_kernel in gfx_v9_0_sw_fini, or it will have unpin warning. Signed-off-by: Emily Deng --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 +--- 1 file changed, 1 insertion(+), 3

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

Am 28.05.19 um 09:38 schrieb Daniel Vetter: > [SNIP] >> Might be a good idea looking into reverting it partially, so that at >> least command submission and buffer allocation is still blocked. > I thought the issue is a lot more than vainfo, it's pretty much every > hacked up compositor under the

[PATCH] drm/amdgpu: reserve stollen vram for raven series

to avoid screen corruption during modprobe. Change-Id: I8671de6ed46285585dbe866832c6d2b835ca37f3 Signed-off-by: Flora Cui --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c

RE: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin

>-Original Message- >From: Koenig, Christian >Sent: Tuesday, May 28, 2019 3:43 PM >To: Deng, Emily ; Quan, Evan >; amd-gfx@lists.freedesktop.org >Subject: Re: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin > >Am 28.05.19 um 09:38 schrieb Deng, Emily: >>> -Original Message-

Re: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin

Am 28.05.19 um 09:38 schrieb Deng, Emily: >> -Original Message- >> From: Koenig, Christian >> Sent: Tuesday, May 28, 2019 3:04 PM >> To: Quan, Evan ; Deng, Emily >> ; amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin >> >> Ok in this case

Re: [PATCH] drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu

Reviewed-by: Christian König Am 28.05.19 um 05:05 schrieb Cui, Flora: the patch is Reviewed-by: Flora Cui 在 5/28/2019 10:52 AM, Chunming Zhou 写道: Change-Id: I2b1af1478fbddbb5084b90b3ff85c2eb964bd217 Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On Tue, May 28, 2019 at 8:58 AM Koenig, Christian wrote: > > Am 27.05.19 um 17:26 schrieb Daniel Vetter: > > On Mon, May 27, 2019 at 3:42 PM Koenig, Christian > > wrote: > >> Am 27.05.19 um 15:26 schrieb Emil Velikov: > >>> On 2019/05/27, Daniel Vetter wrote: > On Mon, May 27, 2019 at

RE: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin

>-Original Message- >From: Koenig, Christian >Sent: Tuesday, May 28, 2019 3:04 PM >To: Quan, Evan ; Deng, Emily >; amd-gfx@lists.freedesktop.org >Subject: Re: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin > >Ok in this case the patch is a NAK. > >The correct solution is to stop

Re: [PATCH] drm/amdgpu: enable PCIE atomics ops support

Am 27.05.19 um 20:23 schrieb Kuehling, Felix: On 2019-05-27 7:51 a.m., Christian König wrote: That idea sounds sane to me as well. By the way, do we somewhere signal to userspace if atomics are supported or not? Yes. KFD topology (a flag in the iolink) provides that information to user mode.

Re: [PATCH] drm/amdgpu: fix ring test failure issue during s3 in vce 3.0

Wow, really good catch! The underlying problem is most likely that VCE block is either power or clock gated and because of this the readptr read always returns zero. Now amdgpu_ring_alloc() informs the power management code that the block is about to be used and so the gating is turned off.

Re: [PATCH] drm/amdgpu: Don't need to call csb_vram_unpin

Ok in this case the patch is a NAK. The correct solution is to stop using amdgpu_bo_free_kernel in gfx_v9_0_sw_fini. BTW: Are we using the kernel pointer somewhere? Cause that one became completely invalid because of patch "drm/amdgpu: pin the csb buffer on hw init". Christian. Am 28.05.19

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

Am 27.05.19 um 17:26 schrieb Daniel Vetter: > On Mon, May 27, 2019 at 3:42 PM Koenig, Christian > wrote: >> Am 27.05.19 um 15:26 schrieb Emil Velikov: >>> On 2019/05/27, Daniel Vetter wrote: On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote: > Am 27.05.19 um 10:17 schrieb