* [PATCH] drm/i915: Add a tracepoint for using a semaphore
@ 2013-08-26 12:46 Chris Wilson
2013-08-26 13:20 ` Ville Syrjälä
0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 12:46 UTC (permalink / raw)
To: intel-gfx
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 85537d1..0122278 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (ret)
return ret;
+ trace_i915_gem_object_sync(obj, to);
+
ret = to->sync_to(to, from, seqno);
if (!ret)
/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index feaacbb..728c43b 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -33,6 +33,25 @@ TRACE_EVENT(i915_gem_object_create,
TP_printk("obj=%p, size=%u", __entry->obj, __entry->size)
);
+TRACE_EVENT(i915_gem_object_sync,
+ TP_PROTO(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to),
+ TP_ARGS(obj, to),
+
+ TP_STRUCT__entry(
+ __field(struct drm_i915_gem_object *, obj)
+ __field(u32, sync_from)
+ __field(u32, sync_to)
+ ),
+
+ TP_fast_assign(
+ __entry->obj = obj;
+ __entry->sync_from = obj->ring->id;
+ __entry->sync_to = to->id;
+ ),
+
+ TP_printk("obj=%p, sync-from=%u, sync-to=%u", __entry->obj, __entry->sync_from, __entry->sync_to)
+);
+
TRACE_EVENT(i915_vma_bind,
TP_PROTO(struct i915_vma *vma, bool mappable),
TP_ARGS(vma, mappable),
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
2013-08-26 12:46 [PATCH] drm/i915: Add a tracepoint for using a semaphore Chris Wilson
@ 2013-08-26 13:20 ` Ville Syrjälä
2013-08-26 13:30 ` Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2013-08-26 13:20 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to detect with a mere tracepoint!
I was staring at the semaphore code a bit recently, and I was wondering
if it would make sense to do a manual seqno check (against the ring's
current seqno, not just the last sync_seqno) before we decide to
add the semaphore into the ring?
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 85537d1..0122278 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> + trace_i915_gem_object_sync(obj, to);
> +
> ret = to->sync_to(to, from, seqno);
> if (!ret)
> /* We use last_read_seqno because sync_to()
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index feaacbb..728c43b 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -33,6 +33,25 @@ TRACE_EVENT(i915_gem_object_create,
> TP_printk("obj=%p, size=%u", __entry->obj, __entry->size)
> );
>
> +TRACE_EVENT(i915_gem_object_sync,
> + TP_PROTO(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to),
> + TP_ARGS(obj, to),
> +
> + TP_STRUCT__entry(
> + __field(struct drm_i915_gem_object *, obj)
> + __field(u32, sync_from)
> + __field(u32, sync_to)
> + ),
> +
> + TP_fast_assign(
> + __entry->obj = obj;
> + __entry->sync_from = obj->ring->id;
> + __entry->sync_to = to->id;
> + ),
> +
> + TP_printk("obj=%p, sync-from=%u, sync-to=%u", __entry->obj, __entry->sync_from, __entry->sync_to)
> +);
> +
> TRACE_EVENT(i915_vma_bind,
> TP_PROTO(struct i915_vma *vma, bool mappable),
> TP_ARGS(vma, mappable),
> --
> 1.8.4.rc3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
2013-08-26 13:20 ` Ville Syrjälä
@ 2013-08-26 13:30 ` Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 13:30 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Mon, Aug 26, 2013 at 04:20:06PM +0300, Ville Syrjälä wrote:
> On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and prevent any concurrent work. That, however, is a little
> > tricker to detect with a mere tracepoint!
>
> I was staring at the semaphore code a bit recently, and I was wondering
> if it would make sense to do a manual seqno check (against the ring's
> current seqno, not just the last sync_seqno) before we decide to
> add the semaphore into the ring?
If we use the cheap check, yeah. We can also store the cross-sync seqno
as well. Both are going to be unlikely paths though.
Anyway, I'm moving the tracepoint over to the ring rather than the
object for consistency.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] drm/i915: Add a tracepoint for using a semaphore
@ 2013-08-26 13:34 Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 13:34 UTC (permalink / raw)
To: intel-gfx
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a ring event, rather than an object event.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 85537d1..a9a6baa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (ret)
return ret;
+ trace_i915_gem_ring_sync_to(from, to);
+
ret = to->sync_to(to, from, seqno);
if (!ret)
/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index feaacbb..163774a 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -235,6 +235,25 @@ TRACE_EVENT(i915_gem_evict_everything,
TP_printk("dev=%d", __entry->dev)
);
+TRACE_EVENT(i915_gem_ring_sync_to,
+ TP_PROTO(struct intel_ring_buffer *from, struct intel_ring_buffer *to),
+ TP_ARGS(from, to),
+
+ TP_STRUCT__entry(
+ __field(u32, dev)
+ __field(u32, sync_from)
+ __field(u32, sync_to)
+ ),
+
+ TP_fast_assign(
+ __entry->dev = from->dev->primary->index;
+ __entry->sync_from = from->id;
+ __entry->sync_to = to->id;
+ ),
+
+ TP_printk("dev=%u, sync-from=%u, sync-to=%u", __entry->dev, __entry->sync_from, __entry->sync_to)
+);
+
TRACE_EVENT(i915_gem_ring_dispatch,
TP_PROTO(struct intel_ring_buffer *ring, u32 flags),
TP_ARGS(ring, flags),
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 09/13] drm/i915: Add a tracepoint for using a semaphore
@ 2013-09-25 10:11 Daniel Vetter
2013-09-25 10:43 ` [PATCH] " Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Vetter @ 2013-09-25 10:11 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Wed, Sep 25, 2013 at 12:34:37PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 23, 2013 at 05:33:26PM -0300, Rodrigo Vivi wrote:
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> >
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and prevent any concurrent work. That, however, is a little
> > tricker to detect with a mere tracepoint!
> >
> > v2: Rebrand it as a ring event, rather than an object event.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
>
> Just wondering if we would want to see the seqno(s) in the trace as well?
Hm yeah, I guess the seqno we're syncing on the from ring would be useful
to gauge how much parallelism there really is. Chris, care to respin?
-Daniel
>
> But anyway, the patch looks fine.
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 2 ++
> > drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index d68cc5c..4a16491 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2614,6 +2614,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
> > if (ret)
> > return ret;
> >
> > + trace_i915_gem_ring_sync_to(from, to);
> > +
> > ret = to->sync_to(to, from, seqno);
> > if (!ret)
> > /* We use last_read_seqno because sync_to()
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> > index 5c8e36a..48e8f07 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -233,6 +233,25 @@ TRACE_EVENT(i915_gem_evict_everything,
> > TP_printk("dev=%d", __entry->dev)
> > );
> >
> > +TRACE_EVENT(i915_gem_ring_sync_to,
> > + TP_PROTO(struct intel_ring_buffer *from, struct intel_ring_buffer *to),
> > + TP_ARGS(from, to),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, dev)
> > + __field(u32, sync_from)
> > + __field(u32, sync_to)
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->dev = from->dev->primary->index;
> > + __entry->sync_from = from->id;
> > + __entry->sync_to = to->id;
> > + ),
> > +
> > + TP_printk("dev=%u, sync-from=%u, sync-to=%u", __entry->dev, __entry->sync_from, __entry->sync_to)
> > +);
> > +
> > TRACE_EVENT(i915_gem_ring_dispatch,
> > TP_PROTO(struct intel_ring_buffer *ring, u32 flags),
> > TP_ARGS(ring, flags),
> > --
> > 1.8.1.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH] drm/i915: Add a tracepoint for using a semaphore
2013-09-25 10:11 [PATCH 09/13] " Daniel Vetter
@ 2013-09-25 10:43 ` Chris Wilson
2013-09-25 11:29 ` Ville Syrjälä
0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2013-09-25 10:43 UTC (permalink / raw)
To: intel-gfx
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a ring event, rather than an object event.
v3: Include the seqno in the tracepoint for posterity or something.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 82bc029..fa3b373 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (ret)
return ret;
+ trace_i915_gem_ring_sync_to(from, to, seqno);
ret = to->sync_to(to, from, seqno);
if (!ret)
/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index daa6fdf..6e580c9 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -248,6 +248,32 @@ TRACE_EVENT(i915_gem_evict_vm,
TP_printk("dev=%d, vm=%p", __entry->vm->dev->primary->index, __entry->vm)
);
+TRACE_EVENT(i915_gem_ring_sync_to,
+ TP_PROTO(struct intel_ring_buffer *from,
+ struct intel_ring_buffer *to,
+ u32 seqno),
+ TP_ARGS(from, to, seqno),
+
+ TP_STRUCT__entry(
+ __field(u32, dev)
+ __field(u32, sync_from)
+ __field(u32, sync_to)
+ __field(u32, seqno)
+ ),
+
+ TP_fast_assign(
+ __entry->dev = from->dev->primary->index;
+ __entry->sync_from = from->id;
+ __entry->sync_to = to->id;
+ __entry->seqno = seqno;
+ ),
+
+ TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
+ __entry->dev,
+ __entry->sync_from, __entry->sync_to,
+ __entry->seqno)
+);
+
TRACE_EVENT(i915_gem_ring_dispatch,
TP_PROTO(struct intel_ring_buffer *ring, u32 seqno, u32 flags),
TP_ARGS(ring, seqno, flags),
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
2013-09-25 10:43 ` [PATCH] " Chris Wilson
@ 2013-09-25 11:29 ` Ville Syrjälä
2013-09-25 11:31 ` Daniel Vetter
0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2013-09-25 11:29 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to detect with a mere tracepoint!
>
> v2: Rebrand it as a ring event, rather than an object event.
> v3: Include the seqno in the tracepoint for posterity or something.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 1 +
> drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 82bc029..fa3b373 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> + trace_i915_gem_ring_sync_to(from, to, seqno);
> ret = to->sync_to(to, from, seqno);
Passing the rings in the same order to both might avoid some confusion,
but I don't care enough to withhold my r-b so:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> if (!ret)
> /* We use last_read_seqno because sync_to()
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index daa6fdf..6e580c9 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -248,6 +248,32 @@ TRACE_EVENT(i915_gem_evict_vm,
> TP_printk("dev=%d, vm=%p", __entry->vm->dev->primary->index, __entry->vm)
> );
>
> +TRACE_EVENT(i915_gem_ring_sync_to,
> + TP_PROTO(struct intel_ring_buffer *from,
> + struct intel_ring_buffer *to,
> + u32 seqno),
> + TP_ARGS(from, to, seqno),
> +
> + TP_STRUCT__entry(
> + __field(u32, dev)
> + __field(u32, sync_from)
> + __field(u32, sync_to)
> + __field(u32, seqno)
> + ),
> +
> + TP_fast_assign(
> + __entry->dev = from->dev->primary->index;
> + __entry->sync_from = from->id;
> + __entry->sync_to = to->id;
> + __entry->seqno = seqno;
> + ),
> +
> + TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
> + __entry->dev,
> + __entry->sync_from, __entry->sync_to,
> + __entry->seqno)
> +);
> +
> TRACE_EVENT(i915_gem_ring_dispatch,
> TP_PROTO(struct intel_ring_buffer *ring, u32 seqno, u32 flags),
> TP_ARGS(ring, seqno, flags),
> --
> 1.8.4.rc3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
2013-09-25 11:29 ` Ville Syrjälä
@ 2013-09-25 11:31 ` Daniel Vetter
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Vetter @ 2013-09-25 11:31 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Wed, Sep 25, 2013 at 02:29:34PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and prevent any concurrent work. That, however, is a little
> > tricker to detect with a mere tracepoint!
> >
> > v2: Rebrand it as a ring event, rather than an object event.
> > v3: Include the seqno in the tracepoint for posterity or something.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 1 +
> > drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index 82bc029..fa3b373 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
> > if (ret)
> > return ret;
> >
> > + trace_i915_gem_ring_sync_to(from, to, seqno);
> > ret = to->sync_to(to, from, seqno);
>
> Passing the rings in the same order to both might avoid some confusion,
> but I don't care enough to withhold my r-b so:
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-09-25 11:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-26 12:46 [PATCH] drm/i915: Add a tracepoint for using a semaphore Chris Wilson
2013-08-26 13:20 ` Ville Syrjälä
2013-08-26 13:30 ` Chris Wilson
-- strict thread matches above, loose matches on Subject: below --
2013-08-26 13:34 Chris Wilson
2013-09-25 10:11 [PATCH 09/13] " Daniel Vetter
2013-09-25 10:43 ` [PATCH] " Chris Wilson
2013-09-25 11:29 ` Ville Syrjälä
2013-09-25 11:31 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox