Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc NULL check (rev3)

[Vudum, Lakshminarayana]

Re-reported.

-Original Message-
From: Anshuman Gupta  
Sent: Thursday, February 11, 2021 7:45 PM
To: Vudum, Lakshminarayana 
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc 
NULL check (rev3)

On 2021-02-11 at 16:42:07 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3)
> URL   : https://patchwork.freedesktop.org/series/86440/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19664_full 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_19664_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_19664_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_19664_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@perf_pmu@cpu-hotplug:
> - shard-iclb: [PASS][1] -> [TIMEOUT][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb6/igt@perf_...@cpu-hotplug.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb7/i
> gt@perf_...@cpu-hotplug.html
Hi Lakshmi ,
Above failure are not related to this series.
could you please create a issue for above failure ans re-report the results.
Thanks,
Anshuman Gupta. 
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_19664_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@core_hotunplug@unbind-rebind:
> - shard-hsw:  NOTRUN -> [WARN][3] ([i915#2283])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/ig
> t@core_hotunp...@unbind-rebind.html
> 
>   * igt@gem_ctx_persistence@engines-mixed:
> - shard-hsw:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw6/ig
> t@gem_ctx_persiste...@engines-mixed.html
> 
>   * igt@gem_ctx_persistence@replace-hostile:
> - shard-hsw:  NOTRUN -> [SKIP][5] ([fdo#109271]) +59 similar 
> issues
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/ig
> t@gem_ctx_persiste...@replace-hostile.html
> 
>   * igt@gem_ctx_sseu@invalid-args:
> - shard-apl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +34 similar 
> issues
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl2/ig
> t@gem_ctx_s...@invalid-args.html
> 
>   * igt@gem_exec_create@forked:
> - shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / 
> [i915#95])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk5/igt@gem_exec_cre...@forked.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-glk5/ig
> t@gem_exec_cre...@forked.html
> 
>   * igt@gem_exec_fair@basic-deadline:
> - shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl3/ig
> t@gem_exec_f...@basic-deadline.html
> 
>   * igt@gem_exec_fair@basic-none@vcs0:
> - shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
> issues
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl7/ig
> t@gem_exec_fair@basic-n...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
> issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb7/i
> gt@gem_exec_fair@basic-pace-sh...@rcs0.html
> 
>   * igt@gem_exec_reloc@basic-wide-active@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2389])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb4/i
> gt@gem_exec_reloc@basic-wide-act...@vcs1.html
> 
>   * igt@gem_exec_schedule@u-fairslice@bcs0:
> - shard-apl:  NOTRUN -> [DMESG-WARN][16] ([i915#1610])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl7/ig
> t@gem_exec_schedule@u-fairsl...@bcs0.html
> 
>   * igt@gem_exec_schedule@u-fairslice@rcs0:
> - shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / 
> [i915#2803])
>[17]: 
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Ratelimit heartbeat completion probing (rev10)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev10)
URL   : https://patchwork.freedesktop.org/series/86665/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9767_full -> Patchwork_19667_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@sysfs_heartbeat_interval@nopreempt@vcs0:
- shard-skl:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-skl7/igt@sysfs_heartbeat_interval@nopree...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-skl9/igt@sysfs_heartbeat_interval@nopree...@vcs0.html
- shard-glk:  [PASS][3] -> [FAIL][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-glk5/igt@sysfs_heartbeat_interval@nopree...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-glk5/igt@sysfs_heartbeat_interval@nopree...@vcs0.html
- shard-apl:  [PASS][5] -> [FAIL][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-apl4/igt@sysfs_heartbeat_interval@nopree...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-apl8/igt@sysfs_heartbeat_interval@nopree...@vcs0.html

  * igt@sysfs_heartbeat_interval@nopreempt@vecs0:
- shard-iclb: [PASS][7] -> [FAIL][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-iclb8/igt@sysfs_heartbeat_interval@nopree...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-iclb3/igt@sysfs_heartbeat_interval@nopree...@vecs0.html
- shard-kbl:  NOTRUN -> [FAIL][9] +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-kbl7/igt@sysfs_heartbeat_interval@nopree...@vecs0.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat2x3-dmat4x2 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/pig-icl-1065g7/spec@glsl-4.00@execution@built-in-functi...@fs-op-mult-dmat2x3-dmat4x2.html

  * spec@glsl-4.00@execution@built-in-functions@gs-transpose-dmat4 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/pig-icl-1065g7/spec@glsl-4.00@execution@built-in-functi...@gs-transpose-dmat4.html

  
New tests
-

  New tests have been introduced between CI_DRM_9767_full and 
Patchwork_19667_full:

### New Piglit tests (2) ###

  * spec@glsl-4.00@execution@built-in-functions@fs-op-mult-dmat2x3-dmat4x2:
- Statuses : 1 crash(s)
- Exec time: [32.45] s

  * spec@glsl-4.00@execution@built-in-functions@gs-transpose-dmat4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-deadline:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-tglb7/igt@gem_exec_f...@basic-deadline.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-tglb2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-glk6/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][16] -> [SKIP][17] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9767/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs: HDCP capability enc NULL check (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3)
URL   : https://patchwork.freedesktop.org/series/86440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19664_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-hsw:  NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@core_hotunp...@unbind-rebind.html

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

  * igt@gem_ctx_persistence@replace-hostile:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271]) +59 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@gem_ctx_persiste...@replace-hostile.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-apl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +34 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl2/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_exec_create@forked:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk5/igt@gem_exec_cre...@forked.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-glk5/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

  * igt@gem_exec_schedule@u-fairslice@bcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][14] ([i915#1610])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl7/igt@gem_exec_schedule@u-fairsl...@bcs0.html

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / 
[i915#2803])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html

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

  * igt@gem_request_retire@retire-vma-not-inactive:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#2895])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb5/igt@gem_request_ret...@retire-vma-not-inactive.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb1/igt@gem_request_ret...@retire-vma-not-inactive.html

  * igt@gem_userptr_blits@process-exit-mmap@wb:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl8/igt@gem_userptr_blits@process-exit-m...@wb.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#112306])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb8/igt@gen9_exec_pa...@batch-without-end.html
- shard-tglb: NOTRUN -> [SKIP][23] ([fdo#112306])
   [23]: 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc NULL check (rev3)

[Anshuman Gupta]

On 2021-02-11 at 16:42:07 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3)
> URL   : https://patchwork.freedesktop.org/series/86440/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19664_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_19664_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_19664_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_19664_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@perf_pmu@cpu-hotplug:
> - shard-iclb: [PASS][1] -> [TIMEOUT][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb6/igt@perf_...@cpu-hotplug.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb7/igt@perf_...@cpu-hotplug.html
Hi Lakshmi ,
Above failure are not related to this series.
could you please create a issue for above failure ans re-report the results.
Thanks,
Anshuman Gupta. 
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_19664_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@core_hotunplug@unbind-rebind:
> - shard-hsw:  NOTRUN -> [WARN][3] ([i915#2283])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@core_hotunp...@unbind-rebind.html
> 
>   * igt@gem_ctx_persistence@engines-mixed:
> - shard-hsw:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw6/igt@gem_ctx_persiste...@engines-mixed.html
> 
>   * igt@gem_ctx_persistence@replace-hostile:
> - shard-hsw:  NOTRUN -> [SKIP][5] ([fdo#109271]) +59 similar 
> issues
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@gem_ctx_persiste...@replace-hostile.html
> 
>   * igt@gem_ctx_sseu@invalid-args:
> - shard-apl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +34 similar 
> issues
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl2/igt@gem_ctx_s...@invalid-args.html
> 
>   * igt@gem_exec_create@forked:
> - shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / 
> [i915#95])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk5/igt@gem_exec_cre...@forked.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-glk5/igt@gem_exec_cre...@forked.html
> 
>   * igt@gem_exec_fair@basic-deadline:
> - shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl3/igt@gem_exec_f...@basic-deadline.html
> 
>   * igt@gem_exec_fair@basic-none@vcs0:
> - shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
> issues
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
> issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
> 
>   * igt@gem_exec_reloc@basic-wide-active@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2389])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html
> 
>   * igt@gem_exec_schedule@u-fairslice@bcs0:
> - shard-apl:  NOTRUN -> [DMESG-WARN][16] ([i915#1610])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl7/igt@gem_exec_schedule@u-fairsl...@bcs0.html
> 
>   * igt@gem_exec_schedule@u-fairslice@rcs0:
> - shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / 
> [i915#2803])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@gem_exec_schedule@u-fairsl...@rcs0.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html
> 
>   * igt@gem_pread@exhaustion:
> - shard-apl:  NOTRUN -> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Ratelimit heartbeat completion probing (rev10)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev10)
URL   : https://patchwork.freedesktop.org/series/86665/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9767 -> Patchwork_19667


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### CI changes ###


### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- 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_9767/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19667/fi-tgl-y/igt@debugfs_test@read_all_entries.html

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

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


Participating hosts (43 -> 38)
--

  Additional (1): fi-ehl-2 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9767 -> Patchwork_19667

  CI-20190529: 20190529
  CI_DRM_9767: 975f60d1f2dc8e653110d33517f00515dede35bb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19667: 1c2fc38a94ff6e886d2fe58f3e1446fa58ab4a19 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1c2fc38a94ff drm/i915/gt: Ratelimit heartbeat completion probing

== Logs ==

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

Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.

[Lyude Paul]

(JFYI I have seen this email, but haven't gotten a chance to actually read
through it yet. I should have the time to do so tomorrow)

On Thu, 2021-02-11 at 06:56 +, Almahallawy, Khaled wrote:
> On Wed, 2021-02-10 at 13:03 -0500, Lyude Paul wrote:
> > On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote:
> > > The number of AUX retries specified in the DP specs is 7.
> > > Currently, to make
> > > Dell 4k monitors happier, the number of retries are 32.
> > > i915 also retries 5 times (intel_dp_aux_xfer) which means in the
> > > case of AUX
> > > timeout we actually retries 32 * 5 = 160 times.
> > 
> > Is there any good reason for i915 to actually be doing retries
> > itself? It seems
> > like an easier solution here might just to be to fix i915 so it
> > doesn't retry,
> > and just rely on DRM to do the retries as appropriate.
> > 
> > That being said though, I'm open to this if there is a legitimate
> > reason for
> > i915 to be handling retries on its own
> 
> i915 or others may benefit from controlling AUX retries to optimize and
> minimize timing spent on the aux transactions.
>  
> drm_dpcd_access handles multiple aux retries cases the same way (retry
> 32 times at worst case). The 4 cases are:
> 1- *AUX receive or IO error*. I believe it is up to specific
> implementation/HW once it detects a receive error to retry based on
> their internal understanding using the timeout appropriate to the HW
> capabilities.
>  
> 2- *AUX Timeout* As the driver follows the specs for the recommended
> timeout timer as defined in section  (2.11.2 AUX Transaction
> Response/Reply Timeouts), the driver has more intelligence to know how
> many retries it needs. This is more useful in case of DP-ALT if some
> issues happen in Type-C stack that cause AUX timeout (e.g. USB3 dock
> detected as high speed (USB2) causing SBU/AUX lines to be disabled).
> Also the disconnect of MST hub/docks is dependent how fast a userspace
> disconnect all MST connectors.  Not all user spaces do it as fast like
> Chrome (ubuntu is an example): 
> https://chromium-review.googlesource.com/c/chromium/src/+/2512550/  
> 
> 3- *AUX_NACK* DP spec mentions retry 3 times for NACK(2.16.1.3 GTC Lock
> Acquisition). However, sometimes we really don’t need any retry for
> NACK, if DPRX replied AUX_NACK for DPCD that it doesn’t support (e.g.
> reading LTTPR Capability and ID Field at DPCD Fh ~ F0007).
> 
> 4- *AUX_DEFER* The specs stated we may retry 7 times on AUX_DEFER
> (3.5.1.2.3 LANEx_CHANNEL_EQ_DONE Sequence) and may terminate LT. Also
> with the increased usage of USB4, TBT/Type-C Docks/Displays, and active
> cables, the use of LTTPR becomes common which adds more challenge
> especially if we have multiple LTTPRs and all operate in non-LTTPR
> mode. In this case all LTTPRs will reply AUX_DEFER in 300us if it did
> not receive any aux response from other LTTPRs and DPRX. The SCR states
> we need to retry 7 times and not more than 50ms (DP v2.0 SCR on 8b/10b
> DPTX and LTTPR Requirements Update to Section 3.6)
> 
> In addition I believe this function is not correct in treating
> AUX_DEFER and AUX_NACK as -EIO. Especially for AUX_DEFER, it is a valid
> 1 byte response that can provide a valuable debugging information
> especially in the case of on-board LTTPR where there is no way to
> capture this AUX response between the SoC and LTTPR unless you solder
> two wires on AUX_P and AUX_N lines and use i2c/aux analyzer to decode.
> At least we should provide the same debug information as we do in
> drm_dp_i2c_do_msg by printing AUX_DEFER and AUX_NACK.
> 
> Thank you for your feedback and review.
> 
> --Khaled
> > 
> > > So making the number of aux retires a variable to allow for fine
> > > tuning and
> > > optimization of aux timing.
> > > 
> > > Signed-off-by: Khaled Almahallawy 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 10 +++---
> > >  include/drm/drm_dp_helper.h |  1 +
> > >  2 files changed, 4 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index eedbb48815b7..8fdf57b4a06c 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -249,13 +249,7 @@ static int drm_dp_dpcd_access(struct
> > > drm_dp_aux *aux, u8
> > > request,
> > >  
> > >     mutex_lock(>hw_mutex);
> > >  
> > > -   /*
> > > -    * The specification doesn't give any recommendation on how
> > > often to
> > > -    * retry native transactions. We used to retry 7 times like
> > > for
> > > -    * aux i2c transactions but real world devices this wasn't
> > > -    * sufficient, bump to 32 which makes Dell 4k monitors
> > > happier.
> > > -    */
> > > -   for (retry = 0; retry < 32; retry++) {
> > > +   for (retry = 0; retry < aux->num_retries; retry++) {
> > >     if (ret != 0 && ret != -ETIMEDOUT) {
> > >     usleep_range(AUX_RETRY_INTERVAL,
> > >   

Re: [Intel-gfx] [PATCH v5] drm/i915/gt: Ratelimit heartbeat completion probing

[Tang, CQ]

Do you have the patch that can apply to DII?

--CQ

> -Original Message-
> From: Chris Wilson 
> Sent: Thursday, February 11, 2021 3:14 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Tang, CQ 
> Subject: [PATCH v5] drm/i915/gt: Ratelimit heartbeat completion probing
> 
> The heartbeat runs through a few phases that we expect to complete within
> a certain number of heartbeat intervals. First we must submit the heartbeat
> to the queue, and if the queue is occupied it may take a couple of intervals
> before the heartbeat preempts the workload and is submitted to HW. Once
> running on HW, completion is not instantaneous as it may have to first reset
> the current workload before it itself runs through the empty request and
> signals completion. As such, we know that the heartbeat must take at least
> the preempt reset timeout and before we have had a chance to reset the
> engine, we do not want to issue a global reset ourselves (simply so that we
> only try to do one reset at a time and not confuse ourselves by resetting
> twice and hitting an innocent.)
> 
> So by taking into consideration that once running the request must take a
> finite amount of time, we can delay the final completion check to
> accommodate that and avoid checking too early (before we've had a chance
> to handle any engine resets required).
> 
> v3: Now with more tracking for selftests and detection of false/unexpected
> hang reports.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
> Suggested-by: CQ Tang 
> Signed-off-by: Chris Wilson 
> ---
>  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 92 +++---
> drivers/gpu/drm/i915/gt/intel_engine_types.h  |  7 ++
>  .../drm/i915/gt/selftest_engine_heartbeat.c   | 93 ---
>  drivers/gpu/drm/i915/gt/selftest_execlists.c  |  5 +-
>  4 files changed, 148 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 0b062fad1837..e14f9eab5779 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -20,6 +20,18 @@
>   * issue a reset -- in the hope that restores progress.
>   */
> 
> +#define HEARTBEAT_COMPLETION 50u /* milliseconds */
> +
> +static long completion_timeout(const struct intel_engine_cs *engine) {
> + long timeout = HEARTBEAT_COMPLETION;
> +
> + if (intel_engine_has_preempt_reset(engine))
> + timeout += READ_ONCE(engine-
> >props.preempt_timeout_ms);
> +
> + return msecs_to_jiffies(timeout);
> +}
> +
>  static bool next_heartbeat(struct intel_engine_cs *engine)  {
>   long delay;
> @@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs
> *engine)
>   return false;
> 
>   delay = msecs_to_jiffies_timeout(delay);
> +
> + /*
> +  * Once we submit a heartbeat to the HW, we know that it will take
> +  * at least a certain amount of time to complete. On a hanging system
> +  * it will first have to wait for the preempt reset timeout, and
> +  * then it will take some time for the reset to resume with the
> +  * heartbeat and for it to complete. So once we have submitted the
> +  * heartbeat to HW, we can wait a while longer before declaring the
> +  * engine stuck and forcing a reset ourselves. If we do a reset
> +  * and the engine is also doing a reset, it is possible that we
> +  * reset the engine twice, harming an innocent.
> +  *
> +  * Before we have sumitted the heartbeat, we do not want to
> change
> +  * the interval as we want to promote the heartbeat and trigger
> +  * preemption in a deterministic time frame.
> +  */
> + if (engine->heartbeat.systole &&
> + i915_request_is_active(engine->heartbeat.systole))
> + delay = max(delay, completion_timeout(engine));
> +
>   if (delay >= HZ)
>   delay = round_jiffies_up_relative(delay);
>   mod_delayed_work(system_highpri_wq, >heartbeat.work,
> delay + 1); @@ -48,12 +80,39 @@ heartbeat_create(struct intel_context *ce,
> gfp_t gfp)
>   return rq;
>  }
> 
> +static void
> +untrack_heartbeat(struct intel_engine_cs *engine) {
> + struct i915_request *rq;
> +
> + rq = engine->heartbeat.systole;
> + if (!rq)
> + return;
> +
> + ENGINE_TRACE(engine, "heartbeat " RQ_FMT " completed\n",
> RQ_ARG(rq));
> + I915_SELFTEST_ONLY(engine->heartbeat.completed++);
> +
> + WRITE_ONCE(engine->heartbeat.systole, NULL);
> + i915_request_put(rq);
> +}
> +
> +static void
> +track_heartbeat(struct intel_engine_cs *engine, struct i915_request
> +*rq) {
> + ENGINE_TRACE(engine, "heartbeat " RQ_FMT " started\n",
> RQ_ARG(rq));
> + I915_SELFTEST_ONLY(engine->heartbeat.submitted++);
> +
> + WRITE_ONCE(engine->heartbeat.systole, i915_request_get(rq));
> + if (!next_heartbeat(engine))
> + 

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos

[Rodrigo Vivi]

On Wed, Feb 10, 2021 at 10:23:58PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote:
> > Apparently the new gen9_bc platforms that Intel has introduced don't
> > provide us with a STRAP config register to read from for initializing DDI
> > B, C, and D detection. So, workaround this by hard-coding our strap config
> > in intel_setup_outputs().
> > 
> > Changes since v4:
> > * Split this into it's own commit
> > 
> > Cc: Matt Roper 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > [originally from Tejas's work]
> > Signed-off-by: Tejas Upadhyay 
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index beed08c00b6c..4dee37f8659d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -11943,7 +11943,14 @@ static void intel_setup_outputs(struct 
> > drm_i915_private *dev_priv)
> >  
> > /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
> >  * register */
> > -   found = intel_de_read(dev_priv, SFUSE_STRAP);
> > +   if (HAS_PCH_TGP(dev_priv)) {
> > +   /* W/A due to lack of STRAP config on TGP PCH*/
> > +   found = (SFUSE_STRAP_DDIB_DETECTED |
> > +SFUSE_STRAP_DDIC_DETECTED |
> > +SFUSE_STRAP_DDID_DETECTED);
> 
> we have somewhere in this function these forced fuse straps for gen9 
> platform...
> don't we have a ways to combine them?
> 
> Afterall, the reason that we need these forced bits is
> because it is a gen9, not because it is a TGP...

just ignore my non-sense comment... I confused with the 
/* WaIgnoreDDIAStrap: skl */
above...
thought it was for all the ports... not just for port A...


Reviewed-by: Rodrigo Vivi 


> 
> > +   } else {
> > +   found = intel_de_read(dev_priv, SFUSE_STRAP);
> > +   }
> >  
> > if (found & SFUSE_STRAP_DDIB_DETECTED)
> > intel_ddi_init(dev_priv, PORT_B);
> > -- 
> > 2.29.2
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5] drm/i915/gt: Ratelimit heartbeat completion probing

[Chris Wilson]

The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)

So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).

v3: Now with more tracking for selftests and detection of
false/unexpected hang reports.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang 
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 92 +++---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  7 ++
 .../drm/i915/gt/selftest_engine_heartbeat.c   | 93 ---
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  5 +-
 4 files changed, 148 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e14f9eab5779 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
  * issue a reset -- in the hope that restores progress.
  */
 
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+   long timeout = HEARTBEAT_COMPLETION;
+
+   if (intel_engine_has_preempt_reset(engine))
+   timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+   return msecs_to_jiffies(timeout);
+}
+
 static bool next_heartbeat(struct intel_engine_cs *engine)
 {
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
 
delay = msecs_to_jiffies_timeout(delay);
+
+   /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we want to promote the heartbeat and trigger
+* preemption in a deterministic time frame.
+*/
+   if (engine->heartbeat.systole &&
+   i915_request_is_active(engine->heartbeat.systole))
+   delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, >heartbeat.work, delay + 1);
@@ -48,12 +80,39 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
 }
 
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+   struct i915_request *rq;
+
+   rq = engine->heartbeat.systole;
+   if (!rq)
+   return;
+
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT " completed\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.completed++);
+
+   WRITE_ONCE(engine->heartbeat.systole, NULL);
+   i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT " started\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.submitted++);
+
+   WRITE_ONCE(engine->heartbeat.systole, i915_request_get(rq));
+   if (!next_heartbeat(engine))
+   untrack_heartbeat(engine);
+}
+
 static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
 {
engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
i915_request_add_active_barriers(rq);
if (!engine->heartbeat.systole && intel_engine_has_heartbeat(engine))
-   engine->heartbeat.systole = i915_request_get(rq);
+   track_heartbeat(engine, rq);
 }
 
 static void 

Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume

[Lyude Paul]

On Wed, 2021-02-10 at 04:33 +, Gupta, Anshuman wrote:
> My sincere apology, I had missed this thread.

No problem! Happens all the time to me :)

> We have decided to keep the alternative WA i.e  setting/clearing 0xC2000 bit
> #7 
> before entering after exiting s0ix to fix the deeper s0ix power consumption
> issues on ICL_PCH
> families platforms. This alternative WA  was added to B.Spec on our request.
> But on TGL_PCH first alternative WA logic i.e  in irq_reset() was working to
> attain deeper s0ix residencies so
> we haven't changed that.

Awesome, thanks for the info!

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
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/gt: Ratelimit heartbeat completion probing (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev9)
URL   : https://patchwork.freedesktop.org/series/86665/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9764 -> Patchwork_19666


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
- fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
- fi-cml-s:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-cml-s/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-cml-s/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-snb-2600:[PASS][8] -> [INCOMPLETE][9] ([i915#2782])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-snb-2600/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-snb-2600/igt@i915_selftest@live@gt_heartbeat.html
- fi-ivb-3770:[PASS][10] -> [INCOMPLETE][11] ([i915#2782])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-ivb-3770/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-ivb-3770/igt@i915_selftest@live@gt_heartbeat.html
- fi-icl-y:   [PASS][12] -> [INCOMPLETE][13] ([i915#2782])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-icl-y/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-icl-y/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][14] -> [FAIL][15] ([i915#1372])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@runner@aborted:
- fi-cfl-8109u:   NOTRUN -> [FAIL][18] ([i915#2295])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-cfl-8109u/igt@run...@aborted.html
- fi-snb-2600:NOTRUN -> [FAIL][19] ([i915#698])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-snb-2600/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][20] ([i915#2295])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-bxt-dsi/igt@run...@aborted.html
- fi-icl-y:   NOTRUN -> [FAIL][21] ([i915#2295] / [i915#2724])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-icl-y/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [INCOMPLETE][22] ([i915#2940]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9764/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19666/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   

[Intel-gfx] [PATCH v4] drm/i915/gt: Ratelimit heartbeat completion probing

[Chris Wilson]

The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)

So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).

v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.

v3: Now with more tracking for selftests and detection of
false/unexpected hang reports.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang 
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 107 +++---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   8 ++
 .../drm/i915/gt/selftest_engine_heartbeat.c   |  93 +--
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |   5 +-
 4 files changed, 163 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..351f58def216 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
  * issue a reset -- in the hope that restores progress.
  */
 
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+   long timeout = HEARTBEAT_COMPLETION;
+
+   if (intel_engine_has_preempt_reset(engine))
+   timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+   return msecs_to_jiffies(timeout);
+}
+
 static bool next_heartbeat(struct intel_engine_cs *engine)
 {
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
 
delay = msecs_to_jiffies_timeout(delay);
+
+   /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we want to promote the heartbeat and trigger
+* preemption in a deterministic time frame.
+*/
+   if (engine->heartbeat.systole &&
+   i915_request_is_active(engine->heartbeat.systole))
+   delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, >heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
 }
 
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct intel_engine_cs *engine =
+   container_of(cb, typeof(*engine), heartbeat.cb);
+
+   if (READ_ONCE(engine->heartbeat.systole))
+   mod_delayed_work(system_highpri_wq, >heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+   struct i915_request *rq;
+
+   rq = fetch_and_zero(>heartbeat.systole);
+   if (!rq)
+   return;
+
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT "completed\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.completed++);
+
+   dma_fence_remove_callback(>fence, >heartbeat.cb);
+   i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT "started\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.submitted++);
+
+   dma_fence_add_callback(>fence,
+  >heartbeat.cb,
+  

[Intel-gfx] 2021 X.Org Foundation Membership renewal and election schedule

[Harry Wentland]

The 2021 X.Org Foundation elections are rapidly approaching. In 
preparation of the elections we would like to remind you that members 
will need to renew their membership each year in order to vote. Please 
take the time to renew your membership by logging into 
https://members.x.org and clicking on the "Apply" button to apply for 
the 2021-2022 membership.


We would also like to encourage you to start considering yourself or 
someone else for nomination to the board. We will send another email to 
start the official nomination period when it opens.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

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

Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers

[Lyude Paul]

On Wed, 2021-02-10 at 23:15 -0500, Rodrigo Vivi wrote:
> On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a set of shared DRM helpers.
> > 
> > Note that these helpers are intended to handle DPCD related backlight
> > control bits such as setting the brightness level over AUX, probing the
> > backlight's TCON, enabling/disabling the backlight over AUX if supported,
> > etc. Any PWM-related portions of backlight control are explicitly left up
> > to the driver, as these will vary from platform to platform.
> > 
> > The only exception to this is the calculation of the PWM frequency
> > pre-divider value. This is because the only platform-specific information
> > required for this is the PWM frequency of the panel, which the driver is
> > expected to provide if available. The actual algorithm for calculating this
> > value is standard and is defined in the eDP specification from VESA.
> > 
> > Note that these helpers do not yet implement the full range of features
> > the VESA backlight interface provides, and only provide the following
> > functionality (all of which was already present in i915's DPCD backlight
> > support):
> > 
> > * Basic control of brightness levels
> > * Basic probing of backlight capabilities
> > * Helpers for enabling and disabling the backlight
> > 
> > v3:
> > * Split out changes to i915's backlight code to separate patches to make it
> >   easier to review
> > v4:
> > * Style/spelling changes from Thomas Zimmermann
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Jani Nikula 
> > Cc: Dave Airlie 
> > Cc: greg.depo...@gmail.com
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c   | 332 ++
> >  .../drm/i915/display/intel_display_types.h    |   5 +-
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
> >  include/drm/drm_dp_helper.h   |  48 +++
> >  4 files changed, 412 insertions(+), 258 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..1a3d4679d720 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct
> > drm_dp_aux *aux, u8 color_spc)
> > return 0;
> >  }
> >  EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> > +
> > +/**
> > + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> > via AUX
> > + * @aux: The DP AUX channel to use
> > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > + * @level: The brightness level to set
> > + *
> > + * Sets the brightness level of an eDP panel's backlight. Note that the
> > panel's backlight must
> > + * already have been enabled by the driver by calling
> > drm_edp_backlight_enable().
> > + *
> > + * Returns: %0 on success, negative error code on failure
> > + */
> > +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > +   u16 level)
> > +{
> > +   int ret;
> > +   u8 buf[2] = { 0 };
> > +
> > +   if (bl->lsb_reg_used) {
> > +   buf[0] = (level & 0xff00) >> 8;
> > +   buf[1] = (level & 0x00ff);
> > +   } else {
> > +   buf[0] = level;
> > +   }
> > +
> > +   ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> > sizeof(buf));
> > +   if (ret != sizeof(buf)) {
> > +   DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> > aux->name, ret);
> > +   return ret < 0 ? ret : -EIO;
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > +
> > +static int
> > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > +    bool enable)
> > +{
> > +   int ret;
> > +   u8 buf;
> > +
> > +   /* The panel uses something other then DPCD for enabling its
> > backlight */
> > +   if (!bl->aux_enable)
> > +   return 0;
> > +
> > +   ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
> > +   if (ret != 1) {
> > +   DRM_ERROR("%s: Failed to read eDP display control register:
> > %d\n", aux->name, ret);
> > +   return ret < 0 ? ret : -EIO;
> > +   }
> > +   if (enable)
> > +   buf |= DP_EDP_BACKLIGHT_ENABLE;
> > +   else
> > +   buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> > +
> > +   ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> > +   if (ret != 1) {
> > +   DRM_ERROR("%s: Failed to write eDP display control register:
> > %d\n", aux->name, ret);
> > +   return ret < 0 ? ret : -EIO;
> > +   }
> > +
> > +   

Re: [Intel-gfx] linux-next: Tree for Feb 11 (drivers/gpu/drm/i915/display/intel_panel.o)

[Randy Dunlap]

On 2/11/21 3:26 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210210:
> 
> The powerpc tree still had its build failure in the allyesconfig for
> which I applied a supplied patch.
> 
> The v4l-dvb tree lost its build failure.
> 
> The drm-misc tree lost its build failure.
> 
> The modules tree lost its build failure.
> 
> The device-mapper tree gained a build failure so I used the version
> from next-20210210.
> 
> The tip tree lost its boot failure.
> 
> The rcu tree gained conflicts against the block tree.
> 
> The driver-core tree lost its build failure.
> 
> The akpm-current tree gained conflicts against the fscache tree.
> 
> Non-merge commits (relative to Linus' tree): 9533
>  9470 files changed, 385794 insertions(+), 266880 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig and htmldocs. And finally, a simple boot test
> of the powerpc pseries_le_defconfig kernel in qemu (with and without
> kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 333 trees (counting Linus' and 87 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 

on x86_64:
# CONFIG_ACPI is not set

ld: drivers/gpu/drm/i915/display/intel_panel.o: in function 
`intel_backlight_device_register':
intel_panel.c:(.text+0x40fb): undefined reference to `backlight_device_register'
ld: drivers/gpu/drm/i915/display/intel_panel.o: in function 
`intel_backlight_device_unregister':
intel_panel.c:(.text+0x41a4): undefined reference to 
`backlight_device_unregister'


Full randconfig file is attached.

-- 
~Randy
Reported-by: Randy Dunlap 


config-r7779.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: Handle lane polarity for DDI port

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, February 11, 2021 6:33 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; Souza, Jose ; 
> Roper,
> Matthew D 
> Subject: Re: [PATCH] drm/i915/display: Handle lane polarity for DDI port
> 
> On Thu, Feb 11, 2021 at 05:12:09PM +0530, Uma Shankar wrote:
> > Lane Reversal is required for some of the DDI ports. This information
> > is populated in VBT and driver should read the same and set the
> > polarity while enabling the port. This patch handles the same.
> >
> > It helps fix a display blankout issue on DP ports on certain
> > platforms.
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 17 +
> > drivers/gpu/drm/i915/display/intel_bios.h |  2 ++
> > drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +++
> >  3 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 7118530a1c38..dd51413e7f45 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -2674,6 +2674,23 @@ intel_bios_is_lspcon_present(const struct
> drm_i915_private *i915,
> > return HAS_LSPCON(i915) && child && child->lspcon;  }
> >
> > +/**
> > + * intel_bios_is_lane_reversal_needed - if lane reversal needed on port
> > + * @i915:   i915 device instance
> > + * @port:   port to check
> > + *
> > + * Return true if port requires lane reversal  */ bool
> > +intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
> > +  enum port port)
> > +{
> > +   const struct child_device_config *child =
> > +   i915->vbt.ddi_port_info[port].child;
> > +
> > +   return child && child->lane_reversal; }
> > +
> >  enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv,
> >enum port port)
> >  {
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
> > b/drivers/gpu/drm/i915/display/intel_bios.h
> > index e29e79faa01b..f25190ecfe97 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> > @@ -241,6 +241,8 @@ bool intel_bios_is_port_hpd_inverted(const struct
> drm_i915_private *i915,
> >  enum port port);
> >  bool intel_bios_is_lspcon_present(const struct drm_i915_private *i915,
> >   enum port port);
> > +bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private 
> > *i915,
> > +   enum port port);
> >  enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv,
> > enum port port);  bool intel_bios_get_dsc_params(struct intel_encoder 
> > *encoder,
> >struct intel_crtc_state *crtc_state, diff --git
> > a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 3c4003605f93..2d6906f6995f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4082,6 +4082,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> > intel_de_read(dev_priv, DDI_BUF_CTL(port))
> > & (DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
> >
> > +   if (intel_bios_is_lane_reversal_needed(dev_priv, port))
> > +   dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
> > +
> 
> Not a huge fan of saved_port_bits in general but as long as we have it 
> stuffing this in
> there seems like the best option.
> 
> Reviewed-by: Ville Syrjälä 

Pushed the change to drm-intel-next. Thanks Ville for the review.

Regards,
Uma Shankar
> > dig_port->dp.output_reg = INVALID_MMIO_REG;
> > dig_port->max_lanes = intel_ddi_max_lanes(dig_port);
> > dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
> > --
> > 2.26.2
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/edp: enable eDP Multi-SST Operation (MSO)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: enable eDP Multi-SST Operation (MSO)
URL   : https://patchwork.freedesktop.org/series/86992/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19665_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-hsw:  NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-hsw8/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-skl7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs1:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs1.html

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

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +44 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-skl7/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_ctx_persistence@replace-hostile:
- shard-hsw:  NOTRUN -> [SKIP][7] ([fdo#109271]) +64 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-hsw8/igt@gem_ctx_persiste...@replace-hostile.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2389])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-glk1/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@bcs0:
- shard-iclb: [PASS][14] -> [DMESG-WARN][15] ([i915#2803])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb6/igt@gem_exec_schedule@u-fairsl...@bcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@bcs0.html

  * igt@gem_exec_schedule@u-fairslice@vecs0:
- shard-tglb: [PASS][16] -> [DMESG-WARN][17] ([i915#2803])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-tglb8/igt@gem_exec_schedule@u-fairsl...@vecs0.html

  * igt@gem_exec_whisper@basic-contexts-priority:
- shard-glk:  [PASS][18] -> [DMESG-WARN][19] ([i915#118] / 
[i915#95])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk3/igt@gem_exec_whis...@basic-contexts-priority.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-glk9/igt@gem_exec_whis...@basic-contexts-priority.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-apl8/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][21] ([i915#2658])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-skl3/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@process-exit-mmap@wb:
- shard-apl:  NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/shard-apl3/igt@gem_userptr_blits@process-exit-m...@wb.html

  * igt@i915_selftest@mock@requests:
- shard-skl:  [PASS][23] -> [INCOMPLETE][24] ([i915#198])
   [23]: 

Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Chris Wilson]

Quoting Matthew Auld (2021-02-11 17:00:20)
> Throwing some color_adjust at it might be another option to consider. 
> Maybe something like:
> 
> +static void i915_ggtt_color_adjust_vdt(const struct drm_mm_node *node,
> +  unsigned long color,
> +  u64 *start,
> +  u64 *end)
> +{
> +   if (color == COLOR_VDT) {
> +   *start += VDT_PADDING;
> +   *end -= VDT_PADDING;
> +   return;
> +   }
> +
> +   if (node->allocated && node->color == COLOR_VDT)
> +   *start += VDT_PADDING;
> +
> +   node = list_next_entry(node, node_list);
> +   if (node->allocated && node->color == COLOR_VDT)
> +   *end -= VDT_PADDING;
> +}
> 
> But not sure if I would call that simpler. Plus we need to add more 
> special casing in the eviction code. And I guess the cache coloring 
> might also be active here, which might be nasty. Also we end up with a 
> bunch of holes in the address space that are unusable, yet the mm search 
> will keep hitting them anyway. Ok, I guess that's what you meant with 
> not introducing "extra nodes". Hmmm.

I considered trying to use coloring, but the problem I found was in
knowing whether or not to fill outside of the vma with scratch pages. We
would have to lookup each PTE to check it is not in use, then fill with
scratch. And if we removed a neighbour, it would have to check to see if
it should replace the guard pages. (And it's more complicated by the
wrap-around of the VT-d, an object at beginning of the GGTT would
overfetch into the pages at the other end of the GGTT.)

I felt that make an explicit reservation and accounting the VT-d
overfetch to the scanout vma would save a lot of hassle. The PTE are
accounted for (will not be reused, and safe to clear after resume),
dedicated as scratch for the overfetch and the overfetch cannot wrap
around as we force the vma to be away from the edges.

Packing the information into the single scanout i915_vma so that we do a
single padded i915_vma_insert seemed to be much easier to manage than
having to do additional i915_vma_inserts on either side (and so we have
to somehow manage searching for enough space for all 3 in the first call
etc). Plus i915_vma is already massive :|
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Matthew Auld]

On 11/02/2021 15:19, Chris Wilson wrote:

Quoting Matthew Auld (2021-02-11 14:25:41)

On 10/02/2021 23:39, Chris Wilson wrote:

VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 160 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.

If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Matthew Auld 
---
   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
   drivers/gpu/drm/i915/gt/intel_ggtt.c   | 37 --
   drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
   drivers/gpu/drm/i915/i915_vma.c| 23 ++
   drivers/gpu/drm/i915/i915_vma_types.h  |  1 +
   5 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0478b069c202..9f2ccc255ca1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
   if (ret)
   goto err;
   
+ if (intel_scanout_needs_vtd_wa(i915))

+ flags |= PIN_VTD;
+
   /*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index b0b8ded834f0..416f77f48561 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -238,6 +238,11 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
   
   gte = (gen8_pte_t __iomem *)ggtt->gsm;

   gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+ end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+ while (end < gte)
+ gen8_set_pte(end++, vm->scratch[0]->encode);
+
   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
   
   for_each_sgt_daddr(addr, iter, vma->pages)

@@ -245,6 +250,7 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
   GEM_BUG_ON(gte > end);
   
   /* Fill the allocated but "unused" space beyond the end of the buffer */

+ end += vma->guard / I915_GTT_PAGE_SIZE;
   while (gte < end)
   gen8_set_pte(gte++, vm->scratch[0]->encode);
   
@@ -289,6 +295,11 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm,
   
   gte = (gen6_pte_t __iomem *)ggtt->gsm;

   gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+ end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+ while (end < gte)
+ gen8_set_pte(end++, vm->scratch[0]->encode);
+
   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
   
   for_each_sgt_daddr(addr, iter, vma->pages)

@@ -296,6 +307,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
   GEM_BUG_ON(gte > end);
   
   /* Fill the allocated but "unused" space beyond the end of the buffer */

+ end += vma->guard / I915_GTT_PAGE_SIZE;
   while (gte < end)
   iowrite32(vm->scratch[0]->encode, gte++);
   
@@ -311,27 +323,6 @@ static void nop_clear_range(struct i915_address_space *vm,

   {
   }
   
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,

-   u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-  "First entry = %d; Num entries = %d (max=%d)\n",
-  first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(_base[i], scratch_pte);
-}
-
   static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
   {
   /*
@@ -898,8 +889,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
   ggtt->vm.cleanup = gen6_gmch_remove;
   ggtt->vm.insert_page = gen8_ggtt_insert_page;
   ggtt->vm.clear_range = 

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Ville Syrjälä]

On Thu, Feb 11, 2021 at 04:14:02PM +, Daniel Stone wrote:
> On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
>  wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == 
> > > true,
> > > then the driver is allowed to steal an unrelated pipe.
> > >
> > > Maybe i915 is stealing a pipe without allow_modeset?
> >
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
> 
> I think this is the salient point.
> 
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> >whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> >
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> >
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?
> 
> So from what I understand, if I enable CRTC 44 and the driver
> magically decides to split it up as a 'big-joiner' output, it will
> also steal CRTC 50 to work as the other half of the output. Then if I
> attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
> getting atomic completion events for both CRTC 44 and CRTC 50?
> 
> That's not OK from a userspace perspective. If you want to do magic to
> create the illusion of a single CRTC, then that magic needs to be
> consistent. At the moment it's the worst kind of magic: it does
> implicit things under the hood for you, but then leaks all of the
> behind-the-scenes detail into userspace.
> 
> Continuing with that would force us all to just ignore whatever events
> we see, because we can't reason about what they may be or why they're
> generated. Which doesn't allow for any kind of best practice in
> userspace.

You should only get externally visibile events for stuff in your
request. Or at least if that's not the case then the atomic
code is already bork regardless of bigjoiner.

-- 
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.IGT: failure for drm/i915/debugfs: HDCP capability enc NULL check (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3)
URL   : https://patchwork.freedesktop.org/series/86440/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19664_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@perf_pmu@cpu-hotplug:
- shard-iclb: [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb6/igt@perf_...@cpu-hotplug.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb7/igt@perf_...@cpu-hotplug.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-hsw:  NOTRUN -> [WARN][3] ([i915#2283])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@core_hotunp...@unbind-rebind.html

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

  * igt@gem_ctx_persistence@replace-hostile:
- shard-hsw:  NOTRUN -> [SKIP][5] ([fdo#109271]) +59 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/igt@gem_ctx_persiste...@replace-hostile.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-apl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +34 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl2/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_exec_create@forked:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk5/igt@gem_exec_cre...@forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-glk5/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

  * igt@gem_exec_schedule@u-fairslice@bcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][16] ([i915#1610])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl7/igt@gem_exec_schedule@u-fairsl...@bcs0.html

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / 
[i915#2803])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html

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

  * igt@gem_request_retire@retire-vma-not-inactive:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#2895])
   [21]: 

Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Chris Wilson]

Quoting Ville Syrjälä (2021-02-11 16:05:59)
> On Wed, Feb 10, 2021 at 11:39:46PM +, Chris Wilson wrote:
> > @@ -637,6 +642,13 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> > alignment, u64 flags)
> > alignment, vma->fence_alignment);
> >   }
> >  
> > + /* VT-d requires padding before/after the vma */
> > + if (flags & PIN_VTD) {
> > + alignment = max_t(typeof(alignment), alignment, VTD_GUARD);
> > + vma->guard = alignment;
> > + size += 2 * vma->guard;
> > + }
> > +
> >   GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
> >   GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
> >   GEM_BUG_ON(!is_power_of_2(alignment));
> someh> @@ -725,6 +737,11 @@ i915_vma_insert(struct i915_vma *vma, u64 size, 
> u64 alignment, u64 flags)
> >  
> >   list_add_tail(>vm_link, >vm->bound_list);
> >  
> > + if (flags & PIN_VTD) {
> > + vma->node.start += vma->guard;
> 
> Was a bit worried for a second that this might give the display
> a potentially misaligned vma start. But looks like you did consider
> all that: VTD_GUARD==POT, alignment + guard both get bumped
> to the max(). So AFAICS should guarantee everyone is happy.
> 
> I guess we're now wasting a lot more ggtt address space though?
> Not sure if anyone has ever been at risk of running out though.
> And DPT should help with this on new platforms.

Definitely this is a considerable bloat to most scanout buffers, which
for the sake of argument lets say are 8MiB. Still enough room for a flip
chain within the mappable portion, and when we get to scanouts that are
large enough to consume the majority of the GGTT, the fixed 2MiB of
padding is lost in the noise.

So handwaving it shouldn't lead to noticeably more thrashing of the
GGTT for existing platforms. There's too much recycling and too little
reuse of scanouts in current display systems for my liking, so the extra
25% overhead in GGTT updates is more likely to be a concern. (Though it
does balance out in that we now skip the clear after use.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Daniel Stone]

On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
 wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == 
> > true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.

I think this is the salient point.

> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
>whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?

So from what I understand, if I enable CRTC 44 and the driver
magically decides to split it up as a 'big-joiner' output, it will
also steal CRTC 50 to work as the other half of the output. Then if I
attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
getting atomic completion events for both CRTC 44 and CRTC 50?

That's not OK from a userspace perspective. If you want to do magic to
create the illusion of a single CRTC, then that magic needs to be
consistent. At the moment it's the worst kind of magic: it does
implicit things under the hood for you, but then leaks all of the
behind-the-scenes detail into userspace.

Continuing with that would force us all to just ignore whatever events
we see, because we can't reason about what they may be or why they're
generated. Which doesn't allow for any kind of best practice in
userspace.

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

Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Ville Syrjälä]

On Wed, Feb 10, 2021 at 11:39:46PM +, Chris Wilson wrote:
> VT-d may cause overfetch of the scanout PTE, both before and after the
> vma (depending on the scanout orientation). bspec recommends that we
> provide a tile-row in either directions, and suggests using 160 PTE,
> warning that the accesses will wrap around the ends of the GGTT.
> Currently, we fill the entire GGTT with scratch pages when using VT-d to
> always ensure there are valid entries around every vma, including
> scanout. However, writing every PTE is slow as on recent devices we
> perform 8MiB of uncached writes, incurring an extra 100ms during resume.
> 
> If instead we focus on only putting guard pages around scanout, we can
> avoid touching the whole GGTT. To avoid having to introduce extra nodes
> around each scanout vma, we adjust the scanout drm_mm_node to be smaller
> than the allocated space, and fixup the extra PTE during dma binding.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
>  drivers/gpu/drm/i915/gt/intel_ggtt.c   | 37 --
>  drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
>  drivers/gpu/drm/i915/i915_vma.c| 23 ++
>  drivers/gpu/drm/i915/i915_vma_types.h  |  1 +
>  5 files changed, 41 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 0478b069c202..9f2ccc255ca1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>   if (ret)
>   goto err;
>  
> + if (intel_scanout_needs_vtd_wa(i915))
> + flags |= PIN_VTD;
> +
>   /*
>* As the user may map the buffer once pinned in the display plane
>* (e.g. libkms for the bootup splash), we have to ensure that we
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index b0b8ded834f0..416f77f48561 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -238,6 +238,11 @@ static void gen8_ggtt_insert_entries(struct 
> i915_address_space *vm,
>  
>   gte = (gen8_pte_t __iomem *)ggtt->gsm;
>   gte += vma->node.start / I915_GTT_PAGE_SIZE;
> +
> + end = gte - vma->guard / I915_GTT_PAGE_SIZE;
> + while (end < gte)
> + gen8_set_pte(end++, vm->scratch[0]->encode);
> +
>   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
>  
>   for_each_sgt_daddr(addr, iter, vma->pages)
> @@ -245,6 +250,7 @@ static void gen8_ggtt_insert_entries(struct 
> i915_address_space *vm,
>   GEM_BUG_ON(gte > end);
>  
>   /* Fill the allocated but "unused" space beyond the end of the buffer */
> + end += vma->guard / I915_GTT_PAGE_SIZE;
>   while (gte < end)
>   gen8_set_pte(gte++, vm->scratch[0]->encode);
>  
> @@ -289,6 +295,11 @@ static void gen6_ggtt_insert_entries(struct 
> i915_address_space *vm,
>  
>   gte = (gen6_pte_t __iomem *)ggtt->gsm;
>   gte += vma->node.start / I915_GTT_PAGE_SIZE;
> +
> + end = gte - vma->guard / I915_GTT_PAGE_SIZE;
> + while (end < gte)
> + gen8_set_pte(end++, vm->scratch[0]->encode);
> +
>   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
>  
>   for_each_sgt_daddr(addr, iter, vma->pages)
> @@ -296,6 +307,7 @@ static void gen6_ggtt_insert_entries(struct 
> i915_address_space *vm,
>   GEM_BUG_ON(gte > end);
>  
>   /* Fill the allocated but "unused" space beyond the end of the buffer */
> + end += vma->guard / I915_GTT_PAGE_SIZE;
>   while (gte < end)
>   iowrite32(vm->scratch[0]->encode, gte++);
>  
> @@ -311,27 +323,6 @@ static void nop_clear_range(struct i915_address_space 
> *vm,
>  {
>  }
>  
> -static void gen8_ggtt_clear_range(struct i915_address_space *vm,
> -   u64 start, u64 length)
> -{
> - struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> - unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
> - unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
> - const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
> - gen8_pte_t __iomem *gtt_base =
> - (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
> - const int max_entries = ggtt_total_entries(ggtt) - first_entry;
> - int i;
> -
> - if (WARN(num_entries > max_entries,
> -  "First entry = %d; Num entries = %d (max=%d)\n",
> -  first_entry, num_entries, max_entries))
> - num_entries = max_entries;
> -
> - for (i = 0; i < num_entries; i++)
> - gen8_set_pte(_base[i], scratch_pte);
> -}
> -
>  static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
>  {
>   /*
> @@ -898,8 +889,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>   ggtt->vm.cleanup 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: enable eDP Multi-SST Operation (MSO)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: enable eDP Multi-SST Operation (MSO)
URL   : https://patchwork.freedesktop.org/series/86992/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19665


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

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

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-7500u:   [PASS][5] -> [DMESG-WARN][6] ([i915#2605])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/fi-kbl-7500u/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([i915#1161] / [i915#262])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19665/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

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

  
  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-guc fi-bsw-cyan 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19665

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19665: 0d0699a630feae8c87f2e42f3528f136da1b9f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0d0699a630fe drm/i915/edp: enable eDP MSO during link training
9c308043182f drm/i915/edp: modify fixed and downclock modes for MSO
cd771f8260ba drm/i915/mso: add splitter state check
2301619c19c5 drm/i915/mso: add splitter state readout for platforms that 
support it
3bcb25a97d79 drm/i915/reg: add stream splitter configuration definitions
bc496e99316f drm/i915/edp: read sink MSO configuration for eDP 1.4+
091e39294413 drm/i915/edp: always add fixed mode to probed modes in 
->get_modes()
dbf512a91559 drm/i915/edp: reject modes with dimensions other than fixed mode
f8c60f212290 drm/dp: add MSO related DPCD registers

== Logs ==

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

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

[Daniel Vetter]

On Wed, Feb 10, 2021 at 03:26:00PM -0800, Navare, Manasi wrote:
> On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter 
> > >  wrote:
> > > 
> > > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > > >
> > > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > > in case of big joiner used in i915 in which case even if the modeset
> > > > > is requested on a single pipe, internally another consecutive
> > > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > > So in this case it is expected that requested crtc and affected crtcs
> > > > > do not match. Hence the added WARN ON becomes irrelevant.
> > > 
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == 
> > > true,
> > > then the driver is allowed to steal an unrelated pipe.
> > > 
> > > Maybe i915 is stealing a pipe without allow_modeset?
> > 
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
> > 
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> >whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> > 
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> > 
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?

Yeah it's option d), because the warning is meant to catch funny uapi that
compositors don't want to deal with. So if this bigjoiner stuff in i915 is
_really_ fully transparent, then it's ok.

And excluding completely disabled CRTC from this check makes imo sense,
since userspace
- is not allowed to issue an atomic flip on these (it's off)
- is required to set allow_modeset to enable (at which point i915 can
  internally move CRTC assignments around however it feels like and it's
  all fine). Once that fully modeset is done we'd again be in sync with
  userspace's understanding of what's going on.
- hence there cannot be a spurious EBUSY to userspace

I think what this needs is a big comment in the code explaining why we can
afford to not check this.

> So as per the offline IRC discussions,
> - We can check for crtc_state->enable and only use the enabled crtcs
> in the affected crtc calculation. And this enable would only
> be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
> even if Pipe B is stolen, since no modeset and because that pipe doesnt
> get enabled the affected crtcs would still be 0x1.
> 
> This should solve the problem. 
> Ville, Danvet - I will make this change?

I think you volunteered :-)

Pls Cc: all the people involved in the original patch discussion, so that
they can ack the change too.

Cheers, Daniel
-- 
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] [PULL] drm-misc-next-fixes

[Maarten Lankhorst]

hi Dave,

Here a pull request for drm-misc-next-fixes, I'm not 100% sure about all the 
CEC fixes,
but seems like it wouldn't hurt. We could revert the flag that enables CEC if 
needed.

I just picked everything that looked like fixes from drm-misc-next.

drm-misc-next-fixes-2021-02-11:
drm-misc-next-fixes cherry picked from drm-misc-next for v5.12:
- Assorted small fixes.
- Disable and remove gma3600 support.
- Fix CEC for vc4/hdmi.
The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb:

  drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-02-11

for you to fetch changes up to e2183fb135a7f62d317aa1c61eb3d1919080edba:

  Revert "drm/scheduler: Job timeout handler returns status (v3)" (2021-02-10 
15:26:00 +0100)






drm-misc-next-fixes cherry picked from drm-misc-next for v5.12:
- Assorted small fixes.
- Disable and remove gma3600 support.
- Fix CEC for vc4/hdmi.


Bernard Zhao (1):
  drm/vc4: remove unneeded variable: "ret"

Dan Carpenter (2):
  drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources()
  drm/virtio: fix an error code in virtio_gpu_init()

Daniel Vetter (1):
  drm/todo: Add entry for moving to dma_resv_lock

Dom Cobley (5):
  drm/vc4: hdmi: Move hdmi reset to bind
  drm/vc4: hdmi: Fix register offset with longer CEC messages
  drm/vc4: hdmi: Fix up CEC registers
  drm/vc4: hdmi: Restore cec physical address on reconnect
  drm/vc4: hdmi: Remove cec_available flag

Imre Deak (1):
  drm/dp_mst: Don't cache EDIDs for physical ports

Joe Perches (1):
  dma-buf: Avoid comma separated statements

Joseph Schulte (1):
  drm: replace drm_modeset_lock_all() in drm_client_modeset_dpms_legacy()

Luben Tuikov (1):
  drm/scheduler: Job timeout handler returns status (v3)

Maarten Lankhorst (1):
  Revert "drm/scheduler: Job timeout handler returns status (v3)"

Maxime Ripard (7):
  drm/vc4: hdmi: Compute the CEC clock divider from the clock rate
  drm/vc4: hdmi: Update the CEC clock divider on HSM rate change
  drm/vc4: hdmi: Introduce a CEC clock
  drm/vc4: hdmi: Split the interrupt handlers
  drm/vc4: hdmi: Support BCM2711 CEC interrupt setup
  drm/vc4: hdmi: Don't register the CEC adapter if there's no interrupts
  dt-binding: display: bcm2711-hdmi: Add CEC and hotplug interrupts

Qinglang Miao (1):
  drm/lima: fix reference leak in lima_pm_busy

Thomas Zimmermann (4):
  drm/gma500: Remove Medfield support
  drm/gma500: Drop DRM_GMA3600 config option
  drm/gma500: Remove CONFIG_X86 conditionals from source files
  drm/gma500: Remove dependency on TTM

Ye Bin (1):
  drm/nouveau: remove set but not used variable ‘pdev’ in nouveau_bios_init

Zack Rusin (1):
  drm/vmwgfx: Fix some memory leaks on errors

 .../bindings/display/brcm,bcm2711-hdmi.yaml|   20 +-
 Documentation/gpu/todo.rst |   19 +
 drivers/dma-buf/st-dma-fence.c |7 +-
 drivers/gpu/drm/drm_client_modeset.c   |7 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  |3 +-
 drivers/gpu/drm/gma500/Kconfig |   17 +-
 drivers/gpu/drm/gma500/Makefile|   37 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|4 -
 drivers/gpu/drm/gma500/mdfld_device.c  |  564 ---
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 1017 
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.h |   79 --
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  603 
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |  377 
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c  |  679 -
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h  |   80 --
 drivers/gpu/drm/gma500/mdfld_intel_display.c   |  966 ---
 drivers/gpu/drm/gma500/mdfld_output.c  |   74 --
 drivers/gpu/drm/gma500/mdfld_output.h  |   76 --
 drivers/gpu/drm/gma500/mdfld_tmd_vid.c |  197 
 drivers/gpu/drm/gma500/mdfld_tpo_vid.c |   83 --
 drivers/gpu/drm/gma500/mmu.c   |   21 -
 drivers/gpu/drm/gma500/psb_drv.c   |   16 +-
 drivers/gpu/drm/gma500/psb_drv.h   |   66 --
 drivers/gpu/drm/gma500/psb_intel_reg.h |   12 +-
 drivers/gpu/drm/gma500/psb_irq.c   |   72 +-
 drivers/gpu/drm/gma500/psb_irq.h   |2 -
 drivers/gpu/drm/gma500/psb_reg.h   |   14 -
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c |  805 
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.h |   38 -
 drivers/gpu/drm/lima/lima_sched.c  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/edp: enable eDP Multi-SST Operation (MSO)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: enable eDP Multi-SST Operation (MSO)
URL   : https://patchwork.freedesktop.org/series/86992/
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"

Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup

[Daniel Vetter]

On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
> 
> On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> > On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
> >> This patch adds tracking of which cgroup to make charges against for a
> >> given GEM object.  We associate the current task's cgroup with GEM objects
> >> as they are created.  First user of this is for charging DRM cgroup for
> >> device memory allocations.  The intended behavior is for device drivers to
> >> make the cgroup charging calls at the time that backing store is allocated
> >> or deallocated for the object.
> >>
> >> Exported functions are provided for charging memory allocations for a
> >> GEM object to DRM cgroup. To aid in debugging, we store how many bytes
> >> have been charged inside the GEM object.  Add helpers for setting and
> >> clearing the object's associated cgroup which will check that charges are
> >> not being leaked.
> >>
> >> For shared objects, this may make the charge against a cgroup that is
> >> potentially not the same cgroup as the process using the memory.  Based
> >> on the memory cgroup's discussion of "memory ownership", this seems
> >> acceptable [1].
> >>
> >> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory 
> >> Ownership"
> >>
> >> Signed-off-by: Brian Welty 
> > 
> > Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that
> > counts everything, why don't we also charge in these gem functions?
> 
> I'm not sure what you mean exactly.  You want to merge/move the charging logic
> proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into
> drm_gem_object_charge_mem() ?
> 
> Or reading below, I think you are okay keeping the logic separated as is, but
> you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ?
> Yes, I see that should allow to reduce number of exported functions.

Both. I mean we'd need to look at the code again when it's shuffled, but
I'd say:

- cgroup code and the charging for general gpu memory moves to
  drivers/gpu/cgroup, so dma-buf heaps can use it too.

- the charging for gem buffers moves into core gem code, so it happens for
  all gpu drivers and all gem buffer allocations.

- this might or might not mean a bunch less exported stuff from the
  cgroups files (since you don't need separate steps for linking a gem
  object to a cgroup from the actual charging), and probably no exports
  anymore for drivers (since they charge nothing). That will change
  when we add charging for specific memory pools I guess, but we add that
  when we add tha functionality.

> > Also, that would remove the need for all these functions exported to
> > drivers. Plus the cgroups setup could also move fully into drm core code,
> > since all drivers (*) support it
> > That way this would really be a fully
> > generic cgroups controller, and we could land it.
> 
> 
> Patch #2 proposed to have a few setup functions called during drm device
> registration.
> You are suggesting to have this more tightly integrated?

Yeah essentially if DRIVER_GEM is set drm core would simply set this all
up. Since with this we'd always account all gem buffers in cgroups, and it
would make basic cgroup support a non-optional part of drm drivers.

> Okay, can see what that looks like.  It's true most of the exported functions 
> from
> kernel/cgroup/drm.c were taking a struct drm_device pointer, so seems it can 
> be
> restructured as you suggest.  But I guess we will always need some logic in
> kernel/cgroup/drm.c to encapsulate the allocation of the 'struct 
> cgroup_subsys_state'
> for this new controller.
> But I'm not sure I see how this makes the controller 'fully generic' as you 
> describe.

All DRIVER_GEM would automatacially support it. And yes there'll still be
some encapsulation ofc.

> > The other things I'd do:
> > - drop gpu scheduling controller from the initial patch series. Yes we'll
> >   need it, but we also need vram limits and all these things for full
> >   featured controller. Having the minimal viable cgroup controller in
> >   upstream would unblock all these other things, and we could discuss them
> >   in separate patch series, instead of one big bikeshed that never reaches
> >   full consensus.
> > 
> > - the xpu thing is probably real, I just chatted with Android people for
> >   their gpu memory accounting needs, and cgroups sounds like a solution
> >   for them too. But unlike on desktop/server linux, on Android all shared
> >   buffers are allocated from dma-buf heaps, so outside of drm, and hence a
> >   cgroup controller that's tightly tied to drm isn't that useful. So I
> >   think we should move the controller/charge functions up one level into
> >   drivers/gpu/cgroups.
> 
> Hmm, so for this, you are asking for the cgroup logic to not directly use
> DRM data structures?  Okay, that's why you suggest drivers/gpu/cgroups and
> not drivers/gpu/drm/cgroups.  So this is your angle to make it 'fully
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for lib: Add a YAML emitter (rev2)

[Patchwork]

== Series Details ==

Series: lib: Add a YAML emitter (rev2)
URL   : https://patchwork.freedesktop.org/series/73433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19662_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-hsw:  NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-hsw6/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-skl2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@close-replace-race:
- shard-apl:  [PASS][3] -> [TIMEOUT][4] ([i915#2918])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-apl1/igt@gem_ctx_persiste...@close-replace-race.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-apl6/igt@gem_ctx_persiste...@close-replace-race.html

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

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +42 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-skl2/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_ctx_persistence@replace-hostile:
- shard-hsw:  NOTRUN -> [SKIP][7] ([fdo#109271]) +59 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-hsw6/igt@gem_ctx_persiste...@replace-hostile.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-kbl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-kbl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl7/igt@gem_exec_fair@basic-f...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-kbl6/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html

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

  * igt@gem_exec_schedule@u-fairslice@vecs0:
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1610] / 
[i915#2803])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@gem_exec_schedule@u-fairsl...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-skl5/igt@gem_exec_schedule@u-fairsl...@vecs0.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-skl9/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@process-exit-mmap@wb:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-apl2/igt@gem_userptr_blits@process-exit-m...@wb.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#112306])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-iclb8/igt@gen9_exec_pa...@batch-without-end.html
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#112306])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/shard-tglb5/igt@gen9_exec_pa...@batch-without-end.html

  * igt@gen9_exec_parse@bb-oversize:
- shard-tglb: NOTRUN -> [SKIP][23] ([i915#2527])
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: HDCP capability enc NULL check (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3)
URL   : https://patchwork.freedesktop.org/series/86440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19664


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][1] -> [INCOMPLETE][2] ([i915#142] / 
[i915#2405])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/fi-byt-j1900/igt@i915_pm_...@module-reload.html

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

  * igt@runner@aborted:
- fi-byt-j1900:   NOTRUN -> [FAIL][5] ([i915#1814] / [i915#2505])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

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

  
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 39)
--

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


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19664

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19664: 27954b4312165647109af8223479a2ada9e7e36e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

27954b431216 drm/i915/debugfs: HDCP capability enc NULL check

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/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: Refine VT-d scanout workaround

[Chris Wilson]

Quoting Matthew Auld (2021-02-11 14:25:41)
> On 10/02/2021 23:39, Chris Wilson wrote:
> > VT-d may cause overfetch of the scanout PTE, both before and after the
> > vma (depending on the scanout orientation). bspec recommends that we
> > provide a tile-row in either directions, and suggests using 160 PTE,
> > warning that the accesses will wrap around the ends of the GGTT.
> > Currently, we fill the entire GGTT with scratch pages when using VT-d to
> > always ensure there are valid entries around every vma, including
> > scanout. However, writing every PTE is slow as on recent devices we
> > perform 8MiB of uncached writes, incurring an extra 100ms during resume.
> > 
> > If instead we focus on only putting guard pages around scanout, we can
> > avoid touching the whole GGTT. To avoid having to introduce extra nodes
> > around each scanout vma, we adjust the scanout drm_mm_node to be smaller
> > than the allocated space, and fixup the extra PTE during dma binding.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Matthew Auld 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
> >   drivers/gpu/drm/i915/gt/intel_ggtt.c   | 37 --
> >   drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
> >   drivers/gpu/drm/i915/i915_vma.c| 23 ++
> >   drivers/gpu/drm/i915/i915_vma_types.h  |  1 +
> >   5 files changed, 41 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > index 0478b069c202..9f2ccc255ca1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > @@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> >   if (ret)
> >   goto err;
> >   
> > + if (intel_scanout_needs_vtd_wa(i915))
> > + flags |= PIN_VTD;
> > +
> >   /*
> >* As the user may map the buffer once pinned in the display plane
> >* (e.g. libkms for the bootup splash), we have to ensure that we
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index b0b8ded834f0..416f77f48561 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -238,6 +238,11 @@ static void gen8_ggtt_insert_entries(struct 
> > i915_address_space *vm,
> >   
> >   gte = (gen8_pte_t __iomem *)ggtt->gsm;
> >   gte += vma->node.start / I915_GTT_PAGE_SIZE;
> > +
> > + end = gte - vma->guard / I915_GTT_PAGE_SIZE;
> > + while (end < gte)
> > + gen8_set_pte(end++, vm->scratch[0]->encode);
> > +
> >   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
> >   
> >   for_each_sgt_daddr(addr, iter, vma->pages)
> > @@ -245,6 +250,7 @@ static void gen8_ggtt_insert_entries(struct 
> > i915_address_space *vm,
> >   GEM_BUG_ON(gte > end);
> >   
> >   /* Fill the allocated but "unused" space beyond the end of the buffer 
> > */
> > + end += vma->guard / I915_GTT_PAGE_SIZE;
> >   while (gte < end)
> >   gen8_set_pte(gte++, vm->scratch[0]->encode);
> >   
> > @@ -289,6 +295,11 @@ static void gen6_ggtt_insert_entries(struct 
> > i915_address_space *vm,
> >   
> >   gte = (gen6_pte_t __iomem *)ggtt->gsm;
> >   gte += vma->node.start / I915_GTT_PAGE_SIZE;
> > +
> > + end = gte - vma->guard / I915_GTT_PAGE_SIZE;
> > + while (end < gte)
> > + gen8_set_pte(end++, vm->scratch[0]->encode);
> > +
> >   end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
> >   
> >   for_each_sgt_daddr(addr, iter, vma->pages)
> > @@ -296,6 +307,7 @@ static void gen6_ggtt_insert_entries(struct 
> > i915_address_space *vm,
> >   GEM_BUG_ON(gte > end);
> >   
> >   /* Fill the allocated but "unused" space beyond the end of the buffer 
> > */
> > + end += vma->guard / I915_GTT_PAGE_SIZE;
> >   while (gte < end)
> >   iowrite32(vm->scratch[0]->encode, gte++);
> >   
> > @@ -311,27 +323,6 @@ static void nop_clear_range(struct i915_address_space 
> > *vm,
> >   {
> >   }
> >   
> > -static void gen8_ggtt_clear_range(struct i915_address_space *vm,
> > -   u64 start, u64 length)
> > -{
> > - struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> > - unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
> > - unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
> > - const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
> > - gen8_pte_t __iomem *gtt_base =
> > - (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
> > - const int max_entries = ggtt_total_entries(ggtt) - first_entry;
> > - int i;
> > -
> > - if (WARN(num_entries > max_entries,
> > -  "First entry = %d; Num entries = %d (max=%d)\n",
> > -  first_entry, num_entries, max_entries))
> > - num_entries = max_entries;
> > -
> > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Ratelimit heartbeat completion probing (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev8)
URL   : https://patchwork.freedesktop.org/series/86665/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19663


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bdw-5557u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-ehl-1}: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-ehl-1/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-ehl-1/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@memory-alloc:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-tgl-y/igt@amdgpu/amd_ba...@memory-alloc.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [PASS][6] -> [DMESG-WARN][7] ([i915#2411] / 
[i915#402])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#2782])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
- fi-ivb-3770:[PASS][10] -> [INCOMPLETE][11] ([i915#2782])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-ivb-3770/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-ivb-3770/igt@i915_selftest@live@gt_heartbeat.html
- fi-tgl-u2:  [PASS][12] -> [INCOMPLETE][13] ([i915#2601])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-u2/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-tgl-u2/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][16] ([i915#2369])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-bdw-5557u/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][17] ([i915#1436] / [i915#2295] / 
[i915#2505])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19663/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

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

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

  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
  [i915#2369]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Probe system memory regions before enabling HW

[Patchwork]

== Series Details ==

Series: drm/i915: Probe system memory regions before enabling HW
URL   : https://patchwork.freedesktop.org/series/86984/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19660_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### Piglit changes ###

 Possible regressions 

  * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat2_2 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/pig-icl-1065g7/spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat2_2.html

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-mat3x2_2 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][2] +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/pig-icl-1065g7/spec@arb_tessellation_shader@execution@tes-input@tes-input-mat3x2_2.html

  
New tests
-

  New tests have been introduced between CI_DRM_9761_full and 
Patchwork_19660_full:

### New Piglit tests (10) ###

  * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-gl_position:
- Statuses : 1 crash(s)
- Exec time: [0.49] s

  * spec@arb_tessellation_shader@execution@tcs-input@tcs-input-mat2_2:
- Statuses : 1 crash(s)
- Exec time: [0.50] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-ivec3_2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-mat3_2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-mat3x2_2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-patch-float_2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-patch-mat4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-patch-uvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-patch-vec4_2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@arb_tessellation_shader@execution@tes-input@tes-input-uvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-skl5/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][4] -> [INCOMPLETE][5] ([i915#146] / [i915#198])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl2/igt@gem_ctx_isolation@preservation...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +44 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-skl5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#2502])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb1/igt@gem_exec_endless@dispa...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-iclb6/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 

[Intel-gfx] [PATCH v3 9/9] drm/i915/edp: enable eDP MSO during link training

[Jani Nikula]

If the source and sink support MSO, enable it during link training.

v3: Adjust timings, refer to splitter

v2: Limit MSO to pipe A using ->pipe_mask

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 37 
 drivers/gpu/drm/i915/display/intel_display.c | 13 +++
 drivers/gpu/drm/i915/display/intel_dp.c  | 34 --
 3 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c9098297b6ac..5a8d1abd208a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2167,6 +2167,34 @@ static void intel_ddi_mso_get_config(struct 
intel_encoder *encoder,
pipe_config->splitter.pixel_overlap = 
REG_FIELD_GET(OVERLAP_PIXELS_MASK, dss1);
 }
 
+static void intel_ddi_mso_configure(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u32 dss1 = 0;
+
+   if (!HAS_MSO(i915))
+   return;
+
+   if (crtc_state->splitter.enable) {
+   /* Splitter enable is supported for pipe A only. */
+   if (drm_WARN_ON(>drm, pipe != PIPE_A))
+   return;
+
+   dss1 |= SPLITTER_ENABLE;
+   dss1 |= OVERLAP_PIXELS(crtc_state->splitter.pixel_overlap);
+   if (crtc_state->splitter.link_count == 2)
+   dss1 |= SPLITTER_CONFIGURATION_2_SEGMENT;
+   else
+   dss1 |= SPLITTER_CONFIGURATION_4_SEGMENT;
+   }
+
+   intel_de_rmw(i915, ICL_PIPE_DSS_CTL1(pipe),
+SPLITTER_ENABLE | SPLITTER_CONFIGURATION_MASK |
+OVERLAP_PIXELS_MASK, dss1);
+}
+
 static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
  struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state,
@@ -2260,6 +2288,11 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
 */
intel_ddi_power_up_lanes(encoder, crtc_state);
 
+   /*
+* 7.g Program CoG/MSO configuration bits in DSS_CTL1 if selected.
+*/
+   intel_ddi_mso_configure(crtc_state);
+
/*
 * 7.g Configure and enable DDI_BUF_CTL
 * 7.h Wait for DDI_BUF_CTL DDI Idle Status = 0b (Not Idle), timeout
@@ -4143,6 +4176,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
goto err;
 
dig_port->hpd_pulse = intel_dp_hpd_pulse;
+
+   /* Splitter enable for eDP MSO is supported for pipe A only. */
+   if (dig_port->dp.mso_link_count)
+   encoder->pipe_mask = BIT(PIPE_A);
}
 
/* In theory we don't need the encoder->type check, but leave it just in
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 3059a07b8c36..06b7edbe1187 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4917,6 +4917,19 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
pipe_config->pipe_src_w /= 2;
}
 
+   if (pipe_config->splitter.enable) {
+   int n = pipe_config->splitter.link_count;
+   int overlap = pipe_config->splitter.pixel_overlap;
+
+   pipe_mode->crtc_hdisplay = (pipe_mode->crtc_hdisplay - overlap) 
* n;
+   pipe_mode->crtc_hblank_start = (pipe_mode->crtc_hblank_start - 
overlap) * n;
+   pipe_mode->crtc_hblank_end = (pipe_mode->crtc_hblank_end - 
overlap) * n;
+   pipe_mode->crtc_hsync_start = (pipe_mode->crtc_hsync_start - 
overlap) * n;
+   pipe_mode->crtc_hsync_end = (pipe_mode->crtc_hsync_end - 
overlap) * n;
+   pipe_mode->crtc_htotal = (pipe_mode->crtc_htotal - overlap) * n;
+   pipe_mode->crtc_clock *= n;
+   }
+
intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
 
if (INTEL_GEN(dev_priv) < 4) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5d5b16f70ed2..8f39da994d14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1745,6 +1745,10 @@ intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
   intel_connector->panel.downclock_mode->clock,
   pipe_config->port_clock, _config->dp_m2_n2,
   constant_n, pipe_config->fec_enable);
+
+   /* FIXME: abstract this better */
+   if (pipe_config->splitter.enable)
+   pipe_config->dp_m2_n2.gmch_m *= 
pipe_config->splitter.link_count;
 }

[Intel-gfx] [PATCH v3 8/9] drm/i915/edp: modify fixed and downclock modes for MSO

[Jani Nikula]

In the case of MSO (Multi-SST Operation), the EDID contains the timings
for a single panel segment. We'll want to hide the fact from userspace,
and expose modes that span the entire display.

Don't modify the EDID, as the userspace should not use that for
modesetting, only modify the actual modes.

v3: Use pixel overlap if available.

v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 48e65b9a967a..5d5b16f70ed2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3516,6 +3516,31 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
*intel_dp)
}
 }
 
+static void intel_edp_mso_mode_fixup(struct intel_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   int n = intel_dp->mso_link_count;
+   int overlap = intel_dp->mso_pixel_overlap;
+
+   if (!mode || !n)
+   return;
+
+   mode->hdisplay = (mode->hdisplay - overlap) * n;
+   mode->hsync_start = (mode->hsync_start - overlap) * n;
+   mode->hsync_end = (mode->hsync_end - overlap) * n;
+   mode->htotal = (mode->htotal - overlap) * n;
+   mode->clock *= n;
+
+   drm_mode_set_name(mode);
+
+   drm_dbg_kms(>drm,
+   "[CONNECTOR:%d:%s] using generated MSO mode: ",
+   connector->base.base.id, connector->base.name);
+   drm_mode_debug_printmodeline(mode);
+}
+
 static void intel_edp_mso_init(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -6493,6 +6518,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
if (fixed_mode)
downclock_mode = intel_dp_drrs_init(intel_connector, 
fixed_mode);
 
+   /* multiply the mode clock and horizontal timings for MSO */
+   intel_edp_mso_mode_fixup(intel_connector, fixed_mode);
+   intel_edp_mso_mode_fixup(intel_connector, downclock_mode);
+
/* fallback to VBT if available for eDP */
if (!fixed_mode)
fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 7/9] drm/i915/mso: add splitter state check

[Jani Nikula]

For starters, we expect the state to be zero, as we don't enable MSO
anywhere.

v2: Refer to splitter.

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index fe9985bd5786..3059a07b8c36 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9326,6 +9326,10 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(dsc.dsc_split);
PIPE_CONF_CHECK_I(dsc.compressed_bpp);
 
+   PIPE_CONF_CHECK_BOOL(splitter.enable);
+   PIPE_CONF_CHECK_I(splitter.link_count);
+   PIPE_CONF_CHECK_I(splitter.pixel_overlap);
+
PIPE_CONF_CHECK_I(mst_master_transcoder);
 
PIPE_CONF_CHECK_BOOL(vrr.enable);
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 6/9] drm/i915/mso: add splitter state readout for platforms that support it

[Jani Nikula]

Add splitter configuration to crtc state, and read it where
supported. Also add splitter state dumping. The stream splitter will be
required for eDP MSO.

v3:
- Convert segment timings to full panel timings.
- Refer to splitter instead of mso in crtc state.
- Dump splitter state.

v2: Add warning for mso being enabled on pipes other than A.

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  | 37 +++
 drivers/gpu/drm/i915/display/intel_display.c  | 31 +++-
 .../drm/i915/display/intel_display_types.h|  7 
 drivers/gpu/drm/i915/i915_drv.h   |  2 +
 4 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3c4003605f93..c9098297b6ac 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2132,6 +2132,41 @@ static void intel_ddi_power_up_lanes(struct 
intel_encoder *encoder,
}
 }
 
+static void intel_ddi_mso_get_config(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
+{
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u32 dss1;
+
+   if (!HAS_MSO(i915))
+   return;
+
+   dss1 = intel_de_read(i915, ICL_PIPE_DSS_CTL1(pipe));
+
+   pipe_config->splitter.enable = dss1 & SPLITTER_ENABLE;
+   if (!pipe_config->splitter.enable)
+   return;
+
+   /* Splitter enable is supported for pipe A only. */
+   if (drm_WARN_ON(>drm, pipe != PIPE_A)) {
+   pipe_config->splitter.enable = false;
+   return;
+   }
+
+   switch (dss1 & SPLITTER_CONFIGURATION_MASK) {
+   case SPLITTER_CONFIGURATION_2_SEGMENT:
+   pipe_config->splitter.link_count = 2;
+   break;
+   case SPLITTER_CONFIGURATION_4_SEGMENT:
+   pipe_config->splitter.link_count = 4;
+   break;
+   }
+
+   pipe_config->splitter.pixel_overlap = 
REG_FIELD_GET(OVERLAP_PIXELS_MASK, dss1);
+}
+
 static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
  struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state,
@@ -3322,6 +3357,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
intel_ddi_read_func_ctl(encoder, pipe_config);
}
 
+   intel_ddi_mso_get_config(encoder, pipe_config);
+
pipe_config->has_audio =
intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index beed08c00b6c..fe9985bd5786 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4856,8 +4856,30 @@ static void intel_crtc_readout_derived_state(struct 
intel_crtc_state *crtc_state
pipe_mode->crtc_clock /= 2;
}
 
-   intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
-   intel_mode_from_crtc_timings(adjusted_mode, adjusted_mode);
+   if (crtc_state->splitter.enable) {
+   int n = crtc_state->splitter.link_count;
+   int overlap = crtc_state->splitter.pixel_overlap;
+
+   /*
+* eDP MSO uses segment timings from EDID for transcoder
+* timings, but full mode for everything else.
+*
+* h_full = (h_segment - pixel_overlap) * link_count
+*/
+   pipe_mode->crtc_hdisplay = (pipe_mode->crtc_hdisplay - overlap) 
* n;
+   pipe_mode->crtc_hblank_start = (pipe_mode->crtc_hblank_start - 
overlap) * n;
+   pipe_mode->crtc_hblank_end = (pipe_mode->crtc_hblank_end - 
overlap) * n;
+   pipe_mode->crtc_hsync_start = (pipe_mode->crtc_hsync_start - 
overlap) * n;
+   pipe_mode->crtc_hsync_end = (pipe_mode->crtc_hsync_end - 
overlap) * n;
+   pipe_mode->crtc_htotal = (pipe_mode->crtc_htotal - overlap) * n;
+   pipe_mode->crtc_clock *= n;
+
+   intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
+   intel_mode_from_crtc_timings(adjusted_mode, pipe_mode);
+   } else {
+   intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
+   intel_mode_from_crtc_timings(adjusted_mode, adjusted_mode);
+   }
 
intel_crtc_compute_pixel_rate(crtc_state);
 
@@ -8259,6 +8281,11 @@ static void intel_dump_pipe_config(const struct 
intel_crtc_state *pipe_config,
pipe_config->bigjoiner_slave ? "slave" :
pipe_config->bigjoiner ? "master" : "no");
 
+   drm_dbg_kms(_priv->drm, "splitter: %s, link count %d, overlap %d\n",
+

[Intel-gfx] [PATCH v3 5/9] drm/i915/reg: add stream splitter configuration definitions

[Jani Nikula]

The splitter configuration is required for eDP MSO.

Bspec: 50174
Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 224ad897af34..e5dd0203991b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11448,6 +11448,9 @@ enum skl_power_gate {
 #define  BIG_JOINER_ENABLE (1 << 29)
 #define  MASTER_BIG_JOINER_ENABLE  (1 << 28)
 #define  VGA_CENTERING_ENABLE  (1 << 27)
+#define  SPLITTER_CONFIGURATION_MASK   REG_GENMASK(26, 25)
+#define  SPLITTER_CONFIGURATION_2_SEGMENT  
REG_FIELD_PREP(SPLITTER_CONFIGURATION_MASK, 0)
+#define  SPLITTER_CONFIGURATION_4_SEGMENT  
REG_FIELD_PREP(SPLITTER_CONFIGURATION_MASK, 1)
 
 #define _ICL_PIPE_DSS_CTL2_PB  0x78204
 #define _ICL_PIPE_DSS_CTL2_PC  0x78404
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 4/9] drm/i915/edp: read sink MSO configuration for eDP 1.4+

[Jani Nikula]

Read and debug log the eDP sink MSO configuration. Do not actually do
anything with the information yet besides logging.

FIXME: The pixel overlap is present in DisplayID 2.0, but we don't have
parsing for that. Assume zero for now. We could also add quirks for
non-zero pixel overlap before DisplayID 2.0 parsing.

v3: Add placeholder for pixel overlap.

v2: Rename intel_dp_mso_init -> intel_edp_mso_init

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 33 +++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ebaa9d0ed376..71611b596c88 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1487,6 +1487,8 @@ struct intel_dp {
int max_link_lane_count;
/* Max rate for the current link */
int max_link_rate;
+   int mso_link_count;
+   int mso_pixel_overlap;
/* sink or branch descriptor */
struct drm_dp_desc desc;
struct drm_dp_aux aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8d7ca03453e5..48e65b9a967a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3516,6 +3516,37 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
*intel_dp)
}
 }
 
+static void intel_edp_mso_init(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 mso;
+
+   if (intel_dp->edp_dpcd[0] < DP_EDP_14)
+   return;
+
+   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_MSO_LINK_CAPABILITIES, 
) != 1) {
+   drm_err(>drm, "Failed to read MSO cap\n");
+   return;
+   }
+
+   /* Valid configurations are SST or MSO 2x1, 2x2, 4x1 */
+   mso &= DP_EDP_MSO_NUMBER_OF_LINKS_MASK;
+   if (mso % 2 || mso > drm_dp_max_lane_count(intel_dp->dpcd)) {
+   drm_err(>drm, "Invalid MSO link count cap %u\n", mso);
+   mso = 0;
+   }
+
+   if (mso) {
+   drm_dbg_kms(>drm, "Sink MSO %ux%u configuration\n",
+   mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso);
+   drm_err(>drm, "No source MSO support, disabling\n");
+   mso = 0;
+   }
+
+   intel_dp->mso_link_count = mso;
+   intel_dp->mso_pixel_overlap = 0; /* FIXME: read from DisplayID v2.0 */
+}
+
 static bool
 intel_edp_init_dpcd(struct intel_dp *intel_dp)
 {
@@ -3599,6 +3630,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 */
intel_edp_init_source_oui(intel_dp, true);
 
+   intel_edp_mso_init(intel_dp);
+
return true;
 }
 
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 3/9] drm/i915/edp: always add fixed mode to probed modes in ->get_modes()

[Jani Nikula]

Unconditionally add fixed mode to probed modes even if EDID is present
and has modes. Prepare for cases where the fixed mode is not present in
EDID (such as eDP MSO).

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 169b44c8ebbc..8d7ca03453e5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5547,19 +5547,18 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
struct edid *edid;
+   int num_modes = 0;
 
edid = intel_connector->detect_edid;
if (edid) {
-   int ret = intel_connector_update_modes(connector, edid);
+   num_modes = intel_connector_update_modes(connector, edid);
 
if (intel_vrr_is_capable(connector))
drm_connector_set_vrr_capable_property(connector,
   true);
-   if (ret)
-   return ret;
}
 
-   /* if eDP has no EDID, fall back to fixed mode */
+   /* Also add fixed mode, which may or may not be present in EDID */
if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
intel_connector->panel.fixed_mode) {
struct drm_display_mode *mode;
@@ -5568,10 +5567,13 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
  intel_connector->panel.fixed_mode);
if (mode) {
drm_mode_probed_add(connector, mode);
-   return 1;
+   num_modes++;
}
}
 
+   if (num_modes)
+   return num_modes;
+
if (!edid) {
struct intel_dp *intel_dp = intel_attached_dp(intel_connector);
struct drm_display_mode *mode;
@@ -5581,11 +5583,11 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
  intel_dp->downstream_ports);
if (mode) {
drm_mode_probed_add(connector, mode);
-   return 1;
+   num_modes++;
}
}
 
-   return 0;
+   return num_modes;
 }
 
 static int
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 2/9] drm/i915/edp: reject modes with dimensions other than fixed mode

[Jani Nikula]

Be more strict about filtering modes for eDP.

Cc: Nischal Varide 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4f89e0de5dde..169b44c8ebbc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -789,10 +789,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_H_ILLEGAL;
 
if (intel_dp_is_edp(intel_dp) && fixed_mode) {
-   if (mode->hdisplay > fixed_mode->hdisplay)
+   if (mode->hdisplay != fixed_mode->hdisplay)
return MODE_PANEL;
 
-   if (mode->vdisplay > fixed_mode->vdisplay)
+   if (mode->vdisplay != fixed_mode->vdisplay)
return MODE_PANEL;
 
target_clock = fixed_mode->clock;
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 1/9] drm/dp: add MSO related DPCD registers

[Jani Nikula]

Add DPCD register definitions for eDP 1.4 Multi-SST Operation.

Cc: Nischal Varide 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 include/drm/drm_dp_helper.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index edffd1dcca3e..632ad7faa006 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1016,6 +1016,11 @@ struct drm_device;
 #define DP_EDP_REGIONAL_BACKLIGHT_BASE  0x740/* eDP 1.4 */
 #define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */
 
+#define DP_EDP_MSO_LINK_CAPABILITIES0x7a4/* eDP 1.4 */
+# define DP_EDP_MSO_NUMBER_OF_LINKS_MASK(7 << 0)
+# define DP_EDP_MSO_NUMBER_OF_LINKS_SHIFT   0
+# define DP_EDP_MSO_INDEPENDENT_LINK_BIT(1 << 3)
+
 /* Sideband MSG Buffers */
 #define DP_SIDEBAND_MSG_DOWN_REQ_BASE  0x1000   /* 1.2 MST */
 #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200   /* 1.2 MST */
-- 
2.20.1

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

[Intel-gfx] [PATCH v3 0/9] drm/i915/edp: enable eDP Multi-SST Operation (MSO)

[Jani Nikula]

This series enables eDP Multi-SST Operation (MSO) on TGL+.

MSO splits the full panel into 2 or 4 segments horizontally. The EDID contains
timings for one segment, and we'll need to use them for transcoder timings as
well as data M/N calculation. We shove the segment timings to
adjusted_mode->crtc_*. Otherwise, we'll need to use full panel timings.

There's a bunch of back and forth conversion to transparently present the full
mode to userspace. Not sure if there's a better way as different places require
conversion of different fields. Otherwise the splitter configuration is trivial.

The segments may include 0-8 pixels overlap. The overlap is defined in DisplayID
2.0 for which we don't have parsing. Hopefully we can insert the overlap in one
place if required, however this has not been tested as the panel at hand does
not use overlap.


BR,
Jani.


Jani Nikula (9):
  drm/dp: add MSO related DPCD registers
  drm/i915/edp: reject modes with dimensions other than fixed mode
  drm/i915/edp: always add fixed mode to probed modes in ->get_modes()
  drm/i915/edp: read sink MSO configuration for eDP 1.4+
  drm/i915/reg: add stream splitter configuration definitions
  drm/i915/mso: add splitter state readout for platforms that support it
  drm/i915/mso: add splitter state check
  drm/i915/edp: modify fixed and downclock modes for MSO
  drm/i915/edp: enable eDP MSO during link training

 drivers/gpu/drm/i915/display/intel_ddi.c  |  74 
 drivers/gpu/drm/i915/display/intel_display.c  |  48 +++-
 .../drm/i915/display/intel_display_types.h|   9 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 112 --
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 include/drm/drm_dp_helper.h   |   5 +
 7 files changed, 242 insertions(+), 11 deletions(-)

-- 
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: success for drm/i915/display: Handle lane polarity for DDI port

[Patchwork]

== Series Details ==

Series: drm/i915/display: Handle lane polarity for DDI port
URL   : https://patchwork.freedesktop.org/series/86983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19659_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][1] ([i915#180])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-apl8/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][2] -> [FAIL][3] ([i915#2846])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-kbl1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2842]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2389])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html

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

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1610] / 
[i915#2803])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@gem_exec_schedule@u-fairsl...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-skl4/igt@gem_exec_schedule@u-fairsl...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@vcs1:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#2803])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vcs1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-tglb6/igt@gem_exec_schedule@u-fairsl...@vcs1.html

  * igt@gem_exec_whisper@basic-queues-priority:
- shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#1895])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb7/igt@gem_exec_whis...@basic-queues-priority.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-iclb7/igt@gem_exec_whis...@basic-queues-priority.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][17] -> [SKIP][18] ([i915#2190])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-apl1/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-skl6/igt@gem_pr...@exhaustion.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#112306])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-iclb1/igt@gen9_exec_pa...@batch-without-end.html

  * igt@gen9_exec_parse@bb-oversize:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#2527])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-iclb1/igt@gen9_exec_pa...@bb-oversize.html

  * igt@i915_pm_lpsp@screens-disabled:
- shard-iclb: NOTRUN -> [SKIP][23] ([i915#1902])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/shard-iclb1/igt@i915_pm_l...@screens-disabled.html

  * igt@kms_async_flips@test-time-stamp:
- shard-tglb: [PASS][24] -> [FAIL][25] ([i915#2597])
   [24]: 

Re: [Intel-gfx] [PATCH] drm/i915: Refine VT-d scanout workaround

[Matthew Auld]

On 10/02/2021 23:39, Chris Wilson wrote:

VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 160 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.

If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
  drivers/gpu/drm/i915/gt/intel_ggtt.c   | 37 --
  drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
  drivers/gpu/drm/i915/i915_vma.c| 23 ++
  drivers/gpu/drm/i915/i915_vma_types.h  |  1 +
  5 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0478b069c202..9f2ccc255ca1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
if (ret)
goto err;
  
+	if (intel_scanout_needs_vtd_wa(i915))

+   flags |= PIN_VTD;
+
/*
 * As the user may map the buffer once pinned in the display plane
 * (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index b0b8ded834f0..416f77f48561 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -238,6 +238,11 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
  
  	gte = (gen8_pte_t __iomem *)ggtt->gsm;

gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+   end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+   while (end < gte)
+   gen8_set_pte(end++, vm->scratch[0]->encode);
+
end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
  
  	for_each_sgt_daddr(addr, iter, vma->pages)

@@ -245,6 +250,7 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
GEM_BUG_ON(gte > end);
  
  	/* Fill the allocated but "unused" space beyond the end of the buffer */

+   end += vma->guard / I915_GTT_PAGE_SIZE;
while (gte < end)
gen8_set_pte(gte++, vm->scratch[0]->encode);
  
@@ -289,6 +295,11 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm,
  
  	gte = (gen6_pte_t __iomem *)ggtt->gsm;

gte += vma->node.start / I915_GTT_PAGE_SIZE;
+
+   end = gte - vma->guard / I915_GTT_PAGE_SIZE;
+   while (end < gte)
+   gen8_set_pte(end++, vm->scratch[0]->encode);
+
end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
  
  	for_each_sgt_daddr(addr, iter, vma->pages)

@@ -296,6 +307,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
GEM_BUG_ON(gte > end);
  
  	/* Fill the allocated but "unused" space beyond the end of the buffer */

+   end += vma->guard / I915_GTT_PAGE_SIZE;
while (gte < end)
iowrite32(vm->scratch[0]->encode, gte++);
  
@@ -311,27 +323,6 @@ static void nop_clear_range(struct i915_address_space *vm,

  {
  }
  
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,

- u64 start, u64 length)
-{
-   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
-   unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
-   unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
-   const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
-   gen8_pte_t __iomem *gtt_base =
-   (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
-   const int max_entries = ggtt_total_entries(ggtt) - first_entry;
-   int i;
-
-   if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
-   num_entries = max_entries;
-
-   for (i = 0; i < num_entries; i++)
-   gen8_set_pte(_base[i], scratch_pte);
-}
-
  static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
  {
/*
@@ -898,8 +889,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
-   if (intel_scanout_needs_vtd_wa(i915))
-  

[Intel-gfx] [PATCH v2] drm/i915/debugfs: HDCP capability enc NULL check

[Anshuman Gupta]

DP-MST connector encoder initializes at modeset
Adding a connector->encoder NULL check in order to
avoid any NULL pointer dereference.
intel_hdcp_enable() already handle this but debugfs
can also invoke the intel_{hdcp,hdcp2_capable}.
Handling it gracefully.

v2:
- Use necessary lock and NULL check in
  i915_hdcp_sink_capability_show. [Imre]

Reviewed-by: Imre Deak 
Signed-off-by: Anshuman Gupta 
---
 .../drm/i915/display/intel_display_debugfs.c| 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d6e4a9237bda..8af663b84314 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2198,16 +2198,27 @@ DEFINE_SHOW_ATTRIBUTE(i915_panel);
 static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
 {
struct drm_connector *connector = m->private;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
+   int ret;
 
-   if (connector->status != connector_status_connected)
-   return -ENODEV;
+   ret = 
drm_modeset_lock_single_interruptible(>drm.mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   if (!connector->encoder || connector->status != 
connector_status_connected) {
+   ret = -ENODEV;
+   goto out;
+   }
 
seq_printf(m, "%s:%d HDCP version: ", connector->name,
   connector->base.id);
intel_hdcp_info(m, intel_connector);
 
-   return 0;
+out:
+   drm_modeset_unlock(>drm.mode_config.connection_mutex);
+
+   return ret;
 }
 DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
 
-- 
2.26.2

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

Re: [Intel-gfx] [PATCH stable-5.10 2/2] drm/i915: Skip vswing programming for TBT

[Greg KH]

On Mon, Feb 08, 2021 at 07:53:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> commit eaf5bfe37db871031232d2bf2535b6ca92afbad8 upstream.
> 
> In thunderbolt mode the PHY is owned by the thunderbolt controller.
> We are not supposed to touch it. So skip the vswing programming
> as well (we already skipped the other steps not applicable to TBT).
> 
> Touching this stuff could supposedly interfere with the PHY
> programming done by the thunderbolt controller.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrj...@linux.intel.com
> Reviewed-by: Imre Deak 
> (cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3)
> Signed-off-by: Jani Nikula 
> (cherry picked from commit eaf5bfe37db871031232d2bf2535b6ca92afbad8)
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
>  1 file changed, 6 insertions(+)

Both n ow queued up,t hanks.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Add a YAML emitter (rev2)

[Patchwork]

== Series Details ==

Series: lib: Add a YAML emitter (rev2)
URL   : https://patchwork.freedesktop.org/series/73433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19662


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#2411] / 
[i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_sync@basic-all:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_s...@basic-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/fi-tgl-y/igt@gem_s...@basic-all.html

  
 Possible fixes 

  * igt@gem_render_tiled_blits@basic:
- fi-tgl-y:   [DMESG-WARN][5] ([i915#402]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19662/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html

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


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-guc fi-bsw-cyan 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19662

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19662: d7299d4b320b3af7e82806e526dc81d5a4f738d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d7299d4b320b lib: Add a YAML emitter

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lib: Add a YAML emitter (rev2)

[Patchwork]

== Series Details ==

Series: lib: Add a YAML emitter (rev2)
URL   : https://patchwork.freedesktop.org/series/73433/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d7299d4b320b lib: Add a YAML emitter
-:19: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#19: 
new file mode 100644

-:494: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the 
config symbol fully
#494: FILE: lib/Kconfig:673:
+config TEST_YAML

-:687: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'str' - possible 
side-effects?
#687: FILE: lib/yaml/yaml-emitter.c:25:
+#define STRING_INIT(str, len) { (str), (str) + (len), (str) }

-:689: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'str' - possible 
side-effects?
#689: FILE: lib/yaml/yaml-emitter.c:27:
+#define YAML_STRING(name, str) \
+   struct yaml_string name = STRING_INIT(str, strlen(str))

-:696: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#696: FILE: lib/yaml/yaml-emitter.c:34:
+#define IS_ALPHA_AT(s, offset) \
+   (isalnum((s).pos[offset]) ||\
+(s).pos[offset] == '_' ||  \
+(s).pos[offset] == '-')

-:696: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'offset' - possible 
side-effects?
#696: FILE: lib/yaml/yaml-emitter.c:34:
+#define IS_ALPHA_AT(s, offset) \
+   (isalnum((s).pos[offset]) ||\
+(s).pos[offset] == '_' ||  \
+(s).pos[offset] == '-')

-:711: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#711: FILE: lib/yaml/yaml-emitter.c:49:
+#define IS_BOM_AT(s, offset)   \
+   (CHECK_AT((s), '\xEF', (offset) + 0) && \
+CHECK_AT((s), '\xBB', (offset) + 1) && \
+CHECK_AT((s), '\xBF', (offset) + 2))  /* BOM (#xFEFF) */

-:711: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'offset' - possible 
side-effects?
#711: FILE: lib/yaml/yaml-emitter.c:49:
+#define IS_BOM_AT(s, offset)   \
+   (CHECK_AT((s), '\xEF', (offset) + 0) && \
+CHECK_AT((s), '\xBB', (offset) + 1) && \
+CHECK_AT((s), '\xBF', (offset) + 2))  /* BOM (#xFEFF) */

-:723: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#723: FILE: lib/yaml/yaml-emitter.c:61:
+#define IS_BLANK_AT(s, offset) \
+   (IS_SPACE_AT((s), (offset)) || IS_TAB_AT((s), (offset)))

-:723: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'offset' - possible 
side-effects?
#723: FILE: lib/yaml/yaml-emitter.c:61:
+#define IS_BLANK_AT(s, offset) \
+   (IS_SPACE_AT((s), (offset)) || IS_TAB_AT((s), (offset)))

-:727: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#727: FILE: lib/yaml/yaml-emitter.c:65:
+#define IS_BREAK_AT(s, offset) \
+   (CHECK_AT((s), '\r', (offset)) || /* CR (#xD)*/ \
+CHECK_AT((s), '\n', (offset)) || /* LF (#xA) */\
+(CHECK_AT((s), '\xC2', (offset)) &&\
+ CHECK_AT((s), '\x85', (offset) + 1)) || /* NEL (#x85) */  \
+(CHECK_AT((s), '\xE2', (offset)) &&\
+ CHECK_AT((s), '\x80', (offset) + 1) &&\
+ CHECK_AT((s), '\xA8', (offset) + 2)) ||   /* LS (#x2028) */   \
+(CHECK_AT((s), '\xE2', (offset)) &&\
+ CHECK_AT((s), '\x80', (offset) + 1) &&\
+   CHECK_AT((s), '\xA9', (offset) + 2)))  /* PS (#x2029) */

-:727: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'offset' - possible 
side-effects?
#727: FILE: lib/yaml/yaml-emitter.c:65:
+#define IS_BREAK_AT(s, offset) \
+   (CHECK_AT((s), '\r', (offset)) || /* CR (#xD)*/ \
+CHECK_AT((s), '\n', (offset)) || /* LF (#xA) */\
+(CHECK_AT((s), '\xC2', (offset)) &&\
+ CHECK_AT((s), '\x85', (offset) + 1)) || /* NEL (#x85) */  \
+(CHECK_AT((s), '\xE2', (offset)) &&\
+ CHECK_AT((s), '\x80', (offset) + 1) &&\
+ CHECK_AT((s), '\xA8', (offset) + 2)) ||   /* LS (#x2028) */   \
+(CHECK_AT((s), '\xE2', (offset)) &&\
+ CHECK_AT((s), '\x80', (offset) + 1) &&\
+   CHECK_AT((s), '\xA9', (offset) + 2)))  /* PS (#x2029) */

-:740: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#740: FILE: lib/yaml/yaml-emitter.c:78:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Defer object allocation from GGTT probe to GGTT init

[Patchwork]

== Series Details ==

Series: drm/i915: Defer object allocation from GGTT probe to GGTT init
URL   : https://patchwork.freedesktop.org/series/86985/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19661


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- fi-pnv-d510:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-pnv-d510/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-pnv-d510/boot.html
- fi-ilk-650: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-ilk-650/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-ilk-650/boot.html
- fi-elk-e7500:   [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-elk-e7500/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-elk-e7500/boot.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][7] -> [INCOMPLETE][8] ([i915#142] / 
[i915#2405])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][9] -> [INCOMPLETE][10] ([i915#2940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

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

  * igt@runner@aborted:
- fi-byt-j1900:   NOTRUN -> [FAIL][13] ([i915#1814] / [i915#2505])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-byt-j1900/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][14] ([i915#1436])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * 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_9761/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 39)
--

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


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19661

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19661: 7c94d0d360710a164eb1deedb16a9f484d9502fc @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7c94d0d36071 drm/i915: Defer object allocation from GGTT probe to GGTT init

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19661/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 HDMI2.1 PCON Misc Fixes (rev2)

[Patchwork]

== Series Details ==

Series: HDMI2.1 PCON Misc Fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/86677/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19658_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html

  * igt@kms_cursor_legacy@pipe-a-torture-bo:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk2/igt@kms_cursor_leg...@pipe-a-torture-bo.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-glk7/igt@kms_cursor_leg...@pipe-a-torture-bo.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-skl8/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +36 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-skl8/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-kbl1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_schedule@u-fairslice@bcs0:
- shard-tglb: [PASS][12] -> [DMESG-WARN][13] ([i915#2803])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@bcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-tglb8/igt@gem_exec_schedule@u-fairsl...@bcs0.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#112306])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-iclb6/igt@gen9_exec_pa...@batch-without-end.html

  * igt@gen9_exec_parse@bb-oversize:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#2527])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-iclb6/igt@gen9_exec_pa...@bb-oversize.html

  * igt@i915_pm_lpsp@screens-disabled:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#1902])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-iclb6/igt@i915_pm_l...@screens-disabled.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-apl1/igt@i915_susp...@sysfs-reader.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-apl8/igt@i915_susp...@sysfs-reader.html

  * igt@kms_chamelium@dp-hpd-fast:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109284] / [fdo#111827])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-tglb8/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_color_chamelium@pipe-b-ctm-0-75:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/shard-apl1/igt@kms_color_chamel...@pipe-b-ctm-0-75.html

  * igt@kms_color_chamelium@pipe-c-ctm-negative:
- shard-skl:  NOTRUN 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc NULL check (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: HDCP capability enc NULL check (rev2)
URL   : https://patchwork.freedesktop.org/series/86440/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19657_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@pipe-a-torture-bo:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk2/igt@kms_cursor_leg...@pipe-a-torture-bo.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-glk4/igt@kms_cursor_leg...@pipe-a-torture-bo.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-skl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +42 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-skl6/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_balancer@hang:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([i915#1895] / 
[i915#2295])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb8/igt@gem_exec_balan...@hang.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-iclb4/igt@gem_exec_balan...@hang.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-kbl7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2389])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html

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

  * igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][16] ([i915#1610])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-apl1/igt@gem_exec_schedule@u-fairsl...@rcs0.html

  * igt@gem_exec_schedule@u-fairslice@vcs1:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vcs1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vcs1.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-apl8/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19657/shard-skl7/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@process-exit-mmap@wb:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [21]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Refine VT-d scanout workaround

[Patchwork]

== Series Details ==

Series: drm/i915: Refine VT-d scanout workaround
URL   : https://patchwork.freedesktop.org/series/86967/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19656_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][1] -> [FAIL][2] ([i915#2846])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-kbl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_nop@basic-sequential:
- shard-iclb: [PASS][8] -> [DMESG-WARN][9] ([i915#1226]) +38 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb7/igt@gem_exec_...@basic-sequential.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-iclb8/igt@gem_exec_...@basic-sequential.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][12] ([i915#2658])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-apl6/igt@gem_pr...@exhaustion.html
- shard-skl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-skl6/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@process-exit-mmap@wb:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1699]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-apl6/igt@gem_userptr_blits@process-exit-m...@wb.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#112306])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-tglb3/igt@gen9_exec_pa...@batch-without-end.html

  * igt@gen9_exec_parse@bb-oversize:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#2527])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-tglb3/igt@gen9_exec_pa...@bb-oversize.html

  * igt@i915_hangman@engine-error@vecs0:
- shard-kbl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +38 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-kbl2/igt@i915_hangman@engine-er...@vecs0.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#454])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb7/igt@i915_pm...@dc6-psr.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-iclb4/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_lpsp@screens-disabled:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#1902])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-tglb3/igt@i915_pm_l...@screens-disabled.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([i915#151])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-skl5/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_chamelium@vga-hpd-for-each-pipe:
- shard-kbl:  NOTRUN -> [SKIP][23] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19656/shard-kbl2/igt@kms_chamel...@vga-hpd-for-each-pipe.html

  * igt@kms_color_chamelium@pipe-b-ctm-0-75:
- shard-apl:  NOTRUN -> [SKIP][24] ([fdo#109271] / 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915/gt: Sanitize GPU during 
prepare-to-suspend
URL   : https://patchwork.freedesktop.org/series/86962/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19655_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk4/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-glk9/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@mock@timelines:
- shard-kbl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl7/igt@i915_selftest@m...@timelines.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-kbl3/igt@i915_selftest@m...@timelines.html
- shard-iclb: [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-iclb5/igt@i915_selftest@m...@timelines.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-iclb8/igt@i915_selftest@m...@timelines.html
- shard-skl:  [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-skl10/igt@i915_selftest@m...@timelines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-skl2/igt@i915_selftest@m...@timelines.html
- shard-tglb: [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb5/igt@i915_selftest@m...@timelines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-tglb6/igt@i915_selftest@m...@timelines.html
- shard-snb:  [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-snb6/igt@i915_selftest@m...@timelines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-snb6/igt@i915_selftest@m...@timelines.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][13] ([i915#3002])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-skl7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@close-replace-race:
- shard-kbl:  [PASS][14] -> [TIMEOUT][15] ([i915#2918])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +34 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-skl7/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2846])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-kbl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-kbl:  [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-kbl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-kbl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2842]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19655/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][23] -> [FAIL][24] ([i915#2389])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Probe system memory regions before enabling HW

[Patchwork]

== Series Details ==

Series: drm/i915: Probe system memory regions before enabling HW
URL   : https://patchwork.freedesktop.org/series/86984/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19660


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  
 Possible fixes 

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

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

  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1208]: https://gitlab.freedesktop.org/drm/intel/issues/1208
  [i915#1614]: https://gitlab.freedesktop.org/drm/intel/issues/1614
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Additional (1): fi-cml-drallion 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19660

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19660: 156d623c53fddd270d5cd0a2353bf76e81f1e0d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

156d623c53fd drm/i915: Probe system memory regions before enabling HW

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19660/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: Defer object allocation from GGTT probe to GGTT init

[Matthew Auld]

On 11/02/2021 11:24, Chris Wilson wrote:

Rather than try and allocate objects as we perform our early HW probes,
defer the allocation for GGTT objects (such as the scratch page) to later
in the initialisation.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 

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

Re: [Intel-gfx] [PATCH] drm/i915/display: Handle lane polarity for DDI port

[Ville Syrjälä]

On Thu, Feb 11, 2021 at 05:12:09PM +0530, Uma Shankar wrote:
> Lane Reversal is required for some of the DDI ports. This information
> is populated in VBT and driver should read the same and set the
> polarity while enabling the port. This patch handles the same.
> 
> It helps fix a display blankout issue on DP ports on certain
> platforms.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 17 +
>  drivers/gpu/drm/i915/display/intel_bios.h |  2 ++
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 7118530a1c38..dd51413e7f45 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2674,6 +2674,23 @@ intel_bios_is_lspcon_present(const struct 
> drm_i915_private *i915,
>   return HAS_LSPCON(i915) && child && child->lspcon;
>  }
>  
> +/**
> + * intel_bios_is_lane_reversal_needed - if lane reversal needed on port
> + * @i915:   i915 device instance
> + * @port:   port to check
> + *
> + * Return true if port requires lane reversal
> + */
> +bool
> +intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
> +enum port port)
> +{
> + const struct child_device_config *child =
> + i915->vbt.ddi_port_info[port].child;
> +
> + return child && child->lane_reversal;
> +}
> +
>  enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv,
>  enum port port)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
> b/drivers/gpu/drm/i915/display/intel_bios.h
> index e29e79faa01b..f25190ecfe97 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.h
> +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> @@ -241,6 +241,8 @@ bool intel_bios_is_port_hpd_inverted(const struct 
> drm_i915_private *i915,
>enum port port);
>  bool intel_bios_is_lspcon_present(const struct drm_i915_private *i915,
> enum port port);
> +bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
> + enum port port);
>  enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum 
> port port);
>  bool intel_bios_get_dsc_params(struct intel_encoder *encoder,
>  struct intel_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3c4003605f93..2d6906f6995f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4082,6 +4082,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   intel_de_read(dev_priv, DDI_BUF_CTL(port))
>   & (DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
>  
> + if (intel_bios_is_lane_reversal_needed(dev_priv, port))
> + dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
> +

Not a huge fan of saved_port_bits in general but as long as we have it
stuffing this in there seems like the best option.

Reviewed-by: Ville Syrjälä 

>   dig_port->dp.output_reg = INVALID_MMIO_REG;
>   dig_port->max_lanes = intel_ddi_max_lanes(dig_port);
>   dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
> -- 
> 2.26.2

-- 
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] drm/i915: Probe system memory regions before enabling HW

[Chris Wilson]

Quoting Matthew Auld (2021-02-11 12:27:56)
> On 11/02/2021 11:20, Chris Wilson wrote:
> > If we want to track system/stolen as memory regions, we need to setup
> > our bookkeeping *before* we want to start allocating and reserving
> > objects in those regions. In particular, in setup up the GGTT we will
> > try to preallocate stolen regions configured by the BIOS, and so should
> > prepare the system-stolen memory region beforehand.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.c | 8 
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index b708517d3972..139cea4443fd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -557,6 +557,10 @@ static int i915_driver_hw_probe(struct 
> > drm_i915_private *dev_priv)
> >   
> >   i915_perf_init(dev_priv);
> >   
> > + ret = intel_memory_regions_hw_probe(dev_priv);
> > + if (ret)
> > + goto err_ggtt;
> 
> Hmmm, adjust_stolen is also peeking at ggtt_total_entries(ggtt) on some 
> old platforms.

A nice catch-22. More splitting required. Maybe a fixup pass from
init_ggtt would work best.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Handle lane polarity for DDI port

[Patchwork]

== Series Details ==

Series: drm/i915/display: Handle lane polarity for DDI port
URL   : https://patchwork.freedesktop.org/series/86983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19659


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#2411] / 
[i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_linear_blits@basic:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_linear_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/fi-tgl-y/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [PASS][5] -> [DMESG-FAIL][6] ([i915#3047])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19659/fi-glk-dsi/igt@i915_selftest@l...@client.html

  
 Possible fixes 

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

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

  [i915#1208]: https://gitlab.freedesktop.org/drm/intel/issues/1208
  [i915#1614]: https://gitlab.freedesktop.org/drm/intel/issues/1614
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Additional (1): fi-cml-drallion 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19659

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19659: d8671dfbf189d73707c4c4f515995af9bd3b70a7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d8671dfbf189 drm/i915/display: Handle lane polarity for DDI port

== Logs ==

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

Re: [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe

[Ville Syrjälä]

On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> From: Nischal Varide 
> 
> If the panel is 12bpc then Dithering is not enabled in the Legacy
> dithering block , instead its Enabled after the C1 CC1 pipe post
> color space conversion.For a 6bpc pannel Dithering is enabled in
> Legacy block.

Dithering is probably going to require a whole uapi bikeshed.
Not sure we can just enable it unilaterally.

Ccing dri-devel, and Mario who had issues with dithering in the
past...

> 
> Cc: Uma Shankar 
> Signed-off-by: Nischal Varide 
> Signed-off-by: Bhanuprakash Modem 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c   | 16 
>  drivers/gpu/drm/i915/display/intel_display.c |  9 -
>  drivers/gpu/drm/i915/i915_reg.h  |  3 ++-
>  3 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ff7dcb7088bf..9a0572bbc5db 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1604,6 +1604,20 @@ static u32 icl_csc_mode(const struct intel_crtc_state 
> *crtc_state)
>   return csc_mode;
>  }
>  
> +static u32 dither_after_cc1_12bpc(const struct intel_crtc_state *crtc_state)
> +{
> + u32 gamma_mode = crtc_state->gamma_mode;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (HAS_DISPLAY13(i915)) {
> + if (!crtc_state->dither_force_disable &&
> + (crtc_state->pipe_bpp == 36))
> + gamma_mode |= GAMMA_MODE_DITHER_AFTER_CC1;
> + }
> +
> + return gamma_mode;
> +}
> +
>  static int icl_color_check(struct intel_crtc_state *crtc_state)
>  {
>   int ret;
> @@ -1614,6 +1628,8 @@ static int icl_color_check(struct intel_crtc_state 
> *crtc_state)
>  
>   crtc_state->gamma_mode = icl_gamma_mode(crtc_state);
>  
> + crtc_state->gamma_mode = dither_after_cc1_12bpc(crtc_state);
> +
>   crtc_state->csc_mode = icl_csc_mode(crtc_state);
>  
>   crtc_state->preload_luts = intel_can_preload_luts(crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4dc4b1be0809..e3dbcd956fc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8098,9 +8098,15 @@ static void bdw_set_pipemisc(const struct 
> intel_crtc_state *crtc_state)
>   break;
>   }
>  
> - if (crtc_state->dither)
> + /*
> +  * If 12bpc panel then, Enables dithering after the CC1 pipe
> +  * post color space conversion and not here
> +  */
> +
> + if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
>   val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>  
> +
>   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
>   crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
>   val |= PIPEMISC_OUTPUT_COLORSPACE_YUV;
> @@ -10760,6 +10766,7 @@ intel_modeset_pipe_config(struct intel_atomic_state 
> *state,
>*/
>   pipe_config->dither = (pipe_config->pipe_bpp == 6*3) &&
>   !pipe_config->dither_force_disable;
> +
>   drm_dbg_kms(>drm,
>   "hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
>   base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 128b835c0adb..27f25214a839 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6132,7 +6132,7 @@ enum {
>  #define   PIPEMISC_DITHER_8_BPC  (0 << 5)
>  #define   PIPEMISC_DITHER_10_BPC (1 << 5)
>  #define   PIPEMISC_DITHER_6_BPC  (2 << 5)
> -#define   PIPEMISC_DITHER_12_BPC (3 << 5)
> +#define   PIPEMISC_DITHER_12_BPC (4 << 5)
>  #define   PIPEMISC_DITHER_ENABLE (1 << 4)
>  #define   PIPEMISC_DITHER_TYPE_MASK  (3 << 2)
>  #define   PIPEMISC_DITHER_TYPE_SP(0 << 2)
> @@ -7668,6 +7668,7 @@ enum {
>  #define  GAMMA_MODE_MODE_12BIT   (2 << 0)
>  #define  GAMMA_MODE_MODE_SPLIT   (3 << 0) /* ivb-bdw */
>  #define  GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED   (3 << 0) /* icl + */
> +#define  GAMMA_MODE_DITHER_AFTER_CC1 (1 << 26)
>  
>  /* DMC/CSR */
>  #define CSR_PROGRAM(i)   _MMIO(0x8 + (i) * 4)
> -- 
> 2.25.4
> 
> ___
> 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] drm/i915: Probe system memory regions before enabling HW

[Matthew Auld]

On 11/02/2021 11:20, Chris Wilson wrote:

If we want to track system/stolen as memory regions, we need to setup
our bookkeeping *before* we want to start allocating and reserving
objects in those regions. In particular, in setup up the GGTT we will
try to preallocate stolen regions configured by the BIOS, and so should
prepare the system-stolen memory region beforehand.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_drv.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b708517d3972..139cea4443fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -557,6 +557,10 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
  
  	i915_perf_init(dev_priv);
  
+	ret = intel_memory_regions_hw_probe(dev_priv);

+   if (ret)
+   goto err_ggtt;


Hmmm, adjust_stolen is also peeking at ggtt_total_entries(ggtt) on some 
old platforms.



+
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
goto err_perf;
@@ -569,10 +573,6 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
if (ret)
goto err_ggtt;
  
-	ret = intel_memory_regions_hw_probe(dev_priv);

-   if (ret)
-   goto err_ggtt;
-
intel_gt_init_hw_early(_priv->gt, _priv->ggtt);
  
  	ret = intel_gt_probe_lmem(_priv->gt);



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

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Hans de Goede]

Hi,

On 2/11/21 11:49 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-11 10:36:13)
>> Hi,
>>
>> On 2/10/21 1:48 PM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-10 10:37:19)
 Hi,

 On 2/10/21 12:07 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-09 11:46:46)
>> Hi,
>>
>> On 2/9/21 12:27 AM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-08 20:38:58)
 Hi All,

 We (Fedora) have been receiving reports from multiple users about gfx 
 issues / glitches
 stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell 
 iGPUs and all
 reporters report that adding i915.mitigations=off to the cmdline fixes 
 things, see:
>>>
>>> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
>>> did not report any differences with and without mitigations. I have yet
>>> to test other platforms. So I don't yet have an alternative.
>>
>> Note the original / first reporter of:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
>>
>> Is using hsw-gt2, so it seems that the problem is not just the enabling 
>> of
>> the mitigations on ivy-bridge / bay-trail but that there actually is
>> a regression on devices where the WA worked fine before...
>
> There have been 3 crashes uploaded related to v5.10.9, and in all 3
> cases the ACTHD has been in the first page. This strongly suggests that
> the w/a is scribbling over address 0. And there's then a very good
> chance that
>
> commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> Author: Chris Wilson 
> Date:   Mon Jan 25 12:50:33 2021 +
>
> drm/i915/gt: Always try to reserve GGTT address 0x0
> 
> commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
>
> in v5.10.14 is sufficient to hide the issue.

 That one actually is already in v5.10.13 and the various reportes of these
 issues have already tested 5.10.13. They did mention that it took longer
 to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:

 "drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5
>>>
>>> Started looking for scratch page overwrites, and found this little gem:
>>> https://patchwork.freedesktop.org/patch/420436/?series=86947=1
>>>
>>> Looks promising wrt the cause of overwriting random addresses -- and
>>> I hope that is the explanation for the glitches/hangs. I have a hsw gt2
>>> with gnome shell, piglit is happy, but I suspect it is all due to
>>> placement and so will only occur at random.
>>
>> If you can give me a list of commits to cherry-pick then I can prepare
>> a Fedora 5.10.y kernel which those added for the group of Fedora users
>> who are hitting this to test.
> 
> e627d5923cae ("drm/i915/gt: One more flush for Baytrail clear residuals")
> d30bbd62b1bf ("drm/i915/gt: Flush before changing register state")
> 1914911f4aa0 ("drm/i915/gt: Correct surface base address for renderclear")

Thanks, the test-kernel is building now. I will let you know when I have
heard back from the Fedora users (this will likely take 1-2 days).

Regards,

Hans

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

Re: [Intel-gfx] [PATCH 03/18] drm/i915/display13: Enhanced pipe underrun reporting

[Ville Syrjälä]

On Thu, Jan 28, 2021 at 11:23:58AM -0800, Matt Roper wrote:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 10fd0e3af2d4..a57593f7d7b1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6039,14 +6039,18 @@ enum {
>  #define   PIPECONF_DITHER_TYPE_ST2 (2 << 2)
>  #define   PIPECONF_DITHER_TYPE_TEMP (3 << 2)
>  #define _PIPEASTAT   0x70024
> +#define _PIPEASTAT_ICL   0x70058

PIPESTAT is a gmch thing. This is not that for sure.

>  #define   PIPE_FIFO_UNDERRUN_STATUS  (1UL << 31)
>  #define   SPRITE1_FLIP_DONE_INT_EN_VLV   (1UL << 30)
>  #define   PIPE_CRC_ERROR_ENABLE  (1UL << 29)
>  #define   PIPE_CRC_DONE_ENABLE   (1UL << 28)
> +#define   PIPE_STAT_SOFT_UNDERRUN_D13(1UL << 28)
>  #define   PERF_COUNTER2_INTERRUPT_EN (1UL << 27)
>  #define   PIPE_GMBUS_EVENT_ENABLE(1UL << 27)
> +#define   PIPE_STAT_HARD_UNDERRUN_D13(1UL << 27)
>  #define   PLANE_FLIP_DONE_INT_EN_VLV (1UL << 26)
>  #define   PIPE_HOTPLUG_INTERRUPT_ENABLE  (1UL << 26)
> +#define   PIPE_STAT_PORT_UNDERRUN_D13(1UL << 26)
>  #define   PIPE_VSYNC_INTERRUPT_ENABLE(1UL << 25)
>  #define   PIPE_DISPLAY_LINE_COMPARE_ENABLE   (1UL << 24)
>  #define   PIPE_DPST_EVENT_ENABLE (1UL << 23)
> @@ -6111,6 +6115,7 @@ enum {
>  #define PIPEFRAME(pipe)  _MMIO_PIPE2(pipe, _PIPEAFRAMEHIGH)
>  #define PIPEFRAMEPIXEL(pipe) _MMIO_PIPE2(pipe, _PIPEAFRAMEPIXEL)
>  #define PIPESTAT(pipe)   _MMIO_PIPE2(pipe, _PIPEASTAT)
> +#define ICL_PIPESTAT(pipe)   _MMIO_PIPE2(pipe, _PIPEASTAT_ICL)
>  
>  #define  _PIPEAGCMAX   0x70010
>  #define  _PIPEBGCMAX   0x71010
> @@ -7789,6 +7794,8 @@ enum {
>  #define  GEN8_PIPE_FIFO_UNDERRUN (1 << 31)
>  #define  GEN8_PIPE_CDCLK_CRC_ERROR   (1 << 29)
>  #define  GEN8_PIPE_CDCLK_CRC_DONE(1 << 28)
> +#define  D13_PIPE_SOFT_UNDERRUN  (1 << 22)
> +#define  D13_PIPE_HARD_UNDERRUN  (1 << 21)
>  #define  GEN8_PIPE_CURSOR_FAULT  (1 << 10)
>  #define  GEN8_PIPE_SPRITE_FAULT  (1 << 9)
>  #define  GEN8_PIPE_PRIMARY_FAULT (1 << 8)
> -- 
> 2.25.4
> 
> ___
> 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] [PATCH v3] drm/i915/gt: Ratelimit heartbeat completion probing

[Chris Wilson]

The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)

So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).

v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.

v3: Now with more tracking for selftests and detection of
false/unexpected hang reports.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang 
Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 104 +++---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   8 ++
 .../drm/i915/gt/selftest_engine_heartbeat.c   |  92 ++--
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |   5 +-
 4 files changed, 159 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..71aa02995417 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
  * issue a reset -- in the hope that restores progress.
  */
 
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+   long timeout = HEARTBEAT_COMPLETION;
+
+   if (intel_engine_has_preempt_reset(engine))
+   timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+   return msecs_to_jiffies(timeout);
+}
+
 static bool next_heartbeat(struct intel_engine_cs *engine)
 {
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
 
delay = msecs_to_jiffies_timeout(delay);
+
+   /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we want to promote the heartbeat and trigger
+* preemption in a deterministic time frame.
+*/
+   if (engine->heartbeat.systole &&
+   i915_request_is_active(engine->heartbeat.systole))
+   delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, >heartbeat.work, delay + 1);
@@ -48,12 +80,51 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
 }
 
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct intel_engine_cs *engine =
+   container_of(cb, typeof(*engine), heartbeat.cb);
+
+   if (READ_ONCE(engine->heartbeat.systole))
+   mod_delayed_work(system_highpri_wq, >heartbeat.work, 0);
+}
+
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+   struct i915_request *rq;
+
+   rq = fetch_and_zero(>heartbeat.systole);
+   if (!rq)
+   return;
+
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT "completed\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.completed++);
+
+   dma_fence_remove_callback(>fence, >heartbeat.cb);
+   i915_request_put(rq);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+   ENGINE_TRACE(engine, "heartbeat " RQ_FMT "started\n", RQ_ARG(rq));
+   I915_SELFTEST_ONLY(engine->heartbeat.submitted++);
+
+   dma_fence_add_callback(>fence,
+  >heartbeat.cb,
+  

Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume

[Imre Deak]

On Wed, Feb 10, 2021 at 06:33:20AM +0200, Gupta, Anshuman wrote:
> > On Tue, 2021-02-02 at 18:14 +0200, Imre Deak wrote:
> > >
> > > BSpec says about this WA for both ICL and TGL:
> > > """
> > > Display driver should set and clear register offset 0xC2000 bit #7 as
> > > last step in programming south display registers in preparation for
> > > entering S0ix state, or set 0xC2000 bit #7 on S0ix entry and clear it
> > > on S0ix exit.
> > >
> > > """
> > >
> > > This means to me the WA is only relevant for S0ix and we can implement
> > > it by setting/clearing 0xC2000 bit #7 right before entering/right
> > > after exiting S0ix. This is done atm on PCH_ICP..PCH_MCC in
> > > intel_display_power_suspend_late()/intel_display_power_resume_early(),
> > > so I'd move the WA for all platforms there.
> > >
> > > I assume the current code in irq_reset() was the first alternative to
> > > implement the WA, but it wasn't enough. Not sure why, maybe there is a
> > > south display register access after irq_reset() during suspend. Adding
> > > Anshuman for an idea on that.
> > >
> > 
> > Poking Anshuman here, is there any update on this? I'm looking to push these
> > patches forward as some of Red Hat's hardware partners are very eager for 
> > this
> > to get upstream asap as we're running out of time from our end. If you can
> > answer this, I can handle respinning this patch as needed.
>
> My sincere apology, I had missed this thread.  We have decided to keep
> the alternative WA i.e  setting/clearing 0xC2000 bit #7 before
> entering after exiting s0ix to fix the deeper s0ix power consumption
> issues on ICL_PCH families platforms. This alternative WA  was added
> to B.Spec on our request.  But on TGL_PCH first alternative WA logic
> i.e  in irq_reset() was working to attain deeper s0ix residencies so
> we haven't changed that.

Ok, thanks for the explanation. For now I'd just ask to add a TODO: in
this patch to check if the WA can be applied in the s0ix suspend/resume
handlers as on earlier platforms and whether the WA is also needed for
runtime s/r.

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

Re: [Intel-gfx] [PATCH v2] drm/i915/debugfs: HDCP capability enc NULL check

[Imre Deak]

On Thu, Feb 11, 2021 at 11:59:49AM +0530, Anshuman Gupta wrote:
> DP-MST connector encoder initializes at modeset
> Adding a connector->encoder NULL check in order to
> avoid any NULL pointer dereference.
> intel_hdcp_enable() already handle this but debugfs
> can also invoke the intel_{hdcp,hdcp2_capable}.
> Handling it gracefully.
> 
> v2:
> - Use necessary lock and NULL check in
>   i915_hdcp_sink_capability_show. [Imre]
> 
> Signed-off-by: Anshuman Gupta 
> ---
>  .../gpu/drm/i915/display/intel_display_debugfs.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index d6e4a9237bda..ed5e2f65b171 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2198,14 +2198,26 @@ DEFINE_SHOW_ATTRIBUTE(i915_panel);
>  static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
>  {
>   struct drm_connector *connector = m->private;
> + struct drm_i915_private *i915 = to_i915(connector->dev);
>   struct intel_connector *intel_connector = to_intel_connector(connector);
> + int ret;
>  
> - if (connector->status != connector_status_connected)
> - return -ENODEV;
> + ret = 
> drm_modeset_lock_single_interruptible(>drm.mode_config.connection_mutex);
> + if (ret)
> + return ret;
> +
> + if (!connector->encoder || connector->status != 
> connector_status_connected) {
> + ret = -ENODEV;
> + goto out;
> + }
>  
>   seq_printf(m, "%s:%d HDCP version: ", connector->name,
>  connector->base.id);
>   intel_hdcp_info(m, intel_connector);
> +out:
> + drm_modeset_unlock(>drm.mode_config.connection_mutex);
> + if (ret)
> + return ret;
>  
>   return 0;

Could be just
return ret;

Reviewed-by: Imre Deak 

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

[Intel-gfx] [PATCH] lib: Add a YAML emitter

[Chris Wilson]

Provide a library to generate correct YAML for use in structured debugfs
or similar information dumps. This will be useful to pull our large
information dumps into a forwards compatible, parse-able file-format by
forcing some structure upon ourselves!

Originally from https://github.com/yaml/libyaml/blob/master/src/emitter.c
under a permissive MIT licence.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 

---
Converting to kerneldoc is about the last major task. It uses an
opencoded stack struct which might be nice to convert to a library,
maybe just use XArray?

It has been dogfooded to convert i915_engine_info (and friends)
https://patchwork.freedesktop.org/patch/353209/?series=73403=1
---
 include/linux/yaml-events.h |  259 
 include/linux/yaml.h|  190 +++
 lib/Kconfig |   11 +
 lib/Makefile|2 +
 lib/yaml/Makefile   |8 +
 lib/yaml/test-yaml.c|  123 ++
 lib/yaml/yaml-emitter.c | 2539 +++
 lib/yaml/yaml-emitter.h |  140 ++
 lib/yaml/yaml-events.c  |  424 ++
 lib/yaml/yaml-simple.c  |  227 
 10 files changed, 3923 insertions(+)
 create mode 100644 include/linux/yaml-events.h
 create mode 100644 include/linux/yaml.h
 create mode 100644 lib/yaml/Makefile
 create mode 100644 lib/yaml/test-yaml.c
 create mode 100644 lib/yaml/yaml-emitter.c
 create mode 100644 lib/yaml/yaml-emitter.h
 create mode 100644 lib/yaml/yaml-events.c
 create mode 100644 lib/yaml/yaml-simple.c

diff --git a/include/linux/yaml-events.h b/include/linux/yaml-events.h
new file mode 100644
index ..33d1bb227e65
--- /dev/null
+++ b/include/linux/yaml-events.h
@@ -0,0 +1,259 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (c) 2006-2016 Kirill Simonov
+ * Copyright (c) 2017-2019 Ingy döt Net
+ * Copyright (c) 2020 Intel Corporation
+ */
+
+#ifndef __LINUX_YAML_EVENTS_H__
+#define __LINUX_YAML_EVENTS_H__
+
+#include 
+#include 
+#include 
+
+/** The version directive data. */
+struct yaml_version_directive {
+   int major;
+   int minor;
+};
+
+/** The tag directive data. */
+struct yaml_tag_directive {
+   char *handle;
+   char *prefix;
+};
+
+/** The pointer position. */
+struct yaml_mark {
+   size_t index;
+   size_t line;
+   size_t column;
+};
+
+enum yaml_event_type {
+   YAML_NO_EVENT = 0,
+
+   YAML_STREAM_START_EVENT,
+   YAML_STREAM_END_EVENT,
+
+   YAML_DOCUMENT_START_EVENT,
+   YAML_DOCUMENT_END_EVENT,
+
+   YAML_ALIAS_EVENT,
+   YAML_SCALAR_EVENT,
+
+   YAML_SEQUENCE_START_EVENT,
+   YAML_SEQUENCE_END_EVENT,
+
+   YAML_MAPPING_START_EVENT,
+   YAML_MAPPING_END_EVENT
+};
+
+struct yaml_event {
+   enum yaml_event_type type;
+   struct list_head link;
+
+   union {
+   /** The stream parameters (for YAML_STREAM_START_EVENT). */
+   struct {
+   } stream_start;
+
+   /** The document parameters (for YAML_DOCUMENT_START_EVENT). */
+   struct {
+   struct yaml_version_directive *version;
+
+   struct {
+   struct yaml_tag_directive *start;
+   struct yaml_tag_directive *end;
+   } tags;
+
+   int implicit;
+   } document_start;
+
+   /** The document end parameters (for YAML_DOCUMENT_END_EVENT). 
*/
+   struct {
+   int implicit;
+   } document_end;
+
+   /** The alias parameters (for YAML_ALIAS_EVENT). */
+   struct {
+   char *anchor;
+   } alias;
+
+   /** The scalar parameters (for YAML_SCALAR_EVENT). */
+   struct {
+   char *anchor;
+   char *tag;
+   char *value;
+   size_t length;
+   int plain_implicit;
+   int quoted_implicit;
+   enum yaml_scalar_style style;
+   } scalar;
+
+   /** The sequence parameters (for YAML_SEQUENCE_START_EVENT). */
+   struct {
+   char *anchor;
+   char *tag;
+   int implicit;
+   enum yaml_sequence_style style;
+   } sequence_start;
+
+   /** The mapping parameters (for YAML_MAPPING_START_EVENT). */
+   struct {
+   char *anchor;
+   char *tag;
+   int implicit;
+   enum yaml_mapping_style style;
+   } mapping_start;
+   };
+
+   struct yaml_mark start_mark;
+   struct yaml_mark end_mark;
+};
+
+struct yaml_event *yaml_stream_start_event_create(gfp_t gfp);
+struct yaml_event *yaml_stream_end_event_create(gfp_t gfp);
+
+/**
+ * 

Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Only write to register in intel_psr2_program_trans_man_trk_ctl()

[Mun, Gwan-gyeong]

On Tue, 2021-02-09 at 10:14 -0800, José Roberto de Souza wrote:
> There is no support for two pipes one transcoder for PSR and if we
> had
> that the current code should not use cpu_transcoder.
> Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch
> is
> set and PSR is not enabled and if by a bug it happens PSR HW will
> just
> ignore any value in set in PSR2_MAN_TRK_CTL.
> 
> So dropping all the rest and keeping the same behavior that we have
> with intel_psr2_program_plane_sel_fetch().
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 1d3903612fcb..8ad9fcff3a12 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1226,23 +1226,13 @@ void
> intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
>  void intel_psr2_program_trans_man_trk_ctl(const struct
> intel_crtc_state *crtc_state)
>  {
> struct drm_i915_private *dev_priv = to_i915(crtc_state-
> >uapi.crtc->dev);
> -   struct intel_encoder *encoder;
>  
> if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
>     !crtc_state->enable_psr2_sel_fetch)
> return;
>  
> -   for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
> -    crtc_state-
> >uapi.encoder_mask) {
> -   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> -   if (!intel_dp->psr.enabled)
> -   continue;
> -
> -   intel_de_write(dev_priv,
> -  PSR2_MAN_TRK_CTL(crtc_state-
> >cpu_transcoder),
> -  crtc_state->psr2_man_track_ctl);
> -   }
> +   intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(crtc_state-
> >cpu_transcoder),
> +  crtc_state->psr2_man_track_ctl);
>  }
>  
>  static void psr2_man_trk_ctl_calc(struct intel_crtc_state
> *crtc_state,

Reviewed-by: Gwan-gyeong Mun 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr

[Mun, Gwan-gyeong]

On Tue, 2021-02-09 at 10:14 -0800, José Roberto de Souza wrote:
> for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion
> "with_psr" is better.
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_display.h |  4 ++--
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c |  6 +++---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 ++
> --
>  drivers/gpu/drm/i915/i915_irq.c  |  4 ++--
>  4 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e3757ecabbf7..c60a58ba60ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -418,7 +418,7 @@ enum phy_fia {
> for_each_if((encoder_mask)
> &\
>     drm_encoder_mask(_encoder->base))
>  
> -#define for_each_intel_encoder_mask_can_psr(dev, intel_encoder,
> encoder_mask) \
> +#define for_each_intel_encoder_mask_with_psr(dev, intel_encoder,
> encoder_mask) \
> list_for_each_entry((intel_encoder), &(dev)-
> >mode_config.encoder_list, base.head) \
> for_each_if(((encoder_mask) &
> drm_encoder_mask(&(intel_encoder)->base)) && \
>     intel_encoder_can_psr(intel_encoder))
> @@ -427,7 +427,7 @@ enum phy_fia {
> for_each_intel_encoder(dev, intel_encoder)  \
> for_each_if(intel_encoder_is_dp(intel_encoder))
>  
> -#define for_each_intel_encoder_can_psr(dev, intel_encoder) \
> +#define for_each_intel_encoder_with_psr(dev, intel_encoder) \
> for_each_intel_encoder((dev), (intel_encoder)) \
> for_each_if(intel_encoder_can_psr(intel_encoder))
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index d6e4a9237bda..7ce11d851163 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -437,7 +437,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> return -ENODEV;
>  
> /* Find the first EDP which supports PSR */
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> intel_dp = enc_to_intel_dp(encoder);
> break;
> }
> @@ -459,7 +459,7 @@ i915_edp_psr_debug_set(void *data, u64 val)
> if (!HAS_PSR(dev_priv))
> return ret;
>  
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> drm_dbg_kms(_priv->drm, "Setting PSR debug to
> %llx\n", val);
> @@ -484,7 +484,7 @@ i915_edp_psr_debug_get(void *data, u64 *val)
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>  
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> // TODO: split to each transcoder's PSR debug state
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index bf214d0e2dec..1d3903612fcb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1232,8 +1232,8 @@ void intel_psr2_program_trans_man_trk_ctl(const
> struct intel_crtc_state *crtc_st
>     !crtc_state->enable_psr2_sel_fetch)
> return;
>  
> -   for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
> -   crtc_state-
> >uapi.encoder_mask) {
> +   for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
> +    crtc_state-
> >uapi.encoder_mask) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> if (!intel_dp->psr.enabled)
> @@ -1515,8 +1515,8 @@ void intel_psr_wait_for_idle(const struct
> intel_crtc_state *new_crtc_state)
> if (!new_crtc_state->has_psr)
> return;
>  
> -   for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
> -   new_crtc_state-
> >uapi.encoder_mask) {
> +   for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
> +    new_crtc_state-
> >uapi.encoder_mask) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> u32 psr_status;
>  
> @@ -1730,7 +1730,7 @@ void intel_psr_invalidate(struct
> drm_i915_private *dev_priv,
> if (origin == ORIGIN_FLIP)
> return;
>  
> -   

Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr

[Mun, Gwan-gyeong]

On Tue, 2021-02-09 at 10:14 -0800, José Roberto de Souza wrote:
> for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion
> "with_psr" is better.
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_display.h |  4 ++--
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c |  6 +++---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 ++
> --
>  drivers/gpu/drm/i915/i915_irq.c  |  4 ++--
>  4 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e3757ecabbf7..c60a58ba60ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -418,7 +418,7 @@ enum phy_fia {
> for_each_if((encoder_mask)
> &\
>     drm_encoder_mask(_encoder->base))
>  
> -#define for_each_intel_encoder_mask_can_psr(dev, intel_encoder,
> encoder_mask) \
> +#define for_each_intel_encoder_mask_with_psr(dev, intel_encoder,
> encoder_mask) \
> list_for_each_entry((intel_encoder), &(dev)-
> >mode_config.encoder_list, base.head) \
> for_each_if(((encoder_mask) &
> drm_encoder_mask(&(intel_encoder)->base)) && \
>     intel_encoder_can_psr(intel_encoder))
> @@ -427,7 +427,7 @@ enum phy_fia {
> for_each_intel_encoder(dev, intel_encoder)  \
> for_each_if(intel_encoder_is_dp(intel_encoder))
>  
> -#define for_each_intel_encoder_can_psr(dev, intel_encoder) \
> +#define for_each_intel_encoder_with_psr(dev, intel_encoder) \
> for_each_intel_encoder((dev), (intel_encoder)) \
> for_each_if(intel_encoder_can_psr(intel_encoder))
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index d6e4a9237bda..7ce11d851163 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -437,7 +437,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> return -ENODEV;
>  
> /* Find the first EDP which supports PSR */
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> intel_dp = enc_to_intel_dp(encoder);
> break;
> }
> @@ -459,7 +459,7 @@ i915_edp_psr_debug_set(void *data, u64 val)
> if (!HAS_PSR(dev_priv))
> return ret;
>  
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> drm_dbg_kms(_priv->drm, "Setting PSR debug to
> %llx\n", val);
> @@ -484,7 +484,7 @@ i915_edp_psr_debug_get(void *data, u64 *val)
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>  
> -   for_each_intel_encoder_can_psr(_priv->drm, encoder) {
> +   for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> // TODO: split to each transcoder's PSR debug state
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index bf214d0e2dec..1d3903612fcb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1232,8 +1232,8 @@ void intel_psr2_program_trans_man_trk_ctl(const
> struct intel_crtc_state *crtc_st
>     !crtc_state->enable_psr2_sel_fetch)
> return;
>  
> -   for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
> -   crtc_state-
> >uapi.encoder_mask) {
> +   for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
> +    crtc_state-
> >uapi.encoder_mask) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> if (!intel_dp->psr.enabled)
> @@ -1515,8 +1515,8 @@ void intel_psr_wait_for_idle(const struct
> intel_crtc_state *new_crtc_state)
> if (!new_crtc_state->has_psr)
> return;
>  
> -   for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
> -   new_crtc_state-
> >uapi.encoder_mask) {
> +   for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
> +    new_crtc_state-
> >uapi.encoder_mask) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> u32 psr_status;
>  
> @@ -1730,7 +1730,7 @@ void intel_psr_invalidate(struct
> drm_i915_private *dev_priv,
> if (origin == ORIGIN_FLIP)
> return;
>  
> -   

[Intel-gfx] [PATCH] drm/i915: Defer object allocation from GGTT probe to GGTT init

[Chris Wilson]

Rather than try and allocate objects as we perform our early HW probes,
defer the allocation for GGTT objects (such as the scratch page) to later
in the initialisation.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 38 +++-
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index b0b8ded834f0..23c7eb462b2f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -78,19 +78,29 @@ static int ggtt_init_hw(struct i915_ggtt *ggtt)
  */
 int i915_ggtt_init_hw(struct drm_i915_private *i915)
 {
+   struct i915_ggtt *ggtt = >ggtt;
+   u32 pte_flags;
int ret;
 
+   ret = setup_scratch_page(>vm);
+   if (ret)
+   return ret;
+
+   pte_flags = 0;
+   if (i915_gem_object_is_lmem(ggtt->vm.scratch[0]))
+   pte_flags |= PTE_LM;
+
+   ggtt->vm.scratch[0]->encode =
+   ggtt->vm.pte_encode(px_dma(ggtt->vm.scratch[0]),
+   I915_CACHE_NONE, 0);
+
/*
 * Note that we use page colouring to enforce a guard page at the
 * end of the address space. This is required as the CS may prefetch
 * beyond the end of the batch buffer, across the page boundary,
 * and beyond the end of the GTT if we do not provide a guard.
 */
-   ret = ggtt_init_hw(>ggtt);
-   if (ret)
-   return ret;
-
-   return 0;
+   return ggtt_init_hw(ggtt);
 }
 
 /*
@@ -803,8 +813,6 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
struct drm_i915_private *i915 = ggtt->vm.i915;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
-   u32 pte_flags;
-   int ret;
 
/* For Modern GENs the PTEs and register space are split in the BAR */
phys_addr = pci_resource_start(pdev, 0) + pci_resource_len(pdev, 0) / 2;
@@ -825,22 +833,6 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
return -ENOMEM;
}
 
-   ret = setup_scratch_page(>vm);
-   if (ret) {
-   drm_err(>drm, "Scratch setup failed\n");
-   /* iounmap will also get called at remove, but meh */
-   iounmap(ggtt->gsm);
-   return ret;
-   }
-
-   pte_flags = 0;
-   if (i915_gem_object_is_lmem(ggtt->vm.scratch[0]))
-   pte_flags |= PTE_LM;
-
-   ggtt->vm.scratch[0]->encode =
-   ggtt->vm.pte_encode(px_dma(ggtt->vm.scratch[0]),
-   I915_CACHE_NONE, pte_flags);
-
return 0;
 }
 
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915: Probe system memory regions before enabling HW

[Chris Wilson]

If we want to track system/stolen as memory regions, we need to setup
our bookkeeping *before* we want to start allocating and reserving
objects in those regions. In particular, in setup up the GGTT we will
try to preallocate stolen regions configured by the BIOS, and so should
prepare the system-stolen memory region beforehand.

Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b708517d3972..139cea4443fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -557,6 +557,10 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
i915_perf_init(dev_priv);
 
+   ret = intel_memory_regions_hw_probe(dev_priv);
+   if (ret)
+   goto err_ggtt;
+
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
goto err_perf;
@@ -569,10 +573,6 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
if (ret)
goto err_ggtt;
 
-   ret = intel_memory_regions_hw_probe(dev_priv);
-   if (ret)
-   goto err_ggtt;
-
intel_gt_init_hw_early(_priv->gt, _priv->ggtt);
 
ret = intel_gt_probe_lmem(_priv->gt);
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915/display: Handle lane polarity for DDI port

[Uma Shankar]

Lane Reversal is required for some of the DDI ports. This information
is populated in VBT and driver should read the same and set the
polarity while enabling the port. This patch handles the same.

It helps fix a display blankout issue on DP ports on certain
platforms.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 17 +
 drivers/gpu/drm/i915/display/intel_bios.h |  2 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +++
 3 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7118530a1c38..dd51413e7f45 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2674,6 +2674,23 @@ intel_bios_is_lspcon_present(const struct 
drm_i915_private *i915,
return HAS_LSPCON(i915) && child && child->lspcon;
 }
 
+/**
+ * intel_bios_is_lane_reversal_needed - if lane reversal needed on port
+ * @i915:   i915 device instance
+ * @port:   port to check
+ *
+ * Return true if port requires lane reversal
+ */
+bool
+intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
+  enum port port)
+{
+   const struct child_device_config *child =
+   i915->vbt.ddi_port_info[port].child;
+
+   return child && child->lane_reversal;
+}
+
 enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv,
   enum port port)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index e29e79faa01b..f25190ecfe97 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -241,6 +241,8 @@ bool intel_bios_is_port_hpd_inverted(const struct 
drm_i915_private *i915,
 enum port port);
 bool intel_bios_is_lspcon_present(const struct drm_i915_private *i915,
  enum port port);
+bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
+   enum port port);
 enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum 
port port);
 bool intel_bios_get_dsc_params(struct intel_encoder *encoder,
   struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3c4003605f93..2d6906f6995f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4082,6 +4082,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
intel_de_read(dev_priv, DDI_BUF_CTL(port))
& (DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
 
+   if (intel_bios_is_lane_reversal_needed(dev_priv, port))
+   dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
+
dig_port->dp.output_reg = INVALID_MMIO_REG;
dig_port->max_lanes = intel_ddi_max_lanes(dig_port);
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
-- 
2.26.2

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

Re: [Intel-gfx] [PATCH] i915/perf: Drop the check for report reason in OA

[Lionel Landwerlin]

On 10/02/2021 21:01, Umesh Nerlige Ramappa wrote:

After fixing the OA_TAIL_PTR corruption, there are no more reports with
reason field of zero. Drop the check for report reason.

Signed-off-by: Umesh Nerlige Ramappa 



I thought I push this patch already :|

Reviewed-by: Lionel Landwerlin 



---
  drivers/gpu/drm/i915/i915_perf.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 93f3e2c5c89a..c15bead2dac7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -725,11 +725,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
  (IS_GEN(stream->perf->i915, 12) ?
   OAREPORT_REASON_MASK_EXTENDED :
   OAREPORT_REASON_MASK));
-   if (reason == 0) {
-   if (__ratelimit(>perf->spurious_report_rs))
-   DRM_NOTE("Skipping spurious, invalid OA 
report\n");
-   continue;
-   }
  
  		ctx_id = report32[2] & stream->specific_ctx_id_mask;
  



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

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Chris Wilson]

Quoting Hans de Goede (2021-02-11 10:36:13)
> Hi,
> 
> On 2/10/21 1:48 PM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-10 10:37:19)
> >> Hi,
> >>
> >> On 2/10/21 12:07 AM, Chris Wilson wrote:
> >>> Quoting Hans de Goede (2021-02-09 11:46:46)
>  Hi,
> 
>  On 2/9/21 12:27 AM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-08 20:38:58)
> >> Hi All,
> >>
> >> We (Fedora) have been receiving reports from multiple users about gfx 
> >> issues / glitches
> >> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell 
> >> iGPUs and all
> >> reporters report that adding i915.mitigations=off to the cmdline fixes 
> >> things, see:
> >
> > I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> > did not report any differences with and without mitigations. I have yet
> > to test other platforms. So I don't yet have an alternative.
> 
>  Note the original / first reporter of:
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1925346
> 
>  Is using hsw-gt2, so it seems that the problem is not just the enabling 
>  of
>  the mitigations on ivy-bridge / bay-trail but that there actually is
>  a regression on devices where the WA worked fine before...
> >>>
> >>> There have been 3 crashes uploaded related to v5.10.9, and in all 3
> >>> cases the ACTHD has been in the first page. This strongly suggests that
> >>> the w/a is scribbling over address 0. And there's then a very good
> >>> chance that
> >>>
> >>> commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> >>> Author: Chris Wilson 
> >>> Date:   Mon Jan 25 12:50:33 2021 +
> >>>
> >>> drm/i915/gt: Always try to reserve GGTT address 0x0
> >>> 
> >>> commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
> >>>
> >>> in v5.10.14 is sufficient to hide the issue.
> >>
> >> That one actually is already in v5.10.13 and the various reportes of these
> >> issues have already tested 5.10.13. They did mention that it took longer
> >> to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:
> >>
> >> "drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5
> > 
> > Started looking for scratch page overwrites, and found this little gem:
> > https://patchwork.freedesktop.org/patch/420436/?series=86947=1
> > 
> > Looks promising wrt the cause of overwriting random addresses -- and
> > I hope that is the explanation for the glitches/hangs. I have a hsw gt2
> > with gnome shell, piglit is happy, but I suspect it is all due to
> > placement and so will only occur at random.
> 
> If you can give me a list of commits to cherry-pick then I can prepare
> a Fedora 5.10.y kernel which those added for the group of Fedora users
> who are hitting this to test.

e627d5923cae ("drm/i915/gt: One more flush for Baytrail clear residuals")
d30bbd62b1bf ("drm/i915/gt: Flush before changing register state")
1914911f4aa0 ("drm/i915/gt: Correct surface base address for renderclear")

are missing from v5.10.15
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/perf: Drop the check for report reason in OA (rev2)

[Patchwork]

== Series Details ==

Series: i915/perf: Drop the check for report reason in OA (rev2)
URL   : https://patchwork.freedesktop.org/series/84478/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9760_full -> Patchwork_19654_full


Summary
---

  **FAILURE**

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

### Piglit changes ###

 Possible regressions 

  * spec@!opengl 3.0@clearbuffer-invalid-buffer (NEW):
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][1] +1 similar issue
   [1]: None

  
New tests
-

  New tests have been introduced between CI_DRM_9760_full and 
Patchwork_19654_full:

### New Piglit tests (2) ###

  * spec@!opengl 3.0@clearbuffer-invalid-buffer:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@!opengl 3.0@clearbuffer-mixed-format:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-apl3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-apl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +66 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-apl6/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-iclb6/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-iclb4/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@hang:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / 
[i915#2295])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-iclb6/igt@gem_exec_balan...@hang.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-iclb4/igt@gem_exec_balan...@hang.html

  * igt@gem_exec_create@forked:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-glk4/igt@gem_exec_cre...@forked.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-glk5/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][11] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-apl1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9760/shard-tglb3/igt@gem_exec_fair@basic-p...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-tglb8/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][18] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][19] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19654/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][20] 

Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues

[Hans de Goede]

Hi,

On 2/10/21 1:48 PM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-10 10:37:19)
>> Hi,
>>
>> On 2/10/21 12:07 AM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-09 11:46:46)
 Hi,

 On 2/9/21 12:27 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-08 20:38:58)
>> Hi All,
>>
>> We (Fedora) have been receiving reports from multiple users about gfx 
>> issues / glitches
>> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell 
>> iGPUs and all
>> reporters report that adding i915.mitigations=off to the cmdline fixes 
>> things, see:
>
> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> did not report any differences with and without mitigations. I have yet
> to test other platforms. So I don't yet have an alternative.

 Note the original / first reporter of:

 https://bugzilla.redhat.com/show_bug.cgi?id=1925346

 Is using hsw-gt2, so it seems that the problem is not just the enabling of
 the mitigations on ivy-bridge / bay-trail but that there actually is
 a regression on devices where the WA worked fine before...
>>>
>>> There have been 3 crashes uploaded related to v5.10.9, and in all 3
>>> cases the ACTHD has been in the first page. This strongly suggests that
>>> the w/a is scribbling over address 0. And there's then a very good
>>> chance that
>>>
>>> commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
>>> Author: Chris Wilson 
>>> Date:   Mon Jan 25 12:50:33 2021 +
>>>
>>> drm/i915/gt: Always try to reserve GGTT address 0x0
>>> 
>>> commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
>>>
>>> in v5.10.14 is sufficient to hide the issue.
>>
>> That one actually is already in v5.10.13 and the various reportes of these
>> issues have already tested 5.10.13. They did mention that it took longer
>> to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:
>>
>> "drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5
> 
> Started looking for scratch page overwrites, and found this little gem:
> https://patchwork.freedesktop.org/patch/420436/?series=86947=1
> 
> Looks promising wrt the cause of overwriting random addresses -- and
> I hope that is the explanation for the glitches/hangs. I have a hsw gt2
> with gnome shell, piglit is happy, but I suspect it is all due to
> placement and so will only occur at random.

If you can give me a list of commits to cherry-pick then I can prepare
a Fedora 5.10.y kernel which those added for the group of Fedora users
who are hitting this to test.

FWIW those users have reported back that the 3 reverts which I mentioned
earlier do indeed restore normal functionality (without glitches) for them.

Regards,

Hans

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Sanitize GPU during prepare-to-suspend

[Chris Wilson]

Quoting Rodrigo Vivi (2021-02-11 04:25:17)
> On Wed, Feb 10, 2021 at 10:19:50PM +, Chris Wilson wrote:
> > After calling intel_gt_suspend_prepare(), the driver starts to turn off
> > various subsystems, such as clearing the GGTT, before calling
> > intel_gt_suspend_late() to relinquish control over the GT. However, if
> > we still have internal GPU state active as we clear the GGTT, the GPU
> > may write back its internal state to the residual GGTT addresses that
> > are now pointing into scratch. Let's reset the GPU to clear that
> > internal state as soon we have idled the GPU in prepare-to-suspend.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > index 0bd303d2823e..f41612faa269 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > @@ -295,6 +295,9 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
> >   wait_for_suspend(gt);
> 
> you just wedged the gpu here...

Potentially. As a means to clear a stuck GPU and force it to idle.
 
> >   intel_uc_suspend(>uc);
> > +
> > + /* Flush all the contexts and internal state before turning off GGTT 
> > */
> > + gt_sanitize(gt, false);
> 
> and now we are unsetting wedge here...
> 
> is this right?

But irrelevant, since it is undone on any of the resume pathways which
must be taken by this point.

Resume has been for many years the method to unwedge a GPU; with the
presumption being that the intervening PCI level reset would be enough
to recover the GPU. Otherwise, it would presumably quite quickly go back
into the wedged state.

The wedging on suspend is just there to cancel outstanding work. Which
is not what we want (we just want to remove work), but is what we have
for the moment. The sanitize is to make sure we don't leak our state
beyond our control of the HW.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave & Daniel -

Calming down, just a couple of Cc: stable fixes now.


drm-intel-fixes-2021-02-11:
drm/i915 fixes for v5.11 final:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking

BR,
Jani.

The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:

  Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-02-11

for you to fetch changes up to 5feba0e905c495a217aea9db4ea91093d8fe5dde:

  drm/i915: Fix overlay frontbuffer tracking (2021-02-10 11:03:56 +0200)


drm/i915 fixes for v5.11 final:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking


Imre Deak (1):
  drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it

Ville Syrjälä (1):
  drm/i915: Fix overlay frontbuffer tracking

 drivers/gpu/drm/i915/display/intel_overlay.c | 17 ---
 drivers/gpu/drm/i915/display/intel_tc.c  | 67 +++-
 2 files changed, 45 insertions(+), 39 deletions(-)

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Clear internal GT state on hibernate

[Chris Wilson]

Quoting Rodrigo Vivi (2021-02-11 04:28:41)
> On Wed, Feb 10, 2021 at 10:19:51PM +, Chris Wilson wrote:
> > Call intel_gt_suspend_late() to disable the GT before hibernation.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > index 000e1cd8e920..da0ef483ad6b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> > @@ -115,6 +115,8 @@ int i915_gem_freeze_late(struct drm_i915_private *i915)
> >* the objects as well, see i915_gem_freeze()
> >*/
> >  
> > + intel_gt_suspend_late(>gt);
> > +
> 
> why are you calling this here instead of directly in i915_drm_suspend_late ?

For symmetry with the current code paths.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI2.1 PCON Misc Fixes (rev2)

[Patchwork]

== Series Details ==

Series: HDMI2.1 PCON Misc Fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/86677/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9761 -> Patchwork_19658


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][3] -> [INCOMPLETE][4] ([i915#142] / 
[i915#2405])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@runner@aborted:
- fi-byt-j1900:   NOTRUN -> [FAIL][5] ([i915#1814] / [i915#2505])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_render_tiled_blits@basic:
- fi-tgl-y:   [DMESG-WARN][6] ([i915#402]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19658/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html

  
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 39)
--

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


Build changes
-

  * Linux: CI_DRM_9761 -> Patchwork_19658

  CI-20190529: 20190529
  CI_DRM_9761: fc52fc2a7332bd301f802ca3a0444a8fb9fe4f7f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6001: d0d6f5e14ef181c93e4b503b05d9c18fa480e09d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19658: bca376cff954e27b863d6eb0c6f93893a9a370a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bca376cff954 i915/display: Remove FRL related code from disable DP sequence for 
older platforms
32f0512988b4 drm/dp_helper: Define options for FRL training for HDMI2.1 PCON
3a1860f8a654 i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 
1.4

== Logs ==

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