Re: [PATCH] drm/i915: Implement local atomic_state_free callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 05/12/2016 14:09, Chris Wilson wrote:
As we use debugobjects to track the lifetime of fences within our atomic
state, we ideally want to mark those objects as freed along with their
containers. This merits us hookin into config->funcs->atomic_state_free
for this purpose.

Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1624db0856d9..19502c4018ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14607,12 +14607,6 @@ intel_atomic_commit_ready(struct i915_sw_fence *fence,
 		break;

 	case FENCE_FREE:
-		/* Ideally we would hook into the state->destroy callback to
-		 * mark the fence object free at the right time. Since we
-		 * don't currently have that callback, mark it as free
-		 * right away.
-		 */
-		i915_sw_fence_fini(fence);
 		drm_atomic_state_put(&state->base);
 		break;
 	}
@@ -16009,6 +16003,17 @@ intel_user_framebuffer_create(struct drm_device *dev,
 	return fb;
 }

+static void intel_atomic_state_free(struct drm_atomic_state *state)
+{
+	struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+
+	drm_atomic_state_default_release(state);
+
+	i915_sw_fence_fini(&intel_state->commit_ready);
+
+	kfree(state);
+}
+
 static const struct drm_mode_config_funcs intel_mode_funcs = {
 	.fb_create = intel_user_framebuffer_create,
 	.output_poll_changed = intel_fbdev_output_poll_changed,
@@ -16016,6 +16021,7 @@ static const struct drm_mode_config_funcs intel_mode_funcs = {
 	.atomic_commit = intel_atomic_commit,
 	.atomic_state_alloc = intel_atomic_state_alloc,
 	.atomic_state_clear = intel_atomic_state_clear,
+	.atomic_state_free = intel_atomic_state_free,
 };

 /**


Looks correct to me. I would just prefer we go with this straight away and drop the preceding hack.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux