[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix selftest_mocs for DGFX

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Fix selftest_mocs for DGFX
URL   : https://patchwork.freedesktop.org/series/73387/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16551


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-skl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#108744])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16551/fi-skl-guc/igt@i915_selftest@live_hangcheck.html

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

  
 Possible fixes 

  * igt@gem_exec_parallel@fds:
- fi-byt-n2820:   [FAIL][5] ([i915#694]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_exec_paral...@fds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16551/fi-byt-n2820/igt@gem_exec_paral...@fds.html

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

  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 39)
--

  Additional (6): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka 
  Missing(12): fi-ilk-m540 fi-bdw-5557u fi-tgl-dsi fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-hsw-4770 fi-ivb-3770 fi-icl-u3 fi-byt-clapper 
fi-bsw-nick fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16551

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16551: 682894ca677494b97822c78d9291f49f2e4b51e7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

682894ca6774 drm/i915/selftests: Fix selftest_mocs for DGFX

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Fix selftest_mocs for DGFX

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Fix selftest_mocs for DGFX
URL   : https://patchwork.freedesktop.org/series/73387/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
682894ca6774 drm/i915/selftests: Fix selftest_mocs for DGFX
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
References: e6e2ac07118b ("drm/i915: do not set MOCS control values on dgfx")

-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit e6e2ac07118b ("drm/i915: do not 
set MOCS control values on dgfx")'
#10: 
References: e6e2ac07118b ("drm/i915: do not set MOCS control values on dgfx")

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

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


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

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add Wa_1808121037 to tgl.
URL   : https://patchwork.freedesktop.org/series/73379/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16550


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-ehl-1}: [INCOMPLETE][7] ([i915#937]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16550/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html

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

  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 41)
--

  Additional (6): fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi fi-bsw-kefka 
fi-kbl-7560u fi-kbl-r 
  Missing(10): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 fi-blb-e6850 fi-byt-n2820 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16550

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16550: 311bb8e099cc5b1119247fbf73e1499d52c691f2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

311bb8e099cc drm/i915/tgl: Add Wa_1808121037 to tgl.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16550/index.html
___
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: Use engine wa list for Wa_1607090982

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Use engine wa list for Wa_1607090982
URL   : https://patchwork.freedesktop.org/series/73374/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16549


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html

  
 Suppressed 

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

  * {igt@gem_exec_fence@basic-await@bcs0}:
- fi-cml-u2:  [SKIP][3] ([i915#1208]) -> [SKIP][4] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-u2/igt@gem_exec_fence@basic-aw...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-cml-u2/igt@gem_exec_fence@basic-aw...@bcs0.html

  * {igt@gem_exec_fence@basic-wait@bcs0}:
- fi-cml-s:   [SKIP][5] ([i915#1208]) -> [SKIP][6] +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-s/igt@gem_exec_fence@basic-w...@bcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-cml-s/igt@gem_exec_fence@basic-w...@bcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-n2820:   [PASS][7] -> [INCOMPLETE][8] ([i915#45])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u3:  [PASS][9] -> [INCOMPLETE][10] ([fdo#108569])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-icl-u3/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@dp-edid-read:
- fi-cml-u2:  [PASS][11] -> [FAIL][12] ([i915#217] / [i915#976])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html

  
 Possible fixes 

  * igt@i915_selftest@live_workarounds:
- {fi-tgl-u}: [DMESG-FAIL][13] ([i915#1169]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-tgl-u/igt@i915_selftest@live_workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-tgl-u/igt@i915_selftest@live_workarounds.html
- {fi-tgl-dsi}:   [DMESG-FAIL][15] ([i915#1169]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-tgl-dsi/igt@i915_selftest@live_workarounds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16549/fi-tgl-dsi/igt@i915_selftest@live_workarounds.html

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

  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [i915#1169]: https://gitlab.freedesktop.org/drm/intel/issues/1169
  [i915#1208]: https://gitlab.freedesktop.org/drm/intel/issues/1208
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
  [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976


Participating hosts (45 -> 45)
--

  Additional (6): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-bsw-kefka fi-kbl-r 
  Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16549

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add support for DP 1.4 Compliance edid corruption test (rev6)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm: Add support for DP 1.4 Compliance edid corruption test (rev6)
URL   : https://patchwork.freedesktop.org/series/70530/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16548


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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


Participating hosts (45 -> 40)
--

  Additional (5): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 
  Missing(10): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-cfl-8700k 
fi-ctg-p8600 fi-skl-lmem fi-byt-n2820 fi-byt-clapper fi-bdw-samus fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16548

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16548: ef3b47e265d695b7a204faa524604763ee0ee191 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ef3b47e265d6 drm: Add support for DP 1.4 Compliance edid corruption test

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pfit/scaler rework prep stuff (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915: pfit/scaler rework prep stuff (rev2)
URL   : https://patchwork.freedesktop.org/series/68409/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16547


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### 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:
- {fi-ehl-1}: NOTRUN -> [WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16547/fi-ehl-1/igt@i915_module_l...@reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-n2820:   [PASS][2] -> [INCOMPLETE][3] ([i915#45])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16547/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-ehl-1}: [INCOMPLETE][6] ([i915#937]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16547/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html

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

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


Participating hosts (45 -> 38)
--

  Additional (6): fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi fi-gdg-551 
fi-bsw-kefka fi-kbl-r 
  Missing(13): fi-ilk-m540 fi-bdw-samus fi-bdw-5557u fi-byt-j1900 
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-cfl-8109u fi-skl-6700k2 
fi-blb-e6850 fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16547

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16547: 833bab58ec2fa453deb38303f5534118c328c5a5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

833bab58ec2f drm/i915: Have pfit calculations return an error code
6ea293f66e4d drm/i915: Pass connector state to pfit calculations
489d614c2d81 drm/i915: s/pipe_config/crtc_state/ in pfit functions
31b06d809c65 drm/i915: Use drm_rect to store the pfit window pos/size
29d781ef706b drm/i915: Flatten a bunch of the pfit functions
e78250ae53d0 drm/i915: Fix skl+ non-scaled pfit modes
0c04ecca2fc1 drm/i915: Use intel_de_write_fw() for skl+ scaler registers
0027eb6cbbdb drm/i915: Parametrize PFIT_PIPE

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] MAINTAINERS: Update drm/i915 bug filing URL

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] MAINTAINERS: Update drm/i915 bug filing URL
URL   : https://patchwork.freedesktop.org/series/73371/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16546


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gtt:
- fi-kbl-7500u:   [PASS][1] -> [TIMEOUT][2] ([fdo#112271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16546/fi-kbl-7500u/igt@i915_selftest@live_gtt.html

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

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][5] ([fdo#109271]) -> [FAIL][6] ([i915#579])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16546/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 46)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-r 
  Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16546

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16546: 63e6a1c6ccf1cf204f06b5e61c0a3b702d0bb004 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

63e6a1c6ccf1 drm/i915: Update drm/i915 bug filing URL
f7eef1bd93b5 MAINTAINERS: Update drm/i915 bug filing URL

== Logs ==

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


[Intel-gfx] [drm-intel:drm-intel-next-queued 5/5] drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs'

2020-02-12 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   c616d2387aeeb987f03eee848f04ffdc248c7aae
commit: c616d2387aeeb987f03eee848f04ffdc248c7aae [5/5] drm/i915/gt: Expand bad 
CS completion event debug
config: i386-randconfig-h003-20200213 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
git checkout c616d2387aeeb987f03eee848f04ffdc248c7aae
# save the attached .config to linux build tree
make ARCH=i386 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'process_csb':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs' 
>> [-Werror=unused-variable]
const u32 *regs = rq->context->lrc_reg_state;
   ^~~~
   cc1: all warnings being treated as errors

vim +/regs +2335 drivers/gpu/drm/i915/gt/intel_lrc.c

    
  2223  static void process_csb(struct intel_engine_cs *engine)
  2224  {
  2225  struct intel_engine_execlists * const execlists = 
>execlists;
  2226  const u32 * const buf = execlists->csb_status;
  2227  const u8 num_entries = execlists->csb_size;
  2228  u8 head, tail;
  2229  
  2230  /*
  2231   * As we modify our execlists state tracking we require 
exclusive
  2232   * access. Either we are inside the tasklet, or the tasklet is 
disabled
  2233   * and we assume that is only inside the reset paths and so 
serialised.
  2234   */
  2235  GEM_BUG_ON(!tasklet_is_locked(>tasklet) &&
  2236 !reset_in_progress(execlists));
  2237  GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
  2238  
  2239  /*
  2240   * Note that csb_write, csb_status may be either in HWSP or 
mmio.
  2241   * When reading from the csb_write mmio register, we have to be
  2242   * careful to only use the GEN8_CSB_WRITE_PTR portion, which is
  2243   * the low 4bits. As it happens we know the next 4bits are 
always
  2244   * zero and so we can simply masked off the low u8 of the 
register
  2245   * and treat it identically to reading from the HWSP (without 
having
  2246   * to use explicit shifting and masking, and probably 
bifurcating
  2247   * the code to handle the legacy mmio read).
  2248   */
  2249  head = execlists->csb_head;
  2250  tail = READ_ONCE(*execlists->csb_write);
  2251  if (unlikely(head == tail))
  2252  return;
  2253  
  2254  /*
  2255   * Hopefully paired with a wmb() in HW!
  2256   *
  2257   * We must complete the read of the write pointer before any 
reads
  2258   * from the CSB, so that we do not see stale values. Without an 
rmb
  2259   * (lfence) the HW may speculatively perform the CSB[] reads 
*before*
  2260   * we perform the READ_ONCE(*csb_write).
  2261   */
  2262  rmb();
  2263  
  2264  ENGINE_TRACE(engine, "cs-irq head=%d, tail=%d\n", head, tail);
  2265  do {
  2266  bool promote;
  2267  
  2268  if (++head == num_entries)
  2269  head = 0;
  2270  
  2271  /*
  2272   * We are flying near dragons again.
  2273   *
  2274   * We hold a reference to the request in execlist_port[]
  2275   * but no more than that. We are operating in softirq
  2276   * context and so cannot hold any mutex or sleep. That
  2277   * prevents us stopping the requests we are processing
  2278   * in port[] from being retired simultaneously (the
  2279   * breadcrumb will be complete before we see the
  2280   * context-switch). As we only hold the reference to the
  2281   * request, any pointer chasing underneath the request
  2282   * is subject to a potential use-after-free. Thus we
  2283   * store all of the bookkeeping within port[] as
  2284   * required, and avoid using unguarded pointers beneath
  2285   * request itself. The same applies to the atomic
  2286   * status notifier.
  2287   */
  2288  
  2289  ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
  2290   head, buf[2 * head + 0], buf[2 * head + 
1]);
  2291  
  2292  if (INTEL_GEN(engine->i915) >= 12)
  2293  promote = gen12_csb_parse(execlists, buf + 2 * 
head);
  2294  else
  2295  promote = gen8_csb_parse(execlists, buf + 2 * 
head);
  2296  if (promote) {
  2297  struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Ensure no conflicts with BIOS when updating Dbuf

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Ensure no conflicts with BIOS when updating Dbuf
URL   : https://patchwork.freedesktop.org/series/73369/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16545


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-n2820:   [PASS][1] -> [INCOMPLETE][2] ([i915#45])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16545/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

  * igt@i915_selftest@live_execlists:
- fi-icl-y:   [PASS][3] -> [DMESG-FAIL][4] ([fdo#108569])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-y/igt@i915_selftest@live_execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16545/fi-icl-y/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gtt:
- fi-bdw-5557u:   [PASS][5] -> [TIMEOUT][6] ([fdo#112271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16545/fi-bdw-5557u/igt@i915_selftest@live_gtt.html

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

  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 42)
--

  Additional (6): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-gdg-551 
fi-bsw-kefka fi-kbl-7560u 
  Missing(9): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-snb-2520m 
fi-ctg-p8600 fi-ivb-3770 fi-skl-lmem fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16545

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16545: d4cfa34dac5fb3d3a2d8464e952923aa5c734cca @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d4cfa34dac5f drm/i915: Ensure no conflicts with BIOS when updating Dbuf

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Force state->modeset=true when distrust_bios_wm==true

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Force state->modeset=true when distrust_bios_wm==true
URL   : https://patchwork.freedesktop.org/series/73367/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16544


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([CI#80] / [fdo#106070] 
/ [i915#424])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
- fi-cml-s:   [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_gtt:
- fi-skl-6600u:   [PASS][5] -> [TIMEOUT][6] ([fdo#111732] / 
[fdo#112271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-skl-6600u/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-skl-6600u/igt@i915_selftest@live_gtt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#111096] / [i915#323])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Warnings 

  * igt@gem_exec_parallel@fds:
- fi-byt-n2820:   [FAIL][9] ([i915#694]) -> [INCOMPLETE][10] ([i915#45])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_exec_paral...@fds.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-byt-n2820/igt@gem_exec_paral...@fds.html

  
  [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (45 -> 44)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-r 
  Missing(8): fi-ilk-m540 fi-ehl-1 fi-tgl-dsi fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16544

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16544: 13b07a71ab0c312340f89f3b3ba477895ea6a0d8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

13b07a71ab0c drm/i915: Force state->modeset=true when distrust_bios_wm==true

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: terminate reauth at stream management failure

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: terminate reauth at stream 
management failure
URL   : https://patchwork.freedesktop.org/series/73282/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7909_full -> Patchwork_16517_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +11 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-iclb4/igt@gem_b...@busy-vcs1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-iclb7/igt@gem_b...@busy-vcs1.html

  * igt@gem_exec_balancer@hang:
- shard-tglb: [PASS][3] -> [TIMEOUT][4] ([fdo#112271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-tglb6/igt@gem_exec_balan...@hang.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-tglb3/igt@gem_exec_balan...@hang.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +7 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-iclb8/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([i915#694]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-hsw7/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-hsw5/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#644])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-glk2/igt@gem_pp...@flink-and-close-vma-leak.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#644])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-kbl6/igt@gem_pp...@flink-and-close-vma-leak.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-kbl2/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#189])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-iclb6/igt@i915_pm_...@modeset-lpsp-stress.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-iclb2/igt@i915_pm_...@modeset-lpsp-stress.html

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-hsw:  [PASS][17] -> [INCOMPLETE][18] ([i915#151] / 
[i915#61])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-hsw2/igt@i915_pm_...@system-suspend-modeset.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-hsw6/igt@i915_pm_...@system-suspend-modeset.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20] ([i915#300])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-apl:  [PASS][23] -> [DMESG-WARN][24] ([i915#180])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7909/shard-apl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16517/shard-apl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][25] -> [FAIL][26] ([fdo#108145] / [i915#265])
   [25]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev2)
URL   : https://patchwork.freedesktop.org/series/73036/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16543


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_execlists:
- fi-icl-y:   [PASS][1] -> [DMESG-FAIL][2] ([fdo#108569])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-y/igt@i915_selftest@live_execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16543/fi-icl-y/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u2:  [PASS][3] -> [INCOMPLETE][4] ([fdo#108569])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16543/fi-icl-u2/igt@i915_selftest@live_hangcheck.html

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

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [INCOMPLETE][7] ([i915#45]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16543/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

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

  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 46)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-r 
  Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16543

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16543: 30796e2ed1db6d3b35bc31a221597634e5841a4d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

30796e2ed1db drm/i915/dsb: Pre allocate and late cleanup of cmd buffer

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: split out vlv/chv specific suspend/resume code

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: split out vlv/chv specific 
suspend/resume code
URL   : https://patchwork.freedesktop.org/series/73365/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16542


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][1] -> [DMESG-FAIL][2] ([i915#1052])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16542/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
- fi-cml-s:   [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16542/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_gtt:
- fi-skl-6600u:   [PASS][5] -> [TIMEOUT][6] ([fdo#111732] / 
[fdo#112271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-skl-6600u/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16542/fi-skl-6600u/igt@i915_selftest@live_gtt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#111096] / [i915#323])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16542/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_parallel@contexts:
- fi-byt-n2820:   [FAIL][9] ([i915#694]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16542/fi-byt-n2820/igt@gem_exec_paral...@contexts.html

  
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (45 -> 45)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-r 
  Missing(7): fi-ilk-m540 fi-ehl-1 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16542

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16542: c756ef3fa3ce3ba656e7a56b370b334792d4a6a6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c756ef3fa3ce drm/i915: switch vlv_suspend to use intel uncore register accessors
ae72e53c4c88 drm/i915: split out vlv/chv specific suspend/resume code

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: split out vlv/chv specific suspend/resume code

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: split out vlv/chv specific 
suspend/resume code
URL   : https://patchwork.freedesktop.org/series/73365/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ae72e53c4c88 drm/i915: split out vlv/chv specific suspend/resume code
-:642: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#642: 
new file mode 100644

-:883: ERROR:SPACING: space required after that ',' (ctx:VxV)
#883: FILE: drivers/gpu/drm/i915/vlv_suspend.c:237:
+   I915_WRITE(GEN6_RP_DOWN_TIMEOUT,s->rp_down_timeout);
   ^

total: 1 errors, 1 warnings, 0 checks, 1104 lines checked
c756ef3fa3ce drm/i915: switch vlv_suspend to use intel uncore register accessors
-:232: ERROR:SPACING: space required after that ',' (ctx:VxV)
#232: FILE: drivers/gpu/drm/i915/vlv_suspend.c:239:
+   intel_uncore_write(uncore, GEN6_RP_DOWN_TIMEOUT,s->rp_down_timeout);
   ^

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

___
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: Move cec_notifier to intel_hdmi_connector_unregister, v2.

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.
URL   : https://patchwork.freedesktop.org/series/73362/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16541


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][1] -> [DMESG-FAIL][2] ([i915#722])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16541/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_chamelium@dp-edid-read:
- fi-cml-u2:  [PASS][3] -> [FAIL][4] ([i915#217] / [i915#976])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16541/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html

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

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

  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
  [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976


Participating hosts (45 -> 44)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-gdg-551 
fi-bsw-kefka fi-kbl-7560u fi-kbl-r 
  Missing(8): fi-ilk-m540 fi-bdw-5557u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-ivb-3770 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16541

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16541: cc5862847c1377172ac432312ea31ecfddcc46e6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cc5862847c13 drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: conversion to struct drm_device based logging macros.

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: conversion to struct drm_device based logging macros.
URL   : https://patchwork.freedesktop.org/series/73354/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16540


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-cml-s:   [PASS][1] -> [DMESG-FAIL][2] ([i915#877])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16540/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

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

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

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


Participating hosts (45 -> 43)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-r 
  Missing(9): fi-ilk-m540 fi-bdw-5557u fi-byt-squawks fi-bsw-cyan 
fi-bwr-2160 fi-kbl-guc fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16540

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16540: 7a0324dd9a391e02aec32c0afcec6cf12740e324 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7a0324dd9a39 drm/i915/hdcp: conversion to struct drm_device based logging 
macros.

== Logs ==

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


[Intel-gfx] [PATCH i-g-t v2 3/5] i915/gem_ctx_isolation: Check engine relative registers - Part 2

2020-02-12 Thread Dale B Stimson
Modify previous i915/gem_ctx_isolation "Check engine relative registers"
for modified mmio_base infrastructure.

Signed-off-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 87 +++---
 1 file changed, 48 insertions(+), 39 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index eff4b1df2..07ffbb84a 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -233,12 +233,12 @@ static bool ignore_register(uint32_t offset, uint32_t 
mmio_base)
 static void tmpl_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  uint32_t handle,
  uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *regs;
 
@@ -278,12 +278,12 @@ static void tmpl_regs(int fd,
 static uint32_t read_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int flags)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_relocation_entry *reloc;
@@ -359,12 +359,12 @@ static uint32_t read_regs(int fd,
 static void write_regs(int fd,
   uint32_t ctx,
   const struct intel_execution_engine2 *e,
+  uint32_t mmio_base,
   unsigned int flags,
   uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
struct drm_i915_gem_exec_object2 obj;
struct drm_i915_gem_execbuffer2 execbuf;
unsigned int batch_size;
@@ -420,13 +420,13 @@ static void write_regs(int fd,
 static void restore_regs(int fd,
 uint32_t ctx,
 const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 unsigned int flags,
 uint32_t regs)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
@@ -498,12 +498,12 @@ static void restore_regs(int fd,
 __attribute__((unused))
 static void dump_regs(int fd,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int regs)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *out;
 
@@ -541,9 +541,9 @@ static void dump_regs(int fd,
 }
 
 static void compare_regs(int fd, const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 uint32_t A, uint32_t B, const char *who)
 {
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int num_errors;
unsigned int regs_size;
uint32_t *a, *b;
@@ -596,6 +596,7 @@ static void compare_regs(int fd, const struct 
intel_execution_engine2 *e,
 
 static void nonpriv(int fd,
const struct intel_execution_engine2 *e,
+   uint32_t mmio_base,
unsigned int flags)
 {
static const uint32_t values[] = {
@@ -623,16 +624,16 @@ static void nonpriv(int fd,
 
ctx = gem_context_clone_with_engines(fd, 0);
 
-   tmpl = read_regs(fd, ctx, e, flags);
-   regs[0] = read_regs(fd, ctx, e, flags);
+   tmpl = read_regs(fd, ctx, e, mmio_base, flags);
+   regs[0] = read_regs(fd, ctx, e, mmio_base, flags);
 
-   tmpl_regs(fd, ctx, e, tmpl, values[v]);
+   tmpl_regs(fd, ctx, e, mmio_base, tmpl, values[v]);
 
spin = igt_spin_new(fd, .ctx = ctx, .engine = e->flags);
 

[Intel-gfx] [PATCH i-g-t v2 1/5] i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)

2020-02-12 Thread Dale B Stimson
Signed-off-by: Dale B Stimson 
---
 lib/Makefile.sources |   2 +
 lib/i915/gem_mmio_base.c | 353 +++
 lib/i915/gem_mmio_base.h |  19 +++
 lib/igt.h|   1 +
 lib/meson.build  |   1 +
 5 files changed, 376 insertions(+)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 3e573f267..4c5d50d5d 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ lib_source_list =   \
i915/gem_context.h  \
i915/gem_engine_topology.c  \
i915/gem_engine_topology.h  \
+   i915/gem_mmio_base.c\
+   i915/gem_mmio_base.h\
i915/gem_scheduler.c\
i915/gem_scheduler.h\
i915/gem_submission.c   \
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
new file mode 100644
index 0..d1b83221a
--- /dev/null
+++ b/lib/i915/gem_mmio_base.c
@@ -0,0 +1,353 @@
+//  Copyright (C) 2020 Intel Corporation
+//
+//  SPDX-License-Identifier: MIT
+
+#include 
+
+#include 
+
+#include "igt.h"
+
+struct eng_mmio_base_s {
+   char   name[8];
+   uint32_t   mmio_base;
+};
+
+struct eng_mmio_base_table_s {
+   unsigned int   mb_cnt;
+   struct eng_mmio_base_s mb_tab[GEM_MAX_ENGINES];
+};
+
+
+static struct eng_mmio_base_table_s *_gem_engine_mmio_info_dup(
+   const struct eng_mmio_base_table_s *mbpi)
+{
+   struct eng_mmio_base_table_s *mbpo;
+   size_t nbytes;
+
+   nbytes = offsetof(typeof(struct eng_mmio_base_table_s), 
mb_tab[mbpi->mb_cnt]);
+   mbpo = malloc(nbytes);
+   igt_assert(mbpo);
+   memcpy(mbpo, mbpi, nbytes);
+
+   return mbpo;
+}
+
+void gem_engine_mmio_base_info_free(struct eng_mmio_base_table_s *mbp)
+{
+   if (mbp)
+   free(mbp);
+}
+
+static void _gem_engine_mmio_info_legacy_add(struct eng_mmio_base_table_s *mbp,
+   const char *eng_name, uint32_t mmio_base)
+{
+   if (mmio_base) {
+   strncpy(mbp->mb_tab[mbp->mb_cnt].name, eng_name,
+   sizeof(mbp->mb_tab[0].name));
+   mbp->mb_tab[mbp->mb_cnt].mmio_base = mmio_base;
+   mbp->mb_cnt++;
+   }
+}
+
+/**
+ * _gem_engine_mmio_base_info_get_legacy:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Provides per-engine mmio_base information from legacy built-in values
+ * for the case when the information is not otherwise available.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ */
+static struct eng_mmio_base_table_s *_gem_engine_mmio_base_info_get_legacy(int 
fd_dev)
+{
+   int gen;
+   uint32_t mmio_base;
+   struct eng_mmio_base_table_s mbt;
+   struct eng_mmio_base_table_s *mbp;
+
+   memset(, 0, sizeof(mbt));
+
+   gen = intel_gen(intel_get_drm_devid(fd_dev));
+
+   /* The mmio_base values for engine instances 1 and higher cannot
+* be reliability determinated a priori. */
+
+   _gem_engine_mmio_info_legacy_add(, "rcs0", 0x2000);
+   _gem_engine_mmio_info_legacy_add(, "bcs0", 0x22000);
+
+   if (gen < 6)
+   mmio_base = 0x4000;
+   else if (gen < 11)
+   mmio_base = 0x12000;
+   else
+   mmio_base = 0x1c;
+   _gem_engine_mmio_info_legacy_add(, "vcs0", mmio_base);
+
+   if (gen < 11)
+   mmio_base = 0x1a000;
+   else
+   mmio_base = 0x1c8000;
+   _gem_engine_mmio_info_legacy_add(, "vecs0", mmio_base);
+
+   if (mbt.mb_cnt <= 0)
+   return NULL;
+
+   mbp = _gem_engine_mmio_info_dup();
+
+   return mbp;
+}
+
+
+/**
+ * _gem_engine_mmio_base_info_get_debugfs:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Obtains per-engine mmio_base information from debugfs.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ *
+ * Looking in debugfs for per-engine instances of:
+ * 
+ *  ...
+ * MMIO base: 
+ *
+ * Example of relevant lines from debugfs:
+ * vcs0
+ * MMIO base:  0x001c
+ * vcs1
+ * MMIO base:  0x001d
+ *
+ * In order to qualify as the introduction of a new per-engine section, an
+ * input line must consist solely of an engine name.  An engine name must
+ * be 7 or fewer characters in length and must consist of an engine class
+ * name of 3 or more lower case characters followed by an instance number.
+ */
+static struct eng_mmio_base_table_s 

[Intel-gfx] [PATCH i-g-t v2 5/5] i915/gem_ctx_isolation.c - If initialization fails, exit

2020-02-12 Thread Dale B Stimson
At the start of igt_main, failure of the initial tests for successful
initialization transfer control to the end of an igt_fixture block.
>From there, execution of the main per-engine loop is attempted.
Instead, the test should be caused to exit.

If initialization fails, exit.

Signed-off-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 07ffbb84a..b11158dab 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -898,10 +898,13 @@ igt_main
int fd = -1;
struct eng_mmio_base_table_s *mbp = NULL;
uint32_t mmio_base = 0;
+   /* igt_fixture block is skipped if --list-subtests, so start with true. 
*/
+   bool init_successful = true;
 
igt_fixture {
int gen;
 
+   init_successful = false;
fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
igt_require(gem_has_contexts(fd));
@@ -916,8 +919,20 @@ igt_main
igt_skip_on(gen > LAST_KNOWN_GEN);
 
mbp = gem_engine_mmio_base_info_get(fd);
+   init_successful = true;
}
 
+   if (!init_successful) {
+   igt_exit_early();
+   }
+
+   /**
+* With --list-subtests the above igt_fixture block is skipped and so
+* the device is not open.  Because fd < 0, __for_each_physical_engine
+* falls back to a static engine list, which will affect the output
+* of --list-subtests.
+*/
+
/* __for_each_physical_engine switches context to all engines. */
__for_each_physical_engine(fd, e) {
igt_subtest_group {
-- 
2.25.0

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


[Intel-gfx] [PATCH i-g-t v2 2/5] i915/gem_ctx_isolation: Check engine relative registers

2020-02-12 Thread Dale B Stimson
From: Chris Wilson 

Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.

Signed-off-by: Chris Wilson 
Reviewed-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 164 -
 1 file changed, 100 insertions(+), 64 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 1b66fec11..eff4b1df2 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -70,6 +70,7 @@ static const struct named_register {
uint32_t ignore_bits;
uint32_t write_mask; /* some registers bits do not exist */
bool masked;
+   bool relative;
 } nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
@@ -109,7 +110,6 @@ static const struct named_register {
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
{ "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
-   { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
{ "OACTXID", GEN8, RCS0, 0x2364 },
{ "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
@@ -138,79 +138,56 @@ static const struct named_register {
 
{ "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
-   { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
 
/* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
{ "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
{ "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked = 
true },
-   { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
+   { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
{ "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,  
0x731c, .masked = true },
{ "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask = 
~0x10 },
{ "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked = 
true },
{ "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
 
-   { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
{ "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true 
},
 
{ "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
{ "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
 
-   { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
-   { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
-   { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
-
-   { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
-   { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
-   { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
-   { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
-   { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
+   { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
 
{}
 }, ignore_registers[] = {
{ "RCS timestamp", GEN6, ~0u, 0x2358 },
{ "BCS timestamp", GEN7, ~0u, 0x22358 },
 
-   { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
-   { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
-   { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
-
-   { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
-   { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
-   { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
-   { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
-   { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
+   { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
 
/* huc read only */
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2014 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x23b0 },
-
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2000 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2014 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x23b0 },
-
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2000 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2014 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x23b0 },
-
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2000 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2014 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x23b0 },
+   { "BSD 0x2000", GEN11, ALL, 0x2000, .relative = true },
+   { "BSD 0x2014", GEN11, ALL, 0x2014, .relative = true },
+   { "BSD 0x23b0", GEN11, ALL, 0x23b0, .relative = true },
 
{}
 };
 
-static const char *register_name(uint32_t offset, char *buf, size_t len)
+static const char *
+register_name(uint32_t offset, uint32_t mmio_base, char *buf, size_t len)
 {
for (const struct named_register *r = nonpriv_registers; r->name; 

[Intel-gfx] [PATCH i-g-t v2 4/5] lib/igt_core.c - Introduce igt_exit_early()

2020-02-12 Thread Dale B Stimson
Call igt_exit() after dealing with assumptions not valid for early calls.

In particular:

igt_exit() assumes that subtests have been considered for execution.
With --run-subtest, for an early exit (where subtests had not yet been
considered):
- igt_exit() would complain about "Unknown subtest"
- igt_exit() would exit prematurely.

Signed-off-by: Dale B Stimson 
---
 lib/igt_core.c | 27 +++
 lib/igt_core.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 70465130c..78704b93a 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -2028,6 +2028,33 @@ void igt_exit(void)
exit(igt_exitcode);
 }
 
+/**
+ * igt_exit_early()
+ *
+ * Call igt_exit() after dealing with assumptions not valid for early calls.
+ *
+ * In particular:
+ * igt_exit() assumes that subtests have been considered for execution
+ * and complains if a subtest specified by --run-subtest was not executed.
+ * (The expectation is that the subtest would have been executed if it 
existed).
+ *
+ * In particular:
+ * igt_exit() assumes that subtests have been considered for execution.
+ * With --run-subtest, for an early exit (where subtests had not yet been
+ * considered):
+ * - igt_exit() would complain about "Unknown subtest"
+ * - igt_exit() would exit prematurely.
+ */
+void igt_exit_early(void)
+{
+   if (run_single_subtest) {
+   free(run_single_subtest);
+   run_single_subtest = NULL;
+   }
+
+   igt_exit();
+}
+
 /* fork support code */
 static int helper_process_count;
 static pid_t helper_process_pids[] =
diff --git a/lib/igt_core.h b/lib/igt_core.h
index c17a7ba81..a1fe4c361 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -500,6 +500,7 @@ void __igt_fail_assert(const char *domain, const char *file,
   const char *format, ...)
__attribute__((noreturn));
 void igt_exit(void) __attribute__((noreturn));
+void igt_exit_early(void) __attribute__((noreturn));
 void igt_fatal_error(void) __attribute__((noreturn));
 
 /**
-- 
2.25.0

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


[Intel-gfx] [PATCH i-g-t v2 0/5] mmio_base via debugfs infrastructure + gem_ctx_isolation

2020-02-12 Thread Dale B Stimson
v2:
- Introduce and use igt_exit_early() so that a failed initialization
  (in igt_fixture) will not attempt to invoke the per-engine loop.
- Initialize mmio_base db inside initial igt_fixture instead of after.
- Some additional functions handle NULL input mmio_base db pointer.
- Variables mbp and mmio_base initialized to NULL/0 so their values will
  not be uninitialized for --list-subtests.
- Failure to obtain an mmio_base db is now igt_debug instead of
  igt_warn.

This patch series provides infrastructure to allow determination of i915
per-engine mmio_base (which is otherwise sometimes hard to get).  The provided
method uses debugfs mmio_base information if present.  Otherwise, a default
determination is provided when possible.  Also, gem_ctx_isolation is modified
to use the new infrastructure.

For example, on TGL, gem_ctx_isolation (without these or similar changes)
will fail for subtests that use engine vcs1.

The patches in this series are as they are intended to be submitted (subject
to comments), except I would like to squash the two gem_ctx_isolation
"relative registers" patches into one (as discussed below).  Also, function
gem_engine_mmio_base_info_dump() could be removed.

On 2020-01-27, Chris wilson sent to the ML:
  [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
  [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative 
registers
plus the following, which are not addressed here:
  [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in 
sysfs
  [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
  [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property

This patch list is:
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

The first 2020-01-27 patch obtains mmio_base information via sysfs, and depends
on a proposed kernel change that would provide the mmio_base information
via sysfs.  It is unclear when or whether that kernel change will progress.

The mmio_base information used by this patch series is available through
debugfs now (as of kernel 5.4).  If the per-engine mmio_base information is
ever added to sysfs, it would be easy to plug that into the infrastructure
proposed here as an additional higher-priority source of that information.

This submission replaces the first patch (switching from sysfs to debugfs),
retains the second 2020-01-27 patch
  i915/gem_ctx_isolation: Check engine relative registers
and has a third patch that modifies the original second patch to support the
altered API:
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

I propose squashing the two gem_ctx_isolation "relative registers" patches
into one patch with author == "Chris Wilson" if Chris agrees.

Some differences from the 2020-01-27 patches:

The mmio_base information is fetched once into local data structures, and
is obtained from them thereafter instead of being fetched from the kernel
everytime it is wanted.

The function that obtains the mmio_base information is called by a particular
test that wants it, and returns a handle through which the mmio_base can be
requested for any particular engine.

These patches introduce new source files lib/i915/gem_mmio_base.c
and lib/i915/gem_mmio_base.h.  Should the code instead be placed into
lib/i915/gem_engine_topology.c?

Function gem_engine_mmio_base_info_dump presently exists to dump the
mmio_base information to stdout for debugging or informational purposes.
This function is not currently called.  I presume this function should
be removed.  Is there any desire to keep it around for future use?

The 2020-01-27 patches define function gem_engine_mmio_base() with its first
parameter as "fd".  The new patches replace the first parameter with the
mmio_base object handle.

Chris Wilson (1):
  i915/gem_ctx_isolation: Check engine relative registers

Dale B Stimson (4):
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers - Part 2
  lib/igt_core.c - Introduce igt_exit_early()
  i915/gem_ctx_isolation.c - If initialization fails, exit

 lib/Makefile.sources   |   2 +
 lib/i915/gem_mmio_base.c   | 353 +
 lib/i915/gem_mmio_base.h   |  19 ++
 lib/igt.h  |   1 +
 lib/igt_core.c |  27 +++
 lib/igt_core.h |   1 +
 lib/meson.build|   1 +
 tests/i915/gem_ctx_isolation.c | 244 ++-
 8 files changed, 556 insertions(+), 92 deletions(-)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

-- 
2.25.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 drm/i915/hdcp: conversion to struct drm_device based logging macros.

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: conversion to struct drm_device based logging macros.
URL   : https://patchwork.freedesktop.org/series/73354/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7a0324dd9a39 drm/i915/hdcp: conversion to struct drm_device based logging 
macros.
-:177: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#177: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:754:
+   intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
+ cpu_transcoder, port)));

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

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


[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP misc (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: HDCP misc (rev2)
URL   : https://patchwork.freedesktop.org/series/73345/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16539


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-hsw-4770r:   [PASS][1] -> [TIMEOUT][2] ([fdo#112271] / [i915#1084])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16539/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
- fi-byt-n2820:   [PASS][3] -> [INCOMPLETE][4] ([i915#45])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16539/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

  * igt@i915_selftest@live_gtt:
- fi-icl-u2:  [PASS][5] -> [TIMEOUT][6] ([fdo#112271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-icl-u2/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16539/fi-icl-u2/igt@i915_selftest@live_gtt.html
- fi-bdw-5557u:   [PASS][7] -> [TIMEOUT][8] ([fdo#112271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16539/fi-bdw-5557u/igt@i915_selftest@live_gtt.html

  
 Warnings 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [INCOMPLETE][9] ([i915#45]) -> [TIMEOUT][10] 
([fdo#112271] / [i915#1084] / [i915#816])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16539/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

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

  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 42)
--

  Additional (6): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-kbl-r 
  Missing(9): fi-ilk-m540 fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-lmem fi-byt-clapper fi-bdw-samus fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16539

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16539: 3e84cadbe86fb79e9872d92a1d850f08e47c3c29 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3e84cadbe86f drm/i915/hdcp: conversion to struct drm_device based logging 
macros.
e8f4a3362d7d drm/i915: dont retry stream management at seq_num_m roll over
d18de5c49d15 drm/i915: terminate reauth at stream management failure
cf23cf2eff64 drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS
3498b51721f6 drm/hdcp: optimizing the srm handling

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX

2020-02-12 Thread Brian Welty


On 2/12/2020 4:34 PM, Chris Wilson wrote:
> Quoting Brian Welty (2020-02-13 00:14:18)
>> For DGFX devices, the MOCS control value is not initialized or used.
> 
> Then why is the table populated?
> -Chris
> 

The format has changed (been reduced?) for DGFX.  
drm_i915_mocs_entry.l3cc_value is what is still initialized/used.
Probably first needed is the patch that defines the table entries for DGFX.
Ugh, I didn't notice this wasn't applied yet.  Let me ask about this.

-Brian

___
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/dp, i915: eDP DPCD backlight control detection fixes (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/dp, i915: eDP DPCD backlight control detection fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/72991/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16538


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2:  [PASS][1] -> [INCOMPLETE][2] ([i915#198])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16538/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][3] -> [DMESG-FAIL][4] ([i915#1052])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16538/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
- fi-cml-s:   [PASS][5] -> [DMESG-FAIL][6] ([i915#877])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16538/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-ehl-1}: [INCOMPLETE][7] ([i915#937]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16538/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html

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

  [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (45 -> 42)
--

  Additional (7): fi-hsw-peppy fi-skl-6770hq fi-glk-dsi fi-gdg-551 fi-bsw-kefka 
fi-kbl-7560u fi-kbl-r 
  Missing(10): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-byt-squawks 
fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-cfl-8109u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16538

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16538: c5bf6ddf092a43ad512a0dd40d0b1958aab2a506 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c5bf6ddf092a drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels
772152d6d874 drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K 
AMOLED panel
94ec9e5e69b6 drm/dp: Introduce EDID-based quirks

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX

2020-02-12 Thread Chris Wilson
Quoting Brian Welty (2020-02-13 00:14:18)
> For DGFX devices, the MOCS control value is not initialized or used.

Then why is the table populated?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP misc (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: HDCP misc (rev2)
URL   : https://patchwork.freedesktop.org/series/73345/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3498b51721f6 drm/hdcp: optimizing the srm handling
cf23cf2eff64 drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS
d18de5c49d15 drm/i915: terminate reauth at stream management failure
e8f4a3362d7d drm/i915: dont retry stream management at seq_num_m roll over
3e84cadbe86f drm/i915/hdcp: conversion to struct drm_device based logging 
macros.
-:175: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#175: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:754:
+   intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
+ cpu_transcoder, port)));

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

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


[Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX

2020-02-12 Thread Brian Welty
For DGFX devices, the MOCS control value is not initialized or used.
Update the selftest to skip reading and checking control values
for these devices.

References: e6e2ac07118b ("drm/i915: do not set MOCS control values on dgfx")
Fixes: 3fb33cd32ffd ("drm/i915/selftests: Add coverage of mocs registers")
Signed-off-by: Brian Welty 
---
 drivers/gpu/drm/i915/gt/selftest_mocs.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c 
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index de1f83100fb6..8a94a546d580 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -199,7 +199,7 @@ static int check_l3cc_table(struct intel_engine_cs *engine,
return 0;
 }
 
-static int check_mocs_engine(struct live_mocs *arg,
+static int check_mocs_engine(struct intel_gt *gt, struct live_mocs *arg,
 struct intel_context *ce)
 {
struct i915_vma *vma = arg->scratch;
@@ -222,7 +222,7 @@ static int check_mocs_engine(struct live_mocs *arg,
 
/* Read the mocs tables back using SRM */
offset = i915_ggtt_offset(vma);
-   if (!err)
+   if (!err && !IS_DGFX(gt->i915))
err = read_mocs_table(rq, >table, );
if (!err && ce->engine->class == RENDER_CLASS)
err = read_l3cc_table(rq, >table, );
@@ -235,7 +235,7 @@ static int check_mocs_engine(struct live_mocs *arg,
 
/* Compare the results against the expected tables */
vaddr = arg->vaddr;
-   if (!err)
+   if (!err && !IS_DGFX(gt->i915))
err = check_mocs_table(ce->engine, >table, );
if (!err && ce->engine->class == RENDER_CLASS)
err = check_l3cc_table(ce->engine, >table, );
@@ -262,7 +262,7 @@ static int live_mocs_kernel(void *arg)
 
for_each_engine(engine, gt, id) {
intel_engine_pm_get(engine);
-   err = check_mocs_engine(, engine->kernel_context);
+   err = check_mocs_engine(gt, , engine->kernel_context);
intel_engine_pm_put(engine);
if (err)
break;
@@ -295,7 +295,7 @@ static int live_mocs_clean(void *arg)
break;
}
 
-   err = check_mocs_engine(, ce);
+   err = check_mocs_engine(gt, , ce);
intel_context_put(ce);
if (err)
break;
@@ -332,7 +332,7 @@ static int active_engine_reset(struct intel_context *ce,
return err;
 }
 
-static int __live_mocs_reset(struct live_mocs *mocs,
+static int __live_mocs_reset(struct intel_gt *gt, struct live_mocs *mocs,
 struct intel_context *ce)
 {
int err;
@@ -341,7 +341,7 @@ static int __live_mocs_reset(struct live_mocs *mocs,
if (err)
return err;
 
-   err = check_mocs_engine(mocs, ce);
+   err = check_mocs_engine(gt, mocs, ce);
if (err)
return err;
 
@@ -349,13 +349,13 @@ static int __live_mocs_reset(struct live_mocs *mocs,
if (err)
return err;
 
-   err = check_mocs_engine(mocs, ce);
+   err = check_mocs_engine(gt, mocs, ce);
if (err)
return err;
 
-   intel_gt_reset(ce->engine->gt, ce->engine->mask, "mocs");
+   intel_gt_reset(gt, ce->engine->mask, "mocs");
 
-   err = check_mocs_engine(mocs, ce);
+   err = check_mocs_engine(gt, mocs, ce);
if (err)
return err;
 
@@ -390,7 +390,7 @@ static int live_mocs_reset(void *arg)
}
 
intel_engine_pm_get(engine);
-   err = __live_mocs_reset(, ce);
+   err = __live_mocs_reset(gt, , ce);
intel_engine_pm_put(engine);
 
intel_context_put(ce);
-- 
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/2] drm/i915/mst: Set intel_dp_set_m_n() for MST slaves

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/mst: Set intel_dp_set_m_n() for 
MST slaves
URL   : https://patchwork.freedesktop.org/series/7/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7926 -> Patchwork_16536


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([CI#80] / [fdo#106070] 
/ [i915#424])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  
  [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424


Participating hosts (45 -> 40)
--

  Additional (8): fi-hsw-peppy fi-skl-6770hq fi-bdw-gvtdvm fi-glk-dsi 
fi-gdg-551 fi-bsw-kefka fi-kbl-7560u fi-kbl-r 
  Missing(13): fi-ilk-m540 fi-bdw-samus fi-bsw-n3050 fi-byt-squawks 
fi-bsw-cyan fi-snb-2520m fi-kbl-7500u fi-ctg-p8600 fi-cfl-8109u fi-blb-e6850 
fi-byt-clapper fi-skl-6600u fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7926 -> Patchwork_16536

  CI-20190529: 20190529
  CI_DRM_7926: 6b2fe829d300abf285e9db8b252ffacd216df3ed @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16536: fd8890d26afc19e2b5953c7dfad3d1cf07b276b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fd8890d26afc drm/i915/display/tgl: Enable hotplug detection in TC5 and TC6
bf8f5f0801d3 drm/i915/mst: Set intel_dp_set_m_n() for MST slaves

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/index.html
___
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/2] drm/i915: Poison rings after use

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Poison rings after use
URL   : https://patchwork.freedesktop.org/series/73327/
State : failure

== Summary ==

Applying: drm/i915: Poison rings after use
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_request.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915/selftests: Sabotague the RING_HEAD
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/selftest_lrc.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

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


Re: [Intel-gfx] [PATCH i-g-t 0/3] mmio_base via debugfs infrastructure + gem_ctx_isolation

2020-02-12 Thread Dale B Stimson
My apologies for the multiple submissions of this patch series.  I had to
work out an issue with an unsuspected git config value in order to make the
references function with patchwork.


On 2020-02-12 14:34:28, Dale B Stimson wrote:
> This patch series provides infrastructure to allow determination of i915
> per-engine mmio_base (which is otherwise sometimes hard to get).  The provided
> method uses debugfs mmio_base information if present.  Otherwise, a default
> determination is provided when possible.  Also, gem_ctx_isolation is modified
> to use the new infrastructure.
> 
> For example, on TGL, gem_ctx_isolation (without these or similar changes)
> will fail for subtests that use engine vcs1.
> 
> The patches in this series are as they are intended to be submitted (subject
> to comments), except I would like to squash the two gem_ctx_isolation
> "relative registers" patches into one (as discussed below).  Also, function
> gem_engine_mmio_base_info_dump() could be removed.
> 
> On 2020-01-27, Chris wilson sent to the ML:
>   [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
>   [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative 
> registers
> plus the following, which are not addressed here:
>   [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in 
> sysfs
>   [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
>   [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property
> 
> This patch list is:
>   i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
>   i915/gem_ctx_isolation: Check engine relative registers
>   i915/gem_ctx_isolation: Check engine relative registers - Part 2
> 
> The first 2020-01-27 patch obtains mmio_base information via sysfs, and 
> depends
> on a proposed kernel change that would provide the mmio_base information
> via sysfs.  It is unclear when or whether that kernel change will progress.
> 
> The mmio_base information used by this patch series is available through
> debugfs now (as of kernel 5.4).  If the per-engine mmio_base information is
> ever added to sysfs, it would be easy to plug that into the infrastructure
> proposed here as an additional higher-priority source of that information.
> 
> This submission replaces the first patch (switching from sysfs to debugfs),
> retains the second 2020-01-27 patch
>   i915/gem_ctx_isolation: Check engine relative registers
> and has a third patch that modifies the original second patch to support the
> altered API:
>   i915/gem_ctx_isolation: Check engine relative registers - Part 2
> 
> I propose squashing the two gem_ctx_isolation "relative registers" patches
> into one patch with author == "Chris Wilson" if Chris agrees.
> 
> Some differences from the 2020-01-27 patches:
> 
> The mmio_base information is fetched once into local data structures, and
> is obtained from them thereafter instead of being fetched from the kernel
> everytime it is wanted.
> 
> The function that obtains the mmio_base information is called by a particular
> test that wants it, and returns a handle through which the mmio_base can be
> requested for any particular engine.
> 
> These patches introduce new source files lib/i915/gem_mmio_base.c
> and lib/i915/gem_mmio_base.h.  Should the code instead be placed into
> lib/i915/gem_engine_topology.c?
> 
> Function gem_engine_mmio_base_info_dump presently exists to dump the
> mmio_base information to stdout for debugging or informational purposes.
> This function is not currently called.  I presume this function should
> be removed.  Is there any desire to keep it around for future use?
> 
> The 2020-01-27 patches define function gem_engine_mmio_base() with its first
> parameter as "fd".  The new patches replace the first parameter with the
> mmio_base object handle.
> 
> Chris Wilson (1):
>   i915/gem_ctx_isolation: Check engine relative registers
> 
> Dale B Stimson (2):
>   i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
>   i915/gem_ctx_isolation: Check engine relative registers - Part 2
> 
>  lib/Makefile.sources   |   2 +
>  lib/i915/gem_mmio_base.c   | 346 +
>  lib/i915/gem_mmio_base.h   |  19 ++
>  lib/igt.h  |   1 +
>  lib/meson.build|   1 +
>  tests/i915/gem_ctx_isolation.c | 229 +-
>  6 files changed, 506 insertions(+), 92 deletions(-)
>  create mode 100644 lib/i915/gem_mmio_base.c
>  create mode 100644 lib/i915/gem_mmio_base.h
> 
> -- 
> 2.25.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t 2/3] i915/gem_ctx_isolation: Check engine relative registers

2020-02-12 Thread Dale B Stimson
From: Chris Wilson 

Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.

Signed-off-by: Chris Wilson 
Reviewed-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 164 -
 1 file changed, 100 insertions(+), 64 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 1b66fec11..eff4b1df2 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -70,6 +70,7 @@ static const struct named_register {
uint32_t ignore_bits;
uint32_t write_mask; /* some registers bits do not exist */
bool masked;
+   bool relative;
 } nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
@@ -109,7 +110,6 @@ static const struct named_register {
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
{ "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
-   { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
{ "OACTXID", GEN8, RCS0, 0x2364 },
{ "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
@@ -138,79 +138,56 @@ static const struct named_register {
 
{ "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
-   { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
 
/* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
{ "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
{ "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked = 
true },
-   { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
+   { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
{ "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,  
0x731c, .masked = true },
{ "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask = 
~0x10 },
{ "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked = 
true },
{ "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
 
-   { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
{ "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true 
},
 
{ "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
{ "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
 
-   { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
-   { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
-   { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
-
-   { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
-   { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
-   { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
-   { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
-   { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
+   { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
 
{}
 }, ignore_registers[] = {
{ "RCS timestamp", GEN6, ~0u, 0x2358 },
{ "BCS timestamp", GEN7, ~0u, 0x22358 },
 
-   { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
-   { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
-   { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
-
-   { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
-   { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
-   { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
-   { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
-   { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
+   { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
 
/* huc read only */
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2014 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x23b0 },
-
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2000 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2014 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x23b0 },
-
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2000 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2014 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x23b0 },
-
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2000 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2014 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x23b0 },
+   { "BSD 0x2000", GEN11, ALL, 0x2000, .relative = true },
+   { "BSD 0x2014", GEN11, ALL, 0x2014, .relative = true },
+   { "BSD 0x23b0", GEN11, ALL, 0x23b0, .relative = true },
 
{}
 };
 
-static const char *register_name(uint32_t offset, char *buf, size_t len)
+static const char *
+register_name(uint32_t offset, uint32_t mmio_base, char *buf, size_t len)
 {
for (const struct named_register *r = nonpriv_registers; r->name; 

[Intel-gfx] [PATCH i-g-t 0/3] mmio_base via debugfs infrastructure + gem_ctx_isolation

2020-02-12 Thread Dale B Stimson
This patch series provides infrastructure to allow determination of i915
per-engine mmio_base (which is otherwise sometimes hard to get).  The provided
method uses debugfs mmio_base information if present.  Otherwise, a default
determination is provided when possible.  Also, gem_ctx_isolation is modified
to use the new infrastructure.

For example, on TGL, gem_ctx_isolation (without these or similar changes)
will fail for subtests that use engine vcs1.

The patches in this series are as they are intended to be submitted (subject
to comments), except I would like to squash the two gem_ctx_isolation
"relative registers" patches into one (as discussed below).  Also, function
gem_engine_mmio_base_info_dump() could be removed.

On 2020-01-27, Chris wilson sent to the ML:
  [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
  [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative 
registers
plus the following, which are not addressed here:
  [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in 
sysfs
  [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
  [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property

This patch list is:
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

The first 2020-01-27 patch obtains mmio_base information via sysfs, and depends
on a proposed kernel change that would provide the mmio_base information
via sysfs.  It is unclear when or whether that kernel change will progress.

The mmio_base information used by this patch series is available through
debugfs now (as of kernel 5.4).  If the per-engine mmio_base information is
ever added to sysfs, it would be easy to plug that into the infrastructure
proposed here as an additional higher-priority source of that information.

This submission replaces the first patch (switching from sysfs to debugfs),
retains the second 2020-01-27 patch
  i915/gem_ctx_isolation: Check engine relative registers
and has a third patch that modifies the original second patch to support the
altered API:
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

I propose squashing the two gem_ctx_isolation "relative registers" patches
into one patch with author == "Chris Wilson" if Chris agrees.

Some differences from the 2020-01-27 patches:

The mmio_base information is fetched once into local data structures, and
is obtained from them thereafter instead of being fetched from the kernel
everytime it is wanted.

The function that obtains the mmio_base information is called by a particular
test that wants it, and returns a handle through which the mmio_base can be
requested for any particular engine.

These patches introduce new source files lib/i915/gem_mmio_base.c
and lib/i915/gem_mmio_base.h.  Should the code instead be placed into
lib/i915/gem_engine_topology.c?

Function gem_engine_mmio_base_info_dump presently exists to dump the
mmio_base information to stdout for debugging or informational purposes.
This function is not currently called.  I presume this function should
be removed.  Is there any desire to keep it around for future use?

The 2020-01-27 patches define function gem_engine_mmio_base() with its first
parameter as "fd".  The new patches replace the first parameter with the
mmio_base object handle.

Chris Wilson (1):
  i915/gem_ctx_isolation: Check engine relative registers

Dale B Stimson (2):
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

 lib/Makefile.sources   |   2 +
 lib/i915/gem_mmio_base.c   | 346 +
 lib/i915/gem_mmio_base.h   |  19 ++
 lib/igt.h  |   1 +
 lib/meson.build|   1 +
 tests/i915/gem_ctx_isolation.c | 229 +-
 6 files changed, 506 insertions(+), 92 deletions(-)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

-- 
2.25.0

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


[Intel-gfx] [PATCH i-g-t 1/3] i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)

2020-02-12 Thread Dale B Stimson
Signed-off-by: Dale B Stimson 
---
 lib/Makefile.sources |   2 +
 lib/i915/gem_mmio_base.c | 346 +++
 lib/i915/gem_mmio_base.h |  19 +++
 lib/igt.h|   1 +
 lib/meson.build  |   1 +
 5 files changed, 369 insertions(+)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 3e573f267..4c5d50d5d 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ lib_source_list =   \
i915/gem_context.h  \
i915/gem_engine_topology.c  \
i915/gem_engine_topology.h  \
+   i915/gem_mmio_base.c\
+   i915/gem_mmio_base.h\
i915/gem_scheduler.c\
i915/gem_scheduler.h\
i915/gem_submission.c   \
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
new file mode 100644
index 0..8718c092f
--- /dev/null
+++ b/lib/i915/gem_mmio_base.c
@@ -0,0 +1,346 @@
+//  Copyright (C) 2020 Intel Corporation
+//
+//  SPDX-License-Identifier: MIT
+
+#include 
+
+#include 
+
+#include "igt.h"
+
+struct eng_mmio_base_s {
+   char   name[8];
+   uint32_t   mmio_base;
+};
+
+struct eng_mmio_base_table_s {
+   unsigned int   mb_cnt;
+   struct eng_mmio_base_s mb_tab[GEM_MAX_ENGINES];
+};
+
+
+static struct eng_mmio_base_table_s *_gem_engine_mmio_info_dup(
+   const struct eng_mmio_base_table_s *mbpi)
+{
+   struct eng_mmio_base_table_s *mbpo;
+   size_t nbytes;
+
+   nbytes = offsetof(typeof(struct eng_mmio_base_table_s), 
mb_tab[mbpi->mb_cnt]);
+   mbpo = malloc(nbytes);
+   igt_assert(mbpo);
+   memcpy(mbpo, mbpi, nbytes);
+
+   return mbpo;
+}
+
+void gem_engine_mmio_base_info_free(struct eng_mmio_base_table_s *mbp)
+{
+   free(mbp);
+}
+
+static void _gem_engine_mmio_info_legacy_add(struct eng_mmio_base_table_s *mbp,
+   const char *eng_name, uint32_t mmio_base)
+{
+   if (mmio_base) {
+   strncpy(mbp->mb_tab[mbp->mb_cnt].name, eng_name,
+   sizeof(mbp->mb_tab[0].name));
+   mbp->mb_tab[mbp->mb_cnt].mmio_base = mmio_base;
+   mbp->mb_cnt++;
+   }
+}
+
+/**
+ * _gem_engine_mmio_base_info_get_legacy:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Provides per-engine mmio_base information from legacy built-in values
+ * for the case when the information is not otherwise available.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ */
+static struct eng_mmio_base_table_s *_gem_engine_mmio_base_info_get_legacy(int 
fd_dev)
+{
+   int gen;
+   uint32_t mmio_base;
+   struct eng_mmio_base_table_s mbt;
+   struct eng_mmio_base_table_s *mbp;
+
+   memset(, 0, sizeof(mbt));
+
+   gen = intel_gen(intel_get_drm_devid(fd_dev));
+
+   /* The mmio_base values for engine instances 1 and higher cannot
+* be reliability determinated a priori. */
+
+   _gem_engine_mmio_info_legacy_add(, "rcs0", 0x2000);
+   _gem_engine_mmio_info_legacy_add(, "bcs0", 0x22000);
+
+   if (gen < 6)
+   mmio_base = 0x4000;
+   else if (gen < 11)
+   mmio_base = 0x12000;
+   else
+   mmio_base = 0x1c;
+   _gem_engine_mmio_info_legacy_add(, "vcs0", mmio_base);
+
+   if (gen < 11)
+   mmio_base = 0x1a000;
+   else
+   mmio_base = 0x1c8000;
+   _gem_engine_mmio_info_legacy_add(, "vecs0", mmio_base);
+
+   if (mbt.mb_cnt <= 0)
+   return NULL;
+
+   mbp = _gem_engine_mmio_info_dup();
+
+   return mbp;
+}
+
+
+/**
+ * _gem_engine_mmio_base_info_get_debugfs:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Obtains per-engine mmio_base information from debugfs.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ *
+ * Looking in debugfs for per-engine instances of:
+ * 
+ *  ...
+ * MMIO base: 
+ *
+ * Example of relevant lines from debugfs:
+ * vcs0
+ * MMIO base:  0x001c
+ * vcs1
+ * MMIO base:  0x001d
+ *
+ * In order to qualify as the introduction of a new per-engine section, an
+ * input line must consist solely of an engine name.  An engine name must
+ * be 7 or fewer characters in length and must consist of an engine class
+ * name of 3 or more lower case characters followed by an instance number.
+ */
+static struct eng_mmio_base_table_s 
*_gem_engine_mmio_base_info_get_debugfs(int fd_dev)
+{
+ 

[Intel-gfx] [PATCH i-g-t 3/3] i915/gem_ctx_isolation: Check engine relative registers - Part 2

2020-02-12 Thread Dale B Stimson
Modify previous i915/gem_ctx_isolation "Check engine relative registers"
for modified mmio_base infrastructure.

Signed-off-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 87 +++---
 1 file changed, 48 insertions(+), 39 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index eff4b1df2..eec78c729 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -233,12 +233,12 @@ static bool ignore_register(uint32_t offset, uint32_t 
mmio_base)
 static void tmpl_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  uint32_t handle,
  uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *regs;
 
@@ -278,12 +278,12 @@ static void tmpl_regs(int fd,
 static uint32_t read_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int flags)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_relocation_entry *reloc;
@@ -359,12 +359,12 @@ static uint32_t read_regs(int fd,
 static void write_regs(int fd,
   uint32_t ctx,
   const struct intel_execution_engine2 *e,
+  uint32_t mmio_base,
   unsigned int flags,
   uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
struct drm_i915_gem_exec_object2 obj;
struct drm_i915_gem_execbuffer2 execbuf;
unsigned int batch_size;
@@ -420,13 +420,13 @@ static void write_regs(int fd,
 static void restore_regs(int fd,
 uint32_t ctx,
 const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 unsigned int flags,
 uint32_t regs)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
@@ -498,12 +498,12 @@ static void restore_regs(int fd,
 __attribute__((unused))
 static void dump_regs(int fd,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int regs)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *out;
 
@@ -541,9 +541,9 @@ static void dump_regs(int fd,
 }
 
 static void compare_regs(int fd, const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 uint32_t A, uint32_t B, const char *who)
 {
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int num_errors;
unsigned int regs_size;
uint32_t *a, *b;
@@ -596,6 +596,7 @@ static void compare_regs(int fd, const struct 
intel_execution_engine2 *e,
 
 static void nonpriv(int fd,
const struct intel_execution_engine2 *e,
+   uint32_t mmio_base,
unsigned int flags)
 {
static const uint32_t values[] = {
@@ -623,16 +624,16 @@ static void nonpriv(int fd,
 
ctx = gem_context_clone_with_engines(fd, 0);
 
-   tmpl = read_regs(fd, ctx, e, flags);
-   regs[0] = read_regs(fd, ctx, e, flags);
+   tmpl = read_regs(fd, ctx, e, mmio_base, flags);
+   regs[0] = read_regs(fd, ctx, e, mmio_base, flags);
 
-   tmpl_regs(fd, ctx, e, tmpl, values[v]);
+   tmpl_regs(fd, ctx, e, mmio_base, tmpl, values[v]);
 
spin = igt_spin_new(fd, .ctx = ctx, .engine = e->flags);
 

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: make a gt sysfs group and move power management files

2020-02-12 Thread Tvrtko Ursulin



On 11/02/2020 21:06, Andi Shyti wrote:

Hi Tvrtko,


+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+   struct kobject *parent = 
kobject_get(>i915->drm.primary->kdev->kobj);


Does this needs a kobject_put to balance out somewhere?


Yes, I forgot the two kobject_put that are needed.


+   int ret;
+
+   gt->kobj = kobject_create_and_add("gt", parent);
+   if (!gt->kobj) {
+   pr_err("failed to initialize sysfs file\n");
+   return;
+   }
+
+   dev_set_drvdata(kobj_to_dev(gt->kobj), gt);
+
+   ret = sysfs_create_files(gt->kobj, gt_attrs);
+   if (ret)
+   pr_err("failed to create sysfs gt info files\n");


I can't remember which log helper takes in the device and prefixes that
string but I think it could be useful here, since the error is otherwise
eaten.


pr_* is used a lot in gt/. Playing with the dev pointer I
can use "dev_err(dev,...)"


+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+   if (!gt->kobj)
+   return;
+
+   intel_gt_sysfs_pm_remove(gt, gt->kobj);
+   sysfs_remove_files(gt->kobj, gt_attrs);


Why is this asymmetrical to creation?


Because in V1 gt_attrs and whatever was created in sysfs_gt_pm
was in the same group, but it desn't matter.


I mean you call intel_gt_sysfs_pm_init
two times with different roots, so why not intel_gt_sysfs_pm_remove also
twice with different roots?


Because I forgot them in the cleanups :)


Next version incoming soon? :)


+   /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/* or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+   if (strcmp(kobj->name, "gt")) {
+   pr_warn("the interface is obsolete, use gt/\n");


I think the message will need to be a bit more verbose since it is intended
for users. I don't have any suggestions straight away apart from googling to
find similar examples from the past and other subsystems.


Yes, I couldn't come up with a better message in 80 characters,
and I can use dev_warn instead of pr_warn.


Maybe we even need to log this once. Well we may need to log the 
offending process name/pid. Not sure if we can manage once on top of 
that.. sounds too hard. So maybe just name/pid.





+static ssize_t rc6_enable_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev);


The rest of code is unchanged apart from this same line in all show/store
vfuncs?


yes, more or less.


Cool, just so I know what I don't have to cross-reference too much.

Regards,

Tvrtko

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Commit early to GuC (rev3)

2020-02-12 Thread Patchwork
== Series Details ==

Series: Commit early to GuC (rev3)
URL   : https://patchwork.freedesktop.org/series/72031/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7925 -> Patchwork_16535


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-cml-u2:  [PASS][1] -> [FAIL][2] ([i915#217])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7925/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16535/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html

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

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][5] ([i915#178]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7925/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16535/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gtt:
- {fi-tgl-dsi}:   [TIMEOUT][7] ([fdo#112126] / [fdo#112271]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7925/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16535/fi-tgl-dsi/igt@i915_selftest@live_gtt.html

  * igt@i915_selftest@live_hangcheck:
- fi-icl-y:   [INCOMPLETE][9] ([fdo#108569]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7925/fi-icl-y/igt@i915_selftest@live_hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16535/fi-icl-y/igt@i915_selftest@live_hangcheck.html

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

  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (42 -> 43)
--

  Additional (8): fi-ivb-3770 fi-cfl-8109u fi-skl-6700k2 fi-skl-lmem 
fi-blb-e6850 fi-kbl-r fi-skl-6600u fi-snb-2600 
  Missing(7): fi-hsw-peppy fi-byt-squawks fi-glk-dsi fi-ctg-p8600 
fi-gdg-551 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7925 -> Patchwork_16535

  CI-20190529: 20190529
  CI_DRM_7925: b266b79c3de9874e0f991b6a9cc284a424094649 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5437: ae42fedfd0c536c560e8e17b06d9c7b94a4e8f0c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16535: 70b2b644b94a9a333ba373ea47c758c7d581368f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

70b2b644b94a HAX: drm/i915: default to enable_guc=2
e5b2f4d6ca34 drm/i915/uc: consolidate firmware cleanup
6df67d7fcd06 drm/i915/uc: Abort early on uc_init failure
c7b983206d15 drm/i915/guc: Apply new uC status tracking to GuC submission as 
well
300e9108bf45 drm/i915/uc: Improve tracking of uC init status
ac5ee731ad09 drm/i915/uc: autogenerate uC checker functions
53a7bb512097 drm/i915/uc: Update the FW status on injected fetch error
9c3bd7cffa07 drm/i915/guc: Kill USES_GUC_SUBMISSION macro
434763d74348 drm/i915/guc: Kill USES_GUC macro
86c2261830f8 drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info

== Logs ==

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


Re: [Intel-gfx] [PATCH v3 08/10] drm/i915/uc: Abort early on uc_init failure

2020-02-12 Thread Daniele Ceraolo Spurio




On 2/11/20 5:47 PM, Andi Shyti wrote:

Hi Daniele,


+   if (intel_uc_uses_huc(uc)) {
+   ret = intel_huc_init(huc);


are we ever going to call intel_huc_init() if
!intel_uc_uses_huc()? if not, why don't check intel_uc_uses_huc()
inside intel_huc_init()? just to avoid always the double "if".


I'm actually plotting another refactoring of the init/fini flows as I 
don't like how we toggle the FW states at the moment. I can bundle this 
change with that.


Daniele



Not a big deal though:

Reviewed-by: Andi Shyti 

Andi


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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Commit early to GuC (rev3)

2020-02-12 Thread Patchwork
== Series Details ==

Series: Commit early to GuC (rev3)
URL   : https://patchwork.freedesktop.org/series/72031/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
86c2261830f8 drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info
434763d74348 drm/i915/guc: Kill USES_GUC macro
9c3bd7cffa07 drm/i915/guc: Kill USES_GUC_SUBMISSION macro
53a7bb512097 drm/i915/uc: Update the FW status on injected fetch error
ac5ee731ad09 drm/i915/uc: autogenerate uC checker functions
-:32: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to 
avoid precedence issues
#32: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:43:
+#define __uc_state_checker(x, state, required) \
+static inline bool intel_uc_##state##_##x(struct intel_uc *uc) \
+{ \
+   return intel_##x##_is_##required(>x); \
 }

-:42: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:49:
+#define uc_state_checkers(x) \
+__uc_state_checker(x, supports, supported) \
+__uc_state_checker(x, uses, enabled)

-:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:49:
+#define uc_state_checkers(x) \
+__uc_state_checker(x, supports, supported) \
+__uc_state_checker(x, uses, enabled)

total: 1 errors, 0 warnings, 2 checks, 44 lines checked
300e9108bf45 drm/i915/uc: Improve tracking of uC init status
c7b983206d15 drm/i915/guc: Apply new uC status tracking to GuC submission as 
well
-:246: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to 
avoid precedence issues
#246: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:65:
+#define __uc_state_checker(x, func, state, required) \
+static inline bool intel_uc_##state##_##func(struct intel_uc *uc) \
 { \
+   return intel_##func##_is_##required(>x); \
 }

-:257: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#257: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:71:
+#define uc_state_checkers(x, func) \
+__uc_state_checker(x, func, supports, supported) \
+__uc_state_checker(x, func, wants, wanted) \
+__uc_state_checker(x, func, uses, used)

-:257: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#257: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:71:
+#define uc_state_checkers(x, func) \
+__uc_state_checker(x, func, supports, supported) \
+__uc_state_checker(x, func, wants, wanted) \
+__uc_state_checker(x, func, uses, used)

-:257: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'func' - possible 
side-effects?
#257: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc.h:71:
+#define uc_state_checkers(x, func) \
+__uc_state_checker(x, func, supports, supported) \
+__uc_state_checker(x, func, wants, wanted) \
+__uc_state_checker(x, func, uses, used)

total: 1 errors, 0 warnings, 3 checks, 250 lines checked
6df67d7fcd06 drm/i915/uc: Abort early on uc_init failure
e5b2f4d6ca34 drm/i915/uc: consolidate firmware cleanup
70b2b644b94a HAX: drm/i915: default to enable_guc=2

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


[Intel-gfx] ✓ Fi.CI.BAT: success for 3 display pipes combination system support (rev3)

2020-02-12 Thread Patchwork
== Series Details ==

Series: 3 display pipes combination system support (rev3)
URL   : https://patchwork.freedesktop.org/series/72468/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7924 -> Patchwork_16534


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-n2820:   [PASS][1] -> [INCOMPLETE][2] ([i915#45])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16534/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][3] ([i915#178]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16534/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gtt:
- fi-icl-u2:  [TIMEOUT][5] ([fdo#112271]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-icl-u2/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16534/fi-icl-u2/igt@i915_selftest@live_gtt.html

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


Participating hosts (43 -> 42)
--

  Additional (8): fi-hsw-4770 fi-kbl-x1275 fi-cfl-8109u fi-bsw-kefka 
fi-skl-lmem fi-blb-e6850 fi-skl-6700k2 fi-kbl-r 
  Missing(9): fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600 fi-byt-clapper fi-bsw-nick fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7924 -> Patchwork_16534

  CI-20190529: 20190529
  CI_DRM_7924: d4ea682de87f4e4378f34f0a196e8fa8983bd306 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16534: 0cbe9fb796ae7161887a23c9f906c0ff2224aefc @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0cbe9fb796ae drm/i915: Fix broken num_entries in skl_ddb_allocation_overlaps
058b783edba8 drm/i915: Add WARN_ON in intel_get_crtc_for_pipe()
a0c0a365e240 drm/i915: Get first crtc instead of PIPE_A crtc
297ffaacaef1 drm/i915: Fix wrongly populated plane possible_crtcs bit mask
cc56990284eb drm/i915: Fix broken transcoder err state
f2a17ab3d0f7 drm/i915: Remove (pipe == crtc->index) assumption
81842e985a7d drm/i915: Iterate over pipe and skip the disabled one

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for 3 display pipes combination system support (rev3)

2020-02-12 Thread Patchwork
== Series Details ==

Series: 3 display pipes combination system support (rev3)
URL   : https://patchwork.freedesktop.org/series/72468/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
81842e985a7d drm/i915: Iterate over pipe and skip the disabled one
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#17: 
"suggest explicit braces to avoid ambiguous ‘else’ [-Werror=dangling-else]"

total: 0 errors, 1 warnings, 0 checks, 39 lines checked
f2a17ab3d0f7 drm/i915: Remove (pipe == crtc->index) assumption
cc56990284eb drm/i915: Fix broken transcoder err state
-:64: WARNING:LONG_LINE: line over 100 characters
#64: FILE: drivers/gpu/drm/i915/i915_drv.h:1677:
+#define HAS_TRANSCODER_DSI0(dev_priv)   
(INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_0] != 0)

-:65: WARNING:LONG_LINE: line over 100 characters
#65: FILE: drivers/gpu/drm/i915/i915_drv.h:1678:
+#define HAS_TRANSCODER_DSI1(dev_priv)   
(INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_1] != 0)

total: 0 errors, 2 warnings, 0 checks, 34 lines checked
297ffaacaef1 drm/i915: Fix wrongly populated plane possible_crtcs bit mask
a0c0a365e240 drm/i915: Get first crtc instead of PIPE_A crtc
058b783edba8 drm/i915: Add WARN_ON in intel_get_crtc_for_pipe()
0cbe9fb796ae drm/i915: Fix broken num_entries in skl_ddb_allocation_overlaps

___
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/gt: Expand bad CS completion event debug

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Expand bad CS completion event debug
URL   : https://patchwork.freedesktop.org/series/73335/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7924 -> Patchwork_16532


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@contexts:
- fi-byt-n2820:   [PASS][1] -> [FAIL][2] ([i915#694]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-byt-n2820/igt@gem_exec_paral...@contexts.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([i915#189])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][5] -> [DMESG-FAIL][6] ([i915#1052])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][7] ([i915#178]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gtt:
- fi-icl-u2:  [TIMEOUT][9] ([fdo#112271]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-icl-u2/igt@i915_selftest@live_gtt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-icl-u2/igt@i915_selftest@live_gtt.html

  
 Warnings 

  * igt@gem_exec_parallel@fds:
- fi-byt-n2820:   [TIMEOUT][11] ([fdo#112271]) -> [FAIL][12] 
([i915#694])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@gem_exec_paral...@fds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/fi-byt-n2820/igt@gem_exec_paral...@fds.html

  
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694


Participating hosts (43 -> 39)
--

  Additional (7): fi-hsw-4770 fi-kbl-x1275 fi-gdg-551 fi-bsw-kefka fi-kbl-7560u 
fi-skl-6700k2 fi-kbl-r 
  Missing(11): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ilk-650 
fi-kbl-7500u fi-ctg-p8600 fi-ivb-3770 fi-bdw-samus fi-byt-clapper fi-skl-6600u 
fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7924 -> Patchwork_16532

  CI-20190529: 20190529
  CI_DRM_7924: d4ea682de87f4e4378f34f0a196e8fa8983bd306 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16532: 9c4c9a0806edc1aa9e49cb27935a2fbe11aa58d2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9c4c9a0806ed drm/i915/gt: Expand bad CS completion event debug

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: make a gt sysfs group and move power management files (rev2)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: make a gt sysfs group and move power management files 
(rev2)
URL   : https://patchwork.freedesktop.org/series/73190/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gt/sysfs_gt_pm.o
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c: In function ‘intel_gt_sysfs_get_drvdata’:
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:26:49: error: "/*" within comment 
[-Werror=comment]
   * has been called, whether it's called from gt/* or from
  
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 
'drivers/gpu/drm/i915/gt/sysfs_gt_pm.o' failed
make[4]: *** [drivers/gpu/drm/i915/gt/sysfs_gt_pm.o] Error 1
scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:505: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1681: recipe for target 'drivers' failed
make: *** [drivers] Error 2

___
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 [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12.

2020-02-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are 
moved since GEN 12.
URL   : https://patchwork.freedesktop.org/series/73332/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7924 -> Patchwork_16531


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-hsw-peppy:   [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_parallel@contexts:
- fi-byt-n2820:   [PASS][3] -> [TIMEOUT][4] ([fdo#112271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-byt-n2820/igt@gem_exec_paral...@contexts.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820:   [PASS][5] -> [DMESG-FAIL][6] ([i915#1052])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#109635] / [i915#262])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][9] ([i915#178]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gtt:
- fi-icl-u2:  [TIMEOUT][11] ([fdo#112271]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-icl-u2/igt@i915_selftest@live_gtt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-icl-u2/igt@i915_selftest@live_gtt.html

  
 Warnings 

  * igt@gem_exec_parallel@fds:
- fi-byt-n2820:   [TIMEOUT][13] ([fdo#112271]) -> [FAIL][14] 
([i915#694])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-byt-n2820/igt@gem_exec_paral...@fds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-byt-n2820/igt@gem_exec_paral...@fds.html

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [FAIL][16] ([i915#579])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816


Participating hosts (43 -> 44)
--

  Additional (9): fi-hsw-4770 fi-kbl-x1275 fi-gdg-551 fi-cfl-8109u fi-bsw-kefka 
fi-skl-lmem fi-blb-e6850 fi-skl-6700k2 fi-kbl-r 
  Missing(8): fi-kbl-soraka fi-hsw-4200u fi-bdw-gvtdvm fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7924 -> Patchwork_16531

  CI-20190529: 20190529
  CI_DRM_7924: d4ea682de87f4e4378f34f0a196e8fa8983bd306 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16531: cbf3d2d61711eb72a4bbb3180d707e637e3971ea @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cbf3d2d61711 drm/i915: MCHBAR memory info registers are moved since GEN 12.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/index.html
___
Intel-gfx mailing list

[Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_1808121037 to tgl.

2020-02-12 Thread Rafael Antognolli
It's not clear whether this workaround is final yet, but the BSpec
indicates that userspace needs to set bit 9 of this register on demand:

   "To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer
   Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA"

BugLink: https://gitlab.freedesktop.org/mesa/mesa/issues/2501
Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 62b43f538a56..57b9685d9347 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1264,6 +1264,12 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
whitelist_reg_ext(w, PS_INVOCATION_COUNT,
  RING_FORCE_TO_NONPRIV_ACCESS_RD |
  RING_FORCE_TO_NONPRIV_RANGE_4);
+
+   /* Wa_1808121037:tgl
+*
+* Allow userpace to implement this workaround.
+*/
+   whitelist_reg(w, GEN7_COMMON_SLICE_CHICKEN1);
break;
default:
break;
-- 
2.25.0

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


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/display/tgl: Enable hotplug detection in TC5 and TC6

2020-02-12 Thread Matt Roper
On Tue, Feb 11, 2020 at 10:50:08AM -0800, José Roberto de Souza wrote:
> The hotplug interruption detection was not being enabled for TC5 and
> TC6 in the north detection side.

TC5 and TC6 would be ports H & I.  We're lacking handling in a few other
places as well (e.g., aux channels).  I sent patches to update some of
those areas a few months back, but Lucas suggested that we just remove
these ports completely since all TGL SKU's don't actually pin them out
for use.

For reference:
  https://lists.freedesktop.org/archives/intel-gfx/2019-October/217820.html

I don't have strong feelings either way, but we should probably all
agree on a direction and then handle it consistently everywhere in the
code.


Matt


> 
> Cc: Matt Roper 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3d0cd0960bd2..abd979ef75ec 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3051,6 +3051,9 @@ static void gen11_hpd_detection_setup(struct 
> drm_i915_private *dev_priv)
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC2) |
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC3) |
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC4);
> + if (INTEL_GEN(dev_priv) >= 12)
> + hotplug |= GEN11_HOTPLUG_CTL_ENABLE(PORT_TC5) |
> +GEN11_HOTPLUG_CTL_ENABLE(PORT_TC6);
>   I915_WRITE(GEN11_TC_HOTPLUG_CTL, hotplug);
>  
>   hotplug = I915_READ(GEN11_TBT_HOTPLUG_CTL);
> @@ -3058,6 +3061,9 @@ static void gen11_hpd_detection_setup(struct 
> drm_i915_private *dev_priv)
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC2) |
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC3) |
>  GEN11_HOTPLUG_CTL_ENABLE(PORT_TC4);
> + if (INTEL_GEN(dev_priv) >= 12)
> + hotplug |= GEN11_HOTPLUG_CTL_ENABLE(PORT_TC5) |
> +GEN11_HOTPLUG_CTL_ENABLE(PORT_TC6);
>   I915_WRITE(GEN11_TBT_HOTPLUG_CTL, hotplug);
>  }
>  
> -- 
> 2.25.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] [PATCH i-g-t 3/3] i915/gem_ctx_isolation: Check engine relative registers - Part 2

2020-02-12 Thread Dale B Stimson
Modify previous i915/gem_ctx_isolation "Check engine relative registers"
for modified mmio_base infrastructure.

Signed-off-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 87 +++---
 1 file changed, 48 insertions(+), 39 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index eff4b1df2..eec78c729 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -233,12 +233,12 @@ static bool ignore_register(uint32_t offset, uint32_t 
mmio_base)
 static void tmpl_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  uint32_t handle,
  uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *regs;
 
@@ -278,12 +278,12 @@ static void tmpl_regs(int fd,
 static uint32_t read_regs(int fd,
  uint32_t ctx,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int flags)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_relocation_entry *reloc;
@@ -359,12 +359,12 @@ static uint32_t read_regs(int fd,
 static void write_regs(int fd,
   uint32_t ctx,
   const struct intel_execution_engine2 *e,
+  uint32_t mmio_base,
   unsigned int flags,
   uint32_t value)
 {
const unsigned int gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
struct drm_i915_gem_exec_object2 obj;
struct drm_i915_gem_execbuffer2 execbuf;
unsigned int batch_size;
@@ -420,13 +420,13 @@ static void write_regs(int fd,
 static void restore_regs(int fd,
 uint32_t ctx,
 const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 unsigned int flags,
 uint32_t regs)
 {
const unsigned int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
const bool r64b = gen >= 8;
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
@@ -498,12 +498,12 @@ static void restore_regs(int fd,
 __attribute__((unused))
 static void dump_regs(int fd,
  const struct intel_execution_engine2 *e,
+ uint32_t mmio_base,
  unsigned int regs)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
const unsigned int gen_bit = 1 << gen;
const unsigned int engine_bit = ENGINE(e->class, e->instance);
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int regs_size;
uint32_t *out;
 
@@ -541,9 +541,9 @@ static void dump_regs(int fd,
 }
 
 static void compare_regs(int fd, const struct intel_execution_engine2 *e,
+uint32_t mmio_base,
 uint32_t A, uint32_t B, const char *who)
 {
-   const uint32_t mmio_base = gem_engine_mmio_base(fd, e->name);
unsigned int num_errors;
unsigned int regs_size;
uint32_t *a, *b;
@@ -596,6 +596,7 @@ static void compare_regs(int fd, const struct 
intel_execution_engine2 *e,
 
 static void nonpriv(int fd,
const struct intel_execution_engine2 *e,
+   uint32_t mmio_base,
unsigned int flags)
 {
static const uint32_t values[] = {
@@ -623,16 +624,16 @@ static void nonpriv(int fd,
 
ctx = gem_context_clone_with_engines(fd, 0);
 
-   tmpl = read_regs(fd, ctx, e, flags);
-   regs[0] = read_regs(fd, ctx, e, flags);
+   tmpl = read_regs(fd, ctx, e, mmio_base, flags);
+   regs[0] = read_regs(fd, ctx, e, mmio_base, flags);
 
-   tmpl_regs(fd, ctx, e, tmpl, values[v]);
+   tmpl_regs(fd, ctx, e, mmio_base, tmpl, values[v]);
 
spin = igt_spin_new(fd, .ctx = ctx, .engine = e->flags);
 

[Intel-gfx] [PATCH i-g-t 2/3] i915/gem_ctx_isolation: Check engine relative registers

2020-02-12 Thread Dale B Stimson
From: Chris Wilson 

Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.

Signed-off-by: Chris Wilson 
Reviewed-by: Dale B Stimson 
---
 tests/i915/gem_ctx_isolation.c | 164 -
 1 file changed, 100 insertions(+), 64 deletions(-)

diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 1b66fec11..eff4b1df2 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -70,6 +70,7 @@ static const struct named_register {
uint32_t ignore_bits;
uint32_t write_mask; /* some registers bits do not exist */
bool masked;
+   bool relative;
 } nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
@@ -109,7 +110,6 @@ static const struct named_register {
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
{ "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
-   { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
{ "OACTXID", GEN8, RCS0, 0x2364 },
{ "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
@@ -138,79 +138,56 @@ static const struct named_register {
 
{ "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
-   { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
 
/* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
{ "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
{ "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked = 
true },
-   { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
+   { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
{ "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,  
0x731c, .masked = true },
{ "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask = 
~0x10 },
{ "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked = 
true },
{ "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
 
-   { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
{ "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true 
},
 
{ "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
{ "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
 
-   { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
-   { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
-   { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
-
-   { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
-   { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
-   { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
-   { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
-   { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
+   { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
 
{}
 }, ignore_registers[] = {
{ "RCS timestamp", GEN6, ~0u, 0x2358 },
{ "BCS timestamp", GEN7, ~0u, 0x22358 },
 
-   { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
-   { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
-   { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
-
-   { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
-   { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
-   { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
-   { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
-   { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
+   { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
 
/* huc read only */
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2014 },
-   { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x23b0 },
-
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2000 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2014 },
-   { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x23b0 },
-
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2000 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2014 },
-   { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x23b0 },
-
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2000 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2014 },
-   { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x23b0 },
+   { "BSD 0x2000", GEN11, ALL, 0x2000, .relative = true },
+   { "BSD 0x2014", GEN11, ALL, 0x2014, .relative = true },
+   { "BSD 0x23b0", GEN11, ALL, 0x23b0, .relative = true },
 
{}
 };
 
-static const char *register_name(uint32_t offset, char *buf, size_t len)
+static const char *
+register_name(uint32_t offset, uint32_t mmio_base, char *buf, size_t len)
 {
for (const struct named_register *r = nonpriv_registers; r->name; 

[Intel-gfx] [PATCH i-g-t 0/3] mmio_base via debugfs infrastructure + gem_ctx_isolation

2020-02-12 Thread Dale B Stimson
This patch series provides infrastructure to allow determination of i915
per-engine mmio_base (which is otherwise sometimes hard to get).  The provided
method uses debugfs mmio_base information if present.  Otherwise, a default
determination is provided when possible.  Also, gem_ctx_isolation is modified
to use the new infrastructure.

For example, on TGL, gem_ctx_isolation (without these or similar changes)
will fail for subtests that use engine vcs1.

The patches in this series are as they are intended to be submitted (subject
to comments), except I would like to squash the two gem_ctx_isolation
"relative registers" patches into one (as discussed below).  Also, function
gem_engine_mmio_base_info_dump() could be removed.

On 2020-01-27, Chris wilson sent to the ML:
  [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
  [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative 
registers
plus the following, which are not addressed here:
  [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in 
sysfs
  [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
  [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property

This patch list is:
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

The first 2020-01-27 patch obtains mmio_base information via sysfs, and depends
on a proposed kernel change that would provide the mmio_base information
via sysfs.  It is unclear when or whether that kernel change will progress.

The mmio_base information used by this patch series is available through
debugfs now (as of kernel 5.4).  If the per-engine mmio_base information is
ever added to sysfs, it would be easy to plug that into the infrastructure
proposed here as an additional higher-priority source of that information.

This submission replaces the first patch (switching from sysfs to debugfs),
retains the second 2020-01-27 patch
  i915/gem_ctx_isolation: Check engine relative registers
and has a third patch that modifies the original second patch to support the
altered API:
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

I propose squashing the two gem_ctx_isolation "relative registers" patches
into one patch with author == "Chris Wilson" if Chris agrees.

Some differences from the 2020-01-27 patches:

The mmio_base information is fetched once into local data structures, and
is obtained from them thereafter instead of being fetched from the kernel
everytime it is wanted.

The function that obtains the mmio_base information is called by a particular
test that wants it, and returns a handle through which the mmio_base can be
requested for any particular engine.

These patches introduce new source files lib/i915/gem_mmio_base.c
and lib/i915/gem_mmio_base.h.  Should the code instead be placed into
lib/i915/gem_engine_topology.c?

Function gem_engine_mmio_base_info_dump presently exists to dump the
mmio_base information to stdout for debugging or informational purposes.
This function is not currently called.  I presume this function should
be removed.  Is there any desire to keep it around for future use?

The 2020-01-27 patches define function gem_engine_mmio_base() with its first
parameter as "fd".  The new patches replace the first parameter with the
mmio_base object handle.

Chris Wilson (1):
  i915/gem_ctx_isolation: Check engine relative registers

Dale B Stimson (2):
  i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
  i915/gem_ctx_isolation: Check engine relative registers - Part 2

 lib/Makefile.sources   |   2 +
 lib/i915/gem_mmio_base.c   | 346 +
 lib/i915/gem_mmio_base.h   |  19 ++
 lib/igt.h  |   1 +
 lib/meson.build|   1 +
 tests/i915/gem_ctx_isolation.c | 229 +-
 6 files changed, 506 insertions(+), 92 deletions(-)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

-- 
2.25.0

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


[Intel-gfx] [PATCH i-g-t 1/3] i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)

2020-02-12 Thread Dale B Stimson
Signed-off-by: Dale B Stimson 
---
 lib/Makefile.sources |   2 +
 lib/i915/gem_mmio_base.c | 346 +++
 lib/i915/gem_mmio_base.h |  19 +++
 lib/igt.h|   1 +
 lib/meson.build  |   1 +
 5 files changed, 369 insertions(+)
 create mode 100644 lib/i915/gem_mmio_base.c
 create mode 100644 lib/i915/gem_mmio_base.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 3e573f267..4c5d50d5d 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ lib_source_list =   \
i915/gem_context.h  \
i915/gem_engine_topology.c  \
i915/gem_engine_topology.h  \
+   i915/gem_mmio_base.c\
+   i915/gem_mmio_base.h\
i915/gem_scheduler.c\
i915/gem_scheduler.h\
i915/gem_submission.c   \
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
new file mode 100644
index 0..8718c092f
--- /dev/null
+++ b/lib/i915/gem_mmio_base.c
@@ -0,0 +1,346 @@
+//  Copyright (C) 2020 Intel Corporation
+//
+//  SPDX-License-Identifier: MIT
+
+#include 
+
+#include 
+
+#include "igt.h"
+
+struct eng_mmio_base_s {
+   char   name[8];
+   uint32_t   mmio_base;
+};
+
+struct eng_mmio_base_table_s {
+   unsigned int   mb_cnt;
+   struct eng_mmio_base_s mb_tab[GEM_MAX_ENGINES];
+};
+
+
+static struct eng_mmio_base_table_s *_gem_engine_mmio_info_dup(
+   const struct eng_mmio_base_table_s *mbpi)
+{
+   struct eng_mmio_base_table_s *mbpo;
+   size_t nbytes;
+
+   nbytes = offsetof(typeof(struct eng_mmio_base_table_s), 
mb_tab[mbpi->mb_cnt]);
+   mbpo = malloc(nbytes);
+   igt_assert(mbpo);
+   memcpy(mbpo, mbpi, nbytes);
+
+   return mbpo;
+}
+
+void gem_engine_mmio_base_info_free(struct eng_mmio_base_table_s *mbp)
+{
+   free(mbp);
+}
+
+static void _gem_engine_mmio_info_legacy_add(struct eng_mmio_base_table_s *mbp,
+   const char *eng_name, uint32_t mmio_base)
+{
+   if (mmio_base) {
+   strncpy(mbp->mb_tab[mbp->mb_cnt].name, eng_name,
+   sizeof(mbp->mb_tab[0].name));
+   mbp->mb_tab[mbp->mb_cnt].mmio_base = mmio_base;
+   mbp->mb_cnt++;
+   }
+}
+
+/**
+ * _gem_engine_mmio_base_info_get_legacy:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Provides per-engine mmio_base information from legacy built-in values
+ * for the case when the information is not otherwise available.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ */
+static struct eng_mmio_base_table_s *_gem_engine_mmio_base_info_get_legacy(int 
fd_dev)
+{
+   int gen;
+   uint32_t mmio_base;
+   struct eng_mmio_base_table_s mbt;
+   struct eng_mmio_base_table_s *mbp;
+
+   memset(, 0, sizeof(mbt));
+
+   gen = intel_gen(intel_get_drm_devid(fd_dev));
+
+   /* The mmio_base values for engine instances 1 and higher cannot
+* be reliability determinated a priori. */
+
+   _gem_engine_mmio_info_legacy_add(, "rcs0", 0x2000);
+   _gem_engine_mmio_info_legacy_add(, "bcs0", 0x22000);
+
+   if (gen < 6)
+   mmio_base = 0x4000;
+   else if (gen < 11)
+   mmio_base = 0x12000;
+   else
+   mmio_base = 0x1c;
+   _gem_engine_mmio_info_legacy_add(, "vcs0", mmio_base);
+
+   if (gen < 11)
+   mmio_base = 0x1a000;
+   else
+   mmio_base = 0x1c8000;
+   _gem_engine_mmio_info_legacy_add(, "vecs0", mmio_base);
+
+   if (mbt.mb_cnt <= 0)
+   return NULL;
+
+   mbp = _gem_engine_mmio_info_dup();
+
+   return mbp;
+}
+
+
+/**
+ * _gem_engine_mmio_base_info_get_debugfs:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Obtains per-engine mmio_base information from debugfs.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ *
+ * Looking in debugfs for per-engine instances of:
+ * 
+ *  ...
+ * MMIO base: 
+ *
+ * Example of relevant lines from debugfs:
+ * vcs0
+ * MMIO base:  0x001c
+ * vcs1
+ * MMIO base:  0x001d
+ *
+ * In order to qualify as the introduction of a new per-engine section, an
+ * input line must consist solely of an engine name.  An engine name must
+ * be 7 or fewer characters in length and must consist of an engine class
+ * name of 3 or more lower case characters followed by an instance number.
+ */
+static struct eng_mmio_base_table_s 
*_gem_engine_mmio_base_info_get_debugfs(int fd_dev)
+{
+ 

[Intel-gfx] ✓ Fi.CI.IGT: success for In order to readout DP SDPs, refactors the handling of DP SDPs (rev7)

2020-02-12 Thread Patchwork
== Series Details ==

Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev7)
URL   : https://patchwork.freedesktop.org/series/72853/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7905_full -> Patchwork_16516_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-apl3/igt@gem_soft...@noreloc-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-apl8/igt@gem_soft...@noreloc-s3.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#716])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-glk8/igt@gen9_exec_pa...@allowed-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-glk9/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +5 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][7] -> [FAIL][8] ([i915#31])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-apl6/igt@kms_setm...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-apl8/igt@kms_setm...@basic.html
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#31])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-kbl7/igt@kms_setm...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-kbl4/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl:  [DMESG-WARN][11] ([i915#180]) -> [PASS][12] +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-kbl3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html

  
 Warnings 

  * igt@i915_pm_rpm@gem-idle:
- shard-snb:  [INCOMPLETE][13] ([i915#82]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7905/shard-snb4/igt@i915_pm_...@gem-idle.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16516/shard-snb4/igt@i915_pm_...@gem-idle.html

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


Participating hosts (10 -> 10)
--

  No changes in participating hosts


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7905 -> Patchwork_16516

  CI-20190529: 20190529
  CI_DRM_7905: db98da3dd757a19dbaaeaef8640276fe7be2fc4e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5433: 6a96c17f3a1b4e1f90b1a0b0ce42a7219875d1a4 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16516: 290fe3c7dbc4fabe23502e3eb9a1b286a993da4e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Use intel_de_write_fw() for skl+ scaler registers

2020-02-12 Thread Jani Nikula
On Wed, 12 Feb 2020, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> We have to write quite a few registers when programming the
> pipe scaler. Let's use intel_de_write_fw() for these to reduce
> the lockdep overhead a bit. All plane registers (including plane
> scaler) already do this.
>
> We already had a few accidental intel_de_write_fw() in there.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
>  1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 61ba1f2256a0..de50aa0b076c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4494,10 +4494,15 @@ static void skl_detach_scaler(struct intel_crtc 
> *intel_crtc, int id)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);

Hrmh, I don't like how the uncore lock leaks through the intel_de_*
abstractions. But I guess I dislike adding wrappers for spin locks even
less.

Reviewed-by: Jani Nikula 


>  
> - intel_de_write(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
> - intel_de_write(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
> - intel_de_write(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
> + intel_de_write_fw(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>  }
>  
>  /*
> @@ -6234,6 +6239,7 @@ static void skl_pfit_enable(const struct 
> intel_crtc_state *crtc_state)
>   if (crtc_state->pch_pfit.enabled) {
>   u16 uv_rgb_hphase, uv_rgb_vphase;
>   int pfit_w, pfit_h, hscale, vscale;
> + unsigned long irqflags;
>   int id;
>  
>   if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
> @@ -6249,16 +6255,21 @@ static void skl_pfit_enable(const struct 
> intel_crtc_state *crtc_state)
>   uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
>  
>   id = scaler_state->scaler_id;
> - intel_de_write(dev_priv, SKL_PS_CTRL(pipe, id),
> -PS_SCALER_EN | PS_FILTER_MEDIUM | 
> scaler_state->scalers[id].mode);
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN 
> |
> +   PS_FILTER_MEDIUM | 
> scaler_state->scalers[id].mode);
>   intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
> PS_Y_PHASE(0) | 
> PS_UV_RGB_PHASE(uv_rgb_vphase));
>   intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
> PS_Y_PHASE(0) | 
> PS_UV_RGB_PHASE(uv_rgb_hphase));
> - intel_de_write(dev_priv, SKL_PS_WIN_POS(pipe, id),
> -crtc_state->pch_pfit.pos);
> - intel_de_write(dev_priv, SKL_PS_WIN_SZ(pipe, id),
> -crtc_state->pch_pfit.size);
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
> +   crtc_state->pch_pfit.pos);
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
> +   crtc_state->pch_pfit.size);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Parametrize PFIT_PIPE

2020-02-12 Thread Jani Nikula
On Wed, 12 Feb 2020, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Make the PFIT_PIPE stuff less ugly via parametrization.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 3 +--
>  drivers/gpu/drm/i915/i915_reg.h| 1 +
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index cba2f1c2557f..8b0730f4c442 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -434,8 +434,7 @@ void intel_gmch_panel_fitting(struct intel_crtc 
> *intel_crtc,
>   /* 965+ wants fuzzy fitting */
>   /* FIXME: handle multiple panels by failing gracefully */
>   if (INTEL_GEN(dev_priv) >= 4)
> - pfit_control |= ((intel_crtc->pipe << PFIT_PIPE_SHIFT) |
> -  PFIT_FILTER_FUZZY);
> + pfit_control |= PFIT_PIPE(intel_crtc->pipe) | PFIT_FILTER_FUZZY;
>  
>  out:
>   if ((pfit_control & PFIT_ENABLE) == 0) {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b09c1d6dc0aa..faf8945a51b0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4928,6 +4928,7 @@ enum {
>  #define   PFIT_ENABLE(1 << 31)
>  #define   PFIT_PIPE_MASK (3 << 29)
>  #define   PFIT_PIPE_SHIFT29
> +#define   PFIT_PIPE(pipe)((pipe) << 29)

This is fine, but might have as well defined this in terms of
REG_FIELD_PREP. I especially like it for parametrized stuff because it
ensures we don't flood the value outside the field.

Reviewed-by: Jani Nikula 

>  #define   VERT_INTERP_DISABLE(0 << 10)
>  #define   VERT_INTERP_BILINEAR   (1 << 10)
>  #define   VERT_INTERP_MASK   (3 << 10)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Implement Wa_1606931601 (rev5)

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Implement Wa_1606931601 (rev5)
URL   : https://patchwork.freedesktop.org/series/72433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7922 -> Patchwork_16530


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [PASS][1] -> [TIMEOUT][2] ([fdo#112271] / [i915#1084] 
/ [i915#816])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#109635] / [i915#262])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [PASS][5] -> [DMESG-WARN][6] ([i915#44])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900:   [DMESG-FAIL][7] ([i915#1052]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_gtt:
- fi-kbl-7500u:   [TIMEOUT][9] ([fdo#112271]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-kbl-7500u/igt@i915_selftest@live_gtt.html

  * igt@i915_selftest@live_workarounds:
- {fi-tgl-u}: [DMESG-FAIL][11] ([i915#1169]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-tgl-u/igt@i915_selftest@live_workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-tgl-u/igt@i915_selftest@live_workarounds.html
- {fi-tgl-dsi}:   [DMESG-FAIL][13] ([i915#1169]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-tgl-dsi/igt@i915_selftest@live_workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/fi-tgl-dsi/igt@i915_selftest@live_workarounds.html

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

  [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
  [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
  [i915#1169]: https://gitlab.freedesktop.org/drm/intel/issues/1169
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816


Participating hosts (53 -> 42)
--

  Additional (1): fi-snb-2520m 
  Missing(12): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-kbl-7560u fi-byt-clapper fi-kbl-r 
fi-bdw-samus fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7922 -> Patchwork_16530

  CI-20190529: 20190529
  CI_DRM_7922: 0367f4b85f1fbbb1f0df1064803c97d35ed53f24 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16530: fc2fdf6349df81db142615b3c34cd20aa320e7c5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fc2fdf6349df drm/i915/tgl: Implement Wa_1606931601

== Logs ==

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


Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Stephen Smalley

On 2/12/20 11:56 AM, Alexey Budankov wrote:



On 12.02.2020 18:45, Stephen Smalley wrote:

On 2/12/20 10:21 AM, Stephen Smalley wrote:

On 2/12/20 8:53 AM, Alexey Budankov wrote:

On 12.02.2020 16:32, Stephen Smalley wrote:

On 2/12/20 3:53 AM, Alexey Budankov wrote:

Hi Stephen,

On 22.01.2020 17:07, Stephen Smalley wrote:

On 1/22/20 5:45 AM, Alexey Budankov wrote:


On 21.01.2020 21:27, Alexey Budankov wrote:


On 21.01.2020 20:55, Alexei Starovoitov wrote:

On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
 wrote:



On 21.01.2020 17:43, Stephen Smalley wrote:

On 1/20/20 6:23 AM, Alexey Budankov wrote:





Introduce CAP_PERFMON capability designed to secure system performance


Why _noaudit()?  Normally only used when a permission failure is non-fatal to 
the operation.  Otherwise, we want the audit message.


So far so good, I suggest using the simplest version for v6:

static inline bool perfmon_capable(void)
{
   return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
}

It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for CAP_PERFMON
privileged process.

Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
processes,
but this bloating also advertises and leverages using more secure CAP_PERFMON
based approach to use perf_event_open system call.


I can live with that.  We just need to document that when you see both a 
CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only allowing 
CAP_PERFMON first and see if that resolves the issue.  We have a similar issue 
with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.


I am trying to reproduce this double logging with CAP_PERFMON.
I am using the refpolicy version with enabled perf_event tclass [1], in 
permissive mode.
When running perf stat -a I am observing this AVC audit messages:

type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1

However there is no capability related messages around. I suppose my refpolicy 
should
be modified somehow to observe capability related AVCs.

Could you please comment or clarify on how to enable caps related AVCs in order
to test the concerned logging.


The new perfmon permission has to be defined in your policy; you'll have a message in 
dmesg about "Permission perfmon in class capability2 not defined in policy.".  
You can either add it to the common cap2 definition in 
refpolicy/policy/flask/access_vectors and rebuild your policy or extract your base module 
as CIL, add it there, and insert the updated module.


Yes, I already have it like this:
common cap2
{
<-->mac_override<--># unused by SELinux
<-->mac_admin
<-->syslog
<-->wake_alarm
<-->block_suspend
<-->audit_read
<-->perfmon
}

dmesg stopped reporting perfmon as not defined but audit.log still doesn't 
report CAP_PERFMON denials.
BTW, audit even doesn't report CAP_SYS_ADMIN denials, however perfmon_capable() 
does check for it.


Some denials may be silenced by dontaudit rules; semodule -DB will strip those 
and semodule -B will restore them.  Other possibility is that the process 
doesn't have CAP_PERFMON in its effective set and therefore never reaches 
SELinux at all; denied first by the capability module.


Also, the fact that your denials are showing up in user_systemd_t suggests that 
something is off in your policy or userspace/distro; I assume that is a domain 
type for the systemd --user instance, but your shell and commands shouldn't be 
running in that domain (user_t would be more appropriate for that).


It is user_t for local terminal session:
ps -Z
LABEL PID TTY  TIME CMD
user_u:user_r:user_t11317 pts/900:00:00 bash
user_u:user_r:user_t11796 pts/900:00:00 ps

For local terminal root session:
ps -Z
LABEL PID TTY  TIME CMD
user_u:user_r:user_su_t  2926 pts/300:00:00 bash
user_u:user_r:user_su_t 10995 pts/300:00:00 ps

For remote ssh session:
ps -Z
LABEL PID TTY  TIME CMD
user_u:user_r:user_t 7540 pts/800:00:00 ps
user_u:user_r:user_systemd_t 8875 pts/800:00:00 bash


That's a 

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable -Wtautological-constant-out-of-range-compare

2020-02-12 Thread Michel Dänzer
On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
>>> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
 On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> A recent commit in clang added -Wtautological-compare to -Wall, which is
> enabled for i915 so we see the following warning:
>
> ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
> result of comparison of constant 576460752303423487 with expression of
> type 'unsigned int' is always false
> [-Wtautological-constant-out-of-range-compare]
> if (unlikely(remain > N_RELOC(ULONG_MAX)))
> ^
>
> This warning only happens on x86_64 but that check is relevant for
> 32-bit x86 so we cannot remove it.

 That's suprising. AFAICT N_RELOC(ULONG_MAX) works out to the same value
 in both cases, and remain is a 32-bit value in both cases. How can it be
 larger than N_RELOC(ULONG_MAX) on 32-bit (but not on 64-bit)?

>>>
>>> Hi Michel,
>>>
>>> Can't this condition be true when UINT_MAX == ULONG_MAX?
>>
>> Oh, right, I think I was wrongly thinking long had 64 bits even on 32-bit.
>>
>>
>> Anyway, this suggests a possible better solution:
>>
>> #if UINT_MAX == ULONG_MAX
>>  if (unlikely(remain > N_RELOC(ULONG_MAX)))
>>  return -EINVAL;
>> #endif
>>
>>
>> Or if that can't be used for some reason, something like
>>
>>  if (unlikely((unsigned long)remain > N_RELOC(ULONG_MAX)))
>>  return -EINVAL;
>>
>> should silence the warning.
> 
> I do like this one better than the former.

FWIW, one downside of this one compared to all alternatives (presumably)
is that it might end up generating actual code even on 64-bit, which
always ends up skipping the return.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Wa_1607090982"

2020-02-12 Thread Mika Kuoppala
Chris Wilson  writes:

> BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still

Now we have some idea. It was in mcr range register thus verification
was doomed to fail. Fix in list.

-Mika

> in effect when it needs to be. Until that is resolved, remove the
> failing bit.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1169
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 62b43f538a56..4bbea781c142 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -598,9 +598,6 @@ static void tgl_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>   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);
> -
> - /* Wa_1606931601:tgl */
> - WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
>  }
>  
>  static void
> -- 
> 2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Disable -Wtautological-constant-out-of-range-compare

2020-02-12 Thread Nathan Chancellor
On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
> > On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
> >> On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> >>> A recent commit in clang added -Wtautological-compare to -Wall, which is
> >>> enabled for i915 so we see the following warning:
> >>>
> >>> ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
> >>> result of comparison of constant 576460752303423487 with expression of
> >>> type 'unsigned int' is always false
> >>> [-Wtautological-constant-out-of-range-compare]
> >>> if (unlikely(remain > N_RELOC(ULONG_MAX)))
> >>> ^
> >>>
> >>> This warning only happens on x86_64 but that check is relevant for
> >>> 32-bit x86 so we cannot remove it.
> >>
> >> That's suprising. AFAICT N_RELOC(ULONG_MAX) works out to the same value
> >> in both cases, and remain is a 32-bit value in both cases. How can it be
> >> larger than N_RELOC(ULONG_MAX) on 32-bit (but not on 64-bit)?
> >>
> > 
> > Hi Michel,
> > 
> > Can't this condition be true when UINT_MAX == ULONG_MAX?
> 
> Oh, right, I think I was wrongly thinking long had 64 bits even on 32-bit.
> 
> 
> Anyway, this suggests a possible better solution:
> 
> #if UINT_MAX == ULONG_MAX
>   if (unlikely(remain > N_RELOC(ULONG_MAX)))
>   return -EINVAL;
> #endif
> 
> 
> Or if that can't be used for some reason, something like
> 
>   if (unlikely((unsigned long)remain > N_RELOC(ULONG_MAX)))
>   return -EINVAL;
> 
> should silence the warning.

I do like this one better than the former.

> 
> 
> Either of these should be better than completely disabling the warning
> for the whole file.

Normally, I would agree but I am currently planning to leave
-Wtautological-constant-out-of-range-compare disabled when I turn on
-Wtautological-compare for the whole kernel because there are plenty of
locations in the kernel where these kind of checks depend on various
kernel configuration options and the general attitude of kernel
developers is that this particular warning is not really helpful
for that reason.

I'll see if there is a general consensus before moving further since I
know i915 turns on a bunch of extra warnings from the rest of the kernel
(hence why we are in this situation).

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Implement Wa_1607090982"

2020-02-12 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: Implement Wa_1607090982"
URL   : https://patchwork.freedesktop.org/series/73324/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7922 -> Patchwork_16529


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [PASS][1] -> [INCOMPLETE][2] ([i915#45])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [PASS][3] -> [FAIL][4] ([i915#178])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

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

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-n2820:   [INCOMPLETE][7] ([i915#45]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/fi-byt-n2820/igt@gem_close_r...@basic-threads.html

  * igt@i915_selftest@live_gtt:
- fi-kbl-7500u:   [TIMEOUT][9] ([fdo#112271]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/fi-kbl-7500u/igt@i915_selftest@live_gtt.html

  * igt@i915_selftest@live_workarounds:
- {fi-tgl-u}: [DMESG-FAIL][11] ([i915#1169]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/fi-tgl-u/igt@i915_selftest@live_workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/fi-tgl-u/igt@i915_selftest@live_workarounds.html

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

  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1169]: https://gitlab.freedesktop.org/drm/intel/issues/1169
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
  [i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460


Participating hosts (53 -> 41)
--

  Additional (1): fi-snb-2520m 
  Missing(13): fi-kbl-soraka fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 
fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ilk-650 fi-ctg-p8600 fi-cfl-8109u 
fi-kbl-7560u fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7922 -> Patchwork_16529

  CI-20190529: 20190529
  CI_DRM_7922: 0367f4b85f1fbbb1f0df1064803c97d35ed53f24 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16529: 8cf3918c615a66b169d4cdf42095e41847ad679b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8cf3918c615a Revert "drm/i915: Implement Wa_1607090982"

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Use engine wa list for Wa_1607090982

2020-02-12 Thread Mika Kuoppala
This is in mcr range of register, thus we can only verify
it through mmio. Use engine wa list with mcr range verification
skip.

Fixes: 0db1a5f8706a ("drm/i915: Implement Wa_1607090982")
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 62b43f538a56..ba86511f1ef9 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -598,9 +598,6 @@ static void tgl_ctx_workarounds_init(struct intel_engine_cs 
*engine,
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);
-
-   /* Wa_1606931601:tgl */
-   WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
 }
 
 static void
@@ -1360,6 +1357,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
wa_write_or(wal,
GEN7_FF_THREAD_MODE,
GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
+
+   /* Wa_1606931601:tgl */
+   wa_masked_en(wal,
+GEN7_ROW_CHICKEN2,
+GEN12_DISABLE_EARLY_READ);
}
 
if (IS_GEN(i915, 11)) {
-- 
2.17.1

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


Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Alexey Budankov


On 12.02.2020 18:45, Stephen Smalley wrote:
> On 2/12/20 10:21 AM, Stephen Smalley wrote:
>> On 2/12/20 8:53 AM, Alexey Budankov wrote:
>>> On 12.02.2020 16:32, Stephen Smalley wrote:
 On 2/12/20 3:53 AM, Alexey Budankov wrote:
> Hi Stephen,
>
> On 22.01.2020 17:07, Stephen Smalley wrote:
>> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 21:27, Alexey Budankov wrote:

 On 21.01.2020 20:55, Alexei Starovoitov wrote:
> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>  wrote:
>>
>>
>> On 21.01.2020 17:43, Stephen Smalley wrote:
>>> On 1/20/20 6:23 AM, Alexey Budankov wrote:

> 
 Introduce CAP_PERFMON capability designed to secure system 
 performance
>>>
>>> Why _noaudit()?  Normally only used when a permission failure is 
>>> non-fatal to the operation.  Otherwise, we want the audit message.
>>>
>>> So far so good, I suggest using the simplest version for v6:
>>>
>>> static inline bool perfmon_capable(void)
>>> {
>>>   return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
>>> }
>>>
>>> It keeps the implementation simple and readable. The implementation is 
>>> more
>>> performant in the sense of calling the API - one capable() call for 
>>> CAP_PERFMON
>>> privileged process.
>>>
>>> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
>>> processes,
>>> but this bloating also advertises and leverages using more secure 
>>> CAP_PERFMON
>>> based approach to use perf_event_open system call.
>>
>> I can live with that.  We just need to document that when you see both a 
>> CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only 
>> allowing CAP_PERFMON first and see if that resolves the issue.  We have 
>> a similar issue with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.
>
> I am trying to reproduce this double logging with CAP_PERFMON.
> I am using the refpolicy version with enabled perf_event tclass [1], in 
> permissive mode.
> When running perf stat -a I am observing this AVC audit messages:
>
> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  
> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  
> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  
> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
> type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  
> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>
> However there is no capability related messages around. I suppose my 
> refpolicy should
> be modified somehow to observe capability related AVCs.
>
> Could you please comment or clarify on how to enable caps related AVCs in 
> order
> to test the concerned logging.

 The new perfmon permission has to be defined in your policy; you'll have a 
 message in dmesg about "Permission perfmon in class capability2 not 
 defined in policy.".  You can either add it to the common cap2 definition 
 in refpolicy/policy/flask/access_vectors and rebuild your policy or 
 extract your base module as CIL, add it there, and insert the updated 
 module.
>>>
>>> Yes, I already have it like this:
>>> common cap2
>>> {
>>> <-->mac_override<--># unused by SELinux
>>> <-->mac_admin
>>> <-->syslog
>>> <-->wake_alarm
>>> <-->block_suspend
>>> <-->audit_read
>>> <-->perfmon
>>> }
>>>
>>> dmesg stopped reporting perfmon as not defined but audit.log still doesn't 
>>> report CAP_PERFMON denials.
>>> BTW, audit even doesn't report CAP_SYS_ADMIN denials, however 
>>> perfmon_capable() does check for it.
>>
>> Some denials may be silenced by dontaudit rules; semodule -DB will strip 
>> those and semodule -B will restore them.  Other possibility is that the 
>> process doesn't have CAP_PERFMON in its effective set and therefore never 
>> reaches SELinux at all; denied first by the capability module.
> 
> Also, the fact that your denials are showing up in user_systemd_t suggests 
> that something is off in your policy or userspace/distro; I assume that is a 
> domain type for the systemd --user instance, but your shell and commands 
> shouldn't be running in that domain (user_t would be more appropriate for 
> that).

It is user_t for local terminal session:
ps -Z
LABEL  

[Intel-gfx] [PATCH V7] drm: Add support for DP 1.4 Compliance edid corruption test

2020-02-12 Thread Jerry (Fangzhi) Zuo
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.

This behavior is not accurate; actually, we need to return
the actual CRC value when corruption is detected.
This commit changes this issue by returning the calculated CRC,
and initiate the required sequence.

Change since v7
- Fix for CI.CHECKPATCH

Change since v6
- Add return check

Change since v5
- Obtain real CRC value before dumping bad edid

Change since v4
- Fix for CI.CHECKPATCH

Change since v3
- Fix a minor typo.

Change since v2
- Rewrite checksum computation routine to avoid duplicated code.
- Rename to avoid confusion.

Change since v1
- Have separate routine for returning real CRC.

Signed-off-by: Jerry (Fangzhi) Zuo 
Reviewed-by: Harry Wentland 
Reviewed-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/drm_dp_helper.c | 59 +
 drivers/gpu/drm/drm_edid.c  | 24 +++---
 include/drm/drm_connector.h |  6 
 include/drm/drm_dp_helper.h |  3 ++
 4 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f629fc5494a4..43e9f1968af4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -351,6 +351,65 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
 
+/**
+ * drm_dp_send_real_edid_checksum() - send back real edid checksum value
+ * @aux: DisplayPort AUX channel
+ * @real_edid_checksum: real edid checksum for the last block
+ *
+ * Returns:
+ * True on success
+ */
+bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
+   u8 real_edid_checksum)
+{
+   u8 link_edid_read = 0, auto_test_req = 0, test_resp = 0;
+
+   if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
+_test_req, 1) < 1) {
+   DRM_ERROR("DPCD failed read at register 0x%x\n",
+ DP_DEVICE_SERVICE_IRQ_VECTOR);
+   return false;
+   }
+   auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
+
+   if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1) < 1) {
+   DRM_ERROR("DPCD failed read at register 0x%x\n",
+ DP_TEST_REQUEST);
+   return false;
+   }
+   link_edid_read &= DP_TEST_LINK_EDID_READ;
+
+   if (!auto_test_req || !link_edid_read) {
+   DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
+   return false;
+   }
+
+   if (drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
+ _test_req, 1) < 1) {
+   DRM_ERROR("DPCD failed write at register 0x%x\n",
+ DP_DEVICE_SERVICE_IRQ_VECTOR);
+   return false;
+   }
+
+   /* send back checksum for the last edid extension block data */
+   if (drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM,
+ _edid_checksum, 1) < 1) {
+   DRM_ERROR("DPCD failed write at register 0x%x\n",
+ DP_TEST_EDID_CHECKSUM);
+   return false;
+   }
+
+   test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
+   if (drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1) < 1) {
+   DRM_ERROR("DPCD failed write at register 0x%x\n",
+ DP_TEST_RESPONSE);
+   return false;
+   }
+
+   return true;
+}
+EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
+
 /**
  * drm_dp_downstream_max_clock() - extract branch device max
  * pixel rate for legacy VGA
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..1fcec5f4c3ec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1590,11 +1590,22 @@ static int validate_displayid(u8 *displayid, int 
length, int idx);
 static int drm_edid_block_checksum(const u8 *raw_edid)
 {
int i;
-   u8 csum = 0;
-   for (i = 0; i < EDID_LENGTH; i++)
+   u8 csum = 0, crc = 0;
+
+   for (i = 0; i < EDID_LENGTH - 1; i++)
csum += raw_edid[i];
 
-   return csum;
+   crc = 0x100 - csum;
+
+   return crc;
+}
+
+static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 real_checksum)
+{
+   if (raw_edid[EDID_LENGTH - 1] != real_checksum)
+   return true;
+   else
+   return false;
 }
 
 static bool drm_edid_is_zero(const u8 *in_edid, int length)
@@ -1652,7 +1663,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
}
 
csum = drm_edid_block_checksum(raw_edid);
-   if (csum) {
+   if (drm_edid_block_checksum_diff(raw_edid, csum)) {
if (edid_corrupt)
*edid_corrupt = true;
 
@@ -1793,6 +1804,11 

Re: [Intel-gfx] [CI 2/2] drm/i915/gt: Track engine round-trip times

2020-02-12 Thread youling 257
it's not the patch "Track engine round-trip times".

it's "drm/i915/gem: Asynchronous cmdparser" "drm/i915/gem: Prepare
gen7 cmdparser for async execution" bad for my Bay trail device.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PULL] drm-misc-next

2020-02-12 Thread Maxime Ripard
Hi Dave, Daniel,

Now that -rc1 is out, here's the first drm-misc-next PR. All things
considered it's been pretty quiet, the diffstat being scary mostly
because of the conversion of device tree bindings to YAML and a new
driver.

Maxime

drm-misc-next-2020-02-10:
drm-misc-next for 5.7:

UAPI Changes:
  - lima: Add support for heap buffers

Cross-subsystem Changes:

Core Changes:
  - Implement mode_config mode_valid for memory constrained drivers
  - Bus format negociation between bridges
  - Consolidate fake vblank events for drivers without vblank interrupts
  - drm/bufs: dma_alloc related cleanups
  - drm/dp_mst: Various fixes
  - drm/print: New drm_device based print helpers
  - Thomas is a drm-misc maintainer now!

Driver Changes:
  - DPMS cleanups for atomic drivers
  - Removal of owner field in SPI tinydrm drivers
  - Removal of explicit dependency on DT for tinydrm drivers
  - Conversion to YAML schemas for DT bindings
  - tidss: New driver
  - virtio: various reworks and fixes
  - Our usual dozen or so new panels or bridges
The following changes since commit 44c58c520ffc4b1f75241e5029c5ae6b223d0623:

  drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support (2020-01-09 
20:27:06 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-02-10

for you to fetch changes up to 06f749af622ca28c4e1f60c43fabd3917114f95a:

  drm/udl: Clear struct drm_connector_funcs.dpms (2020-02-10 09:24:09 +0100)


drm-misc-next for 5.7:

UAPI Changes:
  - lima: Add support for heap buffers

Cross-subsystem Changes:

Core Changes:
  - Implement mode_config mode_valid for memory constrained drivers
  - Bus format negociation between bridges
  - Consolidate fake vblank events for drivers without vblank interrupts
  - drm/bufs: dma_alloc related cleanups
  - drm/dp_mst: Various fixes
  - drm/print: New drm_device based print helpers
  - Thomas is a drm-misc maintainer now!

Driver Changes:
  - DPMS cleanups for atomic drivers
  - Removal of owner field in SPI tinydrm drivers
  - Removal of explicit dependency on DT for tinydrm drivers
  - Conversion to YAML schemas for DT bindings
  - tidss: New driver
  - virtio: various reworks and fixes
  - Our usual dozen or so new panels or bridges


Andy Shevchenko (4):
  drm/tiny/repaper: Make driver OF-independent
  drm/tiny/repaper: No need to set ->owner for spi_register_driver()
  drm/tiny/st7735r: Make driver OF-independent
  drm/tiny/st7735r: No need to set ->owner for spi_register_driver()

Arnd Bergmann (2):
  drm: panel: fix excessive stack usage in td028ttec1_prepare
  drm/drm_panel: fix export of drm_panel_of_backlight, try #3

Benjamin Gaignard (3):
  drm: fix parameters documentation style in drm_dma
  dt-bindings: panel: Convert raydium,rm68200 to json-schema
  dt-bindings: panel: Convert orisetech,otm8009a to json-schema

Bo YU (1):
  drm/drm_dp_mst:remove set but not used variable 'origlen'

Boris Brezillon (8):
  drm/bridge: Add a drm_bridge_state object
  drm/rcar-du: Plug atomic state hooks to the default implementation
  drm/bridge: analogix: Plug atomic state hooks to the default 
implementation
  drm/bridge: Patch atomic hooks to take a drm_bridge_state
  drm/bridge: Add an ->atomic_check() hook
  drm/bridge: Add the necessary bits to support bus format negotiation
  drm/imx: pd: Use bus format/flags provided by the bridge when available
  drm/panel: simple: Fix the lt089ac29000 bus_format

Chia-I Wu (9):
  drm/virtio: fix a wait_event condition
  drm/virtio: remove incorrect ENOSPC check
  drm/virtio: add virtio_gpu_vbuf_ctrl_hdr
  drm/virtio: no need to pass virtio_gpu_ctrl_hdr
  drm/virtio: unlock object array on errors
  drm/virtio: set up virtqueue sgs before locking
  drm/virtio: move locking into virtio_gpu_queue_ctrl_sgs
  drm/virtio: move the check for vqs_ready earlier
  drm/virtio: move virtqueue_notify into virtio_gpu_queue_ctrl_sgs

Chris Wilson (4):
  drm: Release filp before global lock
  drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
  drm: Remove PageReserved manipulation from drm_pci_alloc
  drm: Remove the dma_alloc_coherent wrapper for internal usage

Christian König (1):
  drm/ttm: nuke invalidate_caches callback

Chuhong Yuan (2):
  video: ssd1307fb: add the missed regulator_disable
  pxa168fb: fix release function mismatch in probe failure

Colin Ian King (3):
  video: hyperv_fb: fix indentation issue
  OMAP: DSS2: remove non-zero check on variable r
  video: fbdev: nvidia: clean up indentation issues and comment block

Dan Carpenter (1):
  fbdev: potential information leak in do_fb_ioctl()

Daniel Stone (1):
  drm: Add getfb2 ioctl

Daniel Vetter (8):
  drm/todo: Add item 

Re: [Intel-gfx] [PATCH v3 03/10] drm/i915/guc: Kill USES_GUC_SUBMISSION macro

2020-02-12 Thread Andi Shyti
Hi Daniele,

On Tue, Feb 11, 2020 at 04:31:17PM -0800, Daniele Ceraolo Spurio wrote:
> use intel_uc_uses_guc_submission() directly instead, to be consistent in
> the way we check what we want to do with the GuC.
> 
> v2: do not go through ctx->vm->gt, use i915->gt instead
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Michal Wajdeczko 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Reviewed-by: Michal Wajdeczko  #v1

Reviewed-by: Andi Shyti 

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


[Intel-gfx] [PATCH v2 6/8] drm/i915: s/pipe_config/crtc_state/ in pfit functions

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Follow the new naming convention and call the crtc state
"crtc_state", and while at it drop the redundant crtc argument.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c |  3 +-
 drivers/gpu/drm/i915/display/intel_dp.c|  8 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c  |  5 +-
 drivers/gpu/drm/i915/display/intel_lvds.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_panel.c | 93 +++---
 drivers/gpu/drm/i915/display/intel_panel.h |  6 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c |  5 +-
 7 files changed, 58 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index d842e280699d..7481ec04883a 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1420,7 +1420,6 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
   base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
-   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
const struct drm_display_mode *fixed_mode =
intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode =
@@ -1428,7 +1427,7 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
-   intel_pch_panel_fitting(crtc, pipe_config, conn_state->scaling_mode);
+   intel_pch_panel_fitting(pipe_config, conn_state->scaling_mode);
 
adjusted_mode->flags = 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a827eac8acc2..a352fdcba20c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2306,7 +2306,6 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
const struct drm_display_info *info = >display_info;
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
-   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
if (!drm_mode_is_420_only(info, adjusted_mode) ||
!intel_dp_get_colorimetry_status(intel_dp) ||
@@ -2315,7 +2314,7 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
 
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(crtc, crtc_state, DRM_MODE_SCALE_FULLSCREEN);
+   intel_pch_panel_fitting(crtc_state, DRM_MODE_SCALE_FULLSCREEN);
 
return 0;
 }
@@ -2374,7 +2373,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
enum port port = encoder->port;
-   struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(conn_state);
@@ -2408,10 +2406,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   adjusted_mode);
 
if (HAS_GMCH(dev_priv))
-   intel_gmch_panel_fitting(intel_crtc, pipe_config,
+   intel_gmch_panel_fitting(pipe_config,
 conn_state->scaling_mode);
else
-   intel_pch_panel_fitting(intel_crtc, pipe_config,
+   intel_pch_panel_fitting(pipe_config,
conn_state->scaling_mode);
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 1e42b01045b1..22345880c8f5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2299,8 +2299,6 @@ static bool
 intel_hdmi_ycbcr420_config(struct drm_connector *connector,
   struct intel_crtc_state *config)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(config->uapi.crtc);
-
if (!connector->ycbcr_420_allowed) {
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
return false;
@@ -2308,8 +2306,7 @@ intel_hdmi_ycbcr420_config(struct drm_connector 
*connector,
 
config->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(intel_crtc, config,
-   DRM_MODE_SCALE_FULLSCREEN);
+   intel_pch_panel_fitting(config, DRM_MODE_SCALE_FULLSCREEN);
 
return true;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c

[Intel-gfx] [PATCH v2 2/8] drm/i915: Use intel_de_write_fw() for skl+ scaler registers

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

We have to write quite a few registers when programming the
pipe scaler. Let's use intel_de_write_fw() for these to reduce
the lockdep overhead a bit. All plane registers (including plane
scaler) already do this.

We already had a few accidental intel_de_write_fw() in there.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 61ba1f2256a0..de50aa0b076c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4494,10 +4494,15 @@ static void skl_detach_scaler(struct intel_crtc 
*intel_crtc, int id)
 {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   unsigned long irqflags;
+
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
 
-   intel_de_write(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
-   intel_de_write(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
-   intel_de_write(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
+   intel_de_write_fw(dev_priv, SKL_PS_CTRL(intel_crtc->pipe, id), 0);
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
+
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
 /*
@@ -6234,6 +6239,7 @@ static void skl_pfit_enable(const struct intel_crtc_state 
*crtc_state)
if (crtc_state->pch_pfit.enabled) {
u16 uv_rgb_hphase, uv_rgb_vphase;
int pfit_w, pfit_h, hscale, vscale;
+   unsigned long irqflags;
int id;
 
if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
@@ -6249,16 +6255,21 @@ static void skl_pfit_enable(const struct 
intel_crtc_state *crtc_state)
uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
 
id = scaler_state->scaler_id;
-   intel_de_write(dev_priv, SKL_PS_CTRL(pipe, id),
-  PS_SCALER_EN | PS_FILTER_MEDIUM | 
scaler_state->scalers[id].mode);
+
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
+   intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN 
|
+ PS_FILTER_MEDIUM | 
scaler_state->scalers[id].mode);
intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
  PS_Y_PHASE(0) | 
PS_UV_RGB_PHASE(uv_rgb_vphase));
intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
  PS_Y_PHASE(0) | 
PS_UV_RGB_PHASE(uv_rgb_hphase));
-   intel_de_write(dev_priv, SKL_PS_WIN_POS(pipe, id),
-  crtc_state->pch_pfit.pos);
-   intel_de_write(dev_priv, SKL_PS_WIN_SZ(pipe, id),
-  crtc_state->pch_pfit.size);
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
+ crtc_state->pch_pfit.pos);
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
+ crtc_state->pch_pfit.size);
+
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
}
 }
 
-- 
2.24.1

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


[Intel-gfx] [PATCH v2 4/8] drm/i915: Flatten a bunch of the pfit functions

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Most of the pfit functions are of the form:

func()
{
if (pfit_enabled) {
...
}
}

Flip the pfit_enabled check around to flatten the functions.

And while we're touching all this let's do the usual
s/pipe_config/crtc_state/ replacement.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index becc6322b7dc..796e27c4aece 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6233,42 +6233,42 @@ static void skl_pfit_enable(const struct 
intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
const struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
+   u16 uv_rgb_hphase, uv_rgb_vphase;
+   int pfit_w, pfit_h, hscale, vscale;
+   unsigned long irqflags;
+   int id;
 
-   if (crtc_state->pch_pfit.enabled) {
-   u16 uv_rgb_hphase, uv_rgb_vphase;
-   int pfit_w, pfit_h, hscale, vscale;
-   unsigned long irqflags;
-   int id;
+   if (!crtc_state->pch_pfit.enabled)
+   return;
 
-   if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
-   return;
+   if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
+   return;
 
-   pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
-   pfit_h = crtc_state->pch_pfit.size & 0x;
+   pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
+   pfit_h = crtc_state->pch_pfit.size & 0x;
 
-   hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
-   vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
+   hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
+   vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
 
-   uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
-   uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
+   uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
+   uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
 
-   id = scaler_state->scaler_id;
+   id = scaler_state->scaler_id;
 
-   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
 
-   intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN 
|
- PS_FILTER_MEDIUM | 
scaler_state->scalers[id].mode);
-   intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
- PS_Y_PHASE(0) | 
PS_UV_RGB_PHASE(uv_rgb_vphase));
-   intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
- PS_Y_PHASE(0) | 
PS_UV_RGB_PHASE(uv_rgb_hphase));
-   intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
- crtc_state->pch_pfit.pos);
-   intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
- crtc_state->pch_pfit.size);
+   intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
+ PS_FILTER_MEDIUM | scaler_state->scalers[id].mode);
+   intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
+ PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_vphase));
+   intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
+ PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_hphase));
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
+ crtc_state->pch_pfit.pos);
+   intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
+ crtc_state->pch_pfit.size);
 
-   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
-   }
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
 
 static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state)
@@ -6277,22 +6277,23 @@ static void ilk_pfit_enable(const struct 
intel_crtc_state *crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
-   if (crtc_state->pch_pfit.enabled) {
-   /* Force use of hard-coded filter coefficients
-* as some pre-programmed values are broken,
-* e.g. x201.
-*/
-   if (IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv))
-   intel_de_write(dev_priv, PF_CTL(pipe),
-  PF_ENABLE | PF_FILTER_MED_3x3 | 
PF_PIPE_SEL_IVB(pipe));
-   else
-   intel_de_write(dev_priv, PF_CTL(pipe),
-  PF_ENABLE | PF_FILTER_MED_3x3);
-   intel_de_write(dev_priv, PF_WIN_POS(pipe),
-   

[Intel-gfx] [PATCH v2 7/8] drm/i915: Pass connector state to pfit calculations

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Pass the entire connector state to intel_{gmch,pch}_panel_fitting().
For now we just need to get at .scaling_mode but in the future we'll
want access to the margin properties as well.

v2: Deal with intel_dp_ycbcr420_config()

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c| 17 -
 drivers/gpu/drm/i915/display/intel_hdmi.c  | 12 +++-
 drivers/gpu/drm/i915/display/intel_lvds.c  |  7 ++-
 drivers/gpu/drm/i915/display/intel_panel.c | 17 ++---
 drivers/gpu/drm/i915/display/intel_panel.h |  4 ++--
 drivers/gpu/drm/i915/display/vlv_dsi.c |  6 ++
 7 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 7481ec04883a..d5178be48226 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1427,7 +1427,7 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
-   intel_pch_panel_fitting(pipe_config, conn_state->scaling_mode);
+   intel_pch_panel_fitting(pipe_config, conn_state);
 
adjusted_mode->flags = 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a352fdcba20c..03845bd7d927 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2300,9 +2300,10 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 
 static int
 intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
-struct drm_connector *connector,
-struct intel_crtc_state *crtc_state)
+struct intel_crtc_state *crtc_state,
+const struct drm_connector_state *conn_state)
 {
+   struct drm_connector *connector = conn_state->connector;
const struct drm_display_info *info = >display_info;
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
@@ -2314,7 +2315,7 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
 
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(crtc_state, DRM_MODE_SCALE_FULLSCREEN);
+   intel_pch_panel_fitting(crtc_state, conn_state);
 
return 0;
 }
@@ -2388,8 +2389,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
-   ret = intel_dp_ycbcr420_config(intel_dp, _connector->base,
-  pipe_config);
+   ret = intel_dp_ycbcr420_config(intel_dp, pipe_config,
+  conn_state);
if (ret)
return ret;
 
@@ -2406,11 +2407,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   adjusted_mode);
 
if (HAS_GMCH(dev_priv))
-   intel_gmch_panel_fitting(pipe_config,
-conn_state->scaling_mode);
+   intel_gmch_panel_fitting(pipe_config, conn_state);
else
-   intel_pch_panel_fitting(pipe_config,
-   conn_state->scaling_mode);
+   intel_pch_panel_fitting(pipe_config, conn_state);
}
 
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 22345880c8f5..5e78d993ce77 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2296,17 +2296,19 @@ static bool hdmi_deep_color_possible(const struct 
intel_crtc_state *crtc_state,
 }
 
 static bool
-intel_hdmi_ycbcr420_config(struct drm_connector *connector,
-  struct intel_crtc_state *config)
+intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
 {
+   struct drm_connector *connector = conn_state->connector;
+
if (!connector->ycbcr_420_allowed) {
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
return false;
}
 
-   config->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(config, DRM_MODE_SCALE_FULLSCREEN);
+   intel_pch_panel_fitting(crtc_state, conn_state);
 
return true;
 }
@@ -2434,7 +2436,7 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
pipe_config->pixel_multiplier = 2;
 
if 

[Intel-gfx] [PATCH v2 8/8] drm/i915: Have pfit calculations return an error code

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Change intel_{gmch,pch}_panel_fitting() to return a normal
error vs. success int. We'll need this later to validate that
the margin properties aren't misconfigured.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 10 +++---
 drivers/gpu/drm/i915/display/intel_dp.c| 10 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c  | 22 +++---
 drivers/gpu/drm/i915/display/intel_lvds.c  | 13 -
 drivers/gpu/drm/i915/display/intel_panel.c | 19 +++
 drivers/gpu/drm/i915/display/intel_panel.h |  6 +++---
 drivers/gpu/drm/i915/display/vlv_dsi.c |  6 --
 7 files changed, 49 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index d5178be48226..3134b0436040 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1421,13 +1421,17 @@ static int gen11_dsi_compute_config(struct 
intel_encoder *encoder,
   base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
const struct drm_display_mode *fixed_mode =
-   intel_connector->panel.fixed_mode;
+   intel_connector->panel.fixed_mode;
struct drm_display_mode *adjusted_mode =
-   _config->hw.adjusted_mode;
+   _config->hw.adjusted_mode;
+   int ret;
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
-   intel_pch_panel_fitting(pipe_config, conn_state);
+
+   ret = intel_pch_panel_fitting(pipe_config, conn_state);
+   if (ret)
+   return ret;
 
adjusted_mode->flags = 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 03845bd7d927..e8ebacb066da 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2315,9 +2315,7 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
 
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(crtc_state, conn_state);
-
-   return 0;
+   return intel_pch_panel_fitting(crtc_state, conn_state);
 }
 
 bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
@@ -2407,9 +2405,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
   adjusted_mode);
 
if (HAS_GMCH(dev_priv))
-   intel_gmch_panel_fitting(pipe_config, conn_state);
+   ret = intel_gmch_panel_fitting(pipe_config, conn_state);
else
-   intel_pch_panel_fitting(pipe_config, conn_state);
+   ret = intel_pch_panel_fitting(pipe_config, conn_state);
+   if (ret)
+   return ret;
}
 
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 5e78d993ce77..559caee0bb25 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2295,22 +2295,25 @@ static bool hdmi_deep_color_possible(const struct 
intel_crtc_state *crtc_state,
return true;
 }
 
-static bool
+static int
 intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
struct drm_connector *connector = conn_state->connector;
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+
+   if (!drm_mode_is_420_only(>display_info, adjusted_mode))
+   return 0;
 
if (!connector->ycbcr_420_allowed) {
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
-   return false;
+   return -EINVAL;
}
 
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   intel_pch_panel_fitting(crtc_state, conn_state);
-
-   return true;
+   return intel_pch_panel_fitting(crtc_state, conn_state);
 }
 
 static int intel_hdmi_port_clock(int clock, int bpc)
@@ -2435,12 +2438,9 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
pipe_config->pixel_multiplier = 2;
 
-   if (drm_mode_is_420_only(>display_info, adjusted_mode)) {
-   if (!intel_hdmi_ycbcr420_config(pipe_config, conn_state)) {
-   DRM_ERROR("Can't support YCBCR420 output\n");
-   return -EINVAL;
-   }
-   }
+   ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state);
+   if (ret)
+   return ret;
 
pipe_config->limited_color_range =

[Intel-gfx] [PATCH v2 1/8] drm/i915: Parametrize PFIT_PIPE

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Make the PFIT_PIPE stuff less ugly via parametrization.

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

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index cba2f1c2557f..8b0730f4c442 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -434,8 +434,7 @@ void intel_gmch_panel_fitting(struct intel_crtc *intel_crtc,
/* 965+ wants fuzzy fitting */
/* FIXME: handle multiple panels by failing gracefully */
if (INTEL_GEN(dev_priv) >= 4)
-   pfit_control |= ((intel_crtc->pipe << PFIT_PIPE_SHIFT) |
-PFIT_FILTER_FUZZY);
+   pfit_control |= PFIT_PIPE(intel_crtc->pipe) | PFIT_FILTER_FUZZY;
 
 out:
if ((pfit_control & PFIT_ENABLE) == 0) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..faf8945a51b0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4928,6 +4928,7 @@ enum {
 #define   PFIT_ENABLE  (1 << 31)
 #define   PFIT_PIPE_MASK   (3 << 29)
 #define   PFIT_PIPE_SHIFT  29
+#define   PFIT_PIPE(pipe)  ((pipe) << 29)
 #define   VERT_INTERP_DISABLE  (0 << 10)
 #define   VERT_INTERP_BILINEAR (1 << 10)
 #define   VERT_INTERP_MASK (3 << 10)
-- 
2.24.1

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


[Intel-gfx] [PATCH v2 0/8] drm/i915: pfit/scaler rework prep stuff

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Rebased pfit/scaler rework prep stuff. The eventual aim is to expose
margin properties for external displays. Main use of which is to
squish the image down a bit to avoid overscan on displays that insist
on always overscanning. That will happen via the pfit/pipe scaler.

And to avoid the user getting a black/corrupted screen we also need
to add proper checks against various hw limits (scaling factors,
pfit window coordinates, etc.). In fact we're already missing a bunch
of checks for skl+ plane scaling cases (eg. the scaler simply doesn't
work correctly with >4k resolutions so thos have to be rejected).

Anyways, it's a fair amount of work so I'm posting it in smaller
chunks.

The entire work can be found here:
git://github.com/vsyrjala/linux.git scaler_rework_2

Ville Syrjälä (8):
  drm/i915: Parametrize PFIT_PIPE
  drm/i915: Use intel_de_write_fw() for skl+ scaler registers
  drm/i915: Fix skl+ non-scaled pfit modes
  drm/i915: Flatten a bunch of the pfit functions
  drm/i915: Use drm_rect to store the pfit window pos/size
  drm/i915: s/pipe_config/crtc_state/ in pfit functions
  drm/i915: Pass connector state to pfit calculations
  drm/i915: Have pfit calculations return an error code

 drivers/gpu/drm/i915/display/icl_dsi.c|  11 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 319 ++
 drivers/gpu/drm/i915/display/intel_display.h  |   1 -
 .../drm/i915/display/intel_display_types.h|   3 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  38 +--
 drivers/gpu/drm/i915/display/intel_hdmi.c |  37 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  16 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 127 +++
 drivers/gpu/drm/i915/display/intel_panel.h|  10 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c|   9 +-
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 11 files changed, 288 insertions(+), 284 deletions(-)

-- 
2.24.1

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


[Intel-gfx] [PATCH v2 3/8] drm/i915: Fix skl+ non-scaled pfit modes

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Fix skl_update_scaler_crtc() to deal with different scaling
modes correctly. The current implementation assumes
DRM_MODE_SCALE_FULLSCREEN. Fortunately we don't expose any
border properties currently so the code does actually end
up doing the right thing (assigning a scaler for pfit).
The code does need to be fixed before any borders are
exposed.

Also we have redundant calls to skl_update_scaler_crtc() in
dp/hdmi .compute_config() which can be nuked. They were anyway
called before we had even computed the pfit state so were
basically nonsense. The real call we need to keep is in
intel_crtc_atomic_check().

v2: Deal witrh skl_update_scaler_crtc() in intel_dp_ycbcr420_config()

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
 drivers/gpu/drm/i915/display/intel_display.h |  1 -
 drivers/gpu/drm/i915/display/intel_dp.c  | 15 
 drivers/gpu/drm/i915/display/intel_hdmi.c|  6 ---
 4 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index de50aa0b076c..becc6322b7dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6101,30 +6101,28 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
return 0;
 }
 
-/**
- * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
- *
- * @state: crtc's scaler state
- *
- * Return
- * 0 - scaler_usage updated successfully
- *error - requested scaling cannot be supported or other error condition
- */
-int skl_update_scaler_crtc(struct intel_crtc_state *state)
+static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
 {
-   const struct drm_display_mode *adjusted_mode = >hw.adjusted_mode;
-   bool need_scaler = false;
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+   int width, height;
 
-   if (state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
-   state->pch_pfit.enabled)
-   need_scaler = true;
+   if (crtc_state->pch_pfit.enabled) {
+   u32 pfit_size = crtc_state->pch_pfit.size;
+
+   width = pfit_size >> 16;
+   height = pfit_size & 0x;
+   } else {
+   width = adjusted_mode->crtc_hdisplay;
+   height = adjusted_mode->crtc_vdisplay;
+   }
 
-   return skl_update_scaler(state, !state->hw.active, SKL_CRTC_INDEX,
->scaler_state.scaler_id,
-state->pipe_src_w, state->pipe_src_h,
-adjusted_mode->crtc_hdisplay,
-adjusted_mode->crtc_vdisplay, NULL, 0,
-need_scaler);
+   return skl_update_scaler(crtc_state, !crtc_state->hw.active,
+SKL_CRTC_INDEX,
+_state->scaler_state.scaler_id,
+crtc_state->pipe_src_w, crtc_state->pipe_src_h,
+width, height, NULL, 0,
+crtc_state->pch_pfit.enabled);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 75438a136d58..6291d3dbc513 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -584,7 +584,6 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state);
 
 u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
-int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
 void skl_scaler_disable(const struct intel_crtc_state *old_crtc_state);
 void ilk_pfit_disable(const struct intel_crtc_state *old_crtc_state);
 u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f4dede6253f8..a827eac8acc2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2307,7 +2307,6 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   int ret;
 
if (!drm_mode_is_420_only(info, adjusted_mode) ||
!intel_dp_get_colorimetry_status(intel_dp) ||
@@ -2316,13 +2315,6 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
 
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 
-   /* YCBCR 420 output conversion needs a scaler */
-   ret = skl_update_scaler_crtc(crtc_state);
-   if (ret) {
-   DRM_DEBUG_KMS("Scaler allocation for output failed\n");
-   

[Intel-gfx] [PATCH v2 5/8] drm/i915: Use drm_rect to store the pfit window pos/size

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Make things a bit more abstract by replacing the pch_pfit.pos/size
raw register values with a drm_rect. Makes it slighly more convenient
to eg. compute the scaling factors.

v2: Use drm_rect_init()

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 101 +++---
 .../drm/i915/display/intel_display_types.h|   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  13 ++-
 3 files changed, 67 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 796e27c4aece..19f3fef11b0d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6108,10 +6108,8 @@ static int skl_update_scaler_crtc(struct 
intel_crtc_state *crtc_state)
int width, height;
 
if (crtc_state->pch_pfit.enabled) {
-   u32 pfit_size = crtc_state->pch_pfit.size;
-
-   width = pfit_size >> 16;
-   height = pfit_size & 0x;
+   width = drm_rect_width(_state->pch_pfit.dst);
+   height = drm_rect_height(_state->pch_pfit.dst);
} else {
width = adjusted_mode->crtc_hdisplay;
height = adjusted_mode->crtc_vdisplay;
@@ -6230,11 +6228,20 @@ static void skl_pfit_enable(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);
-   enum pipe pipe = crtc->pipe;
const struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
+   struct drm_rect src = {
+   .x2 = crtc_state->pipe_src_w << 16,
+   .y2 = crtc_state->pipe_src_h << 16,
+   };
+   const struct drm_rect *dst = _state->pch_pfit.dst;
u16 uv_rgb_hphase, uv_rgb_vphase;
-   int pfit_w, pfit_h, hscale, vscale;
+   enum pipe pipe = crtc->pipe;
+   int width = drm_rect_width(dst);
+   int height = drm_rect_height(dst);
+   int x = dst->x1;
+   int y = dst->y1;
+   int hscale, vscale;
unsigned long irqflags;
int id;
 
@@ -6244,11 +6251,8 @@ static void skl_pfit_enable(const struct 
intel_crtc_state *crtc_state)
if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
return;
 
-   pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
-   pfit_h = crtc_state->pch_pfit.size & 0x;
-
-   hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
-   vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
+   hscale = drm_rect_calc_hscale(, dst, 0, INT_MAX);
+   vscale = drm_rect_calc_vscale(, dst, 0, INT_MAX);
 
uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
@@ -6264,9 +6268,9 @@ static void skl_pfit_enable(const struct intel_crtc_state 
*crtc_state)
intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
  PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_hphase));
intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
- crtc_state->pch_pfit.pos);
+ x << 16 | y);
intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
- crtc_state->pch_pfit.size);
+ width << 16 | height);
 
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
@@ -6275,7 +6279,12 @@ static void ilk_pfit_enable(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 drm_rect *dst = _state->pch_pfit.dst;
enum pipe pipe = crtc->pipe;
+   int width = drm_rect_width(dst);
+   int height = drm_rect_height(dst);
+   int x = dst->x1;
+   int y = dst->y1;
 
if (!crtc_state->pch_pfit.enabled)
return;
@@ -6290,10 +6299,8 @@ static void ilk_pfit_enable(const struct 
intel_crtc_state *crtc_state)
else
intel_de_write(dev_priv, PF_CTL(pipe), PF_ENABLE |
   PF_FILTER_MED_3x3);
-   intel_de_write(dev_priv, PF_WIN_POS(pipe),
-  crtc_state->pch_pfit.pos);
-   intel_de_write(dev_priv, PF_WIN_SZ(pipe),
-  crtc_state->pch_pfit.size);
+   intel_de_write(dev_priv, PF_WIN_POS(pipe), x << 16 | y);
+   intel_de_write(dev_priv, PF_WIN_SZ(pipe), width << 16 | height);
 }
 
 void hsw_enable_ips(const struct intel_crtc_state *crtc_state)
@@ -7932,8 +7939,7 @@ static bool intel_crtc_supports_double_wide(const struct 
intel_crtc *crtc)
 static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
 {
u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
-   u32 pfit_size = crtc_state->pch_pfit.size;
-   u64 pipe_w, pipe_h, 

Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Alexey Budankov
On 12.02.2020 18:21, Stephen Smalley wrote:
> On 2/12/20 8:53 AM, Alexey Budankov wrote:
>> On 12.02.2020 16:32, Stephen Smalley wrote:
>>> On 2/12/20 3:53 AM, Alexey Budankov wrote:
 Hi Stephen,

 On 22.01.2020 17:07, Stephen Smalley wrote:
> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>
>> On 21.01.2020 21:27, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
 On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
  wrote:
>
>
> On 21.01.2020 17:43, Stephen Smalley wrote:
>> On 1/20/20 6:23 AM, Alexey Budankov wrote:
>>>
 
>>> Introduce CAP_PERFMON capability designed to secure system 
>>> performance
>>
>> Why _noaudit()?  Normally only used when a permission failure is 
>> non-fatal to the operation.  Otherwise, we want the audit message.
>>
>> So far so good, I suggest using the simplest version for v6:
>>
>> static inline bool perfmon_capable(void)
>> {
>>   return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
>> }
>>
>> It keeps the implementation simple and readable. The implementation is 
>> more
>> performant in the sense of calling the API - one capable() call for 
>> CAP_PERFMON
>> privileged process.
>>
>> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
>> processes,
>> but this bloating also advertises and leverages using more secure 
>> CAP_PERFMON
>> based approach to use perf_event_open system call.
>
> I can live with that.  We just need to document that when you see both a 
> CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only 
> allowing CAP_PERFMON first and see if that resolves the issue.  We have a 
> similar issue with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.

 I am trying to reproduce this double logging with CAP_PERFMON.
 I am using the refpolicy version with enabled perf_event tclass [1], in 
 permissive mode.
 When running perf stat -a I am observing this AVC audit messages:

 type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  
 pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
 tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
 type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  
 pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
 tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
 type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  
 pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
 tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
 type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  
 pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
 tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1

 However there is no capability related messages around. I suppose my 
 refpolicy should
 be modified somehow to observe capability related AVCs.

 Could you please comment or clarify on how to enable caps related AVCs in 
 order
 to test the concerned logging.
>>>
>>> The new perfmon permission has to be defined in your policy; you'll have a 
>>> message in dmesg about "Permission perfmon in class capability2 not defined 
>>> in policy.".  You can either add it to the common cap2 definition in 
>>> refpolicy/policy/flask/access_vectors and rebuild your policy or extract 
>>> your base module as CIL, add it there, and insert the updated module.
>>
>> Yes, I already have it like this:
>> common cap2
>> {
>> <-->mac_override<--># unused by SELinux
>> <-->mac_admin
>> <-->syslog
>> <-->wake_alarm
>> <-->block_suspend
>> <-->audit_read
>> <-->perfmon
>> }
>>
>> dmesg stopped reporting perfmon as not defined but audit.log still doesn't 
>> report CAP_PERFMON denials.
>> BTW, audit even doesn't report CAP_SYS_ADMIN denials, however 
>> perfmon_capable() does check for it.
> 
> Some denials may be silenced by dontaudit rules; semodule -DB will strip 
> those and semodule -B will restore them.  Other possibility is that the 
> process doesn't have CAP_PERFMON in its effective set and therefore never 
> reaches SELinux at all; denied first by the capability module.

Yes, that all makes sense.
selinux_capable() calls avc_audit() logging but cap_capable() doesn't, so 
proper order matters.
I am doing debug tracing of the kernel code to reveal the exact reasons.

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


[Intel-gfx] [PATCH 2/2] drm/i915: Update drm/i915 bug filing URL

2020-02-12 Thread Jani Nikula
We've moved from bugzilla to gitlab.

Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Kconfig  | 5 ++---
 drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
 drivers/gpu/drm/i915/i915_utils.c | 5 ++---
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 023206136d6d..9afa5c4a6bf0 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -68,9 +68,8 @@ config DRM_I915_CAPTURE_ERROR
help
  This option enables capturing the GPU state when a hang is detected.
  This information is vital for triaging hangs and assists in debugging.
- Please report any hang to
-   https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
- for triaging.
+ Please report any hang for triaging according to:
+   
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
 
  If in doubt, say "Y".
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 5a1517d0bf3b..2417c211e1b6 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1862,7 +1862,8 @@ void i915_error_state_store(struct i915_gpu_coredump 
*error)
if (!xchg(, true) &&
ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) {
pr_info("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
-   pr_info("Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel\n");
+   pr_info("Please file a _new_ bug report at 
https://gitlab.freedesktop.org/drm/intel/issues/new.\n;);
+   pr_info("Please see 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for 
details.\n");
pr_info("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
pr_info("The GPU crash dump is required to analyze GPU hangs, 
so please always attach it.\n");
pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n",
diff --git a/drivers/gpu/drm/i915/i915_utils.c 
b/drivers/gpu/drm/i915/i915_utils.c
index c47261ae86ea..632d6953c78d 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -8,9 +8,8 @@
 #include "i915_drv.h"
 #include "i915_utils.h"
 
-#define FDO_BUG_URL "https://bugs.freedesktop.org/enter_bug.cgi?product=DRI;
-#define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL " against DRM/Intel " \
-   "providing the dmesg log by booting with drm.debug=0xf"
+#define FDO_BUG_URL 
"https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs;
+#define FDO_BUG_MSG "Please file a bug on drm/i915; see " FDO_BUG_URL " for 
details."
 
 void
 __i915_printk(struct drm_i915_private *dev_priv, const char *level,
-- 
2.20.1

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


[Intel-gfx] [PATCH 1/2] MAINTAINERS: Update drm/i915 bug filing URL

2020-02-12 Thread Jani Nikula
We've moved from bugzilla to gitlab.

Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b9d8f6c2fd24..3f9a78a726ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8416,7 +8416,7 @@ M:Joonas Lahtinen 

 M: Rodrigo Vivi 
 L: intel-gfx@lists.freedesktop.org
 W: https://01.org/linuxgraphics/
-B: https://01.org/linuxgraphics/documentation/how-report-bugs
+B: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
 C: irc://chat.freenode.net/intel-gfx
 Q: http://patchwork.freedesktop.org/project/intel-gfx/
 T: git git://anongit.freedesktop.org/drm-intel
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Stephen Smalley

On 2/12/20 10:21 AM, Stephen Smalley wrote:

On 2/12/20 8:53 AM, Alexey Budankov wrote:

On 12.02.2020 16:32, Stephen Smalley wrote:

On 2/12/20 3:53 AM, Alexey Budankov wrote:

Hi Stephen,

On 22.01.2020 17:07, Stephen Smalley wrote:

On 1/22/20 5:45 AM, Alexey Budankov wrote:


On 21.01.2020 21:27, Alexey Budankov wrote:


On 21.01.2020 20:55, Alexei Starovoitov wrote:

On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
 wrote:



On 21.01.2020 17:43, Stephen Smalley wrote:

On 1/20/20 6:23 AM, Alexey Budankov wrote:




Introduce CAP_PERFMON capability designed to secure system 
performance


Why _noaudit()?  Normally only used when a permission failure 
is non-fatal to the operation.  Otherwise, we want the audit 
message.


So far so good, I suggest using the simplest version for v6:

static inline bool perfmon_capable(void)
{
  return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
}

It keeps the implementation simple and readable. The 
implementation is more
performant in the sense of calling the API - one capable() call 
for CAP_PERFMON

privileged process.

Yes, it bloats audit log for CAP_SYS_ADMIN privileged and 
unprivileged processes,
but this bloating also advertises and leverages using more secure 
CAP_PERFMON

based approach to use perf_event_open system call.


I can live with that.  We just need to document that when you see 
both a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, 
try only allowing CAP_PERFMON first and see if that resolves the 
issue.  We have a similar issue with CAP_DAC_READ_SEARCH versus 
CAP_DAC_OVERRIDE.


I am trying to reproduce this double logging with CAP_PERFMON.
I am using the refpolicy version with enabled perf_event tclass [1], 
in permissive mode.

When running perf stat -a I am observing this AVC audit messages:

type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  
pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } 
for  pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  
pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } 
for  pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1


However there is no capability related messages around. I suppose my 
refpolicy should

be modified somehow to observe capability related AVCs.

Could you please comment or clarify on how to enable caps related 
AVCs in order

to test the concerned logging.


The new perfmon permission has to be defined in your policy; you'll 
have a message in dmesg about "Permission perfmon in class 
capability2 not defined in policy.".  You can either add it to the 
common cap2 definition in refpolicy/policy/flask/access_vectors and 
rebuild your policy or extract your base module as CIL, add it there, 
and insert the updated module.


Yes, I already have it like this:
common cap2
{
<-->mac_override<--># unused by SELinux
<-->mac_admin
<-->syslog
<-->wake_alarm
<-->block_suspend
<-->audit_read
<-->perfmon
}

dmesg stopped reporting perfmon as not defined but audit.log still 
doesn't report CAP_PERFMON denials.
BTW, audit even doesn't report CAP_SYS_ADMIN denials, however 
perfmon_capable() does check for it.


Some denials may be silenced by dontaudit rules; semodule -DB will strip 
those and semodule -B will restore them.  Other possibility is that the 
process doesn't have CAP_PERFMON in its effective set and therefore 
never reaches SELinux at all; denied first by the capability module.


Also, the fact that your denials are showing up in user_systemd_t 
suggests that something is off in your policy or userspace/distro; I 
assume that is a domain type for the systemd --user instance, but your 
shell and commands shouldn't be running in that domain (user_t would be 
more appropriate for that).

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


Re: [Intel-gfx] [PATCH v1] drm/i915: Ensure no conflicts with BIOS when updating Dbuf

2020-02-12 Thread Lisovskiy, Stanislav
On Wed, 2020-02-12 at 17:36 +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > TGL BIOS seems to enable both DBuf slices ocasionally, depending
> > how many displays are connected, while i915 according to BSpec
> > was powering on S1 DBuf slice, until a modeset was done.
> > 
> > This was causing a brief flash during the boot as we were
> > disabling slice, previously used by BIOS with that.
> > 
> > To prevent this, now we are ensuring tht we are enabling
> > _at least_ one slice, but if there are more, let's not
> > power them off.
> > 
> > Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to
> > pipes")
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 53056def5414..b9a9cbad8a03 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -4470,11 +4470,13 @@ void icl_dbuf_slices_update(struct
> > drm_i915_private *dev_priv,
> >  
> >  static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
> >  {
> > +   skl_ddb_get_hw_state(dev_priv);
> > /*
> > -* Just power up 1 slice, we will
> > +* Just power up at least 1 slice, we will
> >  * figure out later which slices we have and what we need.
> >  */
> > -   icl_dbuf_slices_update(dev_priv, BIT(DBUF_S1));
> > +   icl_dbuf_slices_update(dev_priv, dev_priv-
> > >enabled_dbuf_slices_mask |
> > +  BIT(DBUF_S1));
> 
> I don't know anything about this, but it seems obvious to me the
> enabling code should not do hardware readout; they should be
> separated
> from a much higher level.

Current consensus with Ville is that there is no better place to 
stick it(could be moved to icl_core_init which calls that however
not sure this is any better).
That whole readout is simply done just because at this early stage
we don't yet do a modeset neither have any info, which slices 
should be powered on, however if we enable only single slice as
BSpec says, we might briefly introduce some screen glithes as
BIOS could have used two slices already.


Stan

> 
> BR,
> Jani.
> 
> 
> >  }
> >  
> >  static void icl_dbuf_disable(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 v1] drm/i915: Ensure no conflicts with BIOS when updating Dbuf

2020-02-12 Thread Ville Syrjälä
On Wed, Feb 12, 2020 at 05:36:40PM +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Stanislav Lisovskiy  
> wrote:
> > TGL BIOS seems to enable both DBuf slices ocasionally, depending
> > how many displays are connected, while i915 according to BSpec
> > was powering on S1 DBuf slice, until a modeset was done.
> >
> > This was causing a brief flash during the boot as we were
> > disabling slice, previously used by BIOS with that.
> >
> > To prevent this, now we are ensuring tht we are enabling
> > _at least_ one slice, but if there are more, let's not
> > power them off.
> >
> > Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 53056def5414..b9a9cbad8a03 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -4470,11 +4470,13 @@ void icl_dbuf_slices_update(struct drm_i915_private 
> > *dev_priv,
> >  
> >  static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
> >  {
> > +   skl_ddb_get_hw_state(dev_priv);
> > /*
> > -* Just power up 1 slice, we will
> > +* Just power up at least 1 slice, we will
> >  * figure out later which slices we have and what we need.
> >  */
> > -   icl_dbuf_slices_update(dev_priv, BIT(DBUF_S1));
> > +   icl_dbuf_slices_update(dev_priv, dev_priv->enabled_dbuf_slices_mask |
> > +  BIT(DBUF_S1));
> 
> I don't know anything about this, but it seems obvious to me the
> enabling code should not do hardware readout; they should be separated
> from a much higher level.

This is part of display core init, which is more or less half readout
vs. half initialization anyway. So can't think of a better place for it
really.

What I don't like is that it's now only in the icl+ function but not in
the pre-icl stuff. In fact I don't see why we even have this pre-icl vs.
icl split anymore. The same code should work for both. So as a followup
I'd like to see a patch to nuke the redundant code.

-- 
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 v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Stephen Smalley

On 2/12/20 8:53 AM, Alexey Budankov wrote:

On 12.02.2020 16:32, Stephen Smalley wrote:

On 2/12/20 3:53 AM, Alexey Budankov wrote:

Hi Stephen,

On 22.01.2020 17:07, Stephen Smalley wrote:

On 1/22/20 5:45 AM, Alexey Budankov wrote:


On 21.01.2020 21:27, Alexey Budankov wrote:


On 21.01.2020 20:55, Alexei Starovoitov wrote:

On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
 wrote:



On 21.01.2020 17:43, Stephen Smalley wrote:

On 1/20/20 6:23 AM, Alexey Budankov wrote:





Introduce CAP_PERFMON capability designed to secure system performance


Why _noaudit()?  Normally only used when a permission failure is non-fatal to 
the operation.  Otherwise, we want the audit message.


So far so good, I suggest using the simplest version for v6:

static inline bool perfmon_capable(void)
{
  return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
}

It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for CAP_PERFMON
privileged process.

Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
processes,
but this bloating also advertises and leverages using more secure CAP_PERFMON
based approach to use perf_event_open system call.


I can live with that.  We just need to document that when you see both a 
CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only allowing 
CAP_PERFMON first and see if that resolves the issue.  We have a similar issue 
with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.


I am trying to reproduce this double logging with CAP_PERFMON.
I am using the refpolicy version with enabled perf_event tclass [1], in 
permissive mode.
When running perf stat -a I am observing this AVC audit messages:

type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1

However there is no capability related messages around. I suppose my refpolicy 
should
be modified somehow to observe capability related AVCs.

Could you please comment or clarify on how to enable caps related AVCs in order
to test the concerned logging.


The new perfmon permission has to be defined in your policy; you'll have a message in 
dmesg about "Permission perfmon in class capability2 not defined in policy.".  
You can either add it to the common cap2 definition in 
refpolicy/policy/flask/access_vectors and rebuild your policy or extract your base module 
as CIL, add it there, and insert the updated module.


Yes, I already have it like this:
common cap2
{
<-->mac_override<--># unused by SELinux
<-->mac_admin
<-->syslog
<-->wake_alarm
<-->block_suspend
<-->audit_read
<-->perfmon
}

dmesg stopped reporting perfmon as not defined but audit.log still doesn't 
report CAP_PERFMON denials.
BTW, audit even doesn't report CAP_SYS_ADMIN denials, however perfmon_capable() 
does check for it.


Some denials may be silenced by dontaudit rules; semodule -DB will strip 
those and semodule -B will restore them.  Other possibility is that the 
process doesn't have CAP_PERFMON in its effective set and therefore 
never reaches SELinux at all; denied first by the capability module.




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


Re: [Intel-gfx] [PATCH v1] drm/i915: Ensure no conflicts with BIOS when updating Dbuf

2020-02-12 Thread Jani Nikula
On Wed, 12 Feb 2020, Stanislav Lisovskiy  wrote:
> TGL BIOS seems to enable both DBuf slices ocasionally, depending
> how many displays are connected, while i915 according to BSpec
> was powering on S1 DBuf slice, until a modeset was done.
>
> This was causing a brief flash during the boot as we were
> disabling slice, previously used by BIOS with that.
>
> To prevent this, now we are ensuring tht we are enabling
> _at least_ one slice, but if there are more, let's not
> power them off.
>
> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 53056def5414..b9a9cbad8a03 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4470,11 +4470,13 @@ void icl_dbuf_slices_update(struct drm_i915_private 
> *dev_priv,
>  
>  static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
>  {
> + skl_ddb_get_hw_state(dev_priv);
>   /*
> -  * Just power up 1 slice, we will
> +  * Just power up at least 1 slice, we will
>* figure out later which slices we have and what we need.
>*/
> - icl_dbuf_slices_update(dev_priv, BIT(DBUF_S1));
> + icl_dbuf_slices_update(dev_priv, dev_priv->enabled_dbuf_slices_mask |
> +BIT(DBUF_S1));

I don't know anything about this, but it seems obvious to me the
enabling code should not do hardware readout; they should be separated
from a much higher level.

BR,
Jani.


>  }
>  
>  static void icl_dbuf_disable(struct drm_i915_private *dev_priv)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v1] drm/i915: Ensure no conflicts with BIOS when updating Dbuf

2020-02-12 Thread Stanislav Lisovskiy
TGL BIOS seems to enable both DBuf slices ocasionally, depending
how many displays are connected, while i915 according to BSpec
was powering on S1 DBuf slice, until a modeset was done.

This was causing a brief flash during the boot as we were
disabling slice, previously used by BIOS with that.

To prevent this, now we are ensuring tht we are enabling
_at least_ one slice, but if there are more, let's not
power them off.

Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 53056def5414..b9a9cbad8a03 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4470,11 +4470,13 @@ void icl_dbuf_slices_update(struct drm_i915_private 
*dev_priv,
 
 static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
 {
+   skl_ddb_get_hw_state(dev_priv);
/*
-* Just power up 1 slice, we will
+* Just power up at least 1 slice, we will
 * figure out later which slices we have and what we need.
 */
-   icl_dbuf_slices_update(dev_priv, BIT(DBUF_S1));
+   icl_dbuf_slices_update(dev_priv, dev_priv->enabled_dbuf_slices_mask |
+  BIT(DBUF_S1));
 }
 
 static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
-- 
2.24.1.485.gad05a3d8e5

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


Re: [Intel-gfx] [PATCH] drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.

2020-02-12 Thread Daniel Vetter
On Wed, Feb 12, 2020 at 02:54:45PM +0100, Maarten Lankhorst wrote:
> This fixes the following KASAN splash on module reload:
> [  145.136327] 
> ==
> [  145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 
> [i915]
> [  145.136514] Read of size 8 at addr 888216641830 by task kworker/1:1/134
> 
> [  145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U  T 
> 5.5.0-rc7-valkyria+ #5783
> [  145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 
> 07/27/2016
> [  145.136546] Workqueue: events drm_connector_free_work_fn
> [  145.136551] Call Trace:
> [  145.136560]  dump_stack+0xa1/0xe0
> [  145.136571]  print_address_description.constprop.0+0x1e/0x210
> [  145.136639]  ? intel_hdmi_destroy+0x74/0x80 [i915]
> [  145.136703]  ? intel_hdmi_destroy+0x74/0x80 [i915]
> [  145.136710]  __kasan_report.cold+0x1b/0x37
> [  145.136790]  ? intel_hdmi_destroy+0x74/0x80 [i915]
> [  145.136863]  ? intel_hdmi_destroy+0x74/0x80 [i915]
> [  145.136870]  kasan_report+0x27/0x30
> [  145.136881]  __asan_report_load8_noabort+0x1c/0x20
> [  145.136946]  intel_hdmi_destroy+0x74/0x80 [i915]
> [  145.136954]  drm_connector_free_work_fn+0xd1/0x100
> [  145.136967]  process_one_work+0x86e/0x1610
> [  145.136987]  ? pwq_dec_nr_in_flight+0x2f0/0x2f0
> [  145.137004]  ? move_linked_works+0x128/0x2c0
> [  145.137021]  worker_thread+0x63e/0xc90
> [  145.137048]  kthread+0x2f6/0x3f0
> [  145.137054]  ? calculate_sigpending+0x81/0xa0
> [  145.137059]  ? process_one_work+0x1610/0x1610
> [  145.137064]  ? kthread_bind+0x40/0x40
> [  145.137075]  ret_from_fork+0x24/0x30
> 
> [  145.137111] Allocated by task 0:
> [  145.137119] (stack is not available)
> 
> [  145.137137] Freed by task 5053:
> [  145.137147]  save_stack+0x28/0x90
> [  145.137152]  __kasan_slab_free+0x136/0x180
> [  145.137157]  kasan_slab_free+0x26/0x30
> [  145.137161]  kfree+0xe6/0x350
> [  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
> [  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
> [  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
> [  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
> [  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
> [  145.137489]  pci_device_remove+0x108/0x2d0
> [  145.137494]  device_release_driver_internal+0x1e6/0x4a0
> [  145.137499]  driver_detach+0xcb/0x198
> [  145.137503]  bus_remove_driver+0xde/0x204
> [  145.137508]  driver_unregister+0x6d/0xa0
> [  145.137513]  pci_unregister_driver+0x2e/0x230
> [  145.137576]  i915_exit+0x1f/0x26 [i915]
> [  145.137157]  kasan_slab_free+0x26/0x30
> [  145.137161]  kfree+0xe6/0x350
> [  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
> [  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
> [  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
> [  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
> [  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
> [  145.137489]  pci_device_remove+0x108/0x2d0
> [  145.137494]  device_release_driver_internal+0x1e6/0x4a0
> [  145.137499]  driver_detach+0xcb/0x198
> [  145.137503]  bus_remove_driver+0xde/0x204
> [  145.137508]  driver_unregister+0x6d/0xa0
> [  145.137513]  pci_unregister_driver+0x2e/0x230
> [  145.137576]  i915_exit+0x1f/0x26 [i915]
> [  145.137581]  __x64_sys_delete_module+0x35b/0x470
> [  145.137586]  do_syscall_64+0x99/0x4e0
> [  145.137591]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> [  145.137606] The buggy address belongs to the object at 88821664
> which belongs to the cache kmalloc-8k of size 8192
> [  145.137618] The buggy address is located 6192 bytes inside of
> 8192-byte region [88821664, 888216642000)
> [  145.137630] The buggy address belongs to the page:
> [  145.137640] page:ea0008599000 refcount:1 mapcount:0 
> mapping:888107c02a80 index:0x888216644000 compound_mapcount: 0
> [  145.137647] raw: 02010200  00010001 
> 888107c02a80
> [  145.137652] raw: 888216644000 80020001 0001 
> 
> [  145.137656] page dumped because: kasan: bad access detected
> 
> [  145.137668] Memory state around the buggy address:
> [  145.137678]  888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [  145.137687]  888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [  145.137697] >888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [  145.137706]  ^
> [  145.137715]  888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [  145.137724]  888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [  145.137733] 
> ==
> [  145.137742] Disabling lock debugging due to kernel taint
> 
> Changes since v1:
> - Add fixes tags.
> - Use early unregister.

Yeah, much better than v1.

Reviewed-by: 

Re: [Intel-gfx] [PATCH] drm/i915: Force state->modeset=true when distrust_bios_wm==true

2020-02-12 Thread Lisovskiy, Stanislav
On Wed, 2020-02-12 at 17:01 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently when we load the driver we set distrust_bios_wm=true, which
> will cause active_pipe_changes to get flagged even when we're not
> toggling any pipes on/off. The reason being that we want to fully
> redistribute the dbuf among the active pipes and ignore whatever
> state the firmware left behind.
> 
> Unfortunately when the code flags active_pipe_changes it doesn't
> set state->modeset to true, which means the hardware dbuf state
> won't actually get updated. Hence the hardware and software
> states go out of sync, which can result in planes trying to use a
> disabled dbuf slice. Suprisingly that only seems to corrupt the
> display rather than making the whole display engine keel over.
> 
> Let's fix this for now by flagging state->modeset whenever
> distrust_bios_wm is set.
> 
> Eventually we'll likely want to rip out all of this mess and
> introduce proper statye tracking for dbuf. But that requires
> more work. Toss in a FIXME to that effect.
> 
> Cc: Stanislav Lisovskiy 
> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 61ba1f2256a0..9e4f99ae81fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15027,6 +15027,20 @@ static int intel_atomic_check(struct
> drm_device *dev,
>   if (new_cdclk_state && new_cdclk_state-
> >force_min_cdclk_changed)
>   any_ms = true;
>  
> + /*
> +  * distrust_bios_wm will force a full dbuf recomputation
> +  * but the hardware state will only get updated accordingly
> +  * if state->modeset==true. Hence distrust_bios_wm==true &&
> +  * state->modeset==false is an invalid combination which
> +  * would cause the hardware and software dbuf state to get
> +  * out of sync. We must prevent that.
> +  *
> +  * FIXME clean up this mess and introduce better
> +  * state tracking for dbuf.

I disagree here in that sense, that this is actually not a DBUF
issue :) 
But merely state->modeset and active_pipe_changes going out of sync.
However refactoring here definitely will help to unite those
to somekind of unified new state. At least having this
active_pipe_changes seems to be redundant.

> +  */
> + if (dev_priv->wm.distrust_bios_wm)
> + any_ms = true;
> +

Reviewed-by: Stanislav Lisovskiy 

>   if (any_ms) {
>   ret = intel_modeset_checks(state);
>   if (ret)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Force state->modeset=true when distrust_bios_wm==true

2020-02-12 Thread Ville Syrjala
From: Ville Syrjälä 

Currently when we load the driver we set distrust_bios_wm=true, which
will cause active_pipe_changes to get flagged even when we're not
toggling any pipes on/off. The reason being that we want to fully
redistribute the dbuf among the active pipes and ignore whatever
state the firmware left behind.

Unfortunately when the code flags active_pipe_changes it doesn't
set state->modeset to true, which means the hardware dbuf state
won't actually get updated. Hence the hardware and software
states go out of sync, which can result in planes trying to use a
disabled dbuf slice. Suprisingly that only seems to corrupt the
display rather than making the whole display engine keel over.

Let's fix this for now by flagging state->modeset whenever
distrust_bios_wm is set.

Eventually we'll likely want to rip out all of this mess and
introduce proper statye tracking for dbuf. But that requires
more work. Toss in a FIXME to that effect.

Cc: Stanislav Lisovskiy 
Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 61ba1f2256a0..9e4f99ae81fb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15027,6 +15027,20 @@ static int intel_atomic_check(struct drm_device *dev,
if (new_cdclk_state && new_cdclk_state->force_min_cdclk_changed)
any_ms = true;
 
+   /*
+* distrust_bios_wm will force a full dbuf recomputation
+* but the hardware state will only get updated accordingly
+* if state->modeset==true. Hence distrust_bios_wm==true &&
+* state->modeset==false is an invalid combination which
+* would cause the hardware and software dbuf state to get
+* out of sync. We must prevent that.
+*
+* FIXME clean up this mess and introduce better
+* state tracking for dbuf.
+*/
+   if (dev_priv->wm.distrust_bios_wm)
+   any_ms = true;
+
if (any_ms) {
ret = intel_modeset_checks(state);
if (ret)
-- 
2.24.1

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


[Intel-gfx] [PATCH v3] drm/i915/dsb: Pre allocate and late cleanup of cmd buffer

2020-02-12 Thread Animesh Manna
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.

No change is dsb write/commit functions.

Now dsb get/put function is refactored and currently used only for
reference counting. Below dsb api added to do respective job
mentioned below.

intel_dsb_prepare - Allocate, pin and map the buffer.
intel_dsb_cleanup - Unpin and release the gem object.

RFC: Initial patch for design review.
v2: included _init() part in _prepare(). [Daniel, Ville]
v3: dsb_cleanup called after cleanup_planes. [Daniel]

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_display.c |  36 -
 drivers/gpu/drm/i915/display/intel_dsb.c | 132 ---
 drivers/gpu/drm/i915/display/intel_dsb.h |   2 +
 3 files changed, 116 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 61ba1f2256a0..ae90687e3a6b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15076,6 +15076,19 @@ static int intel_atomic_check(struct drm_device *dev,
 
 static int intel_atomic_prepare_commit(struct intel_atomic_state *state)
 {
+   struct intel_crtc_state *crtc_state;
+   struct intel_crtc *crtc;
+   int i;
+
+   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+   bool mode_changed = needs_modeset(crtc_state);
+
+   if (mode_changed || crtc_state->update_pipe ||
+   crtc_state->uapi.color_mgmt_changed) {
+   intel_dsb_prepare(crtc);
+   }
+   }
+
return drm_atomic_helper_prepare_planes(state->base.dev,
>base);
 }
@@ -15643,15 +15656,26 @@ static void intel_atomic_commit_fence_wait(struct 
intel_atomic_state *intel_stat
_reset);
 }
 
+static void intel_cleanup_dsbs(struct intel_atomic_state *state)
+{
+   struct intel_crtc_state *crtc_state;
+   struct intel_crtc *crtc;
+   int i;
+
+   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i)
+   intel_dsb_cleanup(crtc);
+}
+
 static void intel_atomic_cleanup_work(struct work_struct *work)
 {
-   struct drm_atomic_state *state =
-   container_of(work, struct drm_atomic_state, commit_work);
-   struct drm_i915_private *i915 = to_i915(state->dev);
+   struct intel_atomic_state *state =
+   container_of(work, struct intel_atomic_state, base.commit_work);
+   struct drm_i915_private *i915 = to_i915(state->base.dev);
 
-   drm_atomic_helper_cleanup_planes(>drm, state);
-   drm_atomic_helper_commit_cleanup_done(state);
-   drm_atomic_state_put(state);
+   drm_atomic_helper_cleanup_planes(>drm, >base);
+   intel_cleanup_dsbs(state);
+   drm_atomic_helper_commit_cleanup_done(>base);
+   drm_atomic_state_put(>base);
 
intel_atomic_helper_free_state(i915);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 76ae01277fd6..c31132c41e0f 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -34,6 +34,86 @@
 #define DSB_BYTE_EN_SHIFT  20
 #define DSB_REG_VALUE_MASK 0xf
 
+/**
+ * intel_dsb_prepare() - Allocate, pin and map the DSB command buffer.
+ * @crtc: intel_crtc structure to get pipe info.
+ *
+ * This function prepare the command buffer which is used to store dsb
+ * instructions with data.
+ */
+
+void intel_dsb_prepare(struct intel_crtc *crtc)
+{
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct intel_dsb *dsb = >dsb;
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   u32 *buf;
+   intel_wakeref_t wakeref;
+
+   if (!HAS_DSB(i915) || dsb->cmd_buf)
+   return;
+
+   wakeref = intel_runtime_pm_get(>runtime_pm);
+
+   obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
+   if (IS_ERR(obj)) {
+   DRM_ERROR("Gem object creation failed\n");
+   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 out;
+   }
+
+   buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+   if (IS_ERR(buf)) {
+   DRM_ERROR("Command buffer creation failed\n");
+   goto out;
+   }
+
+   dsb->id = DSB1;
+   dsb->vma = vma;
+   dsb->cmd_buf = buf;
+
+out:
+   /*
+* 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 

Re: [Intel-gfx] [PULL] gvt-fixes

2020-02-12 Thread Jani Nikula
On Wed, 12 Feb 2020, Zhenyu Wang  wrote:
> Hi,
>
> Here's two fixes for gvt. One for missed locking and another for
> firmware allocation change for late load.

Pulled, thanks.

BR,
Jani.

>
> Thanks
> --
> The following changes since commit 5e822e44cecec1ea48925630aa31dfac827fd202:
>
>   drm/i915/gvt: Fix guest boot warning (2019-12-17 11:19:58 +0800)
>
> are available in the Git repository at:
>
>   https://github.com/intel/gvt-linux.git tags/gvt-fixes-2020-02-12
>
> for you to fetch changes up to 0e9d7bb293f3f9c3ee376b126141407efb265f31:
>
>   drm/i915/gvt: more locking for ppgtt mm LRU list (2020-02-10 10:04:34 +0800)
>
> 
> gvt-fixes-2020-02-12
>
> - fix possible high-order allocation fail for late load (Igor)
> - fix one missed lock for ppgtt mm LRU list (Igor)
>
> 
> Igor Druzhinin (2):
>   drm/i915/gvt: fix high-order allocation failure on late load
>   drm/i915/gvt: more locking for ppgtt mm LRU list
>
>  drivers/gpu/drm/i915/gvt/firmware.c | 4 ++--
>  drivers/gpu/drm/i915/gvt/gtt.c  | 4 
>  2 files changed, 6 insertions(+), 2 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display/tgl: Enable hotplug detection in TC5 and TC6

2020-02-12 Thread Patchwork
== Series Details ==

Series: drm/i915/display/tgl: Enable hotplug detection in TC5 and TC6
URL   : https://patchwork.freedesktop.org/series/73267/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7904_full -> Patchwork_16513_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#677]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-iclb3/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +6 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html

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

  * igt@gem_partial_pwrite_pread@writes-after-reads-display:
- shard-hsw:  [PASS][7] -> [FAIL][8] ([i915#694]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-hsw6/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-hsw6/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@i915_suspend@fence-restore-untiled:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x42-random:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-128x42-random.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-128x42-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-256x256-onscreen:
- shard-apl:  [PASS][15] -> [FAIL][16] ([i915#54])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html

  * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-kbl1/igt@kms_draw_...@draw-method-rgb565-blt-xtiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-kbl1/igt@kms_draw_...@draw-method-rgb565-blt-xtiled.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#79]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-glk3/igt@kms_f...@flip-vs-expired-vblank.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#108145])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16513/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-glk:  [PASS][23] -> [FAIL][24] ([i915#899])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7904/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html
   [24]: 

[Intel-gfx] [PATCH 1/2] drm/i915: split out vlv/chv specific suspend/resume code

2020-02-12 Thread Jani Nikula
i915_drv.c is a fairly big file, and having very specific vlv/chv
suspend/resume code in it is a distraction. Split it out to a new
vlv_suspend.[ch] file.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.c| 498 +
 drivers/gpu/drm/i915/i915_drv.h|   2 -
 drivers/gpu/drm/i915/vlv_suspend.c | 484 
 drivers/gpu/drm/i915/vlv_suspend.h |  18 ++
 5 files changed, 516 insertions(+), 489 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/vlv_suspend.c
 create mode 100644 drivers/gpu/drm/i915/vlv_suspend.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 49eed50ef0a4..86e889a82c54 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -54,7 +54,8 @@ i915-y += i915_drv.o \
  intel_runtime_pm.o \
  intel_sideband.o \
  intel_uncore.o \
- intel_wakeref.o
+ intel_wakeref.o \
+ vlv_suspend.o
 
 # core library code
 i915-y += \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 516536234e97..afc68591e48a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -80,71 +80,10 @@
 #include "intel_csr.h"
 #include "intel_memory_region.h"
 #include "intel_pm.h"
+#include "vlv_suspend.h"
 
 static struct drm_driver driver;
 
-struct vlv_s0ix_state {
-   /* GAM */
-   u32 wr_watermark;
-   u32 gfx_prio_ctrl;
-   u32 arb_mode;
-   u32 gfx_pend_tlb0;
-   u32 gfx_pend_tlb1;
-   u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
-   u32 media_max_req_count;
-   u32 gfx_max_req_count;
-   u32 render_hwsp;
-   u32 ecochk;
-   u32 bsd_hwsp;
-   u32 blt_hwsp;
-   u32 tlb_rd_addr;
-
-   /* MBC */
-   u32 g3dctl;
-   u32 gsckgctl;
-   u32 mbctl;
-
-   /* GCP */
-   u32 ucgctl1;
-   u32 ucgctl3;
-   u32 rcgctl1;
-   u32 rcgctl2;
-   u32 rstctl;
-   u32 misccpctl;
-
-   /* GPM */
-   u32 gfxpause;
-   u32 rpdeuhwtc;
-   u32 rpdeuc;
-   u32 ecobus;
-   u32 pwrdwnupctl;
-   u32 rp_down_timeout;
-   u32 rp_deucsw;
-   u32 rcubmabdtmr;
-   u32 rcedata;
-   u32 spare2gh;
-
-   /* Display 1 CZ domain */
-   u32 gt_imr;
-   u32 gt_ier;
-   u32 pm_imr;
-   u32 pm_ier;
-   u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
-
-   /* GT SA CZ domain */
-   u32 tilectl;
-   u32 gt_fifoctl;
-   u32 gtlc_wake_ctrl;
-   u32 gtlc_survive;
-   u32 pmwgicz;
-
-   /* Display 2 CZ domain */
-   u32 gu_ctl0;
-   u32 gu_ctl1;
-   u32 pcbr;
-   u32 clock_gate_dis2;
-};
-
 static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
 {
int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
@@ -446,29 +385,6 @@ static void intel_detect_preproduction_hw(struct 
drm_i915_private *dev_priv)
}
 }
 
-static int vlv_alloc_s0ix_state(struct drm_i915_private *i915)
-{
-   if (!IS_VALLEYVIEW(i915))
-   return 0;
-
-   /* we write all the values in the struct, so no need to zero it out */
-   i915->vlv_s0ix_state = kmalloc(sizeof(*i915->vlv_s0ix_state),
-  GFP_KERNEL);
-   if (!i915->vlv_s0ix_state)
-   return -ENOMEM;
-
-   return 0;
-}
-
-static void vlv_free_s0ix_state(struct drm_i915_private *i915)
-{
-   if (!i915->vlv_s0ix_state)
-   return;
-
-   kfree(i915->vlv_s0ix_state);
-   i915->vlv_s0ix_state = NULL;
-}
-
 static void sanitize_gpu(struct drm_i915_private *i915)
 {
if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
@@ -517,7 +433,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
if (ret < 0)
return ret;
 
-   ret = vlv_alloc_s0ix_state(dev_priv);
+   ret = vlv_suspend_init(dev_priv);
if (ret < 0)
goto err_workqueues;
 
@@ -548,7 +464,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
 err_gem:
i915_gem_cleanup_early(dev_priv);
intel_gt_driver_late_release(_priv->gt);
-   vlv_free_s0ix_state(dev_priv);
+   vlv_suspend_cleanup(dev_priv);
 err_workqueues:
i915_workqueues_cleanup(dev_priv);
return ret;
@@ -565,7 +481,7 @@ static void i915_driver_late_release(struct 
drm_i915_private *dev_priv)
intel_power_domains_cleanup(dev_priv);
i915_gem_cleanup_early(dev_priv);
intel_gt_driver_late_release(_priv->gt);
-   vlv_free_s0ix_state(dev_priv);
+   vlv_suspend_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
 
pm_qos_remove_request(_priv->sb_qos);
@@ -1673,10 +1589,6 @@ static void intel_suspend_encoders(struct 
drm_i915_private *dev_priv)
drm_modeset_unlock_all(dev);
 }
 
-static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
-   

[Intel-gfx] [PATCH 2/2] drm/i915: switch vlv_suspend to use intel uncore register accessors

2020-02-12 Thread Jani Nikula
Prefer intel_uncore_* over I915_READ, I915_WRITE, and POSTING_READ.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/vlv_suspend.c | 237 +++--
 1 file changed, 121 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/vlv_suspend.c 
b/drivers/gpu/drm/i915/vlv_suspend.c
index 05047fe7765f..43eb3797f867 100644
--- a/drivers/gpu/drm/i915/vlv_suspend.c
+++ b/drivers/gpu/drm/i915/vlv_suspend.c
@@ -102,80 +102,81 @@ struct vlv_s0ix_state {
  * a black-box for the driver. Further investigation is needed to reduce the
  * saved/restored registers even further, by following the same 3 criteria.
  */
-static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
+static void vlv_save_gunit_s0ix_state(struct drm_i915_private *i915)
 {
-   struct vlv_s0ix_state *s = dev_priv->vlv_s0ix_state;
+   struct vlv_s0ix_state *s = i915->vlv_s0ix_state;
+   struct intel_uncore *uncore = >uncore;
int i;
 
if (!s)
return;
 
/* GAM 0x4000-0x4770 */
-   s->wr_watermark = I915_READ(GEN7_WR_WATERMARK);
-   s->gfx_prio_ctrl= I915_READ(GEN7_GFX_PRIO_CTRL);
-   s->arb_mode = I915_READ(ARB_MODE);
-   s->gfx_pend_tlb0= I915_READ(GEN7_GFX_PEND_TLB0);
-   s->gfx_pend_tlb1= I915_READ(GEN7_GFX_PEND_TLB1);
+   s->wr_watermark = intel_uncore_read(uncore, GEN7_WR_WATERMARK);
+   s->gfx_prio_ctrl = intel_uncore_read(uncore, GEN7_GFX_PRIO_CTRL);
+   s->arb_mode = intel_uncore_read(uncore, ARB_MODE);
+   s->gfx_pend_tlb0 = intel_uncore_read(uncore, GEN7_GFX_PEND_TLB0);
+   s->gfx_pend_tlb1 = intel_uncore_read(uncore, GEN7_GFX_PEND_TLB1);
 
for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
-   s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS(i));
+   s->lra_limits[i] = intel_uncore_read(uncore, 
GEN7_LRA_LIMITS(i));
 
-   s->media_max_req_count  = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
-   s->gfx_max_req_count= I915_READ(GEN7_GFX_MAX_REQ_COUNT);
+   s->media_max_req_count = intel_uncore_read(uncore, 
GEN7_MEDIA_MAX_REQ_COUNT);
+   s->gfx_max_req_count = intel_uncore_read(uncore, 
GEN7_GFX_MAX_REQ_COUNT);
 
-   s->render_hwsp  = I915_READ(RENDER_HWS_PGA_GEN7);
-   s->ecochk   = I915_READ(GAM_ECOCHK);
-   s->bsd_hwsp = I915_READ(BSD_HWS_PGA_GEN7);
-   s->blt_hwsp = I915_READ(BLT_HWS_PGA_GEN7);
+   s->render_hwsp = intel_uncore_read(uncore, RENDER_HWS_PGA_GEN7);
+   s->ecochk = intel_uncore_read(uncore, GAM_ECOCHK);
+   s->bsd_hwsp = intel_uncore_read(uncore, BSD_HWS_PGA_GEN7);
+   s->blt_hwsp = intel_uncore_read(uncore, BLT_HWS_PGA_GEN7);
 
-   s->tlb_rd_addr  = I915_READ(GEN7_TLB_RD_ADDR);
+   s->tlb_rd_addr = intel_uncore_read(uncore, GEN7_TLB_RD_ADDR);
 
/* MBC 0x9024-0x91D0, 0x8500 */
-   s->g3dctl   = I915_READ(VLV_G3DCTL);
-   s->gsckgctl = I915_READ(VLV_GSCKGCTL);
-   s->mbctl= I915_READ(GEN6_MBCTL);
+   s->g3dctl = intel_uncore_read(uncore, VLV_G3DCTL);
+   s->gsckgctl = intel_uncore_read(uncore, VLV_GSCKGCTL);
+   s->mbctl = intel_uncore_read(uncore, GEN6_MBCTL);
 
/* GCP 0x9400-0x9424, 0x8100-0x810C */
-   s->ucgctl1  = I915_READ(GEN6_UCGCTL1);
-   s->ucgctl3  = I915_READ(GEN6_UCGCTL3);
-   s->rcgctl1  = I915_READ(GEN6_RCGCTL1);
-   s->rcgctl2  = I915_READ(GEN6_RCGCTL2);
-   s->rstctl   = I915_READ(GEN6_RSTCTL);
-   s->misccpctl= I915_READ(GEN7_MISCCPCTL);
+   s->ucgctl1 = intel_uncore_read(uncore, GEN6_UCGCTL1);
+   s->ucgctl3 = intel_uncore_read(uncore, GEN6_UCGCTL3);
+   s->rcgctl1 = intel_uncore_read(uncore, GEN6_RCGCTL1);
+   s->rcgctl2 = intel_uncore_read(uncore, GEN6_RCGCTL2);
+   s->rstctl = intel_uncore_read(uncore, GEN6_RSTCTL);
+   s->misccpctl = intel_uncore_read(uncore, GEN7_MISCCPCTL);
 
/* GPM 0xA000-0xAA84, 0x8000-0x80FC */
-   s->gfxpause = I915_READ(GEN6_GFXPAUSE);
-   s->rpdeuhwtc= I915_READ(GEN6_RPDEUHWTC);
-   s->rpdeuc   = I915_READ(GEN6_RPDEUC);
-   s->ecobus   = I915_READ(ECOBUS);
-   s->pwrdwnupctl  = I915_READ(VLV_PWRDWNUPCTL);
-   s->rp_down_timeout  = I915_READ(GEN6_RP_DOWN_TIMEOUT);
-   s->rp_deucsw= I915_READ(GEN6_RPDEUCSW);
-   s->rcubmabdtmr  = I915_READ(GEN6_RCUBMABDTMR);
-   s->rcedata  = I915_READ(VLV_RCEDATA);
-   s->spare2gh = I915_READ(VLV_SPAREG2H);
+   s->gfxpause = intel_uncore_read(uncore, GEN6_GFXPAUSE);
+   s->rpdeuhwtc = intel_uncore_read(uncore, GEN6_RPDEUHWTC);
+   s->rpdeuc = intel_uncore_read(uncore, GEN6_RPDEUC);
+   s->ecobus = intel_uncore_read(uncore, ECOBUS);
+   s->pwrdwnupctl = 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls

2020-02-12 Thread Petri Latvala
On Mon, Jan 27, 2020 at 12:18:17PM +, Chris Wilson wrote:
> We [will] expose various per-engine scheduling controls. One of which,
> 'heartbeat_duration_ms', defines how often we send a heartbeat down the
> engine to check upon the health of the engine. If a heartbeat does not
> complete within the interval (or two), the engine is declared hung.
> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/Makefile.sources|   3 +
>  tests/i915/sysfs_heartbeat_interval.c | 466 ++
>  tests/meson.build |   1 +
>  3 files changed, 470 insertions(+)
>  create mode 100644 tests/i915/sysfs_heartbeat_interval.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index fc9e04e97..fd6f67a73 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -102,6 +102,9 @@ TESTS_progs = \
>   vgem_slow \
>   $(NULL)
>  
> +TESTS_progs += sysfs_heartbeat_interval
> +sysfs_heartbeat_interval_SOURCES = i915/sysfs_heartbeat_interval

Another missing .c


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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs

2020-02-12 Thread Petri Latvala
On Mon, Jan 27, 2020 at 12:18:16PM +, Chris Wilson wrote:
> We [will] expose various per-engine scheduling controls. One of which,
> 'preempt_timeout_ms', defines how we wait for a preemption request to be
> honoured by the currently executing context. If it fails to relieve the
> GPU within the required timeout, the engine is reset and the miscreant
> forcibly evicted.
> 
> Signed-off-by: Chris Wilson 
> ---
>  lib/i915/gem_context.c |  41 
>  lib/i915/gem_context.h |   2 +
>  lib/i915/gem_engine_topology.c |  48 +
>  lib/i915/gem_engine_topology.h |   3 +
>  tests/Makefile.sources |   3 +
>  tests/i915/sysfs_preempt_timeout.c | 309 +
>  tests/meson.build  |   1 +
>  7 files changed, 407 insertions(+)
>  create mode 100644 tests/i915/sysfs_preempt_timeout.c
> 
> diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
> index 0b6a554df..fc874a187 100644
> --- a/lib/i915/gem_context.c
> +++ b/lib/i915/gem_context.c
> @@ -462,3 +462,44 @@ bool gem_context_has_engine(int fd, uint32_t ctx, 
> uint64_t engine)
>  
>   return __gem_execbuf(fd, ) == -ENOENT;
>  }
> +
> +static int create_ext_ioctl(int i915,
> + struct drm_i915_gem_context_create_ext *arg)
> +{
> + int err;
> +
> + err = 0;
> + if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
> + err = -errno;
> + igt_assume(err);
> + }
> +
> + errno = 0;
> + return err;
> +}
> +
> +uint32_t gem_context_create_for_engine(int i915, unsigned int class, 
> unsigned int inst)
> +{
> + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = {
> + .engines = { { .engine_class = class, .engine_instance = inst } 
> }
> + };
> + struct drm_i915_gem_context_create_ext_setparam p_engines = {
> + .base = {
> + .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
> + .next_extension = 0, /* end of chain */
> + },
> + .param = {
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(),
> + .size = sizeof(engines),
> + },
> + };
> + struct drm_i915_gem_context_create_ext create = {
> + .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> + .extensions = to_user_pointer(_engines),
> + };
> +
> + igt_assert_eq(create_ext_ioctl(i915, ), 0);
> + igt_assert_neq(create.ctx_id, 0);
> + return create.ctx_id;
> +}
> diff --git a/lib/i915/gem_context.h b/lib/i915/gem_context.h
> index cf2ba33fe..ded75bb9c 100644
> --- a/lib/i915/gem_context.h
> +++ b/lib/i915/gem_context.h
> @@ -34,6 +34,8 @@ int __gem_context_create(int fd, uint32_t *ctx_id);
>  void gem_context_destroy(int fd, uint32_t ctx_id);
>  int __gem_context_destroy(int fd, uint32_t ctx_id);
>  
> +uint32_t gem_context_create_for_engine(int fd, unsigned int class, unsigned 
> int inst);
> +
>  int __gem_context_clone(int i915,
>   uint32_t src, unsigned int share,
>   unsigned int flags,
> diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
> index 058983123..81faf3c15 100644
> --- a/lib/i915/gem_engine_topology.c
> +++ b/lib/i915/gem_engine_topology.c
> @@ -22,6 +22,8 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "drmtest.h"
> @@ -415,3 +417,49 @@ uint32_t gem_engine_mmio_base(int i915, const char 
> *engine)
>  
>   return mmio;
>  }
> +
> +void dyn_sysfs_engines(int i915, int engines, const char *file,
> +void (*test)(int, int))
> +{
> + char buf[512];
> + int len;
> +
> + lseek(engines, 0, SEEK_SET);
> + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) > 0) {
> + void *ptr = buf;
> +
> + while (len) {
> + struct linux_dirent64 {
> + ino64_td_ino;
> + off64_td_off;
> + unsigned short d_reclen;
> + unsigned char  d_type;
> + char   d_name[];
> + } *de = ptr;
> + char *name;
> + int engine;
> +
> + ptr += de->d_reclen;
> + len -= de->d_reclen;
> +
> + engine = openat(engines, de->d_name, O_RDONLY);
> + name = igt_sysfs_get(engine, "name");
> + if (!name) {
> + close(engine);
> + continue;
> + }
> +
> + igt_dynamic(name) {
> + if (file) {
> + struct stat st;
> +
> + igt_require(fstatat(engine, file, , 
> 0) == 0);

[Intel-gfx] [PATCH] drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.

2020-02-12 Thread Maarten Lankhorst
This fixes the following KASAN splash on module reload:
[  145.136327] 
==
[  145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136514] Read of size 8 at addr 888216641830 by task kworker/1:1/134

[  145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U  T 
5.5.0-rc7-valkyria+ #5783
[  145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 
07/27/2016
[  145.136546] Workqueue: events drm_connector_free_work_fn
[  145.136551] Call Trace:
[  145.136560]  dump_stack+0xa1/0xe0
[  145.136571]  print_address_description.constprop.0+0x1e/0x210
[  145.136639]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136703]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136710]  __kasan_report.cold+0x1b/0x37
[  145.136790]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136863]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136870]  kasan_report+0x27/0x30
[  145.136881]  __asan_report_load8_noabort+0x1c/0x20
[  145.136946]  intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136954]  drm_connector_free_work_fn+0xd1/0x100
[  145.136967]  process_one_work+0x86e/0x1610
[  145.136987]  ? pwq_dec_nr_in_flight+0x2f0/0x2f0
[  145.137004]  ? move_linked_works+0x128/0x2c0
[  145.137021]  worker_thread+0x63e/0xc90
[  145.137048]  kthread+0x2f6/0x3f0
[  145.137054]  ? calculate_sigpending+0x81/0xa0
[  145.137059]  ? process_one_work+0x1610/0x1610
[  145.137064]  ? kthread_bind+0x40/0x40
[  145.137075]  ret_from_fork+0x24/0x30

[  145.137111] Allocated by task 0:
[  145.137119] (stack is not available)

[  145.137137] Freed by task 5053:
[  145.137147]  save_stack+0x28/0x90
[  145.137152]  __kasan_slab_free+0x136/0x180
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137581]  __x64_sys_delete_module+0x35b/0x470
[  145.137586]  do_syscall_64+0x99/0x4e0
[  145.137591]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

[  145.137606] The buggy address belongs to the object at 88821664
which belongs to the cache kmalloc-8k of size 8192
[  145.137618] The buggy address is located 6192 bytes inside of
8192-byte region [88821664, 888216642000)
[  145.137630] The buggy address belongs to the page:
[  145.137640] page:ea0008599000 refcount:1 mapcount:0 
mapping:888107c02a80 index:0x888216644000 compound_mapcount: 0
[  145.137647] raw: 02010200  00010001 
888107c02a80
[  145.137652] raw: 888216644000 80020001 0001 

[  145.137656] page dumped because: kasan: bad access detected

[  145.137668] Memory state around the buggy address:
[  145.137678]  888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  145.137687]  888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  145.137697] >888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  145.137706]  ^
[  145.137715]  888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  145.137724]  888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[  145.137733] 
==
[  145.137742] Disabling lock debugging due to kernel taint

Changes since v1:
- Add fixes tags.
- Use early unregister.

Signed-off-by: Maarten Lankhorst 
Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
Cc:  # v4.19+
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 

Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Alexey Budankov
On 12.02.2020 16:32, Stephen Smalley wrote:
> On 2/12/20 3:53 AM, Alexey Budankov wrote:
>> Hi Stephen,
>>
>> On 22.01.2020 17:07, Stephen Smalley wrote:
>>> On 1/22/20 5:45 AM, Alexey Budankov wrote:

 On 21.01.2020 21:27, Alexey Budankov wrote:
>
> On 21.01.2020 20:55, Alexei Starovoitov wrote:
>> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>>  wrote:
>>>
>>>
>>> On 21.01.2020 17:43, Stephen Smalley wrote:
 On 1/20/20 6:23 AM, Alexey Budankov wrote:
>
>> 
> Introduce CAP_PERFMON capability designed to secure system performance

 Why _noaudit()?  Normally only used when a permission failure is 
 non-fatal to the operation.  Otherwise, we want the audit message.

 So far so good, I suggest using the simplest version for v6:

 static inline bool perfmon_capable(void)
 {
  return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
 }

 It keeps the implementation simple and readable. The implementation is more
 performant in the sense of calling the API - one capable() call for 
 CAP_PERFMON
 privileged process.

 Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
 processes,
 but this bloating also advertises and leverages using more secure 
 CAP_PERFMON
 based approach to use perf_event_open system call.
>>>
>>> I can live with that.  We just need to document that when you see both a 
>>> CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only 
>>> allowing CAP_PERFMON first and see if that resolves the issue.  We have a 
>>> similar issue with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.
>>
>> I am trying to reproduce this double logging with CAP_PERFMON.
>> I am using the refpolicy version with enabled perf_event tclass [1], in 
>> permissive mode.
>> When running perf stat -a I am observing this AVC audit messages:
>>
>> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  
>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  
>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>> type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  pid=2779 
>> comm="perf" scontext=user_u:user_r:user_systemd_t 
>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>> type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  
>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t 
>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>>
>> However there is no capability related messages around. I suppose my 
>> refpolicy should
>> be modified somehow to observe capability related AVCs.
>>
>> Could you please comment or clarify on how to enable caps related AVCs in 
>> order
>> to test the concerned logging.
> 
> The new perfmon permission has to be defined in your policy; you'll have a 
> message in dmesg about "Permission perfmon in class capability2 not defined 
> in policy.".  You can either add it to the common cap2 definition in 
> refpolicy/policy/flask/access_vectors and rebuild your policy or extract your 
> base module as CIL, add it there, and insert the updated module.

Yes, I already have it like this:
common cap2
{
<-->mac_override<--># unused by SELinux
<-->mac_admin
<-->syslog
<-->wake_alarm
<-->block_suspend
<-->audit_read
<-->perfmon
}

dmesg stopped reporting perfmon as not defined but audit.log still doesn't 
report CAP_PERFMON denials.
BTW, audit even doesn't report CAP_SYS_ADMIN denials, however perfmon_capable() 
does check for it.

~Alexey

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


Re: [Intel-gfx] [PATCH v2 1/7] drm/i915: Iterate over pipe and skip the disabled one

2020-02-12 Thread Ville Syrjälä
On Tue, Feb 11, 2020 at 10:55:26PM +0530, Anshuman Gupta wrote:
> It should not be assumed that a disabled display pipe will be
> always last the pipe.
> for_each_pipe() should iterate over I915_MAX_PIPES and check
> for the disabled pipe and skip that pipe so that it should not
> initialize the intel crtc for any disabled pipes.
> 
> Below compilation error require to be handle due to change in
> for_each_pipe() macro.
> "suggest explicit braces to avoid ambiguous ‘else’ [-Werror=dangling-else]"
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_display.h | 5 +++--
>  drivers/gpu/drm/i915/i915_irq.c  | 6 --
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 75438a136d58..7a531e485b53 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -313,10 +313,11 @@ enum phy_fia {
>  };
>  
>  #define for_each_pipe(__dev_priv, __p) \
> - for ((__p) = 0; (__p) < INTEL_NUM_PIPES(__dev_priv); (__p)++)
> + for ((__p) = 0; (__p) < I915_MAX_PIPES; (__p)++) \
> + for_each_if((INTEL_INFO(__dev_priv)->pipe_mask) & BIT(__p))
>  
>  #define for_each_pipe_masked(__dev_priv, __p, __mask) \
> - for ((__p) = 0; (__p) < INTEL_NUM_PIPES(__dev_priv); (__p)++) \
> + for_each_pipe(__dev_priv, __p) \
>   for_each_if((__mask) & BIT(__p))

You didn't address my comments for this stuff! Please don't leave
review comments unaddressed, it's just wasting everyone's time.

>  
>  #define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3d0cd0960bd2..a26f2bf1b6ea 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1739,11 +1739,12 @@ static void ibx_irq_handler(struct drm_i915_private 
> *dev_priv, u32 pch_iir)
>   if (pch_iir & SDE_POISON)
>   drm_err(_priv->drm, "PCH poison interrupt\n");
>  
> - if (pch_iir & SDE_FDI_MASK)
> + if (pch_iir & SDE_FDI_MASK) {
>   for_each_pipe(dev_priv, pipe)
>   drm_dbg(_priv->drm, "  pipe %c FDI IIR: 0x%08x\n",
>   pipe_name(pipe),
>   I915_READ(FDI_RX_IIR(pipe)));
> + }
>  
>   if (pch_iir & (SDE_TRANSB_CRC_DONE | SDE_TRANSA_CRC_DONE))
>   drm_dbg(_priv->drm, "PCH transcoder CRC done interrupt\n");
> @@ -1823,11 +1824,12 @@ static void cpt_irq_handler(struct drm_i915_private 
> *dev_priv, u32 pch_iir)
>   if (pch_iir & SDE_AUDIO_CP_CHG_CPT)
>   drm_dbg(_priv->drm, "Audio CP change interrupt\n");
>  
> - if (pch_iir & SDE_FDI_MASK_CPT)
> + if (pch_iir & SDE_FDI_MASK_CPT) {
>   for_each_pipe(dev_priv, pipe)
>   drm_dbg(_priv->drm, "  pipe %c FDI IIR: 0x%08x\n",
>   pipe_name(pipe),
>   I915_READ(FDI_RX_IIR(pipe)));
> + }
>  
>   if (pch_iir & SDE_ERROR_CPT)
>   cpt_serr_int_handler(dev_priv);
> -- 
> 2.24.0

-- 
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 v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space

2020-02-12 Thread Stephen Smalley

On 2/12/20 3:53 AM, Alexey Budankov wrote:

Hi Stephen,

On 22.01.2020 17:07, Stephen Smalley wrote:

On 1/22/20 5:45 AM, Alexey Budankov wrote:


On 21.01.2020 21:27, Alexey Budankov wrote:


On 21.01.2020 20:55, Alexei Starovoitov wrote:

On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
 wrote:



On 21.01.2020 17:43, Stephen Smalley wrote:

On 1/20/20 6:23 AM, Alexey Budankov wrote:





Introduce CAP_PERFMON capability designed to secure system performance


Why _noaudit()?  Normally only used when a permission failure is non-fatal to 
the operation.  Otherwise, we want the audit message.


So far so good, I suggest using the simplest version for v6:

static inline bool perfmon_capable(void)
{
 return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
}

It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for CAP_PERFMON
privileged process.

Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged 
processes,
but this bloating also advertises and leverages using more secure CAP_PERFMON
based approach to use perf_event_open system call.


I can live with that.  We just need to document that when you see both a 
CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only allowing 
CAP_PERFMON first and see if that resolves the issue.  We have a similar issue 
with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.


I am trying to reproduce this double logging with CAP_PERFMON.
I am using the refpolicy version with enabled perf_event tclass [1], in 
permissive mode.
When running perf stat -a I am observing this AVC audit messages:

type=AVC msg=audit(1581496695.666:8691): avc:  denied  { open } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { kernel } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8691): avc:  denied  { cpu } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
type=AVC msg=audit(1581496695.666:8692): avc:  denied  { write } for  pid=2779 
comm="perf" scontext=user_u:user_r:user_systemd_t 
tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1

However there is no capability related messages around. I suppose my refpolicy 
should
be modified somehow to observe capability related AVCs.

Could you please comment or clarify on how to enable caps related AVCs in order
to test the concerned logging.


The new perfmon permission has to be defined in your policy; you'll have 
a message in dmesg about "Permission perfmon in class capability2 not 
defined in policy.".  You can either add it to the common cap2 
definition in refpolicy/policy/flask/access_vectors and rebuild your 
policy or extract your base module as CIL, add it there, and insert the 
updated module.



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


[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP 2.2 Comp fixes

2020-02-12 Thread Patchwork
== Series Details ==

Series: HDCP 2.2 Comp fixes
URL   : https://patchwork.freedesktop.org/series/73323/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7919 -> Patchwork_16528


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#184])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7919/fi-icl-guc/igt@gem_exec_susp...@basic-s4-devices.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16528/fi-icl-guc/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy:   [PASS][3] -> [DMESG-FAIL][4] ([i915#722])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7919/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16528/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html

  
 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2:  [FAIL][5] ([i915#262]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7919/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16528/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [DMESG-WARN][7] ([i915#44]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7919/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16528/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
  [i915#184]: https://gitlab.freedesktop.org/drm/intel/issues/184
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722


Participating hosts (53 -> 38)
--

  Missing(15): fi-ilk-m540 fi-ehl-1 fi-bdw-samus fi-cml-s fi-hsw-4200u 
fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ilk-650 fi-kbl-7500u fi-ctg-p8600 
fi-bsw-kefka fi-blb-e6850 fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7919 -> Patchwork_16528

  CI-20190529: 20190529
  CI_DRM_7919: 2fd4d5cecb4d376812677108c7c90316a081cbcc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5435: 2b6d4476dde53c363b8808ed9f0dd5547ac78641 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16528: c65d4d8af1ade2c8b8c907cca7c6857db0027a25 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c65d4d8af1ad drm/i915/hdcp: Mandate zero seq_num_V at first RecvId msg

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/gt: Expand bad CS completion event debug

2020-02-12 Thread Mika Kuoppala
Chris Wilson  writes:

> Show the ring/request/context state if we see what we believe is an
> early CS completion.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/intel_context.c |  3 ++-
>  drivers/gpu/drm/i915/gt/intel_lrc.c | 31 +++--
>  2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 57e8a051ddc2..e4f89341d17c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -116,7 +116,8 @@ int __intel_context_do_pin(struct intel_context *ce)
>   if (unlikely(err))
>   goto err_active;
>  
> - CE_TRACE(ce, "pin ring:{head:%04x, tail:%04x}\n",
> + CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
> +  i915_ggtt_offset(ce->ring->vma),
>ce->ring->head, ce->ring->tail);
>  
>   smp_mb__before_atomic(); /* flush pin before it is visible */
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 902d440ef07d..1e3db37dea2b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2328,8 +2328,35 @@ static void process_csb(struct intel_engine_cs *engine)
>* coherent (visible from the CPU) before the
>* user interrupt and CSB is processed.
>*/
> - GEM_BUG_ON(!i915_request_completed(*execlists->active) 
> &&
> -!reset_in_progress(execlists));
> + if (GEM_SHOW_DEBUG() &&
> + !i915_request_completed(*execlists->active) &&
> + !reset_in_progress(execlists)) {
> + struct i915_request *rq = *execlists->active;
> + const u32 *regs = rq->context->lrc_reg_state;
> +
> + ENGINE_TRACE(engine,
> +  "ring:{start:0x%08x, head:%04x, 
> tail:%04x, ctl:%08x, mode:%08x}\n",
> +  ENGINE_READ(engine, RING_START),
> +  ENGINE_READ(engine, RING_HEAD) & 
> HEAD_ADDR,
> +  ENGINE_READ(engine, RING_TAIL) & 
> TAIL_ADDR,
> +  ENGINE_READ(engine, RING_CTL),
> +  ENGINE_READ(engine, RING_MI_MODE));
> + ENGINE_TRACE(engine,
> +  "rq:{start:%08x, head:%04x, 
> tail:%04x, seqno:%llx:%d, hwsp:%d}, ",
> +  i915_ggtt_offset(rq->ring->vma),
> +  rq->head, rq->tail,
> +  rq->fence.context,
> +  lower_32_bits(rq->fence.seqno),
> +  hwsp_seqno(rq));
> + ENGINE_TRACE(engine,
> +  "ctx:{start:%08x, head:%04x, 
> tail:%04x}, ",
> +  regs[CTX_RING_START],
> +  regs[CTX_RING_HEAD],
> +  regs[CTX_RING_TAIL]);
> +
> + GEM_BUG_ON("context completed before request");
> + }
> +
>   execlists_schedule_out(*execlists->active++);
>  
>   GEM_BUG_ON(execlists->active - execlists->inflight >
> -- 
> 2.25.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   >