public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread
@ 2016-10-19  8:12 Chris Wilson
  2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Chris Wilson @ 2016-10-19  8:12 UTC (permalink / raw)
  To: intel-gfx

The kthread will not be interrupted, don't even bother checking.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index b15cdf5978a9..4cedd3274da7 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -423,12 +423,7 @@ static int workload_thread(void *priv)
 		/*
 		 * Always take i915 big lock first
 		 */
-		ret = i915_mutex_lock_interruptible(&gvt->dev_priv->drm);
-		if (ret < 0) {
-			gvt_err("i915 submission is not available, retry\n");
-			schedule_timeout(1);
-			continue;
-		}
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 
 		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
 				workload->ring_id, workload);
@@ -447,7 +442,7 @@ static int workload_thread(void *priv)
 				workload->ring_id, workload);
 
 		workload->status = i915_wait_request(workload->req,
-						     I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
+						     I915_WAIT_LOCKED,
 						     NULL, NULL);
 		if (workload->status != 0)
 			gvt_err("fail to wait workload, skip\n");
-- 
2.9.3

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

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  8:12 [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Chris Wilson
@ 2016-10-19  8:12 ` Chris Wilson
  2016-10-19  8:54   ` Zhenyu Wang
  2016-10-19  8:55   ` [PATCH 2/2] " Matthew Auld
  2016-10-19  8:50 ` [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Zhenyu Wang
  2016-10-19 11:01 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2) Patchwork
  2 siblings, 2 replies; 10+ messages in thread
From: Chris Wilson @ 2016-10-19  8:12 UTC (permalink / raw)
  To: intel-gfx

For whatever reason, the gvt scheduler runs synchronously. At the very
least, lets run synchronously without holding the struct_mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index 4cedd3274da7..aa83dd3381a3 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -420,10 +420,6 @@ static int workload_thread(void *priv)
 
 		intel_runtime_pm_get(gvt->dev_priv);
 
-		/*
-		 * Always take i915 big lock first
-		 */
-		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 
 		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
 				workload->ring_id, workload);
@@ -432,7 +428,10 @@ static int workload_thread(void *priv)
 			intel_uncore_forcewake_get(gvt->dev_priv,
 					FORCEWAKE_ALL);
 
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 		ret = dispatch_workload(workload);
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
+
 		if (ret) {
 			gvt_err("fail to dispatch workload, skip\n");
 			goto complete;
@@ -442,8 +441,7 @@ static int workload_thread(void *priv)
 				workload->ring_id, workload);
 
 		workload->status = i915_wait_request(workload->req,
-						     I915_WAIT_LOCKED,
-						     NULL, NULL);
+						     0, NULL, NULL);
 		if (workload->status != 0)
 			gvt_err("fail to wait workload, skip\n");
 
@@ -451,13 +449,14 @@ static int workload_thread(void *priv)
 		gvt_dbg_sched("will complete workload %p\n, status: %d\n",
 				workload, workload->status);
 
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 		complete_current_workload(gvt, ring_id);
+		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
 
 		if (need_force_wake)
 			intel_uncore_forcewake_put(gvt->dev_priv,
 					FORCEWAKE_ALL);
 
-		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
 
 		intel_runtime_pm_put(gvt->dev_priv);
 	}
