All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915/uc: don't enable communication twice on resume
@ 2019-07-29 22:28 Daniele Ceraolo Spurio
  2019-07-30  0:41 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Daniele Ceraolo Spurio @ 2019-07-29 22:28 UTC (permalink / raw)
  To: intel-gfx

When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index fafa9be1e12a..34706a753793 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc *guc)
 	guc->interrupts.disable(guc);
 }
 
+static bool guc_communication_enabled(struct intel_guc *guc)
+{
+	return guc->send != intel_guc_send_nop;
+}
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
 	struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
 	int ret;
 
+	GEM_BUG_ON(guc_communication_enabled(guc));
+
 	ret = intel_guc_ct_enable(&guc->ct);
 	if (ret)
 		return ret;
@@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
 	if (!intel_guc_is_running(guc))
 		return 0;
 
-	guc_enable_communication(guc);
+	/*
+	 * When coming out of S3/S4 we sanitize and re-init the HW, so
+	 * communication is already re-enabled at this point and we just need
+	 * to tell GuC to reload its internal state. During runtime resume we
+	 * instead want to re-init everything.
+	 */
+	if (!guc_communication_enabled(guc))
+		guc_enable_communication(guc);
 
 	err = intel_guc_resume(guc);
 	if (err) {
-- 
2.22.0

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

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

* ✓ Fi.CI.BAT: success for drm/i915/uc: don't enable communication twice on resume
  2019-07-29 22:28 [PATCH] drm/i915/uc: don't enable communication twice on resume Daniele Ceraolo Spurio
@ 2019-07-30  0:41 ` Patchwork
  2019-07-30  8:14 ` [PATCH] " Chris Wilson
  2019-07-30 11:25 ` ✓ Fi.CI.IGT: success for " Patchwork
  2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-07-30  0:41 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/uc: don't enable communication twice on resume
URL   : https://patchwork.freedesktop.org/series/64405/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6576 -> Patchwork_13792
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
    - fi-skl-6770hq:      [PASS][3] -> [FAIL][4] ([fdo#108511])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [PASS][5] -> [DMESG-WARN][6] ([fdo#102614])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
    - fi-icl-u2:          [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html

  
#### Possible fixes ####

  * igt@kms_busy@basic-flip-a:
    - fi-kbl-7567u:       [SKIP][9] ([fdo#109271] / [fdo#109278]) -> [PASS][10] +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-icl-u2:          [FAIL][11] ([fdo#109483]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483


Participating hosts (51 -> 46)
------------------------------

  Missing    (5): fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6576 -> Patchwork_13792

  CI-20190529: 20190529
  CI_DRM_6576: 4040b4c4ab647422d82100c8b091d34b6a82f572 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5115: 21be7a02ac8a8ff46b561c36a69e4dd5a0c2938b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13792: a40d51fbdceddd801f6357c6f76051f15c3fb273 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a40d51fbdced drm/i915/uc: don't enable communication twice on resume

== Logs ==

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

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

* Re: [PATCH] drm/i915/uc: don't enable communication twice on resume
  2019-07-29 22:28 [PATCH] drm/i915/uc: don't enable communication twice on resume Daniele Ceraolo Spurio
  2019-07-30  0:41 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2019-07-30  8:14 ` Chris Wilson
  2019-07-30 16:05   ` Daniele Ceraolo Spurio
  2019-07-30 11:25 ` ✓ Fi.CI.IGT: success for " Patchwork
  2 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2019-07-30  8:14 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, intel-gfx

Quoting Daniele Ceraolo Spurio (2019-07-29 23:28:00)
> When coming out of S3/S4 we sanitize and re-init the HW, which includes
> enabling communication during uc_init_hw. We therefore don't want to do
> that again in uc_resume and can just tell GuC to reload its state.
> 
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index fafa9be1e12a..34706a753793 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc *guc)
>         guc->interrupts.disable(guc);
>  }
>  
> +static bool guc_communication_enabled(struct intel_guc *guc)
> +{
> +       return guc->send != intel_guc_send_nop;
> +}
> +
>  static int guc_enable_communication(struct intel_guc *guc)
>  {
>         struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>         int ret;
>  
> +       GEM_BUG_ON(guc_communication_enabled(guc));
> +
>         ret = intel_guc_ct_enable(&guc->ct);
>         if (ret)
>                 return ret;
> @@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
>         if (!intel_guc_is_running(guc))
>                 return 0;
>  
> -       guc_enable_communication(guc);
> +       /*
> +        * When coming out of S3/S4 we sanitize and re-init the HW, so
> +        * communication is already re-enabled at this point and we just need
> +        * to tell GuC to reload its internal state. During runtime resume we
> +        * instead want to re-init everything.
> +        */
> +       if (!guc_communication_enabled(guc))
> +               guc_enable_communication(guc);

We distinguish runtime_suspend from suspend, but not runtime_resume from
resume. Is that distinction worthwhile, could we use it be more strict
over the expected state?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✓ Fi.CI.IGT: success for drm/i915/uc: don't enable communication twice on resume
  2019-07-29 22:28 [PATCH] drm/i915/uc: don't enable communication twice on resume Daniele Ceraolo Spurio
  2019-07-30  0:41 ` ✓ Fi.CI.BAT: success for " Patchwork
  2019-07-30  8:14 ` [PATCH] " Chris Wilson
@ 2019-07-30 11:25 ` Patchwork
  2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-07-30 11:25 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/uc: don't enable communication twice on resume
URL   : https://patchwork.freedesktop.org/series/64405/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6576_full -> Patchwork_13792_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@vecs0-s3:
    - shard-kbl:          [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-kbl1/igt@gem_ctx_isolation@vecs0-s3.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-kbl6/igt@gem_ctx_isolation@vecs0-s3.html

  * igt@gem_pwrite@big-cpu-fbr:
    - shard-kbl:          [PASS][3] -> [INCOMPLETE][4] ([fdo#103665])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-kbl2/igt@gem_pwrite@big-cpu-fbr.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-kbl2/igt@gem_pwrite@big-cpu-fbr.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled:
    - shard-skl:          [PASS][5] -> [FAIL][6] ([fdo#103184] / [fdo#103232])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl4/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl7/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [PASS][9] -> [FAIL][10] ([fdo#103167]) +5 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
    - shard-skl:          [PASS][11] -> [INCOMPLETE][12] ([fdo#104108]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl9/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [PASS][13] -> [FAIL][14] ([fdo#108145])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [PASS][15] -> [SKIP][16] ([fdo#109642] / [fdo#111068])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb7/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109441])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@perf@polling:
    - shard-skl:          [PASS][19] -> [FAIL][20] ([fdo#110728])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl2/igt@perf@polling.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl8/igt@perf@polling.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +10 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-kbl3/igt@gem_ctx_isolation@rcs0-s3.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-kbl3/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [SKIP][23] ([fdo#110854]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb6/igt@gem_exec_balancer@smoke.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb1/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_suspend@basic-s3:
    - shard-snb:          [DMESG-WARN][25] ([fdo#110684] / [fdo#111115]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-snb6/igt@gem_exec_suspend@basic-s3.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-snb4/igt@gem_exec_suspend@basic-s3.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-snb:          [SKIP][27] ([fdo#109271]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-snb7/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-snb7/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-skl:          [INCOMPLETE][29] ([fdo#110741]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque:
    - shard-kbl:          [FAIL][31] ([fdo#103232]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-kbl6/igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [FAIL][33] ([fdo#105363]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-skl:          [FAIL][35] ([fdo#105363]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-hsw:          [INCOMPLETE][37] ([fdo#103540]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-hsw7/igt@kms_flip@flip-vs-suspend.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-hsw6/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
    - shard-iclb:         [FAIL][39] ([fdo#103167]) -> [PASS][40] +2 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-apl:          [DMESG-WARN][41] ([fdo#108566]) -> [PASS][42] +3 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-apl5/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-apl8/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][43] ([fdo#108145] / [fdo#110403]) -> [PASS][44] +1 similar issue
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [SKIP][45] ([fdo#109441]) -> [PASS][46] +3 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb3/igt@kms_psr@psr2_no_drrs.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb2/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_vblank@pipe-c-wait-forked-busy-hang:
    - shard-iclb:         [INCOMPLETE][47] ([fdo#107713]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-iclb7/igt@kms_vblank@pipe-c-wait-forked-busy-hang.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-iclb7/igt@kms_vblank@pipe-c-wait-forked-busy-hang.html

  * igt@prime_busy@wait-hang-vebox:
    - shard-glk:          [DMESG-WARN][49] ([fdo#111256]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6576/shard-glk7/igt@prime_busy@wait-hang-vebox.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13792/shard-glk2/igt@prime_busy@wait-hang-vebox.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [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#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110684]: https://bugs.freedesktop.org/show_bug.cgi?id=110684
  [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
  [fdo#110741]: https://bugs.freedesktop.org/show_bug.cgi?id=110741
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111115]: https://bugs.freedesktop.org/show_bug.cgi?id=111115
  [fdo#111256]: https://bugs.freedesktop.org/show_bug.cgi?id=111256


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

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6576 -> Patchwork_13792

  CI-20190529: 20190529
  CI_DRM_6576: 4040b4c4ab647422d82100c8b091d34b6a82f572 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5115: 21be7a02ac8a8ff46b561c36a69e4dd5a0c2938b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13792: a40d51fbdceddd801f6357c6f76051f15c3fb273 @ 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_13792/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH] drm/i915/uc: don't enable communication twice on resume
  2019-07-30  8:14 ` [PATCH] " Chris Wilson
@ 2019-07-30 16:05   ` Daniele Ceraolo Spurio
  2019-07-30 16:13     ` Chris Wilson
  0 siblings, 1 reply; 6+ messages in thread
From: Daniele Ceraolo Spurio @ 2019-07-30 16:05 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx



On 7/30/19 1:14 AM, Chris Wilson wrote:
> Quoting Daniele Ceraolo Spurio (2019-07-29 23:28:00)
>> When coming out of S3/S4 we sanitize and re-init the HW, which includes
>> enabling communication during uc_init_hw. We therefore don't want to do
>> that again in uc_resume and can just tell GuC to reload its state.
>>
>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>>   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++++++++++++++-
>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> index fafa9be1e12a..34706a753793 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> @@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc *guc)
>>          guc->interrupts.disable(guc);
>>   }
>>   
>> +static bool guc_communication_enabled(struct intel_guc *guc)
>> +{
>> +       return guc->send != intel_guc_send_nop;
>> +}
>> +
>>   static int guc_enable_communication(struct intel_guc *guc)
>>   {
>>          struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>>          int ret;
>>   
>> +       GEM_BUG_ON(guc_communication_enabled(guc));
>> +
>>          ret = intel_guc_ct_enable(&guc->ct);
>>          if (ret)
>>                  return ret;
>> @@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
>>          if (!intel_guc_is_running(guc))
>>                  return 0;
>>   
>> -       guc_enable_communication(guc);
>> +       /*
>> +        * When coming out of S3/S4 we sanitize and re-init the HW, so
>> +        * communication is already re-enabled at this point and we just need
>> +        * to tell GuC to reload its internal state. During runtime resume we
>> +        * instead want to re-init everything.
>> +        */
>> +       if (!guc_communication_enabled(guc))
>> +               guc_enable_communication(guc);
> 
> We distinguish runtime_suspend from suspend, but not runtime_resume from
> resume. Is that distinction worthwhile, could we use it be more strict
> over the expected state?
> -Chris
> 

The actual actions we want to perform in both cases are the same, apart 
from the communication side. What about:

static int __uc_resume(struct intel_uc *uc, bool enable_comm)
{
	if (!intel_guc_is_running())
		return 0;

	GEM_BUG_ON(enable comm == guc_communication_enabled());

	if (enable_comm)
		guc_enable_communication();

	err = intel_guc_resume();
}

intel_uc_runtime_resume()
{
	__uc_resume(uc, true);
}

intel_uc_resume()
{
	__uc_resume(uc, false);
}

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

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

* Re: [PATCH] drm/i915/uc: don't enable communication twice on resume
  2019-07-30 16:05   ` Daniele Ceraolo Spurio
@ 2019-07-30 16:13     ` Chris Wilson
  0 siblings, 0 replies; 6+ messages in thread
From: Chris Wilson @ 2019-07-30 16:13 UTC (permalink / raw)
  To: Daniele Ceraolo Spurio, intel-gfx

Quoting Daniele Ceraolo Spurio (2019-07-30 17:05:19)
> 
> 
> On 7/30/19 1:14 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-07-29 23:28:00)
> >> When coming out of S3/S4 we sanitize and re-init the HW, which includes
> >> enabling communication during uc_init_hw. We therefore don't want to do
> >> that again in uc_resume and can just tell GuC to reload its state.
> >>
> >> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> >> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >> ---
> >>   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++++++++++++++-
> >>   1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> index fafa9be1e12a..34706a753793 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> @@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc *guc)
> >>          guc->interrupts.disable(guc);
> >>   }
> >>   
> >> +static bool guc_communication_enabled(struct intel_guc *guc)
> >> +{
> >> +       return guc->send != intel_guc_send_nop;
> >> +}
> >> +
> >>   static int guc_enable_communication(struct intel_guc *guc)
> >>   {
> >>          struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> >>          int ret;
> >>   
> >> +       GEM_BUG_ON(guc_communication_enabled(guc));
> >> +
> >>          ret = intel_guc_ct_enable(&guc->ct);
> >>          if (ret)
> >>                  return ret;
> >> @@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
> >>          if (!intel_guc_is_running(guc))
> >>                  return 0;
> >>   
> >> -       guc_enable_communication(guc);
> >> +       /*
> >> +        * When coming out of S3/S4 we sanitize and re-init the HW, so
> >> +        * communication is already re-enabled at this point and we just need
> >> +        * to tell GuC to reload its internal state. During runtime resume we
> >> +        * instead want to re-init everything.
> >> +        */
> >> +       if (!guc_communication_enabled(guc))
> >> +               guc_enable_communication(guc);
> > 
> > We distinguish runtime_suspend from suspend, but not runtime_resume from
> > resume. Is that distinction worthwhile, could we use it be more strict
> > over the expected state?
> 
> The actual actions we want to perform in both cases are the same, apart 
> from the communication side. What about:
> 
> static int __uc_resume(struct intel_uc *uc, bool enable_comm)
> {
>         if (!intel_guc_is_running())
>                 return 0;
> 
>         GEM_BUG_ON(enable comm == guc_communication_enabled());
> 
>         if (enable_comm)
>                 guc_enable_communication();
> 
>         err = intel_guc_resume();
> }
> 
> intel_uc_runtime_resume()
> {
>         __uc_resume(uc, true);
> }
> 
> intel_uc_resume()
> {
>         __uc_resume(uc, false);
> }

That works for me. Having uc->suspend unnerved me worrying about what
happens if gets out of sync. I like having the link from drm_resume ->
uc_resume and drm_runtime_resume -> uc_runtime_resume.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

end of thread, other threads:[~2019-07-30 16:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-29 22:28 [PATCH] drm/i915/uc: don't enable communication twice on resume Daniele Ceraolo Spurio
2019-07-30  0:41 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-07-30  8:14 ` [PATCH] " Chris Wilson
2019-07-30 16:05   ` Daniele Ceraolo Spurio
2019-07-30 16:13     ` Chris Wilson
2019-07-30 11:25 ` ✓ Fi.CI.IGT: success for " 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.