x_order = min(max_order, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the intention when that API
> was added but can leave that for the future.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Pushed, I imagine this has been added to the list of sg cleanups you
have :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
order, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the intention when that API
> was added but can leave that for the future.
>
> Reviewed-by: Tvrtko Ursulin
Pushed, I imagine this has been added to the list of sg cleanups you
have :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross <jgr...@suse.com>
> Fixes: 920cf4194954 ("drm/i915: Int
t_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross
> Fixes: 920cf4194954 ("drm/i915: Introduce an internal allo
On Wed, Feb 01, 2017 at 11:24:32AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2017 at 11:19:32AM +0000, Chris Wilson wrote:
> > On a non-llc system, the objects are created with .cache_level =
> > CACHE_NONE and so the transition to uncached for scanout is a no-op.
> > H
On Wed, Feb 01, 2017 at 11:24:32AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2017 at 11:19:32AM +0000, Chris Wilson wrote:
> > On a non-llc system, the objects are created with .cache_level =
> > CACHE_NONE and so the transition to uncached for scanout is a no-op.
> > H
98a7 ("drm/i915: add tracepoints for flip requests &
> completions")
> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com>
That's old, and indeed does seem to be present from that commit and not
exposed by something later.
Cc: <sta...@vger.kernel.org> # v2.6.36+
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
98a7 ("drm/i915: add tracepoints for flip requests &
> completions")
> Signed-off-by: Andrey Ryabinin
That's old, and indeed does seem to be present from that commit and not
exposed by something later.
Cc: # v2.6.36+
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Mark when we run the execlist tasklet following the interrupt, so we
don't probe a potentially uninitialised register when submitting the
contexts multiple times before the hardware responds.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_irq.c
Mark when we run the execlist tasklet following the interrupt, so we
don't probe a potentially uninitialised register when submitting the
contexts multiple times before the hardware responds.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 7 +--
drivers/gpu/drm
-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Jens Axboe <ax...@kernel.dk>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Chen Fan <chen.fan.f...@cn.fujitsu.com>
Cc: Alexander Potapenko &l
-by: Chris Wilson
Cc: Thomas Gleixner
Cc: Jens Axboe
Cc: Hannes Reinecke
Cc: Bjorn Helgaas
Cc: Chen Fan
Cc: Alexander Potapenko
---
include/linux/interrupt.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index
On Fri, Jan 20, 2017 at 10:36:55PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang <geliangt...@gmail.com>
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Jan 20, 2017 at 10:36:55PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
use case, just that on intel, the more prevalent users do not
hit this path - though they will with the ww_mutex refactoring work. ttm
drivers (amdgpu, nouveau etc) will be demonstrating that this is the
unlikely branch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
use case, just that on intel, the more prevalent users do not
hit this path - though they will with the ww_mutex refactoring work. ttm
drivers (amdgpu, nouveau etc) will be demonstrating that this is the
unlikely branch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Jan 18, 2017 at 01:35:33PM +0200, Ander Conselvan De Oliveira wrote:
> On Sun, 2017-01-15 at 12:58 +0000, Chris Wilson wrote:
> > intel_display_resume() may be called without a atomic state to restore,
> > i.e. dev_priv->modeset_reset_restore state is NULL. One such cas
On Wed, Jan 18, 2017 at 01:35:33PM +0200, Ander Conselvan De Oliveira wrote:
> On Sun, 2017-01-15 at 12:58 +0000, Chris Wilson wrote:
> > intel_display_resume() may be called without a atomic state to restore,
> > i.e. dev_priv->modeset_reset_restore state is NULL. One such cas
gt;
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: <drm-intel-fi...@lists.freedesktop.org> # v4.10-rc1
eference counting to drm_atomic_state")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: # v4.10-rc1+
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/in
Commit-ID: d1b42b800e5d09dcee52812b4396aca3a3696ba9
Gitweb: http://git.kernel.org/tip/d1b42b800e5d09dcee52812b4396aca3a3696ba9
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:09 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: 2b0b211134a65401ed874ce0d5d48844f4f6f341
Gitweb: http://git.kernel.org/tip/2b0b211134a65401ed874ce0d5d48844f4f6f341
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:11 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: d1b42b800e5d09dcee52812b4396aca3a3696ba9
Gitweb: http://git.kernel.org/tip/d1b42b800e5d09dcee52812b4396aca3a3696ba9
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:09 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:16 +0100
locking/ww_mutex: Add
Commit-ID: 2b0b211134a65401ed874ce0d5d48844f4f6f341
Gitweb: http://git.kernel.org/tip/2b0b211134a65401ed874ce0d5d48844f4f6f341
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:11 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:17 +0100
locking/ww_mutex: Add
Commit-ID: 2a0c11282881875dc44f166a20eedf0d866dd0ef
Gitweb: http://git.kernel.org/tip/2a0c11282881875dc44f166a20eedf0d866dd0ef
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:10 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: 2a0c11282881875dc44f166a20eedf0d866dd0ef
Gitweb: http://git.kernel.org/tip/2a0c11282881875dc44f166a20eedf0d866dd0ef
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:10 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:17 +0100
locking/ww_mutex: Add
Commit-ID: c22fb3807fd0a3bdd98c13c4d2190ab064e6c09d
Gitweb: http://git.kernel.org/tip/c22fb3807fd0a3bdd98c13c4d2190ab064e6c09d
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:07 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: c22fb3807fd0a3bdd98c13c4d2190ab064e6c09d
Gitweb: http://git.kernel.org/tip/c22fb3807fd0a3bdd98c13c4d2190ab064e6c09d
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:07 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:15 +0100
locking/ww_mutex: Add
Commit-ID: 70207686e492fb97c11d88ae7d8ebce7d2d080aa
Gitweb: http://git.kernel.org/tip/70207686e492fb97c11d88ae7d8ebce7d2d080aa
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:08 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: 70207686e492fb97c11d88ae7d8ebce7d2d080aa
Gitweb: http://git.kernel.org/tip/70207686e492fb97c11d88ae7d8ebce7d2d080aa
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:08 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:16 +0100
locking/ww_mutex: Add
Commit-ID: 0186a6cbdc6287fde65858e5d9c714dc167b8ace
Gitweb: http://git.kernel.org/tip/0186a6cbdc6287fde65858e5d9c714dc167b8ace
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:05 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: f2a5fec17395f259d54daa8833d81b00cceb15c3
Gitweb: http://git.kernel.org/tip/f2a5fec17395f259d54daa8833d81b00cceb15c3
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:06 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: 0186a6cbdc6287fde65858e5d9c714dc167b8ace
Gitweb: http://git.kernel.org/tip/0186a6cbdc6287fde65858e5d9c714dc167b8ace
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:05 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:14 +0100
locking/ww_mutex: Add
Commit-ID: f2a5fec17395f259d54daa8833d81b00cceb15c3
Gitweb: http://git.kernel.org/tip/f2a5fec17395f259d54daa8833d81b00cceb15c3
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:06 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:14 +0100
locking/ww_mutex: Begin
Commit-ID: af2e859edd477fa1ea3d1d106f41a595cff3d162
Gitweb: http://git.kernel.org/tip/af2e859edd477fa1ea3d1d106f41a595cff3d162
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Thu, 1 Dec 2016 11:47:04 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: af2e859edd477fa1ea3d1d106f41a595cff3d162
Gitweb: http://git.kernel.org/tip/af2e859edd477fa1ea3d1d106f41a595cff3d162
Author: Chris Wilson
AuthorDate: Thu, 1 Dec 2016 11:47:04 +
Committer: Ingo Molnar
CommitDate: Sat, 14 Jan 2017 11:37:13 +0100
locking/ww_mutex: Fix
On Thu, Jan 12, 2017 at 04:24:50PM -0600, l...@pengaru.com wrote:
> On Thu, Jan 12, 2017 at 09:17:06PM +0000, Chris Wilson wrote:
> > On Mon, Jan 09, 2017 at 11:19:32AM +0000, Chris Wilson wrote:
> > > On a non-llc system, the objects are created with .cache_level =
>
On Thu, Jan 12, 2017 at 04:24:50PM -0600, l...@pengaru.com wrote:
> On Thu, Jan 12, 2017 at 09:17:06PM +0000, Chris Wilson wrote:
> > On Mon, Jan 09, 2017 at 11:19:32AM +0000, Chris Wilson wrote:
> > > On a non-llc system, the objects are created with .cache_level =
>
On Mon, Jan 09, 2017 at 11:19:32AM +, Chris Wilson wrote:
> On a non-llc system, the objects are created with .cache_level =
> CACHE_NONE and so the transition to uncached for scanout is a no-op.
> However, if the object was never written to, it will still be in the CPU
> domain
On Mon, Jan 09, 2017 at 11:19:32AM +, Chris Wilson wrote:
> On a non-llc system, the objects are created with .cache_level =
> CACHE_NONE and so the transition to uncached for scanout is a no-op.
> However, if the object was never written to, it will still be in the CPU
> domain
On Wed, Jan 11, 2017 at 04:57:32PM +, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:43:02PM +0100, Peter Zijlstra wrote:
> > FWIW, I have the below patch that should also solve this problem afaict.
>
> Thanks, I shall see if makes my machines happy.
I have had a few machin
On Wed, Jan 11, 2017 at 04:57:32PM +, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:43:02PM +0100, Peter Zijlstra wrote:
> > FWIW, I have the below patch that should also solve this problem afaict.
>
> Thanks, I shall see if makes my machines happy.
I have had a few machin
On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> On 11/01/17 18:08, Chris Wilson wrote:
> > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> >> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> >>
> >> [ 49.213697]
On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> On 11/01/17 18:08, Chris Wilson wrote:
> > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> >> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> >>
> >> [ 49.213697]
Is this a new bug? Bisection would be the fastest way to triage it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Is this a new bug? Bisection would be the fastest way to triage it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Jan 11, 2017 at 05:43:02PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 09, 2017 at 11:52:03AM +0000, Chris Wilson wrote:
> > If we abort the mutex_lock() due to an interrupt, or other error from
>
> s/interrupt/signal/, right?
Yes. EINTR is ingrained.
> > ww_mutex,
On Wed, Jan 11, 2017 at 05:43:02PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 09, 2017 at 11:52:03AM +0000, Chris Wilson wrote:
> > If we abort the mutex_lock() due to an interrupt, or other error from
>
> s/interrupt/signal/, right?
Yes. EINTR is ingrained.
> > ww_mutex,
gt; It doesn't apply to mainline, with or without the substitution you suggest.
I was hoping that the locking was the real cause here and would be an
easy fix to apply. I did have a look at trying to reorder the DP-MST
worker with driver registration. Hacky to say the least.
-Chris
--
Chris Wilson,
mainline, with or without the substitution you suggest.
I was hoping that the locking was the real cause here and would be an
easy fix to apply. I did have a look at trying to reorder the DP-MST
worker with driver registration. Hacky to say the least.
-Chris
--
Chris Wilson, Intel Open Source Techno
is already claimed (and since the owner unlocked there
may never be a new wakeup).
Fixes: 9d659ae14b54 ("locking/mutex: Add lock handoff to avoid starvation")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Waiman Long &l
is already claimed (and since the owner unlocked there
may never be a new wakeup).
Fixes: 9d659ae14b54 ("locking/mutex: Add lock handoff to avoid starvation")
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
ffset_map_lock(mm, pmd, address, ptlp))
#define pte_alloc_kernel(pmd, address) \
- ((unlikely(pmd_none(*(pmd))) && __pte_alloc_kernel(pmd, address))? \
+ ((unlikely(pmd_none(*(pmd)) || pmd_clear_huge(pmd)) &&
__pte_alloc_kernel(pmd, address))? \
NULL: pte_offset_kernel(pmd, address))
#if USE_SPLIT_PMD_PTLOCKS
--
Chris Wilson, Intel Open Source Technology Centre
kely(pmd_none(*(pmd))) && __pte_alloc_kernel(pmd, address))? \
+ ((unlikely(pmd_none(*(pmd)) || pmd_clear_huge(pmd)) &&
__pte_alloc_kernel(pmd, address))? \
NULL: pte_offset_kernel(pmd, address))
#if USE_SPLIT_PMD_PTLOCKS
--
Chris Wilson, Intel Open Source Technology Centre
to display.
Reported-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
the scanout")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: <drm-intel-fi...@lists.freedesktop.org> # v4.10-rc1+
---
drivers/gpu/drm/i915/i915_gem.c | 2
to display.
Reported-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
the scanout")
Signed-off-by: Chris Wilson
Cc: # v4.10-rc1+
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gp
On Mon, Jan 09, 2017 at 10:24:01AM +, Chris Wilson wrote:
> On a non-llc system, the objects are created with .cache_level =
> CACHE_NONE and so the transition to uncached for scanout is a no-op.
> However, if the object was never written to, it will still be in the CPU
> domain
On Mon, Jan 09, 2017 at 10:24:01AM +, Chris Wilson wrote:
> On a non-llc system, the objects are created with .cache_level =
> CACHE_NONE and so the transition to uncached for scanout is a no-op.
> However, if the object was never written to, it will still be in the CPU
> domain
to display.
Reported-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
the scanout")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: <drm-intel-fi...@lists.freedesktop.org> # v4.10-rc1+
---
drivers/gpu/drm/i915/i915_gem.c |
to display.
Reported-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning
the scanout")
Signed-off-by: Chris Wilson
Cc: # v4.10-rc1+
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
On Wed, Jan 04, 2017 at 04:40:49PM +0100, Luis R. Rodriguez wrote:
> On Wed, Jan 04, 2017 at 07:12:11PM +0800, Ming Lei wrote:
> > On Wed, Jan 4, 2017 at 5:31 PM, Chris Wilson <ch...@chris-wilson.co.uk>
> > wrote:
> > > If the firmware load is slow and cancel
On Wed, Jan 04, 2017 at 04:40:49PM +0100, Luis R. Rodriguez wrote:
> On Wed, Jan 04, 2017 at 07:12:11PM +0800, Ming Lei wrote:
> > On Wed, Jan 4, 2017 at 5:31 PM, Chris Wilson
> > wrote:
> > > If the firmware load is slow and cancelled, we may call fw_load_abort()
>
If the firmware load is slow and cancelled, we may call fw_load_abort()
twice and promptly oops on the second with a NULL dereference.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ming Lei <ming@canonical.com>
Cc: "Luis R. Rodriguez" <mcg...@kernel.or
If the firmware load is slow and cancelled, we may call fw_load_abort()
twice and promptly oops on the second with a NULL dereference.
Signed-off-by: Chris Wilson
Cc: Ming Lei
Cc: "Luis R. Rodriguez"
Cc: Greg Kroah-Hartman
---
drivers/base/firmware_class.c | 3 +++
1 file
goto err;
}
Though I expect you will be able to find a better solution.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
goto err;
}
Though I expect you will be able to find a better solution.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
12:
> 0008
> [ 29.003947] R13: 00f5 R14: R15:
> 00000000
This should be independent of suspend/resume and should be fixed with
https://patchwork.freedesktop.org/patch/116373/
commit ebc0808fa2da0548a78e715858024cb81cd732bc
Author: Chris Wilson <ch
12:
> 0008
> [ 29.003947] R13: 00f5 R14: R15:
> 00000000
This should be independent of suspend/resume and should be fixed with
https://patchwork.freedesktop.org/patch/116373/
commit ebc0808fa2da0548a78e715858024cb81cd732bc
Author: Chris Wilson
D
ference exception is raised. We need to check execlist_port status
> first.
No. The root cause is whatever got you into the illegal condition in the
first place.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
raised. We need to check execlist_port status
> first.
No. The root cause is whatever got you into the illegal condition in the
first place.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
attached patch should prevent an early ENOMEM following the swiotlb
allocation failure. But I suspect that we will still be tripping up the
failure in the sg walker when binding to the GPU.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>From e3f9268d467768a31e19d21e2f45e5c9ddd9a0f8
attached patch should prevent an early ENOMEM following the swiotlb
allocation failure. But I suspect that we will still be tripping up the
failure in the sg walker when binding to the GPU.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>From e3f9268d467768a31e19d21e2f45e5c9ddd9a0f8
On Mon, Dec 19, 2016 at 10:40:41AM +0900, Inki Dae wrote:
>
>
> 2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> > On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> >> Rendering operations to the dma-buf are tracked implicitly via the
> >>
On Mon, Dec 19, 2016 at 10:40:41AM +0900, Inki Dae wrote:
>
>
> 2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> > On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> >> Rendering operations to the dma-buf are tracked implicitly via the
> >>
t.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
error paths you do not modify user inputs. In
particular, consider EINTR where the usual pattern (e.g. drmIoctl) is
do {
err = ioctl(fd, SUBMIT, arg);
} while (err == -EINTR);
If you modify the in fence before you consume it, you can't recreate it
after handling the signal.
n
particular, consider EINTR where the usual pattern (e.g. drmIoctl) is
do {
err = ioctl(fd, SUBMIT, arg);
} while (err == -EINTR);
If you modify the in fence before you consume it, you can't recreate it
after handling the signal.
-Chris
--
Chris Wilson, Intel
If might_lock() is called on a mutex, it may also potentially sleep.
Call might_sleep() in this case so that the caller is checked for both.
This is similar to the might_sleep() that is checked by the real
mutex_lock().
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zi
If might_lock() is called on a mutex, it may also potentially sleep.
Call might_sleep() in this case so that the caller is checked for both.
This is similar to the might_sleep() that is checked by the real
mutex_lock().
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
As kref_put_mutex() may take the mutex (on the final unreference), mark
it up with might_lock() so that the caller is unconditionally checked by
lockdep.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
---
include/linux/kref.h |
As kref_put_mutex() may take the mutex (on the final unreference), mark
it up with might_lock() so that the caller is unconditionally checked by
lockdep.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
---
include/linux/kref.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux
ry required). Copying a selected set of aux bo is
one option. And since those bo are under user control and do not have to
be executed, you can even store aub data in them or whatnot.
Even if you make attaching the debug information conditional, I would
still keep the error message unconditional.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
lected set of aux bo is
one option. And since those bo are under user control and do not have to
be executed, you can even store aub data in them or whatnot.
Even if you make attaching the debug information conditional, I would
still keep the error message unconditional.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ain, if
> + * our position at the head was temporarily taken away.
Comment makes sense.
Ah. Should this be just if (use_ww_ctx) { /* always recheck... */ ?
Except that !ww_ctx are never gazzumped in the list, so if they are
first, then they are always first.
Could you exp
ain, if
> + * our position at the head was temporarily taken away.
Comment makes sense.
Ah. Should this be just if (use_ww_ctx) { /* always recheck... */ ?
Except that !ww_ctx are never gazzumped in the list, so if they are
first, then they are always first.
Could you exp
Maarten Lankhorst <d...@mblankhorst.nl>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com>
> ---
> kernel/locking/mutex.c |
On Thu, Dec 01, 2016 at 03:06:46PM +0100, Nicolai Hähnle wrote:
> 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: d
can_spin_on_owner() as well. Is it
worth for a contending ww_mutex to enter the osq queue if we expect a
EDEADLK? It seems to boil down to how likely is the EDEADLK going to
evaporate if we wait for the owner to finish and unlock.
The patch looks reasonable, just a question of desirability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
h for a contending ww_mutex to enter the osq queue if we expect a
EDEADLK? It seems to boil down to how likely is the EDEADLK going to
evaporate if we wait for the owner to finish and unlock.
The patch looks reasonable, just a question of desirability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
@redhat.com>
> Cc: Maarten Lankhorst <d...@mblankhorst.nl>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com>
Reviewed-by: Ch
On Thu, Dec 01, 2016 at 03:06:44PM +0100, Nicolai Hähnle wrote:
> 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
&g
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.com>
---
kerne
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 98 ++
1 file changed, 98 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test
v2: Add a couple more variations for degenerate ww_mutex, decrease
timeouts
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hä
Nicolai Hähnle was looking into a deadlock within ww_mutexes (that has
been fixed by Peter's mutex rewrite) and to support his changes, I
thought it was be useful to have a small validation suite for ww_mutex.
-Chris
Although ww_mutexes degenerate into mutexes, it would be useful to
torture the deadlock handling between multiple ww_mutexes in addition to
torturing the regular mutexes.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ing
710 ("mutex: Move ww_mutex definitions to ww_mutex.h")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankho...@canonical.com>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: Ingo Molnar <mi...@redhat.com>
---
include/linux/ww_mu
v2: Use both inorder and reorder locking strategies
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Maarten Lankhorst <d...@mblankhorst.nl>
Cc: Nicolai Hähnle <nhaeh...@gmail.co
Add the minimal test running (modprobe test-ww_mutex) to the kselftests
CI framework.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Shuah Khan <sh...@kernel.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
---
tools/t
501 - 600 of 1356 matches
Mail list logo
