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

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Implement Wa_1604555607
URL   : https://patchwork.freedesktop.org/series/70134/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15481


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][1] ([fdo#112261]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][11] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][12] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15481/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (52 -> 45)
--

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


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7434 -> Patchwork_15481

  CI-20190529: 20190529
  CI_DRM_7434: 1bbc4d30ca9fd950cbcb73f324e00d0bc357758e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5312: 851c75531043cd906e028632b64b02b9312e9945 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15481: f48683f02ed4535aceb6565f477d2dc08479ce8f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f48683f02ed4 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-27 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/5] drm/i915/psr: Add bits per pixel 
limitation
URL   : https://patchwork.freedesktop.org/series/70133/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15480


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][1] -> [FAIL][2] ([fdo#109635 ] / [fdo#110387])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][3] -> [FAIL][4] ([fdo#103167])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-kbl-x1275:   [PASS][5] -> [DMESG-WARN][6] ([fdo#103558] / 
[fdo#105602])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_setm...@basic-clone-single-crtc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-x1275/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][11] ([fdo#112147]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][17] ([fdo#112261]) -> [FAIL][18] 
([fdo#108511])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][20] ([fdo#103558] / [fdo#105602]) +6 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][22] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +7 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15480/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103558]: 

Re: [Intel-gfx] [RFC 02/13] drm/i915/svm: Define SVM UAPI

2019-11-27 Thread Niranjan Vishwanathapura

On Tue, Nov 26, 2019 at 03:44:26PM +0200, Joonas Lahtinen wrote:

Quoting Niranjana Vishwanathapura (2019-11-22 22:57:23)

Define UAPI for Shared Virtual Memory (SVM) fucntionality including
SVM capability and configurability.
When there is no GPU page fault support available, add ioctls
to explicitly bind and migrate virtual address ranges.

Cc: Joonas Lahtinen 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Sudeep Dutt 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Venkata Sandeep Dhanalakota 


Having this as a separate commit ahead of the functionality breaks
bisecting.

The uAPI should be exposed in similar sized chunks as it's implemented.
If it has to go in as single patch, that should be after all the
plumbing is already in place.

That also gives a clear indication to anybody backporting that you
need to backport until the uAPI patch.



Ok, will include ioctls in the relavant patches instead of this separate patch.

Thanks,
Niranjana


Regards, Joonas

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

[Intel-gfx] [PATCH v6] drm/i915/tgl: Implement Wa_1604555607

2019-11-27 Thread Ramalingam C
From: Michel Thierry 

Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
FF_MODE2 is part of the register state context, that's why it is
implemented here.

At TGL A0 stepping, FF_MODE2 register read back is broken, hence
disabling the WA verification.

v2: Rebased on top of the WA refactoring (Oscar)
v3: Correctly add to ctx_workarounds_init (Michel)
v4:
  uncore read is used [Tvrtko]
  Macros as used for MASK definition [Chris]
v5:
  Skip the Wa_1604555607 verification [Ram]
  i915 ptr retrieved from engine. [Tvrtko]
v6:
  Added wa_add as a wrapper for __wa_add [Chris]
  wa_add is directly called instead of new wrapper [tvrtko]

BSpec: 19363
HSDES: 1604555607
Signed-off-by: Michel Thierry 
Signed-off-by: Ramalingam C 
Reviewed-by: Tvrtko Ursulin  [v5]
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 29 ++---
 drivers/gpu/drm/i915/i915_reg.h |  4 +++
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 399acae2f33f..722973e09186 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -146,20 +146,26 @@ static void _wa_add(struct i915_wa_list *wal, const 
struct i915_wa *wa)
}
 }
 
-static void
-wa_write_masked_or(struct i915_wa_list *wal, i915_reg_t reg, u32 mask,
-  u32 val)
+static void wa_add(struct i915_wa_list *wal, i915_reg_t reg, u32 mask,
+  u32 val, u32 read_mask)
 {
struct i915_wa wa = {
.reg  = reg,
.mask = mask,
.val  = val,
-   .read = mask,
+   .read = read_mask,
};
 
_wa_add(wal, );
 }
 
+static void
+wa_write_masked_or(struct i915_wa_list *wal, i915_reg_t reg, u32 mask,
+  u32 val)
+{
+   wa_add(wal, reg, mask, val, mask);
+}
+
 static void
 wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
 {
@@ -568,9 +574,24 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
 static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
 struct i915_wa_list *wal)
 {
+   u32 val;
+
/* Wa_1409142259:tgl */
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
  GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
+
+   /* Wa_1604555607:tgl */
+   val = intel_uncore_read(engine->uncore, FF_MODE2);
+   val &= ~FF_MODE2_TDS_TIMER_MASK;
+   val |= FF_MODE2_TDS_TIMER_128;
+   /*
+* FIXME: FF_MODE2 register is not readable till TGL B0. We can
+* enable verification of WA from the later steppings, which enables
+* the read of FF_MODE2.
+*/
+   wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
+  IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
+   FF_MODE2_TDS_TIMER_MASK);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 94d0f593eeb7..a99fdf8ea53b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7922,6 +7922,10 @@ enum {
 #define   PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
 #define   PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
 
+#define FF_MODE2   _MMIO(0x6604)
+#define   FF_MODE2_TDS_TIMER_MASK  REG_GENMASK(23, 16)
+#define   FF_MODE2_TDS_TIMER_128   REG_FIELD_PREP(FF_MODE2_TDS_TIMER_MASK, 
4)
+
 /* PCH */
 
 #define PCH_DISPLAY_BASE   0xcu
-- 
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 series starting with [v2,1/5] drm/i915/psr: Add bits per pixel limitation (rev3)

2019-11-27 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/5] drm/i915/psr: Add bits per pixel 
limitation (rev3)
URL   : https://patchwork.freedesktop.org/series/70002/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15479


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][9] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][10] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-kbl-x1275:   [DMESG-WARN][11] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][12] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602]) +6 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15479/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
  [fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298


Participating hosts (52 -> 45)
--

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


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7434 -> Patchwork_15479

  CI-20190529: 20190529
  CI_DRM_7434: 1bbc4d30ca9fd950cbcb73f324e00d0bc357758e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5312: 851c75531043cd906e028632b64b02b9312e9945 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15479: f4a870d621348fcbb442fb925df9f01a92f19938 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f4a870d62134 drm/i915/vbt: Parse power conservation features block
64ada6bc2669 drm/i915/psr: Check if sink PSR capability changed

[Intel-gfx] [PATCH CI 1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-27 Thread José Roberto de Souza
PSR2 HW only support a limited number of bits per pixel, if mode has
more than supported PSR2 should not be enabled.

BSpec: 50422
BSpec: 7713
Cc: Gwan-gyeong Mun 
Cc: Matt Roper 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index c1d133362b76..0d84ea28bc6f 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
-   int psr_max_h = 0, psr_max_v = 0;
+   int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
 
if (!dev_priv->psr.sink_psr2_support)
return false;
@@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (INTEL_GEN(dev_priv) >= 12) {
psr_max_h = 5120;
psr_max_v = 3200;
+   max_bpp = 30;
} else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
psr_max_h = 4096;
psr_max_v = 2304;
+   max_bpp = 24;
} else if (IS_GEN(dev_priv, 9)) {
psr_max_h = 3640;
psr_max_v = 2304;
+   max_bpp = 24;
}
 
if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
@@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (crtc_state->pipe_bpp > max_bpp) {
+   DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max supported 
%d\n",
+ crtc_state->pipe_bpp, max_bpp);
+   return false;
+   }
+
/*
 * HW sends SU blocks of size four scan lines, which means the starting
 * X coordinate and Y granularity requirements will always be met. We
-- 
2.24.0

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

[Intel-gfx] [PATCH CI 4/5] drm/i915/psr: Check if sink PSR capability changed

2019-11-27 Thread José Roberto de Souza
eDP specification states that sink can have its PSR capability
changed, I have never found any panel doing that but lets add that
for completeness.
For now it is not reading back the PSR capabilities and if possible
re-enabling PSR, this will be added if a panel is found using this
feature.

v4:
Cleaning DP_PSR_CAPS_CHANGE

Reviewed-by: Matt Roper 
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index a757b6445f21..16e9ff47d519 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1437,6 +1437,29 @@ static void psr_alpm_check(struct intel_dp *intel_dp)
}
 }
 
+static void psr_capability_changed_check(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct i915_psr *psr = _priv->psr;
+   u8 val;
+   int r;
+
+   r = drm_dp_dpcd_readb(_dp->aux, DP_PSR_ESI, );
+   if (r != 1) {
+   DRM_ERROR("Error reading DP_PSR_ESI\n");
+   return;
+   }
+
+   if (val & DP_PSR_CAPS_CHANGE) {
+   intel_psr_disable_locked(intel_dp);
+   psr->sink_not_reliable = true;
+   DRM_DEBUG_KMS("Sink PSR capability changed, disabling PSR\n");
+
+   /* Clearing it */
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ESI, val);
+   }
+}
+
 void intel_psr_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1480,6 +1503,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
 
psr_alpm_check(intel_dp);
+   psr_capability_changed_check(intel_dp);
 
 exit:
mutex_unlock(>lock);
-- 
2.24.0

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

[Intel-gfx] [PATCH CI 2/5] drm/i915/psr: Refactor psr short pulse handler

2019-11-27 Thread José Roberto de Souza
eDP spec states that when sink enconters a problem that prevents it
to keep PSR running it should set PSR status to internal error and
set the reason why it happen to PSR_ERROR_STATUS but it is not how it
was implemented.
But also I don't want to change this behavior, who knows if there is
a panel out there that only set the PSR_ERROR_STATUS.

So here refactoring the code a bit to make more easy to read what was
state above as more checks will be added to this function.

v2:
returning a int instead of a bool in psr_get_status_and_error_status()

Cc: Gwan-gyeong Mun 
Cc: Matt Roper 
Reviewed-by: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 51 ++--
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 0d84ea28bc6f..1a1ac3f46bf7 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1386,11 +1386,30 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
mutex_init(_priv->psr.lock);
 }
 
+static int psr_get_status_and_error_status(struct intel_dp *intel_dp,
+  u8 *status, u8 *error_status)
+{
+   struct drm_dp_aux *aux = _dp->aux;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
+   if (ret != 1)
+   return ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS, error_status);
+   if (ret != 1)
+   return ret;
+
+   *status = *status & DP_PSR_SINK_STATE_MASK;
+
+   return 0;
+}
+
 void intel_psr_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct i915_psr *psr = _priv->psr;
-   u8 val;
+   u8 status, error_status;
const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
  DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
  DP_PSR_LINK_CRC_ERROR;
@@ -1403,38 +1422,30 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
if (!psr->enabled || psr->dp != intel_dp)
goto exit;
 
-   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
-   DRM_ERROR("PSR_STATUS dpcd read failed\n");
+   if (psr_get_status_and_error_status(intel_dp, , _status)) {
+   DRM_ERROR("Error reading PSR status or error status\n");
goto exit;
}
 
-   if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
-   DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
+   if (status == DP_PSR_SINK_INTERNAL_ERROR || (error_status & errors)) {
intel_psr_disable_locked(intel_dp);
psr->sink_not_reliable = true;
}
 
-   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
-   DRM_ERROR("PSR_ERROR_STATUS dpcd read failed\n");
-   goto exit;
-   }
-
-   if (val & DP_PSR_RFB_STORAGE_ERROR)
+   if (status == DP_PSR_SINK_INTERNAL_ERROR && !error_status)
+   DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
+   if (error_status & DP_PSR_RFB_STORAGE_ERROR)
DRM_DEBUG_KMS("PSR RFB storage error, disabling PSR\n");
-   if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
+   if (error_status & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling 
PSR\n");
-   if (val & DP_PSR_LINK_CRC_ERROR)
+   if (error_status & DP_PSR_LINK_CRC_ERROR)
DRM_DEBUG_KMS("PSR Link CRC error, disabling PSR\n");
 
-   if (val & ~errors)
+   if (error_status & ~errors)
DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
- val & ~errors);
-   if (val & errors) {
-   intel_psr_disable_locked(intel_dp);
-   psr->sink_not_reliable = true;
-   }
+ error_status & ~errors);
/* clear status register */
-   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
 exit:
mutex_unlock(>lock);
 }
-- 
2.24.0

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

[Intel-gfx] [PATCH CI 5/5] drm/i915/vbt: Parse power conservation features block

2019-11-27 Thread José Roberto de Souza
From VBT 228+ this is block that PSR and other power saving
features configuration should be read from.

v3:
Using DRRS from this new block

v4:
Using BIT()
Fixing DRRS comment in parse_power_conservation_features()

Cc: Matt Roper 
Cc: Gwan-gyeong Mun 
Reviewed-by: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 38 +--
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29 ++
 2 files changed, 63 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index f6a9a5ccb556..70e644082bec 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -659,16 +659,45 @@ parse_driver_features(struct drm_i915_private *dev_priv,
dev_priv->vbt.int_lvds_support = 0;
}
 
-   DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
+   if (bdb->version < 228) {
+   DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
+   /*
+* If DRRS is not supported, drrs_type has to be set to 0.
+* This is because, VBT is configured in such a way that
+* static DRRS is 0 and DRRS not supported is represented by
+* driver->drrs_enabled=false
+*/
+   if (!driver->drrs_enabled)
+   dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+
+   dev_priv->vbt.psr.enable = driver->psr_enabled;
+   }
+}
+
+static void
+parse_power_conservation_features(struct drm_i915_private *dev_priv,
+ const struct bdb_header *bdb)
+{
+   const struct bdb_lfp_power *power;
+   u8 panel_type = dev_priv->vbt.panel_type;
+
+   if (bdb->version < 228)
+   return;
+
+   power = find_section(bdb, BDB_LVDS_POWER);
+   if (!power)
+   return;
+
+   dev_priv->vbt.psr.enable = power->psr & BIT(panel_type);
+
/*
 * If DRRS is not supported, drrs_type has to be set to 0.
 * This is because, VBT is configured in such a way that
 * static DRRS is 0 and DRRS not supported is represented by
-* driver->drrs_enabled=false
+* power->drrs & BIT(panel_type)=false
 */
-   if (!driver->drrs_enabled)
+   if (!(power->drrs & BIT(panel_type)))
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
-   dev_priv->vbt.psr.enable = driver->psr_enabled;
 }
 
 static void
@@ -1973,6 +2002,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
parse_lfp_backlight(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_driver_features(dev_priv, bdb);
+   parse_power_conservation_features(dev_priv, bdb);
parse_edp(dev_priv, bdb);
parse_psr(dev_priv, bdb);
parse_mipi_config(dev_priv, bdb);
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index f0338da3a82a..98b71dc32d2a 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -793,6 +793,35 @@ struct bdb_lfp_backlight_data {
struct lfp_backlight_control_method backlight_control[16];
 } __packed;
 
+/*
+ * Block 44 - LFP Power Conservation Features Block
+ */
+
+struct als_data_entry {
+   u16 backlight_adjust;
+   u16 lux;
+} __packed;
+
+struct agressiveness_profile_entry {
+   u8 dpst_agressiveness : 4;
+   u8 lace_agressiveness : 4;
+} __packed;
+
+struct bdb_lfp_power {
+   u8 lfp_feature_bits;
+   struct als_data_entry als[5];
+   u8 lace_aggressiveness_profile;
+   u16 dpst;
+   u16 psr;
+   u16 drrs;
+   u16 lace_support;
+   u16 adt;
+   u16 dmrrs;
+   u16 adb;
+   u16 lace_enabled_status;
+   struct agressiveness_profile_entry aggressivenes[16];
+} __packed;
+
 /*
  * Block 52 - MIPI Configuration Block
  */
-- 
2.24.0

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

[Intel-gfx] [PATCH CI 3/5] drm/i915/psr: Enable ALPM lock timeout error interruption

2019-11-27 Thread José Roberto de Souza
When this error happens sink link is not stable after the required
FW_EXIT_LATENCY period so it will miss the selective update.
As the other PSR errors, for now we are not trying to recover from
it.

Cc: Gwan-gyeong Mun 
Reviewed-by: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 37 +++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 1a1ac3f46bf7..a757b6445f21 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -402,7 +402,9 @@ static void intel_psr_enable_sink(struct intel_dp *intel_dp)
/* Enable ALPM at sink for psr2 */
if (dev_priv->psr.psr2_enabled) {
drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
-  DP_ALPM_ENABLE);
+  DP_ALPM_ENABLE |
+  DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
+
dpcd_val |= DP_PSR_ENABLE_PSR2 | DP_PSR_IRQ_HPD_WITH_CRC_ERRORS;
} else {
if (dev_priv->psr.link_standby)
@@ -934,6 +936,9 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
 
+   if (dev_priv->psr.psr2_enabled)
+   drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG, 0);
+
dev_priv->psr.enabled = false;
 }
 
@@ -1405,6 +1410,33 @@ static int psr_get_status_and_error_status(struct 
intel_dp *intel_dp,
return 0;
 }
 
+static void psr_alpm_check(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct drm_dp_aux *aux = _dp->aux;
+   struct i915_psr *psr = _priv->psr;
+   u8 val;
+   int r;
+
+   if (!psr->psr2_enabled)
+   return;
+
+   r = drm_dp_dpcd_readb(aux, DP_RECEIVER_ALPM_STATUS, );
+   if (r != 1) {
+   DRM_ERROR("Error reading ALPM status\n");
+   return;
+   }
+
+   if (val & DP_ALPM_LOCK_TIMEOUT_ERROR) {
+   intel_psr_disable_locked(intel_dp);
+   psr->sink_not_reliable = true;
+   DRM_DEBUG_KMS("ALPM lock timeout error, disabling PSR\n");
+
+   /* Clearing error */
+   drm_dp_dpcd_writeb(aux, DP_RECEIVER_ALPM_STATUS, val);
+   }
+}
+
 void intel_psr_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1446,6 +1478,9 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
  error_status & ~errors);
/* clear status register */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
+
+   psr_alpm_check(intel_dp);
+
 exit:
mutex_unlock(>lock);
 }
-- 
2.24.0

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

Re: [Intel-gfx] [PATCH v2 00/14] drm/i915/fbc: Fix FBC for glk+

2019-11-27 Thread Daniel Drake
On Thu, Nov 28, 2019 at 4:12 AM Ville Syrjala
 wrote:
> I also slapped on an extra patch at the end which should hopefully
> avoid the problems with FBC not getting enabled with fastboot.

Retested Asus E406MA, default parameters (fastboot=1) and now FBC is
marked enabled in i915_fbc_status.
I can't reproduce the visual corruption using my original tests
(interacting with GNOME gdm login screen, frantically scrolling text
inside gnome-terminal).

Tested-by: Daniel Drake 

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

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/psr: Check if sink PSR capability changed

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 17:21 -0800, Matt Roper wrote:
> On Mon, Nov 25, 2019 at 04:53:59PM -0800, José Roberto de Souza
> wrote:
> > eDP specification states that sink can have its PSR capability
> > changed, I have never found any panel doing that but lets add that
> > for completeness.
> > For now it is not reading back the PSR capabilities and if possible
> > re-enabling PSR, this will be added if a panel is found using this
> > feature.
> 
> I'm not super familiar with PSR details, but is it required for us to
> disable PSR in this case?  From a quick skim of the spec it sounds
> like
> the sink is required to keep operating with the same capabilities
> until
> the source clears the CAPS_CHANGE bit (which we never do in the patch
> below).  What happens if we just ignore the sink's notification and
> never ack it by writing a 1 to clear the bit?

Yeah, it is not clearing DP_PSR_CAPS_CHANGE will fix that, thanks.

If we just ignore, sink is supposed to keep the current capabilities
but if wants to change it is because it has some internal problem that
is causing or will cause image corruption.


> 
> I guess disabling is still probably the safest thing to do if we're
> not
> sure and don't have any real panels to test it out with.  Should we
> still clean by clearing the bit even though we disabled PSR?
> 
> Otherwise,
> 
> Reviewed-by: Matt Roper 
> 
> 
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 21
> > +
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index a757b6445f21..ce76e1c6a0b9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1437,6 +1437,26 @@ static void psr_alpm_check(struct intel_dp
> > *intel_dp)
> > }
> >  }
> >  
> > +static void psr_capability_changed_check(struct intel_dp
> > *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   struct i915_psr *psr = _priv->psr;
> > +   u8 val;
> > +   int r;
> > +
> > +   r = drm_dp_dpcd_readb(_dp->aux, DP_PSR_ESI, );
> > +   if (r != 1) {
> > +   DRM_ERROR("Error reading DP_PSR_ESI\n");
> > +   return;
> > +   }
> > +
> > +   if (val & DP_PSR_CAPS_CHANGE) {
> > +   intel_psr_disable_locked(intel_dp);
> > +   psr->sink_not_reliable = true;
> > +   DRM_DEBUG_KMS("Sink PSR capability changed, disabling
> > PSR\n");
> > +   }
> > +}
> > +
> >  void intel_psr_short_pulse(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > @@ -1480,6 +1500,7 @@ void intel_psr_short_pulse(struct intel_dp
> > *intel_dp)
> > drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS,
> > error_status);
> >  
> > psr_alpm_check(intel_dp);
> > +   psr_capability_changed_check(intel_dp);
> >  
> >  exit:
> > mutex_unlock(>lock);
> > -- 
> > 2.24.0
> > 
> > ___
> > 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] drm/i915/display/tgl: Do not program clockgating

2019-11-27 Thread Matt Roper
On Tue, Nov 26, 2019 at 03:17:17PM -0800, José Roberto de Souza wrote:
> Talked with HW team and this is a left over, driver should not
> program clockgating, dekel firmware will be reponsible for any
> clockgating programing.
> 
> BSpec issue: 20885
> BSpec: 49292
> 
> Cc: Lucas De Marchi 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 55 +++-
>  1 file changed, 16 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a976606d21c7..7488dcbb637f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3167,6 +3167,11 @@ icl_phy_set_clock_gating(struct intel_digital_port 
> *dig_port, bool enable)
>   u32 val, bits;
>   int ln;
>  
> + /*
> +  * Should not be called for GEN12+, see "PHY Clockgating programming"
> +  * note
> +  */
> +
>   if (tc_port == PORT_TC_NONE)
>   return;
>  
> @@ -3175,39 +3180,26 @@ icl_phy_set_clock_gating(struct intel_digital_port 
> *dig_port, bool enable)
>  MG_DP_MODE_CFG_GAONPWR_GATING;
>  
>   for (ln = 0; ln < 2; ln++) {
> - if (INTEL_GEN(dev_priv) >= 12) {
> - I915_WRITE(HIP_INDEX_REG(tc_port), 
> HIP_INDEX_VAL(tc_port, ln));
> - val = I915_READ(DKL_DP_MODE(tc_port));
> - } else {
> - val = I915_READ(MG_DP_MODE(ln, tc_port));
> - }
> + val = I915_READ(MG_DP_MODE(ln, tc_port));
>  
>   if (enable)
>   val |= bits;
>   else
>   val &= ~bits;
>  
> - if (INTEL_GEN(dev_priv) >= 12)
> - I915_WRITE(DKL_DP_MODE(tc_port), val);
> - else
> - I915_WRITE(MG_DP_MODE(ln, tc_port), val);
> + I915_WRITE(MG_DP_MODE(ln, tc_port), val);
>   }
>  
> - if (INTEL_GEN(dev_priv) == 11) {
> - bits = MG_MISC_SUS0_CFG_TR2PWR_GATING |
> -MG_MISC_SUS0_CFG_CL2PWR_GATING |
> -MG_MISC_SUS0_CFG_GAONPWR_GATING |
> -MG_MISC_SUS0_CFG_TRPWR_GATING |
> -MG_MISC_SUS0_CFG_CL1PWR_GATING |
> -MG_MISC_SUS0_CFG_DGPWR_GATING;
> + bits = MG_MISC_SUS0_CFG_TR2PWR_GATING | MG_MISC_SUS0_CFG_CL2PWR_GATING |
> +MG_MISC_SUS0_CFG_GAONPWR_GATING | MG_MISC_SUS0_CFG_TRPWR_GATING |
> +MG_MISC_SUS0_CFG_CL1PWR_GATING | MG_MISC_SUS0_CFG_DGPWR_GATING;
>  
> - val = I915_READ(MG_MISC_SUS0(tc_port));
> - if (enable)
> - val |= (bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3));
> - else
> - val &= ~(bits | 
> MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK);
> - I915_WRITE(MG_MISC_SUS0(tc_port), val);
> - }
> + val = I915_READ(MG_MISC_SUS0(tc_port));
> + if (enable)
> + val |= (bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3));
> + else
> + val &= ~(bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK);
> + I915_WRITE(MG_MISC_SUS0(tc_port), val);
>  }
>  
>  static void
> @@ -3508,12 +3500,6 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder 
> *encoder,
>* down this function.
>*/
>  
> - /*
> -  * 7.d Type C with DP alternate or fixed/legacy/static connection -
> -  * Disable PHY clock gating per Type-C DDI Buffer page
> -  */
> - icl_phy_set_clock_gating(dig_port, false);
> -
>   /* 7.e Configure voltage swing and related IO settings */
>   tgl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
>   encoder->type);
> @@ -3565,15 +3551,6 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder 
> *encoder,
>   if (!is_trans_port_sync_mode(crtc_state))
>   intel_dp_stop_link_train(intel_dp);
>  
> - /*
> -  * TODO: enable clock gating
> -  *
> -  * It is not written in DP enabling sequence but "PHY Clockgating
> -  * programming" states that clock gating should be enabled after the
> -  * link training but doing so causes all the following trainings to fail
> -  * so not enabling it for now.
> -  */
> -
>   /* 7.l Configure and enable FEC if needed */
>   intel_ddi_enable_fec(encoder, crtc_state);
>   intel_dsc_enable(encoder, crtc_state);
> -- 
> 2.24.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/psr: Check if sink PSR capability changed

2019-11-27 Thread Matt Roper
On Mon, Nov 25, 2019 at 04:53:59PM -0800, José Roberto de Souza wrote:
> eDP specification states that sink can have its PSR capability
> changed, I have never found any panel doing that but lets add that
> for completeness.
> For now it is not reading back the PSR capabilities and if possible
> re-enabling PSR, this will be added if a panel is found using this
> feature.

I'm not super familiar with PSR details, but is it required for us to
disable PSR in this case?  From a quick skim of the spec it sounds like
the sink is required to keep operating with the same capabilities until
the source clears the CAPS_CHANGE bit (which we never do in the patch
below).  What happens if we just ignore the sink's notification and
never ack it by writing a 1 to clear the bit?

I guess disabling is still probably the safest thing to do if we're not
sure and don't have any real panels to test it out with.  Should we
still clean by clearing the bit even though we disabled PSR?

Otherwise,

Reviewed-by: Matt Roper 


> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a757b6445f21..ce76e1c6a0b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1437,6 +1437,26 @@ static void psr_alpm_check(struct intel_dp *intel_dp)
>   }
>  }
>  
> +static void psr_capability_changed_check(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct i915_psr *psr = _priv->psr;
> + u8 val;
> + int r;
> +
> + r = drm_dp_dpcd_readb(_dp->aux, DP_PSR_ESI, );
> + if (r != 1) {
> + DRM_ERROR("Error reading DP_PSR_ESI\n");
> + return;
> + }
> +
> + if (val & DP_PSR_CAPS_CHANGE) {
> + intel_psr_disable_locked(intel_dp);
> + psr->sink_not_reliable = true;
> + DRM_DEBUG_KMS("Sink PSR capability changed, disabling PSR\n");
> + }
> +}
> +
>  void intel_psr_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -1480,6 +1500,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
>  
>   psr_alpm_check(intel_dp);
> + psr_capability_changed_check(intel_dp);
>  
>  exit:
>   mutex_unlock(>lock);
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915/tgl: Select master trasconder for MST stream

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:59 +0200, Ville Syrjälä wrote:
> On Tue, Nov 26, 2019 at 08:30:31PM +, Souza, Jose wrote:
> > On Tue, 2019-11-26 at 22:05 +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 22, 2019 at 04:54:55PM -0800, José Roberto de Souza
> > > wrote:
> > > > On TGL the blending of all the streams have moved from DDI to
> > > > transcoder, so now every transcoder working over the same MST
> > > > port
> > > > must
> > > > send its stream to a master transcoder and master will send to
> > > > DDI
> > > > respecting the time slots.
> > > > 
> > > > A previous approach was using the lowest pipe/transcoder as
> > > > master
> > > > transcoder but as the comment in skl_commit_modeset_enables()
> > > > states,
> > > > that is not always true.
> > > > 
> > > > So here promoting the first pipe/transcoder of the stream as
> > > > master.
> > > > That caused several other problems as during the commit phase
> > > > the
> > > > state computed should not be changed.
> > > > 
> > > > So the master transcoder is store into intel_dp and the modeset
> > > > in
> > > > slave pipes/transcoders is forced using
> > > > mst_master_trans_pending.
> > > > 
> > > > v2:
> > > > - added missing config compute to trigger fullmodeset in slave
> > > > transcoders
> > > > 
> > > > BSpec: 50493
> > > > BSpec: 49190
> > > > Cc: Ville Syrjälä 
> > > > Cc: Lucas De Marchi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_ddi.c  |  10 +-
> > > >  drivers/gpu/drm/i915/display/intel_display.c  |  58 ++-
> > > >  .../drm/i915/display/intel_display_types.h|   3 +
> > > >  drivers/gpu/drm/i915/display/intel_dp.c   |   1 +
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 149
> > > > +-
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.h   |   2 +
> > > >  6 files changed, 216 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index a976606d21c7..d2f0d393d3ee 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -35,6 +35,7 @@
> > > >  #include "intel_display_types.h"
> > > >  #include "intel_dp.h"
> > > >  #include "intel_dp_link_training.h"
> > > > +#include "intel_dp_mst.h"
> > > >  #include "intel_dpio_phy.h"
> > > >  #include "intel_dsi.h"
> > > >  #include "intel_fifo_underrun.h"
> > > > @@ -1903,8 +1904,13 @@
> > > > intel_ddi_transcoder_func_reg_val_get(const
> > > > struct intel_crtc_state *crtc_state)
> > > > temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> > > > temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
> > > >  
> > > > -   if (INTEL_GEN(dev_priv) >= 12)
> > > > -   temp |=
> > > > TRANS_DDI_MST_TRANSPORT_SELECT(crtc_state->cpu_transcoder);
> > > > +   if (INTEL_GEN(dev_priv) >= 12) {
> > > > +   enum transcoder master;
> > > > +
> > > > +   master =
> > > > intel_dp_mst_master_trans_get(encoder);
> > > 
> > > Why isn't that just stored in the crtc state like everything
> > > else?
> > > 
> > > I'm thinking we should maybe do it just like port sync and have
> > > both
> > > master + slave_mask. That way it should be pretty trivial to add
> > > all
> > > the relevant crtcs to the state when needed.
> > 
> > I guess port sync is not doing the right thing and it could cause
> > underruns.
> > When it is going to enable the master CRTC of the port sync it
> > forcibly
> > enables the slave first, what could cause underruns because of
> > overlap
> > in ddb allocations(that is what I understood from the comment in
> > skl_commit_modeset_enables()).
> 
> Not necessarily just underruns but even a system hang. The fix should
> be
> a trivial "check the slave for ddb overlap as well", but apparently I
> failed at convicing people to do that.
> 
> I've actually been pondering about decoupling the plane updates from
> the crtc enable stuff entirely. At least theoretically crtc enable
> should be able to excute in any order as long we don't enable any
> new planes.
> 
> But none of that really matters for the discussion at hand. Though
> there are other problems with the port sync stuff that would need
> to be handled better. Eg. I think it now adds both crtcs to the state
> always which is going to cut the fps in half. Also the place where
> it does that stuff is rather suspicious. All that stuff should be
> somewhere a bit higher up IMO.
> 
> > So for MST we only know who is the master in the commit phase and
> > at
> > this point we should not modify the computed state.
> 
> I'm not suggesting modifying anything during commit phase. I think
> you are effectiely doing that right now by stuffing that mst master
> transcoder into intel_dp.

Sorry, I still don't get what approach are you suggesting here.

If we can't modify the state in the commit phase, 

Re: [Intel-gfx] [PATCH 4/7] drm/i915/dp: Power down sink before disable pipe/transcoder clock

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:24 +0200, Ville Syrjälä wrote:
> On Tue, Nov 26, 2019 at 10:12:52PM +, Souza, Jose wrote:
> > On Tue, 2019-11-26 at 22:15 +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 22, 2019 at 04:54:56PM -0800, José Roberto de Souza
> > > wrote:
> > > > Disabling pipe/transcoder clock before power down sink could
> > > > cause
> > > > sink lost signal, causing it to trigger a hotplug to notify
> > > > source
> > > > that link signal was lost.
> > > > 
> > > > Cc: Lucas De Marchi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index d2f0d393d3ee..7d3a6e3c7f57 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -3808,12 +3808,12 @@ static void
> > > > intel_ddi_post_disable_dp(struct intel_encoder *encoder,
> > > > enum phy phy = intel_port_to_phy(dev_priv, encoder-
> > > > >port);
> > > >  
> > > > if (!is_mst) {
> > > > -   intel_ddi_disable_pipe_clock(old_crtc_state);
> > > > /*
> > > >  * Power down sink before disabling the port,
> > > > otherwise
> > > > we end
> > > >  * up getting interrupts from the sink on
> > > > detecting
> > > > link loss.
> > > >  */
> > > > intel_dp_sink_dpms(intel_dp,
> > > > DRM_MODE_DPMS_OFF);
> > > > +   intel_ddi_disable_pipe_clock(old_crtc_state);
> > > > }
> > > 
> > > The spec seems to say that we should do this after turning off
> > > DDI_BUF_CTL on tgl+.
> > 
> > What step? I can't find any step talking about AUX DP_SET_POWER.
> 
> I was talking about DDI_BUF disable vs. transcoder clock disable.
> 
> > My understating is that we should power off sink before interfering
> > in
> > the mainlink signal otherwise sink could trigger hotplugs to notify
> > source about link loss.
> 
> Pretty much. Nothing wrong with your patch for pre-tgl I think, but
> for
> tgl+ you didn't move the clock disable quite far enough to match the
> bspec sequence.

Aaahh
That is fixed patch 6 "drm/i915/display/tgl: Fix the order of the step
to turn transcoder clock off" :D

> 
> > > >  
> > > > intel_disable_ddi_buf(encoder, old_crtc_state);
> > > > -- 
> > > > 2.24.0
> > > > 
> > > > ___
> > > > 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: failure for series starting with [CI,1/3] drm/i915/selftests: Count the number of engines used

2019-11-27 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/selftests: Count the number of 
engines used
URL   : https://patchwork.freedesktop.org/series/70131/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15478


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15478 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15478, 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_15478/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_execlists:
- fi-bxt-dsi: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-bxt-dsi/igt@i915_selftest@live_execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-bxt-dsi/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900:   [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
- fi-ivb-3770:[PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770:[PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-peppy:   [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770r:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2:  [PASS][13] -> [FAIL][14] ([fdo#109635 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][17] ([fdo#107713]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][19] ([fdo#112261]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][22] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15478/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-x1275:   [DMESG-WARN][23] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [SKIP][24] ([fdo#109271])
   [23]: 

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/psr: Enable ALPM lock timeout error interruption

2019-11-27 Thread Matt Roper
On Mon, Nov 25, 2019 at 04:53:58PM -0800, José Roberto de Souza wrote:
> When this error happens sink link is not stable after the required
> FW_EXIT_LATENCY period so it will miss the selective update.
> As the other PSR errors, for now we are not trying to recover from
> it.
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 

Seems to match what I see in the eDP 1.4 spec.

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 37 +++-
>  1 file changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 1a1ac3f46bf7..a757b6445f21 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -402,7 +402,9 @@ static void intel_psr_enable_sink(struct intel_dp 
> *intel_dp)
>   /* Enable ALPM at sink for psr2 */
>   if (dev_priv->psr.psr2_enabled) {
>   drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
> -DP_ALPM_ENABLE);
> +DP_ALPM_ENABLE |
> +DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
> +
>   dpcd_val |= DP_PSR_ENABLE_PSR2 | DP_PSR_IRQ_HPD_WITH_CRC_ERRORS;
>   } else {
>   if (dev_priv->psr.link_standby)
> @@ -934,6 +936,9 @@ static void intel_psr_disable_locked(struct intel_dp 
> *intel_dp)
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
>  
> + if (dev_priv->psr.psr2_enabled)
> + drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG, 0);
> +
>   dev_priv->psr.enabled = false;
>  }
>  
> @@ -1405,6 +1410,33 @@ static int psr_get_status_and_error_status(struct 
> intel_dp *intel_dp,
>   return 0;
>  }
>  
> +static void psr_alpm_check(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct drm_dp_aux *aux = _dp->aux;
> + struct i915_psr *psr = _priv->psr;
> + u8 val;
> + int r;
> +
> + if (!psr->psr2_enabled)
> + return;
> +
> + r = drm_dp_dpcd_readb(aux, DP_RECEIVER_ALPM_STATUS, );
> + if (r != 1) {
> + DRM_ERROR("Error reading ALPM status\n");
> + return;
> + }
> +
> + if (val & DP_ALPM_LOCK_TIMEOUT_ERROR) {
> + intel_psr_disable_locked(intel_dp);
> + psr->sink_not_reliable = true;
> + DRM_DEBUG_KMS("ALPM lock timeout error, disabling PSR\n");
> +
> + /* Clearing error */
> + drm_dp_dpcd_writeb(aux, DP_RECEIVER_ALPM_STATUS, val);
> + }
> +}
> +
>  void intel_psr_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -1446,6 +1478,9 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
> error_status & ~errors);
>   /* clear status register */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
> +
> + psr_alpm_check(intel_dp);
> +
>  exit:
>   mutex_unlock(>lock);
>  }
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: Suspend MST topology manager before destroy fbdev

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 10:43 -0800, Lucas De Marchi wrote:
> On Tue, Nov 26, 2019 at 06:16:09PM -0800, Jose Souza wrote:
> > MST do topology probe in threads, so this running threads needs to
> > be
> > flushed before fbdev is destroyed as when a new MST node is found
> > it
> > calls drm_kms_helper_hotplug_event() that calls fbdev functions
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964
> > Signed-off-by: José Roberto de Souza 
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> > 1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8f2770951459..372dd48691cf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -17989,6 +17989,13 @@ void intel_modeset_driver_remove(struct
> > drm_i915_private *i915)
> >  */
> > intel_hpd_poll_fini(i915);
> > 
> > +   /*
> > +* MST do topology probe in threads, so this running threads
> > needs to
> > +* be flushed before fbdev is destroyed as when a new MST node
> > is found
> > +* it call drm_kms_helper_hotplug_event() that calls fbdev
> > functions
> > +*/
> 
> this would normally be part of drm_mode_config_cleanup() in which the
> encoders will be destroyed, together with their mst_mgr via 
> drm_dp_mst_topology_mgr_destroy()
> 
> So I think the comment should actually mention why
> drm_mode_config_cleanup() can't be done before or just state where it
> will actually be destroyed. So... I guess something like:
> 
> /*
>   * MST topology needs to be suspended so we don't have any calls to
>   * fbdev after it's finalized. MST will be destroyed later as part
> of
>   * drm_mode_config_cleanup()
>   */
> 
> Of course, if we can figure out a better ordering to peel the onion
> would be better, but I think this is sufficient.

Sounds better, thanks.

> 
> With the comment update,
> 
> 
> Reviewed-by: Lucas De Marchi 
> 
> Lucas De Marchi
> 
> > +   intel_dp_mst_suspend(i915);
> > +
> > /* poll work can call into fbdev, hence clean that up
> > afterwards */
> > intel_fbdev_fini(i915);
> > 
> > -- 
> > 2.24.0
> > 
> > ___
> > 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 v3 5/5] drm/i915/vbt: Parse power conservation features block

2019-11-27 Thread Matt Roper
On Wed, Nov 27, 2019 at 02:54:51PM -0800, José Roberto de Souza wrote:
> From VBT 228+ this is block that PSR and other power saving
> features configuration should be read from.
> 
> v3:
> Using DRRS from this new block
> 
> Cc: Matt Roper 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 36 +--
>  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29 +++
>  2 files changed, 62 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index f6a9a5ccb556..2d06f1f5734d 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -659,16 +659,45 @@ parse_driver_features(struct drm_i915_private *dev_priv,
>   dev_priv->vbt.int_lvds_support = 0;
>   }
>  
> - DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
> + if (bdb->version < 228) {
> + DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
> + /*
> +  * If DRRS is not supported, drrs_type has to be set to 0.
> +  * This is because, VBT is configured in such a way that
> +  * static DRRS is 0 and DRRS not supported is represented by
> +  * driver->drrs_enabled=false
> +  */
> + if (!driver->drrs_enabled)
> + dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> +
> + dev_priv->vbt.psr.enable = driver->psr_enabled;
> + }
> +}
> +
> +static void
> +parse_power_conservation_features(struct drm_i915_private *dev_priv,
> +   const struct bdb_header *bdb)
> +{
> + const struct bdb_lfp_power *power;
> + u8 panel_type = dev_priv->vbt.panel_type;
> +
> + if (bdb->version < 228)
> + return;
> +
> + power = find_section(bdb, BDB_LVDS_POWER);
> + if (!power)
> + return;
> +
> + dev_priv->vbt.psr.enable = power->psr & (1 << panel_type);
> +
>   /*
>* If DRRS is not supported, drrs_type has to be set to 0.
>* This is because, VBT is configured in such a way that
>* static DRRS is 0 and DRRS not supported is represented by
>* driver->drrs_enabled=false

driver->drrs_enabled in the comment here doesn't apply to the parsing of
block 44.  You'll probably want to reword this.

While you're at it, maybe replace the "1 << panel_type"'s with
BIT(panel_type)?  Up to you.

Otherwise,
Reviewed-by: Matt Roper 

>*/
> - if (!driver->drrs_enabled)
> + if (!(power->drrs & (1 << panel_type)))
>   dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> - dev_priv->vbt.psr.enable = driver->psr_enabled;
>  }
>  
>  static void
> @@ -1973,6 +2002,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
>   parse_lfp_backlight(dev_priv, bdb);
>   parse_sdvo_panel_data(dev_priv, bdb);
>   parse_driver_features(dev_priv, bdb);
> + parse_power_conservation_features(dev_priv, bdb);
>   parse_edp(dev_priv, bdb);
>   parse_psr(dev_priv, bdb);
>   parse_mipi_config(dev_priv, bdb);
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index f0338da3a82a..98b71dc32d2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -793,6 +793,35 @@ struct bdb_lfp_backlight_data {
>   struct lfp_backlight_control_method backlight_control[16];
>  } __packed;
>  
> +/*
> + * Block 44 - LFP Power Conservation Features Block
> + */
> +
> +struct als_data_entry {
> + u16 backlight_adjust;
> + u16 lux;
> +} __packed;
> +
> +struct agressiveness_profile_entry {
> + u8 dpst_agressiveness : 4;
> + u8 lace_agressiveness : 4;
> +} __packed;
> +
> +struct bdb_lfp_power {
> + u8 lfp_feature_bits;
> + struct als_data_entry als[5];
> + u8 lace_aggressiveness_profile;
> + u16 dpst;
> + u16 psr;
> + u16 drrs;
> + u16 lace_support;
> + u16 adt;
> + u16 dmrrs;
> + u16 adb;
> + u16 lace_enabled_status;
> + struct agressiveness_profile_entry aggressivenes[16];
> +} __packed;
> +
>  /*
>   * Block 52 - MIPI Configuration Block
>   */
> -- 
> 2.24.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
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/display: Suspend MST topology manager before destroy fbdev (rev3)

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/display: Suspend MST topology manager before destroy fbdev 
(rev3)
URL   : https://patchwork.freedesktop.org/series/70081/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15477


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4] ([fdo#105541])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-skl-lmem/igt@i915_module_l...@reload.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][9] ([fdo#112261]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][11] ([fdo#112147]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-kbl-x1275:   [DMESG-WARN][17] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][18] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15477/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#112147]: 

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/psr: Refactor psr short pulse handler

2019-11-27 Thread Matt Roper
On Mon, Nov 25, 2019 at 04:53:57PM -0800, José Roberto de Souza wrote:
> eDP spec states that when sink enconters a problem that prevents it
> to keep PSR running it should set PSR status to internal error and
> set the reason why it happen to PSR_ERROR_STATUS but it is not how it
> was implemented.
> But also I don't want to change this behavior, who knows if there is
> a panel out there that only set the PSR_ERROR_STATUS.
> 
> So here refactoring the code a bit to make more easy to read what was
> state above as more checks will be added to this function.
> 
> v2:
> returning a int instead of a bool in psr_get_status_and_error_status()
> 
> Cc: Gwan-gyeong Mun 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 51 ++--
>  1 file changed, 31 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 0d84ea28bc6f..1a1ac3f46bf7 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1386,11 +1386,30 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   mutex_init(_priv->psr.lock);
>  }
>  
> +static int psr_get_status_and_error_status(struct intel_dp *intel_dp,
> +u8 *status, u8 *error_status)
> +{
> + struct drm_dp_aux *aux = _dp->aux;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
> + if (ret != 1)
> + return ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS, error_status);
> + if (ret != 1)
> + return ret;
> +
> + *status = *status & DP_PSR_SINK_STATE_MASK;
> +
> + return 0;
> +}
> +
>  void intel_psr_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   struct i915_psr *psr = _priv->psr;
> - u8 val;
> + u8 status, error_status;
>   const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
> DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
> DP_PSR_LINK_CRC_ERROR;
> @@ -1403,38 +1422,30 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
>   if (!psr->enabled || psr->dp != intel_dp)
>   goto exit;
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
> - DRM_ERROR("PSR_STATUS dpcd read failed\n");
> + if (psr_get_status_and_error_status(intel_dp, , _status)) {
> + DRM_ERROR("Error reading PSR status or error status\n");
>   goto exit;
>   }
>  
> - if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
> - DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
> + if (status == DP_PSR_SINK_INTERNAL_ERROR || (error_status & errors)) {
>   intel_psr_disable_locked(intel_dp);
>   psr->sink_not_reliable = true;
>   }
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
> - DRM_ERROR("PSR_ERROR_STATUS dpcd read failed\n");
> - goto exit;
> - }
> -
> - if (val & DP_PSR_RFB_STORAGE_ERROR)
> + if (status == DP_PSR_SINK_INTERNAL_ERROR && !error_status)
> + DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
> + if (error_status & DP_PSR_RFB_STORAGE_ERROR)
>   DRM_DEBUG_KMS("PSR RFB storage error, disabling PSR\n");
> - if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
> + if (error_status & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
>   DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling 
> PSR\n");
> - if (val & DP_PSR_LINK_CRC_ERROR)
> + if (error_status & DP_PSR_LINK_CRC_ERROR)
>   DRM_DEBUG_KMS("PSR Link CRC error, disabling PSR\n");
>  
> - if (val & ~errors)
> + if (error_status & ~errors)
>   DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
> -   val & ~errors);
> - if (val & errors) {
> - intel_psr_disable_locked(intel_dp);
> - psr->sink_not_reliable = true;
> - }
> +   error_status & ~errors);
>   /* clear status register */
> - drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
> + drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
>  exit:
>   mutex_unlock(>lock);
>  }
> -- 
> 2.24.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-27 Thread Matt Roper
On Mon, Nov 25, 2019 at 04:53:56PM -0800, José Roberto de Souza wrote:
> PSR2 HW only support a limited number of bits per pixel, if mode has
> more than supported PSR2 should not be enabled.
> 
> BSpec: 50422
> BSpec: 7713
> Cc: Gwan-gyeong Mun 
> Cc: Matt Roper 
> Reviewed-by: Lucas De Marchi 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index c1d133362b76..0d84ea28bc6f 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> - int psr_max_h = 0, psr_max_v = 0;
> + int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
>  
>   if (!dev_priv->psr.sink_psr2_support)
>   return false;
> @@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   if (INTEL_GEN(dev_priv) >= 12) {
>   psr_max_h = 5120;
>   psr_max_v = 3200;
> + max_bpp = 30;
>   } else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
>   psr_max_h = 4096;
>   psr_max_v = 2304;
> + max_bpp = 24;
>   } else if (IS_GEN(dev_priv, 9)) {
>   psr_max_h = 3640;
>   psr_max_v = 2304;
> + max_bpp = 24;
>   }
>  
>   if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
> @@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   return false;
>   }
>  
> + if (crtc_state->pipe_bpp > max_bpp) {
> + DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max supported 
> %d\n",
> +   crtc_state->pipe_bpp, max_bpp);
> + return false;
> + }
> +
>   /*
>* HW sends SU blocks of size four scan lines, which means the starting
>* X coordinate and Y granularity requirements will always be met. We
> -- 
> 2.24.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Handle SDEISR according to PCH rather than platform

2019-11-27 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Handle SDEISR according to PCH 
rather than platform
URL   : https://patchwork.freedesktop.org/series/70130/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15476


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- {fi-tgl-u}: [INCOMPLETE][1] ([fdo#111735]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][3] ([fdo#112261]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][9] ([fdo#112147]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602]) +3 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-kbl-x1275:   [DMESG-WARN][17] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][18] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15476/fi-kbl-x1275/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (52 -> 45)
--

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


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7434 -> 

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Assuming intel_crtc_arm_fifo_underrun() only gets called when
> there's no pending plane updates we can utilize it on gen2 by
> checking the active_planes bitmask so that we only re-enable
> underrun reporting if some planes are active.
> i915_fifo_underrun_reset_write() seems to have the necessary
> hw_done/flip_done waits in place.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4377ee2eee56..ec363972e0ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14221,7 +14221,7 @@ void intel_crtc_arm_fifo_underrun(struct
> intel_crtc *crtc,
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  
> - if (!IS_GEN(dev_priv, 2))
> + if (!IS_GEN(dev_priv, 2) || crtc_state->active_planes)
>   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc-
> >pipe, true);
>  
>   if (crtc_state->has_pch_encoder) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Nuke intel_pre_disable_primary_noatomic()

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's just inline intel_pre_disable_primary_noatomic() into
> intel_plane_disable_noatomic(). The CxSR disable we can do
> regardless of which plane we're disabling, and while at it we can
> make the gen2 underrun w/a accurate by consulting the active_planes
> bitmask.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 57 
> 
>  1 file changed, 22 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5368f3ab70af..4377ee2eee56 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -171,7 +171,6 @@ static void ironlake_pfit_disable(const struct
> intel_crtc_state *old_crtc_state)
>  static void ironlake_pfit_enable(const struct intel_crtc_state
> *crtc_state);
>  static void intel_modeset_setup_hw_state(struct drm_device *dev,
>struct drm_modeset_acquire_ctx
> *ctx);
> -static void intel_pre_disable_primary_noatomic(struct drm_crtc
> *crtc);
>  
>  struct intel_limit {
>   struct {
> @@ -3212,6 +3211,7 @@ static void fixup_active_planes(struct
> intel_crtc_state *crtc_state)
>  static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
>struct intel_plane *plane)
>  {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   struct intel_crtc_state *crtc_state =
>   to_intel_crtc_state(crtc->base.state);
>   struct intel_plane_state *plane_state =
> @@ -3227,7 +3227,27 @@ static void
> intel_plane_disable_noatomic(struct intel_crtc *crtc,
>   crtc_state->min_cdclk[plane->id] = 0;
>  
>   if (plane->id == PLANE_PRIMARY)
> - intel_pre_disable_primary_noatomic(>base);
> + hsw_disable_ips(crtc_state);
> +
> + /*
> +  * Vblank time updates from the shadow to live plane control
> register
> +  * are blocked if the memory self-refresh mode is active at
> that
> +  * moment. So to make sure the plane gets truly disabled,
> disable
> +  * first the self-refresh mode. The self-refresh enable bit in
> turn
> +  * will be checked/applied by the HW only at the next frame
> start
> +  * event which is after the vblank start event, so we need to
> have a
> +  * wait-for-vblank between disabling the plane and the pipe.
> +  */
> + if (HAS_GMCH(dev_priv) &&
> + intel_set_memory_cxsr(dev_priv, false))
> + intel_wait_for_vblank(dev_priv, crtc->pipe);
> +
> + /*
> +  * Gen2 reports pipe underruns whenever all planes are
> disabled.
> +  * So disable underrun reporting before all the planes get
> disabled.
> +  */
> + if (IS_GEN(dev_priv, 2) && !crtc_state->active_planes)
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc-
> >pipe, false);
>  
>   intel_disable_plane(plane, crtc_state);
>  }
> @@ -5908,39 +5928,6 @@ static void
> intel_crtc_dpms_overlay_disable(struct intel_crtc *intel_crtc)
>*/
>  }
>  
> -
> -/* FIXME get rid of this and use pre_plane_update */
> -static void
> -intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> -
> - /*
> -  * Gen2 reports pipe underruns whenever all planes are
> disabled.
> -  * So disable underrun reporting before all the planes get
> disabled.
> -  */
> - if (IS_GEN(dev_priv, 2))
> - intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe,
> false);
> -
> - hsw_disable_ips(to_intel_crtc_state(crtc->state));
> -
> - /*
> -  * Vblank time updates from the shadow to live plane control
> register
> -  * are blocked if the memory self-refresh mode is active at
> that
> -  * moment. So to make sure the plane gets truly disabled,
> disable
> -  * first the self-refresh mode. The self-refresh enable bit in
> turn
> -  * will be checked/applied by the HW only at the next frame
> start
> -  * event which is after the vblank start event, so we need to
> have a
> -  * wait-for-vblank between disabling the plane and the pipe.
> -  */
> - if (HAS_GMCH(dev_priv) &&
> - intel_set_memory_cxsr(dev_priv, false))
> - intel_wait_for_vblank(dev_priv, pipe);
> -}
> -
>  static bool hsw_pre_update_disable_ips(const struct intel_crtc_state
> *old_crtc_state,
>  const struct intel_crtc_state
> *new_crtc_state)
>  {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Clean up the gen2 "no planes -> underrun" workaround

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We have the active_planes bitmask now so use it to properly
> determine when some planes are visible for the gen2 underrun
> workaround.
> 
> This let's us almost eliminate intel_post_enable_primary().
> The manual underrun checks we can simply move into
> intel_atomic_commit_tail() since they loop over all the pipes
> already. No point in repeating the checks multiple times when
> there are multiple pipes in the commit.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 155 +--
> 
>  1 file changed, 70 insertions(+), 85 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 72655b5b1365..5368f3ab70af 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5908,37 +5908,6 @@ static void
> intel_crtc_dpms_overlay_disable(struct intel_crtc *intel_crtc)
>*/
>  }
>  
> -/**
> - * intel_post_enable_primary - Perform operations after enabling
> primary plane
> - * @crtc: the CRTC whose primary plane was just enabled
> - * @new_crtc_state: the enabling state
> - *
> - * Performs potentially sleeping operations that must be done after
> the primary
> - * plane is enabled, such as updating FBC and IPS.  Note that this
> may be
> - * called due to an explicit primary plane update, or due to an
> implicit
> - * re-enable that is caused when a sprite plane is updated to no
> longer
> - * completely hide the primary plane.
> - */
> -static void
> -intel_post_enable_primary(struct intel_crtc *crtc)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe;
> -
> - /*
> -  * Gen2 reports pipe underruns whenever all planes are
> disabled.
> -  * So don't enable underrun reporting before at least some
> planes
> -  * are enabled.
> -  * FIXME: Need to fix the logic to work when we turn off all
> planes
> -  * but leave the pipe running.
> -  */
> - if (IS_GEN(dev_priv, 2))
> - intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe,
> true);
> -
> - /* Underruns don't always raise interrupts, so check manually.
> */
> - intel_check_cpu_fifo_underruns(dev_priv);
> - intel_check_pch_fifo_underruns(dev_priv);
> -}
>  
>  /* FIXME get rid of this and use pre_plane_update */
>  static void
> @@ -6059,6 +6028,20 @@ static bool needs_scalerclk_wa(const struct
> intel_crtc_state *crtc_state)
>   return false;
>  }
>  
> +static bool planes_enabling(const struct intel_crtc_state
> *old_crtc_state,
> + const struct intel_crtc_state
> *new_crtc_state)
> +{
> + return (!old_crtc_state->active_planes ||
> needs_modeset(new_crtc_state)) &&
> + new_crtc_state->active_planes;
> +}
> +
> +static bool planes_disabling(const struct intel_crtc_state
> *old_crtc_state,
> +  const struct intel_crtc_state
> *new_crtc_state)
> +{
> + return old_crtc_state->active_planes &&
> + (!new_crtc_state->active_planes ||
> needs_modeset(new_crtc_state));
> +}
> +
>  static void intel_post_plane_update(struct intel_atomic_state
> *state,
>   struct intel_crtc *crtc)
>  {
> @@ -6068,10 +6051,9 @@ static void intel_post_plane_update(struct
> intel_atomic_state *state,
>   intel_atomic_get_old_crtc_state(state, crtc);
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
> - const struct intel_plane_state *old_primary_state =
> - intel_atomic_get_old_plane_state(state, primary);
>   const struct intel_plane_state *new_primary_state =
>   intel_atomic_get_new_plane_state(state, primary);
> + enum pipe pipe = crtc->pipe;
>  
>   intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
>  
> @@ -6081,22 +6063,16 @@ static void intel_post_plane_update(struct
> intel_atomic_state *state,
>   if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
>   hsw_enable_ips(new_crtc_state);
>  
> - if (new_primary_state) {
> + if (new_primary_state)
>   intel_fbc_post_update(crtc);
>  
> - if (new_primary_state->uapi.visible &&
> - (needs_modeset(new_crtc_state) ||
> -  !old_primary_state->uapi.visible))
> - intel_post_enable_primary(crtc);
> - }
> -
>   if (needs_nv12_wa(old_crtc_state) &&
>   !needs_nv12_wa(new_crtc_state))
> - skl_wa_827(dev_priv, crtc->pipe, false);
> + skl_wa_827(dev_priv, pipe, false);

Nitpick: could be left as it was(s/crtc->pipe/pipe)

>  
>   if (needs_scalerclk_wa(old_crtc_state) &&
>   !needs_scalerclk_wa(new_crtc_state))
> - icl_wa_scalerclkgating(dev_priv, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsb: fix cmd_buf being wrongly set

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/dsb: fix cmd_buf being wrongly set
URL   : https://patchwork.freedesktop.org/series/70129/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15475


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([fdo#112223])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- {fi-tgl-u}: [INCOMPLETE][5] ([fdo#111735]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [DMESG-WARN][7] ([fdo#111764]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][9] ([fdo#112261]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][11] ([fdo#112147]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][17] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][18] ([fdo#103558] / [fdo#105602]) +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][20] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +6 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15475/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [fdo#112147]: 

[Intel-gfx] Kernel >=5.3.11 hangs intel GPU and 5.4.0 freezes completely

2019-11-27 Thread Alessio Turchi
I just filed a bug on the kernel bugzilla about the fact that commit
77fc9100fc5768ca01ca2dd2cc5a515a4723a58a, which you authored, hangs the
intel gpu.
I just discovered that this doesn't happen anymore under 5.4.0, instead
this kernel just freeze completely the notebook.

You can find more info here:
https://bugzilla.kernel.org/show_bug.cgi?id=205545
https://bugs.gentoo.org/700782
https://forums.gentoo.org/viewtopic-p-8392910.html#8392910

I'm writing you because I was suggested to write directly to you.
Could you please look into this?

Thanks,
Alessio Turchi

-- 
---
Alessio Turchi, Ph.D.
INAF - Osservatorio Astrofisico di Arcetri
Largo Enrico Fermi 5, 50125 Firenze, Italy
Phone: (+39)0552752331
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 0/4] drm/rect: Bugfixes and selftests

2019-11-27 Thread Benjamin GAIGNARD

On 11/22/19 6:56 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
>
> My earlier fixes for drm_rect + div-by-zero fix + some
> selftests that Daniel requested.
>
> Cc: Maarten Lankhorst 
> Cc: Benjamin Gaignard 
> Cc: Daniel Vetter 

Thanks to have handle this.

Reviewed-by: Benjamin Gaignard 
>
> Ville Syrjälä (4):
>drm/rect: Avoid division by zero
>drm/rect: Keep the scaled clip bounded
>drm/rect: Keep the clipped dst rectangle in place
>drm/selftests: Add drm_rect selftests
>
>   drivers/gpu/drm/drm_rect.c|  36 +--
>   drivers/gpu/drm/selftests/Makefile|   3 +-
>   .../gpu/drm/selftests/drm_modeset_selftests.h |   4 +
>   .../drm/selftests/test-drm_modeset_common.h   |   7 +
>   drivers/gpu/drm/selftests/test-drm_rect.c | 220 ++
>   include/drm/drm_rect.h|   2 +
>   6 files changed, 257 insertions(+), 15 deletions(-)
>   create mode 100644 drivers/gpu/drm/selftests/test-drm_rect.c
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Clean up intel_{pre, post}_plane_update()

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Change the calling convention to just pass the state+crtc and
> switch to intel_ types throughout.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 88 +-
> --
>  drivers/gpu/drm/i915/display/intel_fbc.c | 14 ++--
>  drivers/gpu/drm/i915/display/intel_fbc.h |  8 +-
>  3 files changed, 51 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e341b97b7dec..72655b5b1365 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5920,13 +5920,10 @@ static void
> intel_crtc_dpms_overlay_disable(struct intel_crtc *intel_crtc)
>   * completely hide the primary plane.
>   */
>  static void
> -intel_post_enable_primary(struct drm_crtc *crtc,
> -   const struct intel_crtc_state
> *new_crtc_state)
> +intel_post_enable_primary(struct intel_crtc *crtc)
>  {
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
>  
>   /*
>* Gen2 reports pipe underruns whenever all planes are
> disabled.
> @@ -6062,20 +6059,21 @@ static bool needs_scalerclk_wa(const struct
> intel_crtc_state *crtc_state)
>   return false;
>  }
>  
> -static void intel_post_plane_update(struct intel_crtc_state
> *old_crtc_state)
> +static void intel_post_plane_update(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >uapi.crtc);
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_atomic_state *state = old_crtc_state->uapi.state;
> - struct intel_crtc_state *new_crtc_state =
> - intel_atomic_get_new_crtc_state(to_intel_atomic_state(s
> tate),
> - crtc);
> - struct drm_plane *primary = crtc->base.primary;
> - struct drm_plane_state *old_primary_state =
> - drm_atomic_get_old_plane_state(state, primary);
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_plane *primary = to_intel_plane(crtc-
> >base.primary);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct intel_plane_state *old_primary_state =
> + intel_atomic_get_old_plane_state(state, primary);
> + const struct intel_plane_state *new_primary_state =
> + intel_atomic_get_new_plane_state(state, primary);
>  
> - intel_frontbuffer_flip(to_i915(crtc->base.dev), new_crtc_state-
> >fb_bits);
> + intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
>  
>   if (new_crtc_state->update_wm_post && new_crtc_state-
> >hw.active)
>   intel_update_watermarks(crtc);
> @@ -6083,16 +6081,13 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
>   hsw_enable_ips(new_crtc_state);
>  
> - if (old_primary_state) {
> - struct drm_plane_state *new_primary_state =
> - drm_atomic_get_new_plane_state(state, primary);
> -
> + if (new_primary_state) {


This change from old_primary_state to new_primary_state is way more
than the commit message says, the change looks right to me but maybe it
deserves a separated patch? Same for the same change in
intel_pre_plane_update()

>   intel_fbc_post_update(crtc);
>  
> - if (new_primary_state->visible &&
> + if (new_primary_state->uapi.visible &&
>   (needs_modeset(new_crtc_state) ||
> -  !old_primary_state->visible))
> - intel_post_enable_primary(>base,
> new_crtc_state);
> +  !old_primary_state->uapi.visible))
> + intel_post_enable_primary(crtc);
>   }
>  
>   if (needs_nv12_wa(old_crtc_state) &&
> @@ -6104,34 +6099,31 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
>  }
>  
> -static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state,
> -struct intel_crtc_state
> *new_crtc_state)
> +static void intel_pre_plane_update(struct intel_atomic_state *state,
> +struct intel_crtc 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsb: fix cmd_buf being wrongly set

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/dsb: fix cmd_buf being wrongly set
URL   : https://patchwork.freedesktop.org/series/70129/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e374ea8db851 drm/i915/dsb: fix cmd_buf being wrongly set
-:13: WARNING:TYPO_SPELLING: 'succesful' may be misspelled - perhaps 
'successful'?
#13: 
all steps are succesful. While at it, rename the label so this confusion

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

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fbc: Fix FBC for glk+ (rev4)

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/fbc: Fix FBC for glk+ (rev4)
URL   : https://patchwork.freedesktop.org/series/70062/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15474


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15474 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15474, 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_15474/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-y:   [PASS][1] -> [FAIL][2] +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u3:  [PASS][3] -> [FAIL][4] +7 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
- fi-icl-dsi: [PASS][5] -> [FAIL][6] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][7] -> [FAIL][8] +7 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-glk-dsi: [PASS][9] -> [FAIL][10] +7 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-glk-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-glk-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- {fi-tgl-u}: [INCOMPLETE][13] ([fdo#111735]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][17] ([fdo#107713]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][19] ([fdo#112261]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][21] ([fdo#112147]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [22]: 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: s/pipe_config/new_crtc_state/ intel_{pre, post}_plane_update()

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 23:09 +, Souza, Jose wrote:
> On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Replace the old world 'pipe_config' variable name with the new
> > thing.
> > 

I guess you mean old word 'pipe_config'?

> 
> Reviewed-by: José Roberto de Souza 
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
> > 
> >  1 file changed, 20 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 89c8f818f289..e341b97b7dec 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6068,20 +6068,20 @@ static void intel_post_plane_update(struct
> > intel_crtc_state *old_crtc_state)
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_atomic_state *state = old_crtc_state->uapi.state;
> > -   struct intel_crtc_state *pipe_config =
> > +   struct intel_crtc_state *new_crtc_state =
> > intel_atomic_get_new_crtc_state(to_intel_atomic_state(s
> > tate),
> > crtc);
> > struct drm_plane *primary = crtc->base.primary;
> > struct drm_plane_state *old_primary_state =
> > drm_atomic_get_old_plane_state(state, primary);
> >  
> > -   intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config-
> > > fb_bits);
> > +   intel_frontbuffer_flip(to_i915(crtc->base.dev), new_crtc_state-
> > > fb_bits);
> >  
> > -   if (pipe_config->update_wm_post && pipe_config->hw.active)
> > +   if (new_crtc_state->update_wm_post && new_crtc_state-
> > > hw.active)
> > intel_update_watermarks(crtc);
> >  
> > -   if (hsw_post_update_enable_ips(old_crtc_state, pipe_config))
> > -   hsw_enable_ips(pipe_config);
> > +   if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
> > +   hsw_enable_ips(new_crtc_state);
> >  
> > if (old_primary_state) {
> > struct drm_plane_state *new_primary_state =
> > @@ -6090,22 +6090,22 @@ static void intel_post_plane_update(struct
> > intel_crtc_state *old_crtc_state)
> > intel_fbc_post_update(crtc);
> >  
> > if (new_primary_state->visible &&
> > -   (needs_modeset(pipe_config) ||
> > +   (needs_modeset(new_crtc_state) ||
> >  !old_primary_state->visible))
> > -   intel_post_enable_primary(>base,
> > pipe_config);
> > +   intel_post_enable_primary(>base,
> > new_crtc_state);
> > }
> >  
> > if (needs_nv12_wa(old_crtc_state) &&
> > -   !needs_nv12_wa(pipe_config))
> > +   !needs_nv12_wa(new_crtc_state))
> > skl_wa_827(dev_priv, crtc->pipe, false);
> >  
> > if (needs_scalerclk_wa(old_crtc_state) &&
> > -   !needs_scalerclk_wa(pipe_config))
> > +   !needs_scalerclk_wa(new_crtc_state))
> > icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
> >  }
> >  
> >  static void intel_pre_plane_update(struct intel_crtc_state
> > *old_crtc_state,
> > -  struct intel_crtc_state
> > *pipe_config)
> > +  struct intel_crtc_state
> > *new_crtc_state)
> >  {
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> > > uapi.crtc);
> > struct drm_device *dev = crtc->base.dev;
> > @@ -6114,11 +6114,11 @@ static void intel_pre_plane_update(struct
> > intel_crtc_state *old_crtc_state,
> > struct drm_plane *primary = crtc->base.primary;
> > struct drm_plane_state *old_primary_state =
> > drm_atomic_get_old_plane_state(state, primary);
> > -   bool modeset = needs_modeset(pipe_config);
> > +   bool modeset = needs_modeset(new_crtc_state);
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> >  
> > -   if (hsw_pre_update_disable_ips(old_crtc_state, pipe_config))
> > +   if (hsw_pre_update_disable_ips(old_crtc_state, new_crtc_state))
> > hsw_disable_ips(old_crtc_state);
> >  
> > if (old_primary_state) {
> > @@ -6126,7 +6126,7 @@ static void intel_pre_plane_update(struct
> > intel_crtc_state *old_crtc_state,
> > intel_atomic_get_new_plane_state(intel_state,
> >  to_intel_plane
> > (primary));
> >  
> > -   intel_fbc_pre_update(crtc, pipe_config,
> > new_primary_state);
> > +   intel_fbc_pre_update(crtc, new_crtc_state,
> > new_primary_state);
> > /*
> >  * Gen2 reports pipe underruns whenever all planes are
> > disabled.
> >  * So disable underrun reporting before all the planes
> > get disabled.
> > @@ -6138,12 +6138,12 @@ static void intel_pre_plane_update(struct
> > intel_crtc_state *old_crtc_state,
> >  
> > /* Display WA 827 */
> > 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: s/pipe_config/new_crtc_state/ intel_{pre, post}_plane_update()

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Replace the old world 'pipe_config' variable name with the new thing.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
> 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 89c8f818f289..e341b97b7dec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6068,20 +6068,20 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_atomic_state *state = old_crtc_state->uapi.state;
> - struct intel_crtc_state *pipe_config =
> + struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(to_intel_atomic_state(s
> tate),
>   crtc);
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_primary_state =
>   drm_atomic_get_old_plane_state(state, primary);
>  
> - intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config-
> >fb_bits);
> + intel_frontbuffer_flip(to_i915(crtc->base.dev), new_crtc_state-
> >fb_bits);
>  
> - if (pipe_config->update_wm_post && pipe_config->hw.active)
> + if (new_crtc_state->update_wm_post && new_crtc_state-
> >hw.active)
>   intel_update_watermarks(crtc);
>  
> - if (hsw_post_update_enable_ips(old_crtc_state, pipe_config))
> - hsw_enable_ips(pipe_config);
> + if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
> + hsw_enable_ips(new_crtc_state);
>  
>   if (old_primary_state) {
>   struct drm_plane_state *new_primary_state =
> @@ -6090,22 +6090,22 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   intel_fbc_post_update(crtc);
>  
>   if (new_primary_state->visible &&
> - (needs_modeset(pipe_config) ||
> + (needs_modeset(new_crtc_state) ||
>!old_primary_state->visible))
> - intel_post_enable_primary(>base,
> pipe_config);
> + intel_post_enable_primary(>base,
> new_crtc_state);
>   }
>  
>   if (needs_nv12_wa(old_crtc_state) &&
> - !needs_nv12_wa(pipe_config))
> + !needs_nv12_wa(new_crtc_state))
>   skl_wa_827(dev_priv, crtc->pipe, false);
>  
>   if (needs_scalerclk_wa(old_crtc_state) &&
> - !needs_scalerclk_wa(pipe_config))
> + !needs_scalerclk_wa(new_crtc_state))
>   icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
>  }
>  
>  static void intel_pre_plane_update(struct intel_crtc_state
> *old_crtc_state,
> -struct intel_crtc_state
> *pipe_config)
> +struct intel_crtc_state
> *new_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >uapi.crtc);
>   struct drm_device *dev = crtc->base.dev;
> @@ -6114,11 +6114,11 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_primary_state =
>   drm_atomic_get_old_plane_state(state, primary);
> - bool modeset = needs_modeset(pipe_config);
> + bool modeset = needs_modeset(new_crtc_state);
>   struct intel_atomic_state *intel_state =
>   to_intel_atomic_state(state);
>  
> - if (hsw_pre_update_disable_ips(old_crtc_state, pipe_config))
> + if (hsw_pre_update_disable_ips(old_crtc_state, new_crtc_state))
>   hsw_disable_ips(old_crtc_state);
>  
>   if (old_primary_state) {
> @@ -6126,7 +6126,7 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>   intel_atomic_get_new_plane_state(intel_state,
>to_intel_plane
> (primary));
>  
> - intel_fbc_pre_update(crtc, pipe_config,
> new_primary_state);
> + intel_fbc_pre_update(crtc, new_crtc_state,
> new_primary_state);
>   /*
>* Gen2 reports pipe underruns whenever all planes are
> disabled.
>* So disable underrun reporting before all the planes
> get disabled.
> @@ -6138,12 +6138,12 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>  
>   /* Display WA 827 */
>   if (!needs_nv12_wa(old_crtc_state) &&
> - needs_nv12_wa(pipe_config))
> + needs_nv12_wa(new_crtc_state))
>   skl_wa_827(dev_priv, crtc->pipe, true);
>  
>   /* Wa_2006604312:icl */
>   if 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Pass dev_priv to ilk_disable_lp_wm()

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Get rid of another 'dev' usage by passing dev_priv instead.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 4 +---
>  drivers/gpu/drm/i915/intel_pm.h  | 2 +-
>  3 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d559b7ae1151..89c8f818f289 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6166,7 +6166,7 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>*
>* WaCxSRDisabledForSpriteScaling:ivb
>*/
> - if (pipe_config->disable_lp_wm && ilk_disable_lp_wm(dev) &&
> + if (pipe_config->disable_lp_wm && ilk_disable_lp_wm(dev_priv)
> &&
>   old_crtc_state->hw.active)
>   intel_wait_for_vblank(dev_priv, crtc->pipe);
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 5aad9d49a528..8d63672452a9 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3592,10 +3592,8 @@ static void ilk_write_wm_values(struct
> drm_i915_private *dev_priv,
>   dev_priv->wm.hw = *results;
>  }
>  
> -bool ilk_disable_lp_wm(struct drm_device *dev)
> +bool ilk_disable_lp_wm(struct drm_i915_private *dev_priv)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> -
>   return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.h
> b/drivers/gpu/drm/i915/intel_pm.h
> index b579c724b915..c06c6a846d9a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -54,7 +54,7 @@ void skl_write_plane_wm(struct intel_plane *plane,
>   const struct intel_crtc_state *crtc_state);
>  void skl_write_cursor_wm(struct intel_plane *plane,
>const struct intel_crtc_state *crtc_state);
> -bool ilk_disable_lp_wm(struct drm_device *dev);
> +bool ilk_disable_lp_wm(struct drm_i915_private *dev_priv);
>  void intel_init_ipc(struct drm_i915_private *dev_priv);
>  void intel_enable_ipc(struct drm_i915_private *dev_priv);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Clean up arguments to nv12/scaler w/a funcs

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 21:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Don't pass the redundant dev_priv to needs_nv12_wa() and
> needs_scalerclk_wa().
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 26 +++---
> --
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 53dc310a5f6d..d559b7ae1151 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6037,9 +6037,10 @@ static bool hsw_post_update_enable_ips(const
> struct intel_crtc_state *old_crtc_s
>   return !old_crtc_state->ips_enabled;
>  }
>  
> -static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
> -   const struct intel_crtc_state *crtc_state)
> +static bool needs_nv12_wa(const struct intel_crtc_state *crtc_state)
>  {
> + struct drm_i915_private *dev_priv = to_i915(crtc_state-
> >uapi.crtc->dev);
> +
>   if (!crtc_state->nv12_planes)
>   return false;
>  
> @@ -6050,9 +6051,10 @@ static bool needs_nv12_wa(struct
> drm_i915_private *dev_priv,
>   return false;
>  }
>  
> -static bool needs_scalerclk_wa(struct drm_i915_private *dev_priv,
> -const struct intel_crtc_state
> *crtc_state)
> +static bool needs_scalerclk_wa(const struct intel_crtc_state
> *crtc_state)
>  {
> + struct drm_i915_private *dev_priv = to_i915(crtc_state-
> >uapi.crtc->dev);
> +
>   /* Wa_2006604312:icl */
>   if (crtc_state->scaler_state.scaler_users > 0 &&
> IS_ICELAKE(dev_priv))
>   return true;
> @@ -6093,12 +6095,12 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>   intel_post_enable_primary(>base,
> pipe_config);
>   }
>  
> - if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> - !needs_nv12_wa(dev_priv, pipe_config))
> + if (needs_nv12_wa(old_crtc_state) &&
> + !needs_nv12_wa(pipe_config))
>   skl_wa_827(dev_priv, crtc->pipe, false);
>  
> - if (needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> - !needs_scalerclk_wa(dev_priv, pipe_config))
> + if (needs_scalerclk_wa(old_crtc_state) &&
> + !needs_scalerclk_wa(pipe_config))
>   icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
>  }
>  
> @@ -6135,13 +6137,13 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state,
>   }
>  
>   /* Display WA 827 */
> - if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> - needs_nv12_wa(dev_priv, pipe_config))
> + if (!needs_nv12_wa(old_crtc_state) &&
> + needs_nv12_wa(pipe_config))
>   skl_wa_827(dev_priv, crtc->pipe, true);
>  
>   /* Wa_2006604312:icl */
> - if (!needs_scalerclk_wa(dev_priv, old_crtc_state) &&
> - needs_scalerclk_wa(dev_priv, pipe_config))
> + if (!needs_scalerclk_wa(old_crtc_state) &&
> + needs_scalerclk_wa(pipe_config))
>   icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
>  
>   /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 5/5] drm/i915/vbt: Parse power conservation features block

2019-11-27 Thread José Roberto de Souza
From VBT 228+ this is block that PSR and other power saving
features configuration should be read from.

v3:
Using DRRS from this new block

Cc: Matt Roper 
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 36 +--
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29 +++
 2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index f6a9a5ccb556..2d06f1f5734d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -659,16 +659,45 @@ parse_driver_features(struct drm_i915_private *dev_priv,
dev_priv->vbt.int_lvds_support = 0;
}
 
-   DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
+   if (bdb->version < 228) {
+   DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
+   /*
+* If DRRS is not supported, drrs_type has to be set to 0.
+* This is because, VBT is configured in such a way that
+* static DRRS is 0 and DRRS not supported is represented by
+* driver->drrs_enabled=false
+*/
+   if (!driver->drrs_enabled)
+   dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+
+   dev_priv->vbt.psr.enable = driver->psr_enabled;
+   }
+}
+
+static void
+parse_power_conservation_features(struct drm_i915_private *dev_priv,
+ const struct bdb_header *bdb)
+{
+   const struct bdb_lfp_power *power;
+   u8 panel_type = dev_priv->vbt.panel_type;
+
+   if (bdb->version < 228)
+   return;
+
+   power = find_section(bdb, BDB_LVDS_POWER);
+   if (!power)
+   return;
+
+   dev_priv->vbt.psr.enable = power->psr & (1 << panel_type);
+
/*
 * If DRRS is not supported, drrs_type has to be set to 0.
 * This is because, VBT is configured in such a way that
 * static DRRS is 0 and DRRS not supported is represented by
 * driver->drrs_enabled=false
 */
-   if (!driver->drrs_enabled)
+   if (!(power->drrs & (1 << panel_type)))
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
-   dev_priv->vbt.psr.enable = driver->psr_enabled;
 }
 
 static void
@@ -1973,6 +2002,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
parse_lfp_backlight(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_driver_features(dev_priv, bdb);
+   parse_power_conservation_features(dev_priv, bdb);
parse_edp(dev_priv, bdb);
parse_psr(dev_priv, bdb);
parse_mipi_config(dev_priv, bdb);
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index f0338da3a82a..98b71dc32d2a 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -793,6 +793,35 @@ struct bdb_lfp_backlight_data {
struct lfp_backlight_control_method backlight_control[16];
 } __packed;
 
+/*
+ * Block 44 - LFP Power Conservation Features Block
+ */
+
+struct als_data_entry {
+   u16 backlight_adjust;
+   u16 lux;
+} __packed;
+
+struct agressiveness_profile_entry {
+   u8 dpst_agressiveness : 4;
+   u8 lace_agressiveness : 4;
+} __packed;
+
+struct bdb_lfp_power {
+   u8 lfp_feature_bits;
+   struct als_data_entry als[5];
+   u8 lace_aggressiveness_profile;
+   u16 dpst;
+   u16 psr;
+   u16 drrs;
+   u16 lace_support;
+   u16 adt;
+   u16 dmrrs;
+   u16 adb;
+   u16 lace_enabled_status;
+   struct agressiveness_profile_entry aggressivenes[16];
+} __packed;
+
 /*
  * Block 52 - MIPI Configuration Block
  */
-- 
2.24.0

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/vbt: Parse power conservation features block

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 10:02 -0800, Matt Roper wrote:
> On Mon, Nov 25, 2019 at 04:47:39PM -0800, Souza, Jose wrote:
> > On Tue, 2019-11-12 at 23:56 +, Souza, Jose wrote:
> > > On Tue, 2019-11-12 at 13:21 -0800, Matt Roper wrote:
> > > > On Tue, Nov 05, 2019 at 05:45:04PM -0800, José Roberto de Souza
> > > > wrote:
> > > > > Since VBT 228 is from this block that PSR and other power
> > > > > saving
> > > > > features configuration should be read from.
> > > > > 
> > > > > Cc: Gwan-gyeong Mun 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_bios.c | 19
> > > > > +++-
> > > > >  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29
> > > > > +++
> > > > >  2 files changed, 47 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > > > > b/drivers/gpu/drm/i915/display/intel_bios.c
> > > > > index a03f56b7b4ef..bf79e9858bd8 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > > > > @@ -561,7 +561,23 @@ parse_driver_features(struct
> > > > > drm_i915_private
> > > > > *dev_priv,
> > > > >*/
> > > > >   if (!driver->drrs_enabled)
> > > > >   dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> > > > > - dev_priv->vbt.psr.enable = driver->psr_enabled;
> > > > > + if (bdb->version < 228)
> > > > > + dev_priv->vbt.psr.enable = driver->psr_enabled;
> > > > > +}
> > > > > +
> > > > > +static void
> > > > > +parse_power_conservation_features(struct drm_i915_private
> > > > > *dev_priv,
> > > > > +   const struct bdb_header *bdb)
> > > > > +{
> > > > > + const struct bdb_lfp_power *power;
> > > > > + u8 panel_type = dev_priv->vbt.panel_type;
> > > > > +
> > > > > + power = find_section(bdb, BDB_LVDS_POWER);
> > > > > + if (!power)
> > > > > + return;
> > > > > +
> > > > > + if (bdb->version >= 228)
> > > > > + dev_priv->vbt.psr.enable = power->psr & (1 <<
> > > > > panel_type);
> > > > 
> > > > Should we also be setting dev_priv->vbt.drrs_type =
> > > > DRRS_NOT_SUPPORTED
> > > > if block 44 tells us it isn't valid on this panel?
> > > > 
> > > 
> > > Yep, it should.
> > > Thanks for catching this.
> > 
> > Nothing from block 40 is obsolete, it has the information about the
> > DRRS type of all the 16 possible panels so is better keep relying
> > on it
> > as block 44 only have only the information if DRRS is supported or
> > not.
> > 
> > I also checked the other features but we don't implement those.
> 
> I think the DRRS_NOT_SUPPORTED is currently being set based on the
> contents of block 12 (in parse_driver_features).  Block 12 does list
> the
> bit we're looking at as obsolete in version 228 (moved to block 44).

Now I got it.
Thanks I will fix that.

> 
> 
> Matt
> 
> > 
> > > > Matt
> > > > 
> > > > >  }
> > > > >  
> > > > >  static void
> > > > > @@ -1878,6 +1894,7 @@ void intel_bios_init(struct
> > > > > drm_i915_private
> > > > > *dev_priv)
> > > > >   parse_lfp_backlight(dev_priv, bdb);
> > > > >   parse_sdvo_panel_data(dev_priv, bdb);
> > > > >   parse_driver_features(dev_priv, bdb);
> > > > > + parse_power_conservation_features(dev_priv, bdb);
> > > > >   parse_edp(dev_priv, bdb);
> > > > >   parse_psr(dev_priv, bdb);
> > > > >   parse_mipi_config(dev_priv, bdb);
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > > index 69a7cb1fa121..31f47ce56587 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > > @@ -792,6 +792,35 @@ struct bdb_lfp_backlight_data {
> > > > >   struct lfp_backlight_control_method
> > > > > backlight_control[16];
> > > > >  } __packed;
> > > > >  
> > > > > +/*
> > > > > + * Block 44 - LFP Power Conservation Features Block
> > > > > + */
> > > > > +
> > > > > +struct als_data_entry {
> > > > > + u16 backlight_adjust;
> > > > > + u16 lux;
> > > > > +} __packed;
> > > > > +
> > > > > +struct agressiveness_profile_entry {
> > > > > + u8 dpst_agressiveness : 4;
> > > > > + u8 lace_agressiveness : 4;
> > > > > +} __packed;
> > > > > +
> > > > > +struct bdb_lfp_power {
> > > > > + u8 lfp_feature_bits;
> > > > > + struct als_data_entry als[5];
> > > > > + u8 lace_aggressiveness_profile;
> > > > > + u16 dpst;
> > > > > + u16 psr;
> > > > > + u16 drrs;
> > > > > + u16 lace_support;
> > > > > + u16 adt;
> > > > > + u16 dmrrs;
> > > > > + u16 adb;
> > > > > + u16 lace_enabled_status;
> > > > > + struct agressiveness_profile_entry aggressivenes[16];
> > > > > +} __packed;
> > > > > +
> > > > >  /*
> > > > >   * Block 52 - MIPI Configuration Block
> > > > >   */
> > > > > -- 
> > > > > 2.24.0
> > > > > 
> > > > > 

[Intel-gfx] [CI 3/3] drm/i915/gen7: Re-enable full-ppgtt for ivb, byt, hsw

2019-11-27 Thread Chris Wilson
After much hair pulling, resort to preallocating the ppGTT entries on
init to circumvent the apparent lack of PD invalidate following the
write to PP_DCLV upon switching mm between contexts (and here the same
context after binding new objects). However, the details of that PP_DCLV
invalidate are still unknown, and it appears we need to reload the mm
twice to cover over a timing issue. Worrying.

Fixes: 3dc007fe9b2b ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to 
aliasing-ppgtt")
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 29 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 12 
 drivers/gpu/drm/i915/i915_pci.c   |  4 +--
 3 files changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f25ceccb335e..9b1047df16ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1366,13 +1366,15 @@ static int load_pd_dir(struct i915_request *rq, const 
struct i915_ppgtt *ppgtt)
const struct intel_engine_cs * const engine = rq->engine;
u32 *cs;
 
-   cs = intel_ring_begin(rq, 6);
+   cs = intel_ring_begin(rq, 8);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   *cs++ = MI_LOAD_REGISTER_IMM(1);
+   *cs++ = MI_LOAD_REGISTER_IMM(2);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base));
*cs++ = PP_DIR_DCLV_2G;
+   *cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base)) + 4;
+   *cs++ = 0;
 
*cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
@@ -1579,30 +1581,25 @@ static int switch_context(struct i915_request *rq)
 {
struct intel_context *ce = rq->hw_context;
struct i915_address_space *vm = vm_alias(ce);
+   u32 hw_flags = 0;
int ret;
 
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
 
if (vm) {
-   ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
-   if (ret)
-   return ret;
+   int loops = 8;
+
+   do {
+   ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
+   if (ret)
+   return ret;
+   } while (--loops);
}
 
if (ce->state) {
-   u32 hw_flags;
-
GEM_BUG_ON(rq->engine->id != RCS0);
 
-   /*
-* The kernel context(s) is treated as pure scratch and is not
-* expected to retain any state (as we sacrifice it during
-* suspend and on resume it may be corrupted). This is ok,
-* as nothing actually executes using the kernel context; it
-* is purely used for flushing user contexts.
-*/
-   hw_flags = 0;
-   if (i915_gem_context_is_kernel(rq->gem_context))
+   if (!rq->engine->default_state)
hw_flags = MI_RESTORE_INHIBIT;
 
ret = mi_set_context(rq, hw_flags);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6239a9adbf14..0458dc53e0ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1692,7 +1692,6 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
intel_wakeref_t wakeref;
u64 from = start;
unsigned int pde;
-   bool flush = false;
int ret = 0;
 
wakeref = intel_runtime_pm_get(>i915->runtime_pm);
@@ -1717,11 +1716,6 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
spin_lock(>lock);
if (pd->entry[pde] == >scratch[1]) {
pd->entry[pde] = pt;
-   if (i915_vma_is_bound(ppgtt->vma,
- I915_VMA_GLOBAL_BIND)) {
-   gen6_write_pde(ppgtt, pde, pt);
-   flush = true;
-   }
} else {
alloc = pt;
pt = pd->entry[pde];
@@ -1732,8 +1726,11 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
}
spin_unlock(>lock);
 
-   if (flush)
+   if (i915_vma_is_bound(ppgtt->vma, I915_VMA_GLOBAL_BIND)) {
+   gen6_for_all_pdes(pt, pd, pde)
+   gen6_write_pde(ppgtt, pde, pt);
gen6_ggtt_invalidate(vm->gt->ggtt);
+   }
 
goto out;
 
@@ -1994,6 +1991,7 @@ static struct i915_ppgtt *gen6_ppgtt_create(struct 
drm_i915_private *i915)
 err_pd:
kfree(ppgtt->base.pd);
 err_free:
+   mutex_destroy(>pin_mutex);
kfree(ppgtt);
return ERR_PTR(err);
 }

[Intel-gfx] [CI 1/3] drm/i915/selftests: Count the number of engines used

2019-11-27 Thread Chris Wilson
Don't rely on the RUNTIME_INFO() when we loop over a particular context
and only run on a filtered set of engines.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c | 25 ---
 1 file changed, 16 insertions(+), 9 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 2ea4790f3721..33e56d9af061 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1343,11 +1343,13 @@ static int igt_ctx_sseu(void *arg)
 static int igt_ctx_readonly(void *arg)
 {
struct drm_i915_private *i915 = arg;
+   unsigned long idx, ndwords, dw, num_engines;
struct drm_i915_gem_object *obj = NULL;
struct i915_request *tq[5] = {};
+   struct i915_gem_engines_iter it;
struct i915_address_space *vm;
struct i915_gem_context *ctx;
-   unsigned long idx, ndwords, dw;
+   struct intel_context *ce;
struct igt_live_test t;
I915_RND_STATE(prng);
IGT_TIMEOUT(end_time);
@@ -1381,12 +1383,15 @@ static int igt_ctx_readonly(void *arg)
goto out_file;
}
 
+   num_engines = 0;
+   for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
+   if (intel_engine_can_store_dword(ce->engine))
+   num_engines++;
+   i915_gem_context_unlock_engines(ctx);
+
ndwords = 0;
dw = 0;
while (!time_after(jiffies, end_time)) {
-   struct i915_gem_engines_iter it;
-   struct intel_context *ce;
-
for_each_gem_engine(ce,
i915_gem_context_lock_engines(ctx), it) {
if (!intel_engine_can_store_dword(ce->engine))
@@ -1429,8 +1434,8 @@ static int igt_ctx_readonly(void *arg)
}
i915_gem_context_unlock_engines(ctx);
}
-   pr_info("Submitted %lu dwords (across %u engines)\n",
-   ndwords, RUNTIME_INFO(i915)->num_engines);
+   pr_info("Submitted %lu dwords (across %lu engines)\n",
+   ndwords, num_engines);
 
dw = 0;
idx = 0;
@@ -1690,10 +1695,10 @@ static int igt_vm_isolation(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct i915_gem_context *ctx_a, *ctx_b;
+   unsigned long num_engines, count;
struct intel_engine_cs *engine;
struct igt_live_test t;
I915_RND_STATE(prng);
-   unsigned long count;
struct file *file;
u64 vm_total;
int err;
@@ -1735,6 +1740,7 @@ static int igt_vm_isolation(void *arg)
vm_total -= I915_GTT_PAGE_SIZE;
 
count = 0;
+   num_engines = 0;
for_each_uabi_engine(engine, i915) {
IGT_TIMEOUT(end_time);
unsigned long this = 0;
@@ -1772,9 +1778,10 @@ static int igt_vm_isolation(void *arg)
this++;
}
count += this;
+   num_engines++;
}
-   pr_info("Checked %lu scratch offsets across %d engines\n",
-   count, RUNTIME_INFO(i915)->num_engines);
+   pr_info("Checked %lu scratch offsets across %lu engines\n",
+   count, num_engines);
 
 out_file:
if (igt_live_test_end())
-- 
2.24.0

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

[Intel-gfx] [CI 2/3] drm/i915/selftests: Flush fput after running selftests

2019-11-27 Thread Chris Wilson
Use an rcu_barrier() to flush any mock files used by the selftests as
the deferred cleanup may be holding resources that we need to cleanup.

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

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index d3bf9eefb682..036e30b8b62d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -152,8 +152,10 @@ static int __run_selftests(const char *name,
continue;
 
cond_resched();
-   if (signal_pending(current))
-   return -EINTR;
+   if (signal_pending(current)) {
+   err = -EINTR;
+   goto out;
+   }
 
pr_info(DRIVER_NAME ": Running %s\n", st->name);
if (data)
@@ -171,6 +173,8 @@ static int __run_selftests(const char *name,
 st->name, err))
err = -1;
 
+out:
+   rcu_barrier(); /* flush deferred fput() */
return err;
 }
 
-- 
2.24.0

___
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: Cleanups around pre/post plane update

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915: Cleanups around pre/post plane update
URL   : https://patchwork.freedesktop.org/series/70125/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15473


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([fdo#107707])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#109483])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([fdo#111045] / [fdo#111096])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][11] ([fdo#112261]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][13] ([fdo#112147]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][17] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][18] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][20] ([fdo#103558] / [fdo#105602]) +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][22] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15473/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: 

[Intel-gfx] [CI 1/3] drm/i915: Handle SDEISR according to PCH rather than platform

2019-11-27 Thread Matt Roper
The South Display is part of the PCH so we should technically be basing
our port detection logic off the PCH in use rather than the platform
generation.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index be9e8e4497bf..777adb875ba2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5498,7 +5498,7 @@ static bool icl_combo_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
 }
 
-static bool icl_digital_port_connected(struct intel_encoder *encoder)
+static bool icp_digital_port_connected(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
@@ -5536,9 +5536,9 @@ static bool __intel_digital_port_connected(struct 
intel_encoder *encoder)
return g4x_digital_port_connected(encoder);
}
 
-   if (INTEL_GEN(dev_priv) >= 11)
-   return icl_digital_port_connected(encoder);
-   else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv))
+   if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+   return icp_digital_port_connected(encoder);
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
return spt_digital_port_connected(encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(encoder);
-- 
2.23.0

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

[Intel-gfx] [CI 3/3] drm/i915: Program SHPD_FILTER_CNT on CNP+

2019-11-27 Thread Matt Roper
The bspec tells us 'Program SHPD_FILTER_CNT with the "500 microseconds
adjusted" value before enabling hotplug detection' on CNP+.  We haven't
been touching this register at all thus far, but we should probably
follow the bspec's guidance.

The register also exists on LPT and SPT, but there isn't any specific
guidance I can find on how we should be programming it there so let's
leave it be for now.

Bspec: 4342
Bspec: 31297
Bspec: 8407
Bspec: 49305
Bspec: 50473

Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_irq.c | 5 +
 drivers/gpu/drm/i915/i915_reg.h | 4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8b338744eddf..46a9f7dafbf3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2980,6 +2980,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private 
*dev_priv,
hotplug_irqs = sde_ddi_mask | sde_tc_mask;
enabled_irqs = intel_hpd_enabled_irqs(dev_priv, pins);
 
+   I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
+
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
 
icp_hpd_detection_setup(dev_priv, ddi_enable_mask, tc_enable_mask);
@@ -3085,6 +3087,9 @@ static void spt_hpd_irq_setup(struct drm_i915_private 
*dev_priv)
 {
u32 hotplug_irqs, enabled_irqs;
 
+   if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
+   I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
+
hotplug_irqs = SDE_HOTPLUG_MASK_SPT;
enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_spt);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 94d0f593eeb7..74cf45de162e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8110,6 +8110,10 @@ enum {
 
 #define SHOTPLUG_CTL_TC_MMIO(0xc4034)
 #define   ICP_TC_HPD_ENABLE(tc_port)   (8 << (tc_port) * 4)
+
+#define SHPD_FILTER_CNT_MMIO(0xc4038)
+#define   SHPD_FILTER_CNT_500_ADJ  0x001D9
+
 /* Icelake DSC Rate Control Range Parameter Registers */
 #define DSCA_RC_RANGE_PARAMETERS_0 _MMIO(0x6B240)
 #define DSCA_RC_RANGE_PARAMETERS_0_UDW _MMIO(0x6B240 + 4)
-- 
2.23.0

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

[Intel-gfx] [CI 2/3] drm/i915/ehl: Make icp_digital_port_connected() use phy instead of port

2019-11-27 Thread Matt Roper
When looking at SDEISR to determine the connection status of combo
outputs, we should use the phy index rather than the port index.
Although they're usually the same thing, EHL's DDI-D (port D) is
attached to PHY-A and SDEISR doesn't even have bits for a "D" output.
It's also possible that future platforms may map DDIs (the internal
display engine programming units) to PHYs (the output handling on the IO
side) in ways where port!=phy, so let's look at the PHY index by
default.

v2: Rename to intel_combo_phy_connected.  (Lucas)

Fixes: 719d24002602 ("drm/i915/ehl: Enable DDI-D")
Cc: José Roberto de Souza 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
Reviewed-by: Lucas De Marchi 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 777adb875ba2..5c406a0fd045 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5487,15 +5487,13 @@ static bool bxt_digital_port_connected(struct 
intel_encoder *encoder)
return I915_READ(GEN8_DE_PORT_ISR) & bit;
 }
 
-static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
-struct intel_digital_port *intel_dig_port)
+static bool intel_combo_phy_connected(struct drm_i915_private *dev_priv,
+ enum phy phy)
 {
-   enum port port = intel_dig_port->base.port;
-
-   if (HAS_PCH_MCC(dev_priv) && port == PORT_C)
+   if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
return I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(PORT_TC1);
 
-   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(phy);
 }
 
 static bool icp_digital_port_connected(struct intel_encoder *encoder)
@@ -5505,7 +5503,7 @@ static bool icp_digital_port_connected(struct 
intel_encoder *encoder)
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
 
if (intel_phy_is_combo(dev_priv, phy))
-   return icl_combo_port_connected(dev_priv, dig_port);
+   return intel_combo_phy_connected(dev_priv, phy);
else if (intel_phy_is_tc(dev_priv, phy))
return intel_tc_port_connected(dig_port);
else
-- 
2.23.0

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

[Intel-gfx] [PATCH] drm/i915/dsb: fix cmd_buf being wrongly set

2019-11-27 Thread Lucas De Marchi
The "err" label is not really "err", but rather "out" since the return
path is shared between error condition and normal path. This broke when
commit 03cea61076f0 ("drm/i915/dsb: fix extra warning on error path
handling") added a "dsb->cmd_buf = NULL;" there, making DSB to stop
working since now all writes would pass-through via mmio.

Remove the set to NULL since it's actually not needed: we only set it if
all steps are succesful. While at it, rename the label so this confusion
doesn't happen again.

Fixes: 03cea61076f0 ("drm/i915/dsb: fix extra warning on error path handling"
Resolves: https://gitlab.freedesktop.org/drm/intel/issues/8
Signed-off-by: Lucas De Marchi 
---

Right now I don't have access to the hw to reproduce it, so this is
build-tested only.

 drivers/gpu/drm/i915/display/intel_dsb.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 5bf67bdc8182..ada006a690df 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -116,34 +116,34 @@ intel_dsb_get(struct intel_crtc *crtc)
obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
if (IS_ERR(obj)) {
DRM_ERROR("Gem object creation failed\n");
-   goto err;
+   goto out;
}
 
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
DRM_ERROR("Vma creation failed\n");
i915_gem_object_put(obj);
-   goto err;
+   goto out;
}
 
buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
if (IS_ERR(buf)) {
DRM_ERROR("Command buffer creation failed\n");
-   goto err;
+   goto out;
}
 
dsb->id = DSB1;
dsb->vma = vma;
dsb->cmd_buf = buf;
 
-err:
+out:
/*
-* Set cmd_buf to NULL so the writes pass-through, but leave the
-* dangling refcount to be removed later by the corresponding
-* intel_dsb_put(): the important error message will already be
-* logged above.
+* On error dsb->cmd_buf will continue to be NULL, making the writes
+* pass-through. Leave the dangling ref to be removed later by the
+* corresponding intel_dsb_put(): the important error message will
+* already be logged above.
 */
-   dsb->cmd_buf = NULL;
+
intel_runtime_pm_put(>runtime_pm, wakeref);
 
return dsb;
-- 
2.24.0

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/5] drm/i915/psr: Add bits per pixel limitation (rev2)

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 09:23 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/5] drm/i915/psr: Add bits per
> pixel limitation (rev2)
> URL   : https://patchwork.freedesktop.org/series/70002/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7426_full -> Patchwork_15445_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_15445_full absolutely
> need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the
> changes
>   introduced in Patchwork_15445_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_15445_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_plane@pixel-format-pipe-b-planes:
> - shard-skl:  [PASS][1] -> [INCOMPLETE][2] +2 similar
> issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-skl5/igt@kms_pl...@pixel-format-pipe-b-planes.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-skl4/igt@kms_pl...@pixel-format-pipe-b-planes.html
> 

Not related with this changes.

>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_15445_full that come from
> known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@rcs0-s3:
> - shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566])
> +4 similar issues
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html
> 
>   * igt@gem_exec_parallel@vcs1-fds:
> - shard-kbl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#103665])
> +1 similar issue
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-kbl1/igt@gem_exec_paral...@vcs1-fds.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-kbl4/igt@gem_exec_paral...@vcs1-fds.html
> 
>   * igt@gem_ppgtt@flink-and-close-vma-leak:
> - shard-glk:  [PASS][7] -> [FAIL][8] ([fdo#112392])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html
> - shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#112392])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-skl5/igt@gem_pp...@flink-and-close-vma-leak.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-skl4/igt@gem_pp...@flink-and-close-vma-leak.html
> 
>   * igt@gem_userptr_blits@sync-unmap:
> - shard-snb:  [PASS][11] -> [DMESG-WARN][12]
> ([fdo#111870]) +1 similar issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-snb5/igt@gem_userptr_bl...@sync-unmap.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-snb1/igt@gem_userptr_bl...@sync-unmap.html
> 
>   * igt@gem_userptr_blits@sync-unmap-after-close:
> - shard-hsw:  [PASS][13] -> [DMESG-WARN][14]
> ([fdo#111870]) +1 similar issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-hsw8/igt@gem_userptr_bl...@sync-unmap-after-close.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-hsw7/igt@gem_userptr_bl...@sync-unmap-after-close.html
> 
>   * igt@gem_workarounds@suspend-resume-context:
> - shard-tglb: [PASS][15] -> [INCOMPLETE][16]
> ([fdo#111832] / [fdo#111850])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-tglb6/igt@gem_workarou...@suspend-resume-context.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-tglb4/igt@gem_workarou...@suspend-resume-context.html
> 
>   * igt@i915_pm_dc@dc6-dpms:
> - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#111830 ])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-iclb8/igt@i915_pm...@dc6-dpms.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-iclb3/igt@i915_pm...@dc6-dpms.html
> 
>   * igt@i915_pm_rpm@system-suspend-modeset:
> - shard-kbl:  [PASS][19] -> [INCOMPLETE][20]
> ([fdo#103665] / [fdo#107807])
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-kbl4/igt@i915_pm_...@system-suspend-modeset.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15445/shard-kbl6/igt@i915_pm_...@system-suspend-modeset.html
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-suspend:
> - shard-kbl:  [PASS][21] -> [DMESG-WARN][22]
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen7: Re-enable full-ppgtt for ivb, byt, hsw (rev5)

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915/gen7: Re-enable full-ppgtt for ivb, byt, hsw (rev5)
URL   : https://patchwork.freedesktop.org/series/70089/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15472


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15472 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15472, 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_15472/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
- fi-ivb-3770:[PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770:[PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-peppy:   [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770r:   [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
- fi-byt-n2820:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k:   [PASS][13] -> [INCOMPLETE][14] ([fdo#111700])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][17] ([fdo#107713]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][19] ([fdo#112261]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][21] -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15472/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][23] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][24] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [23]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Handle SDEISR according to PCH rather than platform (rev4)

2019-11-27 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Handle SDEISR according to PCH 
rather than platform (rev4)
URL   : https://patchwork.freedesktop.org/series/70073/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15471


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15471 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15471, 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_15471/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_gt_heartbeat:
- fi-icl-u3:  NOTRUN -> [DMESG-FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-icl-u3/igt@i915_selftest@live_gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][2] -> [FAIL][3] ([fdo#103167])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
- fi-hsw-peppy:   [PASS][4] -> [DMESG-WARN][5] ([fdo#102614])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][6] ([fdo#112261]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][8] ([fdo#107713]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][10] ([fdo#112147]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][12] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][14] ([fdo#112261]) -> [FAIL][15] 
([fdo#108511])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][16] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][17] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +6 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-kbl-x1275:   [DMESG-WARN][18] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][19] ([fdo#103558] / [fdo#105602]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15471/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html

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

  [fdo#102614]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for video, drm: constify fbops in struct fb_info

2019-11-27 Thread Patchwork
== Series Details ==

Series: video, drm: constify fbops in struct fb_info
URL   : https://patchwork.freedesktop.org/series/70119/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15470


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-bsw-nick:[PASS][1] -> [DMESG-FAIL][2] ([fdo#112176])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-bsw-nick/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-bsw-nick/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][9] ([fdo#112261]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][11] ([fdo#112147]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602]) +4 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][17] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][18] ([fdo#103558] / [fdo#105602] / [fdo#105763])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15470/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html

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

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
  [fdo#112298]: 

[Intel-gfx] [PATCH v2 08/14] drm/i915/fbc: Make fence_id optional for i965gm

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.

In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 600565647f37..c25e9ecb8506 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -138,8 +138,10 @@ static void i8xx_fbc_activate(struct drm_i915_private 
*dev_priv)
u32 fbc_ctl2;
 
/* Set it up... */
-   fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM | 
FBC_CTL_CPU_FENCE;
+   fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM;
fbc_ctl2 |= FBC_CTL_PLANE(params->crtc.i9xx_plane);
+   if (params->fence_id >= 0)
+   fbc_ctl2 |= FBC_CTL_CPU_FENCE;
I915_WRITE(FBC_CONTROL2, fbc_ctl2);
I915_WRITE(FBC_FENCE_OFF, params->crtc.fence_y_offset);
}
@@ -151,7 +153,8 @@ static void i8xx_fbc_activate(struct drm_i915_private 
*dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
-   fbc_ctl |= params->fence_id;
+   if (params->fence_id >= 0)
+   fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
 }
 
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 11/14] drm/i915/fbc: Start using flip nuke

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.

We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 50 ++--
 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index ccc1b5cc42d8..220fbe5bd919 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -68,7 +68,7 @@ static unsigned int get_crtc_fence_y_offset(struct intel_fbc 
*fbc)
  * write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
  * we wrote to PIPESRC.
  */
-static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache 
*cache,
+static void intel_fbc_get_plane_source_size(const struct intel_fbc_state_cache 
*cache,
int *width, int *height)
 {
if (width)
@@ -78,7 +78,7 @@ static void intel_fbc_get_plane_source_size(struct 
intel_fbc_state_cache *cache,
 }
 
 static int intel_fbc_calculate_cfb_size(struct drm_i915_private *dev_priv,
-   struct intel_fbc_state_cache *cache)
+   const struct intel_fbc_state_cache 
*cache)
 {
int lines;
 
@@ -827,6 +827,38 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
params->plane_visible = cache->plane.visible;
 }
 
+static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   const struct intel_fbc *fbc = _priv->fbc;
+   const struct intel_fbc_state_cache *cache = >state_cache;
+   const struct intel_fbc_reg_params *params = >params;
+
+   if (drm_atomic_crtc_needs_modeset(_state->uapi))
+   return false;
+
+   if (!params->plane_visible)
+   return false;
+
+   if (!intel_fbc_can_activate(crtc))
+   return false;
+
+   if (params->fb.format != cache->fb.format)
+   return false;
+
+   if (params->fb.stride != cache->fb.stride)
+   return false;
+
+   if (params->cfb_size != intel_fbc_calculate_cfb_size(dev_priv, cache))
+   return false;
+
+   if (params->gen9_wa_cfb_stride != cache->gen9_wa_cfb_stride)
+   return false;
+
+   return true;
+}
+
 void intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct intel_plane_state *plane_state)
@@ -846,7 +878,8 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
 
-   intel_fbc_deactivate(dev_priv, reason);
+   if (!intel_fbc_can_flip_nuke(crtc_state))
+   intel_fbc_deactivate(dev_priv, reason);
 unlock:
mutex_unlock(>lock);
 }
@@ -885,7 +918,6 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
return;
 
fbc->flip_pending = false;
-   WARN_ON(fbc->active);
 
if (!i915_modparams.enable_fbc) {
intel_fbc_deactivate(dev_priv, "disabled at runtime per module 
param");
@@ -899,10 +931,9 @@ static void __intel_fbc_post_update(struct intel_crtc 
*crtc)
if (!intel_fbc_can_activate(crtc))
return;
 
-   if (!fbc->busy_bits) {
-   intel_fbc_deactivate(dev_priv, "FBC enabled (active or 
scheduled)");
+   if (!fbc->busy_bits)
intel_fbc_hw_activate(dev_priv);
-   } else
+   else
intel_fbc_deactivate(dev_priv, "frontbuffer write");
 }
 
@@ -1061,10 +1092,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(>lock);
 
if (fbc->crtc) {
-   if (fbc->crtc == crtc) {
-   WARN_ON(!crtc_state->enable_fbc);
-   WARN_ON(fbc->active);
-   }
+   WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
goto out;
}
 
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 09/14] drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index c25e9ecb8506..9a57ebc16c74 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -281,7 +281,7 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
int threshold = dev_priv->fbc.threshold;
 
/* Display WA #0529: skl, kbl, bxt. */
-   if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) {
+   if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
u32 val = I915_READ(CHICKEN_MISC_4);
 
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
@@ -1089,7 +1089,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
}
 
-   if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+   if ((IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) &&
fb->modifier != I915_FORMAT_MOD_X_TILED)
cache->gen9_wa_cfb_stride =
DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 
8;
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 07/14] drm/i915/fbc: Store fence_id direction in fbc cache/params

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 33 +---
 drivers/gpu/drm/i915/i915_drv.h  |  8 ++
 2 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 54ed1a74d02b..600565647f37 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -151,7 +151,7 @@ static void i8xx_fbc_activate(struct drm_i915_private 
*dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
-   fbc_ctl |= params->vma->fence->id;
+   fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
 }
 
@@ -171,8 +171,8 @@ static void g4x_fbc_activate(struct drm_i915_private 
*dev_priv)
else
dpfc_ctl |= DPFC_CTL_LIMIT_1X;
 
-   if (params->flags & PLANE_HAS_FENCE) {
-   dpfc_ctl |= DPFC_CTL_FENCE_EN | params->vma->fence->id;
+   if (params->fence_id >= 0) {
+   dpfc_ctl |= DPFC_CTL_FENCE_EN | params->fence_id;
I915_WRITE(DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
} else {
I915_WRITE(DPFC_FENCE_YOFF, 0);
@@ -229,14 +229,14 @@ static void ilk_fbc_activate(struct drm_i915_private 
*dev_priv)
break;
}
 
-   if (params->flags & PLANE_HAS_FENCE) {
+   if (params->fence_id >= 0) {
dpfc_ctl |= DPFC_CTL_FENCE_EN;
if (IS_GEN(dev_priv, 5))
-   dpfc_ctl |= params->vma->fence->id;
+   dpfc_ctl |= params->fence_id;
if (IS_GEN(dev_priv, 6)) {
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE |
-  params->vma->fence->id);
+  params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET,
   params->crtc.fence_y_offset);
}
@@ -309,11 +309,11 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
break;
}
 
-   if (params->flags & PLANE_HAS_FENCE) {
+   if (params->fence_id >= 0) {
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE |
-  params->vma->fence->id);
+  params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, params->crtc.fence_y_offset);
} else {
I915_WRITE(SNB_DPFC_CTL_SA,0);
@@ -659,10 +659,14 @@ static void intel_fbc_update_state_cache(struct 
intel_crtc *crtc,
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
 
-   cache->vma = plane_state->vma;
-   cache->flags = plane_state->flags;
-   if (WARN_ON(cache->flags & PLANE_HAS_FENCE && !cache->vma->fence))
-   cache->flags &= ~PLANE_HAS_FENCE;
+   WARN_ON(plane_state->flags & PLANE_HAS_FENCE &&
+   !plane_state->vma->fence);
+
+   if (plane_state->flags & PLANE_HAS_FENCE &&
+   plane_state->vma->fence)
+   cache->fence_id = plane_state->vma->fence->id;
+   else
+   cache->fence_id = -1;
 }
 
 static bool intel_fbc_can_activate(struct intel_crtc *crtc)
@@ -707,7 +711,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 * For now this will effecively disable FBC with 90/270 degree
 * rotation.
 */
-   if (!(cache->flags & PLANE_HAS_FENCE)) {
+   if (cache->fence_id < 0) {
fbc->no_fbc_reason = "framebuffer not tiled or fenced";
return false;
}
@@ -804,8 +808,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
 * zero. */
memset(params, 0, sizeof(*params));
 
-   params->vma = cache->vma;
-   params->flags = cache->flags;
+   params->fence_id = cache->fence_id;
 
params->crtc.pipe = crtc->pipe;
params->crtc.i9xx_plane = 
to_intel_plane(crtc->base.primary)->i9xx_plane;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82dafef9ae10..81556dc353b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -386,9 +386,6 @@ struct intel_fbc {
 * these problems.
 */
struct intel_fbc_state_cache {
-   struct i915_vma *vma;
-   unsigned long flags;
-
struct {
unsigned int mode_flags;
u32 hsw_bdw_pixel_rate;
@@ -418,6 +415,7 @@ struct intel_fbc {
  

[Intel-gfx] [PATCH v2 12/14] drm/i915/fbc: Wait for vblank after FBC disable on glk+

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.

We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c |  4 ++-
 drivers/gpu/drm/i915/display/intel_fbc.c | 26 +---
 drivers/gpu/drm/i915/display/intel_fbc.h |  2 +-
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d592b7284406..3210a0f9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6105,7 +6105,9 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
 
to_intel_plane(primary));
 
-   intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+   if (intel_fbc_pre_update(crtc, pipe_config, new_primary_state))
+   intel_wait_for_vblank(dev_priv, crtc->pipe);
+
/*
 * Gen2 reports pipe underruns whenever all planes are disabled.
 * So disable underrun reporting before all the planes get 
disabled.
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 220fbe5bd919..78fe4abb5a93 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -859,16 +859,17 @@ static bool intel_fbc_can_flip_nuke(const struct 
intel_crtc_state *crtc_state)
return true;
 }
 
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct intel_plane_state *plane_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = _priv->fbc;
const char *reason = "update pending";
+   bool need_vblank_wait = false;
 
if (!fbc_supported(dev_priv))
-   return;
+   return need_vblank_wait;
 
mutex_lock(>lock);
 
@@ -878,10 +879,29 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
 
-   if (!intel_fbc_can_flip_nuke(crtc_state))
+   if (!intel_fbc_can_flip_nuke(crtc_state)) {
intel_fbc_deactivate(dev_priv, reason);
+
+   /*
+* Display WA #1198: glk+
+* Need an extra vblank wait between FBC disable and most plane
+* updates. Bspec says this is only needed for plane disable, 
but
+* that is not true. Touching most plane registers will cause 
the
+* corruption to appear. Also SKL/derivatives do not seem to be
+* affected.
+*
+* TODO: could optimize this a bit by sampling the frame
+* counter when we disable FBC (if it was already done earlier)
+* and skipping the extra vblank wait before the plane update
+* if at least one frame has already passed.
+*/
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+   need_vblank_wait = true;
+   }
 unlock:
mutex_unlock(>lock);
+
+   return need_vblank_wait;
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h 
b/drivers/gpu/drm/i915/display/intel_fbc.h
index ba8eeefd4d9a..9a2f1094cbda 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -19,7 +19,7 @@ struct intel_plane_state;
 void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
   struct intel_atomic_state *state);
 bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct intel_plane_state *plane_state);
 void intel_fbc_post_update(struct intel_crtc *crtc);
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 05/14] drm/i915/fbc: Precompute gen9 cfb stride w/a

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.

The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.

v2: Don't explode when crtc_state->enable_fbc lies to us

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 38 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  3 +-
 2 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index eefa5a88b304..6a32f1eaefeb 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -283,8 +283,7 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
 
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
 
-   if (i915_gem_object_get_tiling(params->vma->obj) !=
-   I915_TILING_X)
+   if (params->gen9_wa_cfb_stride)
val |= FBC_STRIDE_OVERRIDE | params->gen9_wa_cfb_stride;
 
I915_WRITE(CHICKEN_MISC_4, val);
@@ -414,8 +413,8 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv,
 
 static int find_compression_threshold(struct drm_i915_private *dev_priv,
  struct drm_mm_node *node,
- int size,
- int fb_cpp)
+ unsigned int size,
+ unsigned int fb_cpp)
 {
int compression_threshold = 1;
int ret;
@@ -461,18 +460,15 @@ static int find_compression_threshold(struct 
drm_i915_private *dev_priv,
}
 }
 
-static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
+static int intel_fbc_alloc_cfb(struct drm_i915_private *dev_priv,
+  unsigned int size, unsigned int fb_cpp)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = _priv->fbc;
struct drm_mm_node *uninitialized_var(compressed_llb);
-   int size, fb_cpp, ret;
+   int ret;
 
WARN_ON(drm_mm_node_allocated(>compressed_fb));
 
-   size = intel_fbc_calculate_cfb_size(dev_priv, >state_cache);
-   fb_cpp = fbc->state_cache.fb.format->cpp[0];
-
ret = find_compression_threshold(dev_priv, >compressed_fb,
 size, fb_cpp);
if (!ret)
@@ -823,9 +819,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
 
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
 
-   if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
-   params->gen9_wa_cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
-   32 * fbc->threshold) * 8;
+   params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
 }
 
 void intel_fbc_pre_update(struct intel_crtc *crtc,
@@ -1054,6 +1048,8 @@ void intel_fbc_enable(struct intel_crtc *crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = _priv->fbc;
+   struct intel_fbc_state_cache *cache = >state_cache;
+   const struct drm_framebuffer *fb = plane_state->hw.fb;
 
if (!fbc_supported(dev_priv))
return;
@@ -1076,11 +1072,25 @@ void intel_fbc_enable(struct intel_crtc *crtc,
WARN_ON(fbc->crtc != NULL);
 
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
-   if (intel_fbc_alloc_cfb(crtc)) {
+
+   /* FIXME crtc_state->enable_fbc lies :( */
+   if (!cache->plane.visible)
+   goto out;
+
+   if (intel_fbc_alloc_cfb(dev_priv,
+   intel_fbc_calculate_cfb_size(dev_priv, cache),
+   fb->format->cpp[0])) {
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
 
+   if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+   fb->modifier != I915_FORMAT_MOD_X_TILED)
+   cache->gen9_wa_cfb_stride =
+   DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 
8;
+   else
+   cache->gen9_wa_cfb_stride = 0;
+
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0e00078fbce..ccde7eaf7dab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -417,6 +417,7 @@ struct intel_fbc {
const struct drm_format_info *format;
unsigned int stride;
} fb;
+   u16 gen9_wa_cfb_stride;
} state_cache;
 
/*
@@ -442,7 +443,7 @@ struct intel_fbc {
} fb;
 
int cfb_size;
-   

[Intel-gfx] ✗ Fi.CI.IGT: failure for bios: dot not discard address space (rev2)

2019-11-27 Thread Patchwork
== Series Details ==

Series: bios: dot not discard address space (rev2)
URL   : https://patchwork.freedesktop.org/series/70075/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7430_full -> Patchwork_15459_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15459_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15459_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_15459_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-skl1/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@smoketest:
- shard-glk:  [PASS][2] -> [TIMEOUT][3] ([fdo#112404])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-glk4/igt@gem_ctx_persiste...@smoketest.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-glk8/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_schedule@preempt-queue-contexts-blt:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5] ([fdo#111606] / 
[fdo#111677])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-tglb1/igt@gem_exec_sched...@preempt-queue-contexts-blt.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-blt.html

  * igt@gem_exec_schedule@preempt-queue-vebox:
- shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([fdo#111677])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-tglb3/igt@gem_exec_sched...@preempt-queue-vebox.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-tglb6/igt@gem_exec_sched...@preempt-queue-vebox.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][8] -> [FAIL][9] ([fdo#112392])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-glk8/igt@gem_pp...@flink-and-close-vma-leak.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-hsw:  [PASS][10] -> [DMESG-WARN][11] ([fdo#111870]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-hsw1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-hsw2/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][12] -> [FAIL][13] ([fdo#111830 ])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-iclb8/igt@i915_pm...@dc6-psr.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-iclb8/igt@i915_pm...@dc6-psr.html

  * igt@kms_big_fb@y-tiled-8bpp-rotate-180:
- shard-glk:  [PASS][14] -> [INCOMPLETE][15] ([fdo#103359] / 
[k.org#198133])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-glk9/igt@kms_big...@y-tiled-8bpp-rotate-180.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-glk9/igt@kms_big...@y-tiled-8bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl:  [PASS][16] -> [DMESG-WARN][17] ([fdo#108566]) +3 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl:  [PASS][18] -> [DMESG-WARN][19] ([fdo#108566]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-d-cursor-suspend:
- shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([fdo#111850])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7430/shard-tglb7/igt@kms_cursor_...@pipe-d-cursor-suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15459/shard-tglb1/igt@kms_cursor_...@pipe-d-cursor-suspend.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  

[Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.

The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.

Cc: Daniel Drake 
Cc: Paulo Zanoni 
Cc: Jian-Hong Pan 
Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index c976698b0729..928059a5da80 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc 
*crtc,
cache->fence_id = -1;
 }
 
+static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
+{
+   struct intel_fbc *fbc = _priv->fbc;
+
+   return intel_fbc_calculate_cfb_size(dev_priv, >state_cache) >
+   fbc->compressed_fb.size * fbc->threshold;
+}
+
 static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 * we didn't get any invalidate/deactivate calls, but this would require
 * a lot of tracking just for a specific case. If we conclude it's an
 * important case, we can implement it later. */
-   if (intel_fbc_calculate_cfb_size(dev_priv, >state_cache) >
-   fbc->compressed_fb.size * fbc->threshold) {
+   if (intel_fbc_cfb_size_changed(dev_priv)) {
fbc->no_fbc_reason = "CFB requirements changed";
return false;
}
@@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(>lock);
 
if (fbc->crtc) {
-   WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
-   goto out;
-   }
+   if (fbc->crtc != crtc ||
+   !intel_fbc_cfb_size_changed(dev_priv))
+   goto out;
 
-   if (!crtc_state->enable_fbc)
-   goto out;
+   __intel_fbc_disable(dev_priv);
+   }
 
WARN_ON(fbc->active);
 
@@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
if (intel_fbc_alloc_cfb(dev_priv,
intel_fbc_calculate_cfb_size(dev_priv, cache),
fb->format->cpp[0])) {
+   cache->plane.visible = false;
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 13/14] drm/i915/fbc: Enable fbc by default on glk+ once again

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.

Cc: Daniel Drake 
Cc: Paulo Zanoni 
Cc: Jian-Hong Pan 
Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 78fe4abb5a93..c976698b0729 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1288,10 +1288,6 @@ static int intel_sanitize_fbc_option(struct 
drm_i915_private *dev_priv)
if (!HAS_FBC(dev_priv))
return 0;
 
-   /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
-   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
-   return 0;
-
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
return 1;
 
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 10/14] drm/i915/fbc: Nuke fbc.enabled

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 23 +--
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 9a57ebc16c74..ccc1b5cc42d8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -840,7 +840,7 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
 
mutex_lock(>lock);
 
-   if (!fbc->enabled || fbc->crtc != crtc)
+   if (fbc->crtc != crtc)
goto unlock;
 
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
@@ -864,14 +864,13 @@ static void __intel_fbc_disable(struct drm_i915_private 
*dev_priv)
struct intel_crtc *crtc = fbc->crtc;
 
WARN_ON(!mutex_is_locked(>lock));
-   WARN_ON(!fbc->enabled);
+   WARN_ON(!fbc->crtc);
WARN_ON(fbc->active);
 
DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
 
__intel_fbc_cleanup_cfb(dev_priv);
 
-   fbc->enabled = false;
fbc->crtc = NULL;
 }
 
@@ -882,7 +881,7 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
 
WARN_ON(!mutex_is_locked(>lock));
 
-   if (!fbc->enabled || fbc->crtc != crtc)
+   if (fbc->crtc != crtc)
return;
 
fbc->flip_pending = false;
@@ -922,7 +921,7 @@ void intel_fbc_post_update(struct intel_crtc *crtc)
 
 static unsigned int intel_fbc_get_frontbuffer_bit(struct intel_fbc *fbc)
 {
-   if (fbc->enabled)
+   if (fbc->crtc)
return to_intel_plane(fbc->crtc->base.primary)->frontbuffer_bit;
else
return fbc->possible_framebuffer_bits;
@@ -944,7 +943,7 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
 
fbc->busy_bits |= intel_fbc_get_frontbuffer_bit(fbc) & frontbuffer_bits;
 
-   if (fbc->enabled && fbc->busy_bits)
+   if (fbc->crtc && fbc->busy_bits)
intel_fbc_deactivate(dev_priv, "frontbuffer write");
 
mutex_unlock(>lock);
@@ -965,7 +964,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
goto out;
 
-   if (!fbc->busy_bits && fbc->enabled &&
+   if (!fbc->busy_bits && fbc->crtc &&
(frontbuffer_bits & intel_fbc_get_frontbuffer_bit(fbc))) {
if (fbc->active)
intel_fbc_recompress(dev_priv);
@@ -1061,8 +1060,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
 
mutex_lock(>lock);
 
-   if (fbc->enabled) {
-   WARN_ON(fbc->crtc == NULL);
+   if (fbc->crtc) {
if (fbc->crtc == crtc) {
WARN_ON(!crtc_state->enable_fbc);
WARN_ON(fbc->active);
@@ -1074,7 +1072,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
 
WARN_ON(fbc->active);
-   WARN_ON(fbc->crtc != NULL);
 
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
 
@@ -1099,7 +1096,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
 
-   fbc->enabled = true;
fbc->crtc = crtc;
 out:
mutex_unlock(>lock);
@@ -1139,7 +1135,7 @@ void intel_fbc_global_disable(struct drm_i915_private 
*dev_priv)
return;
 
mutex_lock(>lock);
-   if (fbc->enabled) {
+   if (fbc->crtc) {
WARN_ON(fbc->crtc->active);
__intel_fbc_disable(dev_priv);
}
@@ -1155,7 +1151,7 @@ static void intel_fbc_underrun_work_fn(struct work_struct 
*work)
mutex_lock(>lock);
 
/* Maybe we were scheduled twice. */
-   if (fbc->underrun_detected || !fbc->enabled)
+   if (fbc->underrun_detected || !fbc->crtc)
goto out;
 
DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
@@ -1278,7 +1274,6 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
 
INIT_WORK(>underrun_work, intel_fbc_underrun_work_fn);
mutex_init(>lock);
-   fbc->enabled = false;
fbc->active = false;
 
if (!drm_mm_initialized(_priv->mm.stolen))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81556dc353b5..6fbfcaf4fb65 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -373,7 +373,6 @@ struct intel_fbc {
 
bool false_color;
 
-   bool enabled;
bool active;
bool flip_pending;
 
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 00/14] drm/i915/fbc: Fix FBC for glk+

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

CI got hopelessly confused with the v1 series so reposting in its
entirety.

I also slapped on an extra patch at the end which should hopefully
avoid the problems with FBC not getting enabled with fastboot.

Force pushed to
git://github.com/vsyrjala/linux.git glk_fbc_wa

Cc: Daniel Drake 
Cc: Paulo Zanoni 
Cc: Jian-Hong Pan 
Cc: Maarten Lankhorst 

Ville Syrjälä (14):
  drm/i915/fbc: Disable fbc by default on all glk+
  drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
  drm/i915: Relocate intel_crtc_active()
  drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
  drm/i915/fbc: Precompute gen9 cfb stride w/a
  drm/i915/fbc: Track plane visibility
  drm/i915/fbc: Store fence_id direction in fbc cache/params
  drm/i915/fbc: Make fence_id optional for i965gm
  drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
  drm/i915/fbc: Nuke fbc.enabled
  drm/i915/fbc: Start using flip nuke
  drm/i915/fbc: Wait for vblank after FBC disable on glk+
  drm/i915/fbc: Enable fbc by default on glk+ once again
  drm/i915/fbc: Reallocate cfb if we need more of it

 drivers/gpu/drm/i915/display/intel_display.c |  25 +-
 drivers/gpu/drm/i915/display/intel_display.h |   1 -
 drivers/gpu/drm/i915/display/intel_fbc.c | 274 ++-
 drivers/gpu/drm/i915/display/intel_fbc.h |   3 +-
 drivers/gpu/drm/i915/i915_drv.h  |  14 +-
 drivers/gpu/drm/i915/intel_pm.c  |  19 ++
 6 files changed, 169 insertions(+), 167 deletions(-)

-- 
2.23.0

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

[Intel-gfx] [PATCH v2 02/14] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.

v2: Nuke no_fbc_on_multiple_pipes() too

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 -
 drivers/gpu/drm/i915/display/intel_fbc.c | 52 
 drivers/gpu/drm/i915/display/intel_fbc.h |  1 -
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 4 files changed, 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 53dc310a5f6d..d4ca0bc4b260 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17869,8 +17869,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
 
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
-
-   intel_fbc_init_pipe_state(dev_priv);
 }
 
 void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 3cc1f4b4b5a3..2b64b172407d 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -50,11 +50,6 @@ static inline bool fbc_supported(struct drm_i915_private 
*dev_priv)
return HAS_FBC(dev_priv);
 }
 
-static inline bool no_fbc_on_multiple_pipes(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) <= 3;
-}
-
 /*
  * In some platforms where the CRTC's x:0/y:0 coordinates doesn't match the
  * frontbuffer's x:0/y:0 coordinates we lie to the hardware about the plane's
@@ -419,25 +414,6 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv,
fbc->no_fbc_reason = reason;
 }
 
-static bool multiple_pipes_ok(struct intel_crtc *crtc,
- struct intel_plane_state *plane_state)
-{
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_fbc *fbc = _priv->fbc;
-   enum pipe pipe = crtc->pipe;
-
-   /* Don't even bother tracking anything we don't need. */
-   if (!no_fbc_on_multiple_pipes(dev_priv))
-   return true;
-
-   if (plane_state->uapi.visible)
-   fbc->visible_pipes_mask |= (1 << pipe);
-   else
-   fbc->visible_pipes_mask &= ~(1 << pipe);
-
-   return (fbc->visible_pipes_mask & ~(1 << pipe)) != 0;
-}
-
 static int find_compression_threshold(struct drm_i915_private *dev_priv,
  struct drm_mm_node *node,
  int size,
@@ -867,18 +843,12 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
 
mutex_lock(>lock);
 
-   if (!multiple_pipes_ok(crtc, plane_state)) {
-   reason = "more than one pipe active";
-   goto deactivate;
-   }
-
if (!fbc->enabled || fbc->crtc != crtc)
goto unlock;
 
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
 
-deactivate:
intel_fbc_deactivate(dev_priv, reason);
 unlock:
mutex_unlock(>lock);
@@ -1244,28 +1214,6 @@ void intel_fbc_handle_fifo_underrun_irq(struct 
drm_i915_private *dev_priv)
schedule_work(>underrun_work);
 }
 
-/**
- * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
- * @dev_priv: i915 device instance
- *
- * The FBC code needs to track CRTC visibility since the older platforms can't
- * have FBC enabled while multiple pipes are used. This function does the
- * initial setup at driver load to make sure FBC is matching the real hardware.
- */
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv)
-{
-   struct intel_crtc *crtc;
-
-   /* Don't even bother tracking anything if we don't need. */
-   if (!no_fbc_on_multiple_pipes(dev_priv))
-   return;
-
-   for_each_intel_crtc(_priv->drm, crtc)
-   if (intel_crtc_active(crtc) &&
-   crtc->base.primary->state->visible)
-   dev_priv->fbc.visible_pipes_mask |= (1 << crtc->pipe);
-}
-
 /*
  * The DDX driver changes its behavior depending on the value it reads from
  * i915.enable_fbc, so sanitize it by translating the default value into either
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h 
b/drivers/gpu/drm/i915/display/intel_fbc.h
index 50272eda8d43..ba8eeefd4d9a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,6 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_plane_state *plane_state);
 void intel_fbc_post_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv);
 void intel_fbc_enable(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct intel_plane_state 

[Intel-gfx] [PATCH v2 03/14] drm/i915: Relocate intel_crtc_active()

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).

Reviewed-by: Lucas De Marchi 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 19 ---
 drivers/gpu/drm/i915/display/intel_display.h |  1 -
 drivers/gpu/drm/i915/intel_pm.c  | 19 +++
 3 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d4ca0bc4b260..d592b7284406 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1040,25 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state 
*crtc_state,
  NULL, best_clock);
 }
 
-bool intel_crtc_active(struct intel_crtc *crtc)
-{
-   /* Be paranoid as we can arrive here with only partial
-* state retrieved from the hardware during setup.
-*
-* We can ditch the adjusted_mode.crtc_clock check as soon
-* as Haswell has gained clock readout/fastboot support.
-*
-* We can ditch the crtc->primary->state->fb check as soon as we can
-* properly reconstruct framebuffers.
-*
-* FIXME: The intel_crtc->active here should be switched to
-* crtc->state->active once we have proper CRTC states wired up
-* for atomic.
-*/
-   return crtc->active && crtc->base.primary->state->fb &&
-   crtc->config->hw.adjusted_mode.crtc_clock;
-}
-
 enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
 enum pipe pipe)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index a5ec5eeff056..d18dc260fe83 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -558,7 +558,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
 int chv_calc_dpll_params(int refclk, struct dpll *pll_clock);
 
-bool intel_crtc_active(struct intel_crtc *crtc);
 bool hsw_crtc_state_ips_capable(const struct intel_crtc_state *crtc_state);
 void hsw_enable_ips(const struct intel_crtc_state *crtc_state);
 void hsw_disable_ips(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5aad9d49a528..eb54110119d6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -814,6 +814,25 @@ static bool intel_wm_plane_visible(const struct 
intel_crtc_state *crtc_state,
return plane_state->uapi.visible;
 }
 
+static bool intel_crtc_active(struct intel_crtc *crtc)
+{
+   /* Be paranoid as we can arrive here with only partial
+* state retrieved from the hardware during setup.
+*
+* We can ditch the adjusted_mode.crtc_clock check as soon
+* as Haswell has gained clock readout/fastboot support.
+*
+* We can ditch the crtc->primary->state->fb check as soon as we can
+* properly reconstruct framebuffers.
+*
+* FIXME: The intel_crtc->active here should be switched to
+* crtc->state->active once we have proper CRTC states wired up
+* for atomic.
+*/
+   return crtc->active && crtc->base.primary->state->fb &&
+   crtc->config->hw.adjusted_mode.crtc_clock;
+}
+
 static struct intel_crtc *single_enabled_crtc(struct drm_i915_private 
*dev_priv)
 {
struct intel_crtc *crtc, *enabled = NULL;
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 06/14] drm/i915/fbc: Track plane visibility

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 21 ++---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 6a32f1eaefeb..54ed1a74d02b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -634,8 +634,9 @@ static void intel_fbc_update_state_cache(struct intel_crtc 
*crtc,
struct intel_fbc_state_cache *cache = >state_cache;
struct drm_framebuffer *fb = plane_state->hw.fb;
 
-   cache->vma = NULL;
-   cache->flags = 0;
+   cache->plane.visible = plane_state->uapi.visible;
+   if (!cache->plane.visible)
+   return;
 
cache->crtc.mode_flags = crtc_state->hw.adjusted_mode.flags;
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
@@ -649,16 +650,12 @@ static void intel_fbc_update_state_cache(struct 
intel_crtc *crtc,
 */
cache->plane.src_w = drm_rect_width(_state->uapi.src) >> 16;
cache->plane.src_h = drm_rect_height(_state->uapi.src) >> 16;
-   cache->plane.visible = plane_state->uapi.visible;
cache->plane.adjusted_x = plane_state->color_plane[0].x;
cache->plane.adjusted_y = plane_state->color_plane[0].y;
cache->plane.y = plane_state->uapi.src.y1 >> 16;
 
cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
 
-   if (!cache->plane.visible)
-   return;
-
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
 
@@ -674,6 +671,11 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = _priv->fbc;
struct intel_fbc_state_cache *cache = >state_cache;
 
+   if (!cache->plane.visible) {
+   fbc->no_fbc_reason = "primary plane not visible";
+   return false;
+   }
+
/* We don't need to use a state cache here since this information is
 * global for all CRTC.
 */
@@ -682,11 +684,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
 
-   if (!cache->vma) {
-   fbc->no_fbc_reason = "primary plane not visible";
-   return false;
-   }
-
if (cache->crtc.mode_flags & DRM_MODE_FLAG_INTERLACE) {
fbc->no_fbc_reason = "incompatible mode";
return false;
@@ -820,6 +817,8 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
 
params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
+
+   params->plane_visible = cache->plane.visible;
 }
 
 void intel_fbc_pre_update(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccde7eaf7dab..82dafef9ae10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,6 +444,7 @@ struct intel_fbc {
 
int cfb_size;
u16 gen9_wa_cfb_stride;
+   bool plane_visible;
} params;
 
const char *no_fbc_reason;
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 01/14] drm/i915/fbc: Disable fbc by default on all glk+

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.

Cc: sta...@vger.kernel.org
Cc: Daniel Drake 
Cc: Paulo Zanoni 
Cc: Jian-Hong Pan 
Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 92c7eb243559..3cc1f4b4b5a3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1284,7 +1284,7 @@ static int intel_sanitize_fbc_option(struct 
drm_i915_private *dev_priv)
return 0;
 
/* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
-   if (IS_GEMINILAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
return 0;
 
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
-- 
2.23.0

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

[Intel-gfx] [PATCH v2 04/14] drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.

Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2b64b172407d..eefa5a88b304 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -248,8 +248,6 @@ static void ilk_fbc_activate(struct drm_i915_private 
*dev_priv)
}
 
I915_WRITE(ILK_DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
-   I915_WRITE(ILK_FBC_RT_BASE,
-  i915_ggtt_offset(params->vma) | ILK_FBC_RT_VALID);
/* enable it... */
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
 
-- 
2.23.0

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for video, drm: constify fbops in struct fb_info

2019-11-27 Thread Patchwork
== Series Details ==

Series: video, drm: constify fbops in struct fb_info
URL   : https://patchwork.freedesktop.org/series/70119/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a9312755bd82 video: fb_defio: preserve user fb_ops
-:93: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#93: FILE: include/linux/fb.h:662:
+extern int fb_deferred_io_init(struct fb_info *info);

total: 0 errors, 0 warnings, 1 checks, 63 lines checked
cf928543bfcb drm/fb-helper: don't preserve fb_ops across deferred IO use
e515c9d3f15d video: smscufx: don't restore fb_mmap after deferred IO cleanup
ad46cac3c0e3 video: udlfb: don't restore fb_mmap after deferred IO cleanup
460ff53fe566 video: fbdev: vesafb: modify the static fb_ops directly
05fc2b33565c video: fbmem: use const pointer for fb_ops
f0f669a03d49 video: omapfb: use const pointer for fb_ops
5fae561dc75e video: fbdev: make fbops member of struct fb_info a const pointer
74779cba2dfc drm: constify fb ops across all drivers
841a383b2ff8 video: constify fb ops across all drivers
c8ce711c9998 HID: picoLCD: constify fb ops
a7314310fb66 media: constify fb ops across all drivers
ea51beeaf182 samples: vfio-mdev: constify fb ops

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable second DBuf slice for ICL and TGL (rev2)

2019-11-27 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev2)
URL   : https://patchwork.freedesktop.org/series/70059/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15469


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#108569])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#109483])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([fdo#111045] / [fdo#111096])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-flip:
- fi-skl-6700k2:  [PASS][9] -> [DMESG-WARN][10] ([fdo#105541])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6700k2/igt@prime_v...@basic-fence-flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-skl-6700k2/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][11] ([fdo#112261]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3:  [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-icl-u3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [DMESG-FAIL][17] ([fdo#112147]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][20] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][22] ([fdo#103558] / [fdo#105602]) +6 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15469/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-kbl-x1275:   [DMESG-WARN][23] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][24] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [24]: 

Re: [Intel-gfx] [PATCH 3/7] drm/i915/tgl: Select master trasconder for MST stream

2019-11-27 Thread Ville Syrjälä
On Tue, Nov 26, 2019 at 08:30:31PM +, Souza, Jose wrote:
> On Tue, 2019-11-26 at 22:05 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:54:55PM -0800, José Roberto de Souza
> > wrote:
> > > On TGL the blending of all the streams have moved from DDI to
> > > transcoder, so now every transcoder working over the same MST port
> > > must
> > > send its stream to a master transcoder and master will send to DDI
> > > respecting the time slots.
> > > 
> > > A previous approach was using the lowest pipe/transcoder as master
> > > transcoder but as the comment in skl_commit_modeset_enables()
> > > states,
> > > that is not always true.
> > > 
> > > So here promoting the first pipe/transcoder of the stream as
> > > master.
> > > That caused several other problems as during the commit phase the
> > > state computed should not be changed.
> > > 
> > > So the master transcoder is store into intel_dp and the modeset in
> > > slave pipes/transcoders is forced using mst_master_trans_pending.
> > > 
> > > v2:
> > > - added missing config compute to trigger fullmodeset in slave
> > > transcoders
> > > 
> > > BSpec: 50493
> > > BSpec: 49190
> > > Cc: Ville Syrjälä 
> > > Cc: Lucas De Marchi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_ddi.c  |  10 +-
> > >  drivers/gpu/drm/i915/display/intel_display.c  |  58 ++-
> > >  .../drm/i915/display/intel_display_types.h|   3 +
> > >  drivers/gpu/drm/i915/display/intel_dp.c   |   1 +
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 149
> > > +-
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.h   |   2 +
> > >  6 files changed, 216 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index a976606d21c7..d2f0d393d3ee 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -35,6 +35,7 @@
> > >  #include "intel_display_types.h"
> > >  #include "intel_dp.h"
> > >  #include "intel_dp_link_training.h"
> > > +#include "intel_dp_mst.h"
> > >  #include "intel_dpio_phy.h"
> > >  #include "intel_dsi.h"
> > >  #include "intel_fifo_underrun.h"
> > > @@ -1903,8 +1904,13 @@ intel_ddi_transcoder_func_reg_val_get(const
> > > struct intel_crtc_state *crtc_state)
> > >   temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> > >   temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
> > >  
> > > - if (INTEL_GEN(dev_priv) >= 12)
> > > - temp |=
> > > TRANS_DDI_MST_TRANSPORT_SELECT(crtc_state->cpu_transcoder);
> > > + if (INTEL_GEN(dev_priv) >= 12) {
> > > + enum transcoder master;
> > > +
> > > + master =
> > > intel_dp_mst_master_trans_get(encoder);
> > 
> > Why isn't that just stored in the crtc state like everything else?
> > 
> > I'm thinking we should maybe do it just like port sync and have both
> > master + slave_mask. That way it should be pretty trivial to add all
> > the relevant crtcs to the state when needed.
> 
> I guess port sync is not doing the right thing and it could cause
> underruns.
> When it is going to enable the master CRTC of the port sync it forcibly
> enables the slave first, what could cause underruns because of overlap
> in ddb allocations(that is what I understood from the comment in
> skl_commit_modeset_enables()).

Not necessarily just underruns but even a system hang. The fix should be
a trivial "check the slave for ddb overlap as well", but apparently I
failed at convicing people to do that.

I've actually been pondering about decoupling the plane updates from
the crtc enable stuff entirely. At least theoretically crtc enable
should be able to excute in any order as long we don't enable any
new planes.

But none of that really matters for the discussion at hand. Though
there are other problems with the port sync stuff that would need
to be handled better. Eg. I think it now adds both crtcs to the state
always which is going to cut the fps in half. Also the place where
it does that stuff is rather suspicious. All that stuff should be
somewhere a bit higher up IMO.

> 
> So for MST we only know who is the master in the commit phase and at
> this point we should not modify the computed state.

I'm not suggesting modifying anything during commit phase. I think
you are effectiely doing that right now by stuffing that mst master
transcoder into intel_dp.

> 
> > 
> > > + WARN_ON(master == INVALID_TRANSCODER);
> > > + temp |= TRANS_DDI_MST_TRANSPORT_SELECT(master);
> > > + }
> > >   } else {
> > >   temp |= TRANS_DDI_MODE_SELECT_DP_SST;
> > >   temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 801b975c7d39..35a59108194e 100644
> > > --- 

Re: [Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support

2019-11-27 Thread Niranjan Vishwanathapura

On Tue, Nov 26, 2019 at 03:59:31PM +0200, Joonas Lahtinen wrote:

Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)

On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
>Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
>> Shared Virtual Memory (SVM) runtime allocator support allows
>> binding a shared virtual address to a buffer object (BO) in the
>> device page table through an ioctl call.
>
>The ioctl though is not svm specific, it is to do with "bulk residency"
>and can be used to reduce execbuf traffic to provide virtual address
>layout controls to e.g. Vulkan clients.
>
>I915_VM_BIND {
>   uint32_t vm_id;
>   int32_t fd; /* or -1 for anon, or buf depending on flags */
>   uint64_t flags;
>   uint64_t offset; /* offset info fd [page aligned] */
>   uint64_t length; /* page aligned */
>   uint64_t iova; /* page aligned */
>   uint64_t extensions;
>}; /* where page aligned is actually more I915_GTT_PAGE_ALIGNMENT */
>
>as I recall. I also recall it being part of a future command stream
>interface to reduce ioctls, but that is another story.

Thanks Chris.
I will change I915_BIND to I915_VM_BIND.


We're very much depending on GEM VM even if BOs wouldn't be used,
so this is best called I915_GEM_VM_BIND to match I915_GEM_VM_CREATE
and avoid user confusion.



Thanks Joonas.
Ok, makes sense. I will make it as such.


Currently, it is only addressing binding SVM system (buffer) and runtime (BOs)
allocations. But it can be expanded for other bindings. I have 'type' field
instead of 'fd' and 'extensions' & 'iov' can be added later if required.


We should try to have the uAPI as final as early as possible. The
change process is harder the later it is done, even for RFC :)

On the same note, I'm inclined to have I915_SVM_MIGRATE called
I915_GEM_VM_PREFAULT from the start, as I already have got some
confused questions from folks who mix it with memory pressure
initiated migration. And it's inherently racy as anybody could
race with it, so PREFAULT would give an impression of that.

And I think I915_GEM_VM_PREFAULT would be a generally applicable
function, just like I915_GEM_VM_BIND. So we should use a struct
member names that are close to I915_GEM_VM_BIND.

Better ideas for name to emphasis the nature of what is being
done? I915_GEM_VM_FAULT/I915_GEM_VM_{M,}ADVICE...



Though current patchset only supports migrating pages from
host to device memory, I intend to support migrating from device
to host memory as well with same ioctl. User would want that.
Not sure what would be a good name then, _MIGRATE/_PREFETCH/_MOVE?

Also, migrating gem objects is currently handled by separate ioctl
which is part of LMEM patch series. I am open to merging these
ioctls together (similart to VM_BIND) into a single MIGRATE ioctl.

Niranjana


Regards, Joonas


Is that OK?

>-Chris
___
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.SPARSE: warning for Enable second DBuf slice for ICL and TGL (rev2)

2019-11-27 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev2)
URL   : https://patchwork.freedesktop.org/series/70059/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Remove skl_ddl_allocation struct
Okay!

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915/dp: Power down sink before disable pipe/transcoder clock

2019-11-27 Thread Ville Syrjälä
On Tue, Nov 26, 2019 at 10:12:52PM +, Souza, Jose wrote:
> On Tue, 2019-11-26 at 22:15 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:54:56PM -0800, José Roberto de Souza
> > wrote:
> > > Disabling pipe/transcoder clock before power down sink could cause
> > > sink lost signal, causing it to trigger a hotplug to notify source
> > > that link signal was lost.
> > > 
> > > Cc: Lucas De Marchi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index d2f0d393d3ee..7d3a6e3c7f57 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -3808,12 +3808,12 @@ static void
> > > intel_ddi_post_disable_dp(struct intel_encoder *encoder,
> > >   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > >  
> > >   if (!is_mst) {
> > > - intel_ddi_disable_pipe_clock(old_crtc_state);
> > >   /*
> > >* Power down sink before disabling the port, otherwise
> > > we end
> > >* up getting interrupts from the sink on detecting
> > > link loss.
> > >*/
> > >   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > + intel_ddi_disable_pipe_clock(old_crtc_state);
> > >   }
> > 
> > The spec seems to say that we should do this after turning off
> > DDI_BUF_CTL on tgl+.
> 
> What step? I can't find any step talking about AUX DP_SET_POWER.

I was talking about DDI_BUF disable vs. transcoder clock disable.

> 
> My understating is that we should power off sink before interfering in
> the mainlink signal otherwise sink could trigger hotplugs to notify
> source about link loss.

Pretty much. Nothing wrong with your patch for pre-tgl I think, but for
tgl+ you didn't move the clock disable quite far enough to match the
bspec sequence.

> 
> > 
> > >  
> > >   intel_disable_ddi_buf(encoder, old_crtc_state);
> > > -- 
> > > 2.24.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/7] drm/i915/display: Refactor intel_commit_modeset_disables()

2019-11-27 Thread Ville Syrjälä
On Tue, Nov 26, 2019 at 10:03:08PM +, Souza, Jose wrote:
> On Tue, 2019-11-26 at 21:40 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:54:53PM -0800, José Roberto de Souza
> > wrote:
> > > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > > reverted the order that pipes gets disabled because of TGL
> > > master/slave relationship between transcoders in MST mode.
> > > 
> > > But as stated in a comment in skl_commit_modeset_enables() the
> > > enabling order is not always crescent, possibly causing previously
> > > selected slave transcoder being enabled before master so another
> > > approach will be needed to select a transcoder to master in MST
> > > mode.
> > > It will be similar to the approach taken in port sync.
> > > 
> > > But instead of implement something like
> > > intel_trans_port_sync_modeset_disables() to MST lets simply it and
> > > iterate over all pipes 2 times, the first one disabling any slave
> > > and
> > > then disabling everything else.
> > > The MST bits will be added in another patch.
> > > 
> > > Cc: Manasi Navare 
> > > Cc: Matt Roper 
> > > Cc: Maarten Lankhorst 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 79 ++
> > > --
> > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 53dc310a5f6d..1b1fbb6d8acc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -14443,53 +14443,16 @@ static void
> > > intel_old_crtc_state_disables(struct intel_atomic_state *state,
> > >   dev_priv->display.initial_watermarks(state, crtc);
> > >  }
> > >  
> > > -static void intel_trans_port_sync_modeset_disables(struct
> > > intel_atomic_state *state,
> > > -struct intel_crtc
> > > *crtc,
> > > -struct
> > > intel_crtc_state *old_crtc_state,
> > > -struct
> > > intel_crtc_state *new_crtc_state)
> > > -{
> > > - struct intel_crtc *slave_crtc =
> > > intel_get_slave_crtc(new_crtc_state);
> > > - struct intel_crtc_state *new_slave_crtc_state =
> > > - intel_atomic_get_new_crtc_state(state, slave_crtc);
> > > - struct intel_crtc_state *old_slave_crtc_state =
> > > - intel_atomic_get_old_crtc_state(state, slave_crtc);
> > > -
> > > - WARN_ON(!slave_crtc || !new_slave_crtc_state ||
> > > - !old_slave_crtc_state);
> > > -
> > > - /* Disable Slave first */
> > > - intel_pre_plane_update(old_slave_crtc_state,
> > > new_slave_crtc_state);
> > > - if (old_slave_crtc_state->hw.active)
> > > - intel_old_crtc_state_disables(state,
> > > -   old_slave_crtc_state,
> > > -   new_slave_crtc_state,
> > > -   slave_crtc);
> > > -
> > > - /* Disable Master */
> > > - intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > - if (old_crtc_state->hw.active)
> > > - intel_old_crtc_state_disables(state,
> > > -   old_crtc_state,
> > > -   new_crtc_state,
> > > -   crtc);
> > > -}
> > > -
> > >  static void intel_commit_modeset_disables(struct
> > > intel_atomic_state *state)
> > >  {
> > >   struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > >   struct intel_crtc *crtc;
> > >   int i;
> > >  
> > > - /*
> > > -  * Disable CRTC/pipes in reverse order because some
> > > features(MST in
> > > -  * TGL+) requires master and slave relationship between pipes,
> > > so it
> > > -  * should always pick the lowest pipe as master as it will be
> > > enabled
> > > -  * first and disable in the reverse order so the master will be
> > > the
> > > -  * last one to be disabled.
> > > -  */
> > > - for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> > > old_crtc_state,
> > > - new_crtc_state, i)
> > > {
> > > - if (!needs_modeset(new_crtc_state))
> > > + /* Only disable port sync slaves */
> > > + for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > old_crtc_state,
> > > + new_crtc_state, i) {
> > > + if (!needs_modeset(new_crtc_state) || !crtc->active)
> > 
> > What's the deal with these crtc->active checks?
> 
> With just one loop we were using "old_crtc_state->hw.active" but as we
> should not modify the computed state in this phase and
> intel_old_crtc_state_disables() sets crtc->active = false, using it
> instead.

You should never use it. We should aim towards eliminating it. I don't
think we're far off now.

> 
> > 
> > >   continue;
> > >  
> > >   /* In 

[Intel-gfx] [PATCH 6/7] drm/i915: Nuke intel_pre_disable_primary_noatomic()

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Let's just inline intel_pre_disable_primary_noatomic() into
intel_plane_disable_noatomic(). The CxSR disable we can do
regardless of which plane we're disabling, and while at it we can
make the gen2 underrun w/a accurate by consulting the active_planes
bitmask.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 57 
 1 file changed, 22 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5368f3ab70af..4377ee2eee56 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -171,7 +171,6 @@ static void ironlake_pfit_disable(const struct 
intel_crtc_state *old_crtc_state)
 static void ironlake_pfit_enable(const struct intel_crtc_state *crtc_state);
 static void intel_modeset_setup_hw_state(struct drm_device *dev,
 struct drm_modeset_acquire_ctx *ctx);
-static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
 
 struct intel_limit {
struct {
@@ -3212,6 +3211,7 @@ static void fixup_active_planes(struct intel_crtc_state 
*crtc_state)
 static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
 struct intel_plane *plane)
 {
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
struct intel_plane_state *plane_state =
@@ -3227,7 +3227,27 @@ static void intel_plane_disable_noatomic(struct 
intel_crtc *crtc,
crtc_state->min_cdclk[plane->id] = 0;
 
if (plane->id == PLANE_PRIMARY)
-   intel_pre_disable_primary_noatomic(>base);
+   hsw_disable_ips(crtc_state);
+
+   /*
+* Vblank time updates from the shadow to live plane control register
+* are blocked if the memory self-refresh mode is active at that
+* moment. So to make sure the plane gets truly disabled, disable
+* first the self-refresh mode. The self-refresh enable bit in turn
+* will be checked/applied by the HW only at the next frame start
+* event which is after the vblank start event, so we need to have a
+* wait-for-vblank between disabling the plane and the pipe.
+*/
+   if (HAS_GMCH(dev_priv) &&
+   intel_set_memory_cxsr(dev_priv, false))
+   intel_wait_for_vblank(dev_priv, crtc->pipe);
+
+   /*
+* Gen2 reports pipe underruns whenever all planes are disabled.
+* So disable underrun reporting before all the planes get disabled.
+*/
+   if (IS_GEN(dev_priv, 2) && !crtc_state->active_planes)
+   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, 
false);
 
intel_disable_plane(plane, crtc_state);
 }
@@ -5908,39 +5928,6 @@ static void intel_crtc_dpms_overlay_disable(struct 
intel_crtc *intel_crtc)
 */
 }
 
-
-/* FIXME get rid of this and use pre_plane_update */
-static void
-intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
-{
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
-
-   /*
-* Gen2 reports pipe underruns whenever all planes are disabled.
-* So disable underrun reporting before all the planes get disabled.
-*/
-   if (IS_GEN(dev_priv, 2))
-   intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
-
-   hsw_disable_ips(to_intel_crtc_state(crtc->state));
-
-   /*
-* Vblank time updates from the shadow to live plane control register
-* are blocked if the memory self-refresh mode is active at that
-* moment. So to make sure the plane gets truly disabled, disable
-* first the self-refresh mode. The self-refresh enable bit in turn
-* will be checked/applied by the HW only at the next frame start
-* event which is after the vblank start event, so we need to have a
-* wait-for-vblank between disabling the plane and the pipe.
-*/
-   if (HAS_GMCH(dev_priv) &&
-   intel_set_memory_cxsr(dev_priv, false))
-   intel_wait_for_vblank(dev_priv, pipe);
-}
-
 static bool hsw_pre_update_disable_ips(const struct intel_crtc_state 
*old_crtc_state,
   const struct intel_crtc_state 
*new_crtc_state)
 {
-- 
2.23.0

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

[Intel-gfx] [PATCH 4/7] drm/i915: Clean up intel_{pre, post}_plane_update()

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Change the calling convention to just pass the state+crtc and
switch to intel_ types throughout.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 88 +---
 drivers/gpu/drm/i915/display/intel_fbc.c | 14 ++--
 drivers/gpu/drm/i915/display/intel_fbc.h |  8 +-
 3 files changed, 51 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e341b97b7dec..72655b5b1365 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5920,13 +5920,10 @@ static void intel_crtc_dpms_overlay_disable(struct 
intel_crtc *intel_crtc)
  * completely hide the primary plane.
  */
 static void
-intel_post_enable_primary(struct drm_crtc *crtc,
- const struct intel_crtc_state *new_crtc_state)
+intel_post_enable_primary(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
 
/*
 * Gen2 reports pipe underruns whenever all planes are disabled.
@@ -6062,20 +6059,21 @@ static bool needs_scalerclk_wa(const struct 
intel_crtc_state *crtc_state)
return false;
 }
 
-static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
+static void intel_post_plane_update(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_atomic_state *state = old_crtc_state->uapi.state;
-   struct intel_crtc_state *new_crtc_state =
-   intel_atomic_get_new_crtc_state(to_intel_atomic_state(state),
-   crtc);
-   struct drm_plane *primary = crtc->base.primary;
-   struct drm_plane_state *old_primary_state =
-   drm_atomic_get_old_plane_state(state, primary);
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   struct intel_plane *primary = to_intel_plane(crtc->base.primary);
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   const struct intel_plane_state *old_primary_state =
+   intel_atomic_get_old_plane_state(state, primary);
+   const struct intel_plane_state *new_primary_state =
+   intel_atomic_get_new_plane_state(state, primary);
 
-   intel_frontbuffer_flip(to_i915(crtc->base.dev), 
new_crtc_state->fb_bits);
+   intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
 
if (new_crtc_state->update_wm_post && new_crtc_state->hw.active)
intel_update_watermarks(crtc);
@@ -6083,16 +6081,13 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
hsw_enable_ips(new_crtc_state);
 
-   if (old_primary_state) {
-   struct drm_plane_state *new_primary_state =
-   drm_atomic_get_new_plane_state(state, primary);
-
+   if (new_primary_state) {
intel_fbc_post_update(crtc);
 
-   if (new_primary_state->visible &&
+   if (new_primary_state->uapi.visible &&
(needs_modeset(new_crtc_state) ||
-!old_primary_state->visible))
-   intel_post_enable_primary(>base, new_crtc_state);
+!old_primary_state->uapi.visible))
+   intel_post_enable_primary(crtc);
}
 
if (needs_nv12_wa(old_crtc_state) &&
@@ -6104,34 +6099,31 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
 }
 
-static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
-  struct intel_crtc_state *new_crtc_state)
+static void intel_pre_plane_update(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_atomic_state *state = old_crtc_state->uapi.state;
-   struct drm_plane *primary = crtc->base.primary;
-   struct drm_plane_state *old_primary_state =
-   

[Intel-gfx] [PATCH 2/7] drm/i915: Pass dev_priv to ilk_disable_lp_wm()

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Get rid of another 'dev' usage by passing dev_priv instead.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 4 +---
 drivers/gpu/drm/i915/intel_pm.h  | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index d559b7ae1151..89c8f818f289 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6166,7 +6166,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 *
 * WaCxSRDisabledForSpriteScaling:ivb
 */
-   if (pipe_config->disable_lp_wm && ilk_disable_lp_wm(dev) &&
+   if (pipe_config->disable_lp_wm && ilk_disable_lp_wm(dev_priv) &&
old_crtc_state->hw.active)
intel_wait_for_vblank(dev_priv, crtc->pipe);
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5aad9d49a528..8d63672452a9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3592,10 +3592,8 @@ static void ilk_write_wm_values(struct drm_i915_private 
*dev_priv,
dev_priv->wm.hw = *results;
 }
 
-bool ilk_disable_lp_wm(struct drm_device *dev)
+bool ilk_disable_lp_wm(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
index b579c724b915..c06c6a846d9a 100644
--- a/drivers/gpu/drm/i915/intel_pm.h
+++ b/drivers/gpu/drm/i915/intel_pm.h
@@ -54,7 +54,7 @@ void skl_write_plane_wm(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state);
 void skl_write_cursor_wm(struct intel_plane *plane,
 const struct intel_crtc_state *crtc_state);
-bool ilk_disable_lp_wm(struct drm_device *dev);
+bool ilk_disable_lp_wm(struct drm_i915_private *dev_priv);
 void intel_init_ipc(struct drm_i915_private *dev_priv);
 void intel_enable_ipc(struct drm_i915_private *dev_priv);
 
-- 
2.23.0

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

[Intel-gfx] [PATCH 5/7] drm/i915: Clean up the gen2 "no planes -> underrun" workaround

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

We have the active_planes bitmask now so use it to properly
determine when some planes are visible for the gen2 underrun
workaround.

This let's us almost eliminate intel_post_enable_primary().
The manual underrun checks we can simply move into
intel_atomic_commit_tail() since they loop over all the pipes
already. No point in repeating the checks multiple times when
there are multiple pipes in the commit.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 155 +--
 1 file changed, 70 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 72655b5b1365..5368f3ab70af 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5908,37 +5908,6 @@ static void intel_crtc_dpms_overlay_disable(struct 
intel_crtc *intel_crtc)
 */
 }
 
-/**
- * intel_post_enable_primary - Perform operations after enabling primary plane
- * @crtc: the CRTC whose primary plane was just enabled
- * @new_crtc_state: the enabling state
- *
- * Performs potentially sleeping operations that must be done after the primary
- * plane is enabled, such as updating FBC and IPS.  Note that this may be
- * called due to an explicit primary plane update, or due to an implicit
- * re-enable that is caused when a sprite plane is updated to no longer
- * completely hide the primary plane.
- */
-static void
-intel_post_enable_primary(struct intel_crtc *crtc)
-{
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum pipe pipe = crtc->pipe;
-
-   /*
-* Gen2 reports pipe underruns whenever all planes are disabled.
-* So don't enable underrun reporting before at least some planes
-* are enabled.
-* FIXME: Need to fix the logic to work when we turn off all planes
-* but leave the pipe running.
-*/
-   if (IS_GEN(dev_priv, 2))
-   intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
-
-   /* Underruns don't always raise interrupts, so check manually. */
-   intel_check_cpu_fifo_underruns(dev_priv);
-   intel_check_pch_fifo_underruns(dev_priv);
-}
 
 /* FIXME get rid of this and use pre_plane_update */
 static void
@@ -6059,6 +6028,20 @@ static bool needs_scalerclk_wa(const struct 
intel_crtc_state *crtc_state)
return false;
 }
 
+static bool planes_enabling(const struct intel_crtc_state *old_crtc_state,
+   const struct intel_crtc_state *new_crtc_state)
+{
+   return (!old_crtc_state->active_planes || 
needs_modeset(new_crtc_state)) &&
+   new_crtc_state->active_planes;
+}
+
+static bool planes_disabling(const struct intel_crtc_state *old_crtc_state,
+const struct intel_crtc_state *new_crtc_state)
+{
+   return old_crtc_state->active_planes &&
+   (!new_crtc_state->active_planes || 
needs_modeset(new_crtc_state));
+}
+
 static void intel_post_plane_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
 {
@@ -6068,10 +6051,9 @@ static void intel_post_plane_update(struct 
intel_atomic_state *state,
intel_atomic_get_old_crtc_state(state, crtc);
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
-   const struct intel_plane_state *old_primary_state =
-   intel_atomic_get_old_plane_state(state, primary);
const struct intel_plane_state *new_primary_state =
intel_atomic_get_new_plane_state(state, primary);
+   enum pipe pipe = crtc->pipe;
 
intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
 
@@ -6081,22 +6063,16 @@ static void intel_post_plane_update(struct 
intel_atomic_state *state,
if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
hsw_enable_ips(new_crtc_state);
 
-   if (new_primary_state) {
+   if (new_primary_state)
intel_fbc_post_update(crtc);
 
-   if (new_primary_state->uapi.visible &&
-   (needs_modeset(new_crtc_state) ||
-!old_primary_state->uapi.visible))
-   intel_post_enable_primary(crtc);
-   }
-
if (needs_nv12_wa(old_crtc_state) &&
!needs_nv12_wa(new_crtc_state))
-   skl_wa_827(dev_priv, crtc->pipe, false);
+   skl_wa_827(dev_priv, pipe, false);
 
if (needs_scalerclk_wa(old_crtc_state) &&
!needs_scalerclk_wa(new_crtc_state))
-   icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
+   icl_wa_scalerclkgating(dev_priv, pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_atomic_state *state,
@@ -6108,35 +6084,25 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,

[Intel-gfx] [PATCH 3/7] drm/i915: s/pipe_config/new_crtc_state/ intel_{pre, post}_plane_update()

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the old world 'pipe_config' variable name with the new thing.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 89c8f818f289..e341b97b7dec 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6068,20 +6068,20 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_atomic_state *state = old_crtc_state->uapi.state;
-   struct intel_crtc_state *pipe_config =
+   struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(to_intel_atomic_state(state),
crtc);
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_primary_state =
drm_atomic_get_old_plane_state(state, primary);
 
-   intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config->fb_bits);
+   intel_frontbuffer_flip(to_i915(crtc->base.dev), 
new_crtc_state->fb_bits);
 
-   if (pipe_config->update_wm_post && pipe_config->hw.active)
+   if (new_crtc_state->update_wm_post && new_crtc_state->hw.active)
intel_update_watermarks(crtc);
 
-   if (hsw_post_update_enable_ips(old_crtc_state, pipe_config))
-   hsw_enable_ips(pipe_config);
+   if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
+   hsw_enable_ips(new_crtc_state);
 
if (old_primary_state) {
struct drm_plane_state *new_primary_state =
@@ -6090,22 +6090,22 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
intel_fbc_post_update(crtc);
 
if (new_primary_state->visible &&
-   (needs_modeset(pipe_config) ||
+   (needs_modeset(new_crtc_state) ||
 !old_primary_state->visible))
-   intel_post_enable_primary(>base, pipe_config);
+   intel_post_enable_primary(>base, new_crtc_state);
}
 
if (needs_nv12_wa(old_crtc_state) &&
-   !needs_nv12_wa(pipe_config))
+   !needs_nv12_wa(new_crtc_state))
skl_wa_827(dev_priv, crtc->pipe, false);
 
if (needs_scalerclk_wa(old_crtc_state) &&
-   !needs_scalerclk_wa(pipe_config))
+   !needs_scalerclk_wa(new_crtc_state))
icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
-  struct intel_crtc_state *pipe_config)
+  struct intel_crtc_state *new_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
struct drm_device *dev = crtc->base.dev;
@@ -6114,11 +6114,11 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_primary_state =
drm_atomic_get_old_plane_state(state, primary);
-   bool modeset = needs_modeset(pipe_config);
+   bool modeset = needs_modeset(new_crtc_state);
struct intel_atomic_state *intel_state =
to_intel_atomic_state(state);
 
-   if (hsw_pre_update_disable_ips(old_crtc_state, pipe_config))
+   if (hsw_pre_update_disable_ips(old_crtc_state, new_crtc_state))
hsw_disable_ips(old_crtc_state);
 
if (old_primary_state) {
@@ -6126,7 +6126,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
 
to_intel_plane(primary));
 
-   intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+   intel_fbc_pre_update(crtc, new_crtc_state, new_primary_state);
/*
 * Gen2 reports pipe underruns whenever all planes are disabled.
 * So disable underrun reporting before all the planes get 
disabled.
@@ -6138,12 +6138,12 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 
/* Display WA 827 */
if (!needs_nv12_wa(old_crtc_state) &&
-   needs_nv12_wa(pipe_config))
+   needs_nv12_wa(new_crtc_state))
skl_wa_827(dev_priv, crtc->pipe, true);
 
/* Wa_2006604312:icl */
if (!needs_scalerclk_wa(old_crtc_state) &&
-   needs_scalerclk_wa(pipe_config))
+   needs_scalerclk_wa(new_crtc_state))
icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
 
 

[Intel-gfx] [PATCH 7/7] drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Assuming intel_crtc_arm_fifo_underrun() only gets called when
there's no pending plane updates we can utilize it on gen2 by
checking the active_planes bitmask so that we only re-enable
underrun reporting if some planes are active.
i915_fifo_underrun_reset_write() seems to have the necessary
hw_done/flip_done waits in place.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 4377ee2eee56..ec363972e0ac 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14221,7 +14221,7 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc 
*crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
-   if (!IS_GEN(dev_priv, 2))
+   if (!IS_GEN(dev_priv, 2) || crtc_state->active_planes)
intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, 
true);
 
if (crtc_state->has_pch_encoder) {
-- 
2.23.0

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

[Intel-gfx] [PATCH 0/7] drm/i915: Cleanups around pre/post plane update

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

I was poking around the fbc stuff and again stumbled on the
mess in intel_{pre,post}_plane_update(), so I proceeded to
clean it up a bit.

Ville Syrjälä (7):
  drm/i915: Clean up arguments to nv12/scaler w/a funcs
  drm/i915: Pass dev_priv to ilk_disable_lp_wm()
  drm/i915: s/pipe_config/new_crtc_state/
intel_{pre,post}_plane_update()
  drm/i915: Clean up intel_{pre,post}_plane_update()
  drm/i915: Clean up the gen2 "no planes -> underrun" workaround
  drm/i915: Nuke intel_pre_disable_primary_noatomic()
  drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2

 drivers/gpu/drm/i915/display/intel_display.c | 316 +--
 drivers/gpu/drm/i915/display/intel_fbc.c |  14 +-
 drivers/gpu/drm/i915/display/intel_fbc.h |   8 +-
 drivers/gpu/drm/i915/intel_pm.c  |   4 +-
 drivers/gpu/drm/i915/intel_pm.h  |   2 +-
 5 files changed, 154 insertions(+), 190 deletions(-)

-- 
2.23.0

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

[Intel-gfx] [PATCH 1/7] drm/i915: Clean up arguments to nv12/scaler w/a funcs

2019-11-27 Thread Ville Syrjala
From: Ville Syrjälä 

Don't pass the redundant dev_priv to needs_nv12_wa() and
needs_scalerclk_wa().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 26 +++-
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 53dc310a5f6d..d559b7ae1151 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6037,9 +6037,10 @@ static bool hsw_post_update_enable_ips(const struct 
intel_crtc_state *old_crtc_s
return !old_crtc_state->ips_enabled;
 }
 
-static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state)
+static bool needs_nv12_wa(const struct intel_crtc_state *crtc_state)
 {
+   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
if (!crtc_state->nv12_planes)
return false;
 
@@ -6050,9 +6051,10 @@ static bool needs_nv12_wa(struct drm_i915_private 
*dev_priv,
return false;
 }
 
-static bool needs_scalerclk_wa(struct drm_i915_private *dev_priv,
-  const struct intel_crtc_state *crtc_state)
+static bool needs_scalerclk_wa(const struct intel_crtc_state *crtc_state)
 {
+   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
/* Wa_2006604312:icl */
if (crtc_state->scaler_state.scaler_users > 0 && IS_ICELAKE(dev_priv))
return true;
@@ -6093,12 +6095,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
intel_post_enable_primary(>base, pipe_config);
}
 
-   if (needs_nv12_wa(dev_priv, old_crtc_state) &&
-   !needs_nv12_wa(dev_priv, pipe_config))
+   if (needs_nv12_wa(old_crtc_state) &&
+   !needs_nv12_wa(pipe_config))
skl_wa_827(dev_priv, crtc->pipe, false);
 
-   if (needs_scalerclk_wa(dev_priv, old_crtc_state) &&
-   !needs_scalerclk_wa(dev_priv, pipe_config))
+   if (needs_scalerclk_wa(old_crtc_state) &&
+   !needs_scalerclk_wa(pipe_config))
icl_wa_scalerclkgating(dev_priv, crtc->pipe, false);
 }
 
@@ -6135,13 +6137,13 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
}
 
/* Display WA 827 */
-   if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
-   needs_nv12_wa(dev_priv, pipe_config))
+   if (!needs_nv12_wa(old_crtc_state) &&
+   needs_nv12_wa(pipe_config))
skl_wa_827(dev_priv, crtc->pipe, true);
 
/* Wa_2006604312:icl */
-   if (!needs_scalerclk_wa(dev_priv, old_crtc_state) &&
-   needs_scalerclk_wa(dev_priv, pipe_config))
+   if (!needs_scalerclk_wa(old_crtc_state) &&
+   needs_scalerclk_wa(pipe_config))
icl_wa_scalerclkgating(dev_priv, crtc->pipe, true);
 
/*
-- 
2.23.0

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/tgl: Do not program clockgating

2019-11-27 Thread Souza, Jose
On Wed, 2019-11-27 at 11:11 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/display/tgl: Do not program clockgating
> URL   : https://patchwork.freedesktop.org/series/70076/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7426_full -> Patchwork_15450_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_15450_full absolutely
> need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the
> changes
>   introduced in Patchwork_15450_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_15450_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_big_fb@y-tiled-8bpp-rotate-180:
> - shard-skl:  [PASS][1] -> [INCOMPLETE][2] +1 similar
> issue
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-skl10/igt@kms_big...@y-tiled-8bpp-rotate-180.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-skl3/igt@kms_big...@y-tiled-8bpp-rotate-180.html


This changes are not affecting SKL, SKL don't have native TC ports so
it will always return in "if (tc_port == PORT_TC_NONE)"

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_15450_full that come from
> known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@rcs0-s3:
> - shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html
> 
>   * igt@gem_exec_create@forked:
> - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#108838]
> / [fdo#111747])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-tglb1/igt@gem_exec_cre...@forked.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-tglb3/igt@gem_exec_cre...@forked.html
> 
>   * igt@gem_exec_parallel@fds:
> - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111867])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-tglb4/igt@gem_exec_paral...@fds.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-tglb6/igt@gem_exec_paral...@fds.html
> 
>   * igt@gem_mmap_gtt@hang:
> - shard-snb:  [PASS][9] -> [INCOMPLETE][10]
> ([fdo#105411])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-snb2/igt@gem_mmap_...@hang.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-snb7/igt@gem_mmap_...@hang.html
> 
>   * igt@gem_ppgtt@flink-and-close-vma-leak:
> - shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#112392])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-glk2/igt@gem_pp...@flink-and-close-vma-leak.html
> - shard-apl:  [PASS][13] -> [FAIL][14] ([fdo#112392])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-apl4/igt@gem_pp...@flink-and-close-vma-leak.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html
> 
>   * igt@gem_softpin@noreloc-s3:
> - shard-skl:  [PASS][15] -> [INCOMPLETE][16]
> ([fdo#104108])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-skl4/igt@gem_soft...@noreloc-s3.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-skl5/igt@gem_soft...@noreloc-s3.html
> 
>   * igt@gem_userptr_blits@sync-unmap-after-close:
> - shard-hsw:  [PASS][17] -> [DMESG-WARN][18]
> ([fdo#111870]) +1 similar issue
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-hsw8/igt@gem_userptr_bl...@sync-unmap-after-close.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-hsw6/igt@gem_userptr_bl...@sync-unmap-after-close.html
> - shard-snb:  [PASS][19] -> [DMESG-WARN][20]
> ([fdo#110789] / [fdo#111870])
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7426/shard-snb1/igt@gem_userptr_bl...@sync-unmap-after-close.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15450/shard-snb1/igt@gem_userptr_bl...@sync-unmap-after-close.html
> 
>   * igt@kms_big_fb@x-tiled-16bpp-rotate-180:
> - shard-skl:  [PASS][21] -> [INCOMPLETE][22]
> ([fdo#112409])
>[21]: 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for adding gamma state checker for icl+ platforms (rev7)

2019-11-27 Thread Patchwork
== Series Details ==

Series: adding gamma state checker for icl+ platforms (rev7)
URL   : https://patchwork.freedesktop.org/series/66811/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7432 -> Patchwork_15468


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2] ([fdo#112261])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#106070] / 
[fdo#111700])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([fdo#109483] / [fdo#109635 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][11] ([fdo#102614]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2:  [FAIL][13] ([fdo#103167]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u2:  [INCOMPLETE][17] ([fdo#107713]) -> [DMESG-WARN][18] 
([fdo#110595])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-icl-u2/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-icl-u2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][20] ([fdo#103558] / [fdo#105602]) +8 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][22] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15468/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

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

  

Re: [Intel-gfx] [PATCH 1/7] drm/i915/display: Refactor intel_commit_modeset_disables()

2019-11-27 Thread Lucas De Marchi

On Tue, Nov 26, 2019 at 02:49:47PM -0800, Matt Roper wrote:

On Tue, Nov 26, 2019 at 02:03:08PM -0800, Souza, Jose wrote:

On Tue, 2019-11-26 at 21:40 +0200, Ville Syrjälä wrote:
> On Fri, Nov 22, 2019 at 04:54:53PM -0800, José Roberto de Souza
> wrote:
> > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > reverted the order that pipes gets disabled because of TGL
> > master/slave relationship between transcoders in MST mode.
> >
> > But as stated in a comment in skl_commit_modeset_enables() the
> > enabling order is not always crescent, possibly causing previously
> > selected slave transcoder being enabled before master so another
> > approach will be needed to select a transcoder to master in MST
> > mode.
> > It will be similar to the approach taken in port sync.
> >
> > But instead of implement something like
> > intel_trans_port_sync_modeset_disables() to MST lets simply it and
> > iterate over all pipes 2 times, the first one disabling any slave
> > and
> > then disabling everything else.
> > The MST bits will be added in another patch.
> >
> > Cc: Manasi Navare 
> > Cc: Matt Roper 
> > Cc: Maarten Lankhorst 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 79 ++
> > --
> >  1 file changed, 22 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 53dc310a5f6d..1b1fbb6d8acc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -14443,53 +14443,16 @@ static void
> > intel_old_crtc_state_disables(struct intel_atomic_state *state,
> >   dev_priv->display.initial_watermarks(state, crtc);
> >  }
> >
> > -static void intel_trans_port_sync_modeset_disables(struct
> > intel_atomic_state *state,
> > -struct intel_crtc
> > *crtc,
> > -struct
> > intel_crtc_state *old_crtc_state,
> > -struct
> > intel_crtc_state *new_crtc_state)
> > -{
> > - struct intel_crtc *slave_crtc =
> > intel_get_slave_crtc(new_crtc_state);
> > - struct intel_crtc_state *new_slave_crtc_state =
> > - intel_atomic_get_new_crtc_state(state, slave_crtc);
> > - struct intel_crtc_state *old_slave_crtc_state =
> > - intel_atomic_get_old_crtc_state(state, slave_crtc);
> > -
> > - WARN_ON(!slave_crtc || !new_slave_crtc_state ||
> > - !old_slave_crtc_state);
> > -
> > - /* Disable Slave first */
> > - intel_pre_plane_update(old_slave_crtc_state,
> > new_slave_crtc_state);
> > - if (old_slave_crtc_state->hw.active)
> > - intel_old_crtc_state_disables(state,
> > -   old_slave_crtc_state,
> > -   new_slave_crtc_state,
> > -   slave_crtc);
> > -
> > - /* Disable Master */
> > - intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > - if (old_crtc_state->hw.active)
> > - intel_old_crtc_state_disables(state,
> > -   old_crtc_state,
> > -   new_crtc_state,
> > -   crtc);
> > -}
> > -
> >  static void intel_commit_modeset_disables(struct
> > intel_atomic_state *state)
> >  {
> >   struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> >   struct intel_crtc *crtc;
> >   int i;
> >
> > - /*
> > -  * Disable CRTC/pipes in reverse order because some
> > features(MST in
> > -  * TGL+) requires master and slave relationship between pipes,
> > so it
> > -  * should always pick the lowest pipe as master as it will be
> > enabled
> > -  * first and disable in the reverse order so the master will be
> > the
> > -  * last one to be disabled.
> > -  */
> > - for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> > old_crtc_state,
> > - new_crtc_state, i)
> > {
> > - if (!needs_modeset(new_crtc_state))
> > + /* Only disable port sync slaves */
> > + for_each_oldnew_intel_crtc_in_state(state, crtc,
> > old_crtc_state,
> > + new_crtc_state, i) {
> > + if (!needs_modeset(new_crtc_state) || !crtc->active)
>
> What's the deal with these crtc->active checks?

With just one loop we were using "old_crtc_state->hw.active" but as we
should not modify the computed state in this phase and
intel_old_crtc_state_disables() sets crtc->active = false, using it
instead.


I don't think we want to be using intel_crtc->active for anything new if
we can help it.  We have to keep that field around right now to support
some of our ancient platforms 

Re: [Intel-gfx] [PATCH] drm/i915/display: Suspend MST topology manager before destroy fbdev

2019-11-27 Thread Lucas De Marchi

On Tue, Nov 26, 2019 at 06:16:09PM -0800, Jose Souza wrote:

MST do topology probe in threads, so this running threads needs to be
flushed before fbdev is destroyed as when a new MST node is found it
calls drm_kms_helper_hotplug_event() that calls fbdev functions

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964
Signed-off-by: José Roberto de Souza 
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f2770951459..372dd48691cf 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17989,6 +17989,13 @@ void intel_modeset_driver_remove(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);

+   /*
+* MST do topology probe in threads, so this running threads needs to
+* be flushed before fbdev is destroyed as when a new MST node is found
+* it call drm_kms_helper_hotplug_event() that calls fbdev functions
+*/


this would normally be part of drm_mode_config_cleanup() in which the
encoders will be destroyed, together with their mst_mgr via 
drm_dp_mst_topology_mgr_destroy()


So I think the comment should actually mention why
drm_mode_config_cleanup() can't be done before or just state where it
will actually be destroyed. So... I guess something like:

/*
 * MST topology needs to be suspended so we don't have any calls to
 * fbdev after it's finalized. MST will be destroyed later as part of
 * drm_mode_config_cleanup()
 */

Of course, if we can figure out a better ordering to peel the onion
would be better, but I think this is sufficient.

With the comment update,


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


+   intel_dp_mst_suspend(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);

--
2.24.0

___
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/13] samples: vfio-mdev: constify fb ops

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:32:09PM +0200, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can star making
> the ops const as well.
> 
> Cc: Kirti Wankhede 
> Cc: k...@vger.kernel.org
> Signed-off-by: Jani Nikula 

You've missed at least drivers/staging/fbtft in your search. I guess you
need to do a full make allyesconfig on x86/arm and arm64 (the latter
because some stupid drivers only compile there, not on arm, don't ask).
Still misses a pile of mips/ppc only stuff and maybe the sparcs and
alphas, but should be good enough.

With that done, on the remaining patches:

Reviewed-by: Daniel Vetter 

> ---
>  samples/vfio-mdev/mdpy-fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
> index 2719bb259653..21dbf63d6e41 100644
> --- a/samples/vfio-mdev/mdpy-fb.c
> +++ b/samples/vfio-mdev/mdpy-fb.c
> @@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
>   iounmap(info->screen_base);
>  }
>  
> -static struct fb_ops mdpy_fb_ops = {
> +static const struct fb_ops mdpy_fb_ops = {
>   .owner  = THIS_MODULE,
>   .fb_destroy = mdpy_fb_destroy,
>   .fb_setcolreg   = mdpy_fb_setcolreg,
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 05/13] video: fbdev: vesafb: modify the static fb_ops directly

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:32:01PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
> 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/vesafb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index d9c08f6c2155..a1fe24ea869b 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -447,15 +447,15 @@ static int vesafb_probe(struct platform_device *dev)
>  vesafb_fix.smem_start, info->screen_base,
>  size_remap/1024, size_total/1024);
>  
> + if (!ypan)
> + vesafb_ops.fb_pan_display = NULL;

vesafb at least has a guarantee that there's only ever one ...

Reviewed-by: Daniel Vetter 
> +
>   info->fbops = _ops;
>   info->var = vesafb_defined;
>   info->fix = vesafb_fix;
>   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
>   (ypan ? FBINFO_HWACCEL_YPAN : 0);
>  
> - if (!ypan)
> - info->fbops->fb_pan_display = NULL;
> -
>   if (fb_alloc_cmap(>cmap, 256, 0) < 0) {
>   err = -ENOMEM;
>   goto err;
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 04/13] video: udlfb: don't restore fb_mmap after deferred IO cleanup

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:32:00PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
> 
> Cc: Bernie Thompson 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Daniel Vetter 

Aside: I wonder whether we should start retiring all the fbdev drivers
which have kms drivers already ... you get fbdev for free with the latter.
-Daniel

> ---
>  drivers/video/fbdev/udlfb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
> index fe373b63ddd6..07905d385949 100644
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1037,7 +1037,6 @@ static int dlfb_ops_release(struct fb_info *info, int 
> user)
>   fb_deferred_io_cleanup(info);
>   kfree(info->fbdefio);
>   info->fbdefio = NULL;
> - info->fbops->fb_mmap = dlfb_ops_mmap;
>   }
>  
>   dev_dbg(info->dev, "release, user=%d count=%d\n", user, dlfb->fb_count);
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [CI] drm/i915/gen7: Re-enable full-ppgtt for ivb, byt, hsw

2019-11-27 Thread Chris Wilson
After much hair pulling, resort to preallocating the ppGTT entries on
init to circumvent the apparent lack of PD invalidate following the
write to PP_DCLV upon switching mm between contexts (and here the same
context after binding new objects). However, the details of that PP_DCLV
invalidate are still unknown, and it appears we need to reload the mm
twice to cover over a timing issue. Worrying.

Fixes: 3dc007fe9b2b ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to 
aliasing-ppgtt")
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 29 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 12 
 drivers/gpu/drm/i915/i915_pci.c   |  4 +--
 3 files changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f25ceccb335e..9b1047df16ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1366,13 +1366,15 @@ static int load_pd_dir(struct i915_request *rq, const 
struct i915_ppgtt *ppgtt)
const struct intel_engine_cs * const engine = rq->engine;
u32 *cs;
 
-   cs = intel_ring_begin(rq, 6);
+   cs = intel_ring_begin(rq, 8);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   *cs++ = MI_LOAD_REGISTER_IMM(1);
+   *cs++ = MI_LOAD_REGISTER_IMM(2);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base));
*cs++ = PP_DIR_DCLV_2G;
+   *cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base)) + 4;
+   *cs++ = 0;
 
*cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
@@ -1579,30 +1581,25 @@ static int switch_context(struct i915_request *rq)
 {
struct intel_context *ce = rq->hw_context;
struct i915_address_space *vm = vm_alias(ce);
+   u32 hw_flags = 0;
int ret;
 
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
 
if (vm) {
-   ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
-   if (ret)
-   return ret;
+   int loops = 8;
+
+   do {
+   ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
+   if (ret)
+   return ret;
+   } while (--loops);
}
 
if (ce->state) {
-   u32 hw_flags;
-
GEM_BUG_ON(rq->engine->id != RCS0);
 
-   /*
-* The kernel context(s) is treated as pure scratch and is not
-* expected to retain any state (as we sacrifice it during
-* suspend and on resume it may be corrupted). This is ok,
-* as nothing actually executes using the kernel context; it
-* is purely used for flushing user contexts.
-*/
-   hw_flags = 0;
-   if (i915_gem_context_is_kernel(rq->gem_context))
+   if (!rq->engine->default_state)
hw_flags = MI_RESTORE_INHIBIT;
 
ret = mi_set_context(rq, hw_flags);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6239a9adbf14..0458dc53e0ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1692,7 +1692,6 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
intel_wakeref_t wakeref;
u64 from = start;
unsigned int pde;
-   bool flush = false;
int ret = 0;
 
wakeref = intel_runtime_pm_get(>i915->runtime_pm);
@@ -1717,11 +1716,6 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
spin_lock(>lock);
if (pd->entry[pde] == >scratch[1]) {
pd->entry[pde] = pt;
-   if (i915_vma_is_bound(ppgtt->vma,
- I915_VMA_GLOBAL_BIND)) {
-   gen6_write_pde(ppgtt, pde, pt);
-   flush = true;
-   }
} else {
alloc = pt;
pt = pd->entry[pde];
@@ -1732,8 +1726,11 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
}
spin_unlock(>lock);
 
-   if (flush)
+   if (i915_vma_is_bound(ppgtt->vma, I915_VMA_GLOBAL_BIND)) {
+   gen6_for_all_pdes(pt, pd, pde)
+   gen6_write_pde(ppgtt, pde, pt);
gen6_ggtt_invalidate(vm->gt->ggtt);
+   }
 
goto out;
 
@@ -1994,6 +1991,7 @@ static struct i915_ppgtt *gen6_ppgtt_create(struct 
drm_i915_private *i915)
 err_pd:
kfree(ppgtt->base.pd);
 err_free:
+   mutex_destroy(>pin_mutex);
kfree(ppgtt);
return ERR_PTR(err);
 }

Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it prevents making the fbops member of struct fb_info a
> > const pointer, which means we can't make struct fb_ops const
> > anywhere. Second, a few places have to go out of their way to restore
> > the original fb_mmap pointer that gets reset to NULL.
> > 
> > Preserve the passed in fb_ops by making a copy of it and modifying that
> > instead. Add a deferred_io_private member to struct fb_info to store the
> > pointer to the old fb_ops, and restore that at cleanup.
> > 
> > Cc: Jaya Kumar 
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Jani Nikula 
> > 
> > ---
> > 
> > Note: If the approach is acceptable, we'll also need to handle the error
> > returns on memory allocation failures at fb_deferred_io_init() call
> > sites. There are 13.
> 
> it's fbdev defio, I think we can do worse with less effort. Just embed a
> copy of fb_ops into fb_info, and use that, and tada! no memory allocation
> needed :-)
> 
> I'd totally r-b that patch.
> 
> Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
> the _init function and in fb_mmap call fb_deferred_io_mmap for that case
> instead of the driver's fb_ops->fb_mmap. There's only one caller of that
> in the entire tree, in fbmem.c. Also, we could/should nuke the
> EXPORT_SYMBOL(fb_deferred_io_mmap) I think.

I just realized that fb_info->fbdefio is a pointer, so this would be
really simple to pull off I think.
-Daniel

> 
> That version would also get my r-b stamp. So up to you what you prefer.
> -Daniel
> 
> > ---
> >  drivers/video/fbdev/core/fb_defio.c | 25 ++---
> >  include/linux/fb.h  |  3 ++-
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fb_defio.c 
> > b/drivers/video/fbdev/core/fb_defio.c
> > index 82c20c6047b0..36697844c1e0 100644
> > --- a/drivers/video/fbdev/core/fb_defio.c
> > +++ b/drivers/video/fbdev/core/fb_defio.c
> > @@ -200,13 +200,23 @@ static void fb_deferred_io_work(struct work_struct 
> > *work)
> > mutex_unlock(>lock);
> >  }
> >  
> > -void fb_deferred_io_init(struct fb_info *info)
> > +int fb_deferred_io_init(struct fb_info *info)
> >  {
> > struct fb_deferred_io *fbdefio = info->fbdefio;
> > +   struct fb_ops *fbops;
> >  
> > BUG_ON(!fbdefio);
> > +
> > +   fbops = kmemdup(info->fbops, sizeof(*fbops), GFP_KERNEL);
> > +   if (!fbops)
> > +   return -ENOMEM;
> > +
> > +   fbops->fb_mmap = fb_deferred_io_mmap;
> > +   info->deferred_io_private = info->fbops;
> > +   info->fbops = fbops;
> > +
> > mutex_init(>lock);
> > -   info->fbops->fb_mmap = fb_deferred_io_mmap;
> > +
> > INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
> > INIT_LIST_HEAD(>pagelist);
> > if (fbdefio->delay == 0) /* set a default of 1 s */
> > @@ -229,6 +239,12 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> > int i;
> >  
> > BUG_ON(!fbdefio);
> > +
> > +   /* sanity check against misuse */
> > +   if (WARN_ON(!info->deferred_io_private ||
> > +   info->fbops->fb_mmap != fb_deferred_io_mmap))
> > +   return;
> > +
> > cancel_delayed_work_sync(>deferred_work);
> >  
> > /* clear out the mapping that we setup */
> > @@ -237,7 +253,10 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> > page->mapping = NULL;
> > }
> >  
> > -   info->fbops->fb_mmap = NULL;
> > +   kfree(info->fbops);
> > +   info->fbops = info->deferred_io_private;
> > +   info->deferred_io_private = NULL;
> > +
> > mutex_destroy(>lock);
> >  }
> >  EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a6ad528990de..65f2abd47745 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -470,6 +470,7 @@ struct fb_info {
> >  #ifdef CONFIG_FB_DEFERRED_IO
> > struct delayed_work deferred_work;
> > struct fb_deferred_io *fbdefio;
> > +   void *deferred_io_private;
> >  #endif
> >  
> > struct fb_ops *fbops;
> > @@ -658,7 +659,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> > d_pitch,
> >  
> >  /* drivers/video/fb_defio.c */
> >  int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> > -extern void fb_deferred_io_init(struct fb_info *info);
> > +extern int fb_deferred_io_init(struct fb_info *info);
> >  extern void fb_deferred_io_open(struct fb_info *info,
> > struct inode *inode,
> > struct file *file);
> > -- 
> > 2.20.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter

Re: [Intel-gfx] [PATCH 03/13] video: smscufx: don't restore fb_mmap after deferred IO cleanup

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:31:59PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
> 
> Cc: Steve Glendinning 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/video/fbdev/smscufx.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
> index 0e0f5bbfc5ef..e362d7da87fc 100644
> --- a/drivers/video/fbdev/smscufx.c
> +++ b/drivers/video/fbdev/smscufx.c
> @@ -1170,7 +1170,6 @@ static int ufx_ops_release(struct fb_info *info, int 
> user)
>   fb_deferred_io_cleanup(info);
>   kfree(info->fbdefio);
>   info->fbdefio = NULL;
> - info->fbops->fb_mmap = ufx_ops_mmap;

Also totally pointless to restore this here, since if you have indeed
loaded the driver twice shit has hit the fan already. I guess that was for
the module option  wtf.

Reviewed-by: Daniel Vetter 

>   }
>  
>   pr_debug("released /dev/fb%d user=%d count=%d",
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 02/13] drm/fb-helper: don't preserve fb_ops across deferred IO use

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:31:58PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
> 
> Cc: Noralf Trønnes 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 18 ++
>  1 file changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0c088ea70ad0..a5a2a538d085 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1954,7 +1954,6 @@ static int drm_fbdev_fb_release(struct fb_info *info, 
> int user)
>  static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
>  {
>   struct fb_info *fbi = fb_helper->fbdev;
> - struct fb_ops *fbops = NULL;
>   void *shadow = NULL;
>  
>   if (!fb_helper->dev)
> @@ -1963,15 +1962,11 @@ static void drm_fbdev_cleanup(struct drm_fb_helper 
> *fb_helper)
>   if (fbi && fbi->fbdefio) {
>   fb_deferred_io_cleanup(fbi);
>   shadow = fbi->screen_buffer;
> - fbops = fbi->fbops;
>   }
>  
>   drm_fb_helper_fini(fb_helper);
>  
> - if (shadow) {
> - vfree(shadow);
> - kfree(fbops);
> - }
> + vfree(shadow);
>  
>   drm_client_framebuffer_delete(fb_helper->buffer);
>  }
> @@ -2062,23 +2057,14 @@ static int drm_fb_helper_generic_probe(struct 
> drm_fb_helper *fb_helper,
>   drm_fb_helper_fill_info(fbi, fb_helper, sizes);
>  
>   if (drm_fbdev_use_shadow_fb(fb_helper)) {
> - struct fb_ops *fbops;
>   void *shadow;
>  
> - /*
> -  * fb_deferred_io_cleanup() clears >fb_mmap so a per
> -  * instance version is necessary.
> -  */
> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
>   shadow = vzalloc(fbi->screen_size);
> - if (!fbops || !shadow) {
> - kfree(fbops);
> + if (!shadow) {
>   vfree(shadow);
>   return -ENOMEM;
>   }
>  
> - *fbops = *fbi->fbops;
> - fbi->fbops = fbops;
>   fbi->screen_buffer = shadow;
>   fbi->fbdefio = _fbdev_defio;
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer, which means we can't make struct fb_ops const
> anywhere. Second, a few places have to go out of their way to restore
> the original fb_mmap pointer that gets reset to NULL.
> 
> Preserve the passed in fb_ops by making a copy of it and modifying that
> instead. Add a deferred_io_private member to struct fb_info to store the
> pointer to the old fb_ops, and restore that at cleanup.
> 
> Cc: Jaya Kumar 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Note: If the approach is acceptable, we'll also need to handle the error
> returns on memory allocation failures at fb_deferred_io_init() call
> sites. There are 13.

it's fbdev defio, I think we can do worse with less effort. Just embed a
copy of fb_ops into fb_info, and use that, and tada! no memory allocation
needed :-)

I'd totally r-b that patch.

Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
the _init function and in fb_mmap call fb_deferred_io_mmap for that case
instead of the driver's fb_ops->fb_mmap. There's only one caller of that
in the entire tree, in fbmem.c. Also, we could/should nuke the
EXPORT_SYMBOL(fb_deferred_io_mmap) I think.

That version would also get my r-b stamp. So up to you what you prefer.
-Daniel

> ---
>  drivers/video/fbdev/core/fb_defio.c | 25 ++---
>  include/linux/fb.h  |  3 ++-
>  2 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index 82c20c6047b0..36697844c1e0 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -200,13 +200,23 @@ static void fb_deferred_io_work(struct work_struct 
> *work)
>   mutex_unlock(>lock);
>  }
>  
> -void fb_deferred_io_init(struct fb_info *info)
> +int fb_deferred_io_init(struct fb_info *info)
>  {
>   struct fb_deferred_io *fbdefio = info->fbdefio;
> + struct fb_ops *fbops;
>  
>   BUG_ON(!fbdefio);
> +
> + fbops = kmemdup(info->fbops, sizeof(*fbops), GFP_KERNEL);
> + if (!fbops)
> + return -ENOMEM;
> +
> + fbops->fb_mmap = fb_deferred_io_mmap;
> + info->deferred_io_private = info->fbops;
> + info->fbops = fbops;
> +
>   mutex_init(>lock);
> - info->fbops->fb_mmap = fb_deferred_io_mmap;
> +
>   INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
>   INIT_LIST_HEAD(>pagelist);
>   if (fbdefio->delay == 0) /* set a default of 1 s */
> @@ -229,6 +239,12 @@ void fb_deferred_io_cleanup(struct fb_info *info)
>   int i;
>  
>   BUG_ON(!fbdefio);
> +
> + /* sanity check against misuse */
> + if (WARN_ON(!info->deferred_io_private ||
> + info->fbops->fb_mmap != fb_deferred_io_mmap))
> + return;
> +
>   cancel_delayed_work_sync(>deferred_work);
>  
>   /* clear out the mapping that we setup */
> @@ -237,7 +253,10 @@ void fb_deferred_io_cleanup(struct fb_info *info)
>   page->mapping = NULL;
>   }
>  
> - info->fbops->fb_mmap = NULL;
> + kfree(info->fbops);
> + info->fbops = info->deferred_io_private;
> + info->deferred_io_private = NULL;
> +
>   mutex_destroy(>lock);
>  }
>  EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a6ad528990de..65f2abd47745 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -470,6 +470,7 @@ struct fb_info {
>  #ifdef CONFIG_FB_DEFERRED_IO
>   struct delayed_work deferred_work;
>   struct fb_deferred_io *fbdefio;
> + void *deferred_io_private;
>  #endif
>  
>   struct fb_ops *fbops;
> @@ -658,7 +659,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> d_pitch,
>  
>  /* drivers/video/fb_defio.c */
>  int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> -extern void fb_deferred_io_init(struct fb_info *info);
> +extern int fb_deferred_io_init(struct fb_info *info);
>  extern void fb_deferred_io_open(struct fb_info *info,
>   struct inode *inode,
>   struct file *file);
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 01/13] video: fb_defio: preserve user fb_ops

2019-11-27 Thread Daniel Vetter
On Wed, Nov 27, 2019 at 07:01:16PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it prevents making the fbops member of struct fb_info a
> > const pointer, which means we can't make struct fb_ops const
> > anywhere. Second, a few places have to go out of their way to restore
> > the original fb_mmap pointer that gets reset to NULL.
> > 
> > Preserve the passed in fb_ops by making a copy of it and modifying that
> > instead. Add a deferred_io_private member to struct fb_info to store the
> > pointer to the old fb_ops, and restore that at cleanup.
> 
> Quite the horror show. I wonder how hard it would be to just have each
> driver that can use defio provide a mmap hook that either dispatches
> to the defio one or the native one depending if defio is used or not...
> 
> A few drivers at least seem to always use defio so those should be
> trivial. Some others seem to make the decision dynamically, which
> would require custom .mmap(). Though I suppose all of them could just
> be of the form
> foo_mmap_wrap{)
> {
>   if (info->defio)
>   defio_mmap()
>   else
>   foo_mmap();
> }
> 
> Hmm. Actually is .fb_mmap() called from anywhere but fb_mmap()? If not
> we could just shove the defio check there? Or if it's called from
> several places we could try to wrap all calls in _fb_mmap() or somesuch.

While we're spinning this garn about fb_mmap improvements: My cunning
plan, documented in todo.rst even, is to have our own fb_mmap
implementation for the drm fbdev helper, which will handle all this
internally.

And then just quietly burn down the fbdev defio stuff to the ground,
because it's the stuff for nightmares.

https://dri.freedesktop.org/docs/drm/gpu/todo.html#generic-fbdev-defio-support

tldr; Imo no point investing too much in polishing the defio stuff.
-Daniel

> 
> > 
> > Cc: Jaya Kumar 
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Jani Nikula 
> > 
> > ---
> > 
> > Note: If the approach is acceptable, we'll also need to handle the error
> > returns on memory allocation failures at fb_deferred_io_init() call
> > sites. There are 13.
> > ---
> >  drivers/video/fbdev/core/fb_defio.c | 25 ++---
> >  include/linux/fb.h  |  3 ++-
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fb_defio.c 
> > b/drivers/video/fbdev/core/fb_defio.c
> > index 82c20c6047b0..36697844c1e0 100644
> > --- a/drivers/video/fbdev/core/fb_defio.c
> > +++ b/drivers/video/fbdev/core/fb_defio.c
> > @@ -200,13 +200,23 @@ static void fb_deferred_io_work(struct work_struct 
> > *work)
> > mutex_unlock(>lock);
> >  }
> >  
> > -void fb_deferred_io_init(struct fb_info *info)
> > +int fb_deferred_io_init(struct fb_info *info)
> >  {
> > struct fb_deferred_io *fbdefio = info->fbdefio;
> > +   struct fb_ops *fbops;
> >  
> > BUG_ON(!fbdefio);
> > +
> > +   fbops = kmemdup(info->fbops, sizeof(*fbops), GFP_KERNEL);
> > +   if (!fbops)
> > +   return -ENOMEM;
> > +
> > +   fbops->fb_mmap = fb_deferred_io_mmap;
> > +   info->deferred_io_private = info->fbops;
> > +   info->fbops = fbops;
> > +
> > mutex_init(>lock);
> > -   info->fbops->fb_mmap = fb_deferred_io_mmap;
> > +
> > INIT_DELAYED_WORK(>deferred_work, fb_deferred_io_work);
> > INIT_LIST_HEAD(>pagelist);
> > if (fbdefio->delay == 0) /* set a default of 1 s */
> > @@ -229,6 +239,12 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> > int i;
> >  
> > BUG_ON(!fbdefio);
> > +
> > +   /* sanity check against misuse */
> > +   if (WARN_ON(!info->deferred_io_private ||
> > +   info->fbops->fb_mmap != fb_deferred_io_mmap))
> > +   return;
> > +
> > cancel_delayed_work_sync(>deferred_work);
> >  
> > /* clear out the mapping that we setup */
> > @@ -237,7 +253,10 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> > page->mapping = NULL;
> > }
> >  
> > -   info->fbops->fb_mmap = NULL;
> > +   kfree(info->fbops);
> > +   info->fbops = info->deferred_io_private;
> > +   info->deferred_io_private = NULL;
> > +
> > mutex_destroy(>lock);
> >  }
> >  EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a6ad528990de..65f2abd47745 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -470,6 +470,7 @@ struct fb_info {
> >  #ifdef CONFIG_FB_DEFERRED_IO
> > struct delayed_work deferred_work;
> > struct fb_deferred_io *fbdefio;
> > +   void *deferred_io_private;
> >  #endif
> >  
> > struct fb_ops *fbops;
> > @@ -658,7 +659,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> > d_pitch,
> >  
> >  /* drivers/video/fb_defio.c */
> >  int fb_deferred_io_mmap(struct fb_info *info, struct 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for adding gamma state checker for icl+ platforms (rev7)

2019-11-27 Thread Patchwork
== Series Details ==

Series: adding gamma state checker for icl+ platforms (rev7)
URL   : https://patchwork.freedesktop.org/series/66811/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
bee2710f9f35 drm/i915/color: Extract icl_read_luts()
-:33: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#33: 
-removed readouts of fine and coarse segments, failure to read PAL_PREC_DATA

total: 0 errors, 1 warnings, 0 checks, 175 lines checked
f9bb50634ce7 FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
-:18: WARNING:LONG_LINE: line over 100 characters
#18: FILE: drivers/gpu/drm/i915/display/intel_color.c:1584:
+   DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x 
sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", lut2->red, lut1->red, 
lut2->blue, lut1->blue, lut2->green, lut1->green);

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

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/vbt: Parse power conservation features block

2019-11-27 Thread Matt Roper
On Mon, Nov 25, 2019 at 04:47:39PM -0800, Souza, Jose wrote:
> On Tue, 2019-11-12 at 23:56 +, Souza, Jose wrote:
> > On Tue, 2019-11-12 at 13:21 -0800, Matt Roper wrote:
> > > On Tue, Nov 05, 2019 at 05:45:04PM -0800, José Roberto de Souza
> > > wrote:
> > > > Since VBT 228 is from this block that PSR and other power saving
> > > > features configuration should be read from.
> > > > 
> > > > Cc: Gwan-gyeong Mun 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_bios.c | 19 +++-
> > > >  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29
> > > > +++
> > > >  2 files changed, 47 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > > > b/drivers/gpu/drm/i915/display/intel_bios.c
> > > > index a03f56b7b4ef..bf79e9858bd8 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > > > @@ -561,7 +561,23 @@ parse_driver_features(struct
> > > > drm_i915_private
> > > > *dev_priv,
> > > >  */
> > > > if (!driver->drrs_enabled)
> > > > dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> > > > -   dev_priv->vbt.psr.enable = driver->psr_enabled;
> > > > +   if (bdb->version < 228)
> > > > +   dev_priv->vbt.psr.enable = driver->psr_enabled;
> > > > +}
> > > > +
> > > > +static void
> > > > +parse_power_conservation_features(struct drm_i915_private
> > > > *dev_priv,
> > > > + const struct bdb_header *bdb)
> > > > +{
> > > > +   const struct bdb_lfp_power *power;
> > > > +   u8 panel_type = dev_priv->vbt.panel_type;
> > > > +
> > > > +   power = find_section(bdb, BDB_LVDS_POWER);
> > > > +   if (!power)
> > > > +   return;
> > > > +
> > > > +   if (bdb->version >= 228)
> > > > +   dev_priv->vbt.psr.enable = power->psr & (1 <<
> > > > panel_type);
> > > 
> > > Should we also be setting dev_priv->vbt.drrs_type =
> > > DRRS_NOT_SUPPORTED
> > > if block 44 tells us it isn't valid on this panel?
> > > 
> > 
> > Yep, it should.
> > Thanks for catching this.
> 
> Nothing from block 40 is obsolete, it has the information about the
> DRRS type of all the 16 possible panels so is better keep relying on it
> as block 44 only have only the information if DRRS is supported or not.
> 
> I also checked the other features but we don't implement those.

I think the DRRS_NOT_SUPPORTED is currently being set based on the
contents of block 12 (in parse_driver_features).  Block 12 does list the
bit we're looking at as obsolete in version 228 (moved to block 44).


Matt

> 
> 
> > 
> > > Matt
> > > 
> > > >  }
> > > >  
> > > >  static void
> > > > @@ -1878,6 +1894,7 @@ void intel_bios_init(struct
> > > > drm_i915_private
> > > > *dev_priv)
> > > > parse_lfp_backlight(dev_priv, bdb);
> > > > parse_sdvo_panel_data(dev_priv, bdb);
> > > > parse_driver_features(dev_priv, bdb);
> > > > +   parse_power_conservation_features(dev_priv, bdb);
> > > > parse_edp(dev_priv, bdb);
> > > > parse_psr(dev_priv, bdb);
> > > > parse_mipi_config(dev_priv, bdb);
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > index 69a7cb1fa121..31f47ce56587 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > > > @@ -792,6 +792,35 @@ struct bdb_lfp_backlight_data {
> > > > struct lfp_backlight_control_method backlight_control[16];
> > > >  } __packed;
> > > >  
> > > > +/*
> > > > + * Block 44 - LFP Power Conservation Features Block
> > > > + */
> > > > +
> > > > +struct als_data_entry {
> > > > +   u16 backlight_adjust;
> > > > +   u16 lux;
> > > > +} __packed;
> > > > +
> > > > +struct agressiveness_profile_entry {
> > > > +   u8 dpst_agressiveness : 4;
> > > > +   u8 lace_agressiveness : 4;
> > > > +} __packed;
> > > > +
> > > > +struct bdb_lfp_power {
> > > > +   u8 lfp_feature_bits;
> > > > +   struct als_data_entry als[5];
> > > > +   u8 lace_aggressiveness_profile;
> > > > +   u16 dpst;
> > > > +   u16 psr;
> > > > +   u16 drrs;
> > > > +   u16 lace_support;
> > > > +   u16 adt;
> > > > +   u16 dmrrs;
> > > > +   u16 adb;
> > > > +   u16 lace_enabled_status;
> > > > +   struct agressiveness_profile_entry aggressivenes[16];
> > > > +} __packed;
> > > > +
> > > >  /*
> > > >   * Block 52 - MIPI Configuration Block
> > > >   */
> > > > -- 
> > > > 2.24.0
> > > > 
> > > > ___
> > > > 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
> > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Serialise i915_active_fence_set() with itself (rev3)

2019-11-27 Thread Patchwork
== Series Details ==

Series: drm/i915: Serialise i915_active_fence_set() with itself (rev3)
URL   : https://patchwork.freedesktop.org/series/70068/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7432 -> Patchwork_15467


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15467 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15467, 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_15467/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4] ([fdo#112261])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
- {fi-kbl-7560u}: [FAIL][7] ([fdo#112269]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-kbl-7560u/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][11] ([fdo#102614]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2:  [FAIL][13] ([fdo#103167]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275:   [DMESG-WARN][15] ([fdo#103558] / [fdo#105602] / 
[fdo#107139]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763] / 
[fdo#107139])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u2:  [INCOMPLETE][17] ([fdo#107713]) -> [DMESG-WARN][18] 
([fdo#110595])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-icl-u2/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-icl-u2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275:   [DMESG-WARN][19] ([fdo#103558] / [fdo#105602] / 
[fdo#105763]) -> [DMESG-WARN][20] ([fdo#103558] / [fdo#105602]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7432/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15467/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275:   [DMESG-WARN][21] ([fdo#103558] / [fdo#105602]) -> 
[DMESG-WARN][22] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +4 similar issues
   [21]: 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Handle SDEISR according to PCH rather than platform

2019-11-27 Thread Lucas De Marchi

On Tue, Nov 26, 2019 at 01:07:30PM -0800, Matt Roper wrote:

The South Display is part of the PCH so we should technically be basing
our port detection logic off the PCH in use rather than the platform
generation.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_dp.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3123958e2081..ddf5bad1b969 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5487,7 +5487,7 @@ static bool icl_combo_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
}

-static bool icl_digital_port_connected(struct intel_encoder *encoder)
+static bool icp_digital_port_connected(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
@@ -5525,9 +5525,9 @@ static bool __intel_digital_port_connected(struct 
intel_encoder *encoder)
return g4x_digital_port_connected(encoder);
}

-   if (INTEL_GEN(dev_priv) >= 11)
-   return icl_digital_port_connected(encoder);
-   else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv))
+   if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+   return icp_digital_port_connected(encoder);
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
return spt_digital_port_connected(encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(encoder);
--
2.23.0

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

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/ehl: Make icp_digital_port_connected() use phy instead of port

2019-11-27 Thread Lucas De Marchi

On Tue, Nov 26, 2019 at 01:07:31PM -0800, Matt Roper wrote:

When looking at SDEISR to determine the connection status of combo
outputs, we should use the phy index rather than the port index.
Although they're usually the same thing, EHL's DDI-D (port D) is
attached to PHY-A and SDEISR doesn't even have bits for a "D" output.
It's also possible that future platforms may map DDIs (the internal
display engine programming units) to PHYs (the output handling on the IO
side) in ways where port!=phy, so let's look at the PHY index by
default.

Fixes: 719d24002602 ("drm/i915/ehl: Enable DDI-D")
Cc: José Roberto de Souza 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ddf5bad1b969..59c5fd7bf27d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5477,14 +5477,12 @@ static bool bxt_digital_port_connected(struct 
intel_encoder *encoder)
}

static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,


while at it I think it would make more sense to call this
icl_combo_phy_connected() and maybe even intel_combo_phy_connected()

Reviewed-by: Lucas De Marchi 

Lucas De Marchi


-struct intel_digital_port *intel_dig_port)
+enum phy phy)
{
-   enum port port = intel_dig_port->base.port;
-
-   if (HAS_PCH_MCC(dev_priv) && port == PORT_C)
+   if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
return I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(PORT_TC1);

-   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(phy);
}

static bool icp_digital_port_connected(struct intel_encoder *encoder)
@@ -5494,7 +5492,7 @@ static bool icp_digital_port_connected(struct 
intel_encoder *encoder)
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);

if (intel_phy_is_combo(dev_priv, phy))
-   return icl_combo_port_connected(dev_priv, dig_port);
+   return icl_combo_port_connected(dev_priv, phy);
else if (intel_phy_is_tc(dev_priv, phy))
return intel_tc_port_connected(dig_port);
else
--
2.23.0

___
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

  1   2   >