-- 
2.9.3

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

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread
  2016-10-19  8:12 [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Chris Wilson
  2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
@ 2016-10-19  8:50 ` Zhenyu Wang
  2016-10-19 11:01 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2) Patchwork
  2 siblings, 0 replies; 10+ messages in thread
From: Zhenyu Wang @ 2016-10-19  8:50 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx


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

On 2016.10.19 09:12:27 +0100, Chris Wilson wrote:
> The kthread will not be interrupted, don't even bother checking.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..4cedd3274da7 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -423,12 +423,7 @@ static int workload_thread(void *priv)
>  		/*
>  		 * Always take i915 big lock first
>  		 */
> -		ret = i915_mutex_lock_interruptible(&gvt->dev_priv->drm);
> -		if (ret < 0) {
> -			gvt_err("i915 submission is not available, retry\n");
> -			schedule_timeout(1);
> -			continue;
> -		}
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  
>  		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>  				workload->ring_id, workload);
> @@ -447,7 +442,7 @@ static int workload_thread(void *priv)
>  				workload->ring_id, workload);
>  
>  		workload->status = i915_wait_request(workload->req,
> -						     I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
> +						     I915_WAIT_LOCKED,
>  						     NULL, NULL);
>  		if (workload->status != 0)
>  			gvt_err("fail to wait workload, skip\n");
> -- 
> 2.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
@ 2016-10-19  8:54   ` Zhenyu Wang
  2016-10-19  9:08     ` Chris Wilson
  2016-10-19  9:14     ` [PATCH v2] " Chris Wilson
  2016-10-19  8:55   ` [PATCH 2/2] " Matthew Auld
  1 sibling, 2 replies; 10+ messages in thread
From: Zhenyu Wang @ 2016-10-19  8:54 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx


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

On 2016.10.19 09:12:28 +0100, Chris Wilson wrote:
> For whatever reason, the gvt scheduler runs synchronously. At the very
> least, lets run synchronously without holding the struct_mutex.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This will break current device model which assume to serve one VM context
on hw at each time but can't switch to another one between for emulation
issue.

This is not good but its current implementation limit we'll address later.

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 4cedd3274da7..aa83dd3381a3 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -420,10 +420,6 @@ static int workload_thread(void *priv)
>  
>  		intel_runtime_pm_get(gvt->dev_priv);
>  
> -		/*
> -		 * Always take i915 big lock first
> -		 */
> -		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  
>  		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>  				workload->ring_id, workload);
> @@ -432,7 +428,10 @@ static int workload_thread(void *priv)
>  			intel_uncore_forcewake_get(gvt->dev_priv,
>  					FORCEWAKE_ALL);
>  
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  		ret = dispatch_workload(workload);
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
> +
>  		if (ret) {
>  			gvt_err("fail to dispatch workload, skip\n");
>  			goto complete;
> @@ -442,8 +441,7 @@ static int workload_thread(void *priv)
>  				workload->ring_id, workload);
>  
>  		workload->status = i915_wait_request(workload->req,
> -						     I915_WAIT_LOCKED,
> -						     NULL, NULL);
> +						     0, NULL, NULL);
>  		if (workload->status != 0)
>  			gvt_err("fail to wait workload, skip\n");
>  
> @@ -451,13 +449,14 @@ static int workload_thread(void *priv)
>  		gvt_dbg_sched("will complete workload %p\n, status: %d\n",
>  				workload, workload->status);
>  
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  		complete_current_workload(gvt, ring_id);
> +		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>  		if (need_force_wake)
>  			intel_uncore_forcewake_put(gvt->dev_priv,
>  					FORCEWAKE_ALL);
>  
> -		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>  		intel_runtime_pm_put(gvt->dev_priv);
>  	}
> -- 
> 2.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
  2016-10-19  8:54   ` Zhenyu Wang
@ 2016-10-19  8:55   ` Matthew Auld
  1 sibling, 0 replies; 10+ messages in thread
From: Matthew Auld @ 2016-10-19  8:55 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Intel Graphics Development

On 19 October 2016 at 09:12, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> For whatever reason, the gvt scheduler runs synchronously. At the very
> least, lets run synchronously without holding the struct_mutex.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 4cedd3274da7..aa83dd3381a3 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -420,10 +420,6 @@ static int workload_thread(void *priv)
>
>                 intel_runtime_pm_get(gvt->dev_priv);
>
> -               /*
> -                * Always take i915 big lock first
> -                */
> -               mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>
>                 gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>                                 workload->ring_id, workload);
> @@ -432,7 +428,10 @@ static int workload_thread(void *priv)
>                         intel_uncore_forcewake_get(gvt->dev_priv,
>                                         FORCEWAKE_ALL);
>
> +               mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>                 ret = dispatch_workload(workload);
> +               mutex_lock(&gvt->dev_priv->drm.struct_mutex);
mutex_unlock...
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  8:54   ` Zhenyu Wang
@ 2016-10-19  9:08     ` Chris Wilson
  2016-10-19  9:14     ` [PATCH v2] " Chris Wilson
  1 sibling, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-10-19  9:08 UTC (permalink / raw)
  To: Zhenyu Wang; +Cc: intel-gfx

On Wed, Oct 19, 2016 at 04:54:28PM +0800, Zhenyu Wang wrote:
> On 2016.10.19 09:12:28 +0100, Chris Wilson wrote:
> > For whatever reason, the gvt scheduler runs synchronously. At the very
> > least, lets run synchronously without holding the struct_mutex.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> This will break current device model which assume to serve one VM context
> on hw at each time but can't switch to another one between for emulation
> issue.

That's a scheduling issue, which should not require struct_mutex. So
what is struct_mutex being used for?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  8:54   ` Zhenyu Wang
  2016-10-19  9:08     ` Chris Wilson
@ 2016-10-19  9:14     ` Chris Wilson
  2016-10-19  9:22       ` Chris Wilson
  2016-10-19  9:47       ` Zhenyu Wang
  1 sibling, 2 replies; 10+ messages in thread
From: Chris Wilson @ 2016-10-19  9:14 UTC (permalink / raw)
  To: intel-gfx

For whatever reason, the gvt scheduler runs synchronously. At the very
least, lets run synchronously without holding the struct_mutex.

v2: cut'n'paste mutex_lock instead of unlock.
Replace long hold of struct_mutex with a mutex to serialise the worker
threads.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index 4cedd3274da7..55f8ed7d7be5 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -390,6 +390,8 @@ struct workload_thread_param {
 	int ring_id;
 };
 
+static DEFINE_MUTEX(scheduler_mutex);
+
 static int workload_thread(void *priv)
 {
 	struct workload_thread_param *p = (struct workload_thread_param *)priv;
@@ -414,17 +416,14 @@ static int workload_thread(void *priv)
 		if (kthread_should_stop())
 			break;
 
+		mutex_lock(&scheduler_mutex);
+
 		gvt_dbg_sched("ring id %d next workload %p vgpu %d\n",
 				workload->ring_id, workload,
 				workload->vgpu->id);
 
 		intel_runtime_pm_get(gvt->dev_priv);
 
-		/*
-		 * Always take i915 big lock first
-		 */
-		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
-
 		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
 				workload->ring_id, workload);
 
@@ -432,7 +431,10 @@ static int workload_thread(void *priv)
 			intel_uncore_forcewake_get(gvt->dev_priv,
 					FORCEWAKE_ALL);
 
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 		ret = dispatch_workload(workload);
+		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
+
 		if (ret) {
 			gvt_err("fail to dispatch workload, skip\n");
 			goto complete;
@@ -442,8 +444,7 @@ static int workload_thread(void *priv)
 				workload->ring_id, workload);
 
 		workload->status = i915_wait_request(workload->req,
-						     I915_WAIT_LOCKED,
-						     NULL, NULL);
+						     0, NULL, NULL);
 		if (workload->status != 0)
 			gvt_err("fail to wait workload, skip\n");
 
@@ -451,15 +452,18 @@ static int workload_thread(void *priv)
 		gvt_dbg_sched("will complete workload %p\n, status: %d\n",
 				workload, workload->status);
 
+		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
 		complete_current_workload(gvt, ring_id);
+		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
 
 		if (need_force_wake)
 			intel_uncore_forcewake_put(gvt->dev_priv,
 					FORCEWAKE_ALL);
 
-		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
-
 		intel_runtime_pm_put(gvt->dev_priv);
+
+		mutex_unlock(&scheduler_mutex);
+
 	}
 	return 0;
 }
-- 
2.9.3

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

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  9:14     ` [PATCH v2] " Chris Wilson
@ 2016-10-19  9:22       ` Chris Wilson
  2016-10-19  9:47       ` Zhenyu Wang
  1 sibling, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-10-19  9:22 UTC (permalink / raw)
  To: intel-gfx

On Wed, Oct 19, 2016 at 10:14:39AM +0100, Chris Wilson wrote:
> @@ -451,15 +452,18 @@ static int workload_thread(void *priv)
>  		gvt_dbg_sched("will complete workload %p\n, status: %d\n",
>  				workload, workload->status);
>  
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  		complete_current_workload(gvt, ring_id);
> +		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);

