linux/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c, branch v4.11

drm/amdgpu: report the number of bytes moved at buffer creation

2017-02-09T16:29:44Z

Like ttm_bo_validate(), ttm_bo_init() might need to move BO and the number of bytes moved by TTM should be reported. This can help the throttle buffer migration mechanism to make a better decision. v2: fix computation Reviewed-by: Christian König Signed-off-by: Samuel Pitoiset Signed-off-by: Alex Deucher

drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

2017-02-09T16:28:24Z

When ttm_bo_init() fails, the reservation mutex should be unlocked. In debug build, the kernel reported "possible recursive locking detected" in this codepath. For debugging purposes, I also added a "WARN_ON(ww_mutex_is_locked())" when ttm_bo_init() fails and the mutex was locked as expected. This should fix (random) GPU hangs. The easy way to reproduce the issue is to change the "Super Sampling" option from 1.0 to 2.0 in Hitman. It will create a huge buffer, evict a bunch of buffers (around ~5k) and deadlock. This regression has been introduced pretty recently. v2: only release the mutex if resv is NULL Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2)") Reviewed-by: Christian König Signed-off-by: Samuel Pitoiset Signed-off-by: Alex Deucher

drm/amdgpu: shut up #warning for compile testing

2017-02-09T05:23:24Z

My randconfig tests on linux-next showed a newly introduced warning: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 'amdgpu_bo_create_restricted': drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp] Generally speaking, warnings about bad kernel configuration are not particularly helpful. We could enforce the selection of X86_PAT through Kconfig, so the driver cannot even be used unless it is enabled, or we could just rely on the runtime warning that is also there. In this version, I'm making the warning conditional on CONFIG_COMPILE_TEST, which shuts it up for me, but not people that may actually want to run the kernel as a compromize. Fixes: a2e2f29970aa ("drm/amdgpu: Bring bo creation in line with radeon driver (v2)") Reviewed-by: Michel Dänzer Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher

drm/amdgpu: Bring bo creation in line with radeon driver (v2)

2017-01-27T17:20:36Z

Add the bo creation changes that have been done to the radeon driver in recent times, e.g. disable GTT WC on 32 bit because it is broken there, and also disable it generally (and print a warning message) when CONFIG_X86_PAT is not set. v2: agd: fix warning in defined(CONFIG_X86) && !defined(CONFIG_X86_PAT) case Reviewed-by: Michel Dänzer Reviewed-by: Christian König Signed-off-by: Nils Holland Signed-off-by: Alex Deucher

drm/amdgpu: double the priority of kernel allocations

2017-01-27T17:20:34Z

Give kernel allocations a higher priority cause it is often more work to swap them back in. Signed-off-by: Christian König Reviewed-by: Roger.He Signed-off-by: Alex Deucher

drm/amdgpu: user BO priority instead of self coding it (v2)

2017-01-27T17:20:33Z

Keeping groups of BOs on the LRU is to time consuming on command submission. Instead use the newly added BO priority to give a certain eviction order. v2: agd: trivial warning fix Signed-off-by: Christian König Reviewed-by: Roger.He Signed-off-by: Alex Deucher

drm/amd/amdgpu: fix locking in bo creation error path

2017-01-27T16:13:29Z

Unlock the resv lock only if we were the ones to lock it in the first place. Signed-off-by: Nicolai Hähnle Reviewed-by: Edward O'Callaghan Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amd/amdgpu: lock reservation object while creating shadow bo

2017-01-27T16:13:28Z

ttm_bo_init checks that the reservation object is locked. This is the caller's responsibility when resv != NULL. Otherwise, the inline reservation object of the newly allocated buffer is used and must explicitly be locked. Uninterruptible w/w locks without an acquire context are always successful. v2: use ww_mutex_lock Signed-off-by: Nicolai Hähnle Reviewed-by: Edward O'Callaghan (v1) Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amd/amdgpu: move eviction counting to amdgpu_bo_move_notify

2017-01-27T16:13:16Z

This catches evictions of shadow page tables from the GART. Since shadow page tables are always stored in system memory, amdgpu_bo_move is never called for them. This fixes a crash during command submission that occurs when only a shadow page table and no other BOs were evicted since the last submission. Fixes: 1baa439fb2f4e586 ("drm/amdgpu: allocate shadow for pd/pt bo V2") Signed-off-by: Nicolai Hähnle Reviewed-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/ttm: add evict parameter to ttm_bo_driver::move_notify

2017-01-27T16:13:15Z

Ensure that the driver can listen to evictions even when they don't take the path through ttm_bo_driver::move. This is crucial for amdgpu, which relies on an eviction counter to skip re-binding page tables when possible. Signed-off-by: Nicolai Hähnle Reviewed-by: Chunming Zhou Reviewed-by: Christian König Signed-off-by: Alex Deucher