[PATCH 1/3] drm/writeback: don't set fence->ops to default

[PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

It's the default.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/drm_writeback.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 43d9e3bb3a94..dccf4504f1bb 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -108,7 +108,6 @@ static const struct dma_fence_ops drm_writeback_fence_ops = {
 	.get_driver_name = drm_writeback_fence_get_driver_name,
 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
 	.enable_signaling = drm_writeback_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 };
 
 static int create_writeback_properties(struct drm_device *dev)
-- 
2.26.2

[Intel-gfx] [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

It's the default.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/drm_writeback.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 43d9e3bb3a94..dccf4504f1bb 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -108,7 +108,6 @@ static const struct dma_fence_ops drm_writeback_fence_ops = {
 	.get_driver_name = drm_writeback_fence_get_driver_name,
 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
 	.enable_signaling = drm_writeback_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 };
 
 static int create_writeback_properties(struct drm_device *dev)
-- 
2.26.2

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

[PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

It's the default.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/drm_writeback.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 43d9e3bb3a94..dccf4504f1bb 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -108,7 +108,6 @@ static const struct dma_fence_ops drm_writeback_fence_ops = {
 	.get_driver_name = drm_writeback_fence_get_driver_name,
 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
 	.enable_signaling = drm_writeback_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 };
 
 static int create_writeback_properties(struct drm_device *dev)
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

No need to micro-optmize when we're waiting in a mocked object ...

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
 1 file changed, 41 deletions(-)

diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index e593064341c8..8166d2984702 100644
--- a/drivers/dma-buf/st-dma-fence.c
+++ b/drivers/dma-buf/st-dma-fence.c
@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
 	kmem_cache_free(slab_fences, to_mock_fence(f));
 }
 
-struct wait_cb {
-	struct dma_fence_cb cb;
-	struct task_struct *task;
-};
-
-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
-{
-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
-}
-
-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
-{
-	const int state = intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
-	struct wait_cb cb = { .task = current };
-
-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
-		return timeout;
-
-	while (timeout) {
-		set_current_state(state);
-
-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
-			break;
-
-		if (signal_pending_state(state, current))
-			break;
-
-		timeout = schedule_timeout(timeout);
-	}
-	__set_current_state(TASK_RUNNING);
-
-	if (!dma_fence_remove_callback(f, &cb.cb))
-		return timeout;
-
-	if (signal_pending_state(state, current))
-		return -ERESTARTSYS;
-
-	return -ETIME;
-}
-
 static const struct dma_fence_ops mock_ops = {
 	.get_driver_name = mock_name,
 	.get_timeline_name = mock_name,
-	.wait = mock_wait,
 	.release = mock_fence_release,
 };
 
-- 
2.26.2

[Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

No need to micro-optmize when we're waiting in a mocked object ...

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
 1 file changed, 41 deletions(-)

diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index e593064341c8..8166d2984702 100644
--- a/drivers/dma-buf/st-dma-fence.c
+++ b/drivers/dma-buf/st-dma-fence.c
@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
 	kmem_cache_free(slab_fences, to_mock_fence(f));
 }
 
-struct wait_cb {
-	struct dma_fence_cb cb;
-	struct task_struct *task;
-};
-
-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
-{
-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
-}
-
-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
-{
-	const int state = intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
-	struct wait_cb cb = { .task = current };
-
-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
-		return timeout;
-
-	while (timeout) {
-		set_current_state(state);
-
-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
-			break;
-
-		if (signal_pending_state(state, current))
-			break;
-
-		timeout = schedule_timeout(timeout);
-	}
-	__set_current_state(TASK_RUNNING);
-
-	if (!dma_fence_remove_callback(f, &cb.cb))
-		return timeout;
-
-	if (signal_pending_state(state, current))
-		return -ERESTARTSYS;
-
-	return -ETIME;
-}
-
 static const struct dma_fence_ops mock_ops = {
 	.get_driver_name = mock_name,
 	.get_timeline_name = mock_name,
-	.wait = mock_wait,
 	.release = mock_fence_release,
 };
 
-- 
2.26.2

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

[PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

No need to micro-optmize when we're waiting in a mocked object ...

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
 1 file changed, 41 deletions(-)

diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index e593064341c8..8166d2984702 100644
--- a/drivers/dma-buf/st-dma-fence.c
+++ b/drivers/dma-buf/st-dma-fence.c
@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
 	kmem_cache_free(slab_fences, to_mock_fence(f));
 }
 
-struct wait_cb {
-	struct dma_fence_cb cb;
-	struct task_struct *task;
-};
-
-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
-{
-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
-}
-
-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
-{
-	const int state = intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
-	struct wait_cb cb = { .task = current };
-
-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
-		return timeout;
-
-	while (timeout) {
-		set_current_state(state);
-
-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
-			break;
-
-		if (signal_pending_state(state, current))
-			break;
-
-		timeout = schedule_timeout(timeout);
-	}
-	__set_current_state(TASK_RUNNING);
-
-	if (!dma_fence_remove_callback(f, &cb.cb))
-		return timeout;
-
-	if (signal_pending_state(state, current))
-		return -ERESTARTSYS;
-
-	return -ETIME;
-}
-
 static const struct dma_fence_ops mock_ops = {
 	.get_driver_name = mock_name,
 	.get_timeline_name = mock_name,
-	.wait = mock_wait,
 	.release = mock_fence_release,
 };
 
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] dma-fence: use default wait function for mock fences

[Chris Wilson]

Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...

It's setting up the expected return values for the test.
-Chris

Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Chris Wilson]

Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...

It's setting up the expected return values for the test.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] dma-fence: use default wait function for mock fences

[Chris Wilson]

Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...

It's setting up the expected return values for the test.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

On Mon, May 11, 2020 at 10:41:03AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:11:41)
> > No need to micro-optmize when we're waiting in a mocked object ...
> 
> It's setting up the expected return values for the test.

Drat, I suspect something like that but didn't spot it. Kinda wondering
whether we should maybe lift the -ETIME special case to the generic
version. But that's not really a safe thing to do there, drivers might
actually use it for funny stuff.

Anyway motivation is that I'm pondering some extensions of dma_fence_wait
and removing as many of the ->wait hooks as possible would have helped.
But there's some nastier stuff like the legacy nouvea and radeon ones.
-Daniel

Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

On Mon, May 11, 2020 at 10:41:03AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:11:41)
> > No need to micro-optmize when we're waiting in a mocked object ...
> 
> It's setting up the expected return values for the test.

Drat, I suspect something like that but didn't spot it. Kinda wondering
whether we should maybe lift the -ETIME special case to the generic
version. But that's not really a safe thing to do there, drivers might
actually use it for funny stuff.

Anyway motivation is that I'm pondering some extensions of dma_fence_wait
and removing as many of the ->wait hooks as possible would have helped.
But there's some nastier stuff like the legacy nouvea and radeon ones.
-Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/3] dma-fence: use default wait function for mock fences

[Daniel Vetter]

On Mon, May 11, 2020 at 10:41:03AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:11:41)
> > No need to micro-optmize when we're waiting in a mocked object ...
> 
> It's setting up the expected return values for the test.

Drat, I suspect something like that but didn't spot it. Kinda wondering
whether we should maybe lift the -ETIME special case to the generic
version. But that's not really a safe thing to do there, drivers might
actually use it for funny stuff.

Anyway motivation is that I'm pondering some extensions of dma_fence_wait
and removing as many of the ->wait hooks as possible would have helped.
But there's some nastier stuff like the legacy nouvea and radeon ones.
-Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>; linux-
>media@vger.kernel.org
>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>No need to micro-optmize when we're waiting in a mocked object ...

Makes sense to me.

Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

M

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>Cc: linux-media@vger.kernel.org
>Cc: linaro-mm-sig@lists.linaro.org
>---
> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
> 1 file changed, 41 deletions(-)
>
>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>fence.c
>index e593064341c8..8166d2984702 100644
>--- a/drivers/dma-buf/st-dma-fence.c
>+++ b/drivers/dma-buf/st-dma-fence.c
>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
> 	kmem_cache_free(slab_fences, to_mock_fence(f));
> }
>
>-struct wait_cb {
>-	struct dma_fence_cb cb;
>-	struct task_struct *task;
>-};
>-
>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>-{
>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>-}
>-
>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>-{
>-	const int state = intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE;
>-	struct wait_cb cb = { .task = current };
>-
>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>-		return timeout;
>-
>-	while (timeout) {
>-		set_current_state(state);
>-
>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>-			break;
>-
>-		if (signal_pending_state(state, current))
>-			break;
>-
>-		timeout = schedule_timeout(timeout);
>-	}
>-	__set_current_state(TASK_RUNNING);
>-
>-	if (!dma_fence_remove_callback(f, &cb.cb))
>-		return timeout;
>-
>-	if (signal_pending_state(state, current))
>-		return -ERESTARTSYS;
>-
>-	return -ETIME;
>-}
>-
> static const struct dma_fence_ops mock_ops = {
> 	.get_driver_name = mock_name,
> 	.get_timeline_name = mock_name,
>-	.wait = mock_wait,
> 	.release = mock_fence_release,
> };
>
>--
>2.26.2
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>; linux-
>media@vger.kernel.org
>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>No need to micro-optmize when we're waiting in a mocked object ...

Makes sense to me.

Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