I can't see any reason why complete_current_workload() would require
struct_mutex.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] drm/i915/gvt: Stop waiting whilst holding struct_mutex
  2016-10-19  9:14     ` [PATCH v2] " Chris Wilson
  2016-10-19  9:22       ` Chris Wilson
@ 2016-10-19  9:47       ` Zhenyu Wang
  1 sibling, 0 replies; 10+ messages in thread
From: Zhenyu Wang @ 2016-10-19  9:47 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx


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

On 2016.10.19 10:14:39 +0100, Chris Wilson wrote:
> For whatever reason, the gvt scheduler runs synchronously. At the very
> least, lets run synchronously without holding the struct_mutex.
> 
> v2: cut'n'paste mutex_lock instead of unlock.
> Replace long hold of struct_mutex with a mutex to serialise the worker
> threads.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This looks ok to me, but let me test it with VM first to ensure
the behavior is expected.

Thanks

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 4cedd3274da7..55f8ed7d7be5 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -390,6 +390,8 @@ struct workload_thread_param {
>  	int ring_id;
>  };
>  
> +static DEFINE_MUTEX(scheduler_mutex);
> +
>  static int workload_thread(void *priv)
>  {
>  	struct workload_thread_param *p = (struct workload_thread_param *)priv;
> @@ -414,17 +416,14 @@ static int workload_thread(void *priv)
>  		if (kthread_should_stop())
>  			break;
>  
> +		mutex_lock(&scheduler_mutex);
> +
>  		gvt_dbg_sched("ring id %d next workload %p vgpu %d\n",
>  				workload->ring_id, workload,
>  				workload->vgpu->id);
>  
>  		intel_runtime_pm_get(gvt->dev_priv);
>  
> -		/*
> -		 * Always take i915 big lock first
> -		 */
> -		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
> -
>  		gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>  				workload->ring_id, workload);
>  
> @@ -432,7 +431,10 @@ static int workload_thread(void *priv)
>  			intel_uncore_forcewake_get(gvt->dev_priv,
>  					FORCEWAKE_ALL);
>  
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  		ret = dispatch_workload(workload);
> +		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
> +
>  		if (ret) {
>  			gvt_err("fail to dispatch workload, skip\n");
>  			goto complete;
> @@ -442,8 +444,7 @@ static int workload_thread(void *priv)
>  				workload->ring_id, workload);
>  
>  		workload->status = i915_wait_request(workload->req,
> -						     I915_WAIT_LOCKED,
> -						     NULL, NULL);
> +						     0, NULL, NULL);
>  		if (workload->status != 0)
>  			gvt_err("fail to wait workload, skip\n");
>  
> @@ -451,15 +452,18 @@ static int workload_thread(void *priv)
>  		gvt_dbg_sched("will complete workload %p\n, status: %d\n",
>  				workload, workload->status);
>  
> +		mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  		complete_current_workload(gvt, ring_id);
> +		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>  		if (need_force_wake)
>  			intel_uncore_forcewake_put(gvt->dev_priv,
>  					FORCEWAKE_ALL);
>  
> -		mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
> -
>  		intel_runtime_pm_put(gvt->dev_priv);
> +
> +		mutex_unlock(&scheduler_mutex);
> +
>  	}
>  	return 0;
>  }
> -- 
> 2.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2)
  2016-10-19  8:12 [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Chris Wilson
  2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
  2016-10-19  8:50 ` [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Zhenyu Wang
@ 2016-10-19 11:01 ` Patchwork
  2 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2016-10-19 11:01 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2)
URL   : https://patchwork.freedesktop.org/series/14004/
State : failure

== Summary ==

Series 14004v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14004/revisions/2/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                pass       -> INCOMPLETE (fi-snb-2520m)
                incomplete -> PASS       (fi-snb-2600)
        Subgroup suspend-read-crc-pipe-c:
                incomplete -> PASS       (fi-skl-6770hq)

fi-bdw-5557u     total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700     total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900     total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820     total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770      total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r     total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650       total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m     total:186  pass:164  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770      total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u     total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u     total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hq    total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k     total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hq    total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m     total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600      total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2754/

8bbf308ef2835c2b631f339d9d9d26e817934c84 drm-intel-nightly: 2016y-10m-19d-07h-44m-01s UTC integration manifest
74f5ac5 drm/i915/gvt: Stop waiting whilst holding struct_mutex
0346400 drm/i915/gvt: Stop checking for impossible interrupts from a kthread

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-10-19 11:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-19  8:12 [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Chris Wilson
2016-10-19  8:12 ` [PATCH 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex Chris Wilson
2016-10-19  8:54   ` Zhenyu Wang
2016-10-19  9:08     ` Chris Wilson
2016-10-19  9:14     ` [PATCH v2] " Chris Wilson
2016-10-19  9:22       ` Chris Wilson
2016-10-19  9:47       ` Zhenyu Wang
2016-10-19  8:55   ` [PATCH 2/2] " Matthew Auld
2016-10-19  8:50 ` [PATCH 1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread Zhenyu Wang
2016-10-19 11:01 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2) Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox