public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/9] drm/i915: add fences to the request struct
Date: Fri, 09 Oct 2015 14:29:28 +0100	[thread overview]
Message-ID: <1444397368.92154.69.camel@infradead.org> (raw)
In-Reply-To: <1441385943-11508-8-git-send-email-jbarnes@virtuousgeek.org>


[-- Attachment #1.1: Type: text/plain, Size: 3475 bytes --]

On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
> 
> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
>         /** Execlists no. of times this request has been sent to the ELSP */
>         int elsp_submitted;
>  
> +       /* core fence obj for this request, may be exported */
> +       struct fence fence;

As discussed, this doesn't work as-is. The final fence_put() will
attempt to free(&req->fence). Unless you have a .release method in your
fence ops, which you don't.

I suppose we could tie up a .release method with the existing release
method for the drm_i915_gem_request.

As things stand, though, bad things are happening. This makes it go
away and at least lets me get on with testing.

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8ef19e2..2d0c93c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2297,7 +2298,7 @@ struct drm_i915_gem_request {
 	int elsp_submitted;
 
 	/* core fence obj for this request, may be exported */
-	struct fence fence;
+	struct fence *fence;
 
 	wait_queue_t wait;
 };
diff --git a/drivers/gpu/drm/i915/i915_sync.c b/drivers/gpu/drm/i915/i915_sync.c
index 085f1f9..6ffe273 100644
--- a/drivers/gpu/drm/i915/i915_sync.c
+++ b/drivers/gpu/drm/i915/i915_sync.c
@@ -58,7 +58,12 @@ struct i915_sync_timeline {
  *   allow non-RCS fences (need ring/context association)
  */
 
-#define to_i915_request(x) container_of(x, struct drm_i915_gem_request, fence)
+struct foo {
+	struct fence fence;
+	struct drm_i915_gem_request *req;
+};
+
+#define to_i915_request(x) (((struct foo *)(x))->req)
 
 static const char *i915_fence_get_driver_name(struct fence *fence)
 {
@@ -81,10 +86,10 @@ static int i915_fence_ring_check(wait_queue_t *wait, unsigned mode, int flags,
 	if (!i915_gem_request_completed(req, false))
 		return 0;
 
-	fence_signal_locked(&req->fence);
+	fence_signal_locked(req->fence);
 
 	__remove_wait_queue(&ring->irq_queue, wait);
-	fence_put(&req->fence);
+	fence_put(req->fence);
 	ring->irq_put(ring);
 
 	return 0;
@@ -200,6 +205,15 @@ struct fence *i915_fence_create_ring(struct intel_engine_cs *ring,
 	if (ret)
 		return ERR_PTR(ret);
 
+	request->fence = kmalloc(sizeof(struct foo), GFP_KERNEL);
+	if (!request->fence) {
+		ret = -ENOMEM;
+		goto err_cancel;
+	}
+	/* I have no clue how this is *supposed* to work and no real interest
+	   in finding out. Just stop hurting me please. */
+	((struct foo *)request->fence)->req = request;
+
 	if (i915.enable_execlists) {
 		ringbuf = ctx->engine[ring->id].ringbuf;
 	} else
@@ -270,10 +284,10 @@ struct fence *i915_fence_create_ring(struct intel_engine_cs *ring,
 			   round_jiffies_up_relative(HZ));
 	intel_mark_busy(dev_priv->dev);
 
-	fence_init(&request->fence, &i915_fence_ring_ops, &fence_lock,
+	fence_init(request->fence, &i915_fence_ring_ops, &fence_lock,
 		   ctx->user_handle, request->seqno);
 
-	return &request->fence;
+	return request->fence;
 
 err_cancel:
 	i915_gem_request_cancel(request);
@@ -306,10 +320,10 @@ static struct fence *i915_fence_create_display(struct intel_context *ctx)
 
 	req = ring->outstanding_lazy_request;
 
-	fence_init(&req->fence, &i915_fence_ops, &fence_lock,
+	fence_init(req->fence, &i915_fence_ops, &fence_lock,
 		   ctx->user_handle, req->seqno);
 
-	return &req->fence;
+	return req->fence;
 }
 #endif
 
-- 
dwmw2


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-10-09 13:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 16:58 [RFC] Page table sharing and bufferless execbuf Jesse Barnes
2015-09-04 16:58 ` [PATCH 1/9] mm: move mmu_find_ops to mmu_notifier.c Jesse Barnes
2015-09-04 16:58 ` [PATCH 2/9] signal: export force_sig_info Jesse Barnes
2015-09-04 16:58 ` [PATCH 3/9] android/sync: add sync_fence_create_dma Jesse Barnes
2015-09-04 16:58 ` [PATCH 4/9] android/sync: hack: enable fence signaling in Android Native Sync implementation Jesse Barnes
2015-09-04 16:58 ` [PATCH 5/9] drm/i915: add create_context2 ioctl Jesse Barnes
2015-09-04 16:59 ` [PATCH 6/9] drm/i915: driver based PASID handling Jesse Barnes
2015-10-07 13:00   ` David Woodhouse
2015-10-07 15:16     ` Jesse Barnes
2015-10-07 16:14       ` Daniel Vetter
2015-10-07 16:28         ` Jesse Barnes
2015-10-07 17:17           ` David Woodhouse
2015-10-07 17:26             ` Jesse Barnes
2015-10-08  8:12               ` Daniel Vetter
2015-10-08 10:28         ` Tomas Elf
2015-10-08 11:29         ` Tomas Elf
2015-10-08 22:46           ` David Woodhouse
2015-10-09  7:28             ` Daniel Vetter
2015-10-09  7:52               ` Daniel Vetter
2015-10-09  7:56               ` David Woodhouse
2015-10-09  8:47                 ` Daniel Vetter
2015-10-09  9:07                   ` David Woodhouse
2015-10-09 16:20                     ` Jesse Barnes
2015-10-08 15:57   ` Chris Wilson
2015-10-09  7:24     ` David Woodhouse
2015-09-04 16:59 ` [PATCH 7/9] drm/i915: add fences to the request struct Jesse Barnes
2015-10-09 13:29   ` David Woodhouse [this message]
2015-10-09 16:11     ` Jesse Barnes
2015-09-04 16:59 ` [PATCH 8/9] drm/i915: Android sync points for i915 v4 (obsolete) Jesse Barnes
2015-09-04 16:59 ` [PATCH 9/9] drm/i915: add bufferless execbuf ioctl Jesse Barnes
2015-09-04 17:37   ` Chris Wilson
2015-09-04 19:09     ` Jesse Barnes
2015-10-08 10:34   ` David Woodhouse
2015-09-04 17:23 ` [RFC] Page table sharing and bufferless execbuf Chris Wilson
2015-09-04 19:08   ` Jesse Barnes
2015-09-26 14:55 ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1444397368.92154.69.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox