On 29.07.2016 20:38, Deucher, Alexander wrote:
>> -Original Message-
>> From: Sean Paul [mailto:seanpaul at google.com]
>> Sent: Friday, July 29, 2016 3:35 PM
>> To: Wei Yongjun
>> Cc: Deucher, Alexander; Koenig, Christian; Dave Airlie; Jiang, Sonny; Liu,
>> Leo;
>> Nath, Arindam; Zhou, Da
On 02.08.2016 12:08, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes warnings and miscompilation resulting in crashes with clang.
How annoying. Seems like this would affect most (current and future)
uses of container_of, and so it would be better to switch to the Linux
kernel version of
On 03.08.2016 11:09, Dan Carpenter wrote:
> Hello Nicolai Hähnle,
>
> The patch 324c614a819a: "drm/amdgpu/gfx7: set
> USER_SHADER_ARRAY_CONFIG based on disable_cu parameter" from Jun 17,
> 2016, leads to the following static checker warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5057 gfx
On 19.10.2016 01:40, Marek Olšák wrote:
> * We can build upon this idea. I think the worst thing to do would
> be to add metadata handling to driver-agnostic userspace APIs. Really,
> driver-agnostic APIs shouldn't know about that, because they can't
> understand all the hw-specific information
On 29.03.2017 11:36, Michel Dänzer wrote:
On 29/03/17 06:07 PM, Christian König wrote:
Am 29.03.2017 um 10:59 schrieb Michel Dänzer:
On 28/03/17 08:00 PM, Julien Isorce wrote:
On 28 March 2017 at 10:36, Michel Dänzer mailto:mic...@daenzer.net>> wrote:
On 28/03/17 05:24 PM, Julien Isorce
From: Nicolai Hähnle
Changes include: PRT and preemption flags, sensor info, and some more
changes for Vega10.
Generated using make headers_install from airlied/drm-next commit
320d8c3d38739fa8e31a076b86cbdafcf8897d5e.
Signed-off-by: Nicolai Hähnle
---
include/drm/amdgpu_drm.h | 56
From: Nicolai Hähnle
This was already done in commit 3dc002df3e5 ("amdgpu: sync amdgpu_drm.h
with kernel 4.11-rc2"), now update the README accordingly.
Signed-off-by: Nicolai Hähnle
---
include/drm/README | 4
1 file changed, 4 deletions(-)
diff --git a/include/drm/README b/i
From: Junwei Zhang
v2: fix indent
Signed-off-by: Junwei Zhang
Reviewed-by: Nicolai Hähnle
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index f725bfd..8bc1ebd 100644
--- a
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS
instead of a placement limit. That allows us to better handle CPU
accessible placements.
Signed-off-by: Christian König
Acked-by: Michel Dänzer
---
driv
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
This avoids merging them together on page fault.
Signed-off-by: Christian König
Acked-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 16 ---
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
This allows drivers to specify if they need a contiguous allocation or not.
v2: use space instead of tab
Signed-off-by: Christian König
Patches 1-3:
Reviewed-by: Nicolai Hähnle
Patch 4:
Acked-by: Nicolai Hähnle
On 04.04.2017 13:33, Christian König wrote:
Am 03.04.2017 um 18:22 schrieb Nicolai Hähnle:
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS
instead of a placement limit. That allows us to better handle
On 18.04.2017 17:48, Rob Clark wrote:
On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
wrote:
Hi there
I am Raghav Jajodia, an Engineering student from India. While going through
the X.org foundation, I felt that X.org is a great community for new Open
Source developers. I am deeply interested
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall, but I'm separating these two out for a hopefully qui
From: Nicolai Hähnle
This reverts commit 38fc4856ad98f230bc91da0421dec69e4aee40f8, which
introduces a use-after-free.
The underlying bug should be properly fixed with "drm/ttm: never add BO
that failed to validate to the LRU list".
Cc: Samuel Pitoiset
Cc: zhoucm1
Signed-off-b
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of the BO, waits on its reservation lock
Task 1: releases its reference of the BO; never gives up
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO initialization
fails.
Actual deadlocks caused by the missing unlock should have been
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/ttm
On 14.02.2017 11:38, Christian König wrote:
Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Fixes a potential race condition in amdgpu that looks as follows:
Task 1: attempt ttm_bo_init, but ttm_bo_validate fails
Task 1: add BO to global list anyway
Task 2: grabs hold of
From: Nicolai Hähnle
Fix a warning about different types in min() macro in amdgpu:
In file included from ./include/linux/list.h:8:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function
‘amdgpu_bo_create_restricted
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy
On 14.02.2017 13:51, Christian König wrote:
Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO initialization
fails.
Actual deadlocks caused by the missing unlock should have been
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
v2: callers of ttm_bo_init_top should use ttm_bo_unref for
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy
On 15.02.2017 14:35, Nicolai Hähnle wrote:
On 14.02.2017 13:51, Christian König wrote:
Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling
On 16.02.2017 02:00, Michel Dänzer wrote:
On 16/02/17 04:10 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM
From: Nicolai Hähnle
This variant of ttm_bo_init returns the validated buffer object with
the reservation lock held when resv == NULL. This is convenient for
callers that want to use the BO immediately, e.g. for initializing its
contents.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/ttm
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.
Actual deadlocks caused by the missing unlock should have been fixed
by "dr
From: Nicolai Hähnle
The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries
On 09.11.2016 19:08, Emil Velikov wrote:
> From: Emil Velikov
>
> Parsing config sysfs file wakes up the device. The latter of which may
> be slow and isn't required to begin with.
>
> Reading through config is/was required since the revision is not
> available by other means, although with a kern
On 10.11.2016 18:43, Emil Velikov wrote:
> From: Emil Velikov
>
> The original version considered only card devices, while this will pick
> the device/node name regardless - card, control, renderD, other...
>
> Current implementation is "linux" specific, in such that it relies on
> sysfs/uevent fi
From: Nicolai Hähnle
Fix a race condition involving 4 threads and 2 ww_mutexes as indicated in
the following example. Acquire context stamps are ordered like the thread
numbers, i.e. thread #1 should back off when it encounters a mutex locked
by thread #0 etc.
Thread #0Thread #1Thread #
From: Nicolai Hähnle
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/00-INDEX | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/locking/00-INDEX b/Documentation/locking/00-INDEX
From: Nicolai Hähnle
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
include/linux/ww_mutex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 760399a..fd
From: Nicolai Hähnle
When ww_mutex_set_context_slowpath runs, we are in one of two situations:
1. The current task was woken up by ww_mutex_unlock.
2. The current task is racing with ww_mutex_unlock: We entered the slow
path while lock->base.count <= 0, but skipped the wait in
__mutex_lo
On 23.11.2016 15:25, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 03:03:36PM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 23, 2016 at 12:25:22PM +0100, Nicolai Hähnle wrote:
>>> @@ -473,7 +476,14 @@ void __sched ww_mutex_unlock(struct ww_mutex *lock)
>>> */
>>> mutex_clear_owner(&lock->b
On 24.11.2016 12:56, Peter Zijlstra wrote:
> On Thu, Nov 24, 2016 at 12:52:25PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra
>> wrote:
>>>
I do believe we can win a bit by keeping the wait list sorted, if we also
make sure that waiters don't add themse
From: Nicolai Hähnle
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
On 27.03.2017 04:09, Seung-Woo Kim wrote:
In error path of drmGetBusid() and drmGetReservedContextList(),
there are memory leaks for error path. So this removes them.
Signed-off-by: Seung-Woo Kim
Reviewed-by: Nicolai Hähnle
---
xf86drm.c | 18 --
1 files changed, 12
Hi Rob,
On 19.01.2017 23:32, Rob Clark wrote:
Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:
https://www.x.org/wiki/SummerOfCodeIdeas/
There are currently still some stale ideas there (and probably plenty
of missing good ideas).
Also, I'v
I don't think is correct. The incoming handle is in shared_handle, not
in handle. Once the code block around line 310 has executed,
shared_handle is the handle produced by drmPrimeFDToHandle, and closing
it on error (as the code currently does) should be the correct thing to do.
The only possi
On 22.01.2017 19:48, Emil Velikov wrote:
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Nicolai Hähnle
---
amdgpu/amdgpu_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index d30fd1e7..c9f31587 100644
--- a
From: Nicolai Hähnle
Previously, (*device)->businfo.pci would end up misaligned, which results
in undefined behavior.
Signed-off-by: Nicolai Hähnle
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86drm.c b/xf86drm.c
index 5f587d9..94efc08 100644
--- a/xf86
Hi Emil,
On 14.05.2016 18:03, Emil Velikov wrote:
> Hi Nicolai,
>
> On 13 May 2016 at 07:14, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> Previously, (*device)->businfo.pci would end up misaligned, which results
>> in undefined behavior.
>>
> Can you point me to a source where I can rea
Ping.
On 13.05.2016 08:14, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Previously, (*device)->businfo.pci would end up misaligned, which results
> in undefined behavior.
>
> Signed-off-by: Nicolai Hähnle
> ---
> xf86drm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
On 10.06.2016 18:55, Emil Velikov wrote:
> On 10 June 2016 at 15:07, Nicolai Hähnle wrote:
>> Ping.
>>
> Sorry about that, I thought I've already mentioned it:
> Reviewed-by: Emil Velikov
>
> I take it you have commit access ? If not, let me know and I'll push if for
> you.
Thanks, I just push
For the series:
Reviewed-by: Nicolai Hähnle
This patch is also:
Tested-by: Nicolai Hähnle
On 10.06.2016 16:13, Alex Deucher wrote:
> Align to the jump table offset. Fixes hangs on some
> systems with GFX PG enabled.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v
On 21.07.2016 11:07, Jarkko Korpi wrote:
> As the title says.
>
> How to fetch the most recent changes to the hardware? I don't want to
> use 4.7.rc7 but more recent.
Well, 4.7 has now been released. Depending on how adventurous you're
feeling, you can merge in this tree:
https://cgit.freedeskto
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
Fix a bunch of related crashes in amdgpu that occur when shadow page tables
are kicked out of the GART.
One of the issues was that during command submission, we rely on a
device-global evictions counter to skip some of the work of page-table
validation. The driver was never informed of evictions f
From: Nicolai Hähnle
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
---
drivers/gpu/drm
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
non-shadow page tables using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
From: Nicolai Hähnle
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 4306b2f..15a723a 100644
--- a/drivers/g
From: Nicolai Hähnle
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 evi
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm when shadow the page directory is swapped out.
Clean up the check for non-shadow BOs as well using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
non-shadow page tables using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
On 06.12.2016 16:25, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>
>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> struct mutex_waiter waiter;
>> unsigned long flags;
>> bool first
On 06.12.2016 16:36, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> +static inline int __sched
>> +__ww_mutex_add_waiter(struct mutex_waiter *waiter,
>> + struct mutex *lock,
>> + struct ww_acquire_ctx *ww_ctx)
>> +{
>>
Hi Peter and Chris,
(trying to combine the handoff discussion here)
On 06.12.2016 17:55, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>>
On 01.12.2016 16:59, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> debug_mutex_lock_common(lock, &waiter);
>> debug_mutex_add_waiter(lock, &w
On 16.12.2016 18:15, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
>> The concern about picking up a handoff that we didn't request is real,
>> though it cannot happen in the first iteration. Perhaps this __mutex_trylock
>> can be moved to the end of the l
On 16.12.2016 18:20, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
@@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
spin_unlock_mutex(&lock->wait_lock, flags);
sche
On 16.12.2016 21:00, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote:
>> mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin
>> case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the
>> wait_lock.
>
> mutex_optimisti
From: Nicolai Hähnle
As soon as we leave the spinlock after the job has been added to the job
queue, we can no longer rely on the job's data to be available.
I have seen a null-pointer dereference due to sched == NULL in
amd_sched_wakeup via amd_sched_entity_push_job and
amd_sched_ib_submit_ker
On 16.12.2016 03:49, zhoucm1 wrote:
> On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> 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
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
v3: rename to __ww_ctx_stamp_after (Chris Wilson)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
Rev
From: Nicolai Hähnle
There's a possible race where the waiter in front of us leaves the wait list
due to a signal, and the current owner subsequently hands the lock off to us
even though we never observed ourselves at the front of the list.
Set the task state before checking our position in the
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
Keep the documentation in the header file since there is no good
place for it in mutex.c: there are two rather different
implementations with different EXPORT_SYMBOLs for each function.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
1 - 100 of 126 matches
Mail list logo
