[PATCH] drm/amdgpu: release allocated memory

2019-09-20 Thread Navid Emamdoost
In amdgpu_vmid_grab_idle, fences is being leaked in one execution path. The missing kfree was added. Signed-off-by: Navid Emamdoost --- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c

Re: linux-next: Tree for Sep 20 (amdgpu-2)

2019-09-20 Thread Randy Dunlap
On 9/20/19 9:36 AM, Mark Brown wrote: > Hi all, > > News: There will likely be no more -next builds until Stephen returns on > the 30th, I *may* do some next week but it's more likely that I won't > and it certainly won't be every day. > > Changes since 20190919: > on x86_64: (1) where is

Re: [PATCH] drm/amdgpu/display: fix 64 bit divide

2019-09-20 Thread Harry Wentland
On 2019-09-20 4:18 p.m., Alex Deucher wrote: > Use proper helper for 32 bit. > > Signed-off-by: Alex Deucher Reviewed-by: Harry Wentland Harry > --- > .../gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c| 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git

[PATCH] drm/amdgpu/display: fix 64 bit divide

2019-09-20 Thread Alex Deucher
Use proper helper for 32 bit. Signed-off-by: Alex Deucher --- .../gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c| 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c

[PATCH] drm/amdgpu/atomfirmware: use proper index for querying vram type

2019-09-20 Thread Alex Deucher
The index is stored in scratch register 4 after asic init. Use that index. No functional change since all asics in a family use the same type of vram (G5, G6, HBM) and that is all we use at the monent, but if we ever need to query other info, we will now have the proper index. Signed-off-by:

Re: linux-next: Tree for Sep 20 (amd/display)

2019-09-20 Thread Randy Dunlap
On 9/20/19 9:36 AM, Mark Brown wrote: > Hi all, > > News: There will likely be no more -next builds until Stephen returns on > the 30th, I *may* do some next week but it's more likely that I won't > and it certainly won't be every day. > > Changes since 20190919: > on i386: ld:

Re: [PATCH xf86-video-ati] Don't set up black scanout buffer if LeaveVT is called from CloseScreen

2019-09-20 Thread Alex Deucher
On Fri, Sep 20, 2019 at 1:01 PM Michel Dänzer wrote: > > From: Michel Dänzer > > Avoids a crash described in > https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/43#note_223718 > > (Ported from amdgpu commit 5b8bc9fc505c551dcd9b0ed5ab835a49fa4f9fda) > > Signed-off-by:

Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

2019-09-20 Thread Daniel Vetter
On Tue, Dec 12, 2017 at 10:34 AM Roger He wrote: > > on_alloc_stage: is this operation on allocation stage > resv: reservation bo used of this operation > > Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0 > Signed-off-by: Roger He Real commit message (the later patches using this are even

[PATCH xf86-video-ati] Don't set up black scanout buffer if LeaveVT is called from CloseScreen

2019-09-20 Thread Michel Dänzer
From: Michel Dänzer Avoids a crash described in https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/43#note_223718 (Ported from amdgpu commit 5b8bc9fc505c551dcd9b0ed5ab835a49fa4f9fda) Signed-off-by: Michel Dänzer --- src/radeon_kms.c | 10 +- 1 file changed, 9

[PATCH xf86-video-ati] Don't call unreference FB of pixmaps from different screens in LeaveVT

2019-09-20 Thread Michel Dänzer
From: Michel Dänzer FindClientResourcesByType finds pixmaps from all screens, but trying to process ones from other screens here makes no sense and likely results in a crash or memory corruption. Signed-off-by: Michel Dänzer --- src/radeon_kms.c | 27 +-- 1 file

Re: libdrm patch merge request

2019-09-20 Thread Michel Dänzer
On 2019-09-19 4:56 a.m., Ma, Le wrote: > Thanks Alex. BTW, merge requests (MRs) are enabled now for the drm repository, so it's probably best to use MRs from now on. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast |

[amd-staging-drm-nex] Planned move to 5.3+ soon?

2019-09-20 Thread Dieter Nützel
Hello Alex, after release of 5.3 my devel system was migrated to compressed firmware files. So current 'amd-staging-drm-next' can't boot any longer and I can't test anything on it for you (AMD) ;-) Greetings, Dieter PS I'm NOT on amd-gfx. ___

Re: [PATCH v8] drm/amd/amdgpu:Fix compute ring unable to detect hang.

2019-09-20 Thread Christian König
Am 20.09.19 um 08:57 schrieb Jesse Zhang: When compute fence did not signal, compute ring cannot detect hardware hang because its timeout value is set to be infinite by default. In SR-IOV and passthrough mode, if user does not declare custome timeout value for compute ring, then use gfx ring

Re: [PATCH] drm/amdgpu: remove gfx9 NGG

2019-09-20 Thread Christian König
Am 20.09.19 um 04:15 schrieb Marek Olšák: From: Marek Olšák Never used. Signed-off-by: Marek Olšák Acked-by: Christian König Nice cleanup, Christian. --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 41 -

Re: [PATCH 3/6] drm/amdgpu/vm: fix up documentation in amdgpu_vm.c

2019-09-20 Thread Christian König
Am 19.09.19 um 23:45 schrieb Alex Deucher: Missing parameters, wrong comment type, etc. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

[PATCH v8] drm/amd/amdgpu:Fix compute ring unable to detect hang.

2019-09-20 Thread Jesse Zhang
When compute fence did not signal, compute ring cannot detect hardware hang because its timeout value is set to be infinite by default. In SR-IOV and passthrough mode, if user does not declare custome timeout value for compute ring, then use gfx ring timeout value as default. So that when there

RE: [PATCH] drm/amdgpu: remove gfx9 NGG

2019-09-20 Thread Yan, Alex
These registers are used in GFX9 NGG and the addresses are managed by KMD; GFX10 has changed the design; UMD does not need to care about these values any more. I can confirm UMD does not read these values from KMD. Alex -Original Message- From: Zhou, David(ChunMing) Sent: Friday,