[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2)

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

Series: drm/i915/display: Prevent double YUV range correction on HDR planes 
(rev2)
URL   : https://patchwork.freedesktop.org/series/84966/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489_full -> Patchwork_19152_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@gem_exec_balancer@fairslice}:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb3/igt@gem_exec_balan...@fairslice.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb1/igt@gem_exec_balan...@fairslice.html

  * {igt@gem_exec_schedule@u-fairslice@vcs1}:
- shard-tglb: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vcs1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vcs1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][5] -> [INCOMPLETE][6] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2389])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][8] -> [SKIP][9] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][10] ([i915#2658])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +11 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl1/igt@gem_render_c...@linear-to-vebox-y-tiled.html

  * igt@i915_pm_rpm@system-suspend:
- shard-skl:  [PASS][12] -> [INCOMPLETE][13] ([i915#151])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@i915_pm_...@system-suspend.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl3/igt@i915_pm_...@system-suspend.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk9/igt@kms_big...@x-tiled-32bpp-rotate-90.html

  * igt@kms_color_chamelium@pipe-a-ctm-red-to-blue:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@kms_color_chamel...@pipe-a-ctm-red-to-blue.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#54])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html

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

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#79])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * igt@kms_flip@flip-vs-suspend@c-hdmi-a1:
- shard-hsw:  [PASS][22] -> [INCOMPLETE][23] ([i915#2055])
   [22]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] i915/perf: Move gen specific OA formats to single array

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

Series: series starting with [1/2] i915/perf: Move gen specific OA formats to 
single array
URL   : https://patchwork.freedesktop.org/series/84978/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489_full -> Patchwork_19151_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_partial_pwrite_pread@writes-after-reads-display:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) 
+1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk7/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-glk4/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][3] ([i915#2658])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-apl3/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-skl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +11 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl5/igt@gem_render_c...@linear-to-vebox-y-tiled.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-glk4/igt@kms_big...@x-tiled-32bpp-rotate-90.html

  * igt@kms_color_chamelium@pipe-a-ctm-red-to-blue:
- shard-apl:  NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-apl3/igt@kms_color_chamel...@pipe-a-ctm-red-to-blue.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-sliding:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-256x85-sliding.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl7/igt@kms_cursor_...@pipe-a-cursor-256x85-sliding.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#79])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2598])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@b-edp1:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#2122])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_flip@wf_vblank-ts-check-interrupti...@b-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl3/igt@kms_flip@wf_vblank-ts-check-interrupti...@b-edp1.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#1188])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_...@bpc-switch-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl3/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([i915#198])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@prime_vgem@fence-write-hang:
- shard-apl:  NOTRUN -> [SKIP][23] ([fdo#109271]) 

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for DP-HDMI2.1 PCON (rev7)

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

Series: Add support for DP-HDMI2.1 PCON (rev7)
URL   : https://patchwork.freedesktop.org/series/82098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19153


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-apl-guc/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar 
issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@gem_mmap_...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +30 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#2029] / [i915#2722])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[DMESG-WARN][8] -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [INCOMPLETE][10] ([i915#2750]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [INCOMPLETE][12] ([i915#2377]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][14] ([i915#402]) -> [PASS][15] +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19153/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2750]: https://gitlab.freedesktop.org/drm/intel/issues/2750
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9489 -> Patchwork_19153

  CI-20190529: 20190529
  CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19153: f1ff1f79d3edbaa9f8d5cbbde42b436e98c6d373 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f1ff1f79d3ed drm/i915/display: Let PCON convert from RGB to YUV if it can
7b1db3cb9688 drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
3e0bdb5325f7 drm/i915: Add helper functions for calculating DSC parameters for 
HDMI2.1
121b50d5c4f9 drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
cdf76e6dd367 drm/i915: Add support for enabling link status and recovery
1d97d3ca87bd drm/i915: Check for FRL training before DP Link 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for DP-HDMI2.1 PCON (rev7)

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

Series: Add support for DP-HDMI2.1 PCON (rev7)
URL   : https://patchwork.freedesktop.org/series/82098/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for DP-HDMI2.1 PCON (rev7)

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

Series: Add support for DP-HDMI2.1 PCON (rev7)
URL   : https://patchwork.freedesktop.org/series/82098/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b643098d366f drm/edid: Add additional HFVSDB fields for HDMI2.1
-:61: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email name mismatch: 
'From: Swati Sharma ' != 'Signed-off-by: Sharma, 
Swati2 '

total: 0 errors, 1 warnings, 0 checks, 36 lines checked
2a8d461d1aac drm/edid: Parse MAX_FRL field from HFVSDB block
-:73: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#73: FILE: drivers/gpu/drm/drm_edid.c:4948:
+   drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+   >max_frl_rate_per_lane);

-:95: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email name mismatch: 
'From: Swati Sharma ' != 'Signed-off-by: Sharma, 
Swati2 '

total: 0 errors, 1 warnings, 1 checks, 68 lines checked
75eea23aecff drm/edid: Parse DSC1.2 cap fields from HFVSDB block
-:51: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#51: FILE: drivers/gpu/drm/drm_edid.c:4969:
+   drm_get_max_frl_rate(dsc_max_frl_rate, 
_dsc->max_lanes,
+   _dsc->max_frl_rate_per_lane);

-:52: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#52: FILE: drivers/gpu/drm/drm_edid.c:4970:
+   hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] & 
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;

total: 0 errors, 1 warnings, 1 checks, 125 lines checked
4e14c826f024 drm/dp_helper: Add Helpers for FRL Link Training support for 
DP-HDMI2.1 PCON
62259a4da05e drm/dp_helper: Add support for link failure detection
-:112: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#112: FILE: include/drm/drm_dp_helper.h:2055:
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);

total: 0 errors, 0 warnings, 1 checks, 76 lines checked
266a0995f989 drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
-:15: WARNING:TYPO_SPELLING: 'Convertor' may be misspelled - perhaps 
'Converter'?
#15: 
v3: Only setting the DSC bits for the Protocol Convertor control

-:165: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#165: FILE: drivers/gpu/drm/drm_dp_helper.c:3037:
+ * */

-:185: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#185: FILE: drivers/gpu/drm/drm_dp_helper.c:3057:
+ * */

-:210: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#210: FILE: drivers/gpu/drm/drm_dp_helper.c:3082:
+ * */

total: 0 errors, 4 warnings, 0 checks, 343 lines checked
a231438ae8b0 drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
-:18: WARNING:TYPO_SPELLING: 'accomodate' may be misspelled - perhaps 
'accommodate'?
#18: 
-Modified the color-conversion cap helper function, to accomodate

total: 0 errors, 1 warnings, 0 checks, 106 lines checked
fda29a86933b drm/i915: Capture max frl rate for PCON in dfp cap structure
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.

total: 0 errors, 1 warnings, 0 checks, 60 lines checked
37563e5e44fd drm/i915: Add support for starting FRL training for HDMI2.1 via 
PCON
-:86: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#86: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4005:
+{
+

-:147: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#147: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4066:
+   wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true, 
TIMEOUT_FRL_READY_MS);

-:166: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#166: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4085:
+   wait_for(is_active = drm_dp_pcon_hdmi_link_active(_dp->aux) == 
true, TIMEOUT_HDMI_LINK_ACTIVE_MS);

-:172: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#172: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4091:
+   if (DP_PCON_HDMI_MODE_FRL != drm_dp_pcon_hdmi_link_mode(_dp->aux, 
_trained_mask)) {

-:172: WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on 
the right side of the test
#172: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4091:
+   if (DP_PCON_HDMI_MODE_FRL != drm_dp_pcon_hdmi_link_mode(_dp->aux, 
_trained_mask)) {

-:176: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#176: FILE: drivers/gpu/drm/i915/display/intel_dp.c:4095:
+   drm_dbg(>drm, "MAX_FRL_MASK = %u, FRL_TRAINED_MASK = %u\n", 
max_frl_bw_mask, frl_trained_mask);

total: 0 errors, 5 warnings, 1 checks, 194 lines checked
1d97d3ca87bd drm/i915: Check for FRL training before DP Link training
cdf76e6dd367 drm/i915: Add support for enabling link status and recovery
-:54: WARNING:LONG_LINE: line length 

[Intel-gfx] [PATCH v5 15/15] drm/i915/display: Let PCON convert from RGB to YUV if it can

2020-12-15 Thread Ankit Nautiyal
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.

v2: As suggested by Uma Shankar, considered case for colorspace
BT709 and BT2020, and default to BT609. Also appended dir
'display' in commit message.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 68 +++
 drivers/gpu/drm/i915/display/intel_dp.h   |  3 +-
 4 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index fbc07a93504b..17eaa56c5a99 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
 
+   intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
/*
 * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
@@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
intel_ddi_init_dp_buf_reg(encoder, crtc_state);
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
-   intel_dp_configure_protocol_converter(intel_dp);
+   intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
  true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4c01c7c23dfd..2009ae9e9678 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,7 @@ struct intel_dp {
int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+   bool rgb_to_ycbcr;
} dfp;
 
/* Display stream compression testing */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index abc9b772d1c8..7781245c2afe 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector *connector,
!drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
 
+   if (intel_dp->dfp.rgb_to_ycbcr &&
+   intel_dp->dfp.ycbcr_444_to_420)
+   return INTEL_OUTPUT_FORMAT_RGB;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
@@ -4311,7 +4315,8 @@ static void intel_dp_enable_port(struct intel_dp 
*intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
-void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
+void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
+  const struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 tmp;
@@ -4338,14 +4343,34 @@ void intel_dp_configure_protocol_converter(struct 
intel_dp *intel_dp)
drm_dbg_kms(>drm,
"Failed to set protocol converter YCbCr 4:2:0 
conversion mode to %s\n",
enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
-
-   tmp = 0;
-
-   if (drm_dp_dpcd_writeb(_dp->aux,
-  DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
+   if (intel_dp->dfp.rgb_to_ycbcr) {
+   bool bt2020, bt709;
+
+   bt2020 = 
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+   
intel_dp->downstream_ports,
+   
DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
+   bt709 = 
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+   
intel_dp->downstream_ports,
+   
DP_DS_HDMI_BT709_RGB_YCBCR_CONV);
+   switch (crtc_state->infoframes.vsc.colorimetry) {
+   case DP_COLORIMETRY_BT2020_RGB:
+   case DP_COLORIMETRY_BT2020_YCC:
+   tmp = bt2020 ? DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE : 
0;
+   break;
+   case DP_COLORIMETRY_BT709_YCC:
+   case DP_COLORIMETRY_XVYCC_709:
+   tmp = bt709 ? DP_CONVERSION_BT709_RGB_YCBCR_ENABLE : 0;
+   break;
+   default:
+   

[Intel-gfx] [PATCH v5 14/15] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding

2020-12-15 Thread Ankit Nautiyal
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.

This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.

v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message

v3: Only consider non-zero DSC FRL b/w for determining max FRL b/w
supported by sink.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |   1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 118 ++-
 drivers/gpu/drm/i915/display/intel_dp.h  |   2 +
 3 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 974cf42351bc..fbc07a93504b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3653,6 +3653,7 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
 
intel_dp_check_frl_training(intel_dp);
+   intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
 
/*
 * 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 87592bebff01..abc9b772d1c8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4035,9 +4035,22 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
*intel_dp)
 {
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+   int max_frl_rate;
+   int max_lanes, rate_per_lane;
+   int max_dsc_lanes, dsc_rate_per_lane;
 
-   return (connector->display_info.hdmi.max_frl_rate_per_lane *
-   connector->display_info.hdmi.max_lanes);
+   max_lanes = connector->display_info.hdmi.max_lanes;
+   rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+   max_frl_rate = max_lanes * rate_per_lane;
+
+   if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+   max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+   dsc_rate_per_lane = 
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+   if (max_dsc_lanes && dsc_rate_per_lane)
+   max_frl_rate = min(max_frl_rate, max_dsc_lanes * 
dsc_rate_per_lane);
+   }
+
+   return max_frl_rate;
 }
 
 static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4144,6 +4157,105 @@ void intel_dp_check_frl_training(struct intel_dp 
*intel_dp)
}
 }
 
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+   int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+   return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+   int hdmi_throughput = 
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+   int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+   int pcon_max_slices = 
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+   int pcon_max_slice_width = 
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+   return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+   int output_format = crtc_state->output_format;
+   bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
+   int pcon_fractional_bpp = 
drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
+   int hdmi_max_chunk_bytes =
+   connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
+
+   return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
+ num_slices, output_format, hdmi_all_bpp,
+ hdmi_max_chunk_bytes);
+}
+
+void

[Intel-gfx] [PATCH v5 12/15] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder

2020-12-15 Thread Ankit Nautiyal
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.

v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.

v3: rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 20 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index daecff9783ea..4c01c7c23dfd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1362,6 +1362,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+   u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index daf2faaa40fb..87592bebff01 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3980,6 +3980,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   /* Clear the cached register set to avoid using stale values */
+
+   memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+   drm_err(>drm, "Failed to read DPCD register 0x%x\n",
+   DP_PCON_DSC_ENCODER);
+
+   drm_dbg_kms(>drm, "PCON ENCODER DSC DPCD: %*ph\n",
+  (int)sizeof(intel_dp->pcon_dsc_dpcd), 
intel_dp->pcon_dsc_dpcd);
+}
+
 static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
 {
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
@@ -6712,6 +6730,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.min_tmds_clock,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw);
+
+   intel_dp_get_pcon_dsc_cap(intel_dp);
 }
 
 static void
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 13/15] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1

2020-12-15 Thread Ankit Nautiyal
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.

This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.

v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
 drivers/gpu/drm/i915/display/intel_hdmi.h |   7 +
 2 files changed, 240 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e10fdb369daa..41eb1c175a0e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
 }
+
+/*
+ * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
+ * @vactive: Vactive of a display mode
+ *
+ * @return: appropriate dsc slice height for a given mode.
+ */
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+   int slice_height;
+
+   /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+   for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+   if (vactive % slice_height == 0)
+   return slice_height;
+
+   return 0;
+}
+
+/*
+ * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc encoder
+ * and dsc decoder capabilites
+ *
+ * @crtc_state: intel crtc_state
+ * @src_max_slices: maximum slices supported by the DSC encoder
+ * @src_max_slice_width: maximum slice width supported by DSC encoder
+ * @hdmi_max_slices: maximum slices supported by sink DSC decoder
+ * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI sink
+ *
+ * @return: num of dsc slices that can be supported by the dsc encoder
+ * and decoder.
+ */
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE   272
+/*
+ * Rates at which the source and sink are required to process pixels in each
+ * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
+ */
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0  34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1  40
+
+/* Spec limits the slice width to 2720 pixels */
+#define MAX_HDMI_SLICE_WIDTH   2720
+   int kslice_adjust;
+   int adjusted_clk_khz;
+   int min_slices;
+   int target_slices;
+   int max_throughput; /* max clock freq. in khz per slice */
+   int max_slice_width;
+   int slice_width;
+   int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+   if (!hdmi_throughput)
+   return 0;
+
+   /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+   crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+   kslice_adjust = 10;
+   else
+   kslice_adjust = 5;
+
+   /*
+* As per spec, the rate at which the source and the sink process
+* the pixels per slice are at two levels: atleast 340Mhz or 400Mhz.
+* This depends upon the pixel clock rate and output formats
+* (kslice adjust).
+* If pixel clock * kslice adjust >= 2720MHz slices can be processed
+* at max 340MHz, otherwise they can be processed at max 400MHz.
+*/
+
+   adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+   if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+   max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+   else
+   max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+   /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+   max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+   min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+   max_slice_width = 

[Intel-gfx] [PATCH v5 09/15] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON

2020-12-15 Thread Ankit Nautiyal
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.

v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.

v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().

v4: Fixed typo in initialization of frl structure.

v5: Always use FRL if its possible, instead of enabling only for
higher modes as done in v3.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 .../drm/i915/display/intel_display_types.h|   7 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 151 ++
 drivers/gpu/drm/i915/display/intel_dp.h   |   2 +
 3 files changed, 160 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c88d2b918d9f..daecff9783ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1339,6 +1339,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
 };
 
+struct intel_dp_pcon_frl {
+   bool is_trained;
+   int trained_rate_gbps;
+};
+
 struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1461,6 +1466,8 @@ struct intel_dp {
 
bool hobl_failed;
bool hobl_active;
+
+   struct intel_dp_pcon_frl frl;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 660b4bd2280a..1fdcb7672ad0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3883,6 +3883,8 @@ static void intel_disable_dp(struct intel_atomic_state 
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+   intel_dp->frl.is_trained = false;
+   intel_dp->frl.trained_rate_gbps = 0;
 }
 
 static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3978,6 +3980,152 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+   int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+   int i;
+
+   for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+   if (frl_bw_mask & (1 << i))
+   return bw_gbps[i];
+   }
+   return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+   switch (max_frl) {
+   case 48:
+   return DP_PCON_FRL_BW_MASK_48GBPS;
+   case 40:
+   return DP_PCON_FRL_BW_MASK_40GBPS;
+   case 32:
+   return DP_PCON_FRL_BW_MASK_32GBPS;
+   case 24:
+   return DP_PCON_FRL_BW_MASK_24GBPS;
+   case 18:
+   return DP_PCON_FRL_BW_MASK_18GBPS;
+   case 9:
+   return DP_PCON_FRL_BW_MASK_9GBPS;
+   }
+
+   return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+
+   return (connector->display_info.hdmi.max_frl_rate_per_lane *
+   connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+   u8 max_frl_bw_mask = 0, frl_trained_mask;
+   bool is_active;
+
+   ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+   if (ret < 0)
+   return ret;
+
+   max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+   drm_dbg(>drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+   max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+   drm_dbg(>drm, "Sink max rate from EDID = %d Gbps\n", 
max_edid_frl_bw);
+
+   max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+   if (max_frl_bw <= 0)
+   return -EINVAL;
+
+   ret = drm_dp_pcon_frl_prepare(_dp->aux, false);
+   if (ret < 0)
+   return ret;
+   /* Wait for PCON to be FRL Ready */
+   wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true, 
TIMEOUT_FRL_READY_MS);
+
+   if (!is_active)
+   return 

[Intel-gfx] [PATCH v5 11/15] drm/i915: Add support for enabling link status and recovery

2020-12-15 Thread Ankit Nautiyal
From: Swati Sharma 

In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.

v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)

v3: Rearranged code to re-start FRL link training or fall back to
TMDS mode.

v4: Resused function to check frl which inturn restarts FRL and
fallback to TMDS mode.

Signed-off-by: Swati Sharma 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/i915/display/intel_dp.c | 53 +++--
 1 file changed, 50 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9d0adce14613..daf2faaa40fb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6005,6 +6005,28 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
 }
 
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+   bool is_active;
+   u8 buf = 0;
+
+   is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+   if (intel_dp->frl.is_trained && !is_active) {
+   if (drm_dp_dpcd_readb(_dp->aux, 
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+   return;
+
+   buf &=  ~DP_PCON_ENABLE_HDMI_LINK;
+   if (drm_dp_dpcd_writeb(_dp->aux, 
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+   return;
+
+   drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux, 
_dp->attached_connector->base);
+
+   /* Restart FRL training or fall back to TMDS mode */
+   intel_dp_check_frl_training(intel_dp);
+   }
+}
+
 static bool
 intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
 {
@@ -6370,7 +6392,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
 }
 
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6394,6 +6416,30 @@ static void intel_dp_check_service_irq(struct intel_dp 
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
 }
 
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 val;
+
+   if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+   return;
+
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 || 
!val) {
+   drm_dbg_kms(>drm, "Error in reading link service irq 
vector\n");
+   return;
+   }
+
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+   drm_dbg_kms(>drm, "Error in writing link service irq 
vector\n");
+   return;
+   }
+
+   if (val & HDMI_LINK_STATUS_CHANGED)
+   intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
 /*
  * According to DP spec
  * 5.1.2:
@@ -6433,7 +6479,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
 
-   intel_dp_check_service_irq(intel_dp);
+   intel_dp_check_device_service_irq(intel_dp);
+   intel_dp_check_link_service_irq(intel_dp);
 
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6863,7 +6910,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
 
-   intel_dp_check_service_irq(intel_dp);
+   intel_dp_check_device_service_irq(intel_dp);
 
 out:
if (status != connector_status_connected && !intel_dp->is_mst)
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 10/15] drm/i915: Check for FRL training before DP Link training

2020-12-15 Thread Ankit Nautiyal
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.

v2: moved check_frl_training() just after FEC READY, before
starting DP link training.

v3: rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6863236df1d0..974cf42351bc 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3652,6 +3652,8 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
 */
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
 
+   intel_dp_check_frl_training(intel_dp);
+
/*
 * 7.i Follow DisplayPort specification training sequence (see notes for
 * failure handling)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1fdcb7672ad0..9d0adce14613 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4256,6 +4256,7 @@ static void intel_enable_dp(struct intel_atomic_state 
*state,
 
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
intel_dp_configure_protocol_converter(intel_dp);
+   intel_dp_check_frl_training(intel_dp);
intel_dp_start_link_train(intel_dp, pipe_config);
intel_dp_stop_link_train(intel_dp, pipe_config);
 
@@ -6177,6 +6178,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
!intel_dp_mst_is_master_trans(crtc_state))
continue;
 
+   intel_dp_check_frl_training(intel_dp);
intel_dp_start_link_train(intel_dp, crtc_state);
intel_dp_stop_link_train(intel_dp, crtc_state);
break;
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 08/15] drm/i915: Capture max frl rate for PCON in dfp cap structure

2020-12-15 Thread Ankit Nautiyal
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON.

This patch captures this in dfp cap structure in intel_dp and uses
this to prune connector modes that cannot be supported by the PCON
and FRL bandwidth.

v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 30 +--
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..c88d2b918d9f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1451,6 +1451,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+   int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb5e42c3ecd5..660b4bd2280a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,6 +716,25 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
const struct drm_display_info *info = >base.display_info;
int tmds_clock;
 
+   /* If PCON supports FRL MODE, check FRL bandwidth constraints */
+   if (intel_dp->dfp.pcon_max_frl_bw) {
+   int target_bw;
+   int max_frl_bw;
+   int bpp = intel_dp_mode_min_output_bpp(>base, mode);
+
+   target_bw = bpp * target_clock;
+
+   max_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+
+   /* converting bw from Gbps to Kbps*/
+   max_frl_bw = max_frl_bw * 100;
+
+   if (target_bw > max_frl_bw)
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+   }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6484,13 +6503,18 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
 intel_dp->downstream_ports,
 edid);
 
+   intel_dp->dfp.pcon_max_frl_bw =
+   drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+  intel_dp->downstream_ports);
+
drm_dbg_kms(>drm,
-   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS 
clock %d-%d\n",
+   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS 
clock %d-%d, PCON Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
-   intel_dp->dfp.max_tmds_clock);
+   intel_dp->dfp.max_tmds_clock,
+   intel_dp->dfp.pcon_max_frl_bw);
 }
 
 static void
@@ -6582,6 +6606,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
 
+   intel_dp->dfp.pcon_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
 }
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion

2020-12-15 Thread Ankit Nautiyal
DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651

This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
conversion through PCON.

v2: As suggested in review comments:
-Fixed bug in the check condition in a drm_helper as reported by
 Dan Carpenter and Kernel test robot. (Dan Carepenter)
-Modified the color-conversion cap helper function, to accomodate
 BT709 and BT2020 colorspace. (Uma Shankar)
-Added spec details for the new cap for color conversion. (Uma Shankar)

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_dp_helper.c | 61 +
 include/drm/drm_dp_helper.h | 19 +-
 2 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 689fd0d5f6c5..9abd65c694ab 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -949,6 +949,38 @@ bool drm_dp_downstream_444_to_420_conversion(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]
 }
 EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
 
+/**
+ * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream facing 
port
+ *   RGB->YCbCr conversion 
capability
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: downstream facing port capabilities
+ * @colorspc: Colorspace for which conversion cap is sought
+ *
+ * Returns: whether the downstream facing port can convert RGB->YCbCr for a 
given
+ * colorspace.
+ */
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
+  const u8 port_cap[4],
+  u8 color_spc)
+{
+   if (!drm_dp_is_branch(dpcd))
+   return false;
+
+   if (dpcd[DP_DPCD_REV] < 0x13)
+   return false;
+
+   switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
+   case DP_DS_PORT_TYPE_HDMI:
+   if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
+   return false;
+
+   return port_cap[3] & color_spc;
+   default:
+   return false;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
+
 /**
  * drm_dp_downstream_mode() - return a mode for downstream facing port
  * @dev: DRM device
@@ -3101,3 +3133,32 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux 
*aux, u8 pps_param[6])
return 0;
 }
 EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
+
+/*
+ * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to 
Ycbcr
+ * @aux: displayPort AUX channel
+ * @color_spc: Color-space/s for which conversion is to be enabled, 0 for 
disable.
+ *
+ * Returns 0 on success, else returns negative error code.
+ */
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+   if (ret < 0)
+   return ret;
+
+   if (color_spc & DP_CONVERSION_RGB_YCBCR_MASK)
+   buf |= (color_spc & DP_CONVERSION_RGB_YCBCR_MASK);
+   else
+   buf &= ~DP_CONVERSION_RGB_YCBCR_MASK;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index baad87fe6b0a..e096ee98842b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -432,6 +432,17 @@ struct drm_device;
 # define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
 # define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
 
+/*
+ * VESA DP-to-HDMI PCON Specification adds caps for colorspace
+ * conversion in DFP cap DPCD 83h. Sec6.1 Table-3.
+ * Based on the available support the source can enable
+ * color conversion by writing into PROTOCOL_COVERTER_CONTROL_2
+ * DPCD 3052h.
+ */
+# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
+# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
+# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV   (1 << 7)
+
 #define DP_MAX_DOWNSTREAM_PORTS0x10
 
 /* DP Forward error Correction Registers */
@@ -1207,7 +1218,10 @@ struct drm_device;
 # define DP_PCON_ENC_PPS_OVERRIDE_DISABLED  0
 # define DP_PCON_ENC_PPS_OVERRIDE_EN_PARAMS 1
 # define DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER 2
-
+# define DP_CONVERSION_RGB_YCBCR_MASK (7 << 4)
+# define DP_CONVERSION_BT601_RGB_YCBCR_ENABLE  (1 << 4)
+# define DP_CONVERSION_BT709_RGB_YCBCR_ENABLE  (1 << 5)
+# define DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE (1 << 6)
 
 /* PCON Downstream HDMI ERROR Status per Lane */
 #define DP_PCON_HDMI_ERROR_STATUS_LN0  0x3037
@@ -2167,5 +2181,8 

[Intel-gfx] [PATCH v5 05/15] drm/dp_helper: Add support for link failure detection

2020-12-15 Thread Ankit Nautiyal
From: Swati Sharma 

There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.

This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.

v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.

Signed-off-by: Swati Sharma 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_dp_helper.c | 39 +
 include/drm/drm_dp_helper.h | 17 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f501e3890921..a1d518b3a173 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2859,3 +2859,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, 
u8 *frl_trained_mask)
return mode;
 }
 EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+  struct drm_connector *connector)
+{
+   u8 buf, error_count;
+   int i, num_error;
+   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+   for (i = 0; i < hdmi->max_lanes; i++) {
+   if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i, 
) < 0)
+   return;
+
+   error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+   switch (error_count) {
+   case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+   num_error = 100;
+   break;
+   case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+   num_error = 10;
+   break;
+   case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+   num_error = 3;
+   break;
+   default:
+   num_error = 0;
+   }
+
+   DRM_ERROR("More than %d errors since the last read for lane 
%d", num_error, i);
+   }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c66f570eadc2..871e8c051642 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
 # define DP_CEC_IRQ  (1 << 2)
 
 #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
+# define RX_CAP_CHANGED  (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED   (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED   (1 << 4)
 
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
@@ -1120,6 +1125,16 @@ struct drm_device;
 #define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
 # define DP_CONVERSION_TO_YCBCR422_ENABLE  (1 << 0) /* DP 1.3 */
 
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0  0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1  0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2  0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3  0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS   (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
 /* HDCP 1.3 and HDCP 2.2 */
 #define DP_AUX_HDCP_BKSV   0x68000
 #define DP_AUX_HDCP_RI_PRIME   0x68005
@@ -2036,5 +2051,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
 
 bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
 int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
 
 #endif /* _DRM_DP_HELPER_H_ */
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 06/15] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon

2020-12-15 Thread Ankit Nautiyal
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.

v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.

v3: Only setting the DSC bits for the Protocol Convertor control
registers, avoiding overwritining color conversion bits.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/drm_dp_helper.c | 203 
 include/drm/drm_dp_helper.h | 114 ++
 2 files changed, 317 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a1d518b3a173..689fd0d5f6c5 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2898,3 +2898,206 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct 
drm_dp_aux *aux,
}
 }
 EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+   u8 major_v, minor_v;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+   major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+   minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+   if (major_v == 1 && minor_v == 2)
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 slice_cap1, slice_cap2;
+
+   slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 - 
DP_PCON_DSC_ENCODER];
+   slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 - 
DP_PCON_DSC_ENCODER];
+
+   if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+   return 24;
+   if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+   return 20;
+   if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+   return 16;
+   if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+   return 12;
+   if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+   return 10;
+   if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+   return 8;
+   if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+   return 6;
+   if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+   return 4;
+   if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+   return 2;
+   if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+   return 1;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+   return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC 
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+   switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+   case DP_PCON_DSC_ONE_16TH_BPP:
+   return 16;
+   case DP_PCON_DSC_ONE_8TH_BPP:
+   return 8;
+   case DP_PCON_DSC_ONE_4TH_BPP:
+   return 4;
+   case DP_PCON_DSC_ONE_HALF_BPP:
+   return 2;
+   case DP_PCON_DSC_ONE_BPP:
+   return 1;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+   if (ret < 0)
+   return ret;
+
+   buf |= DP_PCON_ENABLE_DSC_ENCODER;
+
+   if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+   buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+   buf |= pps_buf_config << 2;
+   }
+
+   

[Intel-gfx] [PATCH v5 04/15] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON

2020-12-15 Thread Ankit Nautiyal
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.

v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.

v3: Removed DPCD 0x3035 for MAX Sink FRL b/w as per new version of spec.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/drm_dp_helper.c | 263 
 include/drm/drm_dp_helper.h |  70 +
 2 files changed, 333 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..f501e3890921 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,266 @@ void drm_dp_vsc_sdp_log(const char *level, struct 
device *dev,
 #undef DP_SDP_LOG
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ */
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+  const u8 port_cap[4])
+{
+   int bw;
+   u8 buf;
+
+   buf = port_cap[2];
+   bw = buf & DP_PCON_MAX_FRL_BW;
+
+   switch (bw) {
+   case DP_PCON_MAX_9GBPS:
+   return 9;
+   case DP_PCON_MAX_18GBPS:
+   return 18;
+   case DP_PCON_MAX_24GBPS:
+   return 24;
+   case DP_PCON_MAX_32GBPS:
+   return 32;
+   case DP_PCON_MAX_40GBPS:
+   return 40;
+   case DP_PCON_MAX_48GBPS:
+   return 48;
+   case DP_PCON_MAX_0GBPS:
+   default:
+   return 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ */
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+   int ret;
+   u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+   if (enable_frl_ready_hpd)
+   buf |= DP_PCON_ENABLE_HPD_READY;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ */
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+   if (ret < 0)
+   return false;
+
+   if (buf & DP_PCON_FRL_READY)
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ */
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+   bool concurrent_mode)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+   if (ret < 0)
+   return ret;
+
+   if (concurrent_mode)
+   buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+   else
+   buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+   switch (max_frl_gbps) {
+   case 9:
+   buf |=  DP_PCON_ENABLE_MAX_BW_9GBPS;
+   break;
+   case 18:
+   buf |=  DP_PCON_ENABLE_MAX_BW_18GBPS;
+   break;
+   case 24:
+   buf |=  DP_PCON_ENABLE_MAX_BW_24GBPS;
+   break;
+   case 32:
+   buf |=  DP_PCON_ENABLE_MAX_BW_32GBPS;
+   break;
+   case 40:
+   buf |=  DP_PCON_ENABLE_MAX_BW_40GBPS;
+   break;
+   case 48:
+   buf |=  DP_PCON_ENABLE_MAX_BW_48GBPS;
+   break;
+   case 0:
+   buf |=  DP_PCON_ENABLE_MAX_BW_0GBPS;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
+
+/**
+ * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
+ * @aux: DisplayPort AUX channel
+ * @max_frl_mask : Max FRL BW to 

[Intel-gfx] [PATCH v5 03/15] drm/edid: Parse DSC1.2 cap fields from HFVSDB block

2020-12-15 Thread Ankit Nautiyal
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.

v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c  | 59 +
 include/drm/drm_connector.h | 43 +++
 2 files changed, 102 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e657c321d9e4..ca368df2e5ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4941,11 +4941,70 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
 
if (hf_vsdb[7]) {
u8 max_frl_rate;
+   u8 dsc_max_frl_rate;
+   u8 dsc_max_slices;
+   struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
 
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+   hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+   if (hdmi_dsc->v_1p2) {
+   hdmi_dsc->native_420 = hf_vsdb[11] & 
DRM_EDID_DSC_NATIVE_420;
+   hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+   if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+   hdmi_dsc->bpc_supported = 16;
+   else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+   hdmi_dsc->bpc_supported = 12;
+   else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+   hdmi_dsc->bpc_supported = 10;
+   else
+   hdmi_dsc->bpc_supported = 0;
+
+   dsc_max_frl_rate = (hf_vsdb[12] & 
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+   drm_get_max_frl_rate(dsc_max_frl_rate, 
_dsc->max_lanes,
+   _dsc->max_frl_rate_per_lane);
+   hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] & 
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+   dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+   switch (dsc_max_slices) {
+   case 1:
+   hdmi_dsc->max_slices = 1;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 2:
+   hdmi_dsc->max_slices = 2;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 3:
+   hdmi_dsc->max_slices = 4;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 4:
+   hdmi_dsc->max_slices = 8;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 5:
+   hdmi_dsc->max_slices = 8;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 6:
+   hdmi_dsc->max_slices = 12;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 7:
+   hdmi_dsc->max_slices = 16;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 0:
+   default:
+   hdmi_dsc->max_slices = 0;
+   hdmi_dsc->clk_per_slice = 0;
+   }
+   }
}
 
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1a3b4776b458..1922b278ffad 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
 };
 
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+   /** @v_1p2: flag for dsc1.2 version support by sink */
+   bool v_1p2;
+
+   /** @native_420: Does sink support DSC with 4:2:0 compression */
+   bool native_420;
+
+   /**
+* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+  

[Intel-gfx] [PATCH v5 01/15] drm/edid: Add additional HFVSDB fields for HDMI2.1

2020-12-15 Thread Ankit Nautiyal
From: Swati Sharma 

The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.

This patch adds the new HFVSDB fields that are required for
HDMI2.1.

v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)

Signed-off-by: Sharma, Swati2 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 include/drm/drm_edid.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e97daf6ffbb1..a158f585f658 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
 
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION   (1 << 0)
+#define DRM_EDID_ALLM  (1 << 1)
+#define DRM_EDID_FVA   (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420  (1 << 0)
+#define DRM_EDID_DC_36BIT_420  (1 << 1)
+#define DRM_EDID_DC_48BIT_420  (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK  0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP   (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2   (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 02/15] drm/edid: Parse MAX_FRL field from HFVSDB block

2020-12-15 Thread Ankit Nautiyal
From: Swati Sharma 

This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.

v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)

Signed-off-by: Sharma, Swati2 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c  | 44 +
 include/drm/drm_connector.h |  6 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..e657c321d9e4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4851,6 +4851,41 @@ static void drm_parse_vcdb(struct drm_connector 
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
 }
 
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8 
*max_rate_per_lane)
+{
+   switch (max_frl_rate) {
+   case 1:
+   *max_lanes = 3;
+   *max_rate_per_lane = 3;
+   break;
+   case 2:
+   *max_lanes = 3;
+   *max_rate_per_lane = 6;
+   break;
+   case 3:
+   *max_lanes = 4;
+   *max_rate_per_lane = 6;
+   break;
+   case 4:
+   *max_lanes = 4;
+   *max_rate_per_lane = 8;
+   break;
+   case 5:
+   *max_lanes = 4;
+   *max_rate_per_lane = 10;
+   break;
+   case 6:
+   *max_lanes = 4;
+   *max_rate_per_lane = 12;
+   break;
+   case 0:
+   default:
+   *max_lanes = 0;
+   *max_rate_per_lane = 0;
+   }
+}
+
 static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
   const u8 *db)
 {
@@ -4904,6 +4939,15 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
}
}
 
+   if (hf_vsdb[7]) {
+   u8 max_frl_rate;
+
+   DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+   max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+   drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+   >max_frl_rate_per_lane);
+   }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fcdc58d8b88b..1a3b4776b458 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
 
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+   /** @max_frl_rate_per_lane: support fixed rate link */
+   u8 max_frl_rate_per_lane;
+
+   /** @max_lanes: supported by sink */
+   u8 max_lanes;
 };
 
 /**
-- 
2.17.1

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


[Intel-gfx] [PATCH v5 00/15] Add support for DP-HDMI2.1 PCON

2020-12-15 Thread Ankit Nautiyal
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
The details are mentioned in:
VESA DP-to-HDMI PCON Specification Standalone Document
https://groups.vesa.org/wg/DP/document/15651

This series starts with adding support for FRL (Fixed Rate Link)
Training between the PCON and HDMI2.1 sink.
As per HDMI2.1 specification, a new data-channel or lane is added in
FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
lanes).

With these patches, the HDMI2.1 PCON can be configured to achieve FRL
training based on the maximum FRL rate supported by the panel, source
and the PCON.
The approach is to add the support for FRL training between PCON and
HDMI2.1 sink and gradually add other blocks for supporting higher
resolutions and other HDMI2.1 features, that can be supported by pcon
for the sources that do not natively support HDMI2.1.

This is done before the DP Link training between the source and PCON
is started. In case of FRL training is not achieved, the PCON will
work in the regular TMDS mode, without HDMI2.1 feature support.
Any interruption in FRL training between the PCON and HDMI2.1 sink is
notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
registers are read and FRL training is re-attempted.

Currently, we have tested the FRL training and are able to enable 4K
display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
panel.

v2: Addressed review comments and re-organized patches as suggested in
comments on RFC patches.

v3: Addressed review comments on previous version.

v4: Added support for RGB->YCBCR conversion through PCON

v5: Addressed review comments on previous version.

Ankit Nautiyal (11):
  drm/edid: Parse DSC1.2 cap fields from HFVSDB block
  drm/dp_helper: Add Helpers for FRL Link Training support for
DP-HDMI2.1 PCON
  drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
  drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
  drm/i915: Capture max frl rate for PCON in dfp cap structure
  drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
  drm/i915: Check for FRL training before DP Link training
  drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
  drm/i915: Add helper functions for calculating DSC parameters for
HDMI2.1
  drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
  drm/i915/display: Let PCON convert from RGB to YUV if it can

Swati Sharma (4):
  drm/edid: Add additional HFVSDB fields for HDMI2.1
  drm/edid: Parse MAX_FRL field from HFVSDB block
  drm/dp_helper: Add support for link failure detection
  drm/i915: Add support for enabling link status and recovery

 drivers/gpu/drm/drm_dp_helper.c   | 566 ++
 drivers/gpu/drm/drm_edid.c| 103 
 drivers/gpu/drm/i915/display/intel_ddi.c  |   6 +-
 .../drm/i915/display/intel_display_types.h|  10 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 438 +-
 drivers/gpu/drm/i915/display/intel_dp.h   |   7 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 233 +++
 drivers/gpu/drm/i915/display/intel_hdmi.h |   7 +
 include/drm/drm_connector.h   |  49 ++
 include/drm/drm_dp_helper.h   | 218 +++
 include/drm/drm_edid.h|  30 +
 11 files changed, 1645 insertions(+), 22 deletions(-)

-- 
2.17.1

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix mismatch between misplaced vma check and vma insert

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

Series: drm/i915: Fix mismatch between misplaced vma check and vma insert
URL   : https://patchwork.freedesktop.org/series/84975/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9489_full -> Patchwork_19150_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@contexts@rcs0:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl5/igt@gem_exec_parallel@conte...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl3/igt@gem_exec_parallel@conte...@rcs0.html

  * igt@gem_exec_params@larger-than-life-batch:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb3/igt@gem_exec_par...@larger-than-life-batch.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb3/igt@gem_exec_par...@larger-than-life-batch.html
- shard-tglb: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb6/igt@gem_exec_par...@larger-than-life-batch.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-tglb1/igt@gem_exec_par...@larger-than-life-batch.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][9] ([i915#2658])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@gem_render_c...@linear-to-vebox-y-tiled.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#146] / 
[i915#198])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@i915_susp...@fence-restore-tiled2untiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-glk:  NOTRUN -> [SKIP][13] ([fdo#109271]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk5/igt@kms_big...@x-tiled-32bpp-rotate-90.html

  * igt@kms_color@pipe-b-ctm-0-25:
- shard-skl:  [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl3/igt@kms_co...@pipe-b-ctm-0-25.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl3/igt@kms_co...@pipe-b-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-a-ctm-red-to-blue:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@kms_color_chamel...@pipe-a-ctm-red-to-blue.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([i915#2405] / 
[i915#300])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x128-offscreen:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#54])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-128x128-offscreen.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-128x128-offscreen.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#79]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
 

Re: [Intel-gfx] [RFC-v4 01/21] drm/i915/pxp: Introduce Intel PXP component

2020-12-15 Thread Huang, Sean Z
Hello Wilson,

Appreciate your code review feedback and apologize for the late replying.
I have made those modification as below and the change will reflect in the next 
version. (v10)

Best regards,
Sean



1.
> So this is dead code then?
> If the recommendation is not to enable it, and you don't even add it to CI 
> for testing, what's it for?
Yes, I have changed it to default.

2.
> Mesa is but one user; the first but not last.
DONE

3.
> Just call it.
DONE

4.
> Not an error; the system can survive without, and userspace can detect the 
> feature.
DONE

5.
> How often have we used uninit?
I expected uninit is called only when power of or i915 off, very rare chance.

6.
> Only include the types from a types.h
Got it, added intel_pxp_types.h accordingly

7.
> You are not inside gt/, wise not to bake in such embedded assumptions.
> i.e. all the container_of(pxp)>i915>pxp will be far less fragile with a 
> pxp->global = >i915->pxp.
I see, so container_of() isn't preferred, may I know if it's okay to keep the 
pointer of gt in the pxp init call, so later I can use pxp->gt->i915?

8.
> Reconsider; this should only be at most once per device.
It is called only for pxp init during the boot time. so hopefully I can still 
keep this log, but please let me know if you still suggest to remove it, thanks!

9.
> System includes first.
DONE

10.
> As already stated, this randomisation does not add any security; and does not 
> mean you can safely have multiple contexts without collision.
> What you had in mind was an ida.
Got it, I have removed the ctx.id, instead I just need ctx.inited bool


-Original Message-
From: Chris Wilson  
Sent: Thursday, December 10, 2020 12:41 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v4 01/21] drm/i915/pxp: Introduce Intel PXP 
component

Quoting Huang, Sean Z (2020-12-10 07:24:15)
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+, 
> that helps to establish the hardware protected session and manage the 
> status of the alive software session, as well as its life cycle.
> 
> This patch series is to allow the kernel space to create and manage a 
> single hardware session (a.k.a default session or arbitrary session). 
> So Mesa can allocate the protected buffer, which is encrypted with the 
> leverage of the arbitrary hardware session.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Kconfig | 19 +
>  drivers/gpu/drm/i915/Makefile|  5 
>  drivers/gpu/drm/i915/gt/intel_gt.c   |  7 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 27 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.h | 29 
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.c | 27 ++  
> drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 22 +++
>  8 files changed, 139 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig 
> b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..a42b9b031455 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,25 @@ config DRM_I915_GVT_KVMGT
>   Choose this option if you want to enable KVMGT support for
>   Intel GVT-g.
>  
> +config DRM_I915_PXP
> +   bool "Enable Intel PXP support for Intel Gen12+ platform"
> +   depends on DRM_I915
> +   select INTEL_MEI_PXP

Doesn't exist.

Kconfig dependency resolution is not recursive; you probably will need a 
depends on INTEL_MEI

> +   default n

So this is dead code then?
If the recommendation is not to enable it, and you don't even add it to CI for 
testing, what's it for?

> +   help
> + This option selects INTEL_MEI_ME if it isn't already selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> + that helps to establish the hardware protected session and manage
> + the status of the alive software session, as well as its life cycle.
> +
> + This patch series is to allow the kernel space to create and
> + manage a single hardware session (a.k.a default session or
> + arbitrary session). So Mesa can allocate the protected buffer,
> + which is encrypted with the leverage of the arbitrary hardware
> + session.

Mesa is but one user; the first but not last.

> +
>  menu "drm/i915 Debugging"
>  depends on DRM_I915
>  depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/Makefile 
> b/drivers/gpu/drm/i915/Makefile index e5574e506a5c..99efac469cc2 
> 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Track the overall awake/busy time

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

Series: drm/i915/gt: Track the overall awake/busy time
URL   : https://patchwork.freedesktop.org/series/84964/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9488_full -> Patchwork_19148_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@perf_pmu@other-init-4:
- shard-apl:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-apl3/igt@perf_...@other-init-4.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-apl7/igt@perf_...@other-init-4.html
- shard-tglb: [PASS][3] -> [FAIL][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-tglb8/igt@perf_...@other-init-4.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-tglb8/igt@perf_...@other-init-4.html
- shard-glk:  [PASS][5] -> [FAIL][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-glk1/igt@perf_...@other-init-4.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-glk8/igt@perf_...@other-init-4.html
- shard-skl:  [PASS][7] -> [FAIL][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-skl7/igt@perf_...@other-init-4.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-skl8/igt@perf_...@other-init-4.html
- shard-hsw:  [PASS][9] -> [FAIL][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-hsw6/igt@perf_...@other-init-4.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-hsw2/igt@perf_...@other-init-4.html
- shard-kbl:  [PASS][11] -> [FAIL][12] +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-kbl6/igt@perf_...@other-init-4.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-kbl6/igt@perf_...@other-init-4.html

  * igt@perf_pmu@other-read-4:
- shard-snb:  [PASS][13] -> [FAIL][14] +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-snb6/igt@perf_...@other-read-4.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-snb6/igt@perf_...@other-read-4.html
- shard-iclb: [PASS][15] -> [FAIL][16] +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-iclb1/igt@perf_...@other-read-4.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-iclb1/igt@perf_...@other-read-4.html

  
 Warnings 

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl:  [INCOMPLETE][17] ([i915#794]) -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-kbl3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-kbl7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html

  
 Suppressed 

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

  * {igt@gem_exec_balancer@fairslice}:
- shard-iclb: [PASS][19] -> [FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-iclb7/igt@gem_exec_balan...@fairslice.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-iclb1/igt@gem_exec_balan...@fairslice.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hang:
- shard-hsw:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#1099])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-hsw8/igt@gem_ctx_persiste...@legacy-engines-hang.html

  * igt@gem_exec_whisper@basic-fds-priority-all:
- shard-glk:  [PASS][22] -> [DMESG-WARN][23] ([i915#118] / 
[i915#95]) +1 similar issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-glk3/igt@gem_exec_whis...@basic-fds-priority-all.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/shard-glk6/igt@gem_exec_whis...@basic-fds-priority-all.html

  * igt@gem_userptr_blits@readonly-mmap-unsync@wb:
- shard-iclb: NOTRUN -> [SKIP][24] ([i915#1704]) +3 similar issues
   [24]: 

Re: [Intel-gfx] [PATCH 14/65] drm/rcar-du: Annotate dma-fence critical section in commit path

2020-12-15 Thread Laurent Pinchart
Hi Daniel,

Thank you for the patch.

On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote:
> Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> nothing fancy going on here.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: linux-renesas-...@vger.kernel.org

I'm lacking context here, there's only one instance of a call to
dma_fence_begin_signalling() in the subsystem, and no cover letter in
the series to explain what's going on. Some information would help
reviewing the patch :-)

Also, could you mention in the cover letter for the next version if you
will merge the whole series, or expect individual maintainers to pick up
the relevant patches ?

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 72dda446355f..8d91140151cc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -441,6 +441,7 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
>   unsigned int i;
> + bool fence_cookie = dma_fence_begin_signalling();
>  
>   /*
>* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured
> @@ -467,6 +468,7 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
>  
>   drm_atomic_helper_commit_hw_done(old_state);
> + dma_fence_end_signalling(fence_cookie);
>   drm_atomic_helper_wait_for_flip_done(dev, old_state);
>  
>   drm_atomic_helper_cleanup_planes(dev, old_state);

-- 
Regards,

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2)

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

Series: drm/i915/display: Prevent double YUV range correction on HDR planes 
(rev2)
URL   : https://patchwork.freedesktop.org/series/84966/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19152


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +30 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][3] ([fdo#109271]) +21 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  * igt@prime_vgem@basic-write:
- fi-tgl-y:   [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_v...@basic-write.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-tgl-y/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[DMESG-WARN][6] -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [INCOMPLETE][8] ([i915#2377]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

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


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9489 -> Patchwork_19152

  CI-20190529: 20190529
  CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19152: c3629bb8e645760ce4d1e6bae19781c24d4cefe8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c3629bb8e645 drm/i915/display: Prevent double YUV range correction on HDR planes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/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: Fix mismatch between misplaced vma check and vma insert

2020-12-15 Thread Tang, CQ



> -Original Message-
> From: Chris Wilson 
> Sent: Tuesday, December 15, 2020 2:02 PM
> To: Tang, CQ ; intel-gfx@lists.freedesktop.org
> Cc: stable@ 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
> 
> Quoting Tang, CQ (2020-12-15 21:50:53)
> >
> >
> > > -Original Message-
> > > From: Chris Wilson 
> > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson ; Tang, CQ
> > > ; sta...@vger.kernel.org
> > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > and vma insert
> > >
> > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > the caller opts into using the full range. This was done to allow
> > > usersapce the opportunity to transition slowly from a 32b address
> > > space, and to avoid breaking inherent 32b assumptions of some
> commands.
> > >
> > > However, for insert we limited ourselves to 4G-4K, but on
> > > verification we allowed the full 4G. This causes some attempts to
> > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> bound successfully.
> > >
> > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page") suggests that there is a genuine problem with stateless
> > > addressing that cannot utilize the last page in 4G and so we purposefully
> excluded it.
> > >
> > > Reported-by: CQ Tang 
> > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page")
> > > Signed-off-by: Chris Wilson 
> > > Cc: CQ Tang 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 193996144c84..2ff32daa50bd 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > drm_i915_gem_exec_object2 *entry,
> > >   return true;
> > >
> > >   if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > + (vma->node.start + vma->node.size + 4095) >> 32)
> >
> > Why 4095 not 4096?
> 
> It's the nature of the test that we need an inclusive bound.
> 
> Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> 
>   4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> 
>   4G - 4k + 4k - 1 = 4G -1 = 0x => vma ok

How do we trigger this code?  I run gem_exec_params@larger-than-life-batch but 
did not see this code is executed.
Basically how do we triggre first attempt to pin the object in place.

--CQ

> 
> -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 drm/i915/display: Prevent double YUV range correction on HDR planes (rev2)

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

Series: drm/i915/display: Prevent double YUV range correction on HDR planes 
(rev2)
URL   : https://patchwork.freedesktop.org/series/84966/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c3629bb8e645 drm/i915/display: Prevent double YUV range correction on HDR planes
-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#24: 
[1] 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281

total: 0 errors, 1 warnings, 0 checks, 97 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 series starting with [1/2] i915/perf: Move gen specific OA formats to single array

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

Series: series starting with [1/2] i915/perf: Move gen specific OA formats to 
single array
URL   : https://patchwork.freedesktop.org/series/84978/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19151


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-apl-guc/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y:   [PASS][2] -> [DMESG-FAIL][3] ([i915#2601] / 
[i915#541])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +30 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  * igt@prime_vgem@basic-write:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_v...@basic-write.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-tgl-y/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[DMESG-WARN][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [INCOMPLETE][11] ([i915#2750]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [INCOMPLETE][13] ([i915#2377]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377
  [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601
  [i915#2750]: https://gitlab.freedesktop.org/drm/intel/issues/2750
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9489 -> Patchwork_19151

  CI-20190529: 20190529
  CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19151: 4db0badf5a249da08dd4a6635c22eaef89b407f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4db0badf5a24 i915/perf: Add removed OA formats back for TGL
60f0353cf872 i915/perf: Move gen specific OA formats to single array

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19151/index.html

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] i915/perf: Move gen specific OA formats to single array

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

Series: series starting with [1/2] i915/perf: Move gen specific OA formats to 
single array
URL   : https://patchwork.freedesktop.org/series/84978/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
60f0353cf872 i915/perf: Move gen specific OA formats to single array
-:63: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#63: FILE: drivers/gpu/drm/i915/i915_perf.c:321:
+   [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },

total: 0 errors, 1 warnings, 0 checks, 120 lines checked
4db0badf5a24 i915/perf: Add removed OA formats back for TGL
-:30: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#30: FILE: drivers/gpu/drm/i915/i915_perf.c:317:
+   [I915_OA_FORMAT_A12]= { 0, 64, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },

-:31: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#31: FILE: drivers/gpu/drm/i915/i915_perf.c:318:
+   [I915_OA_FORMAT_A12_B8_C8]  = { 2, 128, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },

total: 0 errors, 2 warnings, 0 checks, 53 lines checked


___
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/4] dma-buf: Remove kmap kerneldoc vestiges (rev3)

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

Series: series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges 
(rev3)
URL   : https://patchwork.freedesktop.org/series/84849/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9488_full -> Patchwork_19147_full


Summary
---

  **WARNING**

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

  

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-kbl:  [INCOMPLETE][1] ([i915#794]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-kbl3/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-kbl7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hang:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-hsw6/igt@gem_ctx_persiste...@legacy-engines-hang.html

  * igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][4] ([i915#2389])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb4/igt@gem_exec_reloc@basic-many-act...@vcs1.html

  * igt@gem_userptr_blits@readonly-mmap-unsync@wb:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#1704]) +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@gem_userptr_blits@readonly-mmap-uns...@wb.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-glk:  NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-glk7/igt@gen7_exec_pa...@basic-allocation.html
- shard-iclb: NOTRUN -> [SKIP][7] ([fdo#109289])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@gen7_exec_pa...@basic-allocation.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#2411] / 
[i915#456] / [i915#750])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-tglb6/igt@i915_pm_...@system-suspend-execbuf.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-tglb8/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_big_fb@yf-tiled-8bpp-rotate-0:
- shard-iclb: NOTRUN -> [SKIP][10] ([fdo#110723])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@kms_big...@yf-tiled-8bpp-rotate-0.html

  * igt@kms_ccs@pipe-d-ccs-on-another-bo:
- shard-iclb: NOTRUN -> [SKIP][11] ([fdo#109278]) +4 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@kms_...@pipe-d-ccs-on-another-bo.html

  * igt@kms_chamelium@dp-crc-single:
- shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109284] / [fdo#111827]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@kms_chamel...@dp-crc-single.html

  * igt@kms_chamelium@hdmi-hpd:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-skl6/igt@kms_chamel...@hdmi-hpd.html

  * igt@kms_chamelium@hdmi-hpd-after-suspend:
- shard-hsw:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +4 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-hsw6/igt@kms_chamel...@hdmi-hpd-after-suspend.html

  * igt@kms_color@pipe-a-ctm-0-5:
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-skl3/igt@kms_co...@pipe-a-ctm-0-5.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-skl7/igt@kms_co...@pipe-a-ctm-0-5.html

  * igt@kms_color_chamelium@pipe-d-ctm-green-to-red:
- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-glk7/igt@kms_color_chamel...@pipe-d-ctm-green-to-red.html
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [fdo#109284] / 
[fdo#111827])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/shard-iclb5/igt@kms_color_chamel...@pipe-d-ctm-green-to-red.html

  * 

Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes

2020-12-15 Thread Andres Calderon Jaramillo
On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä
 wrote:
>
> On Mon, Dec 14, 2020 at 10:57:03PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: andrescj via sendgmr 
> > > 
> > > On Behalf Of Andres Calderon Jaramillo
> > > Sent: Tuesday, December 15, 2020 3:50 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Shankar, Uma ; Venkatesh Reddy, Sushma
> > > ; seanp...@chromium.org; Andres
> > > Calderon Jaramillo 
> > > Subject: [PATCH] drm/i915/display: Prevent double YUV range correction on 
> > > HDR
> > > planes
> > >
> > > From: Andres Calderon Jaramillo 
> > >
> > > Prevent the ICL HDR plane pipeline from performing YUV color range 
> > > correction
> > > twice when the input is in limited range.
> > >
> > > Before this patch the following could happen: user space gives us a YUV 
> > > buffer in
> > > limited range; per the pipeline in [1], the plane would first go through 
> > > a "YUV
> > > Range correct" stage that expands the range; the plane would then go 
> > > through
> > > the "Input CSC" stage which would also expand the range because
> > > icl_program_input_csc() would use a matrix and an offset that assume 
> > > limited-
> > > range input; this would ultimately cause dark and light colors to appear 
> > > darker
> > > and lighter than they should respectively.
> > >
> > > This is an issue because if a buffer switches between being scanned out 
> > > and
> > > being composited with the GPU, the user will see a color difference.
> > > If this switching happens quickly and frequently, the user will perceive 
> > > this as a
> > > flickering.
> > >
> > > [1] 
> > > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-
> > > vol12-displayengine_0.pdf#page=281
> >
> > Change looks good to me, double conversion should not be done.
> > Plane input csc coefficients take care of the limited range.
>
> Might make sense to actually use the hw range correction instead.
> Would avoid having to keep around two sets of coefficients.
>
> Also the question now becomes: How can our tests be passing if
> we're doing the range correction twice?
>

I also considered just removing the limited-range matrix/offsets from
icl_program_input_csc(). However, I figured that since the "Input CSC"
stage must happen regardless of range correction, maybe it would be a
gain to disable the "YUV Range Correction" stage. However, I'm not
familiar with the hardware details, so I don't know for sure. I don't
feel strongly either way; let me know what you'd prefer.

I'm also curious about the testing. How do the tests work? I assume
they are in Intel's CI and not open sourced? Do they use the DRM
writeback connector (I didn't think this was implemented for i915
yet)?

> >
> > Reviewed-by: Uma Shankar 
> >
> > > Signed-off-by: Andres Calderon Jaramillo 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 761be8deaa9b..aeea344b06ad 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -4811,6 +4811,13 @@ u32 glk_plane_color_ctl(const struct 
> > > intel_crtc_state
> > > *crtc_state,
> > > plane_color_ctl |=
> > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > } else if (fb->format->is_yuv) {
> > > plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > > +
> > > +   /*
> > > +* Disable the YUV range correction stage because the input 
> > > CSC
> > > +* stage already takes care of range conversion by using 
> > > separate
> > > +* matrices and offsets depending on the color range.
> > > +*/
> > > +   plane_color_ctl |=
> > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > }
> > >
> > > return plane_color_ctl;
> > > --
> > > 2.29.2.684.gfbc64c5ab5-goog
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix mismatch between misplaced vma check and vma insert

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

