All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] drm/i915: fix SFC reset flow
@ 2019-09-19  1:53 Daniele Ceraolo Spurio
  2019-09-19  3:49 ` ✓ Fi.CI.BAT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Daniele Ceraolo Spurio @ 2019-09-19  1:53 UTC (permalink / raw)
  To: intel-gfx; +Cc: Owen Zhang

Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.

Also, failing to get the ack while the SFC is in use means that we can't
cleanly reset it, so fail the engine reset in that scenario.

v2: drop rmw change, keep the log as debug and handle failure (Chris),
    improve comments (Tvrtko).

Reported-by: Owen Zhang <owen.zhang@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gt/intel_reset.c | 51 +++++++++++++++++----------
 1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
index 8327220ac558..797cf50625cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
 	return gen6_hw_domain_reset(gt, hw_mask);
 }
 
-static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
+static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
 {
 	struct intel_uncore *uncore = engine->uncore;
 	u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
@@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
 	i915_reg_t sfc_usage;
 	u32 sfc_usage_bit;
 	u32 sfc_reset_bit;
+	int ret;
 
 	switch (engine->class) {
 	case VIDEO_DECODE_CLASS:
@@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
 	}
 
 	/*
-	 * Tell the engine that a software reset is going to happen. The engine
-	 * will then try to force lock the SFC (if currently locked, it will
-	 * remain so until we tell the engine it is safe to unlock; if currently
-	 * unlocked, it will ignore this and all new lock requests). If SFC
-	 * ends up being locked to the engine we want to reset, we have to reset
-	 * it as well (we will unlock it once the reset sequence is completed).
+	 * If the engine is using a SFC, tell the engine that a software reset
+	 * is going to happen. The engine will then try to force lock the SFC.
+	 * If SFC ends up being locked to the engine we want to reset, we have
+	 * to reset it as well (we will unlock it once the reset sequence is
+	 * completed).
 	 */
+	if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
+		return 0;
+
 	rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
 
-	if (__intel_wait_for_register_fw(uncore,
-					 sfc_forced_lock_ack,
-					 sfc_forced_lock_ack_bit,
-					 sfc_forced_lock_ack_bit,
-					 1000, 0, NULL)) {
-		DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+	ret = __intel_wait_for_register_fw(uncore,
+					   sfc_forced_lock_ack,
+					   sfc_forced_lock_ack_bit,
+					   sfc_forced_lock_ack_bit,
+					   1000, 0, NULL);
+
+	/* was the SFC released while we were trying to lock it? */
+	if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
 		return 0;
-	}
 
-	if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
-		return sfc_reset_bit;
+	if (ret)
+		DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+	else
+		*hw_mask |= sfc_reset_bit;
 
-	return 0;
+	return ret;
 }
 
 static void gen11_unlock_sfc(struct intel_engine_cs *engine)
@@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
 		for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
 			GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
 			hw_mask |= hw_engine_mask[engine->id];
-			hw_mask |= gen11_lock_sfc(engine);
+			ret = gen11_lock_sfc(engine, &hw_mask);
+			if (ret)
+				goto sfc_unlock;
 		}
 	}
 
 	ret = gen6_hw_domain_reset(gt, hw_mask);
 
+sfc_unlock:
+	/*
+	 * we unlock the SFC based on the lock status and not the result of
+	 * gen11_lock_sfc to make sure that we clean properly if something
+	 * wrong happened during the lock (e.g. lock acquired after timeout
+	 * expiration).
+	 */
 	if (engine_mask != ALL_ENGINES)
 		for_each_engine_masked(engine, gt->i915, engine_mask, tmp)
 			gen11_unlock_sfc(engine);
-- 
2.23.0

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

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

* ✓ Fi.CI.BAT: success for drm/i915: fix SFC reset flow (rev2)
  2019-09-19  1:53 [PATCH v2] drm/i915: fix SFC reset flow Daniele Ceraolo Spurio
@ 2019-09-19  3:49 ` Patchwork
  2019-09-19  7:51 ` [PATCH v2] drm/i915: fix SFC reset flow Chris Wilson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2019-09-19  3:49 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: fix SFC reset flow (rev2)
URL   : https://patchwork.freedesktop.org/series/66779/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6917 -> Patchwork_14451
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_frontbuffer_tracking@basic:
    - fi-icl-u3:          [PASS][1] -> [FAIL][2] ([fdo#103167])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html

  
#### Possible fixes ####

  * igt@gem_mmap_gtt@basic-write-no-prefault:
    - fi-icl-u3:          [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@gem_mmap_gtt@basic-write-no-prefault.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/fi-icl-u3/igt@gem_mmap_gtt@basic-write-no-prefault.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111155]: https://bugs.freedesktop.org/show_bug.cgi?id=111155


Participating hosts (53 -> 46)
------------------------------

  Additional (1): fi-bxt-dsi 
  Missing    (8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6917 -> Patchwork_14451

  CI-20190529: 20190529
  CI_DRM_6917: 7ca2b123ae999133223b882e3190955897df8b03 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5191: 63e30122cadaf2798ae2bd44a56cee81a27fbc40 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14451: 51f9319e1febce4967a1446d7947dea41a01f7ec @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

51f9319e1feb drm/i915: fix SFC reset flow

== Logs ==

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

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

* Re: [PATCH v2] drm/i915: fix SFC reset flow
  2019-09-19  1:53 [PATCH v2] drm/i915: fix SFC reset flow Daniele Ceraolo Spurio
  2019-09-19  3:49 ` ✓ Fi.CI.BAT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
