Re: [PATCH 05/10] drm/amdgpu:fix memleak in takedown

On 2017年11月14日 20:00, Christian König wrote: Am 14.11.2017 um 12:52 schrieb Christian König: Am 14.11.2017 um 10:07 schrieb Monk Liu: this can fix the memory leak under the case that not all BO are freed during "takedown" stage, because originally it blocks following kfree on mgr. NAK, all

[PATCH] Revert "drm/radeon: dont switch vt on suspend"

Fixes distorted colors on some cards on resume from suspend. This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832 Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org ---

[PATCH 4/4] drm/amdkfd: Add support for user-mode trap handlers

A second-level user mode trap handler can be installed. The CWSR trap handler jumps to the secondary trap handler conditionally for any conditions not handled by it. This can be used e.g. for debugging or catching math exceptions. When CWSR is disabled, the user mode trap handler is installed as

[PATCH 2/4] drm/amdkfd: Add trap handler for CWSR

The trap handler is like an interrupt handler running on the GPU compute unit. It is needed for supporting CWSR (compute wave save/restore). This file defines an array with the pre-compiled GFXv8 shader ISA. The assembly code is included for reference in #if 0 ... #endif. Signed-off-by:

[PATCH 3/4] drm/amdkfd: Add CWSR support

This hardware feature allows the GPU to preempt shader execution in the middle of a compute wave, save the state and restore it later to resume execution. Memory for saving the state is allocated per queue in user mode and the address and size passed to the create_queue ioctl. The size depends on

[PATCH 1/4] drm/amdkfd: Cleanup qpd.pqm initialization

The PQM doesn't change after process creation. So initialize it in kfd_create_process_device_data. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 4 +--- 2 files

[DC] [CRTC:44:crtc-0] vblank wait timed out

Hi, might this be related to this bug I reportet some time ago? https://bugs.freedesktop.org/show_bug.cgi?id=103489 I currently work around it be reverting the following commits: 8459f633b65a81979b9b233ed0a91a9fdc98b7bd c196cbe065da1c9b5f7683af9cdd0889760151c1

Re: [DC] [CRTC:44:crtc-0] vblank wait timed out

On 11/14/2017 01:06 PM, Michel Dänzer wrote: I sometimes get the attached dmesg splat when the GDM login screen times out and fades to black (presumably specifically when it finally sets DPMS off, which disables the vblank interrupt). As you mention this and also that this happens

Re: [PATCH] drm/amd/display: Drop stream_for_cursor from dcn10_apply_ctx_for_surface

On 2017-11-14 12:57 PM, Michel Dänzer wrote: > From: Michel Dänzer > > The main motivation was that it was at least theoretically possible for > stream_for_cursor to be dereferenced when it was NULL. > > The code also becomes slightly smaller, and hopefully easier to >

RE: [DC] [CRTC:44:crtc-0] vblank wait timed out

Michel, Would you mind attaching the full dmesg? We'll have a look. Thanks, Jordan -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: Tuesday, November 14, 2017 1:06 PM To: amd-gfx@lists.freedesktop.org Cc: dc_upstream Subject: [DC]

RE: [PATCH 56/73] drm/amd/display: Remove dangling planes on dc commit state

DC always work off current context. If we don't swap in a context with plane removed, HWSS will be doing the wrong programming when we enable streams and planes. -Original Message- From: Grodzovsky, Andrey Sent: Tuesday, November 14, 2017 10:08 AM To: Li, Sun peng (Leo)

[DC] [CRTC:44:crtc-0] vblank wait timed out

I sometimes get the attached dmesg splat when the GDM login screen times out and fades to black (presumably specifically when it finally sets DPMS off, which disables the vblank interrupt). I've seen this for the first time today, so it might have been introduced by one of the DC changes which

[PATCH] drm/amd/display: Drop stream_for_cursor from dcn10_apply_ctx_for_surface

From: Michel Dänzer The main motivation was that it was at least theoretically possible for stream_for_cursor to be dereferenced when it was NULL. The code also becomes slightly smaller, and hopefully easier to understand. Signed-off-by: Michel Dänzer

RE: [PATCH] amdgpu: Don't use DRM_ERROR when failing to allocate a BO

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Michel Dänzer > Sent: Tuesday, November 14, 2017 12:52 PM > To: amd-gfx@lists.freedesktop.org > Subject: [PATCH] amdgpu: Don't use DRM_ERROR when failing to allocate a > BO > > From: Michel