Series: drm/i915: Fix mismatch between misplaced vma check and vma insert
URL   : https://patchwork.freedesktop.org/series/84975/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19150


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-apl-guc/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-snb-2600:[PASS][2] -> [DMESG-WARN][3] ([i915#2772])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_susp...@basic-s0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-snb-2600/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload:
- fi-kbl-7500u:   [PASS][4] -> [DMESG-WARN][5] ([i915#2605])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-kbl-7500u/igt@i915_module_l...@reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-kbl-7500u/igt@i915_module_l...@reload.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#2029] / [i915#2722])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-bdw-5557u/igt@run...@aborted.html

  * igt@vgem_basic@create:
- fi-tgl-y:   [PASS][8] -> [DMESG-WARN][9] ([i915#402]) +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@vgem_ba...@create.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-tgl-y/igt@vgem_ba...@create.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [INCOMPLETE][10] ([i915#2750]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [INCOMPLETE][12] ([i915#2377]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-glk-dsi/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][14] ([i915#402]) -> [PASS][15] +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2750]: https://gitlab.freedesktop.org/drm/intel/issues/2750
  [i915#2772]: https://gitlab.freedesktop.org/drm/intel/issues/2772
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9489 -> Patchwork_19150

  CI-20190529: 20190529
  CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19150: 0077303b2c4369d3cf3565ee1b3b7c5f3890d209 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0077303b2c43 drm/i915: Fix mismatch between misplaced vma check and vma insert

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Drop free_work for GEM contexts (rev3)

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

Series: drm/i915/gem: Drop free_work for GEM contexts (rev3)
URL   : https://patchwork.freedesktop.org/series/83537/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9488_full -> Patchwork_19146_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-d-wait-forked-hang:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-tglb3/igt@kms_vbl...@pipe-d-wait-forked-hang.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-tglb8/igt@kms_vbl...@pipe-d-wait-forked-hang.html

  
 Suppressed 

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

  * {igt@perf@non-zero-reason}:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-iclb2/igt@p...@non-zero-reason.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-iclb5/igt@p...@non-zero-reason.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hang:
- shard-hsw:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-hsw4/igt@gem_ctx_persiste...@legacy-engines-hang.html

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  [PASS][6] -> [INCOMPLETE][7] ([i915#2295] / 
[i915#2369])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-skl6/igt@gem_exec_capture@p...@vcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-skl10/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2389])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-iclb4/igt@gem_exec_reloc@basic-many-act...@vcs1.html

  * igt@gem_sync@basic-store-all:
- shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#262])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-iclb4/igt@gem_s...@basic-store-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-iclb2/igt@gem_s...@basic-store-all.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / 
[i915#716])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-glk8/igt@gen9_exec_pa...@allowed-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-glk4/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-kbl1/igt@i915_susp...@sysfs-reader.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-kbl1/igt@i915_susp...@sysfs-reader.html

  * igt@kms_chamelium@hdmi-hpd:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-skl1/igt@kms_chamel...@hdmi-hpd.html

  * igt@kms_chamelium@hdmi-hpd-after-suspend:
- shard-hsw:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +4 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-hsw4/igt@kms_chamel...@hdmi-hpd-after-suspend.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#54]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#2346])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-tglb: [PASS][21] -> [FAIL][22] 

Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert

2020-12-15 Thread Tang, CQ



> -Original Message-
> From: Chris Wilson 
> Sent: Tuesday, December 15, 2020 2:02 PM
> To: Tang, CQ ; intel-gfx@lists.freedesktop.org
> Cc: stable@ 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
> 
> Quoting Tang, CQ (2020-12-15 21:50:53)
> >
> >
> > > -Original Message-
> > > From: Chris Wilson 
> > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson ; Tang, CQ
> > > ; sta...@vger.kernel.org
> > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > and vma insert
> > >
> > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > the caller opts into using the full range. This was done to allow
> > > usersapce the opportunity to transition slowly from a 32b address
> > > space, and to avoid breaking inherent 32b assumptions of some
> commands.
> > >
> > > However, for insert we limited ourselves to 4G-4K, but on
> > > verification we allowed the full 4G. This causes some attempts to
> > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> bound successfully.
> > >
> > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page") suggests that there is a genuine problem with stateless
> > > addressing that cannot utilize the last page in 4G and so we purposefully
> excluded it.
> > >
> > > Reported-by: CQ Tang 
> > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page")
> > > Signed-off-by: Chris Wilson 
> > > Cc: CQ Tang 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 193996144c84..2ff32daa50bd 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > drm_i915_gem_exec_object2 *entry,
> > >   return true;
> > >
> > >   if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > + (vma->node.start + vma->node.size + 4095) >> 32)
> >
> > Why 4095 not 4096?
> 
> It's the nature of the test that we need an inclusive bound.
> 
> Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> 
>   4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> 
>   4G - 4k + 4k - 1 = 4G -1 = 0x => vma ok

Yes, the checking in i915_vma_insert() is ">" not ">="
if (size > end) {
DRM_DEBUG("Attempting to bind an object larger than the 
aperture: request=%llu > %s aperture=%llu\n",
  size, flags & PIN_MAPPABLE ? "mappable" : "total",
  end);
return -ENOSPC;
}

Reviewed-by: CQ Tang 


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


Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert

2020-12-15 Thread Chris Wilson
Quoting Tang, CQ (2020-12-15 21:50:53)
> 
> 
> > -Original Message-
> > From: Chris Wilson 
> > Sent: Tuesday, December 15, 2020 12:31 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Tang, CQ ;
> > sta...@vger.kernel.org
> > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check and
> > vma insert
> > 
> > When inserting a VMA, we restrict the placement to the low 4G unless the
> > caller opts into using the full range. This was done to allow usersapce the
> > opportunity to transition slowly from a 32b address space, and to avoid
> > breaking inherent 32b assumptions of some commands.
> > 
> > However, for insert we limited ourselves to 4G-4K, but on verification we
> > allowed the full 4G. This causes some attempts to bind a new buffer to
> > sporadically fail with -ENOSPC, but at other times be bound successfully.
> > 
> > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > page") suggests that there is a genuine problem with stateless addressing
> > that cannot utilize the last page in 4G and so we purposefully excluded it.
> > 
> > Reported-by: CQ Tang 
> > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > page")
> > Signed-off-by: Chris Wilson 
> > Cc: CQ Tang 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 193996144c84..2ff32daa50bd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > drm_i915_gem_exec_object2 *entry,
> >   return true;
> > 
> >   if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > - (vma->node.start + vma->node.size - 1) >> 32)
> > + (vma->node.start + vma->node.size + 4095) >> 32)
> 
> Why 4095 not 4096?

It's the nature of the test that we need an inclusive bound.

Consider an object of size 4G - 4K, that is allowed to fit within our 32b
GTT.

4G - 4k + 4K = 4G == 1 << 32: => vma misplaced

4G - 4k + 4k - 1 = 4G -1 = 0x => vma ok

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Provide a utility to create a scratch buffer

2020-12-15 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2020-12-15 21:51:13)
> 
> 
> On 12/14/2020 6:15 PM, Chris Wilson wrote:
> > Primarily used by selftests, but also by runtime debugging of engine
> > w/a, is a routine to create a temporarily bound buffer for readback.
> > Almagamate the duplicated routines into one.
> >
> > Suggested-by: Daniele Ceraolo Spurio 
> > Signed-off-by: Chris Wilson 
> > ---
> >   .../drm/i915/gem/selftests/igt_gem_utils.h|  1 +
> >   drivers/gpu/drm/i915/gt/intel_gtt.c   | 29 +++
> >   drivers/gpu/drm/i915/gt/intel_gtt.h   |  3 ++
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 36 ++-
> >   drivers/gpu/drm/i915/gt/selftest_execlists.c  | 29 +--
> >   drivers/gpu/drm/i915/gt/selftest_lrc.c| 24 +
> >   drivers/gpu/drm/i915/gt/selftest_mocs.c   | 29 +--
> >   .../gpu/drm/i915/gt/selftest_workarounds.c|  6 ++--
> >   8 files changed, 41 insertions(+), 116 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h 
> > b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
> > index 4221cf84d175..13b241581dbb 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
> > +++ b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
> > @@ -9,6 +9,7 @@
> >   
> >   #include 
> >   
> > +struct i915_address_space;
> 
> This doesn't seem to be required in this header.

Can you guess where I first put a igt_create_scratch?

> 
> >   struct i915_request;
> >   struct i915_gem_context;
> >   struct i915_vma;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > index 7bfe9072be9a..fbe6c0c5a060 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > @@ -422,6 +422,35 @@ void setup_private_pat(struct intel_uncore *uncore)
> >   bdw_setup_private_ppat(uncore);
> >   }
> >   
> > +struct i915_vma *
> > +__vm_create_scratch(struct i915_address_space *vm, unsigned long size)
> > +{
> > + struct drm_i915_gem_object *obj;
> > + struct i915_vma *vma;
> > + int err;
> > +
> > + obj = i915_gem_object_create_internal(vm->i915, PAGE_ALIGN(size));
> > + if (IS_ERR(obj))
> > + return ERR_CAST(obj);
> > +
> > + i915_gem_object_set_cache_coherency(obj, I915_CACHING_CACHED);
> > +
> > + vma = i915_vma_instance(obj, vm, NULL);
> > + if (IS_ERR(vma)) {
> > + i915_gem_object_put(obj);
> > + return vma;
> > + }
> > +
> > + err = i915_vma_pin(vma, 0, 0,
> > +i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
> > + if (err) {
> > + i915_gem_object_put(obj);
> > + return ERR_PTR(err);
> > + }
> > +
> > + return vma;
> > +}
> > +
> >   #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> >   #include "selftests/mock_gtt.c"
> >   #endif
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
> > b/drivers/gpu/drm/i915/gt/intel_gtt.h
> > index 8a33940a71f3..1cff86073af8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> > @@ -573,6 +573,9 @@ int i915_vm_pin_pt_stash(struct i915_address_space *vm,
> >   void i915_vm_free_pt_stash(struct i915_address_space *vm,
> >  struct i915_vm_pt_stash *stash);
> >   
> > +struct i915_vma *
> > +__vm_create_scratch(struct i915_address_space *vm, unsigned long size);
> > +
> >   static inline struct sgt_dma {
> >   struct scatterlist *sg;
> >   dma_addr_t dma, max;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 52f12a6d66b9..be5b090ae6ae 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -2085,39 +2085,6 @@ void intel_engine_apply_workarounds(struct 
> > intel_engine_cs *engine)
> >   wa_list_apply(engine->uncore, >wa_list);
> >   }
> >   
> > -static struct i915_vma *
> > -create_scratch(struct i915_address_space *vm, int count)
> > -{
> > - struct drm_i915_gem_object *obj;
> > - struct i915_vma *vma;
> > - unsigned int size;
> > - int err;
> > -
> > - size = round_up(count * sizeof(u32), PAGE_SIZE);
> > - obj = i915_gem_object_create_internal(vm->i915, size);
> > - if (IS_ERR(obj))
> > - return ERR_CAST(obj);
> > -
> > - i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
> > -
> > - vma = i915_vma_instance(obj, vm, NULL);
> > - if (IS_ERR(vma)) {
> > - err = PTR_ERR(vma);
> > - goto err_obj;
> > - }
> > -
> > - err = i915_vma_pin(vma, 0, 0,
> > -i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
> > - if (err)
> > - goto err_obj;
> > -
> > - return vma;
> > -
> > -err_obj:
> > - i915_gem_object_put(obj);
> > - return ERR_PTR(err);
> > -}
> > -
> >   struct mcr_range {
> >   

[Intel-gfx] [PATCH i-g-t v2] i915/gem_softpin: Check full placement control under full-ppgtt

2020-12-15 Thread Chris Wilson
With full-ppgtt, userspace has complete control over their GTT. Verify
that we can place an object at the very beginning and the very end of
our GTT.

Signed-off-by: Chris Wilson 
---
 tests/i915/gem_softpin.c | 63 
 1 file changed, 63 insertions(+)

diff --git a/tests/i915/gem_softpin.c b/tests/i915/gem_softpin.c
index fcaf8ef30..a3e6dcac3 100644
--- a/tests/i915/gem_softpin.c
+++ b/tests/i915/gem_softpin.c
@@ -97,6 +97,65 @@ static void test_invalid(int fd)
}
 }
 
+static uint32_t batch_create(int i915, uint64_t *sz)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   struct drm_i915_gem_create create = {
+   .size = sizeof(bbe),
+   };
+
+   if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CREATE, )) {
+   igt_assert_eq(errno, 0);
+   return 0;
+   }
+
+   gem_write(i915, create.handle, 0, , sizeof(bbe));
+
+   *sz = create.size;
+   return create.handle;
+}
+
+static void test_zero(int i915)
+{
+   uint64_t sz, gtt = gem_aperture_size(i915);
+   struct drm_i915_gem_exec_object2 object = {
+   .handle = batch_create(i915, ),
+   .flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   };
+
+   /* Under full-ppgtt, we have complete control of the GTT */
+   igt_info("Object size:%"PRIx64", GTT size:%"PRIx64"\n", sz, gtt);
+
+   object.offset = 0;
+   igt_assert_f(__gem_execbuf(i915, ) == 0,
+"execbuff failed with object.offset=%llx\n",
+object.offset);
+
+   if (gtt >> 32) {
+   object.offset = (1ull << 32) - sz;
+   igt_assert_f(__gem_execbuf(i915, ) == 0,
+"execbuff failed with object.offset=%llx\n",
+object.offset);
+
+   object.offset = 1ull << 32;
+   igt_assert_f(__gem_execbuf(i915, ) == 0,
+"execbuff failed with object.offset=%llx\n",
+object.offset);
+   }
+
+   object.offset = gtt - sz;
+   object.offset = gen8_canonical_addr(object.offset);
+   igt_assert_f(__gem_execbuf(i915, ) == 0,
+"execbuff failed with object.offset=%llx\n",
+object.offset);
+
+   gem_close(i915, object.handle);
+}
+
 static void test_softpin(int fd)
 {
const uint32_t size = 1024 * 1024;
@@ -559,6 +618,10 @@ igt_main
 
igt_subtest("invalid")
test_invalid(fd);
+   igt_subtest("zero") {
+   igt_require(gem_uses_full_ppgtt(fd));
+   test_zero(fd);
+   }
igt_subtest("softpin")
test_softpin(fd);
igt_subtest("overlap")
-- 
2.29.2

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Provide a utility to create a scratch buffer

2020-12-15 Thread Daniele Ceraolo Spurio




On 12/14/2020 6:15 PM, Chris Wilson wrote:

Primarily used by selftests, but also by runtime debugging of engine
w/a, is a routine to create a temporarily bound buffer for readback.
Almagamate the duplicated routines into one.

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
---
  .../drm/i915/gem/selftests/igt_gem_utils.h|  1 +
  drivers/gpu/drm/i915/gt/intel_gtt.c   | 29 +++
  drivers/gpu/drm/i915/gt/intel_gtt.h   |  3 ++
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 36 ++-
  drivers/gpu/drm/i915/gt/selftest_execlists.c  | 29 +--
  drivers/gpu/drm/i915/gt/selftest_lrc.c| 24 +
  drivers/gpu/drm/i915/gt/selftest_mocs.c   | 29 +--
  .../gpu/drm/i915/gt/selftest_workarounds.c|  6 ++--
  8 files changed, 41 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h 
b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
index 4221cf84d175..13b241581dbb 100644
--- a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
+++ b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h
@@ -9,6 +9,7 @@
  
  #include 
  
+struct i915_address_space;


This doesn't seem to be required in this header.


  struct i915_request;
  struct i915_gem_context;
  struct i915_vma;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7bfe9072be9a..fbe6c0c5a060 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -422,6 +422,35 @@ void setup_private_pat(struct intel_uncore *uncore)
bdw_setup_private_ppat(uncore);
  }
  
+struct i915_vma *

+__vm_create_scratch(struct i915_address_space *vm, unsigned long size)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int err;
+
+   obj = i915_gem_object_create_internal(vm->i915, PAGE_ALIGN(size));
+   if (IS_ERR(obj))
+   return ERR_CAST(obj);
+
+   i915_gem_object_set_cache_coherency(obj, I915_CACHING_CACHED);
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma)) {
+   i915_gem_object_put(obj);
+   return vma;
+   }
+
+   err = i915_vma_pin(vma, 0, 0,
+  i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+   if (err) {
+   i915_gem_object_put(obj);
+   return ERR_PTR(err);
+   }
+
+   return vma;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/mock_gtt.c"
  #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8a33940a71f3..1cff86073af8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -573,6 +573,9 @@ int i915_vm_pin_pt_stash(struct i915_address_space *vm,
  void i915_vm_free_pt_stash(struct i915_address_space *vm,
   struct i915_vm_pt_stash *stash);
  
+struct i915_vma *

+__vm_create_scratch(struct i915_address_space *vm, unsigned long size);
+
  static inline struct sgt_dma {
struct scatterlist *sg;
dma_addr_t dma, max;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 52f12a6d66b9..be5b090ae6ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2085,39 +2085,6 @@ void intel_engine_apply_workarounds(struct 
intel_engine_cs *engine)
wa_list_apply(engine->uncore, >wa_list);
  }
  
-static struct i915_vma *

-create_scratch(struct i915_address_space *vm, int count)
-{
-   struct drm_i915_gem_object *obj;
-   struct i915_vma *vma;
-   unsigned int size;
-   int err;
-
-   size = round_up(count * sizeof(u32), PAGE_SIZE);
-   obj = i915_gem_object_create_internal(vm->i915, size);
-   if (IS_ERR(obj))
-   return ERR_CAST(obj);
-
-   i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
-
-   vma = i915_vma_instance(obj, vm, NULL);
-   if (IS_ERR(vma)) {
-   err = PTR_ERR(vma);
-   goto err_obj;
-   }
-
-   err = i915_vma_pin(vma, 0, 0,
-  i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
-   if (err)
-   goto err_obj;
-
-   return vma;
-
-err_obj:
-   i915_gem_object_put(obj);
-   return ERR_PTR(err);
-}
-
  struct mcr_range {
u32 start;
u32 end;
@@ -2220,7 +2187,8 @@ static int engine_wa_list_verify(struct intel_context *ce,
if (!wal->count)
return 0;
  
-	vma = create_scratch(>engine->gt->ggtt->vm, wal->count);

+   vma = __vm_create_scratch(>engine->gt->ggtt->vm,
+ wal->count * sizeof(u32));
if (IS_ERR(vma))
return PTR_ERR(vma);
  
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c b/drivers/gpu/drm/i915/gt/selftest_execlists.c

index 34c2bb8313eb..c6c0b9918c3e 

Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert

2020-12-15 Thread Tang, CQ



> -Original Message-
> From: Chris Wilson 
> Sent: Tuesday, December 15, 2020 12:31 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Tang, CQ ;
> sta...@vger.kernel.org
> Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check and
> vma insert
> 
> When inserting a VMA, we restrict the placement to the low 4G unless the
> caller opts into using the full range. This was done to allow usersapce the
> opportunity to transition slowly from a 32b address space, and to avoid
> breaking inherent 32b assumptions of some commands.
> 
> However, for insert we limited ourselves to 4G-4K, but on verification we
> allowed the full 4G. This causes some attempts to bind a new buffer to
> sporadically fail with -ENOSPC, but at other times be bound successfully.
> 
> commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page") suggests that there is a genuine problem with stateless addressing
> that cannot utilize the last page in 4G and so we purposefully excluded it.
> 
> Reported-by: CQ Tang 
> Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page")
> Signed-off-by: Chris Wilson 
> Cc: CQ Tang 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 193996144c84..2ff32daa50bd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> drm_i915_gem_exec_object2 *entry,
>   return true;
> 
>   if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> - (vma->node.start + vma->node.size - 1) >> 32)
> + (vma->node.start + vma->node.size + 4095) >> 32)

Why 4095 not 4096?

--CQ

>   return true;
> 
>   if (flags & __EXEC_OBJECT_NEEDS_MAP &&
> --
> 2.20.1

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


[Intel-gfx] [PATCH 2/2] i915/perf: Add removed OA formats back for TGL

2020-12-15 Thread Umesh Nerlige Ramappa
When defining OA formats for TGL, some formats were left out. Add them
back and clean up the uapi comments to reflect available formats.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 12 +---
 include/uapi/drm/i915_drm.h  | 24 ++--
 2 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index afa92cf075c4..659fcc9ae819 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -310,14 +310,12 @@ static const struct i915_oa_format 
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A45_B8_C8]  = { 5, 256, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
[I915_OA_FORMAT_B4_C8_A16]  = { 6, 128, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
 
-   /* haswell+ upto but not including tigerlake */
-   [I915_OA_FORMAT_C4_B8]  = { 7, 64, INTEL_IVYBRIDGE, 
INTEL_TIGERLAKE - 1 },
+   /* haswell+ */
+   [I915_OA_FORMAT_C4_B8]  = { 7, 64, INTEL_HASWELL, 
INTEL_MAX_PLATFORMS - 1 },
 
-   /* gen8+ upto but not including tigerlake */
-   [I915_OA_FORMAT_A12]= { 0, 64, INTEL_BROADWELL, 
INTEL_TIGERLAKE - 1 },
-   [I915_OA_FORMAT_A12_B8_C8]  = { 2, 128, INTEL_BROADWELL, 
INTEL_TIGERLAKE - 1 },
-
-   /* gen8+ */
+   /* broadwell+ */
+   [I915_OA_FORMAT_A12]= { 0, 64, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },
+   [I915_OA_FORMAT_A12_B8_C8]  = { 2, 128, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },
 };
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6edcb2b6c708..933511c2892e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1951,20 +1951,24 @@ struct drm_i915_gem_userptr {
 };
 
 enum drm_i915_oa_format {
-   I915_OA_FORMAT_A13 = 1, /* HSW only */
-   I915_OA_FORMAT_A29, /* HSW only */
-   I915_OA_FORMAT_A13_B8_C8,   /* HSW only */
-   I915_OA_FORMAT_B4_C8,   /* HSW only */
-   I915_OA_FORMAT_A45_B8_C8,   /* HSW only */
-   I915_OA_FORMAT_B4_C8_A16,   /* HSW only */
-   I915_OA_FORMAT_C4_B8,   /* HSW+ */
-
-   /* Gen8+ */
+   /* haswell */
+   I915_OA_FORMAT_A13 = 1,
+   I915_OA_FORMAT_A29,
+   I915_OA_FORMAT_A13_B8_C8,
+   I915_OA_FORMAT_B4_C8,
+   I915_OA_FORMAT_A45_B8_C8,
+   I915_OA_FORMAT_B4_C8_A16,
+
+   /* haswell+ */
+   I915_OA_FORMAT_C4_B8,
+
+   /* broadwell+ */
I915_OA_FORMAT_A12,
I915_OA_FORMAT_A12_B8_C8,
I915_OA_FORMAT_A32u40_A4u32_B8_C8,
 
-   I915_OA_FORMAT_MAX  /* non-ABI */
+   /* non-ABI */
+   I915_OA_FORMAT_MAX
 };
 
 enum drm_i915_perf_property_id {
-- 
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] i915/perf: Move gen specific OA formats to single array

2020-12-15 Thread Umesh Nerlige Ramappa
Variations in OA formats in the different gens has led to creation of
several sparse arrays to store the formats.

Move oa formats into a single array and add the supported range of
platforms for the oa formats.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c   | 56 --
 drivers/gpu/drm/i915/i915_perf_types.h |  3 ++
 2 files changed, 28 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f553caf4b06d..afa92cf075c4 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -298,28 +298,27 @@ static u32 i915_oa_max_sample_rate = 10;
 
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
- * be used as a mask to align the OA tail pointer.
+ * be used as a mask to align the OA tail pointer. Note that the platforms
+ * in this array specify a range (inclusive of start and end).
  */
-static const struct i915_oa_format hsw_oa_formats[I915_OA_FORMAT_MAX] = {
-   [I915_OA_FORMAT_A13]= { 0, 64 },
-   [I915_OA_FORMAT_A29]= { 1, 128 },
-   [I915_OA_FORMAT_A13_B8_C8]  = { 2, 128 },
-   /* A29_B8_C8 Disallowed as 192 bytes doesn't factor into buffer size */
-   [I915_OA_FORMAT_B4_C8]  = { 4, 64 },
-   [I915_OA_FORMAT_A45_B8_C8]  = { 5, 256 },
-   [I915_OA_FORMAT_B4_C8_A16]  = { 6, 128 },
-   [I915_OA_FORMAT_C4_B8]  = { 7, 64 },
-};
-
-static const struct i915_oa_format gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
-   [I915_OA_FORMAT_A12]= { 0, 64 },
-   [I915_OA_FORMAT_A12_B8_C8]  = { 2, 128 },
-   [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
-   [I915_OA_FORMAT_C4_B8]  = { 7, 64 },
-};
-
-static const struct i915_oa_format gen12_oa_formats[I915_OA_FORMAT_MAX] = {
-   [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = {
+   /* haswell */
+   [I915_OA_FORMAT_A13]= { 0, 64, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+   [I915_OA_FORMAT_A29]= { 1, 128, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+   [I915_OA_FORMAT_A13_B8_C8]  = { 2, 128, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+   [I915_OA_FORMAT_B4_C8]  = { 4, 64, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+   [I915_OA_FORMAT_A45_B8_C8]  = { 5, 256, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+   [I915_OA_FORMAT_B4_C8_A16]  = { 6, 128, INTEL_IVYBRIDGE, 
INTEL_HASWELL },
+
+   /* haswell+ upto but not including tigerlake */
+   [I915_OA_FORMAT_C4_B8]  = { 7, 64, INTEL_IVYBRIDGE, 
INTEL_TIGERLAKE - 1 },
+
+   /* gen8+ upto but not including tigerlake */
+   [I915_OA_FORMAT_A12]= { 0, 64, INTEL_BROADWELL, 
INTEL_TIGERLAKE - 1 },
+   [I915_OA_FORMAT_A12_B8_C8]  = { 2, 128, INTEL_BROADWELL, 
INTEL_TIGERLAKE - 1 },
+
+   /* gen8+ */
+   [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256, INTEL_BROADWELL, 
INTEL_MAX_PLATFORMS - 1 },
 };
 
 #define SAMPLE_OA_REPORT  (1<<0)
@@ -3575,6 +3574,7 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
for (i = 0; i < n_props; i++) {
u64 oa_period, oa_freq_hz;
u64 id, value;
+   enum intel_platform p = INTEL_INFO(perf->i915)->platform;
 
ret = get_user(id, uprop);
if (ret)
@@ -3611,8 +3611,9 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
  value);
return -EINVAL;
}
-   if (!perf->oa_formats[value].size) {
-   DRM_DEBUG("Unsupported OA report format %llu\n",
+   if (p < perf->oa_formats[value].start ||
+   p > perf->oa_formats[value].end) {
+   DRM_DEBUG("OA report format not supported 
%llu\n",
  value);
return -EINVAL;
}
@@ -4270,6 +4271,7 @@ void i915_perf_init(struct drm_i915_private *i915)
 
/* XXX const struct i915_perf_ops! */
 
+   perf->oa_formats = oa_formats;
if (IS_HASWELL(i915)) {
perf->ops.is_valid_b_counter_reg = gen7_is_valid_b_counter_addr;
perf->ops.is_valid_mux_reg = hsw_is_valid_mux_addr;
@@ -4280,8 +4282,6 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->ops.oa_disable = gen7_oa_disable;
perf->ops.read = gen7_oa_read;
perf->ops.oa_hw_tail_read = gen7_oa_hw_tail_read;
-
-   perf->oa_formats = hsw_oa_formats;
} else if (HAS_LOGICAL_RING_CONTEXTS(i915)) {
/* Note: that 

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_params: Assert a 4G object does _not_ fit without 48b

2020-12-15 Thread Tang, CQ



> -Original Message-
> From: Chris Wilson 
> Sent: Tuesday, December 15, 2020 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: igt-...@lists.freedesktop.org; Chris Wilson ;
> Tang, CQ 
> Subject: [PATCH i-g-t 1/2] i915/gem_exec_params: Assert a 4G object does
> _not_ fit without 48b
> 
> Without opting into 48B addressing, objects are strictly limited to being
> placed only the first (4G - 4K). This is to avoid an issue with stateless 32b
> addressing being unable to access the last 32b page.
> Assert that we do indeed fail to fit in a 4G object without setting the
> EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.
> 
> Reported-by: CQ Tang 
> References:: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB -
> 1 page")
> Signed-off-by: Chris Wilson 
> Cc: CQ Tang 
> ---
>  tests/i915/gem_exec_params.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
> index c405f4eb7..e679c512a 100644
> --- a/tests/i915/gem_exec_params.c
> +++ b/tests/i915/gem_exec_params.c
> @@ -340,7 +340,13 @@ static void test_larger_than_life_batch(int fd)
> for_each_engine(e, fd) {
>  /* Keep the batch_len implicit [0] */
>  execbuf.flags = eb_ring(e);
> -gem_execbuf(fd, );
> +
> +/* non-48b objects are limited to the low (4G - 4K) */
> +igt_assert_eq(__gem_execbuf(fd, ), -ENOSPC);
> +
> +exec.flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> +igt_assert_eq(__gem_execbuf(fd, ), 0);
> +exec.flags = 0;

It is good to test both cases.
Reviewed-by: CQ Tang 


> }
> 
> gem_sync(fd, exec.handle);
> --
> 2.29.2

___
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/display: Prevent double YUV range correction on HDR planes

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

Series: drm/i915/display: Prevent double YUV range correction on HDR planes
URL   : https://patchwork.freedesktop.org/series/84966/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9488 -> Patchwork_19149


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +22 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][4] ([i915#2283])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  * igt@runner@aborted:
- fi-snb-2600:NOTRUN -> [FAIL][7] ([i915#698])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-snb-2600/igt@run...@aborted.html

  
 Possible fixes 

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

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


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9488 -> Patchwork_19149

  CI-20190529: 20190529
  CI_DRM_9488: 610a032e0c8eff40d87d9344f92311382f4acd49 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19149: 7f602d3a40e441cbaf5fa895c639562bcf82d4de @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7f602d3a40e4 drm/i915/display: Prevent double YUV range correction on HDR planes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/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 1/2] i915/gem_exec_params: Assert a 4G object does _not_ fit without 48b

2020-12-15 Thread Chris Wilson
Without opting into 48B addressing, objects are strictly limited to
being placed only the first (4G - 4K). This is to avoid an issue with
stateless 32b addressing being unable to access the last 32b page.
Assert that we do indeed fail to fit in a 4G object without setting the
EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.

Reported-by: CQ Tang 
References:: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
---
 tests/i915/gem_exec_params.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index c405f4eb7..e679c512a 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -340,7 +340,13 @@ static void test_larger_than_life_batch(int fd)
for_each_engine(e, fd) {
   /* Keep the batch_len implicit [0] */
   execbuf.flags = eb_ring(e);
-  gem_execbuf(fd, );
+
+  /* non-48b objects are limited to the low (4G - 4K) */
+  igt_assert_eq(__gem_execbuf(fd, ), -ENOSPC);
+
+  exec.flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+  igt_assert_eq(__gem_execbuf(fd, ), 0);
+  exec.flags = 0;
}
 
gem_sync(fd, exec.handle);
-- 
2.29.2

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


[Intel-gfx] [PATCH i-g-t 2/2] i915/gem_softpin: Check full placement control under full-ppgtt

2020-12-15 Thread Chris Wilson
With full-ppgtt, userspacew has complete control over their GTT. Verify
that we can place an object at the very beginning and the very end of
our GTT.

Signed-off-by: Chris Wilson 
---
 tests/i915/gem_softpin.c | 45 
 1 file changed, 45 insertions(+)

diff --git a/tests/i915/gem_softpin.c b/tests/i915/gem_softpin.c
index fcaf8ef30..a530e89d3 100644
--- a/tests/i915/gem_softpin.c
+++ b/tests/i915/gem_softpin.c
@@ -97,6 +97,47 @@ static void test_invalid(int fd)
}
 }
 
+static uint32_t batch_create(int i915, uint64_t *sz)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   struct drm_i915_gem_create create = {
+   .size = sizeof(bbe),
+   };
+
+   if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CREATE, )) {
+   igt_assert_eq(errno, 0);
+   return 0;
+   }
+
+   gem_write(i915, create.handle, 0, , sizeof(bbe));
+
+   *sz = create.size;
+   return create.handle;
+}
+
+static void test_zero(int i915)
+{
+   uint64_t sz;
+   struct drm_i915_gem_exec_object2 object = {
+   .handle = batch_create(i915, ),
+   .flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   };
+
+   /* Under full-ppgtt, we have complete control of the GTT */
+
+   object.offset = 0;
+   gem_execbuf(i915, );
+
+   object.offset = gem_aperture_size(i915) - sz;
+   gem_close(i915, object.handle);
+
+   gem_close(i915, object.handle);
+}
+
 static void test_softpin(int fd)
 {
const uint32_t size = 1024 * 1024;
@@ -559,6 +600,10 @@ igt_main
 
igt_subtest("invalid")
test_invalid(fd);
+   igt_subtest("zero") {
+   igt_require(gem_uses_full_ppgtt(fd));
+   test_zero(fd);
+   }
igt_subtest("softpin")
test_softpin(fd);
igt_subtest("overlap")
-- 
2.29.2

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


[Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_params: Assert a 4G object does _not_ fit without 48b

2020-12-15 Thread Chris Wilson
Without opting into 48B addressing, objects are strictly limited to
being placed only the first (4G - 4K). This is to avoid an issue with
stateless 32b addressing being unable to access the last 32b page.
Assert that we do indeed fail to fit in a 4G object without setting the
EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.

Reported-by: CQ Tang 
References:: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
---
 tests/i915/gem_exec_params.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index c405f4eb7..e679c512a 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -340,7 +340,13 @@ static void test_larger_than_life_batch(int fd)
for_each_engine(e, fd) {
   /* Keep the batch_len implicit [0] */
   execbuf.flags = eb_ring(e);
-  gem_execbuf(fd, );
+
+  /* non-48b objects are limited to the low (4G - 4K) */
+  igt_assert_eq(__gem_execbuf(fd, ), -ENOSPC);
+
+  exec.flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+  igt_assert_eq(__gem_execbuf(fd, ), 0);
+  exec.flags = 0;
}
 
gem_sync(fd, exec.handle);
-- 
2.29.2

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


[Intel-gfx] [PATCH i-g-t 2/2] i915/gem_softpin: Check full placement control under full-ppgtt

2020-12-15 Thread Chris Wilson
With full-ppgtt, userspacew has complete control over their GTT. Verify
that we can place an object at the very beginning and the very end of
our GTT.

Signed-off-by: Chris Wilson 
---
 tests/i915/gem_softpin.c | 45 
 1 file changed, 45 insertions(+)

diff --git a/tests/i915/gem_softpin.c b/tests/i915/gem_softpin.c
index fcaf8ef30..a530e89d3 100644
--- a/tests/i915/gem_softpin.c
+++ b/tests/i915/gem_softpin.c
@@ -97,6 +97,47 @@ static void test_invalid(int fd)
}
 }
 
+static uint32_t batch_create(int i915, uint64_t *sz)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   struct drm_i915_gem_create create = {
+   .size = sizeof(bbe),
+   };
+
+   if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CREATE, )) {
+   igt_assert_eq(errno, 0);
+   return 0;
+   }
+
+   gem_write(i915, create.handle, 0, , sizeof(bbe));
+
+   *sz = create.size;
+   return create.handle;
+}
+
+static void test_zero(int i915)
+{
+   uint64_t sz;
+   struct drm_i915_gem_exec_object2 object = {
+   .handle = batch_create(i915, ),
+   .flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   };
+
+   /* Under full-ppgtt, we have complete control of the GTT */
+
+   object.offset = 0;
+   gem_execbuf(i915, );
+
+   object.offset = gem_aperture_size(i915) - sz;
+   gem_close(i915, object.handle);
+
+   gem_close(i915, object.handle);
+}
+
 static void test_softpin(int fd)
 {
const uint32_t size = 1024 * 1024;
@@ -559,6 +600,10 @@ igt_main
 
igt_subtest("invalid")
test_invalid(fd);
+   igt_subtest("zero") {
+   igt_require(gem_uses_full_ppgtt(fd));
+   test_zero(fd);
+   }
igt_subtest("softpin")
test_softpin(fd);
igt_subtest("overlap")
-- 
2.29.2

___
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/display: Prevent double YUV range correction on HDR planes

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

Series: drm/i915/display: Prevent double YUV range correction on HDR planes
URL   : https://patchwork.freedesktop.org/series/84966/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7f602d3a40e4 drm/i915/display: Prevent double YUV range correction on HDR planes
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#23: 
[1] 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281

total: 0 errors, 1 warnings, 0 checks, 13 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/gt: Track the overall awake/busy time

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

Series: drm/i915/gt: Track the overall awake/busy time
URL   : https://patchwork.freedesktop.org/series/84964/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9488 -> Patchwork_19148


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_hangman@error-state-basic:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@i915_hang...@error-state-basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/fi-tgl-y/igt@i915_hang...@error-state-basic.html

  
 Possible fixes 

  * igt@gem_basic@create-fd-close:
- fi-tgl-y:   [DMESG-WARN][3] ([i915#402]) -> [PASS][4] +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@gem_ba...@create-fd-close.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19148/fi-tgl-y/igt@gem_ba...@create-fd-close.html

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


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9488 -> Patchwork_19148

  CI-20190529: 20190529
  CI_DRM_9488: 610a032e0c8eff40d87d9344f92311382f4acd49 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19148: 57b8d4adc6235e4cb3c56fa72b3bb5e40b6e22e8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

57b8d4adc623 drm/i915/gt: Track the overall awake/busy time

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes

2020-12-15 Thread Andres Calderon Jaramillo
From: Andres Calderon Jaramillo 

Prevent the ICL HDR plane pipeline from performing YUV color range
correction twice when the input is in limited range.

Before this patch the following could happen: user space gives us a YUV
buffer in limited range; per the pipeline in [1], the plane would first
go through a "YUV Range correct" stage that expands the range; the plane
would then go through the "Input CSC" stage which would also expand the
range because icl_program_input_csc() would use a matrix and an offset
that assume limited-range input; this would ultimately cause dark and
light colors to appear darker and lighter than they should respectively.

This is an issue because if a buffer switches between being scanned out
and being composited with the GPU, the user will see a color difference.
If this switching happens quickly and frequently, the user will perceive
this as a flickering.

[1] 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281

Signed-off-by: Andres Calderon Jaramillo 
---
 drivers/gpu/drm/i915/display/intel_display.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 761be8deaa9b..aeea344b06ad 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4811,6 +4811,13 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= 
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
+
+   /*
+* Disable the YUV range correction stage because the input CSC
+* stage already takes care of range conversion by using 
separate
+* matrices and offsets depending on the color range.
+*/
+   plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
 
return plane_color_ctl;
-- 
2.29.2.684.gfbc64c5ab5-goog

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


[Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert

2020-12-15 Thread Chris Wilson
When inserting a VMA, we restrict the placement to the low 4G unless the
caller opts into using the full range. This was done to allow usersapce
the opportunity to transition slowly from a 32b address space, and to
avoid breaking inherent 32b assumptions of some commands.

However, for insert we limited ourselves to 4G-4K, but on verification
we allowed the full 4G. This causes some attempts to bind a new buffer
to sporadically fail with -ENOSPC, but at other times be bound
successfully.

commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
page") suggests that there is a genuine problem with stateless addressing
that cannot utilize the last page in 4G and so we purposefully excluded
it.

Reported-by: CQ Tang 
Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 193996144c84..2ff32daa50bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -382,7 +382,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 
*entry,
return true;
 
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
-   (vma->node.start + vma->node.size - 1) >> 32)
+   (vma->node.start + vma->node.size + 4095) >> 32)
return true;
 
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
-- 
2.20.1

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/backlight: RFC cache backlight power state

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

Series: drm/i915/backlight: RFC cache backlight power state
URL   : https://patchwork.freedesktop.org/series/84954/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9486_full -> Patchwork_19144_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@perf_pmu@enable-race@bcs0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9486/shard-tglb5/igt@perf_pmu@enable-r...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/shard-tglb5/igt@perf_pmu@enable-r...@bcs0.html

  

### Piglit changes ###

 Possible regressions 

  * spec@ext_framebuffer_multisample@turn-on-off 4:
- pig-snb-2600:   NOTRUN -> [FAIL][3] +30 similar issues
   [3]: None

  
New tests
-

  New tests have been introduced between CI_DRM_9486_full and 
Patchwork_19144_full:

### New Piglit tests (20) ###

  * spec@arb_depth_buffer_float@depthstencil-render-miplevels 1024 ds=z32f_s8:
- Statuses : 1 fail(s)
- Exec time: [5.80] s

  * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 d=s=z24_s8:
- Statuses : 1 fail(s)
- Exec time: [0.46] s

  * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 
d=z24_s8_s=z24_s8:
- Statuses : 1 fail(s)
- Exec time: [0.54] s

  * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 ds=z24_s8:
- Statuses : 1 fail(s)
- Exec time: [0.56] s

  * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 s=d=z24_s8:
- Statuses : 1 fail(s)
- Exec time: [0.46] s

  * spec@ext_packed_depth_stencil@depthstencil-render-miplevels 1024 
s=z24_s8_d=z24_s8:
- Statuses : 1 fail(s)
- Exec time: [0.48] s

  * spec@glsl-1.30@execution@tex-miplevel-selection texture() 1d:
- Statuses : 1 fail(s)
- Exec time: [1.40] s

  * spec@glsl-1.30@execution@tex-miplevel-selection texture() 2darrayshadow:
- Statuses : 1 fail(s)
- Exec time: [1.51] s

  * spec@glsl-1.30@execution@tex-miplevel-selection texture() cubearrayshadow:
- Statuses : 1 fail(s)
- Exec time: [1.99] s

  * spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) 1darrayshadow:
- Statuses : 1 fail(s)
- Exec time: [2.72] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj 1d:
- Statuses : 1 fail(s)
- Exec time: [1.34] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj 1d_projvec4:
- Statuses : 1 fail(s)
- Exec time: [1.35] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj 1dshadow:
- Statuses : 1 fail(s)
- Exec time: [1.46] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj 2d:
- Statuses : 1 fail(s)
- Exec time: [1.35] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj 2dshadow:
- Statuses : 1 fail(s)
- Exec time: [1.48] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj(bias) 
1d_projvec4:
- Statuses : 1 fail(s)
- Exec time: [2.53] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj(bias) 1dshadow:
- Statuses : 1 fail(s)
- Exec time: [2.56] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj(bias) 2d:
- Statuses : 1 fail(s)
- Exec time: [2.53] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureproj(bias) 2dshadow:
- Statuses : 1 fail(s)
- Exec time: [2.21] s

  * spec@glsl-1.30@execution@tex-miplevel-selection textureprojlod 1d:
- Statuses : 1 fail(s)
- Exec time: [2.63] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-queues-all:
- shard-glk:  [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9486/shard-glk4/igt@gem_exec_whis...@basic-queues-all.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/shard-glk7/igt@gem_exec_whis...@basic-queues-all.html

  * igt@i915_pm_dc@dc6-psr:
- shard-tglb: NOTRUN -> [FAIL][6] ([i915#454])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/shard-tglb7/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2692])
   [7]: 

Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes

2020-12-15 Thread Ville Syrjälä
On Tue, Dec 15, 2020 at 03:06:30PM -0500, Andres Calderon Jaramillo wrote:
> On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä
>  wrote:
> >
> > On Mon, Dec 14, 2020 at 10:57:03PM +, Shankar, Uma wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: andrescj via sendgmr 
> > > > 
> > > > On Behalf Of Andres Calderon Jaramillo
> > > > Sent: Tuesday, December 15, 2020 3:50 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Shankar, Uma ; Venkatesh Reddy, Sushma
> > > > ; seanp...@chromium.org; Andres
> > > > Calderon Jaramillo 
> > > > Subject: [PATCH] drm/i915/display: Prevent double YUV range correction 
> > > > on HDR
> > > > planes
> > > >
> > > > From: Andres Calderon Jaramillo 
> > > >
> > > > Prevent the ICL HDR plane pipeline from performing YUV color range 
> > > > correction
> > > > twice when the input is in limited range.
> > > >
> > > > Before this patch the following could happen: user space gives us a YUV 
> > > > buffer in
> > > > limited range; per the pipeline in [1], the plane would first go 
> > > > through a "YUV
> > > > Range correct" stage that expands the range; the plane would then go 
> > > > through
> > > > the "Input CSC" stage which would also expand the range because
> > > > icl_program_input_csc() would use a matrix and an offset that assume 
> > > > limited-
> > > > range input; this would ultimately cause dark and light colors to 
> > > > appear darker
> > > > and lighter than they should respectively.
> > > >
> > > > This is an issue because if a buffer switches between being scanned out 
> > > > and
> > > > being composited with the GPU, the user will see a color difference.
> > > > If this switching happens quickly and frequently, the user will 
> > > > perceive this as a
> > > > flickering.
> > > >
> > > > [1] 
> > > > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-
> > > > vol12-displayengine_0.pdf#page=281
> > >
> > > Change looks good to me, double conversion should not be done.
> > > Plane input csc coefficients take care of the limited range.
> >
> > Might make sense to actually use the hw range correction instead.
> > Would avoid having to keep around two sets of coefficients.
> >
> > Also the question now becomes: How can our tests be passing if
> > we're doing the range correction twice?
> >
> 
> I also considered just removing the limited-range matrix/offsets from
> icl_program_input_csc(). However, I figured that since the "Input CSC"
> stage must happen regardless of range correction, maybe it would be a
> gain to disable the "YUV Range Correction" stage. However, I'm not
> familiar with the hardware details, so I don't know for sure. I don't
> feel strongly either way; let me know what you'd prefer.

IIRC we use the fixed function range compression + full range csc
approach on chv as well. Wouldn't hurt to do the same thing on
icl+ IMO.

> 
> I'm also curious about the testing. How do the tests work? I assume
> they are in Intel's CI and not open sourced? Do they use the DRM
> writeback connector (I didn't think this was implemented for i915
> yet)?

Tests are here:
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

In particular kms_plane/pixel-format tests should rather be failing I
think. Unless we've relaxed things a bit too much to get the crcs to
match when the results are close enough.

> 
> > >
> > > Reviewed-by: Uma Shankar 
> > >
> > > > Signed-off-by: Andres Calderon Jaramillo 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 761be8deaa9b..aeea344b06ad 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -4811,6 +4811,13 @@ u32 glk_plane_color_ctl(const struct 
> > > > intel_crtc_state
> > > > *crtc_state,
> > > > plane_color_ctl |=
> > > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > > } else if (fb->format->is_yuv) {
> > > > plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > > > +
> > > > +   /*
> > > > +* Disable the YUV range correction stage because the input 
> > > > CSC
> > > > +* stage already takes care of range conversion by using 
> > > > separate
> > > > +* matrices and offsets depending on the color range.
> > > > +*/
> > > > +   plane_color_ctl |=
> > > > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > > > }
> > > >
> > > > return plane_color_ctl;
> > > > --
> > > > 2.29.2.684.gfbc64c5ab5-goog
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges (rev3)

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

Series: series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges 
(rev3)
URL   : https://patchwork.freedesktop.org/series/84849/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9488 -> Patchwork_19147


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +22 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#2283])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@vgem_basic@dmabuf-export:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html

  
 Possible fixes 

  * igt@gem_basic@create-fd-close:
- fi-tgl-y:   [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@gem_ba...@create-fd-close.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/fi-tgl-y/igt@gem_ba...@create-fd-close.html

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


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9488 -> Patchwork_19147

  CI-20190529: 20190529
  CI_DRM_9488: 610a032e0c8eff40d87d9344f92311382f4acd49 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19147: c85f8a2cb7d4f2eec063ad0627327543aba54d25 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c85f8a2cb7d4 dma-buf: doc polish for pin/unpin
214090d2fdc5 dma-buf: begin/end_cpu might lock the dma_resv lock
df3455aca7cf dma-buf: some kerneldoc formatting fixes
403e03068940 dma-buf: Remove kmap kerneldoc vestiges

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19147/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: remove h from printk format specifier

2020-12-15 Thread Tom Rix


On 12/15/20 10:13 AM, Chris Wilson wrote:
> Quoting t...@redhat.com (2020-12-15 14:41:01)
>> From: Tom Rix 
>>
>> See Documentation/core-api/printk-formats.rst.
>> h should no longer be used in the format specifier for printk.
> It's understood by format_decode().
> * 'h', 'l', or 'L' for integer fields
>
> At least reference commit cbacb5ab0aa0 ("docs: printk-formats: Stop
> encouraging use of unnecessary %h[xudi] and %hh[xudi]") as to why the
> printk-formats.rst was altered so we know the code is merely in bad
> taste and not using undefined behaviour of printk.

Ok, i will fix this after the first run of patches.

Tom

> -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 series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges (rev3)

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

Series: series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges 
(rev3)
URL   : https://patchwork.freedesktop.org/series/84849/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
403e03068940 dma-buf: Remove kmap kerneldoc vestiges
-:115: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 84 lines checked
df3455aca7cf dma-buf: some kerneldoc formatting fixes
-:144: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 108 lines checked
214090d2fdc5 dma-buf: begin/end_cpu might lock the dma_resv lock
-:42: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 16 lines checked
c85f8a2cb7d4 dma-buf: doc polish for pin/unpin
-:96: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 63 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/gem: Drop free_work for GEM contexts (rev3)

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

Series: drm/i915/gem: Drop free_work for GEM contexts (rev3)
URL   : https://patchwork.freedesktop.org/series/83537/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9488 -> Patchwork_19146


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@execlists:
- fi-cml-s:   [PASS][3] -> [INCOMPLETE][4] ([i915#1037])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-cml-s/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/fi-cml-s/igt@i915_selftest@l...@execlists.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][5] -> [DMESG-WARN][6] ([i915#165]) +27 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  * igt@runner@aborted:
- fi-cml-s:   NOTRUN -> [FAIL][9] ([i915#2082] / [i915#2426] / 
[i915#2722])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/fi-cml-s/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_basic@create-fd-close:
- fi-tgl-y:   [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@gem_ba...@create-fd-close.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/fi-tgl-y/igt@gem_ba...@create-fd-close.html

  
  [i915#1037]: https://gitlab.freedesktop.org/drm/intel/issues/1037
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9488 -> Patchwork_19146

  CI-20190529: 20190529
  CI_DRM_9488: 610a032e0c8eff40d87d9344f92311382f4acd49 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19146: ad5df892a75abce155d0c54d79bc02934eff4ec7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ad5df892a75a drm/i915/gem: Drop free_work for GEM contexts

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19146/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: remove h from printk format specifier

2020-12-15 Thread Chris Wilson
Quoting t...@redhat.com (2020-12-15 14:41:01)
> From: Tom Rix 
> 
> See Documentation/core-api/printk-formats.rst.
> h should no longer be used in the format specifier for printk.

It's understood by format_decode().
* 'h', 'l', or 'L' for integer fields

At least reference commit cbacb5ab0aa0 ("docs: printk-formats: Stop
encouraging use of unnecessary %h[xudi] and %hh[xudi]") as to why the
printk-formats.rst was altered so we know the code is merely in bad
taste and not using undefined behaviour of printk.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes

2020-12-15 Thread Ville Syrjälä
On Mon, Dec 14, 2020 at 10:57:03PM +, Shankar, Uma wrote:
> 
> 
> > -Original Message-
> > From: andrescj via sendgmr 
> > 
> > On Behalf Of Andres Calderon Jaramillo
> > Sent: Tuesday, December 15, 2020 3:50 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Shankar, Uma ; Venkatesh Reddy, Sushma
> > ; seanp...@chromium.org; Andres
> > Calderon Jaramillo 
> > Subject: [PATCH] drm/i915/display: Prevent double YUV range correction on 
> > HDR
> > planes
> > 
> > From: Andres Calderon Jaramillo 
> > 
> > Prevent the ICL HDR plane pipeline from performing YUV color range 
> > correction
> > twice when the input is in limited range.
> > 
> > Before this patch the following could happen: user space gives us a YUV 
> > buffer in
> > limited range; per the pipeline in [1], the plane would first go through a 
> > "YUV
> > Range correct" stage that expands the range; the plane would then go through
> > the "Input CSC" stage which would also expand the range because
> > icl_program_input_csc() would use a matrix and an offset that assume 
> > limited-
> > range input; this would ultimately cause dark and light colors to appear 
> > darker
> > and lighter than they should respectively.
> > 
> > This is an issue because if a buffer switches between being scanned out and
> > being composited with the GPU, the user will see a color difference.
> > If this switching happens quickly and frequently, the user will perceive 
> > this as a
> > flickering.
> > 
> > [1] 
> > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-
> > vol12-displayengine_0.pdf#page=281
> 
> Change looks good to me, double conversion should not be done.
> Plane input csc coefficients take care of the limited range.

Might make sense to actually use the hw range correction instead.
Would avoid having to keep around two sets of coefficients.

Also the question now becomes: How can our tests be passing if
we're doing the range correction twice?

> 
> Reviewed-by: Uma Shankar 
> 
> > Signed-off-by: Andres Calderon Jaramillo 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 761be8deaa9b..aeea344b06ad 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4811,6 +4811,13 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> > *crtc_state,
> > plane_color_ctl |=
> > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > } else if (fb->format->is_yuv) {
> > plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > +
> > +   /*
> > +* Disable the YUV range correction stage because the input CSC
> > +* stage already takes care of range conversion by using 
> > separate
> > +* matrices and offsets depending on the color range.
> > +*/
> > +   plane_color_ctl |=
> > PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > }
> > 
> > return plane_color_ctl;
> > --
> > 2.29.2.684.gfbc64c5ab5-goog
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 15/69] drm/i915/gt: Track all timelines created using the HWSP

2020-12-15 Thread Chris Wilson
Quoting Mika Kuoppala (2020-12-15 17:09:39)
> Chris Wilson  writes:
> 
> > We assume that the contents of the HWSP are lost across suspend, and so
> > upon resume we must restore critical values such as the timeline seqno.
> > Keep track of every timeline allocated that uses the HWSP as its storage
> > and so we can then reset all seqno values by walking that list.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 -
> >  drivers/gpu/drm/i915/gt/intel_engine_pm.c |  6 
> >  drivers/gpu/drm/i915/gt/intel_engine_types.h  |  1 +
> >  .../drm/i915/gt/intel_execlists_submission.c  | 11 --
> >  .../gpu/drm/i915/gt/intel_ring_submission.c   | 35 +++
> >  drivers/gpu/drm/i915/gt/intel_timeline.h  | 13 +--
> >  .../gpu/drm/i915/gt/intel_timeline_types.h|  2 ++
> >  7 files changed, 71 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 71bd052628f4..6c08e74edcae 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -648,6 +648,8 @@ static int init_status_page(struct intel_engine_cs 
> > *engine)
> >   void *vaddr;
> >   int ret;
> >  
> > + INIT_LIST_HEAD(>status_page.timelines);
> > +
> >   /*
> >* Though the HWS register does support 36bit addresses, historically
> >* we have had hangs and corruption reported due to wild writes if
> > @@ -936,6 +938,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs 
> > *engine)
> >   fput(engine->default_state);
> >  
> >   if (engine->kernel_context) {
> > + list_del(>kernel_context->timeline->engine_link);
> >   intel_context_unpin(engine->kernel_context);
> >   intel_context_put(engine->kernel_context);
> >   }
> > @@ -1281,8 +1284,12 @@ void intel_engines_reset_default_submission(struct 
> > intel_gt *gt)
> >   struct intel_engine_cs *engine;
> >   enum intel_engine_id id;
> >  
> > - for_each_engine(engine, gt, id)
> > + for_each_engine(engine, gt, id) {
> > + if (engine->sanitize)
> > + engine->sanitize(engine);
> > +
> >   engine->set_default_submission(engine);
> > + }
> >  }
> >  
> >  bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 99574378047f..1e5bad0b9a82 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -60,6 +60,12 @@ static int __engine_unpark(struct intel_wakeref *wf)
> >  
> >   /* Scrub the context image after our loss of control */
> >   ce->ops->reset(ce);
> > +
> > + CE_TRACE(ce, "reset { seqno:%x, *hwsp:%x, ring:%x }\n",
> > +  ce->timeline->seqno,
> > +  READ_ONCE(*ce->timeline->hwsp_seqno),
> > +  ce->ring->emit);
> > + GEM_BUG_ON(ce->timeline->seqno != *ce->timeline->hwsp_seqno);
> 
> Compiler should be satified but could still have been READ_ONCE,
> for the reader and for the fine bug on which might get delivered to console. 

Yup, I hesitated as it meant a newline :)

> But main thing is that now coherency is enforced from the get go.

> > +static void xcs_sanitize(struct intel_engine_cs *engine)
> > +{
> > + /*
> > +  * Poison residual state on resume, in case the suspend didn't!
> > +  *
> > +  * We have to assume that across suspend/resume (or other loss
> > +  * of control) that the contents of our pinned buffers has been
> > +  * lost, replaced by garbage. Since this doesn't always happen,
> > +  * let's poison such state so that we more quickly spot when
> > +  * we falsely assume it has been preserved.
> > +  */
> > + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> > + memset(engine->status_page.addr, POISON_INUSE, PAGE_SIZE);
> > +
> > + /*
> > +  * The kernel_context HWSP is stored in the status_page. As above,
> > +  * that may be lost on resume/initialisation, and so we need to
> > +  * reset the value in the HWSP.
> > +  */
> > + sanitize_hwsp(engine);
> > +
> > + /* And scrub the dirty cachelines for the HWSP */
> > + clflush_cache_range(engine->status_page.addr, PAGE_SIZE);
> 
> The flush could be part of the actual writing of the seqno with
> that range. But then you would need to track the debug so. Better
> to make sure to transfer everything to be visible.

Yes. It's also just part of the general 'sanitize' paranoia; we scrub
everything until we are convinced that we only see our own bugs
reflected back at us.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 15/69] drm/i915/gt: Track all timelines created using the HWSP

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

> We assume that the contents of the HWSP are lost across suspend, and so
> upon resume we must restore critical values such as the timeline seqno.
> Keep track of every timeline allocated that uses the HWSP as its storage
> and so we can then reset all seqno values by walking that list.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 -
>  drivers/gpu/drm/i915/gt/intel_engine_pm.c |  6 
>  drivers/gpu/drm/i915/gt/intel_engine_types.h  |  1 +
>  .../drm/i915/gt/intel_execlists_submission.c  | 11 --
>  .../gpu/drm/i915/gt/intel_ring_submission.c   | 35 +++
>  drivers/gpu/drm/i915/gt/intel_timeline.h  | 13 +--
>  .../gpu/drm/i915/gt/intel_timeline_types.h|  2 ++
>  7 files changed, 71 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 71bd052628f4..6c08e74edcae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -648,6 +648,8 @@ static int init_status_page(struct intel_engine_cs 
> *engine)
>   void *vaddr;
>   int ret;
>  
> + INIT_LIST_HEAD(>status_page.timelines);
> +
>   /*
>* Though the HWS register does support 36bit addresses, historically
>* we have had hangs and corruption reported due to wild writes if
> @@ -936,6 +938,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs 
> *engine)
>   fput(engine->default_state);
>  
>   if (engine->kernel_context) {
> + list_del(>kernel_context->timeline->engine_link);
>   intel_context_unpin(engine->kernel_context);
>   intel_context_put(engine->kernel_context);
>   }
> @@ -1281,8 +1284,12 @@ void intel_engines_reset_default_submission(struct 
> intel_gt *gt)
>   struct intel_engine_cs *engine;
>   enum intel_engine_id id;
>  
> - for_each_engine(engine, gt, id)
> + for_each_engine(engine, gt, id) {
> + if (engine->sanitize)
> + engine->sanitize(engine);
> +
>   engine->set_default_submission(engine);
> + }
>  }
>  
>  bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 99574378047f..1e5bad0b9a82 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -60,6 +60,12 @@ static int __engine_unpark(struct intel_wakeref *wf)
>  
>   /* Scrub the context image after our loss of control */
>   ce->ops->reset(ce);
> +
> + CE_TRACE(ce, "reset { seqno:%x, *hwsp:%x, ring:%x }\n",
> +  ce->timeline->seqno,
> +  READ_ONCE(*ce->timeline->hwsp_seqno),
> +  ce->ring->emit);
> + GEM_BUG_ON(ce->timeline->seqno != *ce->timeline->hwsp_seqno);

Compiler should be satified but could still have been READ_ONCE,
for the reader and for the fine bug on which might get delivered to console. 

But main thing is that now coherency is enforced from the get go.

>   }
>  
>   if (engine->unpark)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index e71eef157231..c28f4e190fe6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -68,6 +68,7 @@ typedef u8 intel_engine_mask_t;
>  #define ALL_ENGINES ((intel_engine_mask_t)~0ul)
>  
>  struct intel_hw_status_page {
> + struct list_head timelines;
>   struct i915_vma *vma;
>   u32 *addr;
>  };
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 9f5efff08785..c5b013cc10b3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3508,7 +3508,6 @@ static int execlists_context_alloc(struct intel_context 
> *ce)
>  
>  static void execlists_context_reset(struct intel_context *ce)
>  {
> - CE_TRACE(ce, "reset\n");
>   GEM_BUG_ON(!intel_context_is_pinned(ce));
>  
>   intel_ring_reset(ce->ring, ce->ring->emit);
> @@ -3985,6 +3984,14 @@ static void reset_csb_pointers(struct intel_engine_cs 
> *engine)
>   GEM_BUG_ON(READ_ONCE(*execlists->csb_write) != reset_value);
>  }
>  
> +static void sanitize_hwsp(struct intel_engine_cs *engine)
> +{
> + struct intel_timeline *tl;
> +
> + list_for_each_entry(tl, >status_page.timelines, engine_link)
> + intel_timeline_reset_seqno(tl);
> +}
> +
>  static void execlists_sanitize(struct intel_engine_cs *engine)
>  {
>   GEM_BUG_ON(execlists_active(>execlists));
> @@ -4008,7 +4015,7 @@ static void execlists_sanitize(struct intel_engine_cs 
> *engine)
>* that may be lost on 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove h from printk format specifier

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

Series: drm/i915: remove h from printk format specifier
URL   : https://patchwork.freedesktop.org/series/84958/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9487 -> Patchwork_19145


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-tgl-u2:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9487/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +30 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [PASS][4] -> [FAIL][5] ([i915#2679])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9487/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#2029] / [i915#2722])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-bdw-5557u/igt@run...@aborted.html
- fi-tgl-u2:  NOTRUN -> [FAIL][8] ([i915#2045] / [i915#2722])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-tgl-u2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[DMESG-WARN][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9487/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [SKIP][11] ([fdo#109271]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9487/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][13] ([i915#2291] / [i915#541]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9487/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19145/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2045]: https://gitlab.freedesktop.org/drm/intel/issues/2045
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2679]: https://gitlab.freedesktop.org/drm/intel/issues/2679
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Participating hosts (43 -> 38)
--

  Missing(5): fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-tgl-y fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9487 -> Patchwork_19145

  CI-20190529: 20190529
  CI_DRM_9487: 43bb70011b480e222721c5472399dc2dcd795c36 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19145: f67d74d936b7d5934c7ace143ccff2e38f9b758d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f67d74d936b7 drm/i915: remove h from printk format specifier

== Logs ==

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

Re: [Intel-gfx] [patch 23/30] net/mlx5: Use effective interrupt affinity

2020-12-15 Thread Saeed Mahameed
On Thu, 2020-12-10 at 20:25 +0100, Thomas Gleixner wrote:
> Using the interrupt affinity mask for checking locality is not really
> working well on architectures which support effective affinity masks.
> 
> The affinity mask is either the system wide default or set by user
> space,
> but the architecture can or even must reduce the mask to the
> effective set,
> which means that checking the affinity mask itself does not really
> tell
> about the actual target CPUs.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Saeed Mahameed 
> Cc: Leon Romanovsky 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: net...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> 

Acked-by: Saeed Mahameed 

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


Re: [Intel-gfx] [patch 22/30] net/mlx5: Replace irq_to_desc() abuse

2020-12-15 Thread Saeed Mahameed
On Thu, 2020-12-10 at 20:25 +0100, Thomas Gleixner wrote:
> No driver has any business with the internals of an interrupt
> descriptor. Storing a pointer to it just to use yet another helper at
> the
> actual usage site to retrieve the affinity mask is creative at best.
> Just
> because C does not allow encapsulation does not mean that the kernel
> has no
> limits.
> 

you can't blame the developers for using stuff from include/linux/
Not all developers are the same, and sometime we don't read in between
the lines, you can't assume all driver developers to be expert on irq
APIs disciplines.

your rules must be programmatically expressed, for instance,
you can just hide struct irq_desc and irq_to_desc() in kernel/irq/ and
remove them from include/linux/ header files, if you want privacy in
your subsystem, don't put all your header files on display under
include/linux.


> Retrieve a pointer to the affinity mask itself and use that. It's
> still
> using an interface which is usually not for random drivers, but
> definitely
> less hideous than the previous hack.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en.h  |2 +-
>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c |2 +-
>  drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c |6 +-
>  3 files changed, 3 insertions(+), 7 deletions(-)
> 
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -669,7 +669,7 @@ struct mlx5e_channel {
>   spinlock_t async_icosq_lock;
>  
>   /* data path - accessed per napi poll */
> - struct irq_desc *irq_desc;
> + const struct cpumask  *aff_mask;
>   struct mlx5e_ch_stats *stats;
>  
>   /* control */
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -1998,7 +1998,7 @@ static int mlx5e_open_channel(struct mlx
>   c->num_tc   = params->num_tc;
>   c->xdp  = !!params->xdp_prog;
>   c->stats= >channel_stats[ix].ch;
> - c->irq_desc = irq_to_desc(irq);
> + c->aff_mask = irq_get_affinity_mask(irq);

as long as the affinity mask pointer stays the same for the lifetime of
the irq vector.

Assuming that:
Acked-by: Saeed Mahameed 


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


Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs

2020-12-15 Thread Jan Kiszka
On 03.12.20 22:30, Alex Deucher wrote:
> On Tue, Sep 29, 2020 at 4:04 PM Alex Deucher  wrote:
>>
>> On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka  wrote:
>>>
>>> On 10.09.20 20:18, Deucher, Alexander wrote:
 [AMD Public Use]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Daniel Vetter
> Sent: Monday, September 7, 2020 3:15 AM
> To: Jan Kiszka ; amd-gfx list  g...@lists.freedesktop.org>; Wentland, Harry ;
> Kazlauskas, Nicholas 
> Cc: dri-devel ; intel-gfx  g...@lists.freedesktop.org>; Thomas Zimmermann
> ; Ville Syrjala 
> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
>
> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka  wrote:
>>
>> On 11.02.20 18:04, Daniel Vetter wrote:
>>> On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
 From: Ville Syrjälä 

 WARN if the encoder possible_crtcs is effectively empty or contains
 bits for non-existing crtcs.

 v2: Move to drm_mode_config_validate() (Daniel)
 Make the docs say we WARN when this is wrong (Daniel)
 Extract full_crtc_mask()

 Cc: Thomas Zimmermann 
 Cc: Daniel Vetter 
 Signed-off-by: Ville Syrjälä 
>>>
>>> When pushing the fixup needs to be applied before the validation
>>> patch here, because we don't want to anger the bisect gods.
>>>
>>> Reviewed-by: Daniel Vetter 
>>>
>>> I think with the fixup we should be good enough with the existing
>>> nonsense in drivers. Fingers crossed.
>>> -Daniel
>>>
>>>
 ---
  drivers/gpu/drm/drm_mode_config.c | 27
> ++-
  include/drm/drm_encoder.h |  2 +-
  2 files changed, 27 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_mode_config.c
 b/drivers/gpu/drm/drm_mode_config.c
 index afc91447293a..4c1b350ddb95 100644
 --- a/drivers/gpu/drm/drm_mode_config.c
 +++ b/drivers/gpu/drm/drm_mode_config.c
 @@ -581,6 +581,29 @@ static void
> validate_encoder_possible_clones(struct drm_encoder *encoder)
   encoder->possible_clones, encoder_mask);  }

 +static u32 full_crtc_mask(struct drm_device *dev) {
 +struct drm_crtc *crtc;
 +u32 crtc_mask = 0;
 +
 +drm_for_each_crtc(crtc, dev)
 +crtc_mask |= drm_crtc_mask(crtc);
 +
 +return crtc_mask;
 +}
 +
 +static void validate_encoder_possible_crtcs(struct drm_encoder
 +*encoder) {
 +u32 crtc_mask = full_crtc_mask(encoder->dev);
 +
 +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
 + (encoder->possible_crtcs & ~crtc_mask) != 0,
 + "Bogus possible_crtcs: "
 + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc 
 mask=0x%x)\n",
 + encoder->base.id, encoder->name,
 + encoder->possible_crtcs, crtc_mask); }
 +
  void drm_mode_config_validate(struct drm_device *dev)  {
  struct drm_encoder *encoder;
 @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> drm_device *dev)
  drm_for_each_encoder(encoder, dev)
  fixup_encoder_possible_clones(encoder);

 -drm_for_each_encoder(encoder, dev)
 +drm_for_each_encoder(encoder, dev) {
  validate_encoder_possible_clones(encoder);
 +validate_encoder_possible_crtcs(encoder);
 +}
  }
 diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
 index 3741963b9587..b236269f41ac 100644
 --- a/include/drm/drm_encoder.h
 +++ b/include/drm/drm_encoder.h
 @@ -142,7 +142,7 @@ struct drm_encoder {
   * the bits for all _crtc objects this encoder can be 
 connected to
   * before calling drm_dev_register().
   *
 - * In reality almost every driver gets this wrong.
 + * You will get a WARN if you get this wrong in the driver.
   *
   * Note that since CRTC objects can't be hotplugged the assigned
> indices
   * are stable and hence known before registering all objects.
 --
 2.24.1

>>>
>>
>> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
>
> Adding amdgpu display folks.

 I took a quick look at this and it looks like we limit the number of crtcs 
 later in the mode init process if the number of physical displays can't 
 actually use more crtcs.  E.g., the physical board configuration would 
 only allow for 3 active displays even if the hardware technically supports 
 4 crtcs.  I presume that way we can just leave 

Re: [Intel-gfx] [PULL] drm-misc-next-fixes

2020-12-15 Thread Daniel Vetter
On Tue, Dec 15, 2020 at 02:04:31PM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
> 
> here's this week's PR for drm-misc-next-fixes. IIRC the radeon fix is
> already in drm-misc-next.

Pulled, and also your previous -next pull which got stuck somewhere.

Thanks, Daniel

> 
> Best regards
> Thomas
> 
> drm-misc-next-fixes-2020-12-15:
> Short summary of fixes pull (less than what git shortlog provides):
> 
>  * dma-buf: Fix docs
>  * mxsfb: Silence invalid error message
>  * radeon: Fix TTM multihop
> 
> The following changes since commit 05faf1559de52465f1e753e31883aa294e6179c1:
> 
>   drm/imx/dcss: allow using nearest neighbor interpolation scaling 
> (2020-11-26 11:29:44 +0100)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc 
> tags/drm-misc-next-fixes-2020-12-15
> 
> for you to fetch changes up to ee46d16d2e40bebc2aa790fd7b6a056466ff895c:
> 
>   drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge (2020-12-15 
> 11:01:10 +0100)
> 
> 
> Short summary of fixes pull (less than what git shortlog provides):
> 
>  * dma-buf: Fix docs
>  * mxsfb: Silence invalid error message
>  * radeon: Fix TTM multihop
> 
> 
> Christian König (1):
>   drm/radeon: fix check order in radeon_bo_move
> 
> Daniel Vetter (1):
>   dma-buf: Fix kerneldoc formatting
> 
> Guido Günther (1):
>   drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge
> 
>  Documentation/driver-api/dma-buf.rst |  2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c| 10 +++
>  drivers/gpu/drm/radeon/radeon_ttm.c  | 54 
> 
>  include/linux/dma-buf-map.h  |  2 +-
>  4 files changed, 30 insertions(+), 38 deletions(-)
> 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/backlight: RFC cache backlight power state

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

Series: drm/i915/backlight: RFC cache backlight power state
URL   : https://patchwork.freedesktop.org/series/84954/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9486 -> Patchwork_19144


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9486/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html

  
 Possible fixes 

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-y:   [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9486/fi-tgl-y/igt@kms_psr@primary_mmap_gtt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/fi-tgl-y/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9486/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19144/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

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


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9486 -> Patchwork_19144

  CI-20190529: 20190529
  CI_DRM_9486: c834ebc78f2719e0b7f4f442b837daf5e29be100 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19144: a7044e521942e99794babf2e65c993158a04682c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a7044e521942 drm/i915/backlight: RFC cache backlight power state

== Logs ==

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


Re: [Intel-gfx] [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format

2020-12-15 Thread Ville Syrjälä
On Tue, Dec 15, 2020 at 03:43:00PM +, Souza, Jose wrote:
> On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > > Much more clear to read one function call than four lines doing this
> > > conversion.
> > > 
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: Gwan-gyeong Mun 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/drm_rect.c | 15 +++
> > >  include/drm/drm_rect.h |  2 ++
> > >  2 files changed, 17 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > > index 0460e874896e..24345704b353 100644
> > > --- a/drivers/gpu/drm/drm_rect.c
> > > +++ b/drivers/gpu/drm/drm_rect.c
> > > @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> > >   }
> > >  }
> > >  EXPORT_SYMBOL(drm_rect_rotate_inv);
> > > +
> > > +/**
> > > + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed 
> > > point form
> > > + * to regular form.
> > > + * @in: rect in 16.16 fixed point form
> > > + * @out: rect to be stored the converted value
> > > + */
> > > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct 
> > > drm_rect *out)
> > > +{
> > > + out->x1 = in->x1 >> 16;
> > > + out->y1 = in->y1 >> 16;
> > > + out->x2 = in->x2 >> 16;
> > > + out->y2 = in->y2 >> 16;
> > > +}
> > 
> > That's not the same as what we do in most places. We truncate
> > the width/height, not x2/y2. Doing it on x2/y2 may increase
> > the width/height.
> > 
> > So I suggest something more like:
> > 
> > static inline void drm_rect_fp_to_int(struct drm_rect *r)
> > {
> > drm_rect_init(r, r->x1 >> 16, r->y1 >> 16,
> >   drm_rect_width(r) >> 16,
> >   drm_rect_height(r) >> 16);
> > }
> > 
> > to match the current way of doing things.
> 
> Okay, but most use cases takes drm_plane_state.src and converts and sets it 
> in another rect, so will modify it to have two parameters.

Would seem a bit more generic by having the caller make the copy
if needed. But I guess not big deal either way.

At least make it follow the correct argument order as laid out
by memcpy() ;) (+const for the input argument ofc).

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


Re: [Intel-gfx] [CI] drm/i915/gt: Track the overall awake/busy time

2020-12-15 Thread Chris Wilson
Quoting Chris Wilson (2020-12-15 15:44:56)
> Since we wake the GT up before executing a request, and go to sleep as
> soon as it is retired, the GT wake time not only represents how long the
> device is powered up, but also provides a summary, albeit an overestimate,
> of the device runtime (i.e. the rc0 time to compare against rc6 time).
> 
> v2: s/busy/awake/
> v3: software-awake-time and I915_PMU_SOFTWARE_AWAKE_TIME

Last minute change to
__event(I915_PMU_SOFTWARE_GT_AWAKE_TIME, "software-gt-awake-time", "ns"),
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI] drm/i915/gt: Track the overall awake/busy time

2020-12-15 Thread Chris Wilson
Since we wake the GT up before executing a request, and go to sleep as
soon as it is retired, the GT wake time not only represents how long the
device is powered up, but also provides a summary, albeit an overestimate,
of the device runtime (i.e. the rc0 time to compare against rc6 time).

v2: s/busy/awake/
v3: software-awake-time and I915_PMU_SOFTWARE_AWAKE_TIME

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Cc: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/debugfs_gt_pm.c  |  5 ++-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c| 49 
 drivers/gpu/drm/i915/gt/intel_gt_pm.h|  2 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h | 24 
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++-
 drivers/gpu/drm/i915/i915_pmu.c  |  6 +++
 include/uapi/drm/i915_drm.h  |  1 +
 7 files changed, 89 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c 
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 174a24553322..8975717ace06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -11,6 +11,7 @@
 #include "i915_drv.h"
 #include "intel_gt.h"
 #include "intel_gt_clock_utils.h"
+#include "intel_gt_pm.h"
 #include "intel_llc.h"
 #include "intel_rc6.h"
 #include "intel_rps.h"
@@ -558,7 +559,9 @@ static int rps_boost_show(struct seq_file *m, void *data)
 
seq_printf(m, "RPS enabled? %s\n", yesno(intel_rps_is_enabled(rps)));
seq_printf(m, "RPS active? %s\n", yesno(intel_rps_is_active(rps)));
-   seq_printf(m, "GPU busy? %s\n", yesno(gt->awake));
+   seq_printf(m, "GPU busy? %s, %llums\n",
+  yesno(gt->awake),
+  ktime_to_ms(intel_gt_get_awake_time(gt)));
seq_printf(m, "Boosts outstanding? %d\n",
   atomic_read(>num_waiters));
seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->power.interactive));
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 274aa0dd7050..c94e8ac884eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -39,6 +39,28 @@ static void user_forcewake(struct intel_gt *gt, bool suspend)
intel_gt_pm_put(gt);
 }
 
+static void runtime_begin(struct intel_gt *gt)
+{
+   local_irq_disable();
+   write_seqcount_begin(>stats.lock);
+   gt->stats.start = ktime_get();
+   gt->stats.active = true;
+   write_seqcount_end(>stats.lock);
+   local_irq_enable();
+}
+
+static void runtime_end(struct intel_gt *gt)
+{
+   local_irq_disable();
+   write_seqcount_begin(>stats.lock);
+   gt->stats.active = false;
+   gt->stats.total =
+   ktime_add(gt->stats.total,
+ ktime_sub(ktime_get(), gt->stats.start));
+   write_seqcount_end(>stats.lock);
+   local_irq_enable();
+}
+
 static int __gt_unpark(struct intel_wakeref *wf)
 {
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -67,6 +89,7 @@ static int __gt_unpark(struct intel_wakeref *wf)
i915_pmu_gt_unparked(i915);
 
intel_gt_unpark_requests(gt);
+   runtime_begin(gt);
 
return 0;
 }
@@ -79,6 +102,7 @@ static int __gt_park(struct intel_wakeref *wf)
 
GT_TRACE(gt, "\n");
 
+   runtime_end(gt);
intel_gt_park_requests(gt);
 
i915_vma_parked(gt);
@@ -106,6 +130,7 @@ static const struct intel_wakeref_ops wf_ops = {
 void intel_gt_pm_init_early(struct intel_gt *gt)
 {
intel_wakeref_init(>wakeref, gt->uncore->rpm, _ops);
+   seqcount_mutex_init(>stats.lock, >wakeref.mutex);
 }
 
 void intel_gt_pm_init(struct intel_gt *gt)
@@ -339,6 +364,30 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
return intel_uc_runtime_resume(>uc);
 }
 
+static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
+{
+   ktime_t total = gt->stats.total;
+
+   if (gt->stats.active)
+   total = ktime_add(total,
+ ktime_sub(ktime_get(), gt->stats.start));
+
+   return total;
+}
+
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt)
+{
+   unsigned int seq;
+   ktime_t total;
+
+   do {
+   seq = read_seqcount_begin(>stats.lock);
+   total = __intel_gt_get_awake_time(gt);
+   } while (read_seqcount_retry(>stats.lock, seq));
+
+   return total;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftest_gt_pm.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 60f0e2fbe55c..63846a856e7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -58,6 +58,8 @@ int intel_gt_resume(struct intel_gt *gt);
 void intel_gt_runtime_suspend(struct intel_gt *gt);
 int intel_gt_runtime_resume(struct intel_gt *gt);
 
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt);
+
 static inline bool is_mock_gt(const struct 

Re: [Intel-gfx] [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format

2020-12-15 Thread Souza, Jose
On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/drm_rect.c | 15 +++
> >  include/drm/drm_rect.h |  2 ++
> >  2 files changed, 17 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index 0460e874896e..24345704b353 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> >     }
> >  }
> >  EXPORT_SYMBOL(drm_rect_rotate_inv);
> > +
> > +/**
> > + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed point 
> > form
> > + * to regular form.
> > + * @in: rect in 16.16 fixed point form
> > + * @out: rect to be stored the converted value
> > + */
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct 
> > drm_rect *out)
> > +{
> > +   out->x1 = in->x1 >> 16;
> > +   out->y1 = in->y1 >> 16;
> > +   out->x2 = in->x2 >> 16;
> > +   out->y2 = in->y2 >> 16;
> > +}
> 
> That's not the same as what we do in most places. We truncate
> the width/height, not x2/y2. Doing it on x2/y2 may increase
> the width/height.
> 
> So I suggest something more like:
> 
> static inline void drm_rect_fp_to_int(struct drm_rect *r)
> {
>   drm_rect_init(r, r->x1 >> 16, r->y1 >> 16,
> drm_rect_width(r) >> 16,
> drm_rect_height(r) >> 16);
> }
> 
> to match the current way of doing things.

Okay, but most use cases takes drm_plane_state.src and converts and sets it in 
another rect, so will modify it to have two parameters.


> 

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


[Intel-gfx] [CI] drm/i915/gem: Drop free_work for GEM contexts

2020-12-15 Thread Chris Wilson
The free_list and worker was introduced in commit 5f09a9c8ab6b ("drm/i915:
Allow contexts to be unreferenced locklessly"), but subsequently made
redundant by the removal of the last sleeping lock in commit 2935ed5339c4
("drm/i915: Remove logical HW ID"). As we can now free the GEM context
immediately from any context, remove the deferral of the free_list

v2: Lift removing the context from the global list into close().

Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 59 +++
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |  1 -
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  1 -
 drivers/gpu/drm/i915/i915_drv.h   |  3 -
 drivers/gpu/drm/i915/i915_gem.c   |  2 -
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  2 -
 6 files changed, 8 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ad136d009d9b..738a07b3583c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -334,13 +334,12 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
return e;
 }
 
-static void i915_gem_context_free(struct i915_gem_context *ctx)
+void i915_gem_context_release(struct kref *ref)
 {
-   GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+   struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
 
-   spin_lock(>i915->gem.contexts.lock);
-   list_del(>link);
-   spin_unlock(>i915->gem.contexts.lock);
+   trace_i915_context_free(ctx);
+   GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
 
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
@@ -354,37 +353,6 @@ static void i915_gem_context_free(struct i915_gem_context 
*ctx)
kfree_rcu(ctx, rcu);
 }
 
-static void contexts_free_all(struct llist_node *list)
-{
-   struct i915_gem_context *ctx, *cn;
-
-   llist_for_each_entry_safe(ctx, cn, list, free_link)
-   i915_gem_context_free(ctx);
-}
-
-static void contexts_flush_free(struct i915_gem_contexts *gc)
-{
-   contexts_free_all(llist_del_all(>free_list));
-}
-
-static void contexts_free_worker(struct work_struct *work)
-{
-   struct i915_gem_contexts *gc =
-   container_of(work, typeof(*gc), free_work);
-
-   contexts_flush_free(gc);
-}
-
-void i915_gem_context_release(struct kref *ref)
-{
-   struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
-   struct i915_gem_contexts *gc = >i915->gem.contexts;
-
-   trace_i915_context_free(ctx);
-   if (llist_add(>free_link, >free_list))
-   schedule_work(>free_work);
-}
-
 static inline struct i915_gem_engines *
 __context_engines_static(const struct i915_gem_context *ctx)
 {
@@ -633,6 +601,10 @@ static void context_close(struct i915_gem_context *ctx)
 */
lut_close(ctx);
 
+   spin_lock(>i915->gem.contexts.lock);
+   list_del(>link);
+   spin_unlock(>i915->gem.contexts.lock);
+
mutex_unlock(>mutex);
 
/*
@@ -850,9 +822,6 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
!HAS_EXECLISTS(i915))
return ERR_PTR(-EINVAL);
 
-   /* Reap the stale contexts */
-   contexts_flush_free(>gem.contexts);
-
ctx = __create_context(i915);
if (IS_ERR(ctx))
return ctx;
@@ -897,9 +866,6 @@ static void init_contexts(struct i915_gem_contexts *gc)
 {
spin_lock_init(>lock);
INIT_LIST_HEAD(>list);
-
-   INIT_WORK(>free_work, contexts_free_worker);
-   init_llist_head(>free_list);
 }
 
 void i915_gem_init__contexts(struct drm_i915_private *i915)
@@ -907,12 +873,6 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
init_contexts(>gem.contexts);
 }
 
-void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
-{
-   flush_work(>gem.contexts.free_work);
-   rcu_barrier(); /* and flush the left over RCU frees */
-}
-
 static int gem_context_register(struct i915_gem_context *ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
@@ -986,7 +946,6 @@ int i915_gem_context_open(struct drm_i915_private *i915,
 void i915_gem_context_close(struct drm_file *file)
 {
struct drm_i915_file_private *file_priv = file->driver_priv;
-   struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_address_space *vm;
struct i915_gem_context *ctx;
unsigned long idx;
@@ -998,8 +957,6 @@ void i915_gem_context_close(struct drm_file *file)
xa_for_each(_priv->vm_xa, idx, vm)
i915_vm_put(vm);
xa_destroy(_priv->vm_xa);
-
-   contexts_flush_free(>gem.contexts);
 }
 
 int i915_gem_vm_create_ioctl(struct drm_device 

Re: [Intel-gfx] [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format

2020-12-15 Thread Ville Syrjälä
On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> Much more clear to read one function call than four lines doing this
> conversion.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_rect.c | 15 +++
>  include/drm/drm_rect.h |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index 0460e874896e..24345704b353 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>   }
>  }
>  EXPORT_SYMBOL(drm_rect_rotate_inv);
> +
> +/**
> + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed point 
> form
> + * to regular form.
> + * @in: rect in 16.16 fixed point form
> + * @out: rect to be stored the converted value
> + */
> +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct drm_rect 
> *out)
> +{
> + out->x1 = in->x1 >> 16;
> + out->y1 = in->y1 >> 16;
> + out->x2 = in->x2 >> 16;
> + out->y2 = in->y2 >> 16;
> +}

That's not the same as what we do in most places. We truncate
the width/height, not x2/y2. Doing it on x2/y2 may increase
the width/height.

So I suggest something more like:

static inline void drm_rect_fp_to_int(struct drm_rect *r)
{
drm_rect_init(r, r->x1 >> 16, r->y1 >> 16,
  drm_rect_width(r) >> 16,
  drm_rect_height(r) >> 16);
}

to match the current way of doing things.

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


[Intel-gfx] [PATCH] drm/i915: remove h from printk format specifier

2020-12-15 Thread trix
From: Tom Rix 

See Documentation/core-api/printk-formats.rst.
h should no longer be used in the format specifier for printk.

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

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 8a72e0fe34ca..80be9e818a6b 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -755,7 +755,7 @@ void intel_sseu_print_topology(const struct sseu_dev_info 
*sseu,
for (ss = 0; ss < sseu->max_subslices; ss++) {
u16 enabled_eus = sseu_get_eus(sseu, s, ss);
 
-   drm_printf(p, "\tsubslice%d: %u EUs (0x%hx)\n",
+   drm_printf(p, "\tsubslice%d: %u EUs (0x%x)\n",
   ss, hweight16(enabled_eus), enabled_eus);
}
}
-- 
2.27.0

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for doc: Fix build of documentation after i915 file rename

2020-12-15 Thread Souza, Jose
On Mon, 2020-12-14 at 19:42 +, Patchwork wrote:
Patch Details
Series: doc: Fix build of documentation after i915 file rename
URL:https://patchwork.freedesktop.org/series/84914/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19140/index.html
CI Bug Log - changes from CI_DRM_9481 -> Patchwork_19140
Summary

FAILURE

Serious unknown changes coming with Patchwork_19140 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19140, 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_19140/index.html

Possible new issues

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

IGT changes
Possible regressions

  *   igt@i915_selftest@live@memory_region:
 *   fi-cfl-8109u: 
PASS
 -> 
DMESG-WARN
 +12 similar issues

This is a documentation fix, it will not affect any test.
Pushed to drm-intel-gt-next, thanks for the review Chris.

Known issues

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

IGT changes
Issues hit

  *   igt@core_hotunplug@unbind-rebind:

 *   fi-kbl-7500u: 
PASS
 -> 
DMESG-WARN
 (i915#2605)
  *   igt@i915_selftest@live@coherency:

 *   fi-gdg-551: 
PASS
 -> 
DMESG-FAIL
 (i915#1748)
  *   igt@i915_selftest@live@execlists:

 *   fi-cfl-8109u: 
PASS
 -> 
DMESG-WARN
 (i915#1037)
  *   igt@prime_vgem@basic-userptr:

 *   fi-tgl-y: 
PASS
 -> 
DMESG-WARN
 (i915#402) +1 similar 
issue

Possible fixes

  *   igt@prime_self_import@basic-with_one_bo_two_files:
 *   fi-tgl-y: 
DMESG-WARN
 (i915#402) -> 
PASS

Participating hosts (44 -> 39)

Missing (5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus

Build changes

  *   Linux: CI_DRM_9481 -> Patchwork_19140

CI-20190529: 20190529
CI_DRM_9481: 968d6b8835487575d68732a7c0a1588795900de4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5893: ec4073d30b428aaf199c0f4de6c0a5ebdc1c1c65 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19140: 5d11f6b95eb18bc1c213b4b6e675aad0e08327a6 @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Linux commits ==

5d11f6b95eb1 doc: Fix build of documentation after i915 file rename

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


Re: [Intel-gfx] [PATCH 1/4] dma-buf: Remove kmap kerneldoc vestiges

2020-12-15 Thread Christian König

Am 14.12.20 um 17:01 schrieb Daniel Vetter:

On Mon, Dec 14, 2020 at 11:33:10AM +0100, Christian König wrote:

Am 11.12.20 um 16:58 schrieb Daniel Vetter:

Also try to clarify a bit when dma_buf_begin/end_cpu_access should
be called.

Signed-off-by: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
   drivers/dma-buf/dma-buf.c | 20 ++--
   include/linux/dma-buf.h   | 25 +
   2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e63684d4cd90..a12fdffa130f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1001,15 +1001,15 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify);
*   vmalloc space might be limited and result in vmap calls failing.
*
*   Interfaces::
+ *
*  void \*dma_buf_vmap(struct dma_buf \*dmabuf)
*  void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr)
*
*   The vmap call can fail if there is no vmap support in the exporter, or 
if
- *   it runs out of vmalloc space. Fallback to kmap should be implemented. Note
- *   that the dma-buf layer keeps a reference count for all vmap access and
- *   calls down into the exporter's vmap function only when no vmapping exists,
- *   and only unmaps it once. Protection against concurrent vmap/vunmap calls 
is
- *   provided by taking the dma_buf->lock mutex.
+ *   it runs out of vmalloc space. Note that the dma-buf layer keeps a 
reference
+ *   count for all vmap access and calls down into the exporter's vmap function
+ *   only when no vmapping exists, and only unmaps it once. Protection against
+ *   concurrent vmap/vunmap calls is provided by taking the _buf.lock 
mutex.

Who is talking the lock? The caller of the dma_buf_vmap/vunmap() functions,
the functions itself or the callback inside the exporter?

That's the part I didn't change at all here, just re-laid out the line
breaking. I only removed the outdated kmap section here.


I just wanted to point out that this still isn't described here very very.



Should I do another patch and remove this one sentence here (it's kinda
pointless and generally we don't muse about implementation details that
callers don't care about)?


Na, works like this for me.


I did try and do a cursory review of the dma-buf docs, but this is kinda
not meant as an all-out revamp. Just a few things I've noticed while
reviewing Thomas' vmap_local stuff.



Fell free to add an Acked-by: Christian König  
to the series.


Christian.


-Daniel


Christian.


*
* - For full compatibility on the importer side with existing userspace
*   interfaces, which might already support mmap'ing buffers. This is 
needed in
@@ -1098,6 +1098,11 @@ static int __dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
* dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls 
is
* it guaranteed to be coherent with other DMA access.
*
+ * This function will also wait for any DMA transactions tracked through
+ * implicit synchronization in _buf.resv. For DMA transactions with 
explicit
+ * synchronization this function will only ensure cache coherency, callers must
+ * ensure synchronization with such DMA transactions on their own.
+ *
* Can return negative error values, returns 0 on success.
*/
   int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -1199,7 +1204,10 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
- * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * To ensure coherency users must call dma_buf_begin_cpu_access() and
+ * dma_buf_end_cpu_access() around any cpu access performed through this
+ * mapping.
*
* Returns 0 on success, or a negative errno code otherwise.
*/
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cf72699cb2bc..7eca37c8b10c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -183,24 +183,19 @@ struct dma_buf_ops {
 * @begin_cpu_access:
 *
 * This is called from dma_buf_begin_cpu_access() and allows the
-* exporter to ensure that the memory is actually available for cpu
-* access - the exporter might need to allocate or swap-in and pin the
-* backing storage. The exporter also needs to ensure that cpu access is
-* coherent for the access direction. The direction can be used by the
-* exporter to optimize the cache flushing, i.e. access with a different
+* exporter to ensure that the memory is actually coherent for cpu
+* access. The exporter also needs to ensure that cpu access is coherent
+* for the access direction. The direction can be 

Re: [Intel-gfx] [PATCH] dma-buf: begin/end_cpu might lock the dma_resv lock

2020-12-15 Thread Christian König

Am 14.12.20 um 18:16 schrieb Daniel Vetter:

At least amdgpu and i915 do, so lets just document this as the rule.

v2: Works better with less typos (intel-gfx-ci)

Signed-off-by: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e1fa6c6f02c4..a0a02ef888da 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1118,6 +1118,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
if (WARN_ON(!dmabuf))
return -EINVAL;
  
+	might_lock(>resv->lock.base);

+
if (dmabuf->ops->begin_cpu_access)
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
  
@@ -1151,6 +1153,8 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
  
  	WARN_ON(!dmabuf);
  
+	might_lock(>resv->lock.base);

+
if (dmabuf->ops->end_cpu_access)
ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
  


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


[Intel-gfx] [RFC] drm/i915/backlight: RFC cache backlight power state

2020-12-15 Thread Anshuman Gupta
This is RFC proposal to cache the backlight power state in order
to avoid accessing pps register every time while brightness or bl_power
attributes of class intel_backlight is being changed.

Signed-off-by: Anshuman Gupta 
---
 .../gpu/drm/i915/display/intel_display_types.h |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c| 18 ++
 drivers/gpu/drm/i915/display/intel_panel.c |  8 +++-
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..7c12b66c11af 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -263,6 +263,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   bool bl_powered;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2bc0c8c39c7..73536e377c20 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3398,6 +3398,8 @@ void intel_edp_backlight_on(const struct intel_crtc_state 
*crtc_state,
const struct drm_connector_state *conn_state)
 {
struct intel_dp *intel_dp = 
enc_to_intel_dp(to_intel_encoder(conn_state->best_encoder));
+   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
+   struct intel_panel *panel = >panel;
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
if (!intel_dp_is_edp(intel_dp))
@@ -3407,6 +3409,9 @@ void intel_edp_backlight_on(const struct intel_crtc_state 
*crtc_state,
 
intel_panel_enable_backlight(crtc_state, conn_state);
_intel_edp_backlight_on(intel_dp);
+   mutex_lock(>backlight_lock);
+   panel->backlight.bl_powered = true;
+   mutex_unlock(>backlight_lock);
 }
 
 /* Disable backlight in the panel power control. */
@@ -3437,6 +3442,8 @@ static void _intel_edp_backlight_off(struct intel_dp 
*intel_dp)
 void intel_edp_backlight_off(const struct drm_connector_state *old_conn_state)
 {
struct intel_dp *intel_dp = 
enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder));
+   struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
+   struct intel_panel *panel = >panel;
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
if (!intel_dp_is_edp(intel_dp))
@@ -3445,6 +3452,9 @@ void intel_edp_backlight_off(const struct 
drm_connector_state *old_conn_state)
drm_dbg_kms(>drm, "\n");
 
_intel_edp_backlight_off(intel_dp);
+   mutex_lock(>backlight_lock);
+   panel->backlight.bl_powered = false;
+   mutex_unlock(>backlight_lock);
intel_panel_disable_backlight(old_conn_state);
 }
 
@@ -3457,14 +3467,6 @@ static void intel_edp_backlight_power(struct 
intel_connector *connector,
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(connector);
-   intel_wakeref_t wakeref;
-   bool is_enabled;
-
-   is_enabled = false;
-   with_pps_lock(intel_dp, wakeref)
-   is_enabled = ilk_get_pp_control(intel_dp) & EDP_BLC_ENABLE;
-   if (is_enabled == enable)
-   return;
 
drm_dbg_kms(>drm, "panel power control backlight %s\n",
enable ? "enable" : "disable");
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 36b7693453ae..9f81edf25475 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1282,6 +1282,7 @@ static void intel_panel_set_backlight(const struct 
drm_connector_state *conn_sta
 static int intel_backlight_device_update_status(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
struct drm_device *dev = connector->base.dev;
 
@@ -1301,7 +1302,12 @@ static int intel_backlight_device_update_status(struct 
backlight_device *bd)
if (panel->backlight.power) {
bool enable = bd->props.power == FB_BLANK_UNBLANK &&
bd->props.brightness != 0;
-   panel->backlight.power(connector, enable);
+   mutex_lock(_priv->backlight_lock);
+   if (enable != panel->backlight.bl_powered) {
+   panel->backlight.power(connector, enable);
+   panel->backlight.bl_powered = enable;
+   }
+   mutex_unlock(_priv->backlight_lock);

Re: [Intel-gfx] [PATCH 14/69] drm/i915/gt: Track the overall awake/busy time

2020-12-15 Thread Tvrtko Ursulin



On 14/12/2020 10:08, Chris Wilson wrote:

Since we wake the GT up before executing a request, and go to sleep as
soon as it is retired, the GT wake time not only represents how long the
device is powered up, but also provides a summary, albeit an overestimate,
of the device runtime (i.e. the rc0 time to compare against rc6 time).

v2: s/busy/awake/

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gt/debugfs_gt_pm.c  |  5 ++-
  drivers/gpu/drm/i915/gt/intel_gt_pm.c| 49 
  drivers/gpu/drm/i915/gt/intel_gt_pm.h|  2 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h | 24 
  drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++-
  drivers/gpu/drm/i915/i915_pmu.c  |  6 +++
  include/uapi/drm/i915_drm.h  |  1 +
  7 files changed, 89 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c 
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 174a24553322..8975717ace06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -11,6 +11,7 @@
  #include "i915_drv.h"
  #include "intel_gt.h"
  #include "intel_gt_clock_utils.h"
+#include "intel_gt_pm.h"
  #include "intel_llc.h"
  #include "intel_rc6.h"
  #include "intel_rps.h"
@@ -558,7 +559,9 @@ static int rps_boost_show(struct seq_file *m, void *data)
  
  	seq_printf(m, "RPS enabled? %s\n", yesno(intel_rps_is_enabled(rps)));

seq_printf(m, "RPS active? %s\n", yesno(intel_rps_is_active(rps)));
-   seq_printf(m, "GPU busy? %s\n", yesno(gt->awake));
+   seq_printf(m, "GPU busy? %s, %llums\n",
+  yesno(gt->awake),
+  ktime_to_ms(intel_gt_get_awake_time(gt)));
seq_printf(m, "Boosts outstanding? %d\n",
   atomic_read(>num_waiters));
seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->power.interactive));
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 274aa0dd7050..c94e8ac884eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -39,6 +39,28 @@ static void user_forcewake(struct intel_gt *gt, bool suspend)
intel_gt_pm_put(gt);
  }
  
+static void runtime_begin(struct intel_gt *gt)

+{
+   local_irq_disable();
+   write_seqcount_begin(>stats.lock);
+   gt->stats.start = ktime_get();
+   gt->stats.active = true;
+   write_seqcount_end(>stats.lock);
+   local_irq_enable();
+}
+
+static void runtime_end(struct intel_gt *gt)
+{
+   local_irq_disable();
+   write_seqcount_begin(>stats.lock);
+   gt->stats.active = false;
+   gt->stats.total =
+   ktime_add(gt->stats.total,
+ ktime_sub(ktime_get(), gt->stats.start));
+   write_seqcount_end(>stats.lock);
+   local_irq_enable();
+}
+
  static int __gt_unpark(struct intel_wakeref *wf)
  {
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -67,6 +89,7 @@ static int __gt_unpark(struct intel_wakeref *wf)
i915_pmu_gt_unparked(i915);
  
  	intel_gt_unpark_requests(gt);

+   runtime_begin(gt);
  
  	return 0;

  }
@@ -79,6 +102,7 @@ static int __gt_park(struct intel_wakeref *wf)
  
  	GT_TRACE(gt, "\n");
  
+	runtime_end(gt);

intel_gt_park_requests(gt);
  
  	i915_vma_parked(gt);

@@ -106,6 +130,7 @@ static const struct intel_wakeref_ops wf_ops = {
  void intel_gt_pm_init_early(struct intel_gt *gt)
  {
intel_wakeref_init(>wakeref, gt->uncore->rpm, _ops);
+   seqcount_mutex_init(>stats.lock, >wakeref.mutex);
  }
  
  void intel_gt_pm_init(struct intel_gt *gt)

@@ -339,6 +364,30 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
return intel_uc_runtime_resume(>uc);
  }
  
+static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)

+{
+   ktime_t total = gt->stats.total;
+
+   if (gt->stats.active)
+   total = ktime_add(total,
+ ktime_sub(ktime_get(), gt->stats.start));
+
+   return total;
+}
+
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt)
+{
+   unsigned int seq;
+   ktime_t total;
+
+   do {
+   seq = read_seqcount_begin(>stats.lock);
+   total = __intel_gt_get_awake_time(gt);
+   } while (read_seqcount_retry(>stats.lock, seq));
+
+   return total;
+}
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftest_gt_pm.c"
  #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 60f0e2fbe55c..63846a856e7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -58,6 +58,8 @@ int intel_gt_resume(struct intel_gt *gt);
  void intel_gt_runtime_suspend(struct intel_gt *gt);
  int intel_gt_runtime_resume(struct intel_gt *gt);
  
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt);

+
  static inline bool is_mock_gt(const struct intel_gt *gt)
  {
return 

Re: [Intel-gfx] [PATCH] doc: Fix build of documentation after i915 file rename

2020-12-15 Thread Chris Wilson
Quoting José Roberto de Souza (2020-12-14 18:54:40)
> Commit 70a2b431c364 ("drm/i915/gt: Rename lrc.c to
> execlists_submission.c") renamed intel_lrc.c to
> intel_execlists_submission.c but forgot to update i915.rst.
> 
> Fixes: 70a2b431c364 ("drm/i915/gt: Rename lrc.c to execlists_submission.c")
> Cc: Chris Wilson 
> Signed-off-by: José Roberto de Souza 
> ---
>  Documentation/gpu/i915.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 20868f3d0123..486c720f3890 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -428,7 +428,7 @@ User Batchbuffer Execution
>  Logical Rings, Logical Ring Contexts and Execlists
>  --
>  
> -.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists

It's no longer apropos to intel_execlists_submission.c, but nevertheless
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format

2020-12-15 Thread Souza, Jose
On Tue, 2020-12-15 at 12:52 +, Mun, Gwan-gyeong wrote:
> On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/drm_rect.c | 15 +++
> >  include/drm/drm_rect.h |  2 ++
> >  2 files changed, 17 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index 0460e874896e..24345704b353 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> >     }
> >  }
> >  EXPORT_SYMBOL(drm_rect_rotate_inv);
> > +
> > +/**
> > + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed
> > point form
> > + * to regular form.
> > + * @in: rect in 16.16 fixed point form
> > + * @out: rect to be stored the converted value
> > + */
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct
> > drm_rect *out)
> > +{
> > +   out->x1 = in->x1 >> 16;
> > +   out->y1 = in->y1 >> 16;
> > +   out->x2 = in->x2 >> 16;
> > +   out->y2 = in->y2 >> 16;
> > +}
> > +EXPORT_SYMBOL(drm_rect_convert_16_16_to_regular);
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > index e7f4d24cdd00..2ef8180416cd 100644
> > --- a/include/drm/drm_rect.h
> > +++ b/include/drm/drm_rect.h
> > @@ -223,5 +223,7 @@ void drm_rect_rotate(struct drm_rect *r,
> >  void drm_rect_rotate_inv(struct drm_rect *r,
> >  int width, int height,
> >  unsigned int rotation);
> > +void drm_rect_convert_16_16_to_regular(struct drm_rect *in,
> > +  struct drm_rect *out);
> > 
> Hi,
> if it's purpose is just converting 16.16 fp to integer, how about you
> have function prototype like this?
> extern inline struct drm_rect
> drm_rect_convert_16_16_fp_to_integer(struct drm_rect in)

I prefer have a function call as this can be reused in several places, so the 
binaries size can decrease a bit.
Also pointers are better, compiler can decide to not inline the function above 
and it would need to allocate in stack 2 drm_rects for every call.

> 
> And if there are no use case on drm core or other drivers except i915
> display yet,
> before adding this function to drm core, how about you add this
> function code to i915 first?

There is plenty of users in other drivers, just not doing in this series.

> 
> Br,
> G.G.
> >  #endif

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


Re: [Intel-gfx] [PATCH v6 2/5] drm/i915/display/psr: Use plane damage clips to calculate damaged area

2020-12-15 Thread Souza, Jose
On Tue, 2020-12-15 at 13:02 +, Mun, Gwan-gyeong wrote:
> On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> > Now using plane damage clips property to calcualte the damaged area.
> > Selective fetch only supports one region to be fetched so software
> > needs to calculate a bounding box around all damage clips.
> > 
> > Now that we are not complete fetching each plane, there is another
> > loop needed as all the plane areas that intersect with the pipe
> > damaged area needs to be fetched from memory so the complete blending
> > of all planes can happen.
> > 
> Hi,
> > v2:
> > - do not shifthing new_plane_state->uapi.dst only src is in 16.16 
> Typo on commit message. shifthing -> shifting
> > format
> > 
> > v4:
> > - setting plane selective fetch area using the whole pipe damage area
> > - mark the whole plane area damaged if plane visibility or alpha
> > changed
> > 
> > v5:
> > - taking in consideration src.y1 in the damage coordinates
> > - adding to the pipe damaged area planes that were visible but are
> > invisible in the new state
> > 
> > v6:
> > - consider old state plane coordinates when visibility changes or it
> > moved to calculate damaged area
> > - remove from damaged area the portion not in src clip
> > 
> > Cc: Ville Syrjälä 
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 98 +-
> > --
> >  1 file changed, 86 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index d9a395c486d3..7daed098fa74 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1269,8 +1269,8 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> >     struct intel_crtc *crtc)
> >  {
> >     struct intel_crtc_state *crtc_state =
> > intel_atomic_get_new_crtc_state(state, crtc);
> > +   struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX,
> > .y2 = -1 };
> >     struct intel_plane_state *new_plane_state, *old_plane_state;
> > -   struct drm_rect pipe_clip = { .y1 = -1 };
> >     struct intel_plane *plane;
> >     bool full_update = false;
> >     int i, ret;
> > @@ -1282,9 +1282,17 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> >     if (ret)
> >     return ret;
> >  
> > 
> > 
> > 
> > +   /*
> > +* Calculate minimal selective fetch area of each plane and
> > calculate
> > +* the pipe damaged area.
> > +* In the next loop the plane selective fetch area will
> > actually be set
> > +* using whole pipe damaged area.
> > +*/
> >     for_each_oldnew_intel_plane_in_state(state, plane,
> > old_plane_state,
> >  new_plane_state, i) {
> > -   struct drm_rect *sel_fetch_area, temp;
> > +   struct drm_rect src, damaged_area = { .x1 = 0, .y1 =
> > -1, .x2 = INT_MAX, .y2 = -1 };
> > +   struct drm_mode_rect *damaged_clips;
> > +   u32 num_clips, j;
> >  
> > 
> > 
> > 
> >     if (new_plane_state->uapi.crtc != crtc_state-
> > > uapi.crtc)
> >     continue;
> > @@ -1300,23 +1308,89 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> >     break;
> >     }
> >  
> > 
> > 
> > 
> > -   if (!new_plane_state->uapi.visible)
> > -   continue;
> > +   drm_rect_convert_16_16_to_regular(_plane_state-
> > > uapi.src, );
> > +   damaged_clips =
> > drm_plane_get_damage_clips(_plane_state->uapi);
> > +   num_clips =
> > drm_plane_get_damage_clips_count(_plane_state->uapi);
> >  
> > 
> > 
> > 
> >     /*
> > -* For now doing a selective fetch in the whole plane
> > area,
> > -* optimizations will come in the future.
> > +* If visibility or plane moved, mark the whole plane
> > area as
> > +* damaged as it needs to be complete redraw in the new
> > and old
> > +* position.
> >  */
> > +   if (new_plane_state->uapi.visible != old_plane_state-
> > > uapi.visible ||
> > +   !drm_rect_equals(_plane_state->uapi.dst,
> > +_plane_state->uapi.dst)) {
> > +   damaged_area.y1 = old_plane_state->uapi.src.y1
> > > > 16;
> > +   damaged_area.y1 = old_plane_state->uapi.src.y2
> > > > 16;
> > +   damaged_area.y1 += old_plane_state-
> > > uapi.dst.y1;
> > +   damaged_area.y2 += old_plane_state-
> > > uapi.dst.y1;
> > +   clip_area_update(_clip, _area);
> > +
> > +   num_clips = 0;
> > +   damaged_area.y1 = src.y1;
> > +   damaged_area.y2 = src.y2;
> 1. Visibility change case
>  The pipe damaged area (The Selective Update region) needs to
> 

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

2020-12-15 Thread Thomas Zimmermann
Hi Dave and Daniel,

here's this week's PR for drm-misc-next-fixes. IIRC the radeon fix is
already in drm-misc-next.

Best regards
Thomas

drm-misc-next-fixes-2020-12-15:
Short summary of fixes pull (less than what git shortlog provides):

 * dma-buf: Fix docs
 * mxsfb: Silence invalid error message
 * radeon: Fix TTM multihop

The following changes since commit 05faf1559de52465f1e753e31883aa294e6179c1:

  drm/imx/dcss: allow using nearest neighbor interpolation scaling (2020-11-26 
11:29:44 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-12-15

for you to fetch changes up to ee46d16d2e40bebc2aa790fd7b6a056466ff895c:

  drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge (2020-12-15 
11:01:10 +0100)


Short summary of fixes pull (less than what git shortlog provides):

 * dma-buf: Fix docs
 * mxsfb: Silence invalid error message
 * radeon: Fix TTM multihop


Christian König (1):
  drm/radeon: fix check order in radeon_bo_move

Daniel Vetter (1):
  dma-buf: Fix kerneldoc formatting

Guido Günther (1):
  drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge

 Documentation/driver-api/dma-buf.rst |  2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c| 10 +++
 drivers/gpu/drm/radeon/radeon_ttm.c  | 54 
 include/linux/dma-buf-map.h  |  2 +-
 4 files changed, 30 insertions(+), 38 deletions(-)

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v6 2/5] drm/i915/display/psr: Use plane damage clips to calculate damaged area

2020-12-15 Thread Mun, Gwan-gyeong
On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> Now using plane damage clips property to calcualte the damaged area.
> Selective fetch only supports one region to be fetched so software
> needs to calculate a bounding box around all damage clips.
> 
> Now that we are not complete fetching each plane, there is another
> loop needed as all the plane areas that intersect with the pipe
> damaged area needs to be fetched from memory so the complete blending
> of all planes can happen.
> 
Hi,
> v2:
> - do not shifthing new_plane_state->uapi.dst only src is in 16.16 
Typo on commit message. shifthing -> shifting
> format
> 
> v4:
> - setting plane selective fetch area using the whole pipe damage area
> - mark the whole plane area damaged if plane visibility or alpha
> changed
> 
> v5:
> - taking in consideration src.y1 in the damage coordinates
> - adding to the pipe damaged area planes that were visible but are
> invisible in the new state
> 
> v6:
> - consider old state plane coordinates when visibility changes or it
> moved to calculate damaged area
> - remove from damaged area the portion not in src clip
> 
> Cc: Ville Syrjälä 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 98 +-
> --
>  1 file changed, 86 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index d9a395c486d3..7daed098fa74 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1269,8 +1269,8 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
>   struct intel_crtc_state *crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> + struct drm_rect pipe_clip = { .x1 = 0, .y1 = -1, .x2 = INT_MAX,
> .y2 = -1 };
>   struct intel_plane_state *new_plane_state, *old_plane_state;
> - struct drm_rect pipe_clip = { .y1 = -1 };
>   struct intel_plane *plane;
>   bool full_update = false;
>   int i, ret;
> @@ -1282,9 +1282,17 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>   if (ret)
>   return ret;
>  
> + /*
> +  * Calculate minimal selective fetch area of each plane and
> calculate
> +  * the pipe damaged area.
> +  * In the next loop the plane selective fetch area will
> actually be set
> +  * using whole pipe damaged area.
> +  */
>   for_each_oldnew_intel_plane_in_state(state, plane,
> old_plane_state,
>new_plane_state, i) {
> - struct drm_rect *sel_fetch_area, temp;
> + struct drm_rect src, damaged_area = { .x1 = 0, .y1 =
> -1, .x2 = INT_MAX, .y2 = -1 };
> + struct drm_mode_rect *damaged_clips;
> + u32 num_clips, j;
>  
>   if (new_plane_state->uapi.crtc != crtc_state-
> >uapi.crtc)
>   continue;
> @@ -1300,23 +1308,89 @@ int intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>   break;
>   }
>  
> - if (!new_plane_state->uapi.visible)
> - continue;
> + drm_rect_convert_16_16_to_regular(_plane_state-
> >uapi.src, );
> + damaged_clips =
> drm_plane_get_damage_clips(_plane_state->uapi);
> + num_clips =
> drm_plane_get_damage_clips_count(_plane_state->uapi);
>  
>   /*
> -  * For now doing a selective fetch in the whole plane
> area,
> -  * optimizations will come in the future.
> +  * If visibility or plane moved, mark the whole plane
> area as
> +  * damaged as it needs to be complete redraw in the new
> and old
> +  * position.
>*/
> + if (new_plane_state->uapi.visible != old_plane_state-
> >uapi.visible ||
> + !drm_rect_equals(_plane_state->uapi.dst,
> +  _plane_state->uapi.dst)) {
> + damaged_area.y1 = old_plane_state->uapi.src.y1
> >> 16;
> + damaged_area.y1 = old_plane_state->uapi.src.y2
> >> 16;
> + damaged_area.y1 += old_plane_state-
> >uapi.dst.y1;
> + damaged_area.y2 += old_plane_state-
> >uapi.dst.y1;
> + clip_area_update(_clip, _area);
> +
> + num_clips = 0;
> + damaged_area.y1 = src.y1;
> + damaged_area.y2 = src.y2;
1. Visibility change case
 The pipe damaged area (The Selective Update region) needs to
accumulate being visible plane's dst between old and new plane's dst.

if you are implementing this scenario, the code shoule be like this,

if (new_plane_state->uapi.visible != old_plane_state->uapi.visible) {
   if (new_plane_state->uapi.visible) {
  damaged_area.y1 = 

Re: [Intel-gfx] [PATCH v6 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format

2020-12-15 Thread Mun, Gwan-gyeong
On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> Much more clear to read one function call than four lines doing this
> conversion.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_rect.c | 15 +++
>  include/drm/drm_rect.h |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index 0460e874896e..24345704b353 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -373,3 +373,18 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>   }
>  }
>  EXPORT_SYMBOL(drm_rect_rotate_inv);
> +
> +/**
> + * drm_rect_convert_16_16_to_regular - Convert a rect in 16.16 fixed
> point form
> + * to regular form.
> + * @in: rect in 16.16 fixed point form
> + * @out: rect to be stored the converted value
> + */
> +void drm_rect_convert_16_16_to_regular(struct drm_rect *in, struct
> drm_rect *out)
> +{
> + out->x1 = in->x1 >> 16;
> + out->y1 = in->y1 >> 16;
> + out->x2 = in->x2 >> 16;
> + out->y2 = in->y2 >> 16;
> +}
> +EXPORT_SYMBOL(drm_rect_convert_16_16_to_regular);
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index e7f4d24cdd00..2ef8180416cd 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -223,5 +223,7 @@ void drm_rect_rotate(struct drm_rect *r,
>  void drm_rect_rotate_inv(struct drm_rect *r,
>int width, int height,
>unsigned int rotation);
> +void drm_rect_convert_16_16_to_regular(struct drm_rect *in,
> +struct drm_rect *out);
> 
Hi,
if it's purpose is just converting 16.16 fp to integer, how about you
have function prototype like this?
extern inline struct drm_rect
drm_rect_convert_16_16_fp_to_integer(struct drm_rect in)

And if there are no use case on drm core or other drivers except i915
display yet,
before adding this function to drm core, how about you add this
function code to i915 first?

Br,
G.G.
>  #endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for Multi DSB instance support

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

Series: Multi DSB instance support
URL   : https://patchwork.freedesktop.org/series/84934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9482_full -> Patchwork_19143_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@hang:
- shard-hsw:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-hsw7/igt@gem_ctx_persiste...@hang.html

  * igt@gem_exec_params@no-vebox:
- shard-skl:  NOTRUN -> [SKIP][2] ([fdo#109271]) +94 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl5/igt@gem_exec_par...@no-vebox.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][3] ([i915#2389])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-forked:
- shard-glk:  [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/shard-glk3/igt@gem_exec_whis...@basic-forked.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-glk2/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_userptr_blits@process-exit-mmap-busy@uc:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl10/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][7] ([i915#454])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl10/igt@i915_pm...@dc6-dpms.html

  * igt@kms_ccs@pipe-c-bad-aux-stride:
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111304]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl8/igt@kms_...@pipe-c-bad-aux-stride.html

  * igt@kms_chamelium@vga-hpd:
- shard-skl:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl5/igt@kms_chamel...@vga-hpd.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-75:
- shard-hsw:  NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-hsw7/igt@kms_color_chamel...@pipe-d-ctm-0-75.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][11] ([i915#54])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-random:
- shard-skl:  [PASS][12] -> [FAIL][13] ([i915#54])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][14] -> [INCOMPLETE][15] ([i915#300])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-d-cursor-128x42-random:
- shard-hsw:  NOTRUN -> [SKIP][16] ([fdo#109271]) +50 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-hsw7/igt@kms_cursor_...@pipe-d-cursor-128x42-random.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#79])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/shard-kbl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-kbl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2672])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/shard-skl5/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html

  * igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-c:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#1036])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/shard-skl8/igt@kms_pipe_crc_ba...@disable-crc-after-crtc-pipe-c.html
   [21]: 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Measure timeslice distribution when oversaturated

2020-12-15 Thread Tvrtko Ursulin



On 15/12/2020 09:47, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-12-15 09:41:09)


On 14/12/2020 20:44, Chris Wilson wrote:

Check that timeslices for an oversaturated system (where there is more
work than can be supported by a single engine) are evenly distributed
between the clients.

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

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f23d63ac3..263f1dd78 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2516,6 +2516,154 @@ static void measure_semaphore_power(int i915)
   rapl_close();
   }
   
+static int read_timestamp_frequency(int i915)

+{
+ int value = 0;
+ drm_i915_getparam_t gp = {
+ .value = ,
+ .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+ };
+ ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+ return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+ return (x + y - 1) / y;
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+ return div64_u64_round_up(ticks * NSEC_PER_SEC,
+   read_timestamp_frequency(i915));
+}
+
+static int cmp_u32(const void *A, const void *B)
+{
+ const uint32_t *a = A, *b = B;
+
+ if (*a < *b)
+ return -1;
+ else if (*a > *b)
+ return 1;
+ else
+ return 0;
+}
+
+static uint32_t read_ctx_timestamp(int i915,
+uint32_t ctx,
+const struct intel_execution_engine2 *e)
+{
+ const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+ const uint32_t base = gem_engine_mmio_base(i915, e->name);
+ struct drm_i915_gem_relocation_entry reloc;
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(i915, 4096),
+ .offset = 32 << 20,
+ .relocs_ptr = to_user_pointer(),
+ .relocation_count = 1,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .flags = e->flags,
+ .rsvd1 = ctx,
+ };
+#define RUNTIME (base + 0x3a8)
+ uint32_t *map, *cs;
+ uint32_t ts;
+
+ igt_require(base);
+
+ cs = map = gem_mmap__device_coherent(i915, obj.handle,
+  0, 4096, PROT_WRITE);
+
+ *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+ *cs++ = RUNTIME;
+ memset(, 0, sizeof(reloc));
+ reloc.target_handle = obj.handle;
+ reloc.presumed_offset = obj.offset;
+ reloc.offset = offset_in_page(cs);
+ reloc.delta = 4000;
+ *cs++ = obj.offset + 4000;
+ *cs++ = obj.offset >> 32;
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ gem_execbuf(i915, );
+ gem_sync(i915, obj.handle);
+ gem_close(i915, obj.handle);
+
+ ts = map[1000];
+ munmap(map, 4096);
+
+ return ts;
+}
+
+static void fairslice(int i915,
+   const struct intel_execution_engine2 *e,
+   unsigned long flags,
+   int duration)
+{
+ const double timeslice_duration_ns = 1e6;
+ igt_spin_t *spin = NULL;
+ double threshold;
+ uint32_t ctx[3];
+ uint32_t ts[3];
+
+ for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
+ ctx[i] = gem_context_clone_with_engines(i915, 0);
+ if (spin == NULL) {
+ spin = __igt_spin_new(i915,
+   .ctx = ctx[i],
+   .engine = e->flags,
+   .flags = flags);
+ } else {
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffer_count = 1,
+ .buffers_ptr = 
to_user_pointer(>obj[IGT_SPIN_BATCH]),
+ .flags = e->flags,
+ .rsvd1 = ctx[i],
+ };
+ gem_execbuf(i915, );
+ }
+ }
+
+ sleep(duration); /* over the course of many timeslices */
+
+ igt_assert(gem_bo_busy(i915, spin->handle));
+ igt_spin_end(spin);
+ for (int i = 0; i < ARRAY_SIZE(ctx); i++)
+ ts[i] = read_ctx_timestamp(i915, ctx[i], e);
+
+ for (int i = 0; i < ARRAY_SIZE(ctx); i++)
+ gem_context_destroy(i915, ctx[i]);
+ igt_spin_free(i915, spin);
+
+ /*
+  * If we imagine that the timeslices are randomly distributed to
+  * the virtual engines, we would expect the variation to be modelled
+  * by a drunken walk; ergo sqrt(num_timeslices).
+  */
+ threshold = sqrt(1e9 * duration / timeslice_duration_ns);
+ threshold *= timeslice_duration_ns;
+ threshold *= 2; /* CI safety factor before crying wolf */
+
+ qsort(ts, 3, sizeof(*ts), cmp_u32);
+ 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Measure timeslice distribution when oversaturated

2020-12-15 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-12-15 09:41:09)
> 
> On 14/12/2020 20:44, Chris Wilson wrote:
> > Check that timeslices for an oversaturated system (where there is more
> > work than can be supported by a single engine) are evenly distributed
> > between the clients.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   tests/i915/gem_exec_schedule.c | 179 +
> >   1 file changed, 179 insertions(+)
> > 
> > diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> > index f23d63ac3..263f1dd78 100644
> > --- a/tests/i915/gem_exec_schedule.c
> > +++ b/tests/i915/gem_exec_schedule.c
> > @@ -2516,6 +2516,154 @@ static void measure_semaphore_power(int i915)
> >   rapl_close();
> >   }
> >   
> > +static int read_timestamp_frequency(int i915)
> > +{
> > + int value = 0;
> > + drm_i915_getparam_t gp = {
> > + .value = ,
> > + .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
> > + };
> > + ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
> > + return value;
> > +}
> > +
> > +static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
> > +{
> > + return (x + y - 1) / y;
> > +}
> > +
> > +static uint64_t ticks_to_ns(int i915, uint64_t ticks)
> > +{
> > + return div64_u64_round_up(ticks * NSEC_PER_SEC,
> > +   read_timestamp_frequency(i915));
> > +}
> > +
> > +static int cmp_u32(const void *A, const void *B)
> > +{
> > + const uint32_t *a = A, *b = B;
> > +
> > + if (*a < *b)
> > + return -1;
> > + else if (*a > *b)
> > + return 1;
> > + else
> > + return 0;
> > +}
> > +
> > +static uint32_t read_ctx_timestamp(int i915,
> > +uint32_t ctx,
> > +const struct intel_execution_engine2 *e)
> > +{
> > + const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
> > + const uint32_t base = gem_engine_mmio_base(i915, e->name);
> > + struct drm_i915_gem_relocation_entry reloc;
> > + struct drm_i915_gem_exec_object2 obj = {
> > + .handle = gem_create(i915, 4096),
> > + .offset = 32 << 20,
> > + .relocs_ptr = to_user_pointer(),
> > + .relocation_count = 1,
> > + };
> > + struct drm_i915_gem_execbuffer2 execbuf = {
> > + .buffers_ptr = to_user_pointer(),
> > + .buffer_count = 1,
> > + .flags = e->flags,
> > + .rsvd1 = ctx,
> > + };
> > +#define RUNTIME (base + 0x3a8)
> > + uint32_t *map, *cs;
> > + uint32_t ts;
> > +
> > + igt_require(base);
> > +
> > + cs = map = gem_mmap__device_coherent(i915, obj.handle,
> > +  0, 4096, PROT_WRITE);
> > +
> > + *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
> > + *cs++ = RUNTIME;
> > + memset(, 0, sizeof(reloc));
> > + reloc.target_handle = obj.handle;
> > + reloc.presumed_offset = obj.offset;
> > + reloc.offset = offset_in_page(cs);
> > + reloc.delta = 4000;
> > + *cs++ = obj.offset + 4000;
> > + *cs++ = obj.offset >> 32;
> > +
> > + *cs++ = MI_BATCH_BUFFER_END;
> > +
> > + gem_execbuf(i915, );
> > + gem_sync(i915, obj.handle);
> > + gem_close(i915, obj.handle);
> > +
> > + ts = map[1000];
> > + munmap(map, 4096);
> > +
> > + return ts;
> > +}
> > +
> > +static void fairslice(int i915,
> > +   const struct intel_execution_engine2 *e,
> > +   unsigned long flags,
> > +   int duration)
> > +{
> > + const double timeslice_duration_ns = 1e6;
> > + igt_spin_t *spin = NULL;
> > + double threshold;
> > + uint32_t ctx[3];
> > + uint32_t ts[3];
> > +
> > + for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
> > + ctx[i] = gem_context_clone_with_engines(i915, 0);
> > + if (spin == NULL) {
> > + spin = __igt_spin_new(i915,
> > +   .ctx = ctx[i],
> > +   .engine = e->flags,
> > +   .flags = flags);
> > + } else {
> > + struct drm_i915_gem_execbuffer2 eb = {
> > + .buffer_count = 1,
> > + .buffers_ptr = 
> > to_user_pointer(>obj[IGT_SPIN_BATCH]),
> > + .flags = e->flags,
> > + .rsvd1 = ctx[i],
> > + };
> > + gem_execbuf(i915, );
> > + }
> > + }
> > +
> > + sleep(duration); /* over the course of many timeslices */
> > +
> > + igt_assert(gem_bo_busy(i915, spin->handle));
> > + igt_spin_end(spin);
> > + for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> > + ts[i] = read_ctx_timestamp(i915, ctx[i], e);
> > +
> > + for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> > +  

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_shrink: Refactor allocation sizing based on available memory

2020-12-15 Thread Tvrtko Ursulin



On 14/12/2020 20:59, Chris Wilson wrote:

Refactor the allocation such that we utilise just enough memory pressure
to invoke the shrinker, and just enough processes to spread across the
CPUs and contend on the shrinker.

v2: Reduce over-allocation from mem_size/2 to mem_size/8, and 9
processes per cpu.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/i915/gem_shrink.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index 023db8c56..6413d25f5 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -426,6 +426,7 @@ igt_main
int num_processes = 0;
  
  	igt_fixture {

+   const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
uint64_t mem_size = intel_get_total_ram_mb();
int fd;
  
@@ -434,16 +435,16 @@ igt_main
  
  		/*

 * Spawn enough processes to use all memory, but each only
-* uses half the available mappable aperture ~128MiB.
+* uses half of the available per-cpu memory.
 * Individually the processes would be ok, but en masse
 * we expect the shrinker to start purging objects,
 * and possibly fail.
 */
-   alloc_size = gem_mappable_aperture_size(fd) / 2;
-   num_processes = 1 + (mem_size / (alloc_size >> 20));
+   alloc_size = (mem_size + ncpus - 1) / ncpus / 8;
+   num_processes = ncpus + (mem_size / alloc_size);
  
-		igt_info("Using %d processes and %'lluMiB per process\n",

-num_processes, (long long)(alloc_size >> 20));
+   igt_info("Using %d processes and %'"PRIu64"MiB per process\n",
+num_processes, alloc_size);
  
  		intel_require_memory(num_processes, alloc_size,

 CHECK_SWAP | CHECK_RAM);



For some reason I still find the calculation convoluted but okay.

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Measure timeslice distribution when oversaturated

2020-12-15 Thread Tvrtko Ursulin



On 14/12/2020 20:44, Chris Wilson wrote:

Check that timeslices for an oversaturated system (where there is more
work than can be supported by a single engine) are evenly distributed
between the clients.

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

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f23d63ac3..263f1dd78 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2516,6 +2516,154 @@ static void measure_semaphore_power(int i915)
rapl_close();
  }
  
+static int read_timestamp_frequency(int i915)

+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+static int cmp_u32(const void *A, const void *B)
+{
+   const uint32_t *a = A, *b = B;
+
+   if (*a < *b)
+   return -1;
+   else if (*a > *b)
+   return 1;
+   else
+   return 0;
+}
+
+static uint32_t read_ctx_timestamp(int i915,
+  uint32_t ctx,
+  const struct intel_execution_engine2 *e)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = gem_create(i915, 4096),
+   .offset = 32 << 20,
+   .relocs_ptr = to_user_pointer(),
+   .relocation_count = 1,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   .flags = e->flags,
+   .rsvd1 = ctx,
+   };
+#define RUNTIME (base + 0x3a8)
+   uint32_t *map, *cs;
+   uint32_t ts;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, obj.handle,
+0, 4096, PROT_WRITE);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = RUNTIME;
+   memset(, 0, sizeof(reloc));
+   reloc.target_handle = obj.handle;
+   reloc.presumed_offset = obj.offset;
+   reloc.offset = offset_in_page(cs);
+   reloc.delta = 4000;
+   *cs++ = obj.offset + 4000;
+   *cs++ = obj.offset >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_END;
+
+   gem_execbuf(i915, );
+   gem_sync(i915, obj.handle);
+   gem_close(i915, obj.handle);
+
+   ts = map[1000];
+   munmap(map, 4096);
+
+   return ts;
+}
+
+static void fairslice(int i915,
+ const struct intel_execution_engine2 *e,
+ unsigned long flags,
+ int duration)
+{
+   const double timeslice_duration_ns = 1e6;
+   igt_spin_t *spin = NULL;
+   double threshold;
+   uint32_t ctx[3];
+   uint32_t ts[3];
+
+   for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
+   ctx[i] = gem_context_clone_with_engines(i915, 0);
+   if (spin == NULL) {
+   spin = __igt_spin_new(i915,
+ .ctx = ctx[i],
+ .engine = e->flags,
+ .flags = flags);
+   } else {
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = 
to_user_pointer(>obj[IGT_SPIN_BATCH]),
+   .flags = e->flags,
+   .rsvd1 = ctx[i],
+   };
+   gem_execbuf(i915, );
+   }
+   }
+
+   sleep(duration); /* over the course of many timeslices */
+
+   igt_assert(gem_bo_busy(i915, spin->handle));
+   igt_spin_end(spin);
+   for (int i = 0; i < ARRAY_SIZE(ctx); i++)
+   ts[i] = read_ctx_timestamp(i915, ctx[i], e);
+
+   for (int i = 0; i < ARRAY_SIZE(ctx); i++)
+   gem_context_destroy(i915, ctx[i]);
+   igt_spin_free(i915, spin);
+
+   /*
+* If we imagine that the timeslices are randomly distributed to
+* the virtual engines, we would expect the variation to be modelled
+* by a drunken walk; ergo sqrt(num_timeslices).
+*/
+   threshold = sqrt(1e9 * duration / timeslice_duration_ns);
+   threshold *= timeslice_duration_ns;
+   threshold 

[Intel-gfx] ✓ Fi.CI.BAT: success for Multi DSB instance support

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

Series: Multi DSB instance support
URL   : https://patchwork.freedesktop.org/series/84934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9482 -> Patchwork_19143


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +26 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_basic@userptr:
- fi-byt-j1900:   NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][3] ([i915#2283])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@active:
- fi-kbl-soraka:  [PASS][8] -> [DMESG-FAIL][9] ([i915#2291] / 
[i915#666])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/fi-kbl-soraka/igt@i915_selftest@l...@active.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-kbl-soraka/igt@i915_selftest@l...@active.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@gem_flink_basic@bad-flink:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [INCOMPLETE][13] ([i915#142] / [i915#2405]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9482/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19143/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666


Participating hosts (43 -> 39)
--

  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9482 -> Patchwork_19143

  CI-20190529: 20190529
  CI_DRM_9482: 279e4ca8a7117e617c498833deaa287b797e7d09 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5894: a668d5c148ec3c1d3958f660a146a88676aac25d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19143: f98badfe5d95bcabf9220b53328347e339abbf82 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f98badfe5d95 drm/i915/dsb: multi dsb instance support in dsb-commit()
b29008823ac1 drm/i915/dsb: multi dsb instance support in dsb-write()
5408c90cf097 drm/i915/dsb: multi dsb instance support in prepare() and cleanup()

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.DOCS: warning for Multi DSB instance support

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

Series: Multi DSB instance support
URL   : https://patchwork.freedesktop.org/series/84934/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dsb.c:94: warning: Function parameter or 
member 'id' not described in 'intel_dsb_indexed_reg_write'
./drivers/gpu/drm/i915/display/intel_dsb.c:171: warning: Function parameter or 
member 'id' not described in 'intel_dsb_reg_write'
Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 
1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists 
./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1


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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Multi DSB instance support

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

Series: Multi DSB instance support
URL   : https://patchwork.freedesktop.org/series/84934/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1448:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1502:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Multi DSB instance support

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

Series: Multi DSB instance support
URL   : https://patchwork.freedesktop.org/series/84934/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5408c90cf097 drm/i915/dsb: multi dsb instance support in prepare() and cleanup()
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

-:161: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#161: FILE: drivers/gpu/drm/i915/display/intel_dsb.c:277:
+   if (!dsb) {
+   drm_err(>drm, "DSB%d obj creation failed\n", i);

total: 0 errors, 2 warnings, 0 checks, 187 lines checked
b29008823ac1 drm/i915/dsb: multi dsb instance support in dsb-write()
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 127 lines checked
f98badfe5d95 drm/i915/dsb: multi dsb instance support in dsb-commit()
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

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


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