@ 2019-09-19  7:51 ` Chris Wilson
  2019-09-19  9:34 ` Tvrtko Ursulin
  2019-09-19 14:40 ` ✓ Fi.CI.IGT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
  3 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2019-09-19  7:51 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, intel-gfx; +Cc: Owen Zhang

Quoting Daniele Ceraolo Spurio (2019-09-19 02:53:30)
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that the behavior is undefined; on ICL the HW
> ends up to returning the ack and ignoring our lock request, but this is
> not guaranteed and we shouldn't expect it going forward.
> 
> Also, failing to get the ack while the SFC is in use means that we can't
> cleanly reset it, so fail the engine reset in that scenario.
> 
> v2: drop rmw change, keep the log as debug and handle failure (Chris),
>     improve comments (Tvrtko).
> 
> Reported-by: Owen Zhang <owen.zhang@intel.com>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/gt/intel_reset.c | 51 +++++++++++++++++----------
>  1 file changed, 33 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 8327220ac558..797cf50625cb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
>         return gen6_hw_domain_reset(gt, hw_mask);
>  }
>  
> -static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
> +static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
>  {
>         struct intel_uncore *uncore = engine->uncore;
>         u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
> @@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
>         i915_reg_t sfc_usage;
>         u32 sfc_usage_bit;
>         u32 sfc_reset_bit;
> +       int ret;
>  
>         switch (engine->class) {
>         case VIDEO_DECODE_CLASS:
> @@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
>         }
>  
>         /*
> -        * Tell the engine that a software reset is going to happen. The engine
> -        * will then try to force lock the SFC (if currently locked, it will
> -        * remain so until we tell the engine it is safe to unlock; if currently
> -        * unlocked, it will ignore this and all new lock requests). If SFC
> -        * ends up being locked to the engine we want to reset, we have to reset
> -        * it as well (we will unlock it once the reset sequence is completed).
> +        * If the engine is using a SFC, tell the engine that a software reset
> +        * is going to happen. The engine will then try to force lock the SFC.
> +        * If SFC ends up being locked to the engine we want to reset, we have
> +        * to reset it as well (we will unlock it once the reset sequence is
> +        * completed).
>          */
> +       if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
> +               return 0;
> +
>         rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
>  
> -       if (__intel_wait_for_register_fw(uncore,
> -                                        sfc_forced_lock_ack,
> -                                        sfc_forced_lock_ack_bit,
> -                                        sfc_forced_lock_ack_bit,
> -                                        1000, 0, NULL)) {
> -               DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
> +       ret = __intel_wait_for_register_fw(uncore,
> +                                          sfc_forced_lock_ack,
> +                                          sfc_forced_lock_ack_bit,
> +                                          sfc_forced_lock_ack_bit,
> +                                          1000, 0, NULL);
> +
> +       /* was the SFC released while we were trying to lock it? */
> +       if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
>                 return 0;
> -       }
>  
> -       if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
> -               return sfc_reset_bit;
> +       if (ret)
> +               DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");

This unnerves me as on the lock_sfc it would result in lots of full-gpu
resets. However, I do believe that we catch those fallbacks in our
selftests -- so the tests that were triggering the wait timeout must be
taking the earlier return for sfc_usage == 0

Not having per-engine reset is greatly upsetting; we are baking the
assumption we can reset engines & contexts independently into our system
management. We rely on it...

However, this passed on icl so it can't be all bad!
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v2] drm/i915: fix SFC reset flow
  2019-09-19  1:53 [PATCH v2] drm/i915: fix SFC reset flow Daniele Ceraolo Spurio
  2019-09-19  3:49 ` ✓ Fi.CI.BAT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
  2019-09-19  7:51 ` [PATCH v2] drm/i915: fix SFC reset flow Chris Wilson
@ 2019-09-19  9:34 ` Tvrtko Ursulin
  2019-09-19  9:48   ` Chris Wilson
  2019-09-19  9:58   ` Tvrtko Ursulin
  2019-09-19 14:40 ` ✓ Fi.CI.IGT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
  3 siblings, 2 replies; 7+ messages in thread
From: Tvrtko Ursulin @ 2019-09-19  9:34 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, intel-gfx; +Cc: Owen Zhang


On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that the behavior is undefined; on ICL the HW
> ends up to returning the ack and ignoring our lock request, but this is
> not guaranteed and we shouldn't expect it going forward.
> 
> Also, failing to get the ack while the SFC is in use means that we can't
> cleanly reset it, so fail the engine reset in that scenario.
> 
> v2: drop rmw change, keep the log as debug and handle failure (Chris),
>      improve comments (Tvrtko).
> 
> Reported-by: Owen Zhang <owen.zhang@intel.com>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/gt/intel_reset.c | 51 +++++++++++++++++----------
>   1 file changed, 33 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 8327220ac558..797cf50625cb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
>   	return gen6_hw_domain_reset(gt, hw_mask);
>   }
>   
> -static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
> +static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
>   {
>   	struct intel_uncore *uncore = engine->uncore;
>   	u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
> @@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
>   	i915_reg_t sfc_usage;
>   	u32 sfc_usage_bit;
>   	u32 sfc_reset_bit;
> +	int ret;
>   
>   	switch (engine->class) {
>   	case VIDEO_DECODE_CLASS:
> @@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
>   	}
>   
>   	/*
> -	 * Tell the engine that a software reset is going to happen. The engine
> -	 * will then try to force lock the SFC (if currently locked, it will
> -	 * remain so until we tell the engine it is safe to unlock; if currently
> -	 * unlocked, it will ignore this and all new lock requests). If SFC
> -	 * ends up being locked to the engine we want to reset, we have to reset
> -	 * it as well (we will unlock it once the reset sequence is completed).
> +	 * If the engine is using a SFC, tell the engine that a software reset
> +	 * is going to happen. The engine will then try to force lock the SFC.
> +	 * If SFC ends up being locked to the engine we want to reset, we have
> +	 * to reset it as well (we will unlock it once the reset sequence is
> +	 * completed).
>   	 */
> +	if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
> +		return 0;
> +
>   	rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
>   
> -	if (__intel_wait_for_register_fw(uncore,
> -					 sfc_forced_lock_ack,
> -					 sfc_forced_lock_ack_bit,
> -					 sfc_forced_lock_ack_bit,
> -					 1000, 0, NULL)) {
> -		DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
> +	ret = __intel_wait_for_register_fw(uncore,
> +					   sfc_forced_lock_ack,
> +					   sfc_forced_lock_ack_bit,
> +					   sfc_forced_lock_ack_bit,
> +					   1000, 0, NULL);
> +
> +	/* was the SFC released while we were trying to lock it? */
> +	if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
>   		return 0;
> -	}
>   
> -	if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
> -		return sfc_reset_bit;
> +	if (ret)
> +		DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
> +	else
> +		*hw_mask |= sfc_reset_bit;
>   
> -	return 0;
> +	return ret;
>   }
>   
>   static void gen11_unlock_sfc(struct intel_engine_cs *engine)
> @@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
>   		for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
>   			GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
>   			hw_mask |= hw_engine_mask[engine->id];
> -			hw_mask |= gen11_lock_sfc(engine);
> +			ret = gen11_lock_sfc(engine, &hw_mask);
> +			if (ret)
> +				goto sfc_unlock;

Break on first failure looks unsafe to me. I think it would be more 
robust to continue, no? Like if we have been asked to reset multiple 
engines and only one failed, why not do the ones we can?

>   		}
>   	}
>   
>   	ret = gen6_hw_domain_reset(gt, hw_mask);
>   
> +sfc_unlock:
> +	/*
> +	 * we unlock the SFC based on the lock status and not the result of
> +	 * gen11_lock_sfc to make sure that we clean properly if something
> +	 * wrong happened during the lock (e.g. lock acquired after timeout
> +	 * expiration).
> +	 */
>   	if (engine_mask != ALL_ENGINES)
>   		for_each_engine_masked(engine, gt->i915, engine_mask, tmp)
>   			gen11_unlock_sfc(engine);
> 

So you decided not to read the register and cross check?

Regards,

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

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

* Re: [PATCH v2] drm/i915: fix SFC reset flow
  2019-09-19  9:34 ` Tvrtko Ursulin