M

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>Cc: linux-media@vger.kernel.org
>Cc: linaro-mm-sig@lists.linaro.org
>---
> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
> 1 file changed, 41 deletions(-)
>
>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>fence.c
>index e593064341c8..8166d2984702 100644
>--- a/drivers/dma-buf/st-dma-fence.c
>+++ b/drivers/dma-buf/st-dma-fence.c
>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
> 	kmem_cache_free(slab_fences, to_mock_fence(f));
> }
>
>-struct wait_cb {
>-	struct dma_fence_cb cb;
>-	struct task_struct *task;
>-};
>-
>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>-{
>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>-}
>-
>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>-{
>-	const int state = intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE;
>-	struct wait_cb cb = { .task = current };
>-
>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>-		return timeout;
>-
>-	while (timeout) {
>-		set_current_state(state);
>-
>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>-			break;
>-
>-		if (signal_pending_state(state, current))
>-			break;
>-
>-		timeout = schedule_timeout(timeout);
>-	}
>-	__set_current_state(TASK_RUNNING);
>-
>-	if (!dma_fence_remove_callback(f, &cb.cb))
>-		return timeout;
>-
>-	if (signal_pending_state(state, current))
>-		return -ERESTARTSYS;
>-
>-	return -ETIME;
>-}
>-
> static const struct dma_fence_ops mock_ops = {
> 	.get_driver_name = mock_name,
> 	.get_timeline_name = mock_name,
>-	.wait = mock_wait,
> 	.release = mock_fence_release,
> };
>
>--
>2.26.2
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>; linux-
>media@vger.kernel.org
>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>No need to micro-optmize when we're waiting in a mocked object ...

Makes sense to me.

Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

M

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>Cc: linux-media@vger.kernel.org
>Cc: linaro-mm-sig@lists.linaro.org
>---
> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
> 1 file changed, 41 deletions(-)
>
>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>fence.c
>index e593064341c8..8166d2984702 100644
>--- a/drivers/dma-buf/st-dma-fence.c
>+++ b/drivers/dma-buf/st-dma-fence.c
>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
> 	kmem_cache_free(slab_fences, to_mock_fence(f));
> }
>
>-struct wait_cb {
>-	struct dma_fence_cb cb;
>-	struct task_struct *task;
>-};
>-
>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>-{
>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>-}
>-
>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>-{
>-	const int state = intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE;
>-	struct wait_cb cb = { .task = current };
>-
>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>-		return timeout;
>-
>-	while (timeout) {
>-		set_current_state(state);
>-
>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>-			break;
>-
>-		if (signal_pending_state(state, current))
>-			break;
>-
>-		timeout = schedule_timeout(timeout);
>-	}
>-	__set_current_state(TASK_RUNNING);
>-
>-	if (!dma_fence_remove_callback(f, &cb.cb))
>-		return timeout;
>-
>-	if (signal_pending_state(state, current))
>-		return -ERESTARTSYS;
>-
>-	return -ETIME;
>-}
>-
> static const struct dma_fence_ops mock_ops = {
> 	.get_driver_name = mock_name,
> 	.get_timeline_name = mock_name,
>-	.wait = mock_wait,
> 	.release = mock_fence_release,
> };
>
>--
>2.26.2
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Ruhl, Michael J
>Sent: Monday, May 11, 2020 2:13 PM
>To: Daniel Vetter <daniel.vetter@ffwll.ch>; LKML <linux-
>kernel@vger.kernel.org>
>Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; linaro-mm-
>sig@lists.linaro.org; Vetter, Daniel <daniel.vetter@intel.com>; linux-
>media@vger.kernel.org
>Subject: RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>>-----Original Message-----
>>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>>Daniel Vetter
>>Sent: Monday, May 11, 2020 5:12 AM
>>To: LKML <linux-kernel@vger.kernel.org>
>>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
>><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
>><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>;
>linux-
>>media@vger.kernel.org
>>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>>mock fences
>>
>>No need to micro-optmize when we're waiting in a mocked object ...
>
>Makes sense to me.

/sigh.

Reading Chris comment, I am no longer sure it make sense... 

Un-ack?

m

>Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
>
>M
>
>>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: linux-media@vger.kernel.org
>>Cc: linaro-mm-sig@lists.linaro.org
>>---
>> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
>> 1 file changed, 41 deletions(-)
>>
>>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>>fence.c
>>index e593064341c8..8166d2984702 100644
>>--- a/drivers/dma-buf/st-dma-fence.c
>>+++ b/drivers/dma-buf/st-dma-fence.c
>>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
>> 	kmem_cache_free(slab_fences, to_mock_fence(f));
>> }
>>
>>-struct wait_cb {
>>-	struct dma_fence_cb cb;
>>-	struct task_struct *task;
>>-};
>>-
>>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>>-{
>>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>>-}
>>-
>>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>>-{
>>-	const int state = intr ? TASK_INTERRUPTIBLE :
>>TASK_UNINTERRUPTIBLE;
>>-	struct wait_cb cb = { .task = current };
>>-
>>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>>-		return timeout;
>>-
>>-	while (timeout) {
>>-		set_current_state(state);
>>-
>>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>>-			break;
>>-
>>-		if (signal_pending_state(state, current))
>>-			break;
>>-
>>-		timeout = schedule_timeout(timeout);
>>-	}
>>-	__set_current_state(TASK_RUNNING);
>>-
>>-	if (!dma_fence_remove_callback(f, &cb.cb))
>>-		return timeout;
>>-
>>-	if (signal_pending_state(state, current))
>>-		return -ERESTARTSYS;
>>-
>>-	return -ETIME;
>>-}
>>-
>> static const struct dma_fence_ops mock_ops = {
>> 	.get_driver_name = mock_name,
>> 	.get_timeline_name = mock_name,
>>-	.wait = mock_wait,
>> 	.release = mock_fence_release,
>> };
>>
>>--
>>2.26.2
>>
>>_______________________________________________
>>Intel-gfx mailing list
>>Intel-gfx@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Ruhl, Michael J
>Sent: Monday, May 11, 2020 2:13 PM
>To: Daniel Vetter <daniel.vetter@ffwll.ch>; LKML <linux-
>kernel@vger.kernel.org>
>Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; linaro-mm-
>sig@lists.linaro.org; Vetter, Daniel <daniel.vetter@intel.com>; linux-
>media@vger.kernel.org
>Subject: RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>>-----Original Message-----
>>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>>Daniel Vetter
>>Sent: Monday, May 11, 2020 5:12 AM
>>To: LKML <linux-kernel@vger.kernel.org>
>>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
>><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
>><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>;
>linux-
>>media@vger.kernel.org
>>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>>mock fences
>>
>>No need to micro-optmize when we're waiting in a mocked object ...
>
>Makes sense to me.

/sigh.

Reading Chris comment, I am no longer sure it make sense... 

Un-ack?

m

>Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
>
>M
>
>>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: linux-media@vger.kernel.org
>>Cc: linaro-mm-sig@lists.linaro.org
>>---
>> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
>> 1 file changed, 41 deletions(-)
>>
>>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>>fence.c
>>index e593064341c8..8166d2984702 100644
>>--- a/drivers/dma-buf/st-dma-fence.c
>>+++ b/drivers/dma-buf/st-dma-fence.c
>>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
>> 	kmem_cache_free(slab_fences, to_mock_fence(f));
>> }
>>
>>-struct wait_cb {
>>-	struct dma_fence_cb cb;
>>-	struct task_struct *task;
>>-};
>>-
>>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>>-{
>>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>>-}
>>-
>>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>>-{
>>-	const int state = intr ? TASK_INTERRUPTIBLE :
>>TASK_UNINTERRUPTIBLE;
>>-	struct wait_cb cb = { .task = current };
>>-
>>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>>-		return timeout;
>>-
>>-	while (timeout) {
>>-		set_current_state(state);
>>-
>>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>>-			break;
>>-
>>-		if (signal_pending_state(state, current))
>>-			break;
>>-
>>-		timeout = schedule_timeout(timeout);
>>-	}
>>-	__set_current_state(TASK_RUNNING);
>>-
>>-	if (!dma_fence_remove_callback(f, &cb.cb))
>>-		return timeout;
>>-
>>-	if (signal_pending_state(state, current))
>>-		return -ERESTARTSYS;
>>-
>>-	return -ETIME;
>>-}
>>-
>> static const struct dma_fence_ops mock_ops = {
>> 	.get_driver_name = mock_name,
>> 	.get_timeline_name = mock_name,
>>-	.wait = mock_wait,
>> 	.release = mock_fence_release,
>> };
>>
>>--
>>2.26.2
>>
>>_______________________________________________
>>Intel-gfx mailing list
>>Intel-gfx@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for mock fences

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Ruhl, Michael J
>Sent: Monday, May 11, 2020 2:13 PM
>To: Daniel Vetter <daniel.vetter@ffwll.ch>; LKML <linux-
>kernel@vger.kernel.org>
>Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; linaro-mm-
>sig@lists.linaro.org; Vetter, Daniel <daniel.vetter@intel.com>; linux-
>media@vger.kernel.org
>Subject: RE: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>mock fences
>
>>-----Original Message-----
>>From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
>>Daniel Vetter
>>Sent: Monday, May 11, 2020 5:12 AM
>>To: LKML <linux-kernel@vger.kernel.org>
>>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; Intel Graphics Development
>><intel-gfx@lists.freedesktop.org>; DRI Development <dri-
>>devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org; Vetter, Daniel
>><daniel.vetter@intel.com>; Sumit Semwal <sumit.semwal@linaro.org>;
>linux-
>>media@vger.kernel.org
>>Subject: [Intel-gfx] [PATCH 2/3] dma-fence: use default wait function for
>>mock fences
>>
>>No need to micro-optmize when we're waiting in a mocked object ...
>
>Makes sense to me.

/sigh.

Reading Chris comment, I am no longer sure it make sense... 

Un-ack?

m

>Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
>
>M
>
>>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: linux-media@vger.kernel.org
>>Cc: linaro-mm-sig@lists.linaro.org
>>---
>> drivers/dma-buf/st-dma-fence.c | 41 ----------------------------------
>> 1 file changed, 41 deletions(-)
>>
>>diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-
>>fence.c
>>index e593064341c8..8166d2984702 100644
>>--- a/drivers/dma-buf/st-dma-fence.c
>>+++ b/drivers/dma-buf/st-dma-fence.c
>>@@ -33,50 +33,9 @@ static void mock_fence_release(struct dma_fence *f)
>> 	kmem_cache_free(slab_fences, to_mock_fence(f));
>> }
>>
>>-struct wait_cb {
>>-	struct dma_fence_cb cb;
>>-	struct task_struct *task;
>>-};
>>-
>>-static void mock_wakeup(struct dma_fence *f, struct dma_fence_cb *cb)
>>-{
>>-	wake_up_process(container_of(cb, struct wait_cb, cb)->task);
>>-}
>>-
>>-static long mock_wait(struct dma_fence *f, bool intr, long timeout)
>>-{
>>-	const int state = intr ? TASK_INTERRUPTIBLE :
>>TASK_UNINTERRUPTIBLE;
>>-	struct wait_cb cb = { .task = current };
>>-
>>-	if (dma_fence_add_callback(f, &cb.cb, mock_wakeup))
>>-		return timeout;
>>-
>>-	while (timeout) {
>>-		set_current_state(state);
>>-
>>-		if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &f->flags))
>>-			break;
>>-
>>-		if (signal_pending_state(state, current))
>>-			break;
>>-
>>-		timeout = schedule_timeout(timeout);
>>-	}
>>-	__set_current_state(TASK_RUNNING);
>>-
>>-	if (!dma_fence_remove_callback(f, &cb.cb))
>>-		return timeout;
>>-
>>-	if (signal_pending_state(state, current))
>>-		return -ERESTARTSYS;
>>-
>>-	return -ETIME;
>>-}
>>-
>> static const struct dma_fence_ops mock_ops = {
>> 	.get_driver_name = mock_name,
>> 	.get_timeline_name = mock_name,
>>-	.wait = mock_wait,
>> 	.release = mock_fence_release,
>> };
>>
>>--
>>2.26.2
>>
>>_______________________________________________
>>Intel-gfx mailing list
>>Intel-gfx@lists.freedesktop.org
>>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

It's the default.

Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
around.

Would be great if habanalabs would not use this (from a quick look
it's not needed at all), since open source the userspace and playing
by the usual rules isn't on the table. If that's not possible (because
it's actually using the uapi part of dma_fence to interact with gpu
drivers) then we have exactly what everyone promised we'd want to
avoid.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: 	Olof Johansson <olof@lixom.net>
Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/misc/habanalabs/command_submission.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
index 409276b6374d..cc3ce759b6c3 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
 	.get_driver_name = hl_fence_get_driver_name,
 	.get_timeline_name = hl_fence_get_timeline_name,
 	.enable_signaling = hl_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 	.release = hl_fence_release
 };
 
-- 
2.26.2

[Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

It's the default.

Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
around.

Would be great if habanalabs would not use this (from a quick look
it's not needed at all), since open source the userspace and playing
by the usual rules isn't on the table. If that's not possible (because
it's actually using the uapi part of dma_fence to interact with gpu
drivers) then we have exactly what everyone promised we'd want to
avoid.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: 	Olof Johansson <olof@lixom.net>
Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/misc/habanalabs/command_submission.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
index 409276b6374d..cc3ce759b6c3 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
 	.get_driver_name = hl_fence_get_driver_name,
 	.get_timeline_name = hl_fence_get_timeline_name,
 	.enable_signaling = hl_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 	.release = hl_fence_release
 };
 
-- 
2.26.2

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

[PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

It's the default.

Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
around.

Would be great if habanalabs would not use this (from a quick look
it's not needed at all), since open source the userspace and playing
by the usual rules isn't on the table. If that's not possible (because
it's actually using the uapi part of dma_fence to interact with gpu
drivers) then we have exactly what everyone promised we'd want to
avoid.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: 	Olof Johansson <olof@lixom.net>
Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/misc/habanalabs/command_submission.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
index 409276b6374d..cc3ce759b6c3 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
 	.get_driver_name = hl_fence_get_driver_name,
 	.get_timeline_name = hl_fence_get_timeline_name,
 	.enable_signaling = hl_fence_enable_signaling,
-	.wait = dma_fence_default_wait,
 	.release = hl_fence_release
 };
 
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> It's the default.
Thanks for catching that.

>
> Also so much for "we're not going to tell the graphics people how to
> review their code", dma_fence is a pretty core piece of gpu driver
> infrastructure. And it's very much uapi relevant, including piles of
> corresponding userspace protocols and libraries for how to pass these
> around.
>
> Would be great if habanalabs would not use this (from a quick look
> it's not needed at all), since open source the userspace and playing
> by the usual rules isn't on the table. If that's not possible (because
> it's actually using the uapi part of dma_fence to interact with gpu
> drivers) then we have exactly what everyone promised we'd want to
> avoid.

We don't use the uapi parts, we currently only using the fencing and
signaling ability of this module inside our kernel code. But maybe I
didn't understand what you request. You want us *not* to use this
well-written piece of kernel code because it is only used by graphics
drivers ?
I'm sorry but I don't get this argument, if this is indeed what you meant.

Oded

>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc:     Olof Johansson <olof@lixom.net>
> Cc: Oded Gabbay <oded.gabbay@gmail.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/misc/habanalabs/command_submission.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> index 409276b6374d..cc3ce759b6c3 100644
> --- a/drivers/misc/habanalabs/command_submission.c
> +++ b/drivers/misc/habanalabs/command_submission.c
> @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
>         .get_driver_name = hl_fence_get_driver_name,
>         .get_timeline_name = hl_fence_get_timeline_name,
>         .enable_signaling = hl_fence_enable_signaling,
> -       .wait = dma_fence_default_wait,
>         .release = hl_fence_release
>  };
>
> --
> 2.26.2
>

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> It's the default.
Thanks for catching that.

>
> Also so much for "we're not going to tell the graphics people how to
> review their code", dma_fence is a pretty core piece of gpu driver
> infrastructure. And it's very much uapi relevant, including piles of
> corresponding userspace protocols and libraries for how to pass these
> around.
>
> Would be great if habanalabs would not use this (from a quick look
> it's not needed at all), since open source the userspace and playing
> by the usual rules isn't on the table. If that's not possible (because
> it's actually using the uapi part of dma_fence to interact with gpu
> drivers) then we have exactly what everyone promised we'd want to
> avoid.

We don't use the uapi parts, we currently only using the fencing and
signaling ability of this module inside our kernel code. But maybe I
didn't understand what you request. You want us *not* to use this
well-written piece of kernel code because it is only used by graphics
drivers ?
I'm sorry but I don't get this argument, if this is indeed what you meant.

Oded

>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc:     Olof Johansson <olof@lixom.net>
> Cc: Oded Gabbay <oded.gabbay@gmail.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/misc/habanalabs/command_submission.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> index 409276b6374d..cc3ce759b6c3 100644
> --- a/drivers/misc/habanalabs/command_submission.c
> +++ b/drivers/misc/habanalabs/command_submission.c
> @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
>         .get_driver_name = hl_fence_get_driver_name,
>         .get_timeline_name = hl_fence_get_timeline_name,
>         .enable_signaling = hl_fence_enable_signaling,
> -       .wait = dma_fence_default_wait,
>         .release = hl_fence_release
>  };
>
> --
> 2.26.2
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> It's the default.
Thanks for catching that.

>
> Also so much for "we're not going to tell the graphics people how to
> review their code", dma_fence is a pretty core piece of gpu driver
> infrastructure. And it's very much uapi relevant, including piles of
> corresponding userspace protocols and libraries for how to pass these
> around.
>
> Would be great if habanalabs would not use this (from a quick look
> it's not needed at all), since open source the userspace and playing
> by the usual rules isn't on the table. If that's not possible (because
> it's actually using the uapi part of dma_fence to interact with gpu
> drivers) then we have exactly what everyone promised we'd want to
> avoid.

We don't use the uapi parts, we currently only using the fencing and
signaling ability of this module inside our kernel code. But maybe I
didn't understand what you request. You want us *not* to use this
well-written piece of kernel code because it is only used by graphics
drivers ?
I'm sorry but I don't get this argument, if this is indeed what you meant.

Oded

>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc:     Olof Johansson <olof@lixom.net>
> Cc: Oded Gabbay <oded.gabbay@gmail.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org
> ---
>  drivers/misc/habanalabs/command_submission.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> index 409276b6374d..cc3ce759b6c3 100644
> --- a/drivers/misc/habanalabs/command_submission.c
> +++ b/drivers/misc/habanalabs/command_submission.c
> @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
>         .get_driver_name = hl_fence_get_driver_name,
>         .get_timeline_name = hl_fence_get_timeline_name,
>         .enable_signaling = hl_fence_enable_signaling,
> -       .wait = dma_fence_default_wait,
>         .release = hl_fence_release
>  };
>
> --
> 2.26.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

And just FYI, the driver was written internally at 2016-17, where the
dma-buf module didn't check the .wait ops before calling it and that's
why the initialization of the default wait was there in the first
place.
I should have removed it when I upstreamed it but it missed my review.
Thanks,
Oded

On Mon, May 11, 2020 at 12:36 PM Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> Oded
>
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc:     Olof Johansson <olof@lixom.net>
> > Cc: Oded Gabbay <oded.gabbay@gmail.com>
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: linux-media@vger.kernel.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > ---
> >  drivers/misc/habanalabs/command_submission.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> > index 409276b6374d..cc3ce759b6c3 100644
> > --- a/drivers/misc/habanalabs/command_submission.c
> > +++ b/drivers/misc/habanalabs/command_submission.c
> > @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
> >         .get_driver_name = hl_fence_get_driver_name,
> >         .get_timeline_name = hl_fence_get_timeline_name,
> >         .enable_signaling = hl_fence_enable_signaling,
> > -       .wait = dma_fence_default_wait,
> >         .release = hl_fence_release
> >  };
> >
> > --
> > 2.26.2
> >

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

And just FYI, the driver was written internally at 2016-17, where the
dma-buf module didn't check the .wait ops before calling it and that's
why the initialization of the default wait was there in the first
place.
I should have removed it when I upstreamed it but it missed my review.
Thanks,
Oded

On Mon, May 11, 2020 at 12:36 PM Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> Oded
>
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc:     Olof Johansson <olof@lixom.net>
> > Cc: Oded Gabbay <oded.gabbay@gmail.com>
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: linux-media@vger.kernel.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > ---
> >  drivers/misc/habanalabs/command_submission.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> > index 409276b6374d..cc3ce759b6c3 100644
> > --- a/drivers/misc/habanalabs/command_submission.c
> > +++ b/drivers/misc/habanalabs/command_submission.c
> > @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
> >         .get_driver_name = hl_fence_get_driver_name,
> >         .get_timeline_name = hl_fence_get_timeline_name,
> >         .enable_signaling = hl_fence_enable_signaling,
> > -       .wait = dma_fence_default_wait,
> >         .release = hl_fence_release
> >  };
> >
> > --
> > 2.26.2
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

