[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77889/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8567_full -> Patchwork_17836_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl7/igt@i915_susp...@forcewake.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-kbl1/igt@i915_susp...@forcewake.html
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#636] / [i915#69])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl1/igt@i915_susp...@forcewake.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl2/igt@i915_susp...@forcewake.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-apl6/igt@i915_susp...@sysfs-reader.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-apl4/igt@i915_susp...@sysfs-reader.html

  * igt@kms_color@pipe-b-degamma:
- shard-hsw:  [PASS][7] -> [INCOMPLETE][8] ([i915#1927] / [i915#61])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-hsw1/igt@kms_co...@pipe-b-degamma.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-hsw1/igt@kms_co...@pipe-b-degamma.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-render:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#49])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-render.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-render.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#1188])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl7/igt@kms_...@bpc-switch.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl5/igt@kms_...@bpc-switch.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([i915#69])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl4/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl7/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-tglb: [INCOMPLETE][19] ([i915#750]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-tglb7/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-tglb6/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html

  * igt@kms_draw_crc@fill-fb:
- shard-kbl:  [FAIL][21] ([i915#52] / [i915#93] / [i915#95]) -> 
[PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl1/igt@kms_draw_...@fill-fb.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-kbl2/igt@kms_draw_...@fill-fb.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@b-hdmi-a1}:
- shard-hsw:  [INCOMPLETE][23] ([i915#61]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-hsw8/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-hsw6/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [DMESG-WARN][25] ([i915#180] / [i915#95]) -> 
[PASS][26]
  

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Trim set_timer_ms() intervals

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Trim set_timer_ms() intervals
URL   : https://patchwork.freedesktop.org/series/77888/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8567_full -> Patchwork_17835_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@gem_exec_schedule@wide@vcs0}:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl7/igt@gem_exec_schedule@w...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-skl1/igt@gem_exec_schedule@w...@vcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen9_exec_parse@allowed-all:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / 
[i915#716])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-kbl4/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180] / [i915#93] 
/ [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#118] / [i915#70] / 
[i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-glk9/igt@kms_cursor_edge_w...@pipe-a-128x128-right-edge.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-glk8/igt@kms_cursor_edge_w...@pipe-a-128x128-right-edge.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#1188])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl7/igt@kms_...@bpc-switch.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-skl6/igt@kms_...@bpc-switch.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#165])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +4 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-iclb8/igt@kms_psr@psr2_primary_page_flip.html

  
 Possible fixes 

  * {igt@gem_ctx_isolation@preservation-s3@rcs0}:
- shard-kbl:  [DMESG-WARN][21] ([i915#180]) -> [PASS][22] +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl6/igt@gem_ctx_isolation@preservation...@rcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17835/shard-kbl1/igt@gem_c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Dont forget to clean up the connector on error (rev3)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Dont forget to clean up the connector on error (rev3)
URL   : https://patchwork.freedesktop.org/series/77011/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8568 -> Patchwork_17838


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#1250] / 
[i915#1436] / [i915#1506])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/fi-bsw-nick/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/fi-bsw-nick/igt@i915_selftest@l...@hangcheck.html

  
  [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1506]: https://gitlab.freedesktop.org/drm/intel/issues/1506


Participating hosts (51 -> 45)
--

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


Build changes
-

  * Linux: CI_DRM_8568 -> Patchwork_17838

  CI-20190529: 20190529
  CI_DRM_8568: 124bafc80c3ce62fc61b8eabb2657c87424b999b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17838: a30b3a0e479eb9f2f48cf8a737656c9bbb64c15a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a30b3a0e479e drm/i915/dsi: Dont forget to clean up the connector on error (v2)

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add Wa_1409371443

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add Wa_1409371443
URL   : https://patchwork.freedesktop.org/series/77892/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8568 -> Patchwork_17837


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (51 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8568 -> Patchwork_17837

  CI-20190529: 20190529
  CI_DRM_8568: 124bafc80c3ce62fc61b8eabb2657c87424b999b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17837: fe426e69f68a924170739c2e34f71a3771b37c0f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fe426e69f68a drm/i915/tgl: Add Wa_1409371443

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_1409371443

2020-06-01 Thread Aditya Swarup
Set GMBUS0 Pin Pair Select to 1 at boot and each FLR exit.
Return GMBUS0 Pin Pair Select to 1 after GMBUS transactions are done.

Cc: Michal Wajdeczko 
Cc: Piotr Piórkowski 
Cc: Matt Roper 
Cc: Jose Souza 
Signed-off-by: Aditya Swarup 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 16 
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index a8d119b6b45c..8dd5aa025c3f 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -139,11 +139,19 @@ to_intel_gmbus(struct i2c_adapter *i2c)
return container_of(i2c, struct intel_gmbus, adapter);
 }
 
+static void gmbus0_wa_reset(struct drm_i915_private *dev_priv)
+{
+   intel_de_write(dev_priv, GMBUS0, 0 | GMBUS_PIN_PAIR_1);
+}
+
 void
 intel_gmbus_reset(struct drm_i915_private *dev_priv)
 {
intel_de_write(dev_priv, GMBUS0, 0);
intel_de_write(dev_priv, GMBUS4, 0);
+   /* Wa_1409371443: tgl[a0] */
+   if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
+   gmbus0_wa_reset(dev_priv);
 }
 
 static void pnv_gmbus_clock_gating(struct drm_i915_private *dev_priv,
@@ -299,6 +307,10 @@ intel_gpio_post_xfer(struct i2c_adapter *adapter)
 
if (IS_PINEVIEW(dev_priv))
pnv_gmbus_clock_gating(dev_priv, true);
+
+   /* Wa_1409371443: tgl[a0] */
+   if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
+   gmbus0_wa_reset(dev_priv);
 }
 
 static void
@@ -955,4 +967,8 @@ void intel_gmbus_teardown(struct drm_i915_private *dev_priv)
bus = &dev_priv->gmbus[pin];
i2c_del_adapter(&bus->adapter);
}
+
+   /* Wa_1409371443: tgl[a0] */
+   if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
+   gmbus0_wa_reset(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 578cfe11cbb9..a1640476cefb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3337,6 +3337,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   GMBUS_RATE_1MHZ  (3 << 8) /* reserved on Pineview */
 #define   GMBUS_HOLD_EXT   (1 << 7) /* 300ns hold time, rsvd on Pineview */
 #define   GMBUS_BYTE_CNT_OVERRIDE (1 << 6)
+#define   GMBUS_PIN_PAIR_MASK  REG_GENMASK(4, 0)
+#define   GMBUS_PIN_PAIR_1 REG_FIELD_PREP(GMBUS_PIN_PAIR_MASK, 1)
 
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1 << 31)
-- 
2.26.2

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix wrong CDCLK adjustment changes (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix wrong CDCLK adjustment changes (rev2)
URL   : https://patchwork.freedesktop.org/series/77654/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8566_full -> Patchwork_17834_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@perf_pmu@faulting-read@uc}:
- shard-apl:  NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-apl4/igt@perf_pmu@faulting-r...@uc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process@rcs0:
- shard-apl:  [PASS][2] -> [FAIL][3] ([i915#1528])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-apl8/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-apl8/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#1119] / [i915#118] / 
[i915#95])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_legacy@pipe-b-torture-bo:
- shard-tglb: [PASS][8] -> [DMESG-WARN][9] ([i915#128])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-tglb1/igt@kms_cursor_leg...@pipe-b-torture-bo.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-tglb5/igt@kms_cursor_leg...@pipe-b-torture-bo.html

  * igt@kms_draw_crc@fill-fb:
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#95])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-apl4/igt@kms_draw_...@fill-fb.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-apl2/igt@kms_draw_...@fill-fb.html

  * igt@kms_hdr@bpc-switch-dpms:
- shard-skl:  [PASS][12] -> [FAIL][13] ([i915#1188])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-skl5/igt@kms_...@bpc-switch-dpms.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-skl6/igt@kms_...@bpc-switch-dpms.html
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#1188])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-kbl3/igt@kms_...@bpc-switch-dpms.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-kbl6/igt@kms_...@bpc-switch-dpms.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109642] / [fdo#111068])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-iclb5/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_primary_render:
- shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109441])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-iclb2/igt@kms_psr@psr2_primary_render.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-iclb3/igt@kms_psr@psr2_primary_render.html

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-kbl3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-kbl1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html

  
 Possible fixes 

  * igt@gem_exec_reloc@basic-gtt-wc:
- shard-hsw:  [DMESG-WARN][22] ([i915#1927]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-hsw1/igt@gem_exec_re...@basic-gtt-wc.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/shard-hsw2/igt@gem_exec_re...@basic-gtt-wc.html

  * igt@kms_color@pipe-a-gamma:
- shard-hsw:  [INCOMPLETE][24] ([i915#1927] / [i915#61]) -> 
[PASS][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/shard-hs

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-01 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 418 +
 1 file changed, 418 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..d1121ecd2 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,417 @@ static void measure_semaphore_power(int i915)
rapl_close(&pkg);
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = &value,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77889/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8567 -> Patchwork_17836


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@active:
- fi-icl-y:   [PASS][1] -> [DMESG-FAIL][2] ([i915#765])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/fi-icl-y/igt@i915_selftest@l...@active.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/fi-icl-y/igt@i915_selftest@l...@active.html

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


Participating hosts (49 -> 44)
--

  Additional (2): fi-skl-lmem fi-cfl-8109u 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8567 -> Patchwork_17836

  CI-20190529: 20190529
  CI_DRM_8567: d36c7a9807541df70739a5917cbbab42fdf66a29 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17836: 28eb95e6e065e155a6b0a5c8fb4c4bab9a19c411 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

28eb95e6e065 drm/i915/params: prevent changing module params runtime
5cc66b985a6b drm/i915/params: fix i915.fake_lmem_start module param sysfs 
permissions
acf490748fe6 drm/i915/params: don't expose inject_probe_failure in debugfs

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Trim the ironlake+ irq handler (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Trim the ironlake+ irq handler (rev2)
URL   : https://patchwork.freedesktop.org/series/77871/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8565_full -> Patchwork_17832_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-kbl7/igt@i915_susp...@sysfs-reader.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-kbl7/igt@i915_susp...@sysfs-reader.html

  * igt@kms_draw_crc@fill-fb:
- shard-apl:  [PASS][3] -> [FAIL][4] ([i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-apl8/igt@kms_draw_...@fill-fb.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-apl2/igt@kms_draw_...@fill-fb.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][5] -> [FAIL][6] ([i915#1188]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl5/igt@kms_...@bpc-switch-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-skl2/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#108145] / [i915#265]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109642] / [fdo#111068])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-iclb5/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_primary_render:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-iclb2/igt@kms_psr@psr2_primary_render.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-iclb5/igt@kms_psr@psr2_primary_render.html

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-apl1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-apl1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html

  
 Possible fixes 

  * {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk:  [FAIL][15] ([i915#1930]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html

  * {igt@gem_exec_reloc@basic-concurrent16}:
- shard-skl:  [FAIL][17] ([i915#1930]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl8/igt@gem_exec_re...@basic-concurrent16.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-skl10/igt@gem_exec_re...@basic-concurrent16.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- shard-glk:  [FAIL][19] ([i915#1119] / [i915#118] / [i915#95]) -> 
[PASS][20] +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-glk6/igt@kms_big...@x-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge:
- shard-glk:  [INCOMPLETE][21] ([i915#1927] / [i915#58] / 
[k.org#198133]) -> [PASS][22] +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-glk1/igt@kms_cursor_edge_w...@pipe-c-256x256-right-edge.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-glk1/igt@kms_cursor_edge_w...@pipe-c-256x256-right-edge.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [FAIL][23] ([i915#72]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [SKIP][25] ([fdo#109349]

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77889/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77889/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
acf490748fe6 drm/i915/params: don't expose inject_probe_failure in debugfs
5cc66b985a6b drm/i915/params: fix i915.fake_lmem_start module param sysfs 
permissions
-:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#27: FILE: drivers/gpu/drm/i915/i915_params.c:177:
+i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");

total: 0 errors, 0 warnings, 1 checks, 8 lines checked
28eb95e6e065 drm/i915/params: prevent changing module params runtime
-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/i915_params.c:62:
+i915_param_named_unsafe(enable_fbc, int, 0400,
"Enable frame buffer compression for power savings "

-:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#57: FILE: drivers/gpu/drm/i915/i915_params.c:70:
+i915_param_named_unsafe(panel_use_ssc, int, 0400,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "

-:66: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#66: FILE: drivers/gpu/drm/i915/i915_params.c:78:
+i915_param_named_unsafe(reset, int, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");

-:74: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#74: FILE: drivers/gpu/drm/i915/i915_params.c:85:
+i915_param_named(error_capture, bool, 0400,
"Record the GPU state following a hang. "

-:81: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#81: FILE: drivers/gpu/drm/i915/i915_params.c:91:
+i915_param_named_unsafe(enable_hangcheck, bool, 0400,
"Periodically check GPU activity for detecting hangs. "

-:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#87: FILE: drivers/gpu/drm/i915/i915_params.c:96:
+i915_param_named_unsafe(enable_psr, int, 0400,
"Enable PSR "

-:99: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#99: FILE: drivers/gpu/drm/i915/i915_params.c:111:
+i915_param_named(fastboot, int, 0400,
"Try to skip unnecessary mode sets at boot time "

-:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#105: FILE: drivers/gpu/drm/i915/i915_params.c:116:
+i915_param_named_unsafe(load_detect_test, bool, 0400,
"Force-enable the VGA load detect code for testing (default:false). "

-:110: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#110: FILE: drivers/gpu/drm/i915/i915_params.c:120:
+i915_param_named_unsafe(force_reset_modeset_test, bool, 0400,
"Force a modeset during gpu reset for testing (default:false). "

-:115: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#115: FILE: drivers/gpu/drm/i915/i915_params.c:124:
+i915_param_named_unsafe(invert_brightness, int, 0400,
"Invert backlight brightness "

-:124: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#124: FILE: drivers/gpu/drm/i915/i915_params.c:134:
+i915_param_named(mmio_debug, int, 0400,
"Enable the MMIO debug code for the first N failures (default: off). "

-:137: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#137: FILE: drivers/gpu/drm/i915/i915_params.c:169:
+i915_param_named_unsafe(enable_dp_mst, bool, 0400,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");

-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/i915/i915_params.c:177:
+i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"

total: 0 errors, 0 warnings, 13 checks, 115 lines checked

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


[Intel-gfx] [CI 1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-01 Thread Jani Nikula
The parameter only makes sense as a module parameter only.

Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Cc: Juha-Pekka Heikkilä 
Cc: Venkata Sandeep Dhanalakota 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 45323732f099..4f21bfffbf0e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -64,7 +64,7 @@ struct drm_printer;
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO), 0600) \
param(int, edp_vswing, 0, 0400) \
param(unsigned int, reset, 3, 0600) \
-   param(unsigned int, inject_probe_failure, 0, 0600) \
+   param(unsigned int, inject_probe_failure, 0, 0) \
param(int, fastboot, -1, 0600) \
param(int, enable_dpcd_backlight, -1, 0600) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
-- 
2.20.1

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


[Intel-gfx] [CI 2/3] drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions

2020-06-01 Thread Jani Nikula
fake_lmem_start does not need to be mutable via module param sysfs. It's
only used during driver probe.

Fixes: 1629224324b6 ("drm/i915/lmem: add the fake lmem region")
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index add00ec1f787..a3dde770226d 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -173,7 +173,7 @@ i915_param_named(enable_gvt, bool, 0400,
 #endif
 
 #if IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM)
-i915_param_named_unsafe(fake_lmem_start, ulong, 0600,
+i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");
 #endif
 
-- 
2.20.1

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


[Intel-gfx] [CI 3/3] drm/i915/params: prevent changing module params runtime

2020-06-01 Thread Jani Nikula
Only support runtime changes through the debugfs.

i915.verbose_state_checks remains an exception, and is not exposed via
debugfs.

This depends on IGT having been updated to use the debugfs for modifying
the parameters.

Cc: Juha-Pekka Heikkilä 
Cc: Venkata Sandeep Dhanalakota 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 38 +++---
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index a3dde770226d..ace44ad7e6df 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -40,6 +40,15 @@ struct i915_params i915_modparams __read_mostly = {
 #undef MEMBER
 };
 
+/*
+ * Note: As a rule, keep module parameter sysfs permissions read-only
+ * 0400. Runtime changes are only supported through i915 debugfs.
+ *
+ * For any exceptions requiring write access and runtime changes through module
+ * parameter sysfs, prevent debugfs file creation by setting the parameter's
+ * debugfs mode to 0.
+ */
+
 i915_param_named(modeset, int, 0400,
"Use kernel modesetting [KMS] (0=disable, "
"1=on, -1=force vga console preference [default])");
@@ -49,7 +58,7 @@ i915_param_named_unsafe(enable_dc, int, 0400,
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
"3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
 
-i915_param_named_unsafe(enable_fbc, int, 0600,
+i915_param_named_unsafe(enable_fbc, int, 0400,
"Enable frame buffer compression for power savings "
"(default: -1 (use per-chip default))");
 
@@ -57,7 +66,7 @@ i915_param_named_unsafe(lvds_channel_mode, int, 0400,
 "Specify LVDS channel mode "
 "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
 
-i915_param_named_unsafe(panel_use_ssc, int, 0600,
+i915_param_named_unsafe(panel_use_ssc, int, 0400,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "
"(default: auto from VBT)");
 
@@ -65,25 +74,25 @@ i915_param_named_unsafe(vbt_sdvo_panel_type, int, 0400,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-i915_param_named_unsafe(reset, int, 0600,
+i915_param_named_unsafe(reset, int, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");
 
 i915_param_named_unsafe(vbt_firmware, charp, 0400,
"Load VBT from specified file under /lib/firmware");
 
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-i915_param_named(error_capture, bool, 0600,
+i915_param_named(error_capture, bool, 0400,
"Record the GPU state following a hang. "
"This information in /sys/class/drm/card/error is vital for "
"triaging and debugging hangs.");
 #endif
 
-i915_param_named_unsafe(enable_hangcheck, bool, 0600,
+i915_param_named_unsafe(enable_hangcheck, bool, 0400,
"Periodically check GPU activity for detecting hangs. "
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");
 
-i915_param_named_unsafe(enable_psr, int, 0600,
+i915_param_named_unsafe(enable_psr, int, 0400,
"Enable PSR "
"(0=disabled, 1=enabled) "
"Default: -1 (use per-chip default)");
@@ -96,22 +105,22 @@ i915_param_named_unsafe(disable_power_well, int, 0400,
"Disable display power wells when possible "
"(-1=auto [default], 0=power wells always on, 1=power wells disabled 
when possible)");
 
-i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: true)");
+i915_param_named_unsafe(enable_ips, int, 0400, "Enable IPS (default: true)");
 
-i915_param_named(fastboot, int, 0600,
+i915_param_named(fastboot, int, 0400,
"Try to skip unnecessary mode sets at boot time "
"(0=disabled, 1=enabled) "
"Default: -1 (use per-chip default)");
 
-i915_param_named_unsafe(load_detect_test, bool, 0600,
+i915_param_named_unsafe(load_detect_test, bool, 0400,
"Force-enable the VGA load detect code for testing (default:false). "
"For developers only.");
 
-i915_param_named_unsafe(force_reset_modeset_test, bool, 0600,
+i915_param_named_unsafe(force_reset_modeset_test, bool, 0400,
"Force a modeset during gpu reset for testing (default:false). "
"For developers only.");
 
-i915_param_named_unsafe(invert_brightness, int, 0600,
+i915_param_named_unsafe(invert_brightness, int, 0400,
"Invert backlight brightness "
"(-1 force normal, 0 machine defaults, 1 force inversion), please "
"report PCI device ID, subsystem vendor and subsystem device ID "
@@ -121,10 +130,11 @@ i915_param_named_unsafe(invert_brightness, int, 0600,
 i915_param_named(disable_display, bool, 0400,
"Disable display (default: false)");
 
-i915_param_named(mmio_debug, int, 0600,
+i915_param_named(mmio_debug, int, 0400,
"Enable the MMIO debug code for the first N failure

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/panel: Reduce race window between bl_update_status and bl_enable

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915/panel: Reduce race window between bl_update_status and 
bl_enable
URL   : https://patchwork.freedesktop.org/series/77873/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8565_full -> Patchwork_17831_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process@bcs0:
- shard-skl:  [PASS][1] -> [FAIL][2] ([i915#1528])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl7/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html

  * igt@gen9_exec_parse@allowed-all:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / 
[i915#716])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy:
- shard-hsw:  [PASS][5] -> [INCOMPLETE][6] ([i915#1926] / [i915#61])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-hsw2/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-hsw4/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html

  * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk:  [PASS][7] -> [DMESG-FAIL][8] ([i915#1925] / 
[i915#1926])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-glk1/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-glk6/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html

  * igt@kms_draw_crc@fill-fb:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#95])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-apl8/igt@kms_draw_...@fill-fb.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-apl7/igt@kms_draw_...@fill-fb.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#1188])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl7/igt@kms_...@bpc-switch.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-skl3/igt@kms_...@bpc-switch.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-apl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-apl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-iclb1/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_primary_render:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-iclb2/igt@kms_psr@psr2_primary_render.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-iclb1/igt@kms_psr@psr2_primary_render.html

  * igt@perf@stress-open-close:
- shard-kbl:  [PASS][23] -> [INCOMPLETE][24] ([i915#1847] / 
[i915#1855])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/shard-kbl6/igt@p...@stress-open-close.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/shard-kbl7/igt@p...@stress-open-close.html

  
 Possible fixes 

  * igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- shard-glk:  [FAIL][25] ([i915#1119] / [i9

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-01 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 253 +
 1 file changed, 253 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..d58d926b1 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,254 @@ static void measure_semaphore_power(int i915)
rapl_close(&pkg);
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = &value,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ 10);
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void async_delay(int i915,
+   const struct intel_execution_engine2 *e,
+   uint32_t handle,
+   uint64_t addr,
+   uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);
+}
+
+static struct drm_i915_gem_exec_object2
+timed_create(int i915, uint32_t ctx,
+const struct intel_execution_engine2 *e,
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Trim set_timer_ms() intervals

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Trim set_timer_ms() intervals
URL   : https://patchwork.freedesktop.org/series/77888/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8567 -> Patchwork_17835


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (49 -> 44)
--

  Additional (2): fi-skl-lmem fi-cfl-8109u 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8567 -> Patchwork_17835

  CI-20190529: 20190529
  CI_DRM_8567: d36c7a9807541df70739a5917cbbab42fdf66a29 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17835: 183dd61a0a8d0940db360620100f6455738ceffe @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

183dd61a0a8d drm/i915/gt: Always check to enable timeslicing if not submitting
dfd64e60999a drm/i915/gt: Set timeslicing priority from queue
7737d0a8b16f drm/i915: Trim set_timer_ms() intervals

== Logs ==

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


Re: [Intel-gfx] [PATCH v2] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Manasi Navare
On Mon, Jun 01, 2020 at 08:30:58PM +0300, Stanislav Lisovskiy wrote:
> Previous patch didn't take into account all pipes
> but only those in state, which could cause wrong
> CDCLK conclcusions and calculations.
> Also there was a severe issue with min_cdclk being
> assigned to 0 every compare cycle.
> 
> Too bad this was found by me only after merge.
> This could be also causing the issues in test, however
> not clear - anyway marking this as fixing the
> "Adjust CDCLK accordingly to our DBuf bw needs".
> 
> v2: - s/pipe/crtc->pipe/
> - save a bit of instructions by
>   skipping inactive pipes, without
>   getting 0 DBuf slice mask for it.
> 
> Signed-off-by: Stanislav Lisovskiy 
> Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")

Looks good to me, 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_bw.c  | 52 +---
>  drivers/gpu/drm/i915/display/intel_cdclk.c   | 19 ---
>  drivers/gpu/drm/i915/display/intel_display.c | 26 +-
>  3 files changed, 55 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index a79bd7aeb03b..bd060404d249 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>   struct intel_crtc *crtc;
>   int max_bw = 0;
>   int slice_id;
> + enum pipe pipe;
>   int i;
>  
>   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> @@ -447,10 +448,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>   if (IS_ERR(new_bw_state))
>   return PTR_ERR(new_bw_state);
>  
> + old_bw_state = intel_atomic_get_old_bw_state(state);
> +
>   crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
>  
>   memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
>  
> + if (!crtc_state->hw.active)
> + continue;
> +
>   for_each_plane_id_on_crtc(crtc, plane_id) {
>   const struct skl_ddb_entry *plane_alloc =
>   &crtc_state->wm.skl.plane_ddb_y[plane_id];
> @@ -478,6 +484,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>   for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
>   crtc_bw->used_bw[slice_id] += data_rate;
>   }
> + }
> +
> + if (!old_bw_state)
> + return 0;
> +
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_dbuf_bw *crtc_bw;
> +
> + crtc_bw = &new_bw_state->dbuf_bw[pipe];
>  
>   for_each_dbuf_slice(slice_id) {
>   /*
> @@ -490,14 +505,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>*/
>   max_bw += crtc_bw->used_bw[slice_id];
>   }
> -
> - new_bw_state->min_cdclk = max_bw / 64;
> -
> - old_bw_state = intel_atomic_get_old_bw_state(state);
>   }
>  
> - if (!old_bw_state)
> - return 0;
> + new_bw_state->min_cdclk = max_bw / 64;
>  
>   if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
>   int ret = intel_atomic_lock_global_state(&new_bw_state->base);
> @@ -511,34 +521,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> *state)
>  
>  int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
>  {
> - int i;
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_bw_state *new_bw_state = NULL;
> + struct intel_bw_state *old_bw_state = NULL;
>   const struct intel_crtc_state *crtc_state;
>   struct intel_crtc *crtc;
>   int min_cdclk = 0;
> - struct intel_bw_state *new_bw_state = NULL;
> - struct intel_bw_state *old_bw_state = NULL;
> + enum pipe pipe;
> + int i;
>  
>   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - struct intel_cdclk_state *cdclk_state;
> -
>   new_bw_state = intel_atomic_get_bw_state(state);
>   if (IS_ERR(new_bw_state))
>   return PTR_ERR(new_bw_state);
>  
> - cdclk_state = intel_atomic_get_cdclk_state(state);
> - if (IS_ERR(cdclk_state))
> - return PTR_ERR(cdclk_state);
> -
> - min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk);
> -
> - new_bw_state->min_cdclk = min_cdclk;
> -
>   old_bw_state = intel_atomic_get_old_bw_state(state);
>   }
>  
>   if (!old_bw_state)
>   return 0;
>  
> + for_each_pipe(dev_priv, pipe) {
> + struct intel_cdclk_state *cdclk_state;
> +
> + cdclk_state = intel_atomic_get_new_cdclk_state(state);
> + if (!cdclk_state)
> + 

Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Manasi Navare
On Mon, Jun 01, 2020 at 10:49:54AM +0300, Lisovskiy, Stanislav wrote:
> On Fri, May 29, 2020 at 04:57:38PM -0700, Manasi Navare wrote:
> > On Tue, May 26, 2020 at 12:48:52PM +0300, Stanislav Lisovskiy wrote:
> > > Previous patch didn't take into account all pipes
> > > but only those in state, which could cause wrong
> > > CDCLK conclcusions and calculations.
> > > Also there was a severe issue with min_cdclk being
> > > assigned to 0 every compare cycle.
> > > 
> > > Too bad this was found by me only after merge.
> > > This could be also causing the issues in test, however
> > > not clear - anyway marking this as fixing the
> > > "Adjust CDCLK accordingly to our DBuf bw needs".
> > > 
> > > Signed-off-by: Stanislav Lisovskiy 
> > > Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_bw.c  | 51 
> > >  drivers/gpu/drm/i915/display/intel_cdclk.c   | 19 +---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> > >  3 files changed, 53 insertions(+), 43 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index a79bd7aeb03b..8096138abecc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > > *state)
> > >   struct intel_crtc *crtc;
> > >   int max_bw = 0;
> > >   int slice_id;
> > > + enum pipe pipe;
> > >   int i;
> > >  
> > >   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> > > @@ -447,7 +448,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > > *state)
> > >   if (IS_ERR(new_bw_state))
> > >   return PTR_ERR(new_bw_state);
> > >  
> > > - crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
> > > + old_bw_state = intel_atomic_get_old_bw_state(state);
> > > +
> > > + crtc_bw = &new_bw_state->dbuf_bw[pipe];
> > >  
> > >   memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> > >  
> > > @@ -478,6 +481,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > > *state)
> > >   for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
> > >   crtc_bw->used_bw[slice_id] += data_rate;
> > >   }
> > > + }
> > > +
> > > + if (!old_bw_state)
> > > + return 0;
> > > +
> > > + for_each_pipe(dev_priv, pipe) {
> > > + struct intel_dbuf_bw *crtc_bw;
> > > +
> > 
> > So the condition !old_bw_state() will make sure we loop through
> > only the active pipes and compute crtc_bw only for those right?
> > 
> > Manasi
> 
> Well, in fact this condition just checks if we had any crtcs in state - 
> otherwise there were no changes, so bw_state global object doesn't need
> to be changed. Whenever something happens to crtc we should have it
> in the state, so this condition just checks if we need to modify bw_state
> or not. 
> 
> Regarding active/inactive pipes - currently for inactive pipes,
> we are going to get 0 dbuf slice mask, so we just won't accumulate any data
> rate for those. So if the pipe got disabled we will get less required 
> min_cdclk
> which against old_bw_state, which will mean that we are going to acquire
> the global state lock for writing.
> 
> In fact we could optimize the code by skipping inactive pipes completely 
> i.e don't even calculate dbuf slice mask,
> which will be 0. However the logic and the end result would be
> the same anyway.

Okay yes this makes sense, thanks for the clarification.
So would be it be an easy change to add a condition to return for an inactive 
pipe?

Manasi

> 
> Stan
> 
> > 
> > > + crtc_bw = &new_bw_state->dbuf_bw[pipe];
> > >  
> > >   for_each_dbuf_slice(slice_id) {
> > >   /*
> > > @@ -490,14 +502,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > > *state)
> > >*/
> > >   max_bw += crtc_bw->used_bw[slice_id];
> > >   }
> > > -
> > > - new_bw_state->min_cdclk = max_bw / 64;
> > > -
> > > - old_bw_state = intel_atomic_get_old_bw_state(state);
> > >   }
> > >  
> > > - if (!old_bw_state)
> > > - return 0;
> > > + new_bw_state->min_cdclk = max_bw / 64;
> > >  
> > >   if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> > >   int ret = intel_atomic_lock_global_state(&new_bw_state->base);
> > > @@ -511,34 +518,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > > *state)
> > >  
> > >  int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
> > >  {
> > > - int i;
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_bw_state *new_bw_state = NULL;
> > > + struct intel_bw_state *old_bw_state = NULL;
> > >   const struct intel_crtc_state *crtc_state;
> > >   struct intel_crtc *crtc;
> > >   int min_cdclk = 0;
> > > - struct inte

[Intel-gfx] [PATCH 1/3] drm/i915: Trim set_timer_ms() intervals

2020-06-01 Thread Chris Wilson
Use the plain msec_to_jiffies() rather than the _timeout variant so we
round down and do not add an extra jiffy to our interval. For example,
with timeslicing we do not want to err on the longer side as any
fairness depends on catching hogging contexts on the GPU. Bring on
CFS.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.c 
b/drivers/gpu/drm/i915/i915_utils.c
index e28eae4a8f70..f42a9e9a0b4f 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -91,7 +91,7 @@ void set_timer_ms(struct timer_list *t, unsigned long timeout)
return;
}
 
-   timeout = msecs_to_jiffies_timeout(timeout);
+   timeout = msecs_to_jiffies(timeout);
 
/*
 * Paranoia to make sure the compiler computes the timeout before
-- 
2.20.1

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


[Intel-gfx] [PATCH 3/3] drm/i915/gt: Always check to enable timeslicing if not submitting

2020-06-01 Thread Chris Wilson
We may choose not to submit for a number of reasons, yet not fill both
ELSP. In which case we must start timeslicing (there will be no ACK
event on which to hook the start) if the queue would benefit from the
currently active context being evicted.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7a3c55e3ad9d..8e611470c121 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2358,10 +2358,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
if (last->context == rq->context)
goto done;
 
-   if (i915_request_has_sentinel(last)) {
-   start_timeslice(engine, rq_prio(rq));
+   if (i915_request_has_sentinel(last))
goto done;
-   }
 
/*
 * If GVT overrides us we only ever submit
@@ -2442,6 +2440,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
set_preempt_timeout(engine, *active);
execlists_submit_ports(engine);
} else {
+   start_timeslice(engine, execlists->queue_priority_hint);
 skip_submit:
ring_set_paused(engine, 0);
}
-- 
2.20.1

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


[Intel-gfx] [PATCH 2/3] drm/i915/gt: Set timeslicing priority from queue

2020-06-01 Thread Chris Wilson
If we only submit the first port, leaving the second empty yet have
ready requests pending in the queue, use that to set the timeslicing
priority (i.e. the priority at which we will decided to enabling
timeslicing and evict the currently active context if the queue is of
equal priority after its quantum expired).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6fc0966b75ff..7a3c55e3ad9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1962,7 +1962,7 @@ static int
 switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
 {
if (list_is_last(&rq->sched.link, &engine->active.requests))
-   return INT_MIN;
+   return engine->execlists.queue_priority_hint;
 
return rq_prio(list_next_entry(rq, sched.link));
 }
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH 2/7] drm/i915: Fix ibx max vswing/preemph

2020-06-01 Thread Souza, Jose
On Tue, 2020-05-12 at 20:41 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> IBX supports vswing level 3 and pre-emphasis level 3. Don't
> limit it to level 2 for those.

Matches 
https://01.org/linuxgraphics/documentation/driver-documentation-prms/2010-intel-core-processor-family

Reviewed-by: José Roberto de Souza <
jose.so...@intel.com>

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7541264ff4e9..0924e041e1bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3958,7 +3958,7 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
>   if (HAS_DDI(dev_priv))
>   return intel_ddi_dp_voltage_max(encoder);
>   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
> -  (HAS_PCH_CPT(dev_priv) && port != PORT_A))
> +  (HAS_PCH_SPLIT(dev_priv) && port != PORT_A))
>   return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
>   else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A)
>   return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> @@ -3976,7 +3976,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, u8 
> voltage_swing)
>   if (HAS_DDI(dev_priv)) {
>   return intel_ddi_dp_pre_emphasis_max(encoder, voltage_swing);
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
> -(HAS_PCH_CPT(dev_priv) && port != PORT_A)) {
> +(HAS_PCH_SPLIT(dev_priv) && port != PORT_A)) {
>   switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
>   case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
>   return DP_TRAIN_PRE_EMPH_LEVEL_3;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-01 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 245 +
 1 file changed, 245 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..5d91e94a3 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,246 @@ static void measure_semaphore_power(int i915)
rapl_close(&pkg);
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = &value,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ 10);
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void async_delay(int i915,
+   const struct intel_execution_engine2 *e,
+   uint32_t handle,
+   uint64_t addr,
+   uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);
+}
+
+static struct drm_i915_gem_exec_object2
+timed_create(int i915, uint32_t ctx,
+const struct intel_execution_engine2 *e,
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix wrong CDCLK adjustment changes (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix wrong CDCLK adjustment changes (rev2)
URL   : https://patchwork.freedesktop.org/series/77654/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8566 -> Patchwork_17834


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [TIMEOUT][1] ([i915#1288] / [i915#1958]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/fi-glk-dsi/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [SKIP][3] ([fdo#109271]) -> [FAIL][4] ([i915#62])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8566/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17834/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (50 -> 45)
--

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


Build changes
-

  * Linux: CI_DRM_8566 -> Patchwork_17834

  CI-20190529: 20190529
  CI_DRM_8566: fed6b89dd6f3c4e2e909805815c5728b1fd65ce5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5689: 587cbed206689abbad60689d4a32bf9caf0cc124 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17834: 6bfe3f7a62bd1c9345f4789886a8030a10e81d32 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6bfe3f7a62bd drm/i915: Fix wrong CDCLK adjustment changes

== Logs ==

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


[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-01 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 224 +
 1 file changed, 224 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..0ec21bf54 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,227 @@ static void measure_semaphore_power(int i915)
rapl_close(&pkg);
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = &value,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ 10);
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void async_delay(int i915,
+   const struct intel_execution_engine2 *e,
+   uint32_t handle,
+   uint64_t addr,
+   uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);
+}
+
+static struct drm_i915_gem_exec_object2
+timed_create(int i915, uint32_t ctx,
+const struct intel_execution_engine2 *e,
+   

Re: [Intel-gfx] [PATCH] drm/i915: Whitelist context-local timestamp in the gen9 cmdparser

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> Allow batch buffers to read their own _local_ cumulative HW runtime of
> their logical context.
>
> Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc:  # v5.4+

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 189b573d02be..372354d33f55 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -572,6 +572,9 @@ struct drm_i915_reg_descriptor {
>  #define REG32(_reg, ...) \
>   { .addr = (_reg), __VA_ARGS__ }
>  
> +#define REG32_IDX(_reg, idx) \
> + { .addr = _reg(idx) }
> +
>  /*
>   * Convenience macro for adding 64-bit registers.
>   *
> @@ -669,6 +672,7 @@ static const struct drm_i915_reg_descriptor 
> gen9_blt_regs[] = {
>   REG64_IDX(RING_TIMESTAMP, BSD_RING_BASE),
>   REG32(BCS_SWCTRL),
>   REG64_IDX(RING_TIMESTAMP, BLT_RING_BASE),
> + REG32_IDX(RING_CTX_TIMESTAMP, BLT_RING_BASE),
>   REG64_IDX(BCS_GPR, 0),
>   REG64_IDX(BCS_GPR, 1),
>   REG64_IDX(BCS_GPR, 2),
> -- 
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Update TC DP vswing table

2020-06-01 Thread Souza, Jose
On Sat, 2020-05-30 at 04:56 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/tgl: Update TC DP vswing table
> URL   : https://patchwork.freedesktop.org/series/77806/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_8557_full -> Patchwork_17824_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.

Pushed to dinq, thanks for the review Khaled.

> 
>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_17824_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_exec_suspend@basic-s3:
> - shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 
> similar issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl3/igt@gem_exec_susp...@basic-s3.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl7/igt@gem_exec_susp...@basic-s3.html
> 
>   * igt@i915_suspend@debugfs-reader:
> - shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 
> similar issue
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl1/igt@i915_susp...@debugfs-reader.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl4/igt@i915_susp...@debugfs-reader.html
> 
>   * igt@i915_suspend@fence-restore-untiled:
> - shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180] / 
> [i915#93] / [i915#95])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html
> 
>   * igt@i915_suspend@forcewake:
> - shard-kbl:  [PASS][7] -> [INCOMPLETE][8] ([i915#155])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl7/igt@i915_susp...@forcewake.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl3/igt@i915_susp...@forcewake.html
> 
>   * igt@kms_color@pipe-c-legacy-gamma:
> - shard-hsw:  [PASS][9] -> [INCOMPLETE][10] ([i915#61])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-hsw1/igt@kms_co...@pipe-c-legacy-gamma.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-hsw6/igt@kms_co...@pipe-c-legacy-gamma.html
> 
>   * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
> - shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#54])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
> - shard-skl:  [PASS][13] -> [FAIL][14] ([i915#54])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
> - shard-apl:  [PASS][15] -> [FAIL][16] ([i915#54])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
> 
>   * igt@kms_hdr@bpc-switch-suspend:
> - shard-skl:  [PASS][17] -> [FAIL][18] ([i915#1188])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl9/igt@kms_...@bpc-switch-suspend.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl7/igt@kms_...@bpc-switch-suspend.html
> 
>   * igt@kms_psr@psr2_sprite_mmap_cpu:
> - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441])
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_cpu.html
> 
>   
>  Possible fixes 
> 
>   * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
> - shard-skl:  [FAIL][21] ([i915#1528]) -> [PASS][22]
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
> 
>   * igt@gem_softpin@noreloc-s3:
> - shard-apl:  [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2 
> similar issues
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8557/shard-apl4/igt@gem_soft...@noreloc-s3.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17824/shard-apl2/igt@gem_soft...@noreloc-s3.html
> 
>  

[Intel-gfx] [PATCH v2] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Stanislav Lisovskiy
Previous patch didn't take into account all pipes
but only those in state, which could cause wrong
CDCLK conclcusions and calculations.
Also there was a severe issue with min_cdclk being
assigned to 0 every compare cycle.

Too bad this was found by me only after merge.
This could be also causing the issues in test, however
not clear - anyway marking this as fixing the
"Adjust CDCLK accordingly to our DBuf bw needs".

v2: - s/pipe/crtc->pipe/
- save a bit of instructions by
  skipping inactive pipes, without
  getting 0 DBuf slice mask for it.

Signed-off-by: Stanislav Lisovskiy 
Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
---
 drivers/gpu/drm/i915/display/intel_bw.c  | 52 +---
 drivers/gpu/drm/i915/display/intel_cdclk.c   | 19 ---
 drivers/gpu/drm/i915/display/intel_display.c | 26 +-
 3 files changed, 55 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a79bd7aeb03b..bd060404d249 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
struct intel_crtc *crtc;
int max_bw = 0;
int slice_id;
+   enum pipe pipe;
int i;
 
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
@@ -447,10 +448,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
*state)
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
 
+   old_bw_state = intel_atomic_get_old_bw_state(state);
+
crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
 
memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
 
+   if (!crtc_state->hw.active)
+   continue;
+
for_each_plane_id_on_crtc(crtc, plane_id) {
const struct skl_ddb_entry *plane_alloc =
&crtc_state->wm.skl.plane_ddb_y[plane_id];
@@ -478,6 +484,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
crtc_bw->used_bw[slice_id] += data_rate;
}
+   }
+
+   if (!old_bw_state)
+   return 0;
+
+   for_each_pipe(dev_priv, pipe) {
+   struct intel_dbuf_bw *crtc_bw;
+
+   crtc_bw = &new_bw_state->dbuf_bw[pipe];
 
for_each_dbuf_slice(slice_id) {
/*
@@ -490,14 +505,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
 */
max_bw += crtc_bw->used_bw[slice_id];
}
-
-   new_bw_state->min_cdclk = max_bw / 64;
-
-   old_bw_state = intel_atomic_get_old_bw_state(state);
}
 
-   if (!old_bw_state)
-   return 0;
+   new_bw_state->min_cdclk = max_bw / 64;
 
if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
int ret = intel_atomic_lock_global_state(&new_bw_state->base);
@@ -511,34 +521,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
*state)
 
 int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
 {
-   int i;
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   struct intel_bw_state *new_bw_state = NULL;
+   struct intel_bw_state *old_bw_state = NULL;
const struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
int min_cdclk = 0;
-   struct intel_bw_state *new_bw_state = NULL;
-   struct intel_bw_state *old_bw_state = NULL;
+   enum pipe pipe;
+   int i;
 
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
-   struct intel_cdclk_state *cdclk_state;
-
new_bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
 
-   cdclk_state = intel_atomic_get_cdclk_state(state);
-   if (IS_ERR(cdclk_state))
-   return PTR_ERR(cdclk_state);
-
-   min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk);
-
-   new_bw_state->min_cdclk = min_cdclk;
-
old_bw_state = intel_atomic_get_old_bw_state(state);
}
 
if (!old_bw_state)
return 0;
 
+   for_each_pipe(dev_priv, pipe) {
+   struct intel_cdclk_state *cdclk_state;
+
+   cdclk_state = intel_atomic_get_new_cdclk_state(state);
+   if (!cdclk_state)
+   return 0;
+
+   min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);
+   }
+
+   new_bw_state->min_cdclk = min_cdclk;
+
if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
int ret = intel_atomic_lo

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

2020-06-01 Thread Liviu Dudau
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
> 
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
> 
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
> 
> Big thanks to Tetsuo for helping track down what's going wrong here.
> 
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
>   __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
>   motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> 
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
> 
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
> 
> v2: Use the drm_dev_has_vblank() helper.
> 
> Link: 
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa 
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa 
> Cc: "James (Qian) Wang" 
> Cc: Liviu Dudau 
> Cc: Mihail Atanassov 
> Cc: Brian Starkey 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Brian Masney 
> Cc: Emil Velikov 
> Cc: zhengbin 
> Cc: Thomas Gleixner 
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
>  drivers/gpu/drm/arm/malidp_drv.c | 1 -

For the komeda and malidp drivers:

Acked-by: Liviu Dudau 

Best regards,
Liviu

>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
>  drivers/gpu/drm/drm_atomic_state_helper.c| 4 
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
>  drivers/gpu/drm/tegra/dc.c   | 1 -
>  drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
>  drivers/gpu/drm/tidss/tidss_kms.c| 4 
>  8 files changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
>   crtc->state = NULL;
>  
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = &state->base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
>  }
>  
>  static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>   return err;
>  
>   drm_crtc_helper_add(crtc, &komeda_crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>  
>   crtc->port = kcrtc->master->of_output_port;
>  
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c2507b7d8512..02904392e370 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
>   drm->irq_enabled = true;
>  
>   ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> - drm_crtc_vblank_reset(&malidp->crtc);
>   if (ret < 0) {
>   DRM_ERROR("failed to initialise vblank\n");
>   goto vblank_fail;
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 10985134ce0b..ce246b96330b 100644
> --- a/drivers/gpu/drm/atmel-hlcd

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Whitelist context-local timestamp in the gen9 cmdparser

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Whitelist context-local timestamp in the gen9 cmdparser
URL   : https://patchwork.freedesktop.org/series/77877/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8565 -> Patchwork_17833


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][1] -> [FAIL][2] ([i915#227])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17833/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [FAIL][3] ([i915#62]) -> [SKIP][4] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17833/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#227]: https://gitlab.freedesktop.org/drm/intel/issues/227
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (50 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8565 -> Patchwork_17833

  CI-20190529: 20190529
  CI_DRM_8565: 267bdbf5f8ba7c0931eb6c11a3b9eb893b10fead @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5689: 587cbed206689abbad60689d4a32bf9caf0cc124 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17833: 9d9cdd9da66e9c37b9a91aaecba4b86b10fbeee0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9d9cdd9da66e drm/i915: Whitelist context-local timestamp in the gen9 cmdparser

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Whitelist context-local timestamp in the gen9 cmdparser

2020-06-01 Thread Chris Wilson
Allow batch buffers to read their own _local_ cumulative HW runtime of
their logical context.

Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc:  # v5.4+
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 189b573d02be..372354d33f55 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -572,6 +572,9 @@ struct drm_i915_reg_descriptor {
 #define REG32(_reg, ...) \
{ .addr = (_reg), __VA_ARGS__ }
 
+#define REG32_IDX(_reg, idx) \
+   { .addr = _reg(idx) }
+
 /*
  * Convenience macro for adding 64-bit registers.
  *
@@ -669,6 +672,7 @@ static const struct drm_i915_reg_descriptor gen9_blt_regs[] 
= {
REG64_IDX(RING_TIMESTAMP, BSD_RING_BASE),
REG32(BCS_SWCTRL),
REG64_IDX(RING_TIMESTAMP, BLT_RING_BASE),
+   REG32_IDX(RING_CTX_TIMESTAMP, BLT_RING_BASE),
REG64_IDX(BCS_GPR, 0),
REG64_IDX(BCS_GPR, 1),
REG64_IDX(BCS_GPR, 2),
-- 
2.20.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Trim the ironlake+ irq handler (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Trim the ironlake+ irq handler (rev2)
URL   : https://patchwork.freedesktop.org/series/77871/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8565 -> Patchwork_17832


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17832/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (50 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8565 -> Patchwork_17832

  CI-20190529: 20190529
  CI_DRM_8565: 267bdbf5f8ba7c0931eb6c11a3b9eb893b10fead @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5689: 587cbed206689abbad60689d4a32bf9caf0cc124 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17832: b61fdbb8c3873e10973bd087a9811566cbb289e9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b61fdbb8c387 drm/i915: Trim the ironlake+ irq handler

== Logs ==

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Disable pre-parser for rewritten batches

2020-06-01 Thread Chris Wilson
Quoting Mika Kuoppala (2020-06-01 15:56:55)
> Chris Wilson  writes:
> 
> > As we rewrite the batches on the fly to implement the non-preemptible
> > lock, we need to tell Tigerlake to read the batch afresh each time.
> > Amusingly, the disable is a part of an arb-check, so we have to be
> > careful not to include the arbitration point inside our unpreemptible
> > loop.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/i915/gem_exec_balancer.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> > index 026f8347e..0e3b52900 100644
> > --- a/tests/i915/gem_exec_balancer.c
> > +++ b/tests/i915/gem_exec_balancer.c
> > @@ -1350,6 +1350,11 @@ static void __bonded_dual(int i915,
> >   *out = cycles;
> >  }
> >  
> > +static uint32_t preparser_disable(void)
> > +{
> > + return 0x5 << 23 | 1 << 8 | 1; /* preparser masked disable */
> 
> there is MI_ARB_CHECK
> 
> > +}
> > +
> >  static uint32_t sync_from(int i915, uint32_t addr, uint32_t target)
> >  {
> >   uint32_t handle = gem_create(i915, 4096);
> > @@ -1363,14 +1368,14 @@ static uint32_t sync_from(int i915, uint32_t addr, 
> > uint32_t target)
> >   *cs++ = 0;
> >   *cs++ = 0;
> >  
> > - *cs++ = MI_NOOP;
> > + *cs++ = preparser_disable();
> >   *cs++ = MI_NOOP;
> >   *cs++ = MI_NOOP;
> >   *cs++ = MI_NOOP;
> >  
> >   /* wait for them to cancel us */
> >   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> > - *cs++ = addr + 16;
> > + *cs++ = addr + 24;
> 
> I must be totally confused about the layout as I can't get
> the +8. You take one nop out and put one arb check in
> and everything moves with 8?

It's just skipping over the MI_ARB_CHECK, +4, aligned to the next qword
because some old habits die hard.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/panel: Reduce race window between bl_update_status and bl_enable

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915/panel: Reduce race window between bl_update_status and 
bl_enable
URL   : https://patchwork.freedesktop.org/series/77873/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8565 -> Patchwork_17831


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8565/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17831/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (50 -> 45)
--

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


Build changes
-

  * Linux: CI_DRM_8565 -> Patchwork_17831

  CI-20190529: 20190529
  CI_DRM_8565: 267bdbf5f8ba7c0931eb6c11a3b9eb893b10fead @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5689: 587cbed206689abbad60689d4a32bf9caf0cc124 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17831: bca3761377846e842068f30f26ae07d5d8b0e42b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bca376137784 drm/i915/panel: Reduce race window between bl_update_status and 
bl_enable

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/panel: Reduce race window between bl_update_status and bl_enable

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915/panel: Reduce race window between bl_update_status and 
bl_enable
URL   : https://patchwork.freedesktop.org/series/77873/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
bca376137784 drm/i915/panel: Reduce race window between bl_update_status and 
bl_enable
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#8: 
from userspace (which is stored in panel->backlight.device->props.brightness)

total: 0 errors, 1 warnings, 0 checks, 22 lines checked

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: lpsp with hdmi/dp outputs

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: lpsp with hdmi/dp outputs
URL   : https://patchwork.freedesktop.org/series/77866/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8561_full -> Patchwork_17829_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_hdmi_inject@inject-audio:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-tglb1/igt@kms_hdmi_inj...@inject-audio.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-tglb3/igt@kms_hdmi_inj...@inject-audio.html

  * igt@runner@aborted:
- shard-tglb: NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-tglb3/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl:  [PASS][4] -> [FAIL][5] ([i915#1528])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html

  * igt@gem_fenced_exec_thrash@no-spare-fences:
- shard-glk:  [PASS][6] -> [TIMEOUT][7] ([i915#1958]) +1 similar 
issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-glk5/igt@gem_fenced_exec_thr...@no-spare-fences.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-glk6/igt@gem_fenced_exec_thr...@no-spare-fences.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#454])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-iclb3/igt@i915_pm...@dc6-psr.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-iclb3/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-kbl:  [PASS][10] -> [INCOMPLETE][11] ([i915#151] / 
[i915#155])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-kbl7/igt@i915_pm_...@system-suspend-execbuf.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-kbl6/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#1119] / [i915#118] / 
[i915#95]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-glk5/igt@kms_big...@linear-64bpp-rotate-180.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html

  * igt@kms_cursor_legacy@cursora-vs-flipb-toggle:
- shard-glk:  [PASS][14] -> [DMESG-WARN][15] ([i915#1926])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-glk9/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-glk8/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl:  [PASS][16] -> [DMESG-WARN][17] ([i915#180])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl:  [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8561/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17829/shard-iclb4/igt@kms_psr@psr2_cursor_plane_onoff.html

  * igt@kms_setmode@basic:
- shard-hsw:  [PASS][22] -> [FAIL][23] ([i915#31])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_D

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Disable pre-parser for rewritten batches

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> As we rewrite the batches on the fly to implement the non-preemptible
> lock, we need to tell Tigerlake to read the batch afresh each time.
> Amusingly, the disable is a part of an arb-check, so we have to be
> careful not to include the arbitration point inside our unpreemptible
> loop.
>
> Signed-off-by: Chris Wilson 
> ---
>  tests/i915/gem_exec_balancer.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> index 026f8347e..0e3b52900 100644
> --- a/tests/i915/gem_exec_balancer.c
> +++ b/tests/i915/gem_exec_balancer.c
> @@ -1350,6 +1350,11 @@ static void __bonded_dual(int i915,
>   *out = cycles;
>  }
>  
> +static uint32_t preparser_disable(void)
> +{
> + return 0x5 << 23 | 1 << 8 | 1; /* preparser masked disable */

there is MI_ARB_CHECK

> +}
> +
>  static uint32_t sync_from(int i915, uint32_t addr, uint32_t target)
>  {
>   uint32_t handle = gem_create(i915, 4096);
> @@ -1363,14 +1368,14 @@ static uint32_t sync_from(int i915, uint32_t addr, 
> uint32_t target)
>   *cs++ = 0;
>   *cs++ = 0;
>  
> - *cs++ = MI_NOOP;
> + *cs++ = preparser_disable();
>   *cs++ = MI_NOOP;
>   *cs++ = MI_NOOP;
>   *cs++ = MI_NOOP;
>  
>   /* wait for them to cancel us */
>   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> - *cs++ = addr + 16;
> + *cs++ = addr + 24;

I must be totally confused about the layout as I can't get
the +8. You take one nop out and put one arb check in
and everything moves with 8?

-Mika

>   *cs++ = 0;
>  
>   /* self-heal */
> @@ -1393,14 +1398,14 @@ static uint32_t sync_to(int i915, uint32_t addr, 
> uint32_t target)
>  
>   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
>  
> - *cs++ = MI_NOOP;
> + *cs++ = preparser_disable();
>   *cs++ = MI_NOOP;
>   *cs++ = MI_NOOP;
>   *cs++ = MI_NOOP;
>  
>   /* wait to be cancelled */
>   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> - *cs++ = addr;
> + *cs++ = addr + 8;
>   *cs++ = 0;
>  
>   /* cancel their spin as a compliment */
> -- 
> 2.27.0.rc2
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount

2020-06-01 Thread Ville Syrjälä
On Mon, Jun 01, 2020 at 10:59:29AM +0300, Lisovskiy, Stanislav wrote:
> On Fri, May 29, 2020 at 08:11:43AM +0300, Ville Syrjälä wrote:
> > On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > While the current locking/serialization of the global state
> > > > > suffices for protecting the obj->state access and the actual
> > > > > hardware reprogramming, we do have a problem with accessing
> > > > > the old/new states during nonblocking commits.
> > > > > 
> > > > > The state computation and swap will be protected by the crtc
> > > > > locks, but the commit_tails can finish out of order, thus also
> > > > > causing the atomic states to be cleaned up out of order. This
> > > > > would mean the commit that started first but finished last has
> > > > > had its new state freed as the no-longer-needed old state by the
> > > > > other commit.
> > > > > 
> > > > > To fix this let's just refcount the states. obj->state amounts
> > > > > to one reference, and the intel_atomic_state holds extra references
> > > > > to both its new and old global obj states.
> > > > > 
> > > > > Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state 
> > > > > handling")
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  .../gpu/drm/i915/display/intel_global_state.c | 45 
> > > > > ---
> > > > >  .../gpu/drm/i915/display/intel_global_state.h |  3 ++
> > > > >  2 files changed, 42 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > > index 212d4ee68205..7a19215ad844 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > > @@ -10,6 +10,28 @@
> > > > >  #include "intel_display_types.h"
> > > > >  #include "intel_global_state.h"
> > > > >  
> > > > > +static void __intel_atomic_global_state_free(struct kref *kref)
> > > > > +{
> > > > > + struct intel_global_state *obj_state =
> > > > > + container_of(kref, struct intel_global_state, ref);
> > > > > + struct intel_global_obj *obj = obj_state->obj;
> > > > > +
> > > > > + obj->funcs->atomic_destroy_state(obj, obj_state);
> > > > > +}
> > > > > +
> > > > > +static void intel_atomic_global_state_put(struct intel_global_state 
> > > > > *obj_state)
> > > > > +{
> > > > > + kref_put(&obj_state->ref, __intel_atomic_global_state_free);
> > > > > +}
> > > > > +
> > > > > +static struct intel_global_state *
> > > > > +intel_atomic_global_state_get(struct intel_global_state *obj_state)
> > > > > +{
> > > > > + kref_get(&obj_state->ref);
> > > > > +
> > > > > + return obj_state;
> > > > > +}
> > > > > +
> > > > >  void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> > > > > struct intel_global_obj *obj,
> > > > > struct intel_global_state *state,
> > > > > @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct 
> > > > > drm_i915_private *dev_priv,
> > > > >  {
> > > > >   memset(obj, 0, sizeof(*obj));
> > > > >  
> > > > > + state->obj = obj;
> > > > > +
> > > > > + kref_init(&state->ref);
> > > > > +
> > > > >   obj->state = state;
> > > > >   obj->funcs = funcs;
> > > > >   list_add_tail(&obj->head, &dev_priv->global_obj_list);
> > > > > @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct 
> > > > > drm_i915_private *dev_priv)
> > > > >  
> > > > >   list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, 
> > > > > head) {
> > > > >   list_del(&obj->head);
> > > > > - obj->funcs->atomic_destroy_state(obj, obj->state);
> > > > > +
> > > > > + drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) 
> > > > > != 1);
> > > > > + intel_atomic_global_state_put(obj->state);
> > > > >   }
> > > > >  }
> > > > >  
> > > > > @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct 
> > > > > intel_atomic_state *state,
> > > > >   if (!obj_state)
> > > > >   return ERR_PTR(-ENOMEM);
> > > > >  
> > > > > + obj_state->obj = obj;
> > > > >   obj_state->changed = false;
> > > > >  
> > > > > + kref_init(&obj_state->ref);
> > > > > +
> > > > >   state->global_objs[index].state = obj_state;
> > > > > - state->global_objs[index].old_state = obj->state;
> > > > > + state->global_objs[index].old_state =
> > > > > + intel_atomic_global_state_get(obj->state);
> > > > >   state->global_objs[index].new_state = obj_state;
> > > > >   state->global_objs[index].ptr = obj;
> > > > >   obj_state->state = state;
> > > > > @@ -163,7 +195,9 @@ void intel_atomic_swap_glob

Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Lisovskiy, Stanislav
On Mon, Jun 01, 2020 at 05:01:08PM +0300, Dan Carpenter wrote:
> Hi Stanislav,
> 
> url:
> https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Fix-wrong-CDCLK-adjustment-changes/20200526-180642
> base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> config: i386-randconfig-m021-20200531 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot 
> Reported-by: Dan Carpenter 
> 
> smatch warnings:
> drivers/gpu/drm/i915/display/intel_bw.c:453 skl_bw_calc_min_cdclk() error: 
> uninitialized symbol 'pipe'.
> 
> # 
> https://github.com/0day-ci/linux/commit/21b0324886122a396687d977d67eb6ce3caf2b17
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 21b0324886122a396687d977d67eb6ce3caf2b17
> vim +/pipe +453 drivers/gpu/drm/i915/display/intel_bw.c
> 
> 366b6200f76e0f Jani Nikula 2019-08-06  430  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  431  int 
> skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
> cd19154608610a Stanislav Lisovskiy 2020-05-20  432  {
> cd19154608610a Stanislav Lisovskiy 2020-05-20  433struct drm_i915_private 
> *dev_priv = to_i915(state->base.dev);
> cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  434struct intel_bw_state 
> *new_bw_state = NULL;
> cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  435struct intel_bw_state 
> *old_bw_state = NULL;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  436const struct 
> intel_crtc_state *crtc_state;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  437struct intel_crtc *crtc;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  438int max_bw = 0;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  439int slice_id;
> 21b0324886122a Stanislav Lisovskiy 2020-05-26  440enum pipe pipe;
> cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  441int i;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  442  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  443
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> cd19154608610a Stanislav Lisovskiy 2020-05-20  444enum plane_id 
> plane_id;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  445struct 
> intel_dbuf_bw *crtc_bw;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  446  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  447new_bw_state = 
> intel_atomic_get_bw_state(state);
> cd19154608610a Stanislav Lisovskiy 2020-05-20  448if 
> (IS_ERR(new_bw_state))
> cd19154608610a Stanislav Lisovskiy 2020-05-20  449return 
> PTR_ERR(new_bw_state);
> cd19154608610a Stanislav Lisovskiy 2020-05-20  450  
> 21b0324886122a Stanislav Lisovskiy 2020-05-26  451old_bw_state = 
> intel_atomic_get_old_bw_state(state);
> 21b0324886122a Stanislav Lisovskiy 2020-05-26  452  
> 21b0324886122a Stanislav Lisovskiy 2020-05-26 @453crtc_bw = 
> &new_bw_state->dbuf_bw[pipe];
>   
>
> Not initialized.  Probably "i" was intended?

Ahh.. Rather silly typo - it should be crtc->pipe.
Thanks for spotting.

Stan

> 
> cd19154608610a Stanislav Lisovskiy 2020-05-20  454  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  455
> memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> cd19154608610a Stanislav Lisovskiy 2020-05-20  456  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  457
> for_each_plane_id_on_crtc(crtc, plane_id) {
> cd19154608610a Stanislav Lisovskiy 2020-05-20  458const 
> struct skl_ddb_entry *plane_alloc =
> cd19154608610a Stanislav Lisovskiy 2020-05-20  459
> &crtc_state->wm.skl.plane_ddb_y[plane_id];
> cd19154608610a Stanislav Lisovskiy 2020-05-20  460const 
> struct skl_ddb_entry *uv_plane_alloc =
> cd19154608610a Stanislav Lisovskiy 2020-05-20  461
> &crtc_state->wm.skl.plane_ddb_uv[plane_id];
> cd19154608610a Stanislav Lisovskiy 2020-05-20  462
> unsigned int data_rate = crtc_state->data_rate[plane_id];
> cd19154608610a Stanislav Lisovskiy 2020-05-20  463
> unsigned int dbuf_mask = 0;
> cd19154608610a Stanislav Lisovskiy 2020-05-20  464  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  465
> dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, plane_alloc);
> cd19154608610a Stanislav Lisovskiy 2020-05-20  466
> dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, uv_plane_alloc);
> cd19154608610a Stanislav Lisovskiy 2020-05-20  467  
> cd19154608610a Stanislav Lisovskiy 2020-05-20  468/*
> cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  469 * 
> FIXME: To calculate that more properly we probably
> cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  470  

Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-01 Thread Ville Syrjälä
On Mon, Jun 01, 2020 at 03:45:16PM +0530, Anshuman Gupta wrote:
> Gen12 hw are failing to enable lpsp configuration due to PG3 was left on
> due to valid usgae count of POWER_DOMAIN_AUDIO.
> It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling
> a crtc, it should be always i915_audio_component request to get/put
> AUDIO_POWER_DOMAIN.
> 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6c3b11de2daf..f31a579d7a52 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct 
> intel_crtc_state *crtc_state)
>   mask |= BIT_ULL(intel_encoder->power_domain);
>   }
>  
> - if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> + /*
> +  * Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
> +  * enable AUDIO power in order to enable a crtc

Nothing requires audio power to enable a crtc. What this is saying is
that if we want audio then we must enable the audio power. If you
didn't want audio then you wouldn't have .has_audio set.

That said, looks like audio is moving into the always on well, but not
yet in tgl.

.
> +  */
> + if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) && 
> crtc_state->has_audio)
>   mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
>  
>   if (crtc_state->shared_dpll)
> -- 
> 2.26.2

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Chris Wilson
Ever noticed that our interrupt handlers are where we spend most of our
time on a busy system? In part this is unavoidable as each interrupt
requires to poll and reset several registers, but we can try and do so as
efficiently as possible.

Function old new   delta
ilk_irq_handler 23172156-161

v2: Restore the irqreturn_t ret

Function old new   delta
ilk_irq_handler.cold  63  72  +9
ilk_irq_handler 22212080-141

A slight improvement in the baseline overnight as well!

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 57 +
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 63579ab71cf6..490574669eaa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2097,67 +2097,68 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
  */
 static irqreturn_t ilk_irq_handler(int irq, void *arg)
 {
-   struct drm_i915_private *dev_priv = arg;
+   struct drm_i915_private *i915 = arg;
+   void __iomem * const regs = i915->uncore.regs;
u32 de_iir, gt_iir, de_ier, sde_ier = 0;
irqreturn_t ret = IRQ_NONE;
 
-   if (!intel_irqs_enabled(dev_priv))
+   if (unlikely(!intel_irqs_enabled(i915)))
return IRQ_NONE;
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   disable_rpm_wakeref_asserts(&i915->runtime_pm);
 
/* disable master interrupt before clearing iir  */
-   de_ier = I915_READ(DEIER);
-   I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
+   de_ier = raw_reg_read(regs, DEIER);
+   raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
 
/* Disable south interrupts. We'll only write to SDEIIR once, so further
 * interrupts will will be stored on its back queue, and then we'll be
 * able to process them after we restore SDEIER (as soon as we restore
 * it, we'll get an interrupt if SDEIIR still has something to process
 * due to its back queue). */
-   if (!HAS_PCH_NOP(dev_priv)) {
-   sde_ier = I915_READ(SDEIER);
-   I915_WRITE(SDEIER, 0);
+   if (!HAS_PCH_NOP(i915)) {
+   sde_ier = raw_reg_read(regs, SDEIER);
+   raw_reg_write(regs, SDEIER, 0);
}
 
/* Find, clear, then process each source of interrupt */
 
-   gt_iir = I915_READ(GTIIR);
+   gt_iir = raw_reg_read(regs, GTIIR);
if (gt_iir) {
-   I915_WRITE(GTIIR, gt_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 6)
-   gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
+   raw_reg_write(regs, GTIIR, gt_iir);
+   if (INTEL_GEN(i915) >= 6)
+   gen6_gt_irq_handler(&i915->gt, gt_iir);
else
-   gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
+   gen5_gt_irq_handler(&i915->gt, gt_iir);
+   ret = IRQ_HANDLED;
}
 
-   de_iir = I915_READ(DEIIR);
+   de_iir = raw_reg_read(regs, DEIIR);
if (de_iir) {
-   I915_WRITE(DEIIR, de_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 7)
-   ivb_display_irq_handler(dev_priv, de_iir);
+   raw_reg_write(regs, DEIIR, de_iir);
+   if (INTEL_GEN(i915) >= 7)
+   ivb_display_irq_handler(i915, de_iir);
else
-   ilk_display_irq_handler(dev_priv, de_iir);
+   ilk_display_irq_handler(i915, de_iir);
+   ret = IRQ_HANDLED;
}
 
-   if (INTEL_GEN(dev_priv) >= 6) {
-   u32 pm_iir = I915_READ(GEN6_PMIIR);
+   if (INTEL_GEN(i915) >= 6) {
+   u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
if (pm_iir) {
-   I915_WRITE(GEN6_PMIIR, pm_iir);
+   raw_reg_write(regs, GEN6_PMIIR, pm_iir);
+   gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
ret = IRQ_HANDLED;
-   gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
}
}
 
-   I915_WRITE(DEIER, de_ier);
-   if (!HAS_PCH_NOP(dev_priv))
-   I915_WRITE(SDEIER, sde_ier);
+   raw_reg_write(regs, DEIER, de_ier);
+   if (sde_ier)
+   raw_reg_write(regs, SDEIER, sde_ier);
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   enable_rpm_wakeref_

Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Dan Carpenter
Hi Stanislav,

url:
https://github.com/0day-ci/linux/commits/Stanislav-Lisovskiy/drm-i915-Fix-wrong-CDCLK-adjustment-changes/20200526-180642
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-m021-20200531 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 
Reported-by: Dan Carpenter 

smatch warnings:
drivers/gpu/drm/i915/display/intel_bw.c:453 skl_bw_calc_min_cdclk() error: 
uninitialized symbol 'pipe'.

# 
https://github.com/0day-ci/linux/commit/21b0324886122a396687d977d67eb6ce3caf2b17
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 21b0324886122a396687d977d67eb6ce3caf2b17
vim +/pipe +453 drivers/gpu/drm/i915/display/intel_bw.c

366b6200f76e0f Jani Nikula 2019-08-06  430  
cd19154608610a Stanislav Lisovskiy 2020-05-20  431  int 
skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
cd19154608610a Stanislav Lisovskiy 2020-05-20  432  {
cd19154608610a Stanislav Lisovskiy 2020-05-20  433  struct drm_i915_private 
*dev_priv = to_i915(state->base.dev);
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  434  struct intel_bw_state 
*new_bw_state = NULL;
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  435  struct intel_bw_state 
*old_bw_state = NULL;
cd19154608610a Stanislav Lisovskiy 2020-05-20  436  const struct 
intel_crtc_state *crtc_state;
cd19154608610a Stanislav Lisovskiy 2020-05-20  437  struct intel_crtc *crtc;
cd19154608610a Stanislav Lisovskiy 2020-05-20  438  int max_bw = 0;
cd19154608610a Stanislav Lisovskiy 2020-05-20  439  int slice_id;
21b0324886122a Stanislav Lisovskiy 2020-05-26  440  enum pipe pipe;
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  441  int i;
cd19154608610a Stanislav Lisovskiy 2020-05-20  442  
cd19154608610a Stanislav Lisovskiy 2020-05-20  443  
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
cd19154608610a Stanislav Lisovskiy 2020-05-20  444  enum plane_id 
plane_id;
cd19154608610a Stanislav Lisovskiy 2020-05-20  445  struct 
intel_dbuf_bw *crtc_bw;
cd19154608610a Stanislav Lisovskiy 2020-05-20  446  
cd19154608610a Stanislav Lisovskiy 2020-05-20  447  new_bw_state = 
intel_atomic_get_bw_state(state);
cd19154608610a Stanislav Lisovskiy 2020-05-20  448  if 
(IS_ERR(new_bw_state))
cd19154608610a Stanislav Lisovskiy 2020-05-20  449  return 
PTR_ERR(new_bw_state);
cd19154608610a Stanislav Lisovskiy 2020-05-20  450  
21b0324886122a Stanislav Lisovskiy 2020-05-26  451  old_bw_state = 
intel_atomic_get_old_bw_state(state);
21b0324886122a Stanislav Lisovskiy 2020-05-26  452  
21b0324886122a Stanislav Lisovskiy 2020-05-26 @453  crtc_bw = 
&new_bw_state->dbuf_bw[pipe];

 
Not initialized.  Probably "i" was intended?

cd19154608610a Stanislav Lisovskiy 2020-05-20  454  
cd19154608610a Stanislav Lisovskiy 2020-05-20  455  
memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
cd19154608610a Stanislav Lisovskiy 2020-05-20  456  
cd19154608610a Stanislav Lisovskiy 2020-05-20  457  
for_each_plane_id_on_crtc(crtc, plane_id) {
cd19154608610a Stanislav Lisovskiy 2020-05-20  458  const 
struct skl_ddb_entry *plane_alloc =
cd19154608610a Stanislav Lisovskiy 2020-05-20  459  
&crtc_state->wm.skl.plane_ddb_y[plane_id];
cd19154608610a Stanislav Lisovskiy 2020-05-20  460  const 
struct skl_ddb_entry *uv_plane_alloc =
cd19154608610a Stanislav Lisovskiy 2020-05-20  461  
&crtc_state->wm.skl.plane_ddb_uv[plane_id];
cd19154608610a Stanislav Lisovskiy 2020-05-20  462  
unsigned int data_rate = crtc_state->data_rate[plane_id];
cd19154608610a Stanislav Lisovskiy 2020-05-20  463  
unsigned int dbuf_mask = 0;
cd19154608610a Stanislav Lisovskiy 2020-05-20  464  
cd19154608610a Stanislav Lisovskiy 2020-05-20  465  
dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, plane_alloc);
cd19154608610a Stanislav Lisovskiy 2020-05-20  466  
dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv, uv_plane_alloc);
cd19154608610a Stanislav Lisovskiy 2020-05-20  467  
cd19154608610a Stanislav Lisovskiy 2020-05-20  468  /*
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  469   * 
FIXME: To calculate that more properly we probably
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  470   * need 
to to split per plane data_rate into data_rate_y
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  471   * and 
data_rate_uv for multiplanar formats in order not
cac91e671ad5dc Stanislav Lisovskiy 2020-05-22  472   * to

[Intel-gfx] [PATCH] drm/i915/panel: Reduce race window between bl_update_status and bl_enable

2020-06-01 Thread Sean Paul
From: Sean Paul 

If the backlight is updated while the panel is being enabled, the value
from userspace (which is stored in panel->backlight.device->props.brightness)
can be replaced by the hardware's minimum level. There's really no good
way to tell if this is happening in enable_backlight() since
props.brightness can be initialized to the same value as is being set by
userspace. So we'll try to reduce the race window as much as possible.

Signed-off-by: Sean Paul 
---

I don't think there's any way to eliminate this race since grabbing
bd->op_lock in panel_enable would cause a lock inversion deadlock with
the connection_mutex lock in backlight_device_update_status

Suggestions very much welcome!

 drivers/gpu/drm/i915/display/intel_panel.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 3c5056dbf607..abdfb9cc281b 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1285,8 +1285,22 @@ static int intel_backlight_device_update_status(struct 
backlight_device *bd)
struct intel_connector *connector = bl_get_data(bd);
struct intel_panel *panel = &connector->panel;
struct drm_device *dev = connector->base.dev;
+   int value;
+
+   /*
+* Before we attempt to grab the connection mutex, cache the incoming
+* brightness value. If we're in the middle of a modeset,
+* intel_panel_enable_backlight will be called and could pave over
+* props.brightness. This is still racey, but the race window should be
+* significantly smaller and reflects the inherent raceyness of the
+* updating props.brightness outside of bd->op_lock.
+*/
+   value = bd->props.brightness;
 
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+
+   bd->props.brightness = value;
+
DRM_DEBUG_KMS("updating intel_backlight, brightness=%d/%d\n",
  bd->props.brightness, bd->props.max_brightness);
intel_panel_set_backlight(connector->base.state, bd->props.brightness,
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Trim the ironlake+ irq handler
URL   : https://patchwork.freedesktop.org/series/77871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8562 -> Patchwork_17830


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-cml-s:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8562/fi-cml-s/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17830/fi-cml-s/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_pm:
- fi-bsw-n3050:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8562/fi-bsw-n3050/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17830/fi-bsw-n3050/igt@i915_selftest@live@gt_pm.html

  


Participating hosts (51 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8562 -> Patchwork_17830

  CI-20190529: 20190529
  CI_DRM_8562: bd08b2b513aeceb9b1beaa7d23e6bc11cc590d6f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5689: 587cbed206689abbad60689d4a32bf9caf0cc124 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17830: a883f972cf7ac10a4fee4260afdd95e9f08ede8a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a883f972cf7a drm/i915: Trim the ironlake+ irq handler

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> Ever noticed that our interrupt handlers are where we spend most of our
> time on a busy system? In part this is unavoidable as each interrupt
> requires to poll and reset several registers, but we can try and do so as
> efficiently as possible.
>
> Function old new   delta
> ilk_irq_handler 23172156-161
>
> v2: Restore the irqreturn_t ret
>
> Function old new   delta
> ilk_irq_handler.cold  63  72  +9
> ilk_irq_handler 22212080-141
>
> A slight improvement in the baseline overnight as well!
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 59 +
>  1 file changed, 30 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 63579ab71cf6..01d4e3cad69d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2097,67 +2097,68 @@ static void ivb_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   */
>  static irqreturn_t ilk_irq_handler(int irq, void *arg)
>  {
> - struct drm_i915_private *dev_priv = arg;
> + struct drm_i915_private *i915 = arg;
> + void __iomem * const regs = i915->uncore.regs;
>   u32 de_iir, gt_iir, de_ier, sde_ier = 0;
>   irqreturn_t ret = IRQ_NONE;
>  
> - if (!intel_irqs_enabled(dev_priv))
> + if (unlikely(!intel_irqs_enabled(i915)))

Doesn't hurt anymore.

And dont have to worry about ret so only thing different is
void of forcewake dance.

Reviewed-by: Mika Kuoppala 

>   return IRQ_NONE;
>  
>   /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> - disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> + disable_rpm_wakeref_asserts(&i915->runtime_pm);
>  
>   /* disable master interrupt before clearing iir  */
> - de_ier = I915_READ(DEIER);
> - I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> + de_ier = raw_reg_read(regs, DEIER);
> + raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
>  
>   /* Disable south interrupts. We'll only write to SDEIIR once, so further
>* interrupts will will be stored on its back queue, and then we'll be
>* able to process them after we restore SDEIER (as soon as we restore
>* it, we'll get an interrupt if SDEIIR still has something to process
>* due to its back queue). */
> - if (!HAS_PCH_NOP(dev_priv)) {
> - sde_ier = I915_READ(SDEIER);
> - I915_WRITE(SDEIER, 0);
> + if (!HAS_PCH_NOP(i915)) {
> + sde_ier = raw_reg_read(regs, SDEIER);
> + raw_reg_write(regs, SDEIER, 0);
>   }
>  
>   /* Find, clear, then process each source of interrupt */
>  
> - gt_iir = I915_READ(GTIIR);
> + gt_iir = raw_reg_read(regs, GTIIR);
>   if (gt_iir) {
> - I915_WRITE(GTIIR, gt_iir);
> - ret = IRQ_HANDLED;
> - if (INTEL_GEN(dev_priv) >= 6)
> - gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
> + raw_reg_write(regs, GTIIR, gt_iir);
> + if (INTEL_GEN(i915) >= 6)
> + gen6_gt_irq_handler(&i915->gt, gt_iir);
>   else
> - gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
> + gen5_gt_irq_handler(&i915->gt, gt_iir);
> + ret = IRQ_HANDLED;
>   }
>  
> - de_iir = I915_READ(DEIIR);
> + de_iir = raw_reg_read(regs, DEIIR);
>   if (de_iir) {
> - I915_WRITE(DEIIR, de_iir);
> - ret = IRQ_HANDLED;
> - if (INTEL_GEN(dev_priv) >= 7)
> - ivb_display_irq_handler(dev_priv, de_iir);
> + raw_reg_write(regs, DEIIR, de_iir);
> + if (INTEL_GEN(i915) >= 7)
> + ivb_display_irq_handler(i915, de_iir);
>   else
> - ilk_display_irq_handler(dev_priv, de_iir);
> + ilk_display_irq_handler(i915, de_iir);
> + ret = IRQ_HANDLED;
>   }
>  
> - if (INTEL_GEN(dev_priv) >= 6) {
> - u32 pm_iir = I915_READ(GEN6_PMIIR);
> + if (INTEL_GEN(i915) >= 6) {
> + u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
>   if (pm_iir) {
> - I915_WRITE(GEN6_PMIIR, pm_iir);
> - ret = IRQ_HANDLED;
> - gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
> + raw_reg_write(regs, GEN6_PMIIR, pm_iir);
> + gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
>   }
> + ret = IRQ_HANDLED;
>   }
>  
> - I915_WRITE(DEIER, de_ier);
> - if (!HAS_PCH_NOP(dev_priv))
> - I915_WRITE(SDEIER, sde_ier);
> + raw_reg_write(regs, DEIER, de_ier);
>

Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-01 Thread Shankar, Uma


> -Original Message-
> From: Intel-gfx  On Behalf Of
> Anshuman Gupta
> Sent: Monday, June 1, 2020 3:45 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Subject: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs
> 
> Gen12 hw are failing to enable lpsp configuration due to PG3 was left on due 
> to
> valid usgae count of POWER_DOMAIN_AUDIO.
> It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling a crtc,
> it should be always i915_audio_component request to get/put
> AUDIO_POWER_DOMAIN.
> 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6c3b11de2daf..f31a579d7a52 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct
> intel_crtc_state *crtc_state)
>   mask |= BIT_ULL(intel_encoder->power_domain);
>   }
> 
> - if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> + /*
> +  * Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
> +  * enable AUDIO power in order to enable a crtc.
> +  */
> + if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) &&
> +crtc_state->has_audio)
>   mask |= BIT_ULL(POWER_DOMAIN_AUDIO);

As part of ddi_get_config we determine has_audio using power well enabled:
pipe_config->has_audio =
intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);

If audio power domain is not enabled, we may end up with this as false.
Later this may get checked in intel_enable_ddi_hdmi to call audio codec enable

if (crtc_state->has_audio)
intel_audio_codec_enable(encoder, crtc_state, conn_state);

This may cause detection to fail. Please verify this usecase once and confirm.

Regards,
Uma Shankar

>   if (crtc_state->shared_dpll)
> --
> 2.26.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 13/36] drm/i915: Relinquish forcewake immediately after manual grouping

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> Our forcewake utilisation is split into categories: automatic and
> manual. Around bare register reads, we look up the right forcewake
> domain and automatically acquire and release [upon a timer] the
> forcewake domain. For other access, where we know we require the
> forcewake across a group of register reads, we manually acquire the
> forcewake domain and release it at the end. Again, this currently arms
> the domain timer for a later release.
>
> However, looking at some energy utilisation profiles, we have tried to
> avoid using forcewake [and rely on the natural wake up to post register
> updates] due to that even keep the fw active for a brief period
> contributes to a significant power draw [i.e. when the gpu is sleeping
> with rc6 at high clocks]. But as it turns out, not posting the writes
> immediately also has unintended consequences, such as not reducing the
> clocks and so conserving power while busy.
>
> As a compromise, let us only arm the domain timer for automatic
> forcewake usage around bare register access, but immediately release the
> forcewake when manually acquired by intel_uncore_forcewake_get/_put.
>
> The corollary to this is that we may instead have to take forcewake more
> often, and so incur a latency penalty in doing so. For Sandybridge this
> was significant, and even on the latest machines, taking forcewake at
> interrupt frequency is a huge impact. [So we don't do that anymore!
> Hopefully, this will spare us from still needing the mitigation of the
> timer for steady state execution.]
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 

I am not a fan of having explicit put relying on timer,
Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index a61cb8ca4d50..7d6b9ae7403c 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -709,7 +709,7 @@ static void __intel_uncore_forcewake_put(struct 
> intel_uncore *uncore,
>   continue;
>   }
>  
> - fw_domain_arm_timer(domain);
> + uncore->funcs.force_wake_put(uncore, domain->mask);
>   }
>  }
>  
> -- 
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 12/36] drm/i915/gt: Track if an engine requires forcewake w/a

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> Sometimes an engine might need to keep forcewake active while it is busy
> submitting requests for a particular workaround. Track such nuisance
> with engine->fw_domain.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_types.h   | 9 +
>  drivers/gpu/drm/i915/gt/intel_ring_scheduler.c | 4 
>  2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 3782e27c2945..ccdd69923793 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -313,6 +313,15 @@ struct intel_engine_cs {
>   u32 context_size;
>   u32 mmio_base;
>  
> + /*
> +  * Some w/a require forcewake to be held (which prevents RC6) while
> +  * a particular engine is active. If so, we set fw_domain to which
> +  * domains need to be held for the duration of request activity,
> +  * and 0 if none.
> +  */
> + unsigned int fw_domain;
> + unsigned int fw_active;
> +
>   unsigned long context_tag;
>  
>   struct rb_node uabi_node;
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
> index aaff554865b1..777cab6d9540 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
> @@ -60,6 +60,8 @@ static struct i915_request *
>  schedule_in(struct intel_engine_cs *engine, struct i915_request *rq)
>  {
>   __intel_gt_pm_get(engine->gt);
> + if (!engine->fw_active++ && engine->fw_domain)
> + intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
>   intel_engine_context_in(engine);
>   return i915_request_get(rq);
>  }
> @@ -74,6 +76,8 @@ schedule_out(struct intel_engine_cs *engine, struct 
> i915_request *rq)
>  
>   i915_request_put(rq);
>   intel_engine_context_out(engine);
> + if (!--engine->fw_active && engine->fw_domain)
> + intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
>   intel_gt_pm_put_async(engine->gt);
>  }
>  
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Chris Wilson
Ever noticed that our interrupt handlers are where we spend most of our
time on a busy system? In part this is unavoidable as each interrupt
requires to poll and reset several registers, but we can try and do so as
efficiently as possible.

Function old new   delta
ilk_irq_handler 23172156-161

v2: Restore the irqreturn_t ret

Function old new   delta
ilk_irq_handler.cold  63  72  +9
ilk_irq_handler 22212080-141

A slight improvement in the baseline overnight as well!

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 59 +
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 63579ab71cf6..01d4e3cad69d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2097,67 +2097,68 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
  */
 static irqreturn_t ilk_irq_handler(int irq, void *arg)
 {
-   struct drm_i915_private *dev_priv = arg;
+   struct drm_i915_private *i915 = arg;
+   void __iomem * const regs = i915->uncore.regs;
u32 de_iir, gt_iir, de_ier, sde_ier = 0;
irqreturn_t ret = IRQ_NONE;
 
-   if (!intel_irqs_enabled(dev_priv))
+   if (unlikely(!intel_irqs_enabled(i915)))
return IRQ_NONE;
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   disable_rpm_wakeref_asserts(&i915->runtime_pm);
 
/* disable master interrupt before clearing iir  */
-   de_ier = I915_READ(DEIER);
-   I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
+   de_ier = raw_reg_read(regs, DEIER);
+   raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
 
/* Disable south interrupts. We'll only write to SDEIIR once, so further
 * interrupts will will be stored on its back queue, and then we'll be
 * able to process them after we restore SDEIER (as soon as we restore
 * it, we'll get an interrupt if SDEIIR still has something to process
 * due to its back queue). */
-   if (!HAS_PCH_NOP(dev_priv)) {
-   sde_ier = I915_READ(SDEIER);
-   I915_WRITE(SDEIER, 0);
+   if (!HAS_PCH_NOP(i915)) {
+   sde_ier = raw_reg_read(regs, SDEIER);
+   raw_reg_write(regs, SDEIER, 0);
}
 
/* Find, clear, then process each source of interrupt */
 
-   gt_iir = I915_READ(GTIIR);
+   gt_iir = raw_reg_read(regs, GTIIR);
if (gt_iir) {
-   I915_WRITE(GTIIR, gt_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 6)
-   gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
+   raw_reg_write(regs, GTIIR, gt_iir);
+   if (INTEL_GEN(i915) >= 6)
+   gen6_gt_irq_handler(&i915->gt, gt_iir);
else
-   gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
+   gen5_gt_irq_handler(&i915->gt, gt_iir);
+   ret = IRQ_HANDLED;
}
 
-   de_iir = I915_READ(DEIIR);
+   de_iir = raw_reg_read(regs, DEIIR);
if (de_iir) {
-   I915_WRITE(DEIIR, de_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 7)
-   ivb_display_irq_handler(dev_priv, de_iir);
+   raw_reg_write(regs, DEIIR, de_iir);
+   if (INTEL_GEN(i915) >= 7)
+   ivb_display_irq_handler(i915, de_iir);
else
-   ilk_display_irq_handler(dev_priv, de_iir);
+   ilk_display_irq_handler(i915, de_iir);
+   ret = IRQ_HANDLED;
}
 
-   if (INTEL_GEN(dev_priv) >= 6) {
-   u32 pm_iir = I915_READ(GEN6_PMIIR);
+   if (INTEL_GEN(i915) >= 6) {
+   u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
if (pm_iir) {
-   I915_WRITE(GEN6_PMIIR, pm_iir);
-   ret = IRQ_HANDLED;
-   gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
+   raw_reg_write(regs, GEN6_PMIIR, pm_iir);
+   gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
}
+   ret = IRQ_HANDLED;
}
 
-   I915_WRITE(DEIER, de_ier);
-   if (!HAS_PCH_NOP(dev_priv))
-   I915_WRITE(SDEIER, sde_ier);
+   raw_reg_write(regs, DEIER, de_ier);
+   if (sde_ier)
+   raw_reg_write(regs, SDEIER, sde_ier);
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   enable_rpm_w

Re: [Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Chris Wilson
Quoting Chris Wilson (2020-06-01 13:00:43)
> Quoting Mika Kuoppala (2020-06-01 12:49:49)
> > Chris Wilson  writes:
> > 
> > > Ever noticed that our interrupt handlers are where we spend most of our
> > > time on a busy system? In part this is unavoidable as each interrupt
> > > requires to poll and reset several registers, but we can try and so as
> > > efficiently as possible.
> > >
> > > Function old new   delta
> > > ilk_irq_handler 23172156-161

With irqreturn_t ret,

ilk_irq_handler.cold  63  72  +9
ilk_irq_handler 22212083-138

I love how it can change so much simply by recompiling the baseline.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6] drm/i915: Add Plane color encoding support for YCBCR_BT2020

2020-06-01 Thread Shankar, Uma



> -Original Message-
> From: Kadiyala, Kishore 
> Sent: Monday, June 1, 2020 1:06 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kadiyala, Kishore ; Ville Syrjala
> ; Nikula, Jani ; 
> Shankar,
> Uma 
> Subject: [PATCH v6] drm/i915: Add Plane color encoding support for
> YCBCR_BT2020
> 
> Currently the plane property doesn't have support for YCBCR_BT2020, which
> enables the corresponding color conversion mode on plane CSC.
> Enabling the plane property for the planes for GLK & ICL+ platforms.
> Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709 to
> YUV601_TO_RGB601.
> 
> V2: Enabling support for YCBCT_BT2020 for HDR planes on
> platforms GLK & ICL
> 
> V3: Refined the condition check to handle GLK & ICL+ HDR planes
> Also added BT2020 handling in glk_plane_color_ctl.
> 
> V4: Combine If-else into single If
> 
> V5: Drop the checking for HDR planes and enable YCBCR_BT2020
> for platforms GLK & ICL+.
> 
> V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709
> to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's
> feedback.
> 
> V7: Rebased

Pushed the change to dinq. Thanks for the patch and reviews.

Regards,
Uma Shankar

> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Reviewed-by: Uma Shankar 
> Signed-off-by: Kishore Kadiyala 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 15 +++
> drivers/gpu/drm/i915/display/intel_sprite.c  |  9 +++--
>  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
>  3 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f9f9b20d5f5..a9f752d26b4e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4812,11 +4812,18 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
>   plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> 
>   if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> - if (plane_state->hw.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
> + switch (plane_state->hw.color_encoding) {
> + case DRM_COLOR_YCBCR_BT709:
>   plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - else
> - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> -
> + break;
> + case DRM_COLOR_YCBCR_BT2020:
> + plane_color_ctl |=
> +
>   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> + break;
> + default:
> + plane_color_ctl |=
> + PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601;
> + }
>   if (plane_state->hw.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
>   plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
>   } else if (fb->format->is_yuv) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 571c36f929bd..3cd461bf9131 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3061,6 +3061,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
>   struct intel_plane *plane;
>   enum drm_plane_type plane_type;
>   unsigned int supported_rotations;
> + unsigned int supported_csc;
>   const u64 *modifiers;
>   const u32 *formats;
>   int num_formats;
> @@ -3135,9 +3136,13 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
>  DRM_MODE_ROTATE_0,
>  supported_rotations);
> 
> + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> +BIT(DRM_COLOR_YCBCR_BT709);
> +
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
> +
>   drm_plane_create_color_properties(&plane->base,
> -   BIT(DRM_COLOR_YCBCR_BT601) |
> -   BIT(DRM_COLOR_YCBCR_BT709),
> +   supported_csc,
> 
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> DRM_COLOR_YCBCR_BT709,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e9d50fe0f375..578cfe11cbb9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6932,7 +6932,7 @@ enum {
>  #define   PLANE_COLOR_INPUT_CSC_ENABLE   (1 << 20) /* ICL+ */
>  #define   PLANE_COLOR_PIPE_CSC_ENABLE(1 << 23) /* Pre-ICL */
>  #define   PLANE_COLOR_CSC_MODE_BYPASS(0 << 17)
> -#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709  (1 << 17)
> +#define   PL

Re: [Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Chris Wilson
Quoting Mika Kuoppala (2020-06-01 12:49:49)
> Chris Wilson  writes:
> 
> > Ever noticed that our interrupt handlers are where we spend most of our
> > time on a busy system? In part this is unavoidable as each interrupt
> > requires to poll and reset several registers, but we can try and so as
> > efficiently as possible.
> >
> > Function old new   delta
> > ilk_irq_handler 23172156-161
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 59 -
> >  1 file changed, 28 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 63579ab71cf6..07c0c7ea3795 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2097,69 +2097,66 @@ static void ivb_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> >   */
> >  static irqreturn_t ilk_irq_handler(int irq, void *arg)
> >  {
> > - struct drm_i915_private *dev_priv = arg;
> > + struct drm_i915_private *i915 = arg;
> > + void __iomem * const regs = i915->uncore.regs;
> >   u32 de_iir, gt_iir, de_ier, sde_ier = 0;
> > - irqreturn_t ret = IRQ_NONE;
> >  
> > - if (!intel_irqs_enabled(dev_priv))
> > + if (!unlikely(intel_irqs_enabled(i915)))
> 
> Put ! inside the unlikely for readability please.
> 
> >   return IRQ_NONE;
> >  
> >   /* IRQs are synced during runtime_suspend, we don't require a wakeref 
> > */
> > - disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > + disable_rpm_wakeref_asserts(&i915->runtime_pm);
> >  
> >   /* disable master interrupt before clearing iir  */
> > - de_ier = I915_READ(DEIER);
> > - I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> > + de_ier = raw_reg_read(regs, DEIER);
> > + raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> >  
> >   /* Disable south interrupts. We'll only write to SDEIIR once, so 
> > further
> >* interrupts will will be stored on its back queue, and then we'll be
> >* able to process them after we restore SDEIER (as soon as we restore
> >* it, we'll get an interrupt if SDEIIR still has something to process
> >* due to its back queue). */
> > - if (!HAS_PCH_NOP(dev_priv)) {
> > - sde_ier = I915_READ(SDEIER);
> > - I915_WRITE(SDEIER, 0);
> > + if (!HAS_PCH_NOP(i915)) {
> > + sde_ier = raw_reg_read(regs, SDEIER);
> > + raw_reg_write(regs, SDEIER, 0);
> >   }
> >  
> >   /* Find, clear, then process each source of interrupt */
> >  
> > - gt_iir = I915_READ(GTIIR);
> > + gt_iir = raw_reg_read(regs, GTIIR);
> >   if (gt_iir) {
> > - I915_WRITE(GTIIR, gt_iir);
> > - ret = IRQ_HANDLED;
> > - if (INTEL_GEN(dev_priv) >= 6)
> > - gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
> > + raw_reg_write(regs, GTIIR, gt_iir);
> > + if (INTEL_GEN(i915) >= 6)
> > + gen6_gt_irq_handler(&i915->gt, gt_iir);
> >   else
> > - gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
> > + gen5_gt_irq_handler(&i915->gt, gt_iir);
> >   }
> >  
> > - de_iir = I915_READ(DEIIR);
> > + de_iir = raw_reg_read(regs, DEIIR);
> >   if (de_iir) {
> > - I915_WRITE(DEIIR, de_iir);
> > - ret = IRQ_HANDLED;
> > - if (INTEL_GEN(dev_priv) >= 7)
> > - ivb_display_irq_handler(dev_priv, de_iir);
> > + raw_reg_write(regs, DEIIR, de_iir);
> > + if (INTEL_GEN(i915) >= 7)
> > + ivb_display_irq_handler(i915, de_iir);
> >   else
> > - ilk_display_irq_handler(dev_priv, de_iir);
> > + ilk_display_irq_handler(i915, de_iir);
> >   }
> >  
> > - if (INTEL_GEN(dev_priv) >= 6) {
> > - u32 pm_iir = I915_READ(GEN6_PMIIR);
> > + if (INTEL_GEN(i915) >= 6) {
> > + u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
> >   if (pm_iir) {
> > - I915_WRITE(GEN6_PMIIR, pm_iir);
> > - ret = IRQ_HANDLED;
> > - gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
> > + raw_reg_write(regs, GEN6_PMIIR, pm_iir);
> > + gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
> >   }
> >   }
> >  
> > - I915_WRITE(DEIER, de_ier);
> > - if (!HAS_PCH_NOP(dev_priv))
> > - I915_WRITE(SDEIER, sde_ier);
> > + raw_reg_write(regs, DEIER, de_ier);
> > + if (sde_ier)
> > + raw_reg_write(regs, SDEIER, sde_ier);
> >  
> >   /* IRQs are synced during runtime_suspend, we don't require a wakeref 
> > */
> > - enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > +

Re: [Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> Ever noticed that our interrupt handlers are where we spend most of our
> time on a busy system? In part this is unavoidable as each interrupt
> requires to poll and reset several registers, but we can try and so as
> efficiently as possible.
>
> Function old new   delta
> ilk_irq_handler 23172156-161
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 59 -
>  1 file changed, 28 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 63579ab71cf6..07c0c7ea3795 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2097,69 +2097,66 @@ static void ivb_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   */
>  static irqreturn_t ilk_irq_handler(int irq, void *arg)
>  {
> - struct drm_i915_private *dev_priv = arg;
> + struct drm_i915_private *i915 = arg;
> + void __iomem * const regs = i915->uncore.regs;
>   u32 de_iir, gt_iir, de_ier, sde_ier = 0;
> - irqreturn_t ret = IRQ_NONE;
>  
> - if (!intel_irqs_enabled(dev_priv))
> + if (!unlikely(intel_irqs_enabled(i915)))

Put ! inside the unlikely for readability please.

>   return IRQ_NONE;
>  
>   /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> - disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> + disable_rpm_wakeref_asserts(&i915->runtime_pm);
>  
>   /* disable master interrupt before clearing iir  */
> - de_ier = I915_READ(DEIER);
> - I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> + de_ier = raw_reg_read(regs, DEIER);
> + raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
>  
>   /* Disable south interrupts. We'll only write to SDEIIR once, so further
>* interrupts will will be stored on its back queue, and then we'll be
>* able to process them after we restore SDEIER (as soon as we restore
>* it, we'll get an interrupt if SDEIIR still has something to process
>* due to its back queue). */
> - if (!HAS_PCH_NOP(dev_priv)) {
> - sde_ier = I915_READ(SDEIER);
> - I915_WRITE(SDEIER, 0);
> + if (!HAS_PCH_NOP(i915)) {
> + sde_ier = raw_reg_read(regs, SDEIER);
> + raw_reg_write(regs, SDEIER, 0);
>   }
>  
>   /* Find, clear, then process each source of interrupt */
>  
> - gt_iir = I915_READ(GTIIR);
> + gt_iir = raw_reg_read(regs, GTIIR);
>   if (gt_iir) {
> - I915_WRITE(GTIIR, gt_iir);
> - ret = IRQ_HANDLED;
> - if (INTEL_GEN(dev_priv) >= 6)
> - gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
> + raw_reg_write(regs, GTIIR, gt_iir);
> + if (INTEL_GEN(i915) >= 6)
> + gen6_gt_irq_handler(&i915->gt, gt_iir);
>   else
> - gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
> + gen5_gt_irq_handler(&i915->gt, gt_iir);
>   }
>  
> - de_iir = I915_READ(DEIIR);
> + de_iir = raw_reg_read(regs, DEIIR);
>   if (de_iir) {
> - I915_WRITE(DEIIR, de_iir);
> - ret = IRQ_HANDLED;
> - if (INTEL_GEN(dev_priv) >= 7)
> - ivb_display_irq_handler(dev_priv, de_iir);
> + raw_reg_write(regs, DEIIR, de_iir);
> + if (INTEL_GEN(i915) >= 7)
> + ivb_display_irq_handler(i915, de_iir);
>   else
> - ilk_display_irq_handler(dev_priv, de_iir);
> + ilk_display_irq_handler(i915, de_iir);
>   }
>  
> - if (INTEL_GEN(dev_priv) >= 6) {
> - u32 pm_iir = I915_READ(GEN6_PMIIR);
> + if (INTEL_GEN(i915) >= 6) {
> + u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
>   if (pm_iir) {
> - I915_WRITE(GEN6_PMIIR, pm_iir);
> - ret = IRQ_HANDLED;
> - gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
> + raw_reg_write(regs, GEN6_PMIIR, pm_iir);
> + gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
>   }
>   }
>  
> - I915_WRITE(DEIER, de_ier);
> - if (!HAS_PCH_NOP(dev_priv))
> - I915_WRITE(SDEIER, sde_ier);
> + raw_reg_write(regs, DEIER, de_ier);
> + if (sde_ier)
> + raw_reg_write(regs, SDEIER, sde_ier);
>  
>   /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> - enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> + enable_rpm_wakeref_asserts(&i915->runtime_pm);
>  
> - return ret;
> + return IRQ_HANDLED;

Change in here is that if we catch a intr without any work, we now
return handled instead of none. 

And as we have not actually done anything to prevent the next
one to kicking off, this i

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2)

2020-06-01 Thread Chris Wilson
Quoting Patchwork (2020-06-01 12:00:40)
> == Series Details ==
> 
> Series: series starting with [01/36] drm/i915: Handle very early engine 
> initialisation failure (rev2)
> URL   : https://patchwork.freedesktop.org/series/77857/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_8560_full -> Patchwork_17828_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_17828_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_17828_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_17828_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@runner@aborted:
> - shard-hsw:  NOTRUN -> [FAIL][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-hsw6/igt@run...@aborted.html
> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * {igt@gem_exec_fence@parallel@vecs0}:
> - shard-hsw:  [PASS][2] -> [FAIL][3] +3 similar issues
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-hsw1/igt@gem_exec_fence@paral...@vecs0.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-hsw2/igt@gem_exec_fence@paral...@vecs0.html

Sigh. They dropped the memory compare from MI_SEMAPHORE_MBOX in Haswell.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 01/36] drm/i915: Handle very early engine initialisation failure

2020-06-01 Thread Mika Kuoppala
Chris Wilson  writes:

> If we fail during engine setup, we may leave some engines not yet setup.
> During the error cleanup, we have to be careful not to try and use the
> uninitialise engines before discarding them.
>
> [   16.136152] RIP: 0010:__flush_work+0x198/0x1b0
> [   16.136168] Code: ff ff 8b 0b 48 8b 53 08 83 e1 08 48 0f ba 2b 03 80 c9 f0 
> e9 63 ff ff ff 0f 0b 48 83 c4 48 44 89 f0 5b 5d 41 5c 41 5d 41 5e c3 <0f> 0b 
> 45 31 f6 e9 62 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f
> [   16.136186] RSP: 0018:c93bb928 EFLAGS: 00010246
> [   16.136201] RAX:  RBX: 88844f392168 RCX: 
> 
> [   16.136216] RDX:  RSI:  RDI: 
> 88844f392168
> [   16.136231] RBP: 88844f392130 R08:  R09: 
> 0001
> [   16.136246] R10: 888441e31e40 R11: 88845e329c70 R12: 
> 88844f796988
> [   16.136261] R13: 888441e4fb80 R14: 0001 R15: 
> 88844f79
> [   16.136388] FS:  7fecbd208880() GS:88845e38() 
> knlGS:
> [   16.136405] CS:  0010 DS:  ES:  CR0: 80050033
> [   16.136420] CR2: 7ff3ce748f90 CR3: 000457a6a001 CR4: 
> 000606e0
> [   16.136437] Call Trace:
> [   16.136456]  ? try_to_del_timer_sync+0x3a/0x50
> [   16.136529]  intel_wakeref_wait_for_idle+0x87/0xb0 [i915]
> [   16.136606]  ? intel_engines_release+0x68/0xc0 [i915]
> [   16.136680]  intel_engines_release+0x49/0xc0 [i915]
> [   16.136757]  intel_gt_init+0x2f4/0x5e0 [i915]
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 


> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index da5b61085257..c8c14981eb5d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -414,12 +414,12 @@ void intel_engines_release(struct intel_gt *gt)
>  
>   /* Decouple the backend; but keep the layout for late GPU resets */
>   for_each_engine(engine, gt, id) {
> - intel_wakeref_wait_for_idle(&engine->wakeref);
> - GEM_BUG_ON(intel_engine_pm_is_awake(engine));
> -
>   if (!engine->release)
>   continue;
>  
> + intel_wakeref_wait_for_idle(&engine->wakeref);
> + GEM_BUG_ON(intel_engine_pm_is_awake(engine));
> +
>   engine->release(engine);
>   engine->release = NULL;
>  
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: lpsp with hdmi/dp outputs

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: lpsp with hdmi/dp outputs
URL   : https://patchwork.freedesktop.org/series/77866/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8561 -> Patchwork_17829


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (51 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8561 -> Patchwork_17829

  CI-20190529: 20190529
  CI_DRM_8561: 989e079eb7172d7423686cab0dd5d4e47a48f3e1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5688: 33c8411480b4945e44188f82cd6c3a0d53b40485 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17829: 78f04fcced9a26b870739cbc213801bd1b570606 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

78f04fcced9a drm/i915: lpsp with hdmi/dp outputs

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)
URL   : https://patchwork.freedesktop.org/series/75660/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8560_full -> Patchwork_17827_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@gem_ctx_isolation@preservation-s3@vecs0}:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-iclb8/igt@gem_ctx_isolation@preservation...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-iclb3/igt@gem_ctx_isolation@preservation...@vecs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-ccs:
- shard-apl:  [PASS][3] -> [INCOMPLETE][4] ([i915#1635])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl4/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-offscreen:
- shard-apl:  [PASS][5] -> [TIMEOUT][6] ([i915#1635]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-iclb1/igt@kms_psr@psr2_primary_mmap_gtt.html

  
 Possible fixes 

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-apl:  [FAIL][13] ([i915#54]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  [FAIL][17] ([i915#72]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@c-dp1}:
- shard-apl:  [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +6 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html

  * {igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1}:
- shard-skl:  [FAIL][21] ([i915#1928]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-skl9/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html
   [22]: 
https://intel-gfx-ci.01.org/tr

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure (rev2)
URL   : https://patchwork.freedesktop.org/series/77857/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8560_full -> Patchwork_17828_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-hsw6/igt@run...@aborted.html

  
 Suppressed 

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

  * {igt@gem_exec_fence@parallel@vecs0}:
- shard-hsw:  [PASS][2] -> [FAIL][3] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-hsw1/igt@gem_exec_fence@paral...@vecs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-hsw2/igt@gem_exec_fence@paral...@vecs0.html

  * {igt@gem_exec_fence@syncobj-invalid-wait}:
- shard-snb:  [PASS][4] -> [FAIL][5] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-snb5/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-snb5/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-tglb: [PASS][6] -> [FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-tglb6/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-tglb8/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-skl:  [PASS][8] -> [FAIL][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-skl8/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-skl8/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-glk:  [PASS][10] -> [FAIL][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-glk6/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-glk1/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-apl:  [PASS][12] -> [FAIL][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl1/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-apl1/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-kbl:  [PASS][14] -> [FAIL][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-kbl3/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-kbl4/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-iclb: [PASS][16] -> [FAIL][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-iclb2/igt@gem_exec_fe...@syncobj-invalid-wait.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-iclb2/igt@gem_exec_fe...@syncobj-invalid-wait.html

  
New tests
-

  New tests have been introduced between CI_DRM_8560_full and 
Patchwork_17828_full:

### New IGT tests (1) ###

  * igt@dmabuf@all@dma_fence_proxy:
- Statuses : 8 pass(s)
- Exec time: [0.04, 0.10] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-snb:  [PASS][18] -> [SKIP][19] ([fdo#109271])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-snb5/igt@gem_ctx_pa...@set-priority-not-supported.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-snb1/igt@gem_ctx_pa...@set-priority-not-supported.html
- shard-hsw:  [PASS][20] -> [SKIP][21] ([fdo#109271])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-hsw1/igt@gem_ctx_pa...@set-priority-not-supported.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17828/shard-hsw2/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@i915_pm_rps@waitboost:
- shard-hsw:  [PASS][22] -> [FAIL][23] ([i915#39]) +1 similar issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-hsw1/igt@i915_pm_...@waitboost.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor

[Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-01 Thread Anshuman Gupta
Gen12 hw are failing to enable lpsp configuration due to PG3 was left on
due to valid usgae count of POWER_DOMAIN_AUDIO.
It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling
a crtc, it should be always i915_audio_component request to get/put
AUDIO_POWER_DOMAIN.

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c3b11de2daf..f31a579d7a52 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct 
intel_crtc_state *crtc_state)
mask |= BIT_ULL(intel_encoder->power_domain);
}
 
-   if (HAS_DDI(dev_priv) && crtc_state->has_audio)
+   /*
+* Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
+* enable AUDIO power in order to enable a crtc.
+*/
+   if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) && 
crtc_state->has_audio)
mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
 
if (crtc_state->shared_dpll)
-- 
2.26.2

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)
URL   : https://patchwork.freedesktop.org/series/75660/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8560_full -> Patchwork_17827_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-ccs:
- shard-apl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl4/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html

  
 Suppressed 

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

  * {igt@gem_ctx_isolation@preservation-s3@vecs0}:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-iclb8/igt@gem_ctx_isolation@preservation...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-iclb3/igt@gem_ctx_isolation@preservation...@vecs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-offscreen:
- shard-apl:  [PASS][5] -> [TIMEOUT][6] ([i915#1635]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-iclb1/igt@kms_psr@psr2_primary_mmap_gtt.html

  
 Possible fixes 

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-apl:  [FAIL][13] ([i915#54]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  [FAIL][17] ([i915#72]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@c-dp1}:
- shard-apl:  [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +6 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/shard-apl1/igt@kms_flip@flip-vs-s

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure (rev2)
URL   : https://patchwork.freedesktop.org/series/77857/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8560 -> Patchwork_17828


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_8560 and Patchwork_17828:

### New IGT tests (1) ###

  * igt@dmabuf@all@dma_fence_proxy:
- Statuses : 42 pass(s)
- Exec time: [0.03, 0.10] s

  


Changes
---

  No changes found


Participating hosts (50 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8560 -> Patchwork_17828

  CI-20190529: 20190529
  CI_DRM_8560: 02fe287fdb4a3d6bceb1bb61b3c8538b4b941b3c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5687: 668a5be752186b6e08f361bac34da37309d08393 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17828: d2ba95a40d8a1c2731ac575e5183770cbb118343 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d2ba95a40d8a drm/i915/gem: Bind the fence async for execbuf
55b772ca8526 drm/i915/gem: Asynchronous GTT unbinding
8ed22b7514d8 drm/i915/gem: Separate the ww_mutex walker into its own list
e8d99d37c64d drm/i915: Export a preallocate variant of i915_active_acquire()
f86a694d1a36 drm/i915/gem: Assign context id for async work
30672d041d30 drm/i915: Always defer fenced work to the worker
796d8967ce3e drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT
0f995d2bfbe2 drm/i915/gt: Declare when we enabled timeslicing
fe5ce9a4c96f drm/i915/gem: Allow combining submit-fences with syncobj
9f06244959ca drm/i915/gem: Teach execbuf how to wait on future syncobj
59c00fdc9150 drm/syncobj: Allow use of dma-fence-proxy
7f48f9f9cabb drm/i915/gem: Make relocations atomic within execbuf
ce15d9f7f287 drm/i915: Unpeel awaits on a proxy fence
3d075ea5bad9 dma-buf: Proxy fence, an unsignaled fence placeholder
b5ed91ed9028 drm/i915/gem: Add all GPU reloc awaits/signals en masse
cf3caf6ea48e drm/i915/gem: Build the reloc request first
a5a8005dc0d5 drm/i915/gem: Lift GPU relocation allocation
bf626d095a0a drm/i915/gem: Separate reloc validation into an earlier step
d6bb9bf39a67 drm/i915: Add list_for_each_entry_safe_continue_reverse
043a8c092764 drm/i915/gem: Async GPU relocations only
4223614bdbed drm/i915/gem: Mark the buffer pool as active for the cmdparser
8f4228e0458d drm/i915/gt: Enable ring scheduling for gen6/7
e4172f511dc0 drm/i915/gt: Implement ring scheduler for gen6/7
e43d3f056a59 drm/i915: Relinquish forcewake immediately after manual grouping
ad2a6b63bf64 drm/i915/gt: Track if an engine requires forcewake w/a
5354a72cf88c drm/i915/gt: Enable busy-stats for ring-scheduler
9c8572c7a931 drm/i915/gt: Infrastructure for ring scheduling
75a19e638ad6 drm/i915: Support inter-engine semaphores on gen6/7
ad2ec515e737 drm/i915/gt: Use client timeline address for seqno writes
a186650cc2c0 drm/i915/gt: Support creation of 'internal' rings
ee444a1c9757 drm/i915/gt: Couple tasklet scheduling for all CS interrupts
db08f3a83b7d Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
51c5e9106b00 drm/i915: Trim the ironlake+ irq handler
84fb5312e69a drm/i915/gt: Move legacy context wa to intel_workarounds
28f59054aa9e drm/i915/gt: Split low level gen2-7 CS emitters
b0896ff73ea4 drm/i915: Handle very early engine initialisation failure

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure (rev2)
URL   : https://patchwork.freedesktop.org/series/77857/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2)

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure (rev2)
URL   : https://patchwork.freedesktop.org/series/77857/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b0896ff73ea4 drm/i915: Handle very early engine initialisation failure
28f59054aa9e drm/i915/gt: Split low level gen2-7 CS emitters
-:9: WARNING:TYPO_SPELLING: 'wnat' may be misspelled - perhaps 'want'?
#9: 
with requests, and we will wnat to reuse them outside of this context.

-:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#27: 
new file mode 100644

-:179: WARNING:LONG_LINE: line over 100 characters
#179: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:148:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:202: WARNING:LONG_LINE: line over 100 characters
#202: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:171:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:220: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#220: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:189:
+}
+#undef GEN5_WA_STORES

-:798: WARNING:LONG_LINE: line over 100 characters
#798: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:377:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:818: WARNING:LONG_LINE: line over 100 characters
#818: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:397:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:843: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#843: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:422:
+}
+#undef GEN7_XCS_WA

total: 0 errors, 6 warnings, 2 checks, 1812 lines checked
84fb5312e69a drm/i915/gt: Move legacy context wa to intel_workarounds
51c5e9106b00 drm/i915: Trim the ironlake+ irq handler
db08f3a83b7d Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
ee444a1c9757 drm/i915/gt: Couple tasklet scheduling for all CS interrupts
a186650cc2c0 drm/i915/gt: Support creation of 'internal' rings
ad2ec515e737 drm/i915/gt: Use client timeline address for seqno writes
75a19e638ad6 drm/i915: Support inter-engine semaphores on gen6/7
9c8572c7a931 drm/i915/gt: Infrastructure for ring scheduling
-:79: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#79: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 842 lines checked
5354a72cf88c drm/i915/gt: Enable busy-stats for ring-scheduler
-:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#13: 
new file mode 100644

-:200: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see 
Documentation/timers/timers-howto.rst
#200: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:47:
+   udelay(100);

-:230: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see 
Documentation/timers/timers-howto.rst
#230: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:77:
+   udelay(100);

total: 0 errors, 1 warnings, 2 checks, 236 lines checked
ad2a6b63bf64 drm/i915/gt: Track if an engine requires forcewake w/a
e43d3f056a59 drm/i915: Relinquish forcewake immediately after manual grouping
e4172f511dc0 drm/i915/gt: Implement ring scheduler for gen6/7
-:68: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#68: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:324:
+   *cs++ = i915_mmio_reg_offset(

-:70: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#70: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:326:
+   *cs++ = _MASKED_BIT_ENABLE(

-:105: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#105: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:361:
+   *cs++ = _MASKED_BIT_DISABLE(

total: 0 errors, 0 warnings, 3 checks, 512 lines checked
8f4228e0458d drm/i915/gt: Enable ring scheduling for gen6/7
4223614bdbed drm/i915/gem: Mark the buffer pool as active for the cmdparser
043a8c092764 drm/i915/gem: Async GPU relocations only
d6bb9bf39a67 drm/i915: Add list_for_each_entry_safe_continue_reverse
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+   for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member);  \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))

-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#20: FILE: drivers/gpu/d

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)

2020-06-01 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Plane color encoding support for YCBCR_BT2020 (rev6)
URL   : https://patchwork.freedesktop.org/series/75660/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8560 -> Patchwork_17827


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [SKIP][1] ([fdo#109271]) -> [FAIL][2] ([i915#62] / 
[i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17827/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (50 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8560 -> Patchwork_17827

  CI-20190529: 20190529
  CI_DRM_8560: 02fe287fdb4a3d6bceb1bb61b3c8538b4b941b3c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5687: 668a5be752186b6e08f361bac34da37309d08393 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17827: 2d67bb8cef9491f3109c6c2dbc237b5cff273ebb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2d67bb8cef94 drm/i915: Add Plane color encoding support for YCBCR_BT2020

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/gt: Enable busy-stats for ring-scheduler

2020-06-01 Thread Chris Wilson
Couple up the context in/out accounting to record how long each engine
is busy handling requests. This is exposed to userspace for more accurate
measurements, and also enables our soft-rps timer.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_engine_stats.h  | 49 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 34 +--
 .../gpu/drm/i915/gt/intel_ring_scheduler.c|  4 +
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c  | 90 +++
 drivers/gpu/drm/i915/gt/selftest_rps.c|  5 ++
 5 files changed, 149 insertions(+), 33 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h 
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include 
+#include 
+#include 
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+
+   if (atomic_add_unless(&engine->stats.active, 1, 0))
+   return;
+
+   write_seqlock_irqsave(&engine->stats.lock, flags);
+   if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
+   engine->stats.start = ktime_get();
+   atomic_inc(&engine->stats.active);
+   }
+   write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+
+   GEM_BUG_ON(!atomic_read(&engine->stats.active));
+
+   if (atomic_add_unless(&engine->stats.active, -1, 1))
+   return;
+
+   write_seqlock_irqsave(&engine->stats.lock, flags);
+   if (atomic_dec_and_test(&engine->stats.active)) {
+   engine->stats.total =
+   ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+   }
+   write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6fc0966b75ff..13ef4f58cb08 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
 #include "i915_vgpu.h"
 #include "intel_context.h"
 #include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -1187,39 +1188,6 @@ execlists_context_status_change(struct i915_request *rq, 
unsigned long status)
   status, rq);
 }
 
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
-   unsigned long flags;
-
-   if (atomic_add_unless(&engine->stats.active, 1, 0))
-   return;
-
-   write_seqlock_irqsave(&engine->stats.lock, flags);
-   if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
-   engine->stats.start = ktime_get();
-   atomic_inc(&engine->stats.active);
-   }
-   write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
-   unsigned long flags;
-
-   GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
-   if (atomic_add_unless(&engine->stats.active, -1, 1))
-   return;
-
-   write_seqlock_irqsave(&engine->stats.lock, flags);
-   if (atomic_dec_and_test(&engine->stats.active)) {
-   engine->stats.total =
-   ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
-   }
-   write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
 static void
 execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c 
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
index c8cd435d1c51..aaff554865b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -9,6 +9,7 @@
 
 #include "i915_drv.h"
 #include "intel_context.h"
+#include "intel_engine_stats.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -59,6 +60,7 @@ static struct i915_request *
 schedule_in(struct intel_engine_cs *engine, struct i915_request *rq)
 {
__intel_gt_pm_get(engine->gt);
+   intel_engine_context_in(engine);
return i915_request_get(rq);
 }
 
@@ -71,6 +73,7 @@ schedule_out(struct intel_engine_cs *engine, struct 
i915_request *rq)
intel_engine_add_retire(engine, ce->timeline);
 
i915_reque

Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount

2020-06-01 Thread Lisovskiy, Stanislav
On Fri, May 29, 2020 at 08:11:43AM +0300, Ville Syrjälä wrote:
> On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > While the current locking/serialization of the global state
> > > > suffices for protecting the obj->state access and the actual
> > > > hardware reprogramming, we do have a problem with accessing
> > > > the old/new states during nonblocking commits.
> > > > 
> > > > The state computation and swap will be protected by the crtc
> > > > locks, but the commit_tails can finish out of order, thus also
> > > > causing the atomic states to be cleaned up out of order. This
> > > > would mean the commit that started first but finished last has
> > > > had its new state freed as the no-longer-needed old state by the
> > > > other commit.
> > > > 
> > > > To fix this let's just refcount the states. obj->state amounts
> > > > to one reference, and the intel_atomic_state holds extra references
> > > > to both its new and old global obj states.
> > > > 
> > > > Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling")
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  .../gpu/drm/i915/display/intel_global_state.c | 45 ---
> > > >  .../gpu/drm/i915/display/intel_global_state.h |  3 ++
> > > >  2 files changed, 42 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c 
> > > > b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > index 212d4ee68205..7a19215ad844 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > > @@ -10,6 +10,28 @@
> > > >  #include "intel_display_types.h"
> > > >  #include "intel_global_state.h"
> > > >  
> > > > +static void __intel_atomic_global_state_free(struct kref *kref)
> > > > +{
> > > > +   struct intel_global_state *obj_state =
> > > > +   container_of(kref, struct intel_global_state, ref);
> > > > +   struct intel_global_obj *obj = obj_state->obj;
> > > > +
> > > > +   obj->funcs->atomic_destroy_state(obj, obj_state);
> > > > +}
> > > > +
> > > > +static void intel_atomic_global_state_put(struct intel_global_state 
> > > > *obj_state)
> > > > +{
> > > > +   kref_put(&obj_state->ref, __intel_atomic_global_state_free);
> > > > +}
> > > > +
> > > > +static struct intel_global_state *
> > > > +intel_atomic_global_state_get(struct intel_global_state *obj_state)
> > > > +{
> > > > +   kref_get(&obj_state->ref);
> > > > +
> > > > +   return obj_state;
> > > > +}
> > > > +
> > > >  void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> > > >   struct intel_global_obj *obj,
> > > >   struct intel_global_state *state,
> > > > @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct 
> > > > drm_i915_private *dev_priv,
> > > >  {
> > > > memset(obj, 0, sizeof(*obj));
> > > >  
> > > > +   state->obj = obj;
> > > > +
> > > > +   kref_init(&state->ref);
> > > > +
> > > > obj->state = state;
> > > > obj->funcs = funcs;
> > > > list_add_tail(&obj->head, &dev_priv->global_obj_list);
> > > > @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct 
> > > > drm_i915_private *dev_priv)
> > > >  
> > > > list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, 
> > > > head) {
> > > > list_del(&obj->head);
> > > > -   obj->funcs->atomic_destroy_state(obj, obj->state);
> > > > +
> > > > +   drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) 
> > > > != 1);
> > > > +   intel_atomic_global_state_put(obj->state);
> > > > }
> > > >  }
> > > >  
> > > > @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct 
> > > > intel_atomic_state *state,
> > > > if (!obj_state)
> > > > return ERR_PTR(-ENOMEM);
> > > >  
> > > > +   obj_state->obj = obj;
> > > > obj_state->changed = false;
> > > >  
> > > > +   kref_init(&obj_state->ref);
> > > > +
> > > > state->global_objs[index].state = obj_state;
> > > > -   state->global_objs[index].old_state = obj->state;
> > > > +   state->global_objs[index].old_state =
> > > > +   intel_atomic_global_state_get(obj->state);
> > > > state->global_objs[index].new_state = obj_state;
> > > > state->global_objs[index].ptr = obj;
> > > > obj_state->state = state;
> > > > @@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct 
> > > > intel_atomic_state *state)
> > > > new_obj_state->state = NULL;
> > > >  
> > > > state->global_objs[i].state = old_obj_state;
> > > > -   obj->state = new_obj_state;
> > > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/36] drm/i915: Handle very early engine initialisation failure

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure
URL   : https://patchwork.freedesktop.org/series/77857/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8560 -> Patchwork_17826


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_engines:
- fi-cml-s:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8560/fi-cml-s/igt@i915_selftest@live@gt_engines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17826/fi-cml-s/igt@i915_selftest@live@gt_engines.html

  
New tests
-

  New tests have been introduced between CI_DRM_8560 and Patchwork_17826:

### New IGT tests (1) ###

  * igt@dmabuf@all@dma_fence_proxy:
- Statuses : 42 pass(s)
- Exec time: [0.02, 0.11] s

  



Participating hosts (50 -> 44)
--

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


Build changes
-

  * Linux: CI_DRM_8560 -> Patchwork_17826

  CI-20190529: 20190529
  CI_DRM_8560: 02fe287fdb4a3d6bceb1bb61b3c8538b4b941b3c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5687: 668a5be752186b6e08f361bac34da37309d08393 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17826: ac90fd42eb1dc9c16ba67d9a551bb2b3c238cd42 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ac90fd42eb1d drm/i915/gem: Bind the fence async for execbuf
9c2cdb286a07 drm/i915/gem: Asynchronous GTT unbinding
d90d92d26c5c drm/i915/gem: Separate the ww_mutex walker into its own list
68f85c40ff48 drm/i915: Export a preallocate variant of i915_active_acquire()
b253079dbe95 drm/i915/gem: Assign context id for async work
308d42d80cb3 drm/i915: Always defer fenced work to the worker
7cf3aad63437 drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT
9675274fc27c drm/i915/gt: Declare when we enabled timeslicing
9b560a7e6079 drm/i915/gem: Allow combining submit-fences with syncobj
d03f86e3977c drm/i915/gem: Teach execbuf how to wait on future syncobj
dda5123316b5 drm/syncobj: Allow use of dma-fence-proxy
f3cd5ea0ff2c drm/i915/gem: Make relocations atomic within execbuf
06d2116fd5f4 drm/i915: Unpeel awaits on a proxy fence
6b9cc101590e dma-buf: Proxy fence, an unsignaled fence placeholder
710af09a4672 drm/i915/gem: Add all GPU reloc awaits/signals en masse
6f01210067aa drm/i915/gem: Build the reloc request first
c26758f43cfe drm/i915/gem: Lift GPU relocation allocation
b2abfeed9589 drm/i915/gem: Separate reloc validation into an earlier step
9b9d4aa5ab50 drm/i915: Add list_for_each_entry_safe_continue_reverse
033b56b47071 drm/i915/gem: Async GPU relocations only
143d1995d466 drm/i915/gem: Mark the buffer pool as active for the cmdparser
3148cd01132a drm/i915/gt: Enable ring scheduling for gen6/7
8c829f7c5554 drm/i915/gt: Implement ring scheduler for gen6/7
99a81a3f55b0 drm/i915: Relinquish forcewake immediately after manual grouping
118524c684c6 drm/i915/gt: Track if an engine requires forcewake w/a
0760ab97f627 drm/i915/gt: Enable busy-stats for ring-scheduler
15787ec4da9d drm/i915/gt: Infrastructure for ring scheduling
703dea6710a7 drm/i915: Support inter-engine semaphores on gen6/7
58305c0b593a drm/i915/gt: Use client timeline address for seqno writes
eacfbfb97087 drm/i915/gt: Support creation of 'internal' rings
ce9a7aebf8d2 drm/i915/gt: Couple tasklet scheduling for all CS interrupts
cf0807656a76 Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
5b9d253c3510 drm/i915: Trim the ironlake+ irq handler
8f9e2ddc2328 drm/i915/gt: Move legacy context wa to intel_workarounds
284e5e82f9e8 drm/i915/gt: Split low level gen2-7 CS emitters
96d738818236 drm/i915: Handle very early engine initialisation failure

== Logs ==

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


Re: [Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes

2020-06-01 Thread Lisovskiy, Stanislav
On Fri, May 29, 2020 at 04:57:38PM -0700, Manasi Navare wrote:
> On Tue, May 26, 2020 at 12:48:52PM +0300, Stanislav Lisovskiy wrote:
> > Previous patch didn't take into account all pipes
> > but only those in state, which could cause wrong
> > CDCLK conclcusions and calculations.
> > Also there was a severe issue with min_cdclk being
> > assigned to 0 every compare cycle.
> > 
> > Too bad this was found by me only after merge.
> > This could be also causing the issues in test, however
> > not clear - anyway marking this as fixing the
> > "Adjust CDCLK accordingly to our DBuf bw needs".
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
> > ---
> >  drivers/gpu/drm/i915/display/intel_bw.c  | 51 
> >  drivers/gpu/drm/i915/display/intel_cdclk.c   | 19 +---
> >  drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> >  3 files changed, 53 insertions(+), 43 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index a79bd7aeb03b..8096138abecc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > *state)
> > struct intel_crtc *crtc;
> > int max_bw = 0;
> > int slice_id;
> > +   enum pipe pipe;
> > int i;
> >  
> > for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> > @@ -447,7 +448,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > *state)
> > if (IS_ERR(new_bw_state))
> > return PTR_ERR(new_bw_state);
> >  
> > -   crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
> > +   old_bw_state = intel_atomic_get_old_bw_state(state);
> > +
> > +   crtc_bw = &new_bw_state->dbuf_bw[pipe];
> >  
> > memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> >  
> > @@ -478,6 +481,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > *state)
> > for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
> > crtc_bw->used_bw[slice_id] += data_rate;
> > }
> > +   }
> > +
> > +   if (!old_bw_state)
> > +   return 0;
> > +
> > +   for_each_pipe(dev_priv, pipe) {
> > +   struct intel_dbuf_bw *crtc_bw;
> > +
> 
> So the condition !old_bw_state() will make sure we loop through
> only the active pipes and compute crtc_bw only for those right?
> 
> Manasi

Well, in fact this condition just checks if we had any crtcs in state - 
otherwise there were no changes, so bw_state global object doesn't need
to be changed. Whenever something happens to crtc we should have it
in the state, so this condition just checks if we need to modify bw_state
or not. 

Regarding active/inactive pipes - currently for inactive pipes,
we are going to get 0 dbuf slice mask, so we just won't accumulate any data
rate for those. So if the pipe got disabled we will get less required min_cdclk
which against old_bw_state, which will mean that we are going to acquire
the global state lock for writing.

In fact we could optimize the code by skipping inactive pipes completely 
i.e don't even calculate dbuf slice mask,
which will be 0. However the logic and the end result would be
the same anyway.

Stan

> 
> > +   crtc_bw = &new_bw_state->dbuf_bw[pipe];
> >  
> > for_each_dbuf_slice(slice_id) {
> > /*
> > @@ -490,14 +502,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > *state)
> >  */
> > max_bw += crtc_bw->used_bw[slice_id];
> > }
> > -
> > -   new_bw_state->min_cdclk = max_bw / 64;
> > -
> > -   old_bw_state = intel_atomic_get_old_bw_state(state);
> > }
> >  
> > -   if (!old_bw_state)
> > -   return 0;
> > +   new_bw_state->min_cdclk = max_bw / 64;
> >  
> > if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> > int ret = intel_atomic_lock_global_state(&new_bw_state->base);
> > @@ -511,34 +518,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
> > *state)
> >  
> >  int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
> >  {
> > -   int i;
> > +   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > +   struct intel_bw_state *new_bw_state = NULL;
> > +   struct intel_bw_state *old_bw_state = NULL;
> > const struct intel_crtc_state *crtc_state;
> > struct intel_crtc *crtc;
> > int min_cdclk = 0;
> > -   struct intel_bw_state *new_bw_state = NULL;
> > -   struct intel_bw_state *old_bw_state = NULL;
> > +   enum pipe pipe;
> > +   int i;
> >  
> > for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> > -   struct intel_cdclk_state *cdclk_state;
> > -
> > new_bw_state = intel_atomic_get_bw_state(state);
> > if (IS_ERR(new_bw_state))
> > 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure
URL   : https://patchwork.freedesktop.org/series/77857/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure

2020-06-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/36] drm/i915: Handle very early engine 
initialisation failure
URL   : https://patchwork.freedesktop.org/series/77857/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
96d738818236 drm/i915: Handle very early engine initialisation failure
284e5e82f9e8 drm/i915/gt: Split low level gen2-7 CS emitters
-:9: WARNING:TYPO_SPELLING: 'wnat' may be misspelled - perhaps 'want'?
#9: 
with requests, and we will wnat to reuse them outside of this context.

-:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#27: 
new file mode 100644

-:179: WARNING:LONG_LINE: line over 100 characters
#179: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:148:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:202: WARNING:LONG_LINE: line over 100 characters
#202: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:171:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:220: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#220: FILE: drivers/gpu/drm/i915/gt/gen2_engine_cs.c:189:
+}
+#undef GEN5_WA_STORES

-:798: WARNING:LONG_LINE: line over 100 characters
#798: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:377:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:818: WARNING:LONG_LINE: line over 100 characters
#818: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:397:
+   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);

-:843: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#843: FILE: drivers/gpu/drm/i915/gt/gen6_engine_cs.c:422:
+}
+#undef GEN7_XCS_WA

total: 0 errors, 6 warnings, 2 checks, 1812 lines checked
8f9e2ddc2328 drm/i915/gt: Move legacy context wa to intel_workarounds
5b9d253c3510 drm/i915: Trim the ironlake+ irq handler
cf0807656a76 Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
ce9a7aebf8d2 drm/i915/gt: Couple tasklet scheduling for all CS interrupts
eacfbfb97087 drm/i915/gt: Support creation of 'internal' rings
58305c0b593a drm/i915/gt: Use client timeline address for seqno writes
703dea6710a7 drm/i915: Support inter-engine semaphores on gen6/7
15787ec4da9d drm/i915/gt: Infrastructure for ring scheduling
-:79: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#79: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 842 lines checked
0760ab97f627 drm/i915/gt: Enable busy-stats for ring-scheduler
-:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#13: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 232 lines checked
118524c684c6 drm/i915/gt: Track if an engine requires forcewake w/a
99a81a3f55b0 drm/i915: Relinquish forcewake immediately after manual grouping
8c829f7c5554 drm/i915/gt: Implement ring scheduler for gen6/7
-:68: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#68: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:324:
+   *cs++ = i915_mmio_reg_offset(

-:70: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#70: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:326:
+   *cs++ = _MASKED_BIT_ENABLE(

-:105: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#105: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:361:
+   *cs++ = _MASKED_BIT_DISABLE(

total: 0 errors, 0 warnings, 3 checks, 512 lines checked
3148cd01132a drm/i915/gt: Enable ring scheduling for gen6/7
143d1995d466 drm/i915/gem: Mark the buffer pool as active for the cmdparser
033b56b47071 drm/i915/gem: Async GPU relocations only
9b9d4aa5ab50 drm/i915: Add list_for_each_entry_safe_continue_reverse
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+   for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member);  \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))

-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+   for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member);  \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))

-:20: CHECK:MACRO_ARG

[Intel-gfx] [PATCH v6] drm/i915: Add Plane color encoding support for YCBCR_BT2020

2020-06-01 Thread Kishore Kadiyala
Currently the plane property doesn't have support for YCBCR_BT2020,
which enables the corresponding color conversion mode on plane CSC.
Enabling the plane property for the planes for GLK & ICL+ platforms.
Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709
to YUV601_TO_RGB601.

V2: Enabling support for YCBCT_BT2020 for HDR planes on
platforms GLK & ICL

V3: Refined the condition check to handle GLK & ICL+ HDR planes
Also added BT2020 handling in glk_plane_color_ctl.

V4: Combine If-else into single If

V5: Drop the checking for HDR planes and enable YCBCR_BT2020
for platforms GLK & ICL+.

V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709
to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's
feedback.

V7: Rebased

Cc: Ville Syrjala 
Cc: Jani Nikula 
Reviewed-by: Uma Shankar 
Signed-off-by: Kishore Kadiyala 
---
 drivers/gpu/drm/i915/display/intel_display.c | 15 +++
 drivers/gpu/drm/i915/display/intel_sprite.c  |  9 +++--
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f9f9b20d5f5..a9f752d26b4e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4812,11 +4812,18 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
 
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
-   if (plane_state->hw.color_encoding == DRM_COLOR_YCBCR_BT709)
+   switch (plane_state->hw.color_encoding) {
+   case DRM_COLOR_YCBCR_BT709:
plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
-   else
-   plane_color_ctl |= 
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
-
+   break;
+   case DRM_COLOR_YCBCR_BT2020:
+   plane_color_ctl |=
+   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+   break;
+   default:
+   plane_color_ctl |=
+   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601;
+   }
if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
plane_color_ctl |= 
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 571c36f929bd..3cd461bf9131 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -3061,6 +3061,7 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
struct intel_plane *plane;
enum drm_plane_type plane_type;
unsigned int supported_rotations;
+   unsigned int supported_csc;
const u64 *modifiers;
const u32 *formats;
int num_formats;
@@ -3135,9 +3136,13 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
   DRM_MODE_ROTATE_0,
   supported_rotations);
 
+   supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
+
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+   supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
+
drm_plane_create_color_properties(&plane->base,
- BIT(DRM_COLOR_YCBCR_BT601) |
- BIT(DRM_COLOR_YCBCR_BT709),
+ supported_csc,
  BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
  BIT(DRM_COLOR_YCBCR_FULL_RANGE),
  DRM_COLOR_YCBCR_BT709,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9d50fe0f375..578cfe11cbb9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6932,7 +6932,7 @@ enum {
 #define   PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23) /* Pre-ICL */
 #define   PLANE_COLOR_CSC_MODE_BYPASS  (0 << 17)
-#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709(1 << 17)
+#define   PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601(1 << 17)
 #define   PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709(2 << 17)
 #define   PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020  (3 << 17)
 #define   PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020   (4 << 17)
-- 
2.26.2

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


[Intel-gfx] [PATCH 36/36] drm/i915/gem: Bind the fence async for execbuf

2020-06-01 Thread Chris Wilson
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  41 --
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  | 137 +-
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h  |   5 +
 3 files changed, 166 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 49bfae968215..aa8d86d4466d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -511,13 +511,23 @@ eb_pin_vma(struct i915_execbuffer *eb,
}
 
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
-   if (unlikely(i915_vma_pin_fence(vma))) {
-   i915_vma_unpin(vma);
-   return false;
-   }
+   struct i915_fence_reg *reg = vma->fence;
 
-   if (vma->fence)
+   /* Avoid waiting to change the fence; defer to async worker */
+   if (reg) {
+   if (READ_ONCE(reg->dirty)) {
+   __i915_vma_unpin(vma);
+   return false;
+   }
+
+   atomic_inc(®->pin_count);
ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+   } else {
+   if (i915_gem_object_is_tiled(vma->obj)) {
+   __i915_vma_unpin(vma);
+   return false;
+   }
+   }
}
 
ev->flags |= __EXEC_OBJECT_HAS_PIN;
@@ -1043,15 +1053,6 @@ static int eb_reserve_vma(struct eb_vm_work *work, 
struct eb_vma *ev)
return err;
 
 pin:
-   if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
-   err = __i915_vma_pin_fence(vma); /* XXX no waiting */
-   if (unlikely(err))
-   return err;
-
-   if (vma->fence)
-   ev->flags |= __EXEC_OBJECT_HAS_FENCE;
-   }
-
bind_flags &= ~atomic_read(&vma->flags);
if (bind_flags) {
err = set_bind_fence(vma, work);
@@ -1082,6 +1083,15 @@ static int eb_reserve_vma(struct eb_vm_work *work, 
struct eb_vma *ev)
ev->flags |= __EXEC_OBJECT_HAS_PIN;
GEM_BUG_ON(eb_vma_misplaced(entry, vma, ev->flags));
 
+   if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+   err = __i915_vma_pin_fence_async(vma, &work->base);
+   if (unlikely(err))
+   return err;
+
+   if (vma->fence)
+   ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+   }
+
return 0;
 }
 
@@ -1117,6 +1127,9 @@ static int __eb_bind_vma(struct eb_vm_work *work, int err)
list_for_each_entry(ev, &work->unbound, bind_link) {
struct i915_vma *vma = ev->vma;
 
+   if (ev->flags & __EXEC_OBJECT_HAS_FENCE)
+   __i915_vma_apply_fence_async(vma);
+
if (!ev->bind_flags)
goto put;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 7fb36b12fe7a..734b6aa61809 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -21,10 +21,13 @@
  * IN THE SOFTWARE.
  */
 
+#include "i915_active.h"
 #include "i915_drv.h"
 #include "i915_scatterlist.h"
+#include "i915_sw_fence_work.h"
 #include "i915_pvinfo.h"
 #include "i915_vgpu.h"
+#include "i915_vma.h"
 
 /**
  * DOC: fence register handling
@@ -340,19 +343,37 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt 
*ggtt)
return ERR_PTR(-EDEADLK);
 }
 
+static int fence_wait_bind(struct i915_fence_reg *reg)
+{
+   struct dma_fence *fence;
+   int err = 0;
+
+   fence = i915_active_fence_get(®->active.excl);
+   if (fence) {
+   err = dma_fence_wait(fence, true);
+   dma_fence_put(fence);
+   }
+
+   return err;
+}
+
 int __i915_vma_pin_fence(struct i915_vma *vma)
 {
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
-   struct i915_fence_reg *fence;
+   struct i915_fence_reg *fence = vma->fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
int err;
 
lockdep_assert_held(&vma->vm->mutex);
 
/* Just update our place in the LRU if our fence is getting reused. */
-   if (vma->fence) {
-   fence = vma->fence;
+   if (fence) {
GEM_BUG_ON(fence->vma != vma);
+
+   err = fence_wait_bind(fence);
+   if (err)
+   return err;
+
  

[Intel-gfx] [PATCH 34/36] drm/i915/gem: Separate the ww_mutex walker into its own list

2020-06-01 Thread Chris Wilson
In preparation for making eb_vma bigger and heavy to run inn parallel,
we need to stop apply an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 52 ---
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cb4872ccfe58..b400eed1f435 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -36,6 +36,7 @@ struct eb_vma {
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
struct list_head reloc_link;
+   struct list_head lock_link;
 
struct hlist_node node;
u32 handle;
@@ -247,6 +248,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
 
+   struct list_head lock;
+
/**
 * Track the most recently used object for relocations, as we
 * frequently have to perform multiple relocations within the same
@@ -391,6 +394,10 @@ static int eb_create(struct i915_execbuffer *eb)
eb->lut_size = -eb->buffer_count;
}
 
+   INIT_LIST_HEAD(&eb->relocs);
+   INIT_LIST_HEAD(&eb->unbound);
+   INIT_LIST_HEAD(&eb->lock);
+
return 0;
 }
 
@@ -598,6 +605,8 @@ eb_add_vma(struct i915_execbuffer *eb,
eb_unreserve_vma(ev);
list_add_tail(&ev->bind_link, &eb->unbound);
}
+
+   list_add_tail(&ev->lock_link, &eb->lock);
 }
 
 static int eb_reserve_vma(const struct i915_execbuffer *eb,
@@ -857,9 +866,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
unsigned int i;
int err = 0;
 
-   INIT_LIST_HEAD(&eb->relocs);
-   INIT_LIST_HEAD(&eb->unbound);
-
for (i = 0; i < eb->buffer_count; i++) {
struct i915_vma *vma;
 
@@ -1701,38 +1707,43 @@ static void eb_reloc_signal(struct i915_execbuffer *eb, 
struct i915_request *rq)
 
 static int eb_move_to_gpu(struct i915_execbuffer *eb)
 {
-   const unsigned int count = eb->buffer_count;
struct ww_acquire_ctx acquire;
-   unsigned int i;
+   struct eb_vma *ev;
int err = 0;
 
ww_acquire_init(&acquire, &reservation_ww_class);
 
-   for (i = 0; i < count; i++) {
-   struct eb_vma *ev = &eb->vma[i];
+   list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
 
err = ww_mutex_lock_interruptible(&vma->resv->lock, &acquire);
if (err == -EDEADLK) {
-   GEM_BUG_ON(i == 0);
-   do {
-   int j = i - 1;
-
-   ww_mutex_unlock(&eb->vma[j].vma->resv->lock);
+   struct eb_vma *unlock = ev, *en;
 
-   swap(eb->vma[i],  eb->vma[j]);
-   } while (--i);
+   list_for_each_entry_safe_continue_reverse(unlock, en,
+ &eb->lock,
+ lock_link) {
+   ww_mutex_unlock(&unlock->vma->resv->lock);
+   list_move_tail(&unlock->lock_link, &eb->lock);
+   }
 
+   GEM_BUG_ON(!list_is_first(&ev->lock_link, &eb->lock));
err = ww_mutex_lock_slow_interruptible(&vma->resv->lock,
   &acquire);
}
-   if (err)
-   break;
+   if (err) {
+   list_for_each_entry_continue_reverse(ev,
+&eb->lock,
+lock_link)
+   ww_mutex_unlock(&ev->vma->resv->lock);
+
+   ww_acquire_fini(&acquire);
+   goto err_skip;
+   }
}
ww_acquire_done(&acquire);
 
-   while (i--) {
-   struct eb_vma *ev = &eb->vma[i];
+   list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
unsigned int flags = ev->flags;
struct drm_i915_gem_object *obj = vma->obj;
@@ -2079,9 +2090,10 @@ static int eb_parse(struct i915_execbuffer *eb)
if (err)
goto err_trampoline;
 
-   eb->vma[eb->buffer_count].vma = i915_vma_get(shadow);
-   eb->vma[eb->buffer_count].flags = __EXEC_OBJECT_HAS_PIN;
eb->batch = &eb->vma[eb->buffer_count++];
+   eb->batch->vma = i915_vma_get(shadow);
+   eb->batch->flags = __EXEC_OBJECT_HAS_PIN;
+   list_a

[Intel-gfx] [PATCH 03/36] drm/i915/gt: Move legacy context wa to intel_workarounds

2020-06-01 Thread Chris Wilson
Use the central mechanism for recording and verifying that we restore
the w/a for the older devices as well.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 28 -
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 31 +++
 2 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 96881cd8b17b..d9c1701061b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -429,32 +429,6 @@ static void reset_finish(struct intel_engine_cs *engine)
 {
 }
 
-static int rcs_resume(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *i915 = engine->i915;
-   struct intel_uncore *uncore = engine->uncore;
-
-   /*
-* Disable CONSTANT_BUFFER before it is loaded from the context
-* image. For as it is loaded, it is executed and the stored
-* address may no longer be valid, leading to a GPU hang.
-*
-* This imposes the requirement that userspace reload their
-* CONSTANT_BUFFER on every batch, fortunately a requirement
-* they are already accustomed to from before contexts were
-* enabled.
-*/
-   if (IS_GEN(i915, 4))
-   intel_uncore_write(uncore, ECOSKPD,
-  _MASKED_BIT_ENABLE(ECO_CONSTANT_BUFFER_SR_DISABLE));
-
-   if (IS_GEN_RANGE(i915, 6, 7))
-   intel_uncore_write(uncore, INSTPM,
-  _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
-
-   return xcs_resume(engine);
-}
-
 static void reset_cancel(struct intel_engine_cs *engine)
 {
struct i915_request *request;
@@ -1139,8 +1113,6 @@ static void setup_rcs(struct intel_engine_cs *engine)
 
if (IS_HASWELL(i915))
engine->emit_bb_start = hsw_emit_bb_start;
-
-   engine->resume = rcs_resume;
 }
 
 static void setup_vcs(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index fa1e15657663..94d66a9d760d 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -199,6 +199,18 @@ wa_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, 
u32 val)
 #define WA_SET_FIELD_MASKED(addr, mask, value) \
wa_write_masked_or(wal, (addr), 0, _MASKED_FIELD((mask), (value)))
 
+static void gen6_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
+{
+   WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
+}
+
+static void gen7_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
+{
+   WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
+}
+
 static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine,
  struct i915_wa_list *wal)
 {
@@ -638,6 +650,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
chv_ctx_workarounds_init(engine, wal);
else if (IS_BROADWELL(i915))
bdw_ctx_workarounds_init(engine, wal);
+   else if (IS_GEN(i915, 7))
+   gen7_ctx_workarounds_init(engine, wal);
+   else if (IS_GEN(i915, 6))
+   gen6_ctx_workarounds_init(engine, wal);
else if (INTEL_GEN(i915) < 8)
return;
else
@@ -1583,6 +1599,21 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
   0, _MASKED_BIT_ENABLE(VS_TIMER_DISPATCH),
   /* XXX bit doesn't stick on Broadwater */
   IS_I965G(i915) ? 0 : VS_TIMER_DISPATCH);
+
+   if (IS_GEN(i915, 4))
+   /*
+* Disable CONSTANT_BUFFER before it is loaded from the context
+* image. For as it is loaded, it is executed and the stored
+* address may no longer be valid, leading to a GPU hang.
+*
+* This imposes the requirement that userspace reload their
+* CONSTANT_BUFFER on every batch, fortunately a requirement
+* they are already accustomed to from before contexts were
+* enabled.
+*/
+   wa_add(wal, ECOSKPD,
+  0, _MASKED_BIT_ENABLE(ECO_CONSTANT_BUFFER_SR_DISABLE),
+  0 /* XXX bit doesn't stick on Broadwater */);
 }
 
 static void
-- 
2.20.1

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


[Intel-gfx] [PATCH 31/36] drm/i915: Always defer fenced work to the worker

2020-06-01 Thread Chris Wilson
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context.

With the execute-immediate flag, for most cases this should result in
immediate cleanup of an error.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_sw_fence_work.c | 25 +++
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c 
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index a3a81bb8f2c3..29f63ebc24e8 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -16,11 +16,14 @@ static void fence_complete(struct dma_fence_work *f)
 static void fence_work(struct work_struct *work)
 {
struct dma_fence_work *f = container_of(work, typeof(*f), work);
-   int err;
 
-   err = f->ops->work(f);
-   if (err)
-   dma_fence_set_error(&f->dma, err);
+   if (!f->dma.error) {
+   int err;
+
+   err = f->ops->work(f);
+   if (err)
+   dma_fence_set_error(&f->dma, err);
+   }
 
fence_complete(f);
dma_fence_put(&f->dma);
@@ -36,15 +39,11 @@ fence_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
if (fence->error)
dma_fence_set_error(&f->dma, fence->error);
 
-   if (!f->dma.error) {
-   dma_fence_get(&f->dma);
-   if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
-   fence_work(&f->work);
-   else
-   queue_work(system_unbound_wq, &f->work);
-   } else {
-   fence_complete(f);
-   }
+   dma_fence_get(&f->dma);
+   if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
+   fence_work(&f->work);
+   else
+   queue_work(system_unbound_wq, &f->work);
break;
 
case FENCE_FREE:
-- 
2.20.1

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


[Intel-gfx] [PATCH 20/36] drm/i915/gem: Lift GPU relocation allocation

2020-06-01 Thread Chris Wilson
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 98 ++-
 .../i915/gem/selftests/i915_gem_execbuffer.c  |  5 +-
 2 files changed, 56 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bed7c7ea2723..9537fd87e3a4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -900,8 +900,6 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long 
handle)
 
 static void eb_destroy(const struct i915_execbuffer *eb)
 {
-   GEM_BUG_ON(eb->reloc_cache.rq);
-
if (eb->array)
eb_vma_array_put(eb->array);
 
@@ -926,7 +924,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
-   cache->rq = NULL;
cache->target = NULL;
 }
 
@@ -1026,13 +1023,9 @@ static unsigned int reloc_bb_flags(const struct 
reloc_cache *cache)
 
 static int reloc_gpu_flush(struct reloc_cache *cache)
 {
-   struct i915_request *rq;
+   struct i915_request *rq = cache->rq;
int err;
 
-   rq = fetch_and_zero(&cache->rq);
-   if (!rq)
-   return 0;
-
if (cache->rq_vma) {
struct drm_i915_gem_object *obj = cache->rq_vma->obj;
 
@@ -1081,9 +1074,8 @@ static int reloc_move_to_gpu(struct i915_request *rq, 
struct i915_vma *vma)
return err;
 }
 
-static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
-struct intel_engine_cs *engine,
-unsigned int len)
+static int
+__reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_engine_cs *engine)
 {
struct reloc_cache *cache = &eb->reloc_cache;
struct intel_gt_buffer_pool_node *pool;
@@ -1173,33 +1165,14 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
return err;
 }
 
-static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
-{
-   return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
-}
-
-static u32 *reloc_gpu(struct i915_execbuffer *eb,
- struct i915_vma *vma,
- unsigned int len)
+static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
+struct i915_vma *vma,
+unsigned int len)
 {
struct reloc_cache *cache = &eb->reloc_cache;
u32 *cmd;
int err;
 
-   if (unlikely(!cache->rq)) {
-   struct intel_engine_cs *engine = eb->engine;
-
-   if (!reloc_can_use_engine(engine)) {
-   engine = engine->gt->engine_class[COPY_ENGINE_CLASS][0];
-   if (!engine)
-   return ERR_PTR(-ENODEV);
-   }
-
-   err = __reloc_gpu_alloc(eb, engine, len);
-   if (unlikely(err))
-   return ERR_PTR(err);
-   }
-
if (vma != cache->target) {
err = reloc_move_to_gpu(cache->rq, vma);
if (unlikely(err)) {
@@ -1257,7 +1230,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
else
len = 3;
 
-   batch = reloc_gpu(eb, vma, len);
+   batch = reloc_batch_grow(eb, vma, len);
if (IS_ERR(batch))
return PTR_ERR(batch);
 
@@ -1577,6 +1550,47 @@ static long eb_reloc_vma_validate(struct i915_execbuffer 
*eb, struct eb_vma *ev)
return required;
 }
 
+static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
+{
+   return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+}
+
+static int reloc_gpu_alloc(struct i915_execbuffer *eb)
+{
+   struct intel_engine_cs *engine = eb->engine;
+
+   if (!reloc_can_use_engine(engine)) {
+   engine = engine->gt->engine_class[COPY_ENGINE_CLASS][0];
+   if (!engine)
+   return -ENODEV;
+   }
+
+   return __reloc_gpu_alloc(eb, engine);
+}
+
+static int reloc_gpu(struct i915_execbuffer *eb)
+{
+   struct eb_vma *ev;
+   int flush, err;
+
+   err = reloc_gpu_alloc(eb);
+   if (err)
+   return err;
+   GEM_BUG_ON(!eb->reloc_cache.rq);
+
+   list_for_each_entry(ev, &eb->relocs, reloc_link) {
+   err = eb_relocate_vma(eb, ev);
+   if (err)
+   goto out;
+   }
+
+out:
+   flush = reloc_gpu_flush(&eb->reloc_cache);
+   if (!err)
+   err = flush;
+   return err;
+}
+
 static int eb_relocate(struct i915_execbuffer *eb)
 {
int err;
@

[Intel-gfx] [PATCH 15/36] drm/i915/gt: Enable ring scheduling for gen6/7

2020-06-01 Thread Chris Wilson
Switch over from FIFO global submission to the priority-sorted
topographical scheduler. At the cost of more busy work on the CPU to
keep the GPU supplied with the next packet of requests, this allows us
to reorder requests around submission stalls.

This also enables the timer based RPS, with the exception of Valleyview
who's PCU doesn't take kindly to our interference.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
 drivers/gpu/drm/i915/gt/intel_rps.c   | 6 ++
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..bb57687aea99 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -94,7 +94,7 @@ static int live_nop_switch(void *arg)
rq = i915_request_get(this);
i915_request_add(this);
}
-   if (i915_request_wait(rq, 0, HZ / 5) < 0) {
+   if (i915_request_wait(rq, 0, HZ) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
intel_gt_set_wedged(&i915->gt);
i915_request_put(rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 64e13c074708..c29727b3ba4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -791,6 +791,8 @@ int intel_engines_init(struct intel_gt *gt)
 
if (HAS_EXECLISTS(gt->i915))
setup = intel_execlists_submission_setup;
+   else if (INTEL_GEN(gt->i915) >= 6)
+   setup = intel_ring_scheduler_setup;
else
setup = intel_ring_submission_setup;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 2e4ddc9ca09d..22882c2953da 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1053,9 +1053,7 @@ static bool gen6_rps_enable(struct intel_rps *rps)
intel_uncore_write_fw(uncore, GEN6_RP_DOWN_TIMEOUT, 5);
intel_uncore_write_fw(uncore, GEN6_RP_IDLE_HYSTERSIS, 10);
 
-   rps->pm_events = (GEN6_PM_RP_UP_THRESHOLD |
- GEN6_PM_RP_DOWN_THRESHOLD |
- GEN6_PM_RP_DOWN_TIMEOUT);
+   rps->pm_events = GEN6_PM_RP_UP_THRESHOLD | GEN6_PM_RP_DOWN_THRESHOLD;
 
return rps_reset(rps);
 }
@@ -1362,7 +1360,7 @@ void intel_rps_enable(struct intel_rps *rps)
GEM_BUG_ON(rps->efficient_freq < rps->min_freq);
GEM_BUG_ON(rps->efficient_freq > rps->max_freq);
 
-   if (has_busy_stats(rps))
+   if (has_busy_stats(rps) && !IS_VALLEYVIEW(i915))
intel_rps_set_timer(rps);
else if (INTEL_GEN(i915) >= 6)
intel_rps_set_interrupts(rps);
-- 
2.20.1

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


[Intel-gfx] [PATCH 13/36] drm/i915: Relinquish forcewake immediately after manual grouping

2020-06-01 Thread Chris Wilson
Our forcewake utilisation is split into categories: automatic and
manual. Around bare register reads, we look up the right forcewake
domain and automatically acquire and release [upon a timer] the
forcewake domain. For other access, where we know we require the
forcewake across a group of register reads, we manually acquire the
forcewake domain and release it at the end. Again, this currently arms
the domain timer for a later release.

However, looking at some energy utilisation profiles, we have tried to
avoid using forcewake [and rely on the natural wake up to post register
updates] due to that even keep the fw active for a brief period
contributes to a significant power draw [i.e. when the gpu is sleeping
with rc6 at high clocks]. But as it turns out, not posting the writes
immediately also has unintended consequences, such as not reducing the
clocks and so conserving power while busy.

As a compromise, let us only arm the domain timer for automatic
forcewake usage around bare register access, but immediately release the
forcewake when manually acquired by intel_uncore_forcewake_get/_put.

The corollary to this is that we may instead have to take forcewake more
often, and so incur a latency penalty in doing so. For Sandybridge this
was significant, and even on the latest machines, taking forcewake at
interrupt frequency is a huge impact. [So we don't do that anymore!
Hopefully, this will spare us from still needing the mitigation of the
timer for steady state execution.]

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_uncore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index a61cb8ca4d50..7d6b9ae7403c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -709,7 +709,7 @@ static void __intel_uncore_forcewake_put(struct 
intel_uncore *uncore,
continue;
}
 
-   fw_domain_arm_timer(domain);
+   uncore->funcs.force_wake_put(uncore, domain->mask);
}
 }
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 26/36] drm/syncobj: Allow use of dma-fence-proxy

2020-06-01 Thread Chris Wilson
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_syncobj.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 42d46414f767..e141db0e1eb6 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,6 +184,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -324,14 +325,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *old_fence;
struct syncobj_wait_entry *cur, *tmp;
 
-   if (fence)
-   dma_fence_get(fence);
-
spin_lock(&syncobj->lock);
 
-   old_fence = rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(&syncobj->lock));
-   rcu_assign_pointer(syncobj->fence, fence);
+   old_fence = dma_fence_replace_proxy(&syncobj->fence, fence);
 
if (fence != old_fence) {
list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node)
-- 
2.20.1

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


[Intel-gfx] [PATCH 19/36] drm/i915/gem: Separate reloc validation into an earlier step

2020-06-01 Thread Chris Wilson
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc validation into an early step, which we can use both to
reject the execbuf before committing to making our changes, and to
filter out the unmodified vma.

This does introduce a second pass through the reloc[], but only if we
need to emit relocations.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 178 +-
 1 file changed, 133 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 540188454b6d..bed7c7ea2723 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1331,6 +1331,117 @@ static u64
 eb_relocate_entry(struct i915_execbuffer *eb,
  struct eb_vma *ev,
  const struct drm_i915_gem_relocation_entry *reloc)
+{
+   struct eb_vma *target;
+
+   /* we've already hold a reference to all valid objects */
+   target = eb_get_vma(eb, reloc->target_handle);
+   if (unlikely(!target))
+   return -ENOENT;
+
+   /*
+* If the relocation already has the right value in it, no
+* more work needs to be done.
+*/
+   if (gen8_canonical_addr(target->vma->node.start) == 
reloc->presumed_offset)
+   return 0;
+
+   /*
+* If we write into the object, we need to force the synchronisation
+* barrier, either with an asynchronous clflush or if we executed the
+* patching using the GPU (though that should be serialised by the
+* timeline). To be completely sure, and since we are required to
+* do relocations we are already stalling, disable the user's opt
+* out of our synchronisation.
+*/
+   ev->flags &= ~EXEC_OBJECT_ASYNC;
+
+   /* and update the user's relocation entry */
+   return relocate_entry(eb, ev->vma, reloc, target->vma);
+}
+
+static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+#define N_RELOC(x) ((x) / sizeof(struct drm_i915_gem_relocation_entry))
+   struct drm_i915_gem_relocation_entry stack[N_RELOC(512)];
+   const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+   struct drm_i915_gem_relocation_entry __user *urelocs =
+   u64_to_user_ptr(entry->relocs_ptr);
+   unsigned long remain = entry->relocation_count;
+
+   if (unlikely(remain > N_RELOC(ULONG_MAX)))
+   return -EINVAL;
+
+   /*
+* We must check that the entire relocation array is safe
+* to read. However, if the array is not writable the user loses
+* the updated relocation values.
+*/
+   if (unlikely(!access_ok(urelocs, remain * sizeof(*urelocs
+   return -EFAULT;
+
+   do {
+   struct drm_i915_gem_relocation_entry *r = stack;
+   unsigned int count =
+   min_t(unsigned long, remain, ARRAY_SIZE(stack));
+   unsigned int copied;
+
+   /*
+* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+   copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+   if (unlikely(copied))
+   return -EFAULT;
+
+   remain -= count;
+   do {
+   u64 offset = eb_relocate_entry(eb, ev, r);
+
+   if (likely(offset == 0)) {
+   } else if ((s64)offset < 0) {
+   return (int)offset;
+   } else {
+   /*
+* Note that reporting an error now
+* leaves everything in an inconsistent
+* state as we have *already* changed
+* the relocation value inside the
+* object. As we have not changed the
+* reloc.presumed_offset or will not
+* change the execobject.offset, on the
+* call we may not rewrite the value
+* inside the object, leaving it
+* dangling and causing a GPU hang. Unless
+   

[Intel-gfx] [PATCH 24/36] drm/i915: Unpeel awaits on a proxy fence

2020-06-01 Thread Chris Wilson
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-completion.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c   | 157 ++
 drivers/gpu/drm/i915/i915_scheduler.c |  41 +++
 drivers/gpu/drm/i915/i915_scheduler.h |   3 +
 3 files changed, 201 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 9537e30f9439..02747c171c54 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -461,6 +462,7 @@ static bool fatal_error(int error)
case 0: /* not an error! */
case -EAGAIN: /* innocent victim of a GT reset (__i915_request_reset) */
case -ETIMEDOUT: /* waiting for Godot (timer_i915_sw_fence_wake) */
+   case -EDEADLK: /* cyclic fence lockup (await_proxy)  */
return false;
default:
return true;
@@ -1251,6 +1253,138 @@ i915_request_await_external(struct i915_request *rq, 
struct dma_fence *fence)
return err;
 }
 
+struct await_proxy {
+   struct wait_queue_entry base;
+   struct i915_request *request;
+   struct dma_fence *fence;
+   struct timer_list timer;
+   struct work_struct work;
+   int (*attach)(struct await_proxy *ap);
+   void *data;
+};
+
+static void await_proxy_work(struct work_struct *work)
+{
+   struct await_proxy *ap = container_of(work, typeof(*ap), work);
+   struct i915_request *rq = ap->request;
+
+   del_timer_sync(&ap->timer);
+
+   if (ap->fence) {
+   int err = 0;
+
+   /*
+* If the fence is external, we impose a 10s timeout.
+* However, if the fence is internal, we skip a timeout in
+* the belief that all fences are in-order (DAG, no cycles)
+* and we can enforce forward progress by reset the GPU if
+* necessary. A future fence, provided userspace, can trivially
+* generate a cycle in the dependency graph, and so cause
+* that entire cycle to become deadlocked and for no forward
+* progress to either be made, and the driver being kept
+* eternally awake.
+*/
+   if (dma_fence_is_i915(ap->fence) &&
+   !i915_sched_node_verify_dag(&rq->sched,
+   &to_request(ap->fence)->sched))
+   err = -EDEADLK;
+
+   if (!err) {
+   mutex_lock(&rq->context->timeline->mutex);
+   err = ap->attach(ap);
+   mutex_unlock(&rq->context->timeline->mutex);
+   }
+
+   /* Don't flag an error for co-dependent scheduling */
+   if (err == -EDEADLK) {
+   struct i915_sched_node *waiter =
+   &to_request(ap->fence)->sched;
+   struct i915_dependency *p;
+
+   list_for_each_entry_lockless(p,
+&rq->sched.waiters_list,
+wait_link) {
+   if (p->waiter == waiter &&
+   p->flags & I915_DEPENDENCY_WEAK) {
+   err = 0;
+   break;
+   }
+   }
+   }
+
+   if (err < 0)
+   i915_sw_fence_set_error_once(&rq->submit, err);
+   }
+
+   i915_sw_fence_complete(&rq->submit);
+
+   dma_fence_put(ap->fence);
+   kfree(ap);
+}
+
+static int
+await_proxy_wake(struct wait_queue_entry *entry,
+unsigned int mode,
+int flags,
+void *fence)
+{
+   struct await_proxy *ap = container_of(entry, typeof(*ap), base);
+
+   ap->fence = dma_fence_get(fence);
+   schedule_work(&ap->work);
+
+   return 0;
+}
+
+static void
+await_proxy_timer(struct timer_list *t)
+{
+   struct await_proxy *ap = container_of(t, typeof(*ap), timer);
+
+   if (dma_fence_remove_proxy_listener(ap->base.private, &ap->base)) {
+   struct i915_request *rq = ap->request;
+
+   pr_notice("Asynchronous wait on unset proxy fence by %s:%s:%llx 
timed out\n",
+ rq->fence.ops->get_driver_name(&rq->fence),
+ rq->fence.ops->get_timeline_name(&rq->fence),
+ rq->fence.seqno);
+   i915_sw_fence_set_error_once(&rq->submit, -ETIMEDOUT)

[Intel-gfx] [PATCH 06/36] drm/i915/gt: Couple tasklet scheduling for all CS interrupts

2020-06-01 Thread Chris Wilson
If any engine asks for the tasklet to be kicked from the CS interrupt,
do so.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c | 17 -
 drivers/gpu/drm/i915/gt/intel_gt_irq.h |  3 +++
 drivers/gpu/drm/i915/gt/intel_rps.c|  2 +-
 drivers/gpu/drm/i915/i915_irq.c|  8 
 4 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0cc7dd54f4f9..28edf314a319 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -60,6 +60,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
tasklet_hi_schedule(&engine->execlists.tasklet);
 }
 
+void gen2_engine_cs_irq(struct intel_engine_cs *engine)
+{
+   intel_engine_signal_breadcrumbs(engine);
+   if (intel_engine_needs_breadcrumb_tasklet(engine))
+   tasklet_hi_schedule(&engine->execlists.tasklet);
+}
+
 static u32
 gen11_gt_engine_identity(struct intel_gt *gt,
 const unsigned int bank, const unsigned int bit)
@@ -273,9 +280,9 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
 void gen5_gt_irq_handler(struct intel_gt *gt, u32 gt_iir)
 {
if (gt_iir & GT_RENDER_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(gt->engine_class[RENDER_CLASS][0]);
+   gen2_engine_cs_irq(gt->engine_class[RENDER_CLASS][0]);
if (gt_iir & ILK_BSD_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(gt->engine_class[VIDEO_DECODE_CLASS][0]);
+   gen2_engine_cs_irq(gt->engine_class[VIDEO_DECODE_CLASS][0]);
 }
 
 static void gen7_parity_error_irq_handler(struct intel_gt *gt, u32 iir)
@@ -299,11 +306,11 @@ static void gen7_parity_error_irq_handler(struct intel_gt 
*gt, u32 iir)
 void gen6_gt_irq_handler(struct intel_gt *gt, u32 gt_iir)
 {
if (gt_iir & GT_RENDER_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(gt->engine_class[RENDER_CLASS][0]);
+   gen2_engine_cs_irq(gt->engine_class[RENDER_CLASS][0]);
if (gt_iir & GT_BSD_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(gt->engine_class[VIDEO_DECODE_CLASS][0]);
+   gen2_engine_cs_irq(gt->engine_class[VIDEO_DECODE_CLASS][0]);
if (gt_iir & GT_BLT_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(gt->engine_class[COPY_ENGINE_CLASS][0]);
+   gen2_engine_cs_irq(gt->engine_class[COPY_ENGINE_CLASS][0]);
 
if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
  GT_BSD_CS_ERROR_INTERRUPT |
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.h 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.h
index 886c5cf408a2..6c69cd563fe1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.h
@@ -9,6 +9,7 @@
 
 #include 
 
+struct intel_engine_cs;
 struct intel_gt;
 
 #define GEN8_GT_IRQS (GEN8_GT_RCS_IRQ | \
@@ -19,6 +20,8 @@ struct intel_gt;
  GEN8_GT_PM_IRQ | \
  GEN8_GT_GUC_IRQ)
 
+void gen2_engine_cs_irq(struct intel_engine_cs *engine);
+
 void gen11_gt_irq_reset(struct intel_gt *gt);
 void gen11_gt_irq_postinstall(struct intel_gt *gt);
 void gen11_gt_irq_handler(struct intel_gt *gt, const u32 master_ctl);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 2f59fc6df3c2..2e4ddc9ca09d 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1741,7 +1741,7 @@ void gen6_rps_irq_handler(struct intel_rps *rps, u32 
pm_iir)
return;
 
if (pm_iir & PM_VEBOX_USER_INTERRUPT)
-   intel_engine_signal_breadcrumbs(gt->engine[VECS0]);
+   gen2_engine_cs_irq(gt->engine[VECS0]);
 
if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT)
DRM_DEBUG("Command parser error, pm_iir 0x%08x\n", pm_iir);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 07c0c7ea3795..096123777533 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3678,7 +3678,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
intel_uncore_write16(&dev_priv->uncore, GEN2_IIR, iir);
 
if (iir & I915_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(dev_priv->gt.engine[RCS0]);
+   gen2_engine_cs_irq(dev_priv->gt.engine[RCS0]);
 
if (iir & I915_MASTER_ERROR_INTERRUPT)
i8xx_error_irq_handler(dev_priv, eir, eir_stuck);
@@ -3783,7 +3783,7 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
I915_WRITE(GEN2_IIR, iir);
 
if (iir & I915_USER_INTERRUPT)
-   
intel_engine_signal_breadcrumbs(dev_priv->gt.engine[RCS0]);
+   gen2_engine_cs_irq(dev_priv->gt.engine[RCS0]);
 
if (iir & I915_MASTER_ERROR_INTERR

[Intel-gfx] [PATCH 22/36] drm/i915/gem: Add all GPU reloc awaits/signals en masse

2020-06-01 Thread Chris Wilson
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the timelines en masse.

Testcase: igt/gem_exec_reloc/basic-concurrent16
Fixes: 0e97fbb08055 ("drm/i915/gem: Use a single chained reloc batches for a 
single execbuf")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1889
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 114 --
 .../i915/gem/selftests/i915_gem_execbuffer.c  |  24 ++--
 2 files changed, 93 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c48950d7f1c9..37855ae8f8b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -259,7 +259,6 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
 
-   struct i915_vma *target;
struct i915_request *rq;
struct i915_vma *rq_vma;
u32 *rq_cmd;
@@ -924,7 +923,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
-   cache->target = NULL;
 }
 
 static inline void *unmask_page(unsigned long p)
@@ -1057,26 +1055,6 @@ static void reloc_gpu_flush(struct reloc_cache *cache)
i915_request_add(rq);
 }
 
-static int reloc_move_to_gpu(struct i915_request *rq, struct i915_vma *vma)
-{
-   struct drm_i915_gem_object *obj = vma->obj;
-   int err;
-
-   i915_vma_lock(vma);
-
-   if (obj->cache_dirty & ~obj->cache_coherent)
-   i915_gem_clflush_object(obj, 0);
-   obj->write_domain = 0;
-
-   err = i915_request_await_object(rq, vma->obj, true);
-   if (err == 0)
-   err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
-
-   i915_vma_unlock(vma);
-
-   return err;
-}
-
 static int
 __reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_engine_cs *engine)
 {
@@ -1166,24 +1144,12 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct 
intel_engine_cs *engine)
return err;
 }
 
-static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
-struct i915_vma *vma,
-unsigned int len)
+static u32 *reloc_batch_grow(struct i915_execbuffer *eb, unsigned int len)
 {
struct reloc_cache *cache = &eb->reloc_cache;
u32 *cmd;
int err;
 
-   if (vma != cache->target) {
-   err = reloc_move_to_gpu(cache->rq, vma);
-   if (unlikely(err)) {
-   i915_request_set_error_once(cache->rq, err);
-   return ERR_PTR(err);
-   }
-
-   cache->target = vma;
-   }
-
if (unlikely(cache->rq_size + len >
 PAGE_SIZE / sizeof(u32) - RELOC_TAIL)) {
err = reloc_gpu_chain(cache);
@@ -1229,7 +1195,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
else
len = 3;
 
-   batch = reloc_batch_grow(eb, vma, len);
+   batch = reloc_batch_grow(eb, len);
if (IS_ERR(batch))
return PTR_ERR(batch);
 
@@ -1549,6 +1515,78 @@ static long eb_reloc_vma_validate(struct i915_execbuffer 
*eb, struct eb_vma *ev)
return required;
 }
 
+static int reloc_move_to_gpu(struct reloc_cache *cache, struct eb_vma *ev)
+{
+   struct i915_request *rq = cache->rq;
+   struct i915_vma *vma = ev->vma;
+   struct drm_i915_gem_object *obj = vma->obj;
+   int err;
+
+   if (obj->cache_dirty & ~obj->cache_coherent)
+   i915_gem_clflush_object(obj, 0);
+
+   obj->write_domain = I915_GEM_DOMAIN_RENDER;
+   obj->read_domains = I915_GEM_DOMAIN_RENDER;
+
+   err = i915_request_await_object(rq, obj, true);
+   if (err)
+   return err;
+
+   err = __i915_vma_move_to_active(vma, rq);
+   if (err)
+   return err;
+
+   dma_resv_add_excl_fence(vma->resv, &rq->fence);
+
+   return 0;
+}
+
+static int
+lock_relocs(struct i915_execbuffer *eb)
+{
+   struct ww_acquire_ctx acquire;
+   struct eb_vma *ev;
+   int err = 0;
+
+   ww_acquire_init(&acquire, &reservation_ww_class);
+
+   list_for_each_entry(ev, &eb->relocs, reloc_link) {
+   struct i915_vma *vma = ev->vma;
+
+   err = ww_mutex_lock_interruptible(&vma->resv->lock, &acquire);
+   if (err == -EDEADLK) {
+   struct eb_vma *unlock = ev, *en;
+
+   list_for_each_entry_safe_continue_reverse(unlock, en,
+

[Intel-gfx] [PATCH 09/36] drm/i915: Support inter-engine semaphores on gen6/7

2020-06-01 Thread Chris Wilson
Should we gain per-client timelines, we can then utilise the separate
HWSP in order to use MI_SEMAPHORE_MBOX with the unique GGTT addresses
required for synchronising between clients across different engines.
Teach the emit_semaphore_wait about MI_SEMAPHORE_MBOX for the older
generations.

Note that the engine must still indicate support for the semaphore
synchronisation before the context is allowed to use them.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c | 31 +++--
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c5d7220de529..9537e30f9439 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1016,7 +1016,7 @@ __emit_semaphore_wait(struct i915_request *to,
int len, err;
u32 *cs;
 
-   GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
+   GEM_BUG_ON(INTEL_GEN(to->i915) < 6);
GEM_BUG_ON(i915_request_has_initial_breadcrumb(to));
 
/* We need to pin the signaler's HWSP until we are finished reading. */
@@ -1040,17 +1040,26 @@ __emit_semaphore_wait(struct i915_request *to,
 * (post-wrap) values than they were expecting (and so wait
 * forever).
 */
-   *cs++ = (MI_SEMAPHORE_WAIT |
-MI_SEMAPHORE_GLOBAL_GTT |
-MI_SEMAPHORE_POLL |
-MI_SEMAPHORE_SAD_GTE_SDD) +
-   has_token;
-   *cs++ = seqno;
-   *cs++ = hwsp_offset;
-   *cs++ = 0;
-   if (has_token) {
+   if (INTEL_GEN(to->i915) >= 8) {
+   *cs++ = (MI_SEMAPHORE_WAIT |
+MI_SEMAPHORE_GLOBAL_GTT |
+MI_SEMAPHORE_POLL |
+MI_SEMAPHORE_SAD_GTE_SDD) +
+   has_token;
+   *cs++ = seqno;
+   *cs++ = hwsp_offset;
+   *cs++ = 0;
+   if (has_token) {
+   *cs++ = 0;
+   *cs++ = MI_NOOP;
+   }
+   } else {
+   *cs++ = (MI_SEMAPHORE_MBOX |
+MI_SEMAPHORE_GLOBAL_GTT |
+MI_SEMAPHORE_COMPARE);
+   *cs++ = seqno - 1; /* COMPARE is a strict greater-than */
+   *cs++ = hwsp_offset;
*cs++ = 0;
-   *cs++ = MI_NOOP;
}
 
intel_ring_advance(to, cs);
-- 
2.20.1

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


[Intel-gfx] [PATCH 11/36] drm/i915/gt: Enable busy-stats for ring-scheduler

2020-06-01 Thread Chris Wilson
Couple up the context in/out accounting to record how long each engine
is busy handling requests. This is exposed to userspace for more accurate
measurements, and also enables our soft-rps timer.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_engine_stats.h  | 49 +++
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 34 +---
 .../gpu/drm/i915/gt/intel_ring_scheduler.c|  4 +
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c  | 86 +++
 drivers/gpu/drm/i915/gt/selftest_rps.c|  5 ++
 5 files changed, 145 insertions(+), 33 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h 
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include 
+#include 
+#include 
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+
+   if (atomic_add_unless(&engine->stats.active, 1, 0))
+   return;
+
+   write_seqlock_irqsave(&engine->stats.lock, flags);
+   if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
+   engine->stats.start = ktime_get();
+   atomic_inc(&engine->stats.active);
+   }
+   write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+
+   GEM_BUG_ON(!atomic_read(&engine->stats.active));
+
+   if (atomic_add_unless(&engine->stats.active, -1, 1))
+   return;
+
+   write_seqlock_irqsave(&engine->stats.lock, flags);
+   if (atomic_dec_and_test(&engine->stats.active)) {
+   engine->stats.total =
+   ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+   }
+   write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6fc0966b75ff..13ef4f58cb08 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
 #include "i915_vgpu.h"
 #include "intel_context.h"
 #include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -1187,39 +1188,6 @@ execlists_context_status_change(struct i915_request *rq, 
unsigned long status)
   status, rq);
 }
 
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
-   unsigned long flags;
-
-   if (atomic_add_unless(&engine->stats.active, 1, 0))
-   return;
-
-   write_seqlock_irqsave(&engine->stats.lock, flags);
-   if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
-   engine->stats.start = ktime_get();
-   atomic_inc(&engine->stats.active);
-   }
-   write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
-   unsigned long flags;
-
-   GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
-   if (atomic_add_unless(&engine->stats.active, -1, 1))
-   return;
-
-   write_seqlock_irqsave(&engine->stats.lock, flags);
-   if (atomic_dec_and_test(&engine->stats.active)) {
-   engine->stats.total =
-   ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
-   }
-   write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
 static void
 execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c 
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
index c8cd435d1c51..aaff554865b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -9,6 +9,7 @@
 
 #include "i915_drv.h"
 #include "intel_context.h"
+#include "intel_engine_stats.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -59,6 +60,7 @@ static struct i915_request *
 schedule_in(struct intel_engine_cs *engine, struct i915_request *rq)
 {
__intel_gt_pm_get(engine->gt);
+   intel_engine_context_in(engine);
return i915_request_get(rq);
 }
 
@@ -71,6 +73,7 @@ schedule_out(struct intel_engine_cs *engine, struct 
i915_request *rq)
intel_engine_add_retire(engine, ce->timeline);
 
i915_req

[Intel-gfx] [PATCH 23/36] dma-buf: Proxy fence, an unsignaled fence placeholder

2020-06-01 Thread Chris Wilson
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real fence completes, and any future listeners will instead be
attach directly to the real fence avoiding any indirection overhead.

Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
---
 drivers/dma-buf/Makefile |  13 +-
 drivers/dma-buf/dma-fence-private.h  |  20 +
 drivers/dma-buf/dma-fence-proxy.c| 306 +++
 drivers/dma-buf/dma-fence.c  |   4 +-
 drivers/dma-buf/selftests.h  |   1 +
 drivers/dma-buf/st-dma-fence-proxy.c | 752 +++
 include/linux/dma-fence-proxy.h  |  38 ++
 7 files changed, 1130 insertions(+), 4 deletions(-)
 create mode 100644 drivers/dma-buf/dma-fence-private.h
 create mode 100644 drivers/dma-buf/dma-fence-proxy.c
 create mode 100644 drivers/dma-buf/st-dma-fence-proxy.c
 create mode 100644 include/linux/dma-fence-proxy.h

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 995e05f609ff..afaf6dadd9a3 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-dma-resv.o seqno-fence.o
+obj-y := \
+   dma-buf.o \
+   dma-fence.o \
+   dma-fence-array.o \
+   dma-fence-chain.o \
+   dma-fence-proxy.o \
+   dma-resv.o \
+   seqno-fence.o
 obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
 obj-$(CONFIG_DMABUF_HEAPS) += heaps/
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
@@ -10,6 +16,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
 dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
-   st-dma-fence-chain.o
+   st-dma-fence-chain.o \
+   st-dma-fence-proxy.o
 
 obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/dma-fence-private.h 
b/drivers/dma-buf/dma-fence-private.h
new file mode 100644
index ..6924d28af0fa
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-private.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark 
+ * Maarten Lankhorst 
+ */
+
+#ifndef DMA_FENCE_PRIVATE_H
+#define DMA_FENCE_PRIAVTE_H
+
+struct dma_fence;
+
+bool __dma_fence_enable_signaling(struct dma_fence *fence);
+
+#endif /* DMA_FENCE_PRIAVTE_H */
diff --git a/drivers/dma-buf/dma-fence-proxy.c 
b/drivers/dma-buf/dma-fence-proxy.c
new file mode 100644
index ..42674e92b0f9
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-proxy.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dma-fence-proxy: placeholder unsignaled fence
+ *
+ * Copyright (C) 2017-2019 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dma-fence-private.h"
+
+struct dma_fence_proxy {
+   struct dma_fence base;
+
+   struct dma_fence *real;
+   struct dma_fence_cb cb;
+   struct irq_work work;
+
+   wait_queue_head_t wq;
+};
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define same_lockclass(A, B) (A)->dep_map.key == (B)->dep_map.key
+#else
+#define same_lockclass(A, B) 0
+#endif
+
+static const char *proxy_get_driver_name(struct dma_fence *fence)
+{
+   struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+   struct dma_fence *real = READ_ONCE(p->real);
+
+   return real ? real->ops->get_driver_name(real) : "proxy";
+}
+
+static const char *proxy_get_timeline_name(struct dma_fence *fence)
+{
+   struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+   struct dma_fence *real = READ_ONCE(p->real);
+
+   return real ? real->ops->get_timeline_name(real) : "unset";
+}
+
+static void proxy_irq_work(struct irq_work *work)
+{
+   struct dma_fence_proxy *p = container_of(work, typeof(*p), work);
+
+   dma_fence_signal(&p->base);
+   dma_fence_put(&p->base);
+}
+
+static void proxy_callback(struct dma_fence *real, struct dma_fence_cb *cb)
+{
+   struct dma_fence_proxy *p = container_of(cb, typeof(*p), cb);
+
+   /* Signaled before enabling signalling callbacks? */
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &p->base.flags)) {
+   dma_fence_put(&p->base);
+   return;
+   }
+
+   if (real->error)
+   dma_fence_set_error(&p->base, real->error);
+
+   /* Lower the height of the proxy chain -> single stack frame */
+   irq_work_queue(&p->work);
+}
+
+static bool proxy_enable_signaling(struct dma_fence *fence)
+{
+   struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+   struct dma_fence *real = READ_ONCE(p->real);
+ 

[Intel-gfx] [PATCH 17/36] drm/i915/gem: Async GPU relocations only

2020-06-01 Thread Chris Wilson
Reduce the 3 relocation patches down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).

The tradeoff in using async gpu relocations is that it increases latency
over using direct CPU relocations, for the cases where the target is
idle and accessible by the CPU. The benefit is greatly reduced lock
contention and improved concurrency by pipelining.

Note that forcing the async gpu relocations does reveal a few issues
they have. Firstly, is that they are visible as writes to gem_busy,
causing to mark some buffers are being to written to by the GPU even
though userspace only reads. Secondly is that, in combination with the
cmdparser, they can cause priority inversions. This should be the case
where the work is being put into a common workqueue losing our priority
information and so being executed in FIFO from the worker, denying us
the opportunity to reorder the requests afterwards.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 295 ++
 .../i915/gem/selftests/i915_gem_execbuffer.c  |  21 +-
 2 files changed, 27 insertions(+), 289 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 0829ac8a55bf..540188454b6d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -45,13 +45,6 @@ struct eb_vma_array {
struct eb_vma vma[];
 };
 
-enum {
-   FORCE_CPU_RELOC = 1,
-   FORCE_GTT_RELOC,
-   FORCE_GPU_RELOC,
-#define DBG_FORCE_RELOC 0 /* choose one of the above! */
-};
-
 #define __EXEC_OBJECT_HAS_PIN  BIT(31)
 #define __EXEC_OBJECT_HAS_FENCEBIT(30)
 #define __EXEC_OBJECT_NEEDS_MAPBIT(29)
@@ -260,8 +253,6 @@ struct i915_execbuffer {
 */
struct reloc_cache {
struct drm_mm_node node; /** temporary GTT binding */
-   unsigned long vaddr; /** Current kmap address */
-   unsigned long page; /** Currently mapped page index */
unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
bool has_llc : 1;
@@ -605,23 +596,6 @@ eb_add_vma(struct i915_execbuffer *eb,
}
 }
 
-static inline int use_cpu_reloc(const struct reloc_cache *cache,
-   const struct drm_i915_gem_object *obj)
-{
-   if (!i915_gem_object_has_struct_page(obj))
-   return false;
-
-   if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
-   return true;
-
-   if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
-   return false;
-
-   return (cache->has_llc ||
-   obj->cache_dirty ||
-   obj->cache_level != I915_CACHE_NONE);
-}
-
 static int eb_reserve_vma(const struct i915_execbuffer *eb,
  struct eb_vma *ev,
  u64 pin_flags)
@@ -945,8 +919,6 @@ relocation_target(const struct 
drm_i915_gem_relocation_entry *reloc,
 static void reloc_cache_init(struct reloc_cache *cache,
 struct drm_i915_private *i915)
 {
-   cache->page = -1;
-   cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
@@ -1089,181 +1061,6 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
return err;
 }
 
-static void reloc_cache_reset(struct reloc_cache *cache)
-{
-   void *vaddr;
-
-   if (!cache->vaddr)
-   return;
-
-   vaddr = unmask_page(cache->vaddr);
-   if (cache->vaddr & KMAP) {
-   if (cache->vaddr & CLFLUSH_AFTER)
-   mb();
-
-   kunmap_atomic(vaddr);
-   i915_gem_object_finish_access((struct drm_i915_gem_object 
*)cache->node.mm);
-   } else {
-   struct i915_ggtt *ggtt = cache_to_ggtt(cache);
-
-   intel_gt_flush_ggtt_writes(ggtt->vm.gt);
-   io_mapping_unmap_atomic((void __iomem *)vaddr);
-
-   if (drm_mm_node_allocated(&cache->node)) {
-   ggtt->vm.clear_range(&ggtt->vm,
-cache->node.start,
-cache->node.size);
-   mutex_lock(&ggtt->vm.mutex);
-   drm_mm_remove_node(&cache->node);
-   mutex_unlock(&ggtt->vm.mutex);
-   } else {
-   i915_vma_unpin((struct i915_vma *)cache->node.mm);
-   }
-   }
-
-   cache->vaddr = 0;
-   cache->page = -1;
-}
-
-static void *reloc_kmap(struct drm_i915_gem_object *obj,
-   struct reloc_cache *cache,
-   unsigned long page)
-{
-   void *vaddr;
-
-   i

[Intel-gfx] [PATCH 21/36] drm/i915/gem: Build the reloc request first

2020-06-01 Thread Chris Wilson
If we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid future batches. If we build the relocation request
packet first, we can always emit as far as we get up in the relocation
chain.

Fixes: 0e97fbb08055 ("drm/i915/gem: Use a single chained reloc batches for a 
single execbuf")
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 51 ++-
 .../i915/gem/selftests/i915_gem_execbuffer.c  |  8 +--
 2 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9537fd87e3a4..c48950d7f1c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1021,11 +1021,27 @@ static unsigned int reloc_bb_flags(const struct 
reloc_cache *cache)
return cache->gen > 5 ? 0 : I915_DISPATCH_SECURE;
 }
 
-static int reloc_gpu_flush(struct reloc_cache *cache)
+static int reloc_gpu_emit(struct reloc_cache *cache)
 {
struct i915_request *rq = cache->rq;
int err;
 
+   err = 0;
+   if (rq->engine->emit_init_breadcrumb)
+   err = rq->engine->emit_init_breadcrumb(rq);
+   if (!err)
+   err = rq->engine->emit_bb_start(rq,
+   rq->batch->node.start,
+   PAGE_SIZE,
+   reloc_bb_flags(cache));
+
+   return err;
+}
+
+static void reloc_gpu_flush(struct reloc_cache *cache)
+{
+   struct i915_request *rq = cache->rq;
+
if (cache->rq_vma) {
struct drm_i915_gem_object *obj = cache->rq_vma->obj;
 
@@ -1037,21 +1053,8 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
i915_gem_object_unpin_map(obj);
}
 
-   err = 0;
-   if (rq->engine->emit_init_breadcrumb)
-   err = rq->engine->emit_init_breadcrumb(rq);
-   if (!err)
-   err = rq->engine->emit_bb_start(rq,
-   rq->batch->node.start,
-   PAGE_SIZE,
-   reloc_bb_flags(cache));
-   if (err)
-   i915_request_set_error_once(rq, err);
-
intel_gt_chipset_flush(rq->engine->gt);
i915_request_add(rq);
-
-   return err;
 }
 
 static int reloc_move_to_gpu(struct i915_request *rq, struct i915_vma *vma)
@@ -1139,7 +1142,7 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct 
intel_engine_cs *engine)
err = i915_vma_move_to_active(batch, rq, 0);
i915_vma_unlock(batch);
if (err)
-   goto skip_request;
+   goto err_request;
 
rq->batch = batch;
i915_vma_unpin(batch);
@@ -1152,8 +1155,6 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct 
intel_engine_cs *engine)
/* Return with batch mapping (cmd) still pinned */
goto out_pool;
 
-skip_request:
-   i915_request_set_error_once(rq, err);
 err_request:
i915_request_add(rq);
 err_unpin:
@@ -1186,10 +1187,8 @@ static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
if (unlikely(cache->rq_size + len >
 PAGE_SIZE / sizeof(u32) - RELOC_TAIL)) {
err = reloc_gpu_chain(cache);
-   if (unlikely(err)) {
-   i915_request_set_error_once(cache->rq, err);
+   if (unlikely(err))
return ERR_PTR(err);
-   }
}
 
GEM_BUG_ON(cache->rq_size + len >= PAGE_SIZE  / sizeof(u32));
@@ -1571,23 +1570,25 @@ static int reloc_gpu_alloc(struct i915_execbuffer *eb)
 static int reloc_gpu(struct i915_execbuffer *eb)
 {
struct eb_vma *ev;
-   int flush, err;
+   int err;
 
err = reloc_gpu_alloc(eb);
if (err)
return err;
GEM_BUG_ON(!eb->reloc_cache.rq);
 
+   err = reloc_gpu_emit(&eb->reloc_cache);
+   if (err)
+   goto out;
+
list_for_each_entry(ev, &eb->relocs, reloc_link) {
err = eb_relocate_vma(eb, ev);
if (err)
-   goto out;
+   break;
}
 
 out:
-   flush = reloc_gpu_flush(&eb->reloc_cache);
-   if (!err)
-   err = flush;
+   reloc_gpu_flush(&eb->reloc_cache);
return err;
 }
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
index 50fe22d87ae1..faed6480a792 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
@@ -

[Intel-gfx] [PATCH 25/36] drm/i915/gem: Make relocations atomic within execbuf

2020-06-01 Thread Chris Wilson
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its own relocations. We must order the relocations
and their batch such that they are an atomic pair on the GPU, and that
the ioctl itself appears atomic to userspace. The order of execution may
be undetermined, but it will not be subverted.

We could do this by moving the relocations into the main request, if it
were not for the situation where we need a second engine to perform the
relocations for us. Instead, we use the dependency tracking to only
publish the write fence on the main request and not on the relocation
request, so that concurrent updates are queued after the batch has
consumed its relocations.

Testcase: igt/gem_exec_reloc/basic-concurrent
Fixes: ef398881d27d ("drm/i915/gem: Limit struct_mutex to eb_reserve")
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 92 ++-
 .../i915/gem/selftests/i915_gem_execbuffer.c  | 11 ++-
 2 files changed, 73 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 37855ae8f8b3..2844274c37bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -259,6 +260,8 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
 
+   struct dma_fence *fence;
+
struct i915_request *rq;
struct i915_vma *rq_vma;
u32 *rq_cmd;
@@ -555,16 +558,6 @@ eb_add_vma(struct i915_execbuffer *eb,
ev->exec = entry;
ev->flags = entry->flags;
 
-   if (eb->lut_size > 0) {
-   ev->handle = entry->handle;
-   hlist_add_head(&ev->node,
-  &eb->buckets[hash_32(entry->handle,
-   eb->lut_size)]);
-   }
-
-   if (entry->relocation_count)
-   list_add_tail(&ev->reloc_link, &eb->relocs);
-
/*
 * SNA is doing fancy tricks with compressing batch buffers, which leads
 * to negative relocation deltas. Usually that works out ok since the
@@ -581,9 +574,21 @@ eb_add_vma(struct i915_execbuffer *eb,
if (eb->reloc_cache.has_fence)
ev->flags |= EXEC_OBJECT_NEEDS_FENCE;
 
+   INIT_LIST_HEAD(&ev->reloc_link);
+
eb->batch = ev;
}
 
+   if (entry->relocation_count)
+   list_add_tail(&ev->reloc_link, &eb->relocs);
+
+   if (eb->lut_size > 0) {
+   ev->handle = entry->handle;
+   hlist_add_head(&ev->node,
+  &eb->buckets[hash_32(entry->handle,
+   eb->lut_size)]);
+   }
+
if (eb_pin_vma(eb, entry, ev)) {
if (entry->offset != vma->node.start) {
entry->offset = vma->node.start | UPDATE;
@@ -923,6 +928,7 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
+   cache->fence = NULL;
 }
 
 static inline void *unmask_page(unsigned long p)
@@ -1052,6 +1058,7 @@ static void reloc_gpu_flush(struct reloc_cache *cache)
}
 
intel_gt_chipset_flush(rq->engine->gt);
+   i915_request_get(rq);
i915_request_add(rq);
 }
 
@@ -1284,16 +1291,6 @@ eb_relocate_entry(struct i915_execbuffer *eb,
if (gen8_canonical_addr(target->vma->node.start) == 
reloc->presumed_offset)
return 0;
 
-   /*
-* If we write into the object, we need to force the synchronisation
-* barrier, either with an asynchronous clflush or if we executed the
-* patching using the GPU (though that should be serialised by the
-* timeline). To be completely sure, and since we are required to
-* do relocations we are already stalling, disable the user's opt
-* out of our synchronisation.
-*/
-   ev->flags &= ~EXEC_OBJECT_ASYNC;
-
/* and update the user's relocation entry */
return relocate_entry(eb, ev->vma, reloc, target->vma);
 }
@@ -1527,6 +1524,11 @@ static int reloc_move_to_gpu(struct reloc_cache *cache, 
struct eb_vma *ev)
 
obj->write_domain = I915_GEM_DOMAIN_RENDER;
obj->read_domains = I915_GEM_DOMAIN_RENDER;
+   ev->flags |= EXEC_OBJECT_ASYNC;
+
+   err = dma_resv_reserve_shared(vma->resv, 1);
+   if (err)
+   return err;
 
err = i915_request_await_object(rq, ob

[Intel-gfx] [PATCH 16/36] drm/i915/gem: Mark the buffer pool as active for the cmdparser

2020-06-01 Thread Chris Wilson
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer pool itself. The result was that an interrupted execbuf could
still have run the cmdparser pipeline, but since the buffer pool was
idle, its target vma could have been recycled.

Note this problem only occurs if the cmdparser is running async due to
pipelined waits on busy fences, and the execbuf is interrupted.

Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser")
Fixes: 16e87459673a ("drm/i915/gt: Move the batch buffer pool from the engine 
to the gt")
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 56 ---
 1 file changed, 48 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 219a36995b96..0829ac8a55bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1987,6 +1987,38 @@ static const struct dma_fence_work_ops eb_parse_ops = {
.release = __eb_parse_release,
 };
 
+static inline int
+__parser_mark_active(struct i915_vma *vma,
+struct intel_timeline *tl,
+struct dma_fence *fence)
+{
+   struct intel_gt_buffer_pool_node *node = vma->private;
+
+   return i915_active_ref(&node->active, tl, fence);
+}
+
+static int
+parser_mark_active(struct eb_parse_work *pw, struct intel_timeline *tl)
+{
+   int err;
+
+   mutex_lock(&tl->mutex);
+
+   err = __parser_mark_active(pw->shadow, tl, &pw->base.dma);
+   if (err)
+   goto unlock;
+
+   if (pw->trampoline) {
+   err = __parser_mark_active(pw->trampoline, tl, &pw->base.dma);
+   if (err)
+   goto unlock;
+   }
+
+unlock:
+   mutex_unlock(&tl->mutex);
+   return err;
+}
+
 static int eb_parse_pipeline(struct i915_execbuffer *eb,
 struct i915_vma *shadow,
 struct i915_vma *trampoline)
@@ -2021,20 +2053,25 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
pw->shadow = shadow;
pw->trampoline = trampoline;
 
+   /* Mark active refs for this worker, in case we get interrupted */
+   err = parser_mark_active(pw, eb->context->timeline);
+   if (err)
+   goto err_commit;
+
err = dma_resv_lock_interruptible(pw->batch->resv, NULL);
if (err)
-   goto err_trampoline;
+   goto err_commit;
 
err = dma_resv_reserve_shared(pw->batch->resv, 1);
if (err)
-   goto err_batch_unlock;
+   goto err_commit_unlock;
 
/* Wait for all writes (and relocs) into the batch to complete */
err = i915_sw_fence_await_reservation(&pw->base.chain,
  pw->batch->resv, NULL, false,
  0, I915_FENCE_GFP);
if (err < 0)
-   goto err_batch_unlock;
+   goto err_commit_unlock;
 
/* Keep the batch alive and unwritten as we parse */
dma_resv_add_shared_fence(pw->batch->resv, &pw->base.dma);
@@ -2049,11 +2086,13 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_fence_work_commit_imm(&pw->base);
return 0;
 
-err_batch_unlock:
+err_commit_unlock:
dma_resv_unlock(pw->batch->resv);
-err_trampoline:
-   if (trampoline)
-   i915_active_release(&trampoline->active);
+err_commit:
+   i915_sw_fence_set_error_once(&pw->base.chain, err);
+   dma_fence_work_commit_imm(&pw->base);
+   return err;
+
 err_shadow:
i915_active_release(&shadow->active);
 err_batch:
@@ -2099,6 +2138,7 @@ static int eb_parse(struct i915_execbuffer *eb)
goto err;
}
i915_gem_object_set_readonly(shadow->obj);
+   shadow->private = pool;
 
trampoline = NULL;
if (CMDPARSER_USES_GGTT(eb->i915)) {
@@ -2112,6 +2152,7 @@ static int eb_parse(struct i915_execbuffer *eb)
shadow = trampoline;
goto err_shadow;
}
+   shadow->private = pool;
 
eb->batch_flags |= I915_DISPATCH_SECURE;
}
@@ -2128,7 +2169,6 @@ static int eb_parse(struct i915_execbuffer *eb)
eb->trampoline = trampoline;
eb->batch_start_offset = 0;
 
-   shadow->private = pool;
return 0;
 
 err_trampoline:
-- 
2.20.1

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


[Intel-gfx] [PATCH 05/36] Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"

2020-06-01 Thread Chris Wilson
This was removed in commit 478ffad6d690 ("drm/i915: drop
engine_pin/unpin_breadcrumbs_irq") as the last user had been removed,
but now there is a promise of a new user in the next patch.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 22 +
 drivers/gpu/drm/i915/gt/intel_engine.h  |  3 +++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d907d538176e..03c14ab86d95 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,6 +220,28 @@ static void signal_irq_work(struct irq_work *work)
}
 }
 
+void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+   spin_lock_irq(&b->irq_lock);
+   if (!b->irq_enabled++)
+   irq_enable(engine);
+   GEM_BUG_ON(!b->irq_enabled); /* no overflow! */
+   spin_unlock_irq(&b->irq_lock);
+}
+
+void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+   spin_lock_irq(&b->irq_lock);
+   GEM_BUG_ON(!b->irq_enabled); /* no underflow! */
+   if (!--b->irq_enabled)
+   irq_disable(engine);
+   spin_unlock_irq(&b->irq_lock);
+}
+
 static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
struct intel_engine_cs *engine =
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 791897f8d847..043462b6ce1f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -226,6 +226,9 @@ void intel_engine_init_execlists(struct intel_engine_cs 
*engine);
 void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
 
+void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine);
+void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine);
+
 void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
 
 static inline void
-- 
2.20.1

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


[Intel-gfx] [PATCH 27/36] drm/i915/gem: Teach execbuf how to wait on future syncobj

2020-06-01 Thread Chris Wilson
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.

Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 20 +--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2844274c37bb..4fddbe34efa6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2490,8 +2490,24 @@ await_fence_array(struct i915_execbuffer *eb,
continue;
 
fence = drm_syncobj_fence_get(syncobj);
-   if (!fence)
-   return -EINVAL;
+   if (!fence) {
+   struct dma_fence *old;
+
+   fence = dma_fence_create_proxy();
+   if (!fence)
+   return -ENOMEM;
+
+   spin_lock(&syncobj->lock);
+   old = rcu_dereference_protected(syncobj->fence, true);
+   if (unlikely(old)) {
+   dma_fence_put(fence);
+   fence = dma_fence_get(old);
+   } else {
+   rcu_assign_pointer(syncobj->fence,
+  dma_fence_get(fence));
+   }
+   spin_unlock(&syncobj->lock);
+   }
 
err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
-- 
2.20.1

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


[Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler

2020-06-01 Thread Chris Wilson
Ever noticed that our interrupt handlers are where we spend most of our
time on a busy system? In part this is unavoidable as each interrupt
requires to poll and reset several registers, but we can try and so as
efficiently as possible.

Function old new   delta
ilk_irq_handler 23172156-161

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_irq.c | 59 -
 1 file changed, 28 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 63579ab71cf6..07c0c7ea3795 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2097,69 +2097,66 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
  */
 static irqreturn_t ilk_irq_handler(int irq, void *arg)
 {
-   struct drm_i915_private *dev_priv = arg;
+   struct drm_i915_private *i915 = arg;
+   void __iomem * const regs = i915->uncore.regs;
u32 de_iir, gt_iir, de_ier, sde_ier = 0;
-   irqreturn_t ret = IRQ_NONE;
 
-   if (!intel_irqs_enabled(dev_priv))
+   if (!unlikely(intel_irqs_enabled(i915)))
return IRQ_NONE;
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   disable_rpm_wakeref_asserts(&i915->runtime_pm);
 
/* disable master interrupt before clearing iir  */
-   de_ier = I915_READ(DEIER);
-   I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
+   de_ier = raw_reg_read(regs, DEIER);
+   raw_reg_write(regs, DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
 
/* Disable south interrupts. We'll only write to SDEIIR once, so further
 * interrupts will will be stored on its back queue, and then we'll be
 * able to process them after we restore SDEIER (as soon as we restore
 * it, we'll get an interrupt if SDEIIR still has something to process
 * due to its back queue). */
-   if (!HAS_PCH_NOP(dev_priv)) {
-   sde_ier = I915_READ(SDEIER);
-   I915_WRITE(SDEIER, 0);
+   if (!HAS_PCH_NOP(i915)) {
+   sde_ier = raw_reg_read(regs, SDEIER);
+   raw_reg_write(regs, SDEIER, 0);
}
 
/* Find, clear, then process each source of interrupt */
 
-   gt_iir = I915_READ(GTIIR);
+   gt_iir = raw_reg_read(regs, GTIIR);
if (gt_iir) {
-   I915_WRITE(GTIIR, gt_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 6)
-   gen6_gt_irq_handler(&dev_priv->gt, gt_iir);
+   raw_reg_write(regs, GTIIR, gt_iir);
+   if (INTEL_GEN(i915) >= 6)
+   gen6_gt_irq_handler(&i915->gt, gt_iir);
else
-   gen5_gt_irq_handler(&dev_priv->gt, gt_iir);
+   gen5_gt_irq_handler(&i915->gt, gt_iir);
}
 
-   de_iir = I915_READ(DEIIR);
+   de_iir = raw_reg_read(regs, DEIIR);
if (de_iir) {
-   I915_WRITE(DEIIR, de_iir);
-   ret = IRQ_HANDLED;
-   if (INTEL_GEN(dev_priv) >= 7)
-   ivb_display_irq_handler(dev_priv, de_iir);
+   raw_reg_write(regs, DEIIR, de_iir);
+   if (INTEL_GEN(i915) >= 7)
+   ivb_display_irq_handler(i915, de_iir);
else
-   ilk_display_irq_handler(dev_priv, de_iir);
+   ilk_display_irq_handler(i915, de_iir);
}
 
-   if (INTEL_GEN(dev_priv) >= 6) {
-   u32 pm_iir = I915_READ(GEN6_PMIIR);
+   if (INTEL_GEN(i915) >= 6) {
+   u32 pm_iir = raw_reg_read(regs, GEN6_PMIIR);
if (pm_iir) {
-   I915_WRITE(GEN6_PMIIR, pm_iir);
-   ret = IRQ_HANDLED;
-   gen6_rps_irq_handler(&dev_priv->gt.rps, pm_iir);
+   raw_reg_write(regs, GEN6_PMIIR, pm_iir);
+   gen6_rps_irq_handler(&i915->gt.rps, pm_iir);
}
}
 
-   I915_WRITE(DEIER, de_ier);
-   if (!HAS_PCH_NOP(dev_priv))
-   I915_WRITE(SDEIER, sde_ier);
+   raw_reg_write(regs, DEIER, de_ier);
+   if (sde_ier)
+   raw_reg_write(regs, SDEIER, sde_ier);
 
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
-   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+   enable_rpm_wakeref_asserts(&i915->runtime_pm);
 
-   return ret;
+   return IRQ_HANDLED;
 }
 
 static void bxt_hpd_irq_handler(struct drm_i915_private *dev_priv,
-- 
2.20.1

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


[Intel-gfx] [PATCH 12/36] drm/i915/gt: Track if an engine requires forcewake w/a

2020-06-01 Thread Chris Wilson
Sometimes an engine might need to keep forcewake active while it is busy
submitting requests for a particular workaround. Track such nuisance
with engine->fw_domain.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h   | 9 +
 drivers/gpu/drm/i915/gt/intel_ring_scheduler.c | 4 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 3782e27c2945..ccdd69923793 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -313,6 +313,15 @@ struct intel_engine_cs {
u32 context_size;
u32 mmio_base;
 
+   /*
+* Some w/a require forcewake to be held (which prevents RC6) while
+* a particular engine is active. If so, we set fw_domain to which
+* domains need to be held for the duration of request activity,
+* and 0 if none.
+*/
+   unsigned int fw_domain;
+   unsigned int fw_active;
+
unsigned long context_tag;
 
struct rb_node uabi_node;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c 
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
index aaff554865b1..777cab6d9540 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -60,6 +60,8 @@ static struct i915_request *
 schedule_in(struct intel_engine_cs *engine, struct i915_request *rq)
 {
__intel_gt_pm_get(engine->gt);
+   if (!engine->fw_active++ && engine->fw_domain)
+   intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
intel_engine_context_in(engine);
return i915_request_get(rq);
 }
@@ -74,6 +76,8 @@ schedule_out(struct intel_engine_cs *engine, struct 
i915_request *rq)
 
i915_request_put(rq);
intel_engine_context_out(engine);
+   if (!--engine->fw_active && engine->fw_domain)
+   intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
 }
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 07/36] drm/i915/gt: Support creation of 'internal' rings

2020-06-01 Thread Chris Wilson
To support legacy ring buffer scheduling, we want a virtual ringbuffer
for each client. These rings are purely for holding the requests as they
are being constructed on the CPU and never accessed by the GPU, so they
should not be bound into the GGTT, and we can use plain old WB mapped
pages.

As they are not bound, we need to nerf a few assumptions that a rq->ring
is in the GGTT.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_context.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c  | 17 ++
 drivers/gpu/drm/i915/gt/intel_ring.c   | 63 ++
 drivers/gpu/drm/i915/gt/intel_ring.h   | 12 -
 drivers/gpu/drm/i915/gt/intel_ring_types.h |  2 +
 5 files changed, 57 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..fd71977c010a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -127,7 +127,7 @@ int __intel_context_do_pin(struct intel_context *ce)
goto err_active;
 
CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
+intel_ring_address(ce->ring),
 ce->ring->head, ce->ring->tail);
 
smp_mb__before_atomic(); /* flush pin before it is visible */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c8c14981eb5d..64e13c074708 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1261,7 +1261,7 @@ static int print_ring(char *buf, int sz, struct 
i915_request *rq)
 
len = scnprintf(buf, sz,
"ring:{start:%08x, hwsp:%08x, seqno:%08x, 
runtime:%llums}, ",
-   i915_ggtt_offset(rq->ring->vma),
+   intel_ring_address(rq->ring),
tl ? tl->hwsp_offset : 0,
hwsp_seqno(rq),

DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
@@ -1542,7 +1542,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
print_request(m, rq, "\t\tactive ");
 
drm_printf(m, "\t\tring->start:  0x%08x\n",
-  i915_ggtt_offset(rq->ring->vma));
+  intel_ring_address(rq->ring));
drm_printf(m, "\t\tring->head:   0x%08x\n",
   rq->ring->head);
drm_printf(m, "\t\tring->tail:   0x%08x\n",
@@ -1621,13 +1621,6 @@ ktime_t intel_engine_get_busy_time(struct 
intel_engine_cs *engine)
return total;
 }
 
-static bool match_ring(struct i915_request *rq)
-{
-   u32 ring = ENGINE_READ(rq->engine, RING_START);
-
-   return ring == i915_ggtt_offset(rq->ring->vma);
-}
-
 struct i915_request *
 intel_engine_find_active_request(struct intel_engine_cs *engine)
 {
@@ -1667,11 +1660,7 @@ intel_engine_find_active_request(struct intel_engine_cs 
*engine)
continue;
 
if (!i915_request_started(request))
-   continue;
-
-   /* More than one preemptible request may match! */
-   if (!match_ring(request))
-   continue;
+   break;
 
active = request;
break;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 8cda1b7e17ba..438637996ab5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -24,33 +24,42 @@ unsigned int intel_ring_update_space(struct intel_ring 
*ring)
 int intel_ring_pin(struct intel_ring *ring)
 {
struct i915_vma *vma = ring->vma;
-   unsigned int flags;
void *addr;
int ret;
 
if (atomic_fetch_inc(&ring->pin_count))
return 0;
 
-   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
-   flags = PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
+   if (!(ring->flags & INTEL_RING_CREATE_INTERNAL)) {
+   unsigned int pin;
 
-   if (vma->obj->stolen)
-   flags |= PIN_MAPPABLE;
-   else
-   flags |= PIN_HIGH;
+   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+   pin |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
 
-   ret = i915_ggtt_pin(vma, 0, flags);
-   if (unlikely(ret))
-   goto err_unpin;
+   if (vma->obj->stolen)
+   pin |= PIN_MAPPABLE;
+   else
+   pin |= PIN_HIGH;
 
-   if (i915_vma_is_map_and_fenceable(vma))
-   addr = (void __force *)i915_vma_pin_iomap(vma);
-   else
-   addr = i915_gem_object_pin_map(vma->obj,
-

[Intel-gfx] [PATCH 18/36] drm/i915: Add list_for_each_entry_safe_continue_reverse

2020-06-01 Thread Chris Wilson
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_utils.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 03a73d2bd50d..6ebccdd12d4c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -266,6 +266,12 @@ static inline int list_is_last_rcu(const struct list_head 
*list,
return READ_ONCE(list->next) == head;
 }
 
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+   for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member);  \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
+
 /*
  * Wait until the work is finally complete, even if it tries to postpone
  * by requeueing itself. Note, that if the worker never cancels itself,
-- 
2.20.1

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


[Intel-gfx] [PATCH 10/36] drm/i915/gt: Infrastructure for ring scheduling

2020-06-01 Thread Chris Wilson
Build a bare bones scheduler to sit on top the global legacy ringbuffer
submission. This virtual execlists scheme should be applicable to all
older platforms.

A key problem we have with the legacy ring buffer submission is that it
only allows for FIFO queuing. All clients share the global request queue
and must contend for its lock when submitting. As any client may need to
wait for external events, all clients must then wait. However, if we
stage each client into their own virtual ringbuffer with their own
timelines, we can copy the client requests into the global ringbuffer
only when they are ready, reordering the submission around stalls.
Furthermore, the ability to reorder gives us rudimentarily priority
sorting -- although without preemption support, once something is on the
GPU it stays on the GPU, and so it is still possible for a hog to delay
a high priority request (such as updating the display). However, it does
means that in keeping a short submission queue, the high priority
request will be next. This design resembles the old guc submission
scheduler, for reordering requests onto a global workqueue.

The implementation uses the MI_USER_INTERRUPT at the end of every
request to track completion, so is more interrupt happy than execlists
[which has an interrupt for each context event, albeit two]. Our
interrupts on these system are relatively heavy, and in the past we have
been able to completely starve Sandybrige by the interrupt traffic. Our
interrupt handlers are being much better (in part offloading the work to
bottom halves leaving the interrupt itself only dealing with acking the
registers) but we can still see the impact of starvation in the uneven
submission latency on a saturated system.

Overall though, the short sumission queues and extra interrupts do not
appear to be affecting throughput (+-10%, some tasks even improve to the
reduced request overheads) and improve latency. [Which is a massive
improvement since the introduction of Sandybridge!]

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h|   1 +
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   1 +
 .../gpu/drm/i915/gt/intel_ring_scheduler.c| 760 ++
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  13 +-
 .../gpu/drm/i915/gt/intel_ring_submission.h   |  16 +
 6 files changed, 786 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_ring_submission.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 41a27fd5dbc7..6d98a74da41e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -109,6 +109,7 @@ gt-y += \
gt/intel_renderstate.o \
gt/intel_reset.o \
gt/intel_ring.o \
+   gt/intel_ring_scheduler.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
gt/intel_sseu.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 043462b6ce1f..08176117757e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -209,6 +209,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs 
*engine);
 int intel_engine_resume(struct intel_engine_cs *engine);
 
 int intel_ring_submission_setup(struct intel_engine_cs *engine);
+int intel_ring_scheduler_setup(struct intel_engine_cs *engine);
 
 int intel_engine_stop_cs(struct intel_engine_cs *engine);
 void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 2b6cdf47d428..3782e27c2945 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -348,6 +348,7 @@ struct intel_engine_cs {
struct {
struct intel_ring *ring;
struct intel_timeline *timeline;
+   struct intel_context *context;
} legacy;
 
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c 
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
new file mode 100644
index ..c8cd435d1c51
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -0,0 +1,760 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "i915_drv.h"
+#include "intel_context.h"
+#include "intel_gt.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "intel_reset.h"
+#include "intel_ring.h"
+#include "intel_ring_submission.h"
+#include "shmem_utils.h"
+
+/*
+ * Rough estimate of the typical request size, performing a flush,
+ * set-context and then emitting the batch.
+ */
+#define LEGACY_REQUEST_SIZE 200
+
+static inline int rq_prio(const struct i915_request *rq)
+{
+   return rq->sched.attr.priority;
+}
+
+static inline struct i91

[Intel-gfx] [PATCH 33/36] drm/i915: Export a preallocate variant of i915_active_acquire()

2020-06-01 Thread Chris Wilson
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_active.c | 107 ++---
 drivers/gpu/drm/i915/i915_active.h |   5 ++
 2 files changed, 103 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..71ad0d452680 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -217,11 +217,10 @@ excl_retire(struct dma_fence *fence, struct dma_fence_cb 
*cb)
 }
 
 static struct i915_active_fence *
-active_instance(struct i915_active *ref, struct intel_timeline *tl)
+active_instance(struct i915_active *ref, u64 idx)
 {
struct active_node *node, *prealloc;
struct rb_node **p, *parent;
-   u64 idx = tl->fence_context;
 
/*
 * We track the most recently used timeline to skip a rbtree search
@@ -367,7 +366,7 @@ int i915_active_ref(struct i915_active *ref,
if (err)
return err;
 
-   active = active_instance(ref, tl);
+   active = active_instance(ref, tl->fence_context);
if (!active) {
err = -ENOMEM;
goto out;
@@ -384,32 +383,104 @@ int i915_active_ref(struct i915_active *ref,
atomic_dec(&ref->count);
}
if (!__i915_active_fence_set(active, fence))
-   atomic_inc(&ref->count);
+   __i915_active_acquire(ref);
 
 out:
i915_active_release(ref);
return err;
 }
 
-struct dma_fence *
-i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+static struct dma_fence *
+__i915_active_set_fence(struct i915_active *ref,
+   struct i915_active_fence *active,
+   struct dma_fence *fence)
 {
struct dma_fence *prev;
 
/* We expect the caller to manage the exclusive timeline ordering */
GEM_BUG_ON(i915_active_is_idle(ref));
 
+   if (is_barrier(active)) { /* proto-node used by our idle barrier */
+   /*
+* This request is on the kernel_context timeline, and so
+* we can use it to substitute for the pending idle-barrer
+* request that we want to emit on the kernel_context.
+*/
+   __active_del_barrier(ref, node_from_active(active));
+   RCU_INIT_POINTER(active->fence, NULL);
+   atomic_dec(&ref->count);
+   }
+
rcu_read_lock();
-   prev = __i915_active_fence_set(&ref->excl, f);
+   prev = __i915_active_fence_set(active, fence);
if (prev)
prev = dma_fence_get_rcu(prev);
else
-   atomic_inc(&ref->count);
+   __i915_active_acquire(ref);
rcu_read_unlock();
 
return prev;
 }
 
+static struct i915_active_fence *
+__active_lookup(struct i915_active *ref, u64 idx)
+{
+   struct active_node *node;
+   struct rb_node *p;
+
+   /* Like active_instance() but with no malloc */
+
+   node = READ_ONCE(ref->cache);
+   if (node && node->timeline == idx)
+   return &node->base;
+
+   spin_lock_irq(&ref->tree_lock);
+   GEM_BUG_ON(i915_active_is_idle(ref));
+
+   p = ref->tree.rb_node;
+   while (p) {
+   node = rb_entry(p, struct active_node, node);
+   if (node->timeline == idx) {
+   ref->cache = node;
+   spin_unlock_irq(&ref->tree_lock);
+   return &node->base;
+   }
+
+   if (node->timeline < idx)
+   p = p->rb_right;
+   else
+   p = p->rb_left;
+   }
+
+   spin_unlock_irq(&ref->tree_lock);
+
+   return NULL;
+}
+
+struct dma_fence *
+__i915_active_ref(struct i915_active *ref, u64 idx, struct dma_fence *fence)
+{
+   struct dma_fence *prev = ERR_PTR(-ENOENT);
+   struct i915_active_fence *active;
+
+   if (!i915_active_acquire_if_busy(ref))
+   return ERR_PTR(-EINVAL);
+
+   active = __active_lookup(ref, idx);
+   if (active)
+   prev = __i915_active_set_fence(ref, active, fence);
+
+   i915_active_release(ref);
+   return prev;
+}
+
+struct dma_fence *
+i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+{
+   /* We expect the caller to manage the exclusive timeline ordering */
+   return __i915_active_set_fence(ref, &ref->excl, f);
+}
+
 bool i915_active_acquire_if_busy(struct i915_active *ref)
 {
debug_active_assert(ref);
@@ -443,6 +514,24 @@ int i915_active_acquire(struct i915_active *ref)
return err;
 }
 
+int i915_active_acquire_for_context(struct

[Intel-gfx] [PATCH 08/36] drm/i915/gt: Use client timeline address for seqno writes

2020-06-01 Thread Chris Wilson
If we allow for per-client timelines, even with legacy ring submission,
we open the door to a world full of possiblities [scheduling and
semaphores].

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index ce38d1bcaba3..fa11174bb13b 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -373,11 +373,10 @@ u32 *gen7_emit_breadcrumb_rcs(struct i915_request *rq, 
u32 *cs)
 
 u32 *gen6_emit_breadcrumb_xcs(struct i915_request *rq, u32 *cs)
 {
-   GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
rq->engine->status_page.vma);
-   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);
+   u32 addr = i915_request_active_timeline(rq)->hwsp_offset;
 
-   *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
-   *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
+   *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+   *cs++ = addr | MI_FLUSH_DW_USE_GTT;
*cs++ = rq->fence.seqno;
 
*cs++ = MI_USER_INTERRUPT;
@@ -391,19 +390,17 @@ u32 *gen6_emit_breadcrumb_xcs(struct i915_request *rq, 
u32 *cs)
 #define GEN7_XCS_WA 32
 u32 *gen7_emit_breadcrumb_xcs(struct i915_request *rq, u32 *cs)
 {
+   u32 addr = i915_request_active_timeline(rq)->hwsp_offset;
int i;
 
-   GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
rq->engine->status_page.vma);
-   
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);
-
-   *cs++ = MI_FLUSH_DW | MI_INVALIDATE_TLB |
-   MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
-   *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
+   *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+   *cs++ = addr | MI_FLUSH_DW_USE_GTT;
*cs++ = rq->fence.seqno;
 
for (i = 0; i < GEN7_XCS_WA; i++) {
-   *cs++ = MI_STORE_DWORD_INDEX;
-   *cs++ = I915_GEM_HWS_SEQNO_ADDR;
+   *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+   *cs++ = 0;
+   *cs++ = addr;
*cs++ = rq->fence.seqno;
}
 
-- 
2.20.1

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


  1   2   >