@ 2019-09-19  9:48   ` Chris Wilson
  2019-09-19  9:58   ` Tvrtko Ursulin
  1 sibling, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2019-09-19  9:48 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, Tvrtko Ursulin, intel-gfx; +Cc: Owen Zhang

Quoting Tvrtko Ursulin (2019-09-19 10:34:15)
> 
> On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
> > Our assumption that the we can ask the HW to lock the SFC even if not
> > currently in use does not match the HW commitment. The expectation from
> > the HW is that SW will not try to lock the SFC if the engine is not
> > using it and if we do that the behavior is undefined; on ICL the HW
> > ends up to returning the ack and ignoring our lock request, but this is
> > not guaranteed and we shouldn't expect it going forward.
> > 
> > Also, failing to get the ack while the SFC is in use means that we can't
> > cleanly reset it, so fail the engine reset in that scenario.
> > 
> > v2: drop rmw change, keep the log as debug and handle failure (Chris),
> >      improve comments (Tvrtko).
> > 
> > Reported-by: Owen Zhang <owen.zhang@intel.com>
> > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >   static void gen11_unlock_sfc(struct intel_engine_cs *engine)
> > @@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
> >               for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
> >                       GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
> >                       hw_mask |= hw_engine_mask[engine->id];
> > -                     hw_mask |= gen11_lock_sfc(engine);
> > +                     ret = gen11_lock_sfc(engine, &hw_mask);
> > +                     if (ret)
> > +                             goto sfc_unlock;
> 
> Break on first failure looks unsafe to me. I think it would be more 
> robust to continue, no? Like if we have been asked to reset multiple 
> engines and only one failed, why not do the ones we can?