And just FYI, the driver was written internally at 2016-17, where the
dma-buf module didn't check the .wait ops before calling it and that's
why the initialization of the default wait was there in the first
place.
I should have removed it when I upstreamed it but it missed my review.
Thanks,
Oded

On Mon, May 11, 2020 at 12:36 PM Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> Oded
>
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc:     Olof Johansson <olof@lixom.net>
> > Cc: Oded Gabbay <oded.gabbay@gmail.com>
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: linux-media@vger.kernel.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > ---
> >  drivers/misc/habanalabs/command_submission.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/misc/habanalabs/command_submission.c b/drivers/misc/habanalabs/command_submission.c
> > index 409276b6374d..cc3ce759b6c3 100644
> > --- a/drivers/misc/habanalabs/command_submission.c
> > +++ b/drivers/misc/habanalabs/command_submission.c
> > @@ -46,7 +46,6 @@ static const struct dma_fence_ops hl_fence_ops = {
> >         .get_driver_name = hl_fence_get_driver_name,
> >         .get_timeline_name = hl_fence_get_timeline_name,
> >         .enable_signaling = hl_fence_enable_signaling,
> > -       .wait = dma_fence_default_wait,
> >         .release = hl_fence_release
> >  };
> >
> > --
> > 2.26.2
> >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Dave Airlie]

On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.

We would rather drivers using a feature that has requirements on
correct userspace implementations of the feature have a userspace that
is open source and auditable.

Fencing is tricky, cross-device fencing is really tricky, and having
the ability for a closed userspace component to mess up other people's
drivers, think i915 shared with closed habana userspace and shared
fences, decreases ability to debug things.

Ideally we wouldn't offer users known untested/broken scenarios, so
yes we'd prefer that drivers that intend to expose a userspace fencing
api around dma-fence would adhere to the rules of the gpu drivers.

I'm not say you have to drop using dma-fence, but if you move towards
cross-device stuff I believe other drivers would be correct in
refusing to interact with fences from here.

Dave.

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Dave Airlie]

On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.

We would rather drivers using a feature that has requirements on
correct userspace implementations of the feature have a userspace that
is open source and auditable.

Fencing is tricky, cross-device fencing is really tricky, and having
the ability for a closed userspace component to mess up other people's
drivers, think i915 shared with closed habana userspace and shared
fences, decreases ability to debug things.

Ideally we wouldn't offer users known untested/broken scenarios, so
yes we'd prefer that drivers that intend to expose a userspace fencing
api around dma-fence would adhere to the rules of the gpu drivers.

I'm not say you have to drop using dma-fence, but if you move towards
cross-device stuff I believe other drivers would be correct in
refusing to interact with fences from here.

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

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Dave Airlie]