[PATCH] amdgpu: Don't use DRM_ERROR when failing to allocate a BO

From: Michel Dänzer This can be triggered by userspace, e.g. trying to allocate too large a BO, so it shouldn't log anything by default. Callers need to handle failure anyway. Signed-off-by: Michel Dänzer ---

Re: [PATCH 38/73] drm/amd/display: Fix warnings on S3 resume

On 11/14/2017 11:00 AM, Leo Li wrote: On 2017-11-10 01:40 PM, Andrey Grodzovsky wrote: On 11/10/2017 01:38 PM, Andrey Grodzovsky wrote: On 11/09/2017 03:05 PM, Harry Wentland wrote: From: "Leo (Sunpeng) Li" This is a followup to the following revert: Rex Zhu

Re: [PATCH 38/73] drm/amd/display: Fix warnings on S3 resume

On 2017-11-10 01:40 PM, Andrey Grodzovsky wrote: On 11/10/2017 01:38 PM, Andrey Grodzovsky wrote: On 11/09/2017 03:05 PM, Harry Wentland wrote: From: "Leo (Sunpeng) Li" This is a followup to the following revert: Rex Zhu    Revert "drm/amd/display: Match actual

Re: [PATCH] drm/amdgpu: set f_mapping on exported DMA-bufs

On Tue, Nov 14, 2017 at 7:13 AM, Christian König wrote: > Otherwise we can't correctly CPU map TTM buffers. > > Signed-off-by: Christian König Acked-by: Alex Deucher > --- >

Re: [PATCH 07/10] drm/amdgpu:free CSA in unified place

Thought so, in this case the patch is Reviewed-by: Christian König . Regards, Christian. Am 14.11.2017 um 16:02 schrieb Liu, Monk: Yeah CSA is allocated right after in GMC hw init (and after WB_INIT) So we can put the free of it right before WB_INIT, thus avoiding

Re: [PATCH] drm/amdgpu: Properly allocate VM invalidate eng v2

Am 14.11.2017 um 16:22 schrieb Oak Zeng: From: ozeng v1: Properly allocate TLB invalidation engine to avoid conflict. v2: Added comments to codes Change-Id: I9a32cbcb133c07d7efad1a7bd07c6e2098c747e7 Signed-off-by: Oak Zeng Reviewed-by: Christian König

Re: [PATCH 05/10] drm/amdgpu:fix memleak in takedown

Makes sense, Reviewed-by: Christian König fro this one as well. Regards, Christian. Am 14.11.2017 um 16:00 schrieb Liu, Monk: Actually " drm_mm_takedown" below will give you the warning if some BO is still in MM That means below part is totally useless: -

Re: regression on Carrizo display bringup

On 14/11/17 03:37 PM, Tom St Denis wrote: > On 14/11/17 09:36 AM, Harry Wentland wrote: >> On 2017-11-14 08:30 AM, Tom St Denis wrote: >>> Hi all, >>> >>> Found when testing the tip of drm-next on my A12-9800 Carrizo. >>> >>> [root@carrizo linux]# git bisect good >>>

Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4

On 14/11/17 01:18 PM, Christian König wrote: > Am 14.11.2017 um 11:02 schrieb Michel Dänzer: >> On 13/11/17 10:54 AM, Christian König wrote: >>> >>> +    } else { >>> +    locked = reservation_object_trylock(bo->resv); >>> +    if (!locked) >>> +   

Re: [PATCH] drm/amdgpu: Properly allocate VM invalidate eng v2

On Tue, Nov 14, 2017 at 10:22 AM, Oak Zeng wrote: > From: ozeng > > v1: Properly allocate TLB invalidation engine to avoid conflict. > v2: Added comments to codes > > Change-Id: I9a32cbcb133c07d7efad1a7bd07c6e2098c747e7 > Signed-off-by: Oak Zeng

[PATCH] drm/amdgpu: Properly allocate VM invalidate eng v2

From: ozeng v1: Properly allocate TLB invalidation engine to avoid conflict. v2: Added comments to codes Change-Id: I9a32cbcb133c07d7efad1a7bd07c6e2098c747e7 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 15 --- 1 file

Re: [PATCH] drm/amd/display: fix static checker warning

On 2017-11-10 04:14 AM, S, Shirish wrote: > From: Shirish S > > This patch fixes static checker warning of > "warn: cast after binop" introduced by > 56087b31 drm/amd/display: fix high part address in > dm_plane_helper_prepare_fb() > > Signed-off-by: Shirish S

Re: [PATCH 56/73] drm/amd/display: Remove dangling planes on dc commit state

Ok, got it. Thanks, Andrey On 11/14/2017 10:10 AM, Cheng, Tony wrote: DC always work off current context. If we don't swap in a context with plane removed, HWSS will be doing the wrong programming when we enable streams and planes. -Original Message- From: Grodzovsky, Andrey Sent:

Re: [PATCH 56/73] drm/amd/display: Remove dangling planes on dc commit state

On 11/13/2017 04:53 PM, Leo Li wrote: On 2017-11-10 02:00 PM, Andrey Grodzovsky wrote: On 11/09/2017 03:05 PM, Harry Wentland wrote: From: "Leo (Sunpeng) Li" When disabling pipe splitting, we need to make sure we disable both planes used. This should be done for

RE: [PATCH 07/10] drm/amdgpu:free CSA in unified place

Yeah CSA is allocated right after in GMC hw init (and after WB_INIT) So we can put the free of it right before WB_INIT, thus avoiding doing it in each GFX IP's sw_init -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2017年11月14日 19:55 To: Liu,

RE: [PATCH 05/10] drm/amdgpu:fix memleak in takedown

Actually " drm_mm_takedown" below will give you the warning if some BO is still in MM That means below part is totally useless: >> -spin_lock(>lock); >> -if (!drm_mm_clean(>mm)) { >> -spin_unlock(>lock); >> -return -EBUSY; >> -} >> - And the worse thing is this

Re: regression on Carrizo display bringup

On 2017-11-14 08:30 AM, Tom St Denis wrote: > Hi all, > > Found when testing the tip of drm-next on my A12-9800 Carrizo. > > [root@carrizo linux]# git bisect good > 138a3358c17918bb5cd5aa1ea9e8760ac69c515d is the first bad commit > commit 138a3358c17918bb5cd5aa1ea9e8760ac69c515d > Author:

Re: [PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace v3

Quoting Chris Wilson (2017-11-14 14:39:29) > Quoting Christian König (2017-11-14 14:24:35) > > The amdgpu issue to also need signaled fences in the reservation objects > > should be fixed by now. > > > > Optimize the list by keeping only the not signaled yet fences around. > > > > v2: temporary

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Christian König (2017-11-14 14:24:36) > The amdgpu issue to also need signaled fences in the reservation objects > should > be fixed by now. > > Optimize the handling by replacing a signaled fence when adding a new > shared one. > > Signed-off-by: Christian König

Re: uninitialized variable in dcn10 code

On 2017-11-14 09:33 AM, Michel Dänzer wrote: > On 14/11/17 01:29 PM, Tom St Denis wrote: >> Hi Harry, >> >> At display/dc/dcn10/dcn10_hw_sequencer.c:2140 >> >> if (num_planes > 0) { >>     struct dc_stream_state *stream_for_cursor; >> >>     program_all_pipe_in_tree(dc,

Re: [PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace v3

Quoting Christian König (2017-11-14 14:24:35) > The amdgpu issue to also need signaled fences in the reservation objects > should be fixed by now. > > Optimize the list by keeping only the not signaled yet fences around. > > v2: temporary put the signaled fences at the end of the new container >

Re: regression on Carrizo display bringup

On 14/11/17 09:36 AM, Harry Wentland wrote: On 2017-11-14 08:30 AM, Tom St Denis wrote: Hi all, Found when testing the tip of drm-next on my A12-9800 Carrizo. [root@carrizo linux]# git bisect good 138a3358c17918bb5cd5aa1ea9e8760ac69c515d is the first bad commit commit

Re: uninitialized variable in dcn10 code

On 2017-11-14 07:29 AM, Tom St Denis wrote: > Hi Harry, > > At display/dc/dcn10/dcn10_hw_sequencer.c:2140 > > if (num_planes > 0) { >     struct dc_stream_state *stream_for_cursor; > >     program_all_pipe_in_tree(dc, top_pipe_to_program, context); > >     for (i = 0; i <

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Quoting Christian König (2017-11-14 14:24:44) > Am 06.11.2017 um 17:22 schrieb Chris Wilson: > > Quoting Christian König (2017-10-30 14:59:04) > >> From: Christian König > >> > >> The amdgpu issue to also need signaled fences in the reservation objects > >> should > >>

Re: uninitialized variable in dcn10 code

On 14/11/17 01:29 PM, Tom St Denis wrote: > Hi Harry, > > At display/dc/dcn10/dcn10_hw_sequencer.c:2140 > > if (num_planes > 0) { >     struct dc_stream_state *stream_for_cursor; > >     program_all_pipe_in_tree(dc, top_pipe_to_program, context); > >     for (i = 0; i <

Re: [PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

Am 06.11.2017 um 17:22 schrieb Chris Wilson: Quoting Christian König (2017-10-30 14:59:04) From: Christian König The amdgpu issue to also need signaled fences in the reservation objects should be fixed by now. Optimize the handling by replacing a signaled fence when

[PATCH 1/2] dma-buf: keep only not signaled fence in reservation_object_add_shared_replace v3

The amdgpu issue to also need signaled fences in the reservation objects should be fixed by now. Optimize the list by keeping only the not signaled yet fences around. v2: temporary put the signaled fences at the end of the new container v3: put the old fence at the end of the new container as

[PATCH 2/2] dma-buf: try to replace a signaled fence in reservation_object_add_shared_inplace

The amdgpu issue to also need signaled fences in the reservation objects should be fixed by now. Optimize the handling by replacing a signaled fence when adding a new shared one. Signed-off-by: Christian König --- drivers/dma-buf/reservation.c | 18 +++---

[PATCH libdrm] amdgpu: Disable deadlock test suite for Vega 10

The suite stalls the CP, until RCA is done the suite is disabled to not disrupt regression testing. Signed-off-by: Andrey Grodzovsky --- tests/amdgpu/amdgpu_test.c| 2 +- tests/amdgpu/amdgpu_test.h| 5 + tests/amdgpu/deadlock_tests.c | 19

regression on Carrizo display bringup

Hi all, Found when testing the tip of drm-next on my A12-9800 Carrizo. [root@carrizo linux]# git bisect good 138a3358c17918bb5cd5aa1ea9e8760ac69c515d is the first bad commit commit 138a3358c17918bb5cd5aa1ea9e8760ac69c515d Author: Yongqiang Sun Date: Tue Nov 7 11:01:34

Re: [PATCH libdrm v2] amdgpu: Add memory over allocation test.

Am 14.11.2017 um 13:53 schrieb Andrey Grodzovsky: On 11/14/2017 03:44 AM, Christian König wrote: Am 13.11.2017 um 18:01 schrieb Andrey Grodzovsky: Allocates 1 TB of memory. Test is disabled by default since it's triggers OOM killer. v2: FIx the test to only alloc the BO and assert if return

Re: [PATCH libdrm v2] amdgpu: Add memory over allocation test.

On 11/14/2017 03:44 AM, Christian König wrote: Am 13.11.2017 um 18:01 schrieb Andrey Grodzovsky: Allocates 1 TB of memory. Test is disabled by default since it's triggers OOM killer. v2: FIx the test to only alloc the BO and assert if return value not equal to -ENOMEM and remove test disable

uninitialized variable in dcn10 code

Hi Harry, At display/dc/dcn10/dcn10_hw_sequencer.c:2140 if (num_planes > 0) { struct dc_stream_state *stream_for_cursor; program_all_pipe_in_tree(dc, top_pipe_to_program, context); for (i = 0; i < dc->res_pool->pipe_count; i++) {

Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4

Am 14.11.2017 um 11:02 schrieb Michel Dänzer: On 13/11/17 10:54 AM, Christian König wrote: Deleted BOs with the same reservation object can be reaped even if they can't be reserved. v2: rebase and we still need to remove/add the BO from/to the LRU. v3: fix remove/add one more time, cleanup the

Re: [PATCH 05/10] drm/amdgpu:fix memleak in takedown

Am 14.11.2017 um 12:52 schrieb Christian König: Am 14.11.2017 um 10:07 schrieb Monk Liu: this can fix the memory leak under the case that not all BO are freed during "takedown" stage, because originally it blocks following kfree on mgr. NAK, all BOs must be freed before we take down at least

Re: [PATCH 10/10] drm/amdgpu:show error message if fail on event4

Am 14.11.2017 um 10:07 schrieb Monk Liu: Change-Id: I984697748672421a05f179a7bf4eeb0255b28bdc Signed-off-by: Monk Liu Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH 09/10] drm/amdgpu:fix memleak

Am 14.11.2017 um 10:07 schrieb Monk Liu: those RLC used buffers are not cleared in GFX's sw_fini Change-Id: I0c9204753caa327cfbabdfb1465d2c03012ee977 Signed-off-by: Monk Liu Reviewed-by: Christian König ---

Re: [PATCH 08/10] drm/amdgpu:cleanup firmware.fw_buf alloc/free

Am 14.11.2017 um 10:07 schrieb Monk Liu: use bo_create/free_kernel instead of manually doing it Change-Id: I128651d2b2207f6e16b484b050f3232c08b53de3 Signed-off-by: Monk Liu Reviewed-by: Christian König ---

Re: [PATCH 07/10] drm/amdgpu:free CSA in unified place

Am 14.11.2017 um 10:07 schrieb Monk Liu: instead of doing it in each GFX ip's sw_fini Mhm, is that allocated in the same way as well? Change-Id: Idf0fd500d4fc385cf7a930cc56305070c937bf20 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +

Re: [PATCH 06/10] drm/amdgpu:cleanup unused stack var

Am 14.11.2017 um 10:07 schrieb Monk Liu: Change-Id: I5d3ea5facc23bcc94806a098ae9455ce1564fa09 Signed-off-by: Monk Liu Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-- 1 file changed, 1 insertion(+), 2

Re: [PATCH 05/10] drm/amdgpu:fix memleak in takedown

Am 14.11.2017 um 10:07 schrieb Monk Liu: this can fix the memory leak under the case that not all BO are freed during "takedown" stage, because originally it blocks following kfree on mgr. NAK, all BOs must be freed before we take down at least the GTT manager. That we run into a memory leak

Re: [PATCH 04/10] drm/amdgpu:put reserve_fw_vram_fini to correct place

Am 14.11.2017 um 10:07 schrieb Monk Liu: Move "reserve_fw_vram_fini" to the correct place which should in amdgpu_ttm_fini() since reserve_fw_vram_init is in amdgpu_ttm_init(). this can fix error report and memory leak in "vram_mgr_fini()". Change-Id: I4b1dc7eecda62407f30a5a16f59555eee49f04a3

Re: [PATCH 03/10] drm/amdgpu:fix NULL pointer access during drv remove

Am 14.11.2017 um 10:07 schrieb Monk Liu: NULL pointer is because original logic will step into set_pde_pte() even after the gart.ptr is freed due to there are twice gart_unbind() on all gart area. also, there are other minor fixes: 1,since gart_init only create dummy page, the corresponding

Re: [PATCH 01/10] drm/amdgpu:cleanup stolen vga memory finish

Am 14.11.2017 um 10:07 schrieb Monk Liu: Change-Id: Id641e125f3dafc54223e49ee444ab64249e7e3a1 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git

Re: [PATCH 02/10] drm/amdgpu:cleanup GMC & gart garbage function

Am 14.11.2017 um 10:07 schrieb Monk Liu: for gart_ram_alloc/free, they are never used in driver thus ripe them out totally. for gart_vram_pin/unpin, they are not needed becuase we can use bo_creat_kernel/free to replace the original manual way in the gart_vram_alloc/free, thus

Re: [PATCH] drm/amdgpu: Properly allocate VM invalidate engine

Am 14.11.2017 um 03:30 schrieb Chunming Zhou: On 2017年11月14日 01:22, Christian König wrote: Am 13.11.2017 um 17:12 schrieb Oak Zeng: From: ozeng Properly allocate TLB invalidation engine to avoid conflict. The latest engine allocation on gfx9 is: Engine 0, 1: idle Engine

Re: [PATCH 1/2] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional v2

On 13/11/17 10:54 AM, Christian König wrote: > Needed for the next patch. > > v2: actually predicate all unlocks > > Signed-off-by: Christian König [...] > @@ -531,24 +533,28 @@ static int ttm_bo_cleanup_refs_and_unlock(struct > ttm_buffer_object *bo, >

Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4

On 13/11/17 10:54 AM, Christian König wrote: > Deleted BOs with the same reservation object can be reaped even if they > can't be reserved. > > v2: rebase and we still need to remove/add the BO from/to the LRU. > v3: fix remove/add one more time, cleanup the logic a bit > v4: we should still

[PATCH 09/10] drm/amdgpu:fix memleak

those RLC used buffers are not cleared in GFX's sw_fini Change-Id: I0c9204753caa327cfbabdfb1465d2c03012ee977 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 8 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 +

[PATCH 10/10] drm/amdgpu:show error message if fail on event4

Change-Id: I984697748672421a05f179a7bf4eeb0255b28bdc Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

[PATCH 08/10] drm/amdgpu:cleanup firmware.fw_buf alloc/free

use bo_create/free_kernel instead of manually doing it Change-Id: I128651d2b2207f6e16b484b050f3232c08b53de3 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 43 +++ 1 file changed, 9 insertions(+), 34 deletions(-) diff --git

[PATCH 06/10] drm/amdgpu:cleanup unused stack var

Change-Id: I5d3ea5facc23bcc94806a098ae9455ce1564fa09 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

[PATCH 07/10] drm/amdgpu:free CSA in unified place

instead of doing it in each GFX ip's sw_fini Change-Id: Idf0fd500d4fc385cf7a930cc56305070c937bf20 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 6 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 1

[PATCH 05/10] drm/amdgpu:fix memleak in takedown

this can fix the memory leak under the case that not all BO are freed during "takedown" stage, because originally it blocks following kfree on mgr. Change-Id: I56e832ac317215a4d9f58edb8e75ea722158715c Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6

[PATCH 03/10] drm/amdgpu:fix NULL pointer access during drv remove

NULL pointer is because original logic will step into set_pde_pte() even after the gart.ptr is freed due to there are twice gart_unbind() on all gart area. also, there are other minor fixes: 1,since gart_init only create dummy page, the corresponding gart_fini shouldn't do more like unbinding all

[PATCH 04/10] drm/amdgpu:put reserve_fw_vram_fini to correct place

Move "reserve_fw_vram_fini" to the correct place which should in amdgpu_ttm_fini() since reserve_fw_vram_init is in amdgpu_ttm_init(). this can fix error report and memory leak in "vram_mgr_fini()". Change-Id: I4b1dc7eecda62407f30a5a16f59555eee49f04a3 Signed-off-by: Monk Liu

[PATCH 00/10] *** bug fixing and cleanups ***

patch 3 is to fix kernel driver cannot removed bug (new regression) patch 1,2,6,7,8,10 are the cleanups to make code more readable and simple patch 4,5,9 are the fixes for memory leak bug after driver unloaded Monk Liu (10): drm/amdgpu:cleanup stolen vga memory finish drm/amdgpu:cleanup

[PATCH 02/10] drm/amdgpu:cleanup GMC & gart garbage function

for gart_ram_alloc/free, they are never used in driver thus ripe them out totally. for gart_vram_pin/unpin, they are not needed becuase we can use bo_creat_kernel/free to replace the original manual way in the gart_vram_alloc/free, thus gart_vram_pin/unpin can also be riped out. Change-Id:

[PATCH 01/10] drm/amdgpu:cleanup stolen vga memory finish

Change-Id: Id641e125f3dafc54223e49ee444ab64249e7e3a1 Signed-off-by: Monk Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4

Am 14.11.2017 um 03:40 schrieb Chunming Zhou: On 2017年11月13日 17:54, Christian König wrote: Deleted BOs with the same reservation object can be reaped even if they can't be reserved. v2: rebase and we still need to remove/add the BO from/to the LRU. v3: fix remove/add one more time, cleanup

Re: [PATCH] drm/amd/amdgpu: not allow gtt size exceed system memory size

Am 13.11.2017 um 23:34 schrieb Felix Kuehling: On 2017-11-10 07:02 AM, Christian König wrote: Am 10.11.2017 um 12:33 schrieb Roger He: since sometimes VRAM size is bigger than system memory Change-Id: I5b14d18ed7a9f79810cc50c023ac9e240bddf101 Signed-off-by: Roger He ---  

Re: [PATCH 1/4] drm/amdgpu/gfx7: cache raster_config values

Am 13.11.2017 um 22:09 schrieb Alex Deucher: We did this for gfx6 and 8, but somehow missed gfx7. Signed-off-by: Alex Deucher This one is Reviewed-by: Christian König , the rest of the series is Acked-by: Christian König

Re: [PATCH libdrm v2] amdgpu: Add memory over allocation test.

Am 13.11.2017 um 18:01 schrieb Andrey Grodzovsky: Allocates 1 TB of memory. Test is disabled by default since it's triggers OOM killer. v2: FIx the test to only alloc the BO and assert if return value not equal to -ENOMEM and remove test disable on start. Signed-off-by: Andrey Grodzovsky