Any failure means a fallback to a full device reset. It doesn't matter
if we could reset one of two+ engines at that point, it's past the point
of no return.

> >       ret = gen6_hw_domain_reset(gt, hw_mask);
> >   
> > +sfc_unlock:
> > +     /*
> > +      * we unlock the SFC based on the lock status and not the result of
> > +      * gen11_lock_sfc to make sure that we clean properly if something
> > +      * wrong happened during the lock (e.g. lock acquired after timeout
> > +      * expiration).
> > +      */
> >       if (engine_mask != ALL_ENGINES)
> >               for_each_engine_masked(engine, gt->i915, engine_mask, tmp)
> >                       gen11_unlock_sfc(engine);
> > 
> 
> So you decided not to read the register and cross check?

Very meh, that check didn't seem like it would improve our ability to
handle resets. If you wanted to actually check, we should check the
lock_ack_bit is cleared as well. (Or at least check that is clear before
we start the next lock_sfc().) I think skipping an unnecessary
gen11_lock_sfc() is a solid improvement by itself (I'm hopeful that's
enough to make icl more robust...). Tightening up the unlock can be done
separately.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v2] drm/i915: fix SFC reset flow
  2019-09-19  9:34 ` Tvrtko Ursulin
  2019-09-19  9:48   ` Chris Wilson
@ 2019-09-19  9:58   ` Tvrtko Ursulin
  1 sibling, 0 replies; 7+ messages in thread
From: Tvrtko Ursulin @ 2019-09-19  9:58 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, intel-gfx; +Cc: Owen Zhang


On 19/09/2019 10:34, Tvrtko Ursulin wrote:
> 
> On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
>> Our assumption that the we can ask the HW to lock the SFC even if not
>> currently in use does not match the HW commitment. The expectation from
>> the HW is that SW will not try to lock the SFC if the engine is not
>> using it and if we do that the behavior is undefined; on ICL the HW
>> ends up to returning the ack and ignoring our lock request, but this is
>> not guaranteed and we shouldn't expect it going forward.
>>
>> Also, failing to get the ack while the SFC is in use means that we can't
>> cleanly reset it, so fail the engine reset in that scenario.
>>
>> v2: drop rmw change, keep the log as debug and handle failure (Chris),
>>      improve comments (Tvrtko).
>>
>> Reported-by: Owen Zhang <owen.zhang@intel.com>
>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>>   drivers/gpu/drm/i915/gt/intel_reset.c | 51 +++++++++++++++++----------
>>   1 file changed, 33 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
>> b/drivers/gpu/drm/i915/gt/intel_reset.c
>> index 8327220ac558..797cf50625cb 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
>> @@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
>>       return gen6_hw_domain_reset(gt, hw_mask);
>>   }
>> -static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
>> +static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
>>   {
>>       struct intel_uncore *uncore = engine->uncore;
>>       u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
>> @@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs 
>> *engine)
>>       i915_reg_t sfc_usage;
>>       u32 sfc_usage_bit;
>>       u32 sfc_reset_bit;
>> +    int ret;
>>       switch (engine->class) {
>>       case VIDEO_DECODE_CLASS:
>> @@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs 
>> *engine)
>>       }
>>       /*
>> -     * Tell the engine that a software reset is going to happen. The 
>> engine
>> -     * will then try to force lock the SFC (if currently locked, it will
>> -     * remain so until we tell the engine it is safe to unlock; if 
>> currently
>> -     * unlocked, it will ignore this and all new lock requests). If SFC
>> -     * ends up being locked to the engine we want to reset, we have 
>> to reset
>> -     * it as well (we will unlock it once the reset sequence is 
>> completed).
>> +     * If the engine is using a SFC, tell the engine that a software 
>> reset
>> +     * is going to happen. The engine will then try to force lock the 
>> SFC.
>> +     * If SFC ends up being locked to the engine we want to reset, we 
>> have
>> +     * to reset it as well (we will unlock it once the reset sequence is
>> +     * completed).
>>        */
>> +    if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
>> +        return 0;
>> +
>>       rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
>> -    if (__intel_wait_for_register_fw(uncore,
>> -                     sfc_forced_lock_ack,
>> -                     sfc_forced_lock_ack_bit,
>> -                     sfc_forced_lock_ack_bit,
>> -                     1000, 0, NULL)) {
>> -        DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
>> +    ret = __intel_wait_for_register_fw(uncore,
>> +                       sfc_forced_lock_ack,
>> +                       sfc_forced_lock_ack_bit,
>> +                       sfc_forced_lock_ack_bit,
>> +                       1000, 0, NULL);
>> +
>> +    /* was the SFC released while we were trying to lock it? */
>> +    if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
>>           return 0;
>> -    }
>> -    if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
>> -        return sfc_reset_bit;
>> +    if (ret)
>> +        DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
>> +    else
>> +        *hw_mask |= sfc_reset_bit;
>> -    return 0;
>> +    return ret;
>>   }
>>   static void gen11_unlock_sfc(struct intel_engine_cs *engine)
>> @@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
>>           for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
>>               GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
>>               hw_mask |= hw_engine_mask[engine->id];
>> -            hw_mask |= gen11_lock_sfc(engine);
>> +            ret = gen11_lock_sfc(engine, &hw_mask);
>> +            if (ret)
>> +                goto sfc_unlock;
> 
> Break on first failure looks unsafe to me. I think it would be more 
> robust to continue, no? Like if we have been asked to reset multiple 
> engines and only one failed, why not do the ones we can?

Chris corrected me on IRC explaining that as longs as we fail to reset 
one engine from engine_mask we fall back to full reset anyway. So this 
early return is immaterial to end behavior and I have no further 
complaints. :)

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

Regards,

Tvrtko

> 
>>           }
>>       }
>>       ret = gen6_hw_domain_reset(gt, hw_mask);
>> +sfc_unlock:
>> +    /*
>> +     * we unlock the SFC based on the lock status and not the result of
>> +     * gen11_lock_sfc to make sure that we clean properly if something
>> +     * wrong happened during the lock (e.g. lock acquired after timeout
>> +     * expiration).
>> +     */
>>       if (engine_mask != ALL_ENGINES)
>>           for_each_engine_masked(engine, gt->i915, engine_mask, tmp)
>>               gen11_unlock_sfc(engine);
>>
> 
> So you decided not to read the register and cross check?
> 
> Regards,
> 
> Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✓ Fi.CI.IGT: success for drm/i915: fix SFC reset flow (rev2)
  2019-09-19  1:53 [PATCH v2] drm/i915: fix SFC reset flow Daniele Ceraolo Spurio
                   ` (2 preceding siblings ...)
  2019-09-19  9:34 ` Tvrtko Ursulin
@ 2019-09-19 14:40 ` Patchwork
  3 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2019-09-19 14:40 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: fix SFC reset flow (rev2)
URL   : https://patchwork.freedesktop.org/series/66779/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14451_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_balancer@nop:
    - shard-apl:          [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl7/igt@gem_exec_balancer@nop.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl4/igt@gem_exec_balancer@nop.html

  * igt@gem_exec_schedule@preempt-bsd:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#111325]) +5 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb8/igt@gem_exec_schedule@preempt-bsd.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb1/igt@gem_exec_schedule@preempt-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#109276]) +14 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb1/igt@gem_exec_schedule@preempt-queue-bsd1.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb3/igt@gem_exec_schedule@preempt-queue-bsd1.html

  * igt@gem_workarounds@suspend-resume-fd:
    - shard-skl:          [PASS][7] -> [INCOMPLETE][8] ([fdo#104108])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@gem_workarounds@suspend-resume-fd.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl1/igt@gem_workarounds@suspend-resume-fd.html

  * igt@i915_pm_rpm@system-suspend-modeset:
    - shard-skl:          [PASS][9] -> [INCOMPLETE][10] ([fdo#104108] / [fdo#107807])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl8/igt@i915_pm_rpm@system-suspend-modeset.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl10/igt@i915_pm_rpm@system-suspend-modeset.html

  * igt@i915_selftest@mock_fence:
    - shard-iclb:         [PASS][11] -> [INCOMPLETE][12] ([fdo#107713])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@i915_selftest@mock_fence.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb7/igt@i915_selftest@mock_fence.html

  * igt@kms_cursor_legacy@cursor-vs-flip-legacy:
    - shard-hsw:          [PASS][13] -> [FAIL][14] ([fdo#103355])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw8/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-hsw6/igt@kms_cursor_legacy@cursor-vs-flip-legacy.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-skl:          [PASS][15] -> [INCOMPLETE][16] ([fdo#109507])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl7/igt@kms_flip@flip-vs-suspend.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl1/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-apl:          [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +6 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl8/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_psr@psr2_basic:
    - shard-iclb:         [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_basic.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb3/igt@kms_psr@psr2_basic.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-apl:          [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@gem_ctx_isolation@rcs0-s3.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl4/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [SKIP][25] ([fdo#111325]) -> [PASS][26] +5 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb7/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_mmap_gtt@hang:
    - shard-iclb:         [FAIL][27] ([fdo#109677]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb1/igt@gem_mmap_gtt@hang.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb8/igt@gem_mmap_gtt@hang.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][29] ([fdo#104108]) -> [PASS][30] +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl10/igt@gem_softpin@noreloc-s3.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl6/igt@gem_softpin@noreloc-s3.html

  * igt@kms_atomic_interruptible@atomic-setmode:
    - shard-apl:          [INCOMPLETE][31] ([fdo#103927]) -> [PASS][32] +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl6/igt@kms_atomic_interruptible@atomic-setmode.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl3/igt@kms_atomic_interruptible@atomic-setmode.html

  * igt@kms_flip@flip-vs-modeset-interruptible:
    - shard-iclb:         [INCOMPLETE][33] ([fdo#107713]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb7/igt@kms_flip@flip-vs-modeset-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb7/igt@kms_flip@flip-vs-modeset-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
    - shard-iclb:         [FAIL][35] ([fdo#103167]) -> [PASS][36] +3 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt:
    - shard-iclb:         [INCOMPLETE][37] ([fdo#106978] / [fdo#107713]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb7/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb5/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [FAIL][39] ([fdo#108145]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [SKIP][41] ([fdo#109642] / [fdo#111068]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_psr2_su@frontbuffer.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][43] ([fdo#109441]) -> [PASS][44] +1 similar issue
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_psr@psr2_cursor_blt.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  * igt@prime_busy@hang-bsd2:
    - shard-iclb:         [SKIP][45] ([fdo#109276]) -> [PASS][46] +14 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@prime_busy@hang-bsd2.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@prime_busy@hang-bsd2.html

  * igt@tools_test@tools_test:
    - shard-skl:          [SKIP][47] ([fdo#109271]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl3/igt@tools_test@tools_test.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl3/igt@tools_test@tools_test.html

  
#### Warnings ####

  * igt@gem_mocs_settings@mocs-reset-bsd2:
    - shard-iclb:         [SKIP][49] ([fdo#109276]) -> [FAIL][50] ([fdo#111330]) +3 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb6/igt@gem_mocs_settings@mocs-reset-bsd2.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb4/igt@gem_mocs_settings@mocs-reset-bsd2.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#109677]: https://bugs.freedesktop.org/show_bug.cgi?id=109677
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6917 -> Patchwork_14451

  CI-20190529: 20190529
  CI_DRM_6917: 7ca2b123ae999133223b882e3190955897df8b03 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5191: 63e30122cadaf2798ae2bd44a56cee81a27fbc40 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14451: 51f9319e1febce4967a1446d7947dea41a01f7ec @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

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

end of thread, other threads:[~2019-09-19 14:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-19  1:53 [PATCH v2] drm/i915: fix SFC reset flow Daniele Ceraolo Spurio
2019-09-19  3:49 ` ✓ Fi.CI.BAT: success for drm/i915: fix SFC reset flow (rev2) Patchwork
2019-09-19  7:51 ` [PATCH v2] drm/i915: fix SFC reset flow Chris Wilson
2019-09-19  9:34 ` Tvrtko Ursulin
2019-09-19  9:48   ` Chris Wilson
2019-09-19  9:58   ` Tvrtko Ursulin
2019-09-19 14:40 ` ✓ Fi.CI.IGT: success for drm/i915: fix SFC reset flow (rev2) Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.