On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece of gpu driver
> > infrastructure. And it's very much uapi relevant, including piles of
> > corresponding userspace protocols and libraries for how to pass these
> > around.
> >
> > Would be great if habanalabs would not use this (from a quick look
> > it's not needed at all), since open source the userspace and playing
> > by the usual rules isn't on the table. If that's not possible (because
> > it's actually using the uapi part of dma_fence to interact with gpu
> > drivers) then we have exactly what everyone promised we'd want to
> > avoid.
>
> We don't use the uapi parts, we currently only using the fencing and
> signaling ability of this module inside our kernel code. But maybe I
> didn't understand what you request. You want us *not* to use this
> well-written piece of kernel code because it is only used by graphics
> drivers ?
> I'm sorry but I don't get this argument, if this is indeed what you meant.

We would rather drivers using a feature that has requirements on
correct userspace implementations of the feature have a userspace that
is open source and auditable.

Fencing is tricky, cross-device fencing is really tricky, and having
the ability for a closed userspace component to mess up other people's
drivers, think i915 shared with closed habana userspace and shared
fences, decreases ability to debug things.

Ideally we wouldn't offer users known untested/broken scenarios, so
yes we'd prefer that drivers that intend to expose a userspace fencing
api around dma-fence would adhere to the rules of the gpu drivers.

I'm not say you have to drop using dma-fence, but if you move towards
cross-device stuff I believe other drivers would be correct in
refusing to interact with fences from here.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> >
> > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > It's the default.
> > Thanks for catching that.
> >
> > >
> > > Also so much for "we're not going to tell the graphics people how to
> > > review their code", dma_fence is a pretty core piece of gpu driver
> > > infrastructure. And it's very much uapi relevant, including piles of
> > > corresponding userspace protocols and libraries for how to pass these
> > > around.
> > >
> > > Would be great if habanalabs would not use this (from a quick look
> > > it's not needed at all), since open source the userspace and playing
> > > by the usual rules isn't on the table. If that's not possible (because
> > > it's actually using the uapi part of dma_fence to interact with gpu
> > > drivers) then we have exactly what everyone promised we'd want to
> > > avoid.
> >
> > We don't use the uapi parts, we currently only using the fencing and
> > signaling ability of this module inside our kernel code. But maybe I
> > didn't understand what you request. You want us *not* to use this
> > well-written piece of kernel code because it is only used by graphics
> > drivers ?
> > I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> We would rather drivers using a feature that has requirements on
> correct userspace implementations of the feature have a userspace that
> is open source and auditable.
>
> Fencing is tricky, cross-device fencing is really tricky, and having
> the ability for a closed userspace component to mess up other people's
> drivers, think i915 shared with closed habana userspace and shared
> fences, decreases ability to debug things.
>
> Ideally we wouldn't offer users known untested/broken scenarios, so
> yes we'd prefer that drivers that intend to expose a userspace fencing
> api around dma-fence would adhere to the rules of the gpu drivers.
>
> I'm not say you have to drop using dma-fence, but if you move towards
> cross-device stuff I believe other drivers would be correct in
> refusing to interact with fences from here.

The flip side is if you only used dma-fence.c "because it's there",
and not because it comes with an uapi attached and a cross-driver
kernel internal contract for how to interact with gpu drivers, then
there's really not much point in using it. It's a custom-rolled
wait_queue/event thing, that's all. Without the gpu uapi and gpu
cross-driver contract it would be much cleaner to just use wait_queue
directly, and that's a construct all kernel developers understand, not
just gpu folks. From a quick look at least habanalabs doesn't use any
of these uapi/cross-driver/gpu bits.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> >
> > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > It's the default.
> > Thanks for catching that.
> >
> > >
> > > Also so much for "we're not going to tell the graphics people how to
> > > review their code", dma_fence is a pretty core piece of gpu driver
> > > infrastructure. And it's very much uapi relevant, including piles of
> > > corresponding userspace protocols and libraries for how to pass these
> > > around.
> > >
> > > Would be great if habanalabs would not use this (from a quick look
> > > it's not needed at all), since open source the userspace and playing
> > > by the usual rules isn't on the table. If that's not possible (because
> > > it's actually using the uapi part of dma_fence to interact with gpu
> > > drivers) then we have exactly what everyone promised we'd want to
> > > avoid.
> >
> > We don't use the uapi parts, we currently only using the fencing and
> > signaling ability of this module inside our kernel code. But maybe I
> > didn't understand what you request. You want us *not* to use this
> > well-written piece of kernel code because it is only used by graphics
> > drivers ?
> > I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> We would rather drivers using a feature that has requirements on
> correct userspace implementations of the feature have a userspace that
> is open source and auditable.
>
> Fencing is tricky, cross-device fencing is really tricky, and having
> the ability for a closed userspace component to mess up other people's
> drivers, think i915 shared with closed habana userspace and shared
> fences, decreases ability to debug things.
>
> Ideally we wouldn't offer users known untested/broken scenarios, so
> yes we'd prefer that drivers that intend to expose a userspace fencing
> api around dma-fence would adhere to the rules of the gpu drivers.
>
> I'm not say you have to drop using dma-fence, but if you move towards
> cross-device stuff I believe other drivers would be correct in
> refusing to interact with fences from here.

The flip side is if you only used dma-fence.c "because it's there",
and not because it comes with an uapi attached and a cross-driver
kernel internal contract for how to interact with gpu drivers, then
there's really not much point in using it. It's a custom-rolled
wait_queue/event thing, that's all. Without the gpu uapi and gpu
cross-driver contract it would be much cleaner to just use wait_queue
directly, and that's a construct all kernel developers understand, not
just gpu folks. From a quick look at least habanalabs doesn't use any
of these uapi/cross-driver/gpu bits.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> >
> > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > It's the default.
> > Thanks for catching that.
> >
> > >
> > > Also so much for "we're not going to tell the graphics people how to
> > > review their code", dma_fence is a pretty core piece of gpu driver
> > > infrastructure. And it's very much uapi relevant, including piles of
> > > corresponding userspace protocols and libraries for how to pass these
> > > around.
> > >
> > > Would be great if habanalabs would not use this (from a quick look
> > > it's not needed at all), since open source the userspace and playing
> > > by the usual rules isn't on the table. If that's not possible (because
> > > it's actually using the uapi part of dma_fence to interact with gpu
> > > drivers) then we have exactly what everyone promised we'd want to
> > > avoid.
> >
> > We don't use the uapi parts, we currently only using the fencing and
> > signaling ability of this module inside our kernel code. But maybe I
> > didn't understand what you request. You want us *not* to use this
> > well-written piece of kernel code because it is only used by graphics
> > drivers ?
> > I'm sorry but I don't get this argument, if this is indeed what you meant.
>
> We would rather drivers using a feature that has requirements on
> correct userspace implementations of the feature have a userspace that
> is open source and auditable.
>
> Fencing is tricky, cross-device fencing is really tricky, and having
> the ability for a closed userspace component to mess up other people's
> drivers, think i915 shared with closed habana userspace and shared
> fences, decreases ability to debug things.
>
> Ideally we wouldn't offer users known untested/broken scenarios, so
> yes we'd prefer that drivers that intend to expose a userspace fencing
> api around dma-fence would adhere to the rules of the gpu drivers.
>
> I'm not say you have to drop using dma-fence, but if you move towards
> cross-device stuff I believe other drivers would be correct in
> refusing to interact with fences from here.

The flip side is if you only used dma-fence.c "because it's there",
and not because it comes with an uapi attached and a cross-driver
kernel internal contract for how to interact with gpu drivers, then
there's really not much point in using it. It's a custom-rolled
wait_queue/event thing, that's all. Without the gpu uapi and gpu
cross-driver contract it would be much cleaner to just use wait_queue
directly, and that's a construct all kernel developers understand, not
just gpu folks. From a quick look at least habanalabs doesn't use any
of these uapi/cross-driver/gpu bits.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >
> > > > It's the default.
> > > Thanks for catching that.
> > >
> > > >
> > > > Also so much for "we're not going to tell the graphics people how to
> > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > corresponding userspace protocols and libraries for how to pass these
> > > > around.
> > > >
> > > > Would be great if habanalabs would not use this (from a quick look
> > > > it's not needed at all), since open source the userspace and playing
> > > > by the usual rules isn't on the table. If that's not possible (because
> > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > drivers) then we have exactly what everyone promised we'd want to
> > > > avoid.
> > >
> > > We don't use the uapi parts, we currently only using the fencing and
> > > signaling ability of this module inside our kernel code. But maybe I
> > > didn't understand what you request. You want us *not* to use this
> > > well-written piece of kernel code because it is only used by graphics
> > > drivers ?
> > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> >
> > We would rather drivers using a feature that has requirements on
> > correct userspace implementations of the feature have a userspace that
> > is open source and auditable.
> >
> > Fencing is tricky, cross-device fencing is really tricky, and having
> > the ability for a closed userspace component to mess up other people's
> > drivers, think i915 shared with closed habana userspace and shared
> > fences, decreases ability to debug things.
> >
> > Ideally we wouldn't offer users known untested/broken scenarios, so
> > yes we'd prefer that drivers that intend to expose a userspace fencing
> > api around dma-fence would adhere to the rules of the gpu drivers.
> >
> > I'm not say you have to drop using dma-fence, but if you move towards
> > cross-device stuff I believe other drivers would be correct in
> > refusing to interact with fences from here.
>
> The flip side is if you only used dma-fence.c "because it's there",
> and not because it comes with an uapi attached and a cross-driver
> kernel internal contract for how to interact with gpu drivers, then
> there's really not much point in using it. It's a custom-rolled
> wait_queue/event thing, that's all. Without the gpu uapi and gpu
> cross-driver contract it would be much cleaner to just use wait_queue
> directly, and that's a construct all kernel developers understand, not
> just gpu folks. From a quick look at least habanalabs doesn't use any
> of these uapi/cross-driver/gpu bits.
> -Daniel

Hi Daniel,
I want to say explicitly that we don't use the dma-buf uapi parts, nor
we intend to use them to communicate with any GPU device. We only use
it as simple completion mechanism as it was convenient to use.
I do understand I can exchange that mechanism with a simpler one, and
I will add an internal task to do it (albeit not in a very high
priority) and upstream it, its just that it is part of our data path
so we need to thoroughly validate it first.

Thanks,
Oded
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >
> > > > It's the default.
> > > Thanks for catching that.
> > >
> > > >
> > > > Also so much for "we're not going to tell the graphics people how to
> > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > corresponding userspace protocols and libraries for how to pass these
> > > > around.
> > > >
> > > > Would be great if habanalabs would not use this (from a quick look
> > > > it's not needed at all), since open source the userspace and playing
> > > > by the usual rules isn't on the table. If that's not possible (because
> > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > drivers) then we have exactly what everyone promised we'd want to
> > > > avoid.
> > >
> > > We don't use the uapi parts, we currently only using the fencing and
> > > signaling ability of this module inside our kernel code. But maybe I
> > > didn't understand what you request. You want us *not* to use this
> > > well-written piece of kernel code because it is only used by graphics
> > > drivers ?
> > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> >
> > We would rather drivers using a feature that has requirements on
> > correct userspace implementations of the feature have a userspace that
> > is open source and auditable.
> >
> > Fencing is tricky, cross-device fencing is really tricky, and having
> > the ability for a closed userspace component to mess up other people's
> > drivers, think i915 shared with closed habana userspace and shared
> > fences, decreases ability to debug things.
> >
> > Ideally we wouldn't offer users known untested/broken scenarios, so
> > yes we'd prefer that drivers that intend to expose a userspace fencing
> > api around dma-fence would adhere to the rules of the gpu drivers.
> >
> > I'm not say you have to drop using dma-fence, but if you move towards
> > cross-device stuff I believe other drivers would be correct in
> > refusing to interact with fences from here.
>
> The flip side is if you only used dma-fence.c "because it's there",
> and not because it comes with an uapi attached and a cross-driver
> kernel internal contract for how to interact with gpu drivers, then
> there's really not much point in using it. It's a custom-rolled
> wait_queue/event thing, that's all. Without the gpu uapi and gpu
> cross-driver contract it would be much cleaner to just use wait_queue
> directly, and that's a construct all kernel developers understand, not
> just gpu folks. From a quick look at least habanalabs doesn't use any
> of these uapi/cross-driver/gpu bits.
> -Daniel

Hi Daniel,
I want to say explicitly that we don't use the dma-buf uapi parts, nor
we intend to use them to communicate with any GPU device. We only use
it as simple completion mechanism as it was convenient to use.
I do understand I can exchange that mechanism with a simpler one, and
I will add an internal task to do it (albeit not in a very high
priority) and upstream it, its just that it is part of our data path
so we need to thoroughly validate it first.

Thanks,
Oded
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >
> > > > It's the default.
> > > Thanks for catching that.
> > >
> > > >
> > > > Also so much for "we're not going to tell the graphics people how to
> > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > corresponding userspace protocols and libraries for how to pass these
> > > > around.
> > > >
> > > > Would be great if habanalabs would not use this (from a quick look
> > > > it's not needed at all), since open source the userspace and playing
> > > > by the usual rules isn't on the table. If that's not possible (because
> > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > drivers) then we have exactly what everyone promised we'd want to
> > > > avoid.
> > >
> > > We don't use the uapi parts, we currently only using the fencing and
> > > signaling ability of this module inside our kernel code. But maybe I
> > > didn't understand what you request. You want us *not* to use this
> > > well-written piece of kernel code because it is only used by graphics
> > > drivers ?
> > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> >
> > We would rather drivers using a feature that has requirements on
> > correct userspace implementations of the feature have a userspace that
> > is open source and auditable.
> >
> > Fencing is tricky, cross-device fencing is really tricky, and having
> > the ability for a closed userspace component to mess up other people's
> > drivers, think i915 shared with closed habana userspace and shared
> > fences, decreases ability to debug things.
> >
> > Ideally we wouldn't offer users known untested/broken scenarios, so
> > yes we'd prefer that drivers that intend to expose a userspace fencing
> > api around dma-fence would adhere to the rules of the gpu drivers.
> >
> > I'm not say you have to drop using dma-fence, but if you move towards
> > cross-device stuff I believe other drivers would be correct in
> > refusing to interact with fences from here.
>
> The flip side is if you only used dma-fence.c "because it's there",
> and not because it comes with an uapi attached and a cross-driver
> kernel internal contract for how to interact with gpu drivers, then
> there's really not much point in using it. It's a custom-rolled
> wait_queue/event thing, that's all. Without the gpu uapi and gpu
> cross-driver contract it would be much cleaner to just use wait_queue
> directly, and that's a construct all kernel developers understand, not
> just gpu folks. From a quick look at least habanalabs doesn't use any
> of these uapi/cross-driver/gpu bits.
> -Daniel

Hi Daniel,
I want to say explicitly that we don't use the dma-buf uapi parts, nor
we intend to use them to communicate with any GPU device. We only use
it as simple completion mechanism as it was convenient to use.
I do understand I can exchange that mechanism with a simpler one, and
I will add an internal task to do it (albeit not in a very high
priority) and upstream it, its just that it is part of our data path
so we need to thoroughly validate it first.

Thanks,
Oded
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > >
> > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > It's the default.
> > > > Thanks for catching that.
> > > >
> > > > >
> > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > around.
> > > > >
> > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > it's not needed at all), since open source the userspace and playing
> > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > avoid.
> > > >
> > > > We don't use the uapi parts, we currently only using the fencing and
> > > > signaling ability of this module inside our kernel code. But maybe I
> > > > didn't understand what you request. You want us *not* to use this
> > > > well-written piece of kernel code because it is only used by graphics
> > > > drivers ?
> > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > >
> > > We would rather drivers using a feature that has requirements on
> > > correct userspace implementations of the feature have a userspace that
> > > is open source and auditable.
> > >
> > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > the ability for a closed userspace component to mess up other people's
> > > drivers, think i915 shared with closed habana userspace and shared
> > > fences, decreases ability to debug things.
> > >
> > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > api around dma-fence would adhere to the rules of the gpu drivers.
> > >
> > > I'm not say you have to drop using dma-fence, but if you move towards
> > > cross-device stuff I believe other drivers would be correct in
> > > refusing to interact with fences from here.
> >
> > The flip side is if you only used dma-fence.c "because it's there",
> > and not because it comes with an uapi attached and a cross-driver
> > kernel internal contract for how to interact with gpu drivers, then
> > there's really not much point in using it. It's a custom-rolled
> > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > cross-driver contract it would be much cleaner to just use wait_queue
> > directly, and that's a construct all kernel developers understand, not
> > just gpu folks. From a quick look at least habanalabs doesn't use any
> > of these uapi/cross-driver/gpu bits.
> > -Daniel
> 
> Hi Daniel,
> I want to say explicitly that we don't use the dma-buf uapi parts, nor
> we intend to use them to communicate with any GPU device. We only use
> it as simple completion mechanism as it was convenient to use.
> I do understand I can exchange that mechanism with a simpler one, and
> I will add an internal task to do it (albeit not in a very high
> priority) and upstream it, its just that it is part of our data path
> so we need to thoroughly validate it first.

Sounds good.

Wrt merging this patch here, can you include that in one of your next
pulls? Or should I toss it entirely, waiting for you to remove dma_fence
outright?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > >
> > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > It's the default.
> > > > Thanks for catching that.
> > > >
> > > > >
> > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > around.
> > > > >
> > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > it's not needed at all), since open source the userspace and playing
> > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > avoid.
> > > >
> > > > We don't use the uapi parts, we currently only using the fencing and
> > > > signaling ability of this module inside our kernel code. But maybe I
> > > > didn't understand what you request. You want us *not* to use this
> > > > well-written piece of kernel code because it is only used by graphics
> > > > drivers ?
> > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > >
> > > We would rather drivers using a feature that has requirements on
> > > correct userspace implementations of the feature have a userspace that
> > > is open source and auditable.
> > >
> > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > the ability for a closed userspace component to mess up other people's
> > > drivers, think i915 shared with closed habana userspace and shared
> > > fences, decreases ability to debug things.
> > >
> > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > api around dma-fence would adhere to the rules of the gpu drivers.
> > >
> > > I'm not say you have to drop using dma-fence, but if you move towards
> > > cross-device stuff I believe other drivers would be correct in
> > > refusing to interact with fences from here.
> >
> > The flip side is if you only used dma-fence.c "because it's there",
> > and not because it comes with an uapi attached and a cross-driver
> > kernel internal contract for how to interact with gpu drivers, then
> > there's really not much point in using it. It's a custom-rolled
> > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > cross-driver contract it would be much cleaner to just use wait_queue
> > directly, and that's a construct all kernel developers understand, not
> > just gpu folks. From a quick look at least habanalabs doesn't use any
> > of these uapi/cross-driver/gpu bits.
> > -Daniel
> 
> Hi Daniel,
> I want to say explicitly that we don't use the dma-buf uapi parts, nor
> we intend to use them to communicate with any GPU device. We only use
> it as simple completion mechanism as it was convenient to use.
> I do understand I can exchange that mechanism with a simpler one, and
> I will add an internal task to do it (albeit not in a very high
> priority) and upstream it, its just that it is part of our data path
> so we need to thoroughly validate it first.

Sounds good.

Wrt merging this patch here, can you include that in one of your next
pulls? Or should I toss it entirely, waiting for you to remove dma_fence
outright?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > >
> > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > It's the default.
> > > > Thanks for catching that.
> > > >
> > > > >
> > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > around.
> > > > >
> > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > it's not needed at all), since open source the userspace and playing
> > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > avoid.
> > > >
> > > > We don't use the uapi parts, we currently only using the fencing and
> > > > signaling ability of this module inside our kernel code. But maybe I
> > > > didn't understand what you request. You want us *not* to use this
> > > > well-written piece of kernel code because it is only used by graphics
> > > > drivers ?
> > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > >
> > > We would rather drivers using a feature that has requirements on
> > > correct userspace implementations of the feature have a userspace that
> > > is open source and auditable.
> > >
> > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > the ability for a closed userspace component to mess up other people's
> > > drivers, think i915 shared with closed habana userspace and shared
> > > fences, decreases ability to debug things.
> > >
> > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > api around dma-fence would adhere to the rules of the gpu drivers.
> > >
> > > I'm not say you have to drop using dma-fence, but if you move towards
> > > cross-device stuff I believe other drivers would be correct in
> > > refusing to interact with fences from here.
> >
> > The flip side is if you only used dma-fence.c "because it's there",
> > and not because it comes with an uapi attached and a cross-driver
> > kernel internal contract for how to interact with gpu drivers, then
> > there's really not much point in using it. It's a custom-rolled
> > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > cross-driver contract it would be much cleaner to just use wait_queue
> > directly, and that's a construct all kernel developers understand, not
> > just gpu folks. From a quick look at least habanalabs doesn't use any
> > of these uapi/cross-driver/gpu bits.
> > -Daniel
> 
> Hi Daniel,
> I want to say explicitly that we don't use the dma-buf uapi parts, nor
> we intend to use them to communicate with any GPU device. We only use
> it as simple completion mechanism as it was convenient to use.
> I do understand I can exchange that mechanism with a simpler one, and
> I will add an internal task to do it (albeit not in a very high
> priority) and upstream it, its just that it is part of our data path
> so we need to thoroughly validate it first.

Sounds good.

Wrt merging this patch here, can you include that in one of your next
pulls? Or should I toss it entirely, waiting for you to remove dma_fence
outright?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > > >
> > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > > >
> > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > >
> > > > > > It's the default.
> > > > > Thanks for catching that.
> > > > >
> > > > > >
> > > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > > around.
> > > > > >
> > > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > > it's not needed at all), since open source the userspace and playing
> > > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > > avoid.
> > > > >
> > > > > We don't use the uapi parts, we currently only using the fencing and
> > > > > signaling ability of this module inside our kernel code. But maybe I
> > > > > didn't understand what you request. You want us *not* to use this
> > > > > well-written piece of kernel code because it is only used by graphics
> > > > > drivers ?
> > > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > > >
> > > > We would rather drivers using a feature that has requirements on
> > > > correct userspace implementations of the feature have a userspace that
> > > > is open source and auditable.
> > > >
> > > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > > the ability for a closed userspace component to mess up other people's
> > > > drivers, think i915 shared with closed habana userspace and shared
> > > > fences, decreases ability to debug things.
> > > >
> > > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > > api around dma-fence would adhere to the rules of the gpu drivers.
> > > >
> > > > I'm not say you have to drop using dma-fence, but if you move towards
> > > > cross-device stuff I believe other drivers would be correct in
> > > > refusing to interact with fences from here.
> > >
> > > The flip side is if you only used dma-fence.c "because it's there",
> > > and not because it comes with an uapi attached and a cross-driver
> > > kernel internal contract for how to interact with gpu drivers, then
> > > there's really not much point in using it. It's a custom-rolled
> > > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > > cross-driver contract it would be much cleaner to just use wait_queue
> > > directly, and that's a construct all kernel developers understand, not
> > > just gpu folks. From a quick look at least habanalabs doesn't use any
> > > of these uapi/cross-driver/gpu bits.
> > > -Daniel
> >
> > Hi Daniel,
> > I want to say explicitly that we don't use the dma-buf uapi parts, nor
> > we intend to use them to communicate with any GPU device. We only use
> > it as simple completion mechanism as it was convenient to use.
> > I do understand I can exchange that mechanism with a simpler one, and
> > I will add an internal task to do it (albeit not in a very high
> > priority) and upstream it, its just that it is part of our data path
> > so we need to thoroughly validate it first.
>
> Sounds good.
>
> Wrt merging this patch here, can you include that in one of your next
> pulls? Or should I toss it entirely, waiting for you to remove dma_fence
> outright?

I'll include it in the next pull.
Thanks,
Oded
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > > >
> > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > > >
> > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > >
> > > > > > It's the default.
> > > > > Thanks for catching that.
> > > > >
> > > > > >
> > > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > > around.
> > > > > >
> > > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > > it's not needed at all), since open source the userspace and playing
> > > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > > avoid.
> > > > >
> > > > > We don't use the uapi parts, we currently only using the fencing and
> > > > > signaling ability of this module inside our kernel code. But maybe I
> > > > > didn't understand what you request. You want us *not* to use this
> > > > > well-written piece of kernel code because it is only used by graphics
> > > > > drivers ?
> > > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > > >
> > > > We would rather drivers using a feature that has requirements on
> > > > correct userspace implementations of the feature have a userspace that
> > > > is open source and auditable.
> > > >
> > > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > > the ability for a closed userspace component to mess up other people's
> > > > drivers, think i915 shared with closed habana userspace and shared
> > > > fences, decreases ability to debug things.
> > > >
> > > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > > api around dma-fence would adhere to the rules of the gpu drivers.
> > > >
> > > > I'm not say you have to drop using dma-fence, but if you move towards
> > > > cross-device stuff I believe other drivers would be correct in
> > > > refusing to interact with fences from here.
> > >
> > > The flip side is if you only used dma-fence.c "because it's there",
> > > and not because it comes with an uapi attached and a cross-driver
> > > kernel internal contract for how to interact with gpu drivers, then
> > > there's really not much point in using it. It's a custom-rolled
> > > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > > cross-driver contract it would be much cleaner to just use wait_queue
> > > directly, and that's a construct all kernel developers understand, not
> > > just gpu folks. From a quick look at least habanalabs doesn't use any
> > > of these uapi/cross-driver/gpu bits.
> > > -Daniel
> >
> > Hi Daniel,
> > I want to say explicitly that we don't use the dma-buf uapi parts, nor
> > we intend to use them to communicate with any GPU device. We only use
> > it as simple completion mechanism as it was convenient to use.
> > I do understand I can exchange that mechanism with a simpler one, and
> > I will add an internal task to do it (albeit not in a very high
> > priority) and upstream it, its just that it is part of our data path
> > so we need to thoroughly validate it first.
>
> Sounds good.
>
> Wrt merging this patch here, can you include that in one of your next
> pulls? Or should I toss it entirely, waiting for you to remove dma_fence
> outright?

I'll include it in the next pull.
Thanks,
Oded
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie <airlied@gmail.com> wrote:
> > > >
> > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > > > >
> > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > >
> > > > > > It's the default.
> > > > > Thanks for catching that.
> > > > >
> > > > > >
> > > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > > around.
> > > > > >
> > > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > > it's not needed at all), since open source the userspace and playing
> > > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > > avoid.
> > > > >
> > > > > We don't use the uapi parts, we currently only using the fencing and
> > > > > signaling ability of this module inside our kernel code. But maybe I
> > > > > didn't understand what you request. You want us *not* to use this
> > > > > well-written piece of kernel code because it is only used by graphics
> > > > > drivers ?
> > > > > I'm sorry but I don't get this argument, if this is indeed what you meant.
> > > >
> > > > We would rather drivers using a feature that has requirements on
> > > > correct userspace implementations of the feature have a userspace that
> > > > is open source and auditable.
> > > >
> > > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > > the ability for a closed userspace component to mess up other people's
> > > > drivers, think i915 shared with closed habana userspace and shared
> > > > fences, decreases ability to debug things.
> > > >
> > > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > > api around dma-fence would adhere to the rules of the gpu drivers.
> > > >
> > > > I'm not say you have to drop using dma-fence, but if you move towards
> > > > cross-device stuff I believe other drivers would be correct in
> > > > refusing to interact with fences from here.
> > >
> > > The flip side is if you only used dma-fence.c "because it's there",
> > > and not because it comes with an uapi attached and a cross-driver
> > > kernel internal contract for how to interact with gpu drivers, then
> > > there's really not much point in using it. It's a custom-rolled
> > > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > > cross-driver contract it would be much cleaner to just use wait_queue
> > > directly, and that's a construct all kernel developers understand, not
> > > just gpu folks. From a quick look at least habanalabs doesn't use any
> > > of these uapi/cross-driver/gpu bits.
> > > -Daniel
> >
> > Hi Daniel,
> > I want to say explicitly that we don't use the dma-buf uapi parts, nor
> > we intend to use them to communicate with any GPU device. We only use
> > it as simple completion mechanism as it was convenient to use.
> > I do understand I can exchange that mechanism with a simpler one, and
> > I will add an internal task to do it (albeit not in a very high
> > priority) and upstream it, its just that it is part of our data path
> > so we need to thoroughly validate it first.
>
> Sounds good.
>
> Wrt merging this patch here, can you include that in one of your next
> pulls? Or should I toss it entirely, waiting for you to remove dma_fence
> outright?

I'll include it in the next pull.
Thanks,
Oded
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/writeback: don't set fence->ops to default

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/writeback: don't set fence->ops to default
URL   : https://patchwork.freedesktop.org/series/77144/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9634e3eb3729 drm/writeback: don't set fence->ops to default
-:26: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 7 lines checked
d701844ab384 dma-fence: use default wait function for mock fences
-:67: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 50 lines checked
22f23e5ef53f misc/habalabs: don't set default fence_ops->wait
-:23: WARNING:BAD_SIGN_OFF: Use a single space after Cc:
#23: 
Cc: 	Olof Johansson <olof@lixom.net>

-:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 2 warnings, 0 checks, 7 lines checked

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/writeback: don't set fence->ops to default

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/writeback: don't set fence->ops to default
URL   : https://patchwork.freedesktop.org/series/77144/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8461 -> Patchwork_17621
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_17621 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17621, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_17621:

### IGT changes ###

#### Possible regressions ####

  * igt@dmabuf@all@dma_fence:
    - fi-icl-u2:          [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-icl-u2/igt@dmabuf@all@dma_fence.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-icl-u2/igt@dmabuf@all@dma_fence.html
    - fi-icl-guc:         [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-icl-guc/igt@dmabuf@all@dma_fence.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-icl-guc/igt@dmabuf@all@dma_fence.html
    - fi-kbl-8809g:       [PASS][5] -> [FAIL][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-kbl-8809g/igt@dmabuf@all@dma_fence.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-kbl-8809g/igt@dmabuf@all@dma_fence.html
    - fi-byt-n2820:       [PASS][7] -> [FAIL][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-byt-n2820/igt@dmabuf@all@dma_fence.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-byt-n2820/igt@dmabuf@all@dma_fence.html
    - fi-kbl-r:           [PASS][9] -> [FAIL][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-kbl-r/igt@dmabuf@all@dma_fence.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-kbl-r/igt@dmabuf@all@dma_fence.html
    - fi-cfl-8700k:       [PASS][11] -> [FAIL][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-cfl-8700k/igt@dmabuf@all@dma_fence.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-cfl-8700k/igt@dmabuf@all@dma_fence.html
    - fi-apl-guc:         [PASS][13] -> [FAIL][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-apl-guc/igt@dmabuf@all@dma_fence.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-apl-guc/igt@dmabuf@all@dma_fence.html
    - fi-snb-2520m:       [PASS][15] -> [FAIL][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-snb-2520m/igt@dmabuf@all@dma_fence.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-snb-2520m/igt@dmabuf@all@dma_fence.html
    - fi-bsw-kefka:       [PASS][17] -> [FAIL][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bsw-kefka/igt@dmabuf@all@dma_fence.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bsw-kefka/igt@dmabuf@all@dma_fence.html
    - fi-glk-dsi:         [PASS][19] -> [FAIL][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-glk-dsi/igt@dmabuf@all@dma_fence.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-glk-dsi/igt@dmabuf@all@dma_fence.html
    - fi-kbl-x1275:       [PASS][21] -> [FAIL][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-kbl-x1275/igt@dmabuf@all@dma_fence.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-kbl-x1275/igt@dmabuf@all@dma_fence.html
    - fi-cml-s:           [PASS][23] -> [FAIL][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-cml-s/igt@dmabuf@all@dma_fence.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-cml-s/igt@dmabuf@all@dma_fence.html
    - fi-skl-6600u:       [PASS][25] -> [FAIL][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-skl-6600u/igt@dmabuf@all@dma_fence.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-skl-6600u/igt@dmabuf@all@dma_fence.html
    - fi-skl-guc:         [PASS][27] -> [FAIL][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-skl-guc/igt@dmabuf@all@dma_fence.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-skl-guc/igt@dmabuf@all@dma_fence.html
    - fi-icl-y:           NOTRUN -> [FAIL][29]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-icl-y/igt@dmabuf@all@dma_fence.html
    - fi-cfl-guc:         [PASS][30] -> [FAIL][31]
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-cfl-guc/igt@dmabuf@all@dma_fence.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-cfl-guc/igt@dmabuf@all@dma_fence.html
    - fi-bsw-n3050:       [PASS][32] -> [FAIL][33]
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bsw-n3050/igt@dmabuf@all@dma_fence.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bsw-n3050/igt@dmabuf@all@dma_fence.html
    - fi-ilk-650:         [PASS][34] -> [FAIL][35]
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-ilk-650/igt@dmabuf@all@dma_fence.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-ilk-650/igt@dmabuf@all@dma_fence.html
    - fi-ivb-3770:        [PASS][36] -> [FAIL][37]
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-ivb-3770/igt@dmabuf@all@dma_fence.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-ivb-3770/igt@dmabuf@all@dma_fence.html
    - fi-cml-u2:          [PASS][38] -> [FAIL][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-cml-u2/igt@dmabuf@all@dma_fence.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-cml-u2/igt@dmabuf@all@dma_fence.html
    - fi-blb-e6850:       [PASS][40] -> [FAIL][41]
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-blb-e6850/igt@dmabuf@all@dma_fence.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-blb-e6850/igt@dmabuf@all@dma_fence.html
    - fi-byt-j1900:       [PASS][42] -> [FAIL][43]
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-byt-j1900/igt@dmabuf@all@dma_fence.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-byt-j1900/igt@dmabuf@all@dma_fence.html
    - fi-elk-e7500:       [PASS][44] -> [FAIL][45]
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-elk-e7500/igt@dmabuf@all@dma_fence.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-elk-e7500/igt@dmabuf@all@dma_fence.html
    - fi-skl-6700k2:      [PASS][46] -> [FAIL][47]
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-skl-6700k2/igt@dmabuf@all@dma_fence.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-skl-6700k2/igt@dmabuf@all@dma_fence.html
    - fi-bxt-dsi:         [PASS][48] -> [FAIL][49]
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bxt-dsi/igt@dmabuf@all@dma_fence.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bxt-dsi/igt@dmabuf@all@dma_fence.html
    - fi-hsw-4770:        [PASS][50] -> [FAIL][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-hsw-4770/igt@dmabuf@all@dma_fence.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-hsw-4770/igt@dmabuf@all@dma_fence.html
    - fi-whl-u:           [PASS][52] -> [FAIL][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-whl-u/igt@dmabuf@all@dma_fence.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-whl-u/igt@dmabuf@all@dma_fence.html
    - fi-bdw-5557u:       [PASS][54] -> [FAIL][55]
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bdw-5557u/igt@dmabuf@all@dma_fence.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bdw-5557u/igt@dmabuf@all@dma_fence.html
    - fi-snb-2600:        [PASS][56] -> [FAIL][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-snb-2600/igt@dmabuf@all@dma_fence.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-snb-2600/igt@dmabuf@all@dma_fence.html
    - fi-bwr-2160:        [PASS][58] -> [FAIL][59]
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bwr-2160/igt@dmabuf@all@dma_fence.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bwr-2160/igt@dmabuf@all@dma_fence.html
    - fi-gdg-551:         [PASS][60] -> [FAIL][61]
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-gdg-551/igt@dmabuf@all@dma_fence.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-gdg-551/igt@dmabuf@all@dma_fence.html
    - fi-skl-lmem:        [PASS][62] -> [FAIL][63]
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-skl-lmem/igt@dmabuf@all@dma_fence.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-skl-lmem/igt@dmabuf@all@dma_fence.html
    - fi-kbl-guc:         [PASS][64] -> [FAIL][65]
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-kbl-guc/igt@dmabuf@all@dma_fence.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-kbl-guc/igt@dmabuf@all@dma_fence.html
    - fi-cfl-8109u:       [PASS][66] -> [FAIL][67]
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-cfl-8109u/igt@dmabuf@all@dma_fence.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-cfl-8109u/igt@dmabuf@all@dma_fence.html
    - fi-bsw-nick:        [PASS][68] -> [FAIL][69]
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-bsw-nick/igt@dmabuf@all@dma_fence.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-bsw-nick/igt@dmabuf@all@dma_fence.html

  * igt@i915_selftest@live@requests:
    - fi-kbl-soraka:      [PASS][70] -> [INCOMPLETE][71]
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-kbl-soraka/igt@i915_selftest@live@requests.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-kbl-soraka/igt@i915_selftest@live@requests.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@dmabuf@all@dma_fence:
    - {fi-tgl-dsi}:       [PASS][72] -> [FAIL][73]
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-tgl-dsi/igt@dmabuf@all@dma_fence.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-tgl-dsi/igt@dmabuf@all@dma_fence.html
    - {fi-tgl-u}:         [PASS][74] -> [FAIL][75]
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-tgl-u/igt@dmabuf@all@dma_fence.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-tgl-u/igt@dmabuf@all@dma_fence.html
    - {fi-ehl-1}:         [PASS][76] -> [FAIL][77]
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-ehl-1/igt@dmabuf@all@dma_fence.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-ehl-1/igt@dmabuf@all@dma_fence.html

  
Known issues
------------

  Here are the changes found in Patchwork_17621 that come from known issues:

### IGT changes ###

#### Possible fixes ####

  * igt@i915_selftest@live@hangcheck:
    - fi-icl-y:           [INCOMPLETE][78] ([i915#1580]) -> [PASS][79]
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8461/fi-icl-y/igt@i915_selftest@live@hangcheck.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/fi-icl-y/igt@i915_selftest@live@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580


Participating hosts (48 -> 43)
------------------------------

  Additional (1): fi-kbl-7560u 
  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8461 -> Patchwork_17621

  CI-20190529: 20190529
  CI_DRM_8461: c0be14b9502e54c9ece4f4fc25872d665c6a6553 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5644: 16f067ae42a6a93b8f0c5835210e2575a883001b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17621: 22f23e5ef53f4a88a03167d3341821452c5f2d4f @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

22f23e5ef53f misc/habalabs: don't set default fence_ops->wait
d701844ab384 dma-fence: use default wait function for mock fences
9634e3eb3729 drm/writeback: don't set fence->ops to default

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17621/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
>Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
>Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
>
>It's the default.

I can get behind that. 😊

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Cc: Maxime Ripard <mripard@kernel.org>
>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>Cc: David Airlie <airlied@linux.ie>
>Cc: Daniel Vetter <daniel@ffwll.ch>
>---
> drivers/gpu/drm/drm_writeback.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_writeback.c
>b/drivers/gpu/drm/drm_writeback.c
>index 43d9e3bb3a94..dccf4504f1bb 100644
>--- a/drivers/gpu/drm/drm_writeback.c
>+++ b/drivers/gpu/drm/drm_writeback.c
>@@ -108,7 +108,6 @@ static const struct dma_fence_ops
>drm_writeback_fence_ops = {
> 	.get_driver_name = drm_writeback_fence_get_driver_name,
> 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> 	.enable_signaling = drm_writeback_fence_enable_signaling,
>-	.wait = dma_fence_default_wait,
> };
>
> static int create_writeback_properties(struct drm_device *dev)
>--
>2.26.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
>Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
>Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
>
>It's the default.

I can get behind that. 😊

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Cc: Maxime Ripard <mripard@kernel.org>
>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>Cc: David Airlie <airlied@linux.ie>
>Cc: Daniel Vetter <daniel@ffwll.ch>
>---
> drivers/gpu/drm/drm_writeback.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_writeback.c
>b/drivers/gpu/drm/drm_writeback.c
>index 43d9e3bb3a94..dccf4504f1bb 100644
>--- a/drivers/gpu/drm/drm_writeback.c
>+++ b/drivers/gpu/drm/drm_writeback.c
>@@ -108,7 +108,6 @@ static const struct dma_fence_ops
>drm_writeback_fence_ops = {
> 	.get_driver_name = drm_writeback_fence_get_driver_name,
> 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> 	.enable_signaling = drm_writeback_fence_enable_signaling,
>-	.wait = dma_fence_default_wait,
> };
>
> static int create_writeback_properties(struct drm_device *dev)
>--
>2.26.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Ruhl, Michael J]

>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML <linux-kernel@vger.kernel.org>
>Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
>Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
>Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
>Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
>
>It's the default.

I can get behind that. 😊

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

>Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Cc: Maxime Ripard <mripard@kernel.org>
>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>Cc: David Airlie <airlied@linux.ie>
>Cc: Daniel Vetter <daniel@ffwll.ch>
>---
> drivers/gpu/drm/drm_writeback.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_writeback.c
>b/drivers/gpu/drm/drm_writeback.c
>index 43d9e3bb3a94..dccf4504f1bb 100644
>--- a/drivers/gpu/drm/drm_writeback.c
>+++ b/drivers/gpu/drm/drm_writeback.c
>@@ -108,7 +108,6 @@ static const struct dma_fence_ops
>drm_writeback_fence_ops = {
> 	.get_driver_name = drm_writeback_fence_get_driver_name,
> 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> 	.enable_signaling = drm_writeback_fence_enable_signaling,
>-	.wait = dma_fence_default_wait,
> };
>
> static int create_writeback_properties(struct drm_device *dev)
>--
>2.26.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

On Mon, May 11, 2020 at 06:12:32PM +0000, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML <linux-kernel@vger.kernel.org>
> >Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
> >Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
> >Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
> ><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
> >Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
> >
> >It's the default.
> 
> I can get behind that. 😊
> 
> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

Applied to drm-misc-next, thanks for reviewing.
-Daniel

> 
> >Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >Cc: Maxime Ripard <mripard@kernel.org>
> >Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >Cc: David Airlie <airlied@linux.ie>
> >Cc: Daniel Vetter <daniel@ffwll.ch>
> >---
> > drivers/gpu/drm/drm_writeback.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_writeback.c
> >b/drivers/gpu/drm/drm_writeback.c
> >index 43d9e3bb3a94..dccf4504f1bb 100644
> >--- a/drivers/gpu/drm/drm_writeback.c
> >+++ b/drivers/gpu/drm/drm_writeback.c
> >@@ -108,7 +108,6 @@ static const struct dma_fence_ops
> >drm_writeback_fence_ops = {
> > 	.get_driver_name = drm_writeback_fence_get_driver_name,
> > 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> > 	.enable_signaling = drm_writeback_fence_enable_signaling,
> >-	.wait = dma_fence_default_wait,
> > };
> >
> > static int create_writeback_properties(struct drm_device *dev)
> >--
> >2.26.2
> >
> >_______________________________________________
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

On Mon, May 11, 2020 at 06:12:32PM +0000, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML <linux-kernel@vger.kernel.org>
> >Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
> >Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
> >Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
> ><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
> >Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
> >
> >It's the default.
> 
> I can get behind that. 😊
> 
> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

Applied to drm-misc-next, thanks for reviewing.
-Daniel

> 
> >Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >Cc: Maxime Ripard <mripard@kernel.org>
> >Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >Cc: David Airlie <airlied@linux.ie>
> >Cc: Daniel Vetter <daniel@ffwll.ch>
> >---
> > drivers/gpu/drm/drm_writeback.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_writeback.c
> >b/drivers/gpu/drm/drm_writeback.c
> >index 43d9e3bb3a94..dccf4504f1bb 100644
> >--- a/drivers/gpu/drm/drm_writeback.c
> >+++ b/drivers/gpu/drm/drm_writeback.c
> >@@ -108,7 +108,6 @@ static const struct dma_fence_ops
> >drm_writeback_fence_ops = {
> > 	.get_driver_name = drm_writeback_fence_get_driver_name,
> > 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> > 	.enable_signaling = drm_writeback_fence_enable_signaling,
> >-	.wait = dma_fence_default_wait,
> > };
> >
> > static int create_writeback_properties(struct drm_device *dev)
> >--
> >2.26.2
> >
> >_______________________________________________
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

On Mon, May 11, 2020 at 06:12:32PM +0000, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML <linux-kernel@vger.kernel.org>
> >Cc: David Airlie <airlied@linux.ie>; Daniel Vetter <daniel.vetter@ffwll.ch>;
> >Intel Graphics Development <intel-gfx@lists.freedesktop.org>; DRI
> >Development <dri-devel@lists.freedesktop.org>; Thomas Zimmermann
> ><tzimmermann@suse.de>; Vetter, Daniel <daniel.vetter@intel.com>
> >Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
> >
> >It's the default.
> 
> I can get behind that. 😊
> 
> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

Applied to drm-misc-next, thanks for reviewing.
-Daniel

> 
> >Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >Cc: Maxime Ripard <mripard@kernel.org>
> >Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >Cc: David Airlie <airlied@linux.ie>
> >Cc: Daniel Vetter <daniel@ffwll.ch>
> >---
> > drivers/gpu/drm/drm_writeback.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_writeback.c
> >b/drivers/gpu/drm/drm_writeback.c
> >index 43d9e3bb3a94..dccf4504f1bb 100644
> >--- a/drivers/gpu/drm/drm_writeback.c
> >+++ b/drivers/gpu/drm/drm_writeback.c
> >@@ -108,7 +108,6 @@ static const struct dma_fence_ops
> >drm_writeback_fence_ops = {
> > 	.get_driver_name = drm_writeback_fence_get_driver_name,
> > 	.get_timeline_name = drm_writeback_fence_get_timeline_name,
> > 	.enable_signaling = drm_writeback_fence_enable_signaling,
> >-	.wait = dma_fence_default_wait,
> > };
> >
> > static int create_writeback_properties(struct drm_device *dev)
> >--
> >2.26.2
> >
> >_______________________________________________
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel