Re: [PATCH 0/3] drm/amdgpu: implement raster configuration

On Mon, Sep 26, 2016 at 10:42 PM, Deucher, Alexander wrote: >> -Original Message- >> From: Marek Olšák [mailto:mar...@gmail.com] >> Sent: Monday, September 26, 2016 4:39 PM >> To: Huang, Ray >> Cc: amd-gfx mailing list; Deucher, Alexander; Wang, Ken; Huan, Alvin

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

On Mon, Sep 26, 2016 at 8:29 PM, Lukas Wunner wrote: > On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote: >> Some code called by drm_crtc_force_disable_all() wants to wait for all >> fences, so only do fence teardown after CRTCs are disabled. > > Ugh, how

[PATCH] drm/amdgpu: add version bump for raster config programming

Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 2be20b4..28c6ea8 100644 ---

RE: [PATCH 0/3] drm/amdgpu: implement raster configuration

> -Original Message- > From: Marek Olšák [mailto:mar...@gmail.com] > Sent: Monday, September 26, 2016 4:39 PM > To: Huang, Ray > Cc: amd-gfx mailing list; Deucher, Alexander; Wang, Ken; Huan, Alvin > Subject: Re: [PATCH 0/3] drm/amdgpu: implement raster configuration > > The series is

Re: [PATCH] drm/amdgpu: add the interface of waiting multiple fences (v3)

On 13 September 2016 at 04:48, Deucher, Alexander wrote: >> -Original Message- >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >> Of Christian König >> Sent: Monday, September 12, 2016 2:46 PM >> To: Bas Nieuwenhuizen; Alex Deucher >>

Re: [PATCH] drm/amdgpu/i2c: add const where appropriate

On Sun, Sep 25, 2016 at 4:34 PM, Grazvydas Ignotas wrote: > Signed-off-by: Grazvydas Ignotas > --- Applied this whole set of patches. Thanks! Alex > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 14 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h |

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote: > Some code called by drm_crtc_force_disable_all() wants to wait for all > fences, so only do fence teardown after CRTCs are disabled. > > Signed-off-by: Grazvydas Ignotas Fixes: 84b89bdcedf8 ("drm/amdgpu:

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote: > Some code called by drm_crtc_force_disable_all() wants to wait for all > fences, so only do fence teardown after CRTCs are disabled. Ugh, how embarrassing, that was added by me. Do you have a BUG splat (e.g. soft lockup) for

Re: [PATCH 2/2] drm/amdgpu: improve VM PTE trace points

On Mon, Sep 26, 2016 at 7:47 AM, Christian König wrote: > From: Christian König > > Use a separate one for the copy operation and > log all the interesting parameters. > > Signed-off-by: Christian König Series is:

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

With current drm-next-4.9-wip plus drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping testdma is now working OK for my R9285 - just did 35k tests while simultaneously running valley/heaven, plus messing with powerplay/cpufreq and all is good, no lock, no vm faults. Andy Furniss

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

The function called is either amdgpu_vm_do_set_ptes() or amdgpu_vm_do_copy_ptes(). But that is actually rather unrelated to the local handling of addr in the function changed. The point here is we have handled the address offset by giving it to amdgpu_vm_map_gart() and so we shouldn't add

Re: [amdgpu][CIK] drm-next-4.9-wip - piglit test - max-texture-size - GPU deadlock

Hi, You can try this patch: drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping Marek On Fri, Sep 23, 2016 at 12:37 AM, Shawn Starr wrote: > When I try to run piglit, I get a GPU deadlock running max-texture-size, > > Test: spec/!opengl 1.1/max-texture-size >

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

I'm reading through the amdgpu_vm.c to try and see if the patch is correct but I'm not that familiar with the VM side of things. It seems to boil down to calling params->func() with a new dst value of NULL but that's where I'm stopped at the moment since I don't know what func() is. Nothing

RE: [PATCH] drm/amdgpu: bypass vce clock if vce is idle on Fiji.

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Rex Zhu > Sent: Saturday, September 24, 2016 4:39 AM > To: amd-gfx@lists.freedesktop.org > Cc: Zhu, Rex > Subject: [PATCH] drm/amdgpu: bypass vce clock if vce is idle on Fiji. > > Change-Id:

Re: Bonair support Kernel compiling instructions

Am 26.09.2016 um 02:52 schrieb Michel Dänzer: On 26/09/16 02:55 AM, Striker Leggette wrote: I am running a Lenovo Y700 with an R7 Carrizo APU and an R9 Bonaire GPU on Fedora 24. At the moment, the latest Fedora Kernel supports amdgpu for the Carrizo, and many things run very well on this.

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

Yeah, that wouldn't really help but just make the problem more unlikely to happen once more. Anyway Tom St confirmed that the patch seems to work for the open stack. Anybody brave enough to throw an rb on this so that I can commit it? Thanks, Christian. Am 26.09.2016 um 11:16 schrieb Flora

[PATCH 2/2] drm/amdgpu: improve VM PTE trace points

From: Christian König Use a separate one for the copy operation and log all the interesting parameters. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20 +++-

[PATCH 1/2] drm/amdgpu: fix GART_DEBUGFS define

From: Christian König Obviously missed during the rename. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

please ignore this patch. it actually revert the gtt mgr changes. On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote: > On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote: > > From: Christian König > > > > Otherwise we will look at the wrong place