[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
URL   : https://patchwork.freedesktop.org/series/93570/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20921_full


Summary
---

  **FAILURE**

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

### Piglit changes ###

 Possible regressions 

  * spec@!opengl 3.0@required-renderbuffer-attachment-formats (NEW):
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][1] +2 similar issues
   [1]: None

  
New tests
-

  New tests have been introduced between CI_DRM_10537_full and 
Patchwork_20921_full:

### New Piglit tests (3) ###

  * spec@!opengl 3.0@render-integer:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@!opengl 3.0@required-renderbuffer-attachment-formats:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@!opengl 3.0@required-sized-texture-formats:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-apl2/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb6/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb3/igt@gem_...@in-flight-contexts-immediate.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb2/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb8/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb2/igt@gem_...@unwedge-stress.html
- shard-snb:  NOTRUN -> [FAIL][10] ([i915#3354])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb5/igt@gem_...@unwedge-stress.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_20921/shard-apl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb8/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb5/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#1888] / [i915#307])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-glk6/igt@gem_mmap_...@cpuset-big-copy.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-glk9/igt@gem_mmap_...@cpuset-big-copy.html

  * 

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Remove require_force_probe protection

2021-09-06 Thread Siddiqui, Ayaz A



> -Original Message-
> From: Intel-gfx  On Behalf Of Talla
> Raviteja Goud
> Sent: Friday, September 3, 2021 11:51 PM
> To: intel-gfx@lists.freedesktop.org; Surendrakumar Upadhyay, TejaskumarX
> ; Meena, Mahesh
> ; Pandey, Hariom 
> Cc: Talla, RavitejaX Goud ; De Marchi, Lucas
> 
> Subject: [Intel-gfx] [PATCH] drm/i915/adl_s: Remove require_force_probe
> protection
> 
> From: ravitejax 
> 
> Removing force probe protection from ADLS platform. Did not observe
> warnings, errors, flickering or any visual defects while doing ordinary tasks
> like browsing and editing documents in a two monitor setup.
> 
> For more info drm-tip idle run results :
> https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html?
> 
> Cc: Lucas De Marchi 
> Signed-off-by: ravitejax 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c index 03a820955458..d4a6a9dcf182
> 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -912,7 +912,6 @@ static const struct intel_device_info adl_s_info = {
>   GEN12_FEATURES,
>   PLATFORM(INTEL_ALDERLAKE_S),
>   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> - .require_force_probe = 1,

AFIR, force probe removal was blocked for MOCS update, which is landed on 
drm-tip. 
LGTM. 
Reviewed-by: Ayaz A Siddiqui 
>   .display.has_hti = 1,
>   .display.has_psr_hw_tracking = 0,
>   .platform_engine_mask =
> --
> 2.30.2



Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)

2021-09-06 Thread Gupta, Anshuman
Hi Jaswanth ,
Could you please raise a issue for below failure and re-report the results.
https://patchwork.freedesktop.org/series/93570/
Thanks,
Anshuman Gupta.

> -Original Message-
> From: Gupta, Anshuman
> Sent: Tuesday, September 7, 2021 9:52 AM
> To: Li, Juston ; Vudum, Lakshminarayana
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST
> dock fixes (rev8)
> 
> Hi Lakshmi ,
> Below test failure are not related to Display  and HDCP.
> 
> spec@!opengl 3.0@required-renderbuffer-attachment-formats (NEW):
>   pig-glk-j5005: NOTRUN -> INCOMPLETE +2 similar issues
> 
> Could you please raise issue and re-report the results.
> 
> Thanks,
> Anshuman Gupta.
> 
> From: Intel-gfx  On Behalf Of
> Patchwork
> Sent: Tuesday, August 31, 2021 2:41 AM
> To: Li, Juston 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock
> fixes (rev8)
> 
> Patch Details
> Series:
> drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
> URL:
> https://patchwork.freedesktop.org/series/93570/
> State:
> failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/index.html
> CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20921_full
> Summary FAILURE Serious unknown changes coming with Patchwork_20921_full
> absolutely need to be verified manually.
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_20921_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_20921_full:
> Piglit changes
> Possible regressions
> • spec@!opengl mailto:3.0@required-renderbuffer-attachment-formats (NEW):
> o pig-glk-j5005: NOTRUN -> None +2 similar issues New tests New tests have
> been introduced between CI_DRM_10537_full and Patchwork_20921_full:
> New Piglit tests (3)
> • spec@!opengl mailto:3.0@render-integer:
> o Statuses : 1 incomplete(s)
> o Exec time: [0.0] s
> • spec@!opengl mailto:3.0@required-renderbuffer-attachment-formats:
> o Statuses : 1 incomplete(s)
> o Exec time: [0.0] s
> • spec@!opengl mailto:3.0@required-sized-texture-formats:
> o Statuses : 1 incomplete(s)
> o Exec time: [0.0] s
> Known issues
> Here are the changes found in Patchwork_20921_full that come from known
> issues:
> IGT changes
> Issues hit
> • igt@gem_create@create-massive:
> o shard-snb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_20921/shard-snb5/igt@gem_cre...@create-massive.html
> ([i915#3002]) • igt@gem_ctx_isolation@preservation-s3@vcs0:
> o shard-apl: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> apl6/igt@gem_ctx_isolation@preservation...@vcs0.html -> https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_20921/shard-
> apl2/igt@gem_ctx_isolation@preservation...@vcs0.html ([i915#180]) •
> igt@gem_ctx_persistence@smoketest:
> o shard-snb: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_20921/shard-snb6/igt@gem_ctx_persiste...@smoketest.html
> ([fdo#109271] / [i915#1099]) +5 similar issues • igt@gem_eio@in-flight-
> contexts-immediate:
> o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> iclb3/igt@gem_...@in-flight-contexts-immediate.html -> https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb2/igt@gem_eio@in-flight-
> contexts-immediate.html ([i915#3070]) • igt@gem_eio@unwedge-stress:
> o shard-tglb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> tglb8/igt@gem_...@unwedge-stress.html -> https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb2/igt@gem_eio@unwedge-
> stress.html ([i915#2369] / [i915#3063] / [i915#3648]) o shard-snb: NOTRUN ->
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-
> snb5/igt@gem_...@unwedge-stress.html ([i915#3354]) •
> igt@gem_exec_fair@basic-deadline:
> o shard-apl: NOTRUN -> https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_20921/shard-apl6/igt@gem_exec_f...@basic-deadline.html
> ([i915#2846]) • igt@gem_exec_fair@basic-none-vip@rcs0:
> o shard-tglb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html -> https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_20921/shard-
> tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html ([i915#2842]) +1 similar
> issue • igt@gem_exec_fair@basic-pace-share@rcs0:
> o shard-glk: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html -> https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_20921/shard-
> glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html ([i915#2842]) +1 similar
> issue • igt@gem_exec_fair@basic-pace@vecs0:
> o shard-iclb: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-
> iclb8/igt@gem_exec_fair@basic-p...@vecs0.html -> https://intel-gfx-
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add support for remapping CCS FBs (rev3)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adlp: Add support for remapping CCS FBs (rev3)
URL   : https://patchwork.freedesktop.org/series/94108/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10553_full -> Patchwork_20971_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@sysfs-reader:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb2/igt@i915_susp...@sysfs-reader.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-iclb3/igt@i915_susp...@sysfs-reader.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][3] ([fdo#111827])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-tglb8/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@display-2x:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-tglb3/igt@feature_discov...@display-2x.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-snb5/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb3/igt@gem_...@in-flight-contexts-1us.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-iclb3/igt@gem_...@in-flight-contexts-1us.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_10553/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk5/igt@gem_exec_f...@basic-deadline.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-glk2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb6/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-tglb3/igt@gem_exec_fair@basic-p...@rcs0.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_20971/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_parallel@engines@basic:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
[i915#95]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk9/igt@gem_exec_parallel@engi...@basic.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/shard-glk7/igt@gem_exec_parallel@engi...@basic.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#112283])
   [22]: 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)

2021-09-06 Thread Gupta, Anshuman
Hi Lakshmi ,
Below test failure are not related to Display  and HDCP.

spec@!opengl 3.0@required-renderbuffer-attachment-formats (NEW):
pig-glk-j5005: NOTRUN -> INCOMPLETE +2 similar issues

Could you please raise issue and re-report the results.

Thanks,
Anshuman Gupta. 

From: Intel-gfx  On Behalf Of Patchwork
Sent: Tuesday, August 31, 2021 2:41 AM
To: Li, Juston 
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock 
fixes (rev8)

Patch Details 
Series:
drm/i915/hdcp: HDCP2.2 MST dock fixes (rev8)
URL:
https://patchwork.freedesktop.org/series/93570/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/index.html
CI Bug Log - changes from CI_DRM_10537_full -> Patchwork_20921_full
Summary
FAILURE
Serious unknown changes coming with Patchwork_20921_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20921_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_20921_full:
Piglit changes
Possible regressions
• spec@!opengl mailto:3.0@required-renderbuffer-attachment-formats (NEW):
o pig-glk-j5005: NOTRUN -> None +2 similar issues
New tests
New tests have been introduced between CI_DRM_10537_full and 
Patchwork_20921_full:
New Piglit tests (3)
• spec@!opengl mailto:3.0@render-integer:
o Statuses : 1 incomplete(s)
o Exec time: [0.0] s
• spec@!opengl mailto:3.0@required-renderbuffer-attachment-formats:
o Statuses : 1 incomplete(s)
o Exec time: [0.0] s
• spec@!opengl mailto:3.0@required-sized-texture-formats:
o Statuses : 1 incomplete(s)
o Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_20921_full that come from known issues:
IGT changes
Issues hit
• igt@gem_create@create-massive:
o shard-snb: NOTRUN -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb5/igt@gem_cre...@create-massive.html
 ([i915#3002])
• igt@gem_ctx_isolation@preservation-s3@vcs0:
o shard-apl: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-apl6/igt@gem_ctx_isolation@preservation...@vcs0.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-apl2/igt@gem_ctx_isolation@preservation...@vcs0.html
 ([i915#180])
• igt@gem_ctx_persistence@smoketest:
o shard-snb: NOTRUN -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb6/igt@gem_ctx_persiste...@smoketest.html
 ([fdo#109271] / [i915#1099]) +5 similar issues
• igt@gem_eio@in-flight-contexts-immediate:
o shard-iclb: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb3/igt@gem_...@in-flight-contexts-immediate.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb2/igt@gem_...@in-flight-contexts-immediate.html
 ([i915#3070])
• igt@gem_eio@unwedge-stress:
o shard-tglb: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb8/igt@gem_...@unwedge-stress.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb2/igt@gem_...@unwedge-stress.html
 ([i915#2369] / [i915#3063] / [i915#3648])
o shard-snb: NOTRUN -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-snb5/igt@gem_...@unwedge-stress.html
 ([i915#3354])
• igt@gem_exec_fair@basic-deadline:
o shard-apl: NOTRUN -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-apl6/igt@gem_exec_f...@basic-deadline.html
 ([i915#2846])
• igt@gem_exec_fair@basic-none-vip@rcs0:
o shard-tglb: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
 ([i915#2842]) +1 similar issue
• igt@gem_exec_fair@basic-pace-share@rcs0:
o shard-glk: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
 ([i915#2842]) +1 similar issue
• igt@gem_exec_fair@basic-pace@vecs0:
o shard-iclb: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-iclb8/igt@gem_exec_fair@basic-p...@vecs0.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb5/igt@gem_exec_fair@basic-p...@vecs0.html
 ([i915#2842])
• igt@gem_mmap_gtt@cpuset-big-copy:
o shard-glk: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10537/shard-glk6/igt@gem_mmap_...@cpuset-big-copy.html
 -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-glk9/igt@gem_mmap_...@cpuset-big-copy.html
 ([i915#1888] / [i915#307])
• igt@gem_render_copy@y-tiled-mc-ccs-to-yf-tiled-ccs:
o shard-iclb: NOTRUN -> 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20921/shard-iclb7/igt@gem_render_c...@y-tiled-mc-ccs-to-yf-tiled-ccs.html
 ([i915#768])
• 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

2021-09-06 Thread Gupta, Anshuman


> -Original Message-
> From: Latvala, Petri 
> Sent: Monday, September 6, 2021 4:56 PM
> To: Tvrtko Ursulin 
> Cc: jim.cro...@gmail.com; Intel Graphics Development  g...@lists.freedesktop.org>; Bhatt, Jigar ; Gupta,
> Anshuman 
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to
> implement DRM.debug (rev2)
> 
> On Mon, Sep 06, 2021 at 11:04:13AM +0100, Tvrtko Ursulin wrote:
> >
> > On 03/09/2021 14:01, Petri Latvala wrote:
> > > On Fri, Sep 03, 2021 at 12:29:51PM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 03/09/2021 01:31, jim.cro...@gmail.com wrote:
> > > > >
> > > > >
> > > > > On Tue, Aug 31, 2021 at 5:38 PM Patchwork
> > > > >  > > > > > wrote:
> > > > >
> > > > >  __
> > > > >  *Patch Details*
> > > > >  *Series:*use DYNAMIC_DEBUG to implement DRM.debug (rev2)
> > > > >  *URL:*   https://patchwork.freedesktop.org/series/93914/
> > > > >  
> > > > >  *State:* failure
> > > > >  *Details:*
> > > > >  
> > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.html
> > > > >
> > > > >  > > > > html>
> > > > >
> > > > >
> > > > >CI Bug Log - changes from CI_DRM_10541_full ->
> > > > > Patchwork_20931_full
> > > > >
> > > > >
> > > > >  Summary
> > > > >
> > > > >  *FAILURE*
> > > > >
> > > > >  Serious unknown changes coming with Patchwork_20931_full
> absolutely
> > > > >  need to be
> > > > >  verified manually.
> > > > >
> > > > >  If you think the reported changes have nothing to do with the 
> > > > > changes
> > > > >  introduced in Patchwork_20931_full, please notify your bug team 
> > > > > to
> > > > >  allow them
> > > > >  to document this new failure mode, which will reduce false 
> > > > > positives
> > > > >  in CI.
> > > > >
> > > > >
> > > > > hi Team !
> > > > >
> > > > > I think I need a bit of orientation.
> > > > >
> > > > >
> > > > >  Possible new issues
> > > > >
> > > > >  Here are the unknown changes that may have been introduced in
> > > > >  Patchwork_20931_full:
> > > > >
> > > > >
> > > > >IGT changes
> > > > >
> > > > >
> > > > >  Possible regressions
> > > > >
> > > > >* igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
> > > > >o shard-skl: NOTRUN -> INCOMPLETE
> > > > >
> > > > >  > > > > skl10/igt@gem_exec_schedule@u-submit-golden-sl...@vcs0.html>
> > > > >
> > > > >
> > > > >  Warnings
> > > > >
> > > > >* igt@i915_pm_dc@dc9-dpms:
> > > > >o shard-skl: SKIP
> > > > >  
> > > > >  skl6/igt@i915_pm...@dc9-dpms.html>
> > > > >  ([fdo#109271]) -> FAIL
I915_pm_dc test failures are not related to your series , probably  this 
failure can be ignored.
Br,
Anshuman Gupta.
> > > > >
> > > > >  > > > > skl8/igt@i915_pm...@dc9-dpms.html>
> > > > >
> > > > >
> > > > >
> > > > > Im assuming the FAIL is the sticking point,
> > > >
> > > > Both INCOMPLETE and FAIL will cause a failure to be declared, but in 
> > > > this
> case it looks to me this series is not at fault.
> > > >
> > > > 1)
> > > >
> > > > The gem_exec_schedule failure looks like a test runner timeout issue 
> > > > (and
> apparently test does not handle well running the the fence timeout enabled).
> > > >
> > > > @Petri - does the below look like IGT runner running our of time
> > > > budget for the test run? Would it log
> > > >
> > > > [1051.943629] [114/138] ( 11s left) gem_exec_schedule
> > > > (u-submit-golden-slice) Starting subtest: u-submit-golden-slice
> > > > Starting dynamic subtest: rcs0 Dynamic subtest rcs0: SUCCESS
> > > > (80.175s) Starting dynamic subtest: bcs0 Dynamic subtest bcs0:
> > > > SUCCESS (80.195s) Starting dynamic subtest: vcs0 Dynamic subtest
> > > > vcs0: SUCCESS (80.243s) Starting dynamic subtest: vecs0
> > > >
> > > > Interesting part is that according to dmesg it never got to the vecs0
> dynamic subtest - any idea what happened there?
> > >
> > > Yep, we ran out of time. We still had 11 seconds left to execute
> > > something but then that test took centuries.
> >
> > Okay at least that's explained then.
> >
> > Perhaps could make that act of termination logged in igt_runner log?
> 
> We do log everything we can, but unfortunately this was such an extreme case
> that it hit the timeout that just cuts off AC power.
> 
> run.log has this act logged.
> 
> >
> > Also, any explanation on why dmesg and igt_runner log disagree on how
> > far the test progressed (in terms of which subtest was active when
> > things ended)?
> >
> 
> Looks like a race condition with the above mentioned AC cutoff. The 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp: Add support for remapping CCS FBs (rev3)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adlp: Add support for remapping CCS FBs (rev3)
URL   : https://patchwork.freedesktop.org/series/94108/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20971


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][2] -> [INCOMPLETE][3] ([i915#155])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][4] -> [FAIL][5] ([i915#1888])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@runner@aborted:
- fi-kbl-r:   NOTRUN -> [FAIL][6] ([i915#1569] / [i915#192] / 
[i915#193] / [i915#194] / [i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-kbl-r/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#1602] / [i915#2029])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u:   [INCOMPLETE][8] ([i915#198]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20971/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
bat-jsl-1 


Build changes
-

  * IGT: IGT_6197 -> IGTPW_6202
  * Linux: CI_DRM_10553 -> Patchwork_20971

  CI-20190529: 20190529
  CI_DRM_10553: 47b2bd2caa7b29b5741ff2521206657853b85165 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_6202: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6202/index.html
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20971: c8552aaceea7412b0a9ab9590a94399d8a144967 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c8552aaceea7 drm/fourcc: Add the ADL-P specific pitch requirements of CCS 
modifiers
6dc44341ecbf drm/i915/adlp: Add support for remapping CCS FBs
f2a2176817a5 drm/i915: Follow a new->old platform check order in 
intel_fb_stride_alignment
bc1f46e15e83 drm/i915/adlp: Assert that VMAs in DPT start at 0
3e3035b666ae drm/i915/adlp: Require always a power-of-two sized CCS surface 
stride
fcebda4f317f drm/i915: Use tile block based dimensions for CCS origin x, y check

== Logs ==

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


[Intel-gfx] [CI 1/6] drm/i915: Use tile block based dimensions for CCS origin x, y check

2021-09-06 Thread Imre Deak
The tile size for all surface types is 4 kbyte (or 2 kbyte on old
platforms), with the exception of the TGL/ADL CCS surface where the tile
size is 64 bytes. To be able to remap CCS FBs the CCS surface tile needs
to be defined as 4 kbyte as well (the granularity of GTT pages in a
remapped view).

The only place using the dimension of the 64 byte CCS area is the initial
check for the main vs. CCS plane origin coordinate match. To prepare for
adding support for remapping CCS FBs let's call the 64 byte CCS area a
'tile block' and add a helper to retrieve the dimensions for it.

No functional change.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 30 -
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index e4b8602ec0cd2..0cf568a9cb1c6 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -143,14 +143,14 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
 
 unsigned int intel_tile_height(const struct drm_framebuffer *fb, int 
color_plane)
 {
-   if (is_gen12_ccs_plane(fb, color_plane))
-   return 1;
-
return intel_tile_size(to_i915(fb->dev)) /
intel_tile_width_bytes(fb, color_plane);
 }
 
-/* Return the tile dimensions in pixel units */
+/*
+ * Return the tile dimensions in pixel units, based on the (2 or 4 kbyte) GTT
+ * page tile size.
+ */
 static void intel_tile_dims(const struct drm_framebuffer *fb, int color_plane,
unsigned int *tile_width,
unsigned int *tile_height)
@@ -162,6 +162,21 @@ static void intel_tile_dims(const struct drm_framebuffer 
*fb, int color_plane,
*tile_height = intel_tile_height(fb, color_plane);
 }
 
+/*
+ * Return the tile dimensions in pixel units, based on the tile block size.
+ * The block covers the full GTT page sized tile on all tiled surfaces and
+ * it's a 64 byte portion of the tile on TGL+ CCS surfaces.
+ */
+static void intel_tile_block_dims(const struct drm_framebuffer *fb, int 
color_plane,
+ unsigned int *tile_width,
+ unsigned int *tile_height)
+{
+   intel_tile_dims(fb, color_plane, tile_width, tile_height);
+
+   if (is_gen12_ccs_plane(fb, color_plane))
+   *tile_height = 1;
+}
+
 unsigned int intel_tile_row_size(const struct drm_framebuffer *fb, int 
color_plane)
 {
unsigned int tile_width, tile_height;
@@ -567,7 +582,12 @@ static int intel_fb_check_ccs_xy(const struct 
drm_framebuffer *fb, int ccs_plane
if (!is_ccs_plane(fb, ccs_plane) || is_gen12_ccs_cc_plane(fb, 
ccs_plane))
return 0;
 
-   intel_tile_dims(fb, ccs_plane, _width, _height);
+   /*
+* While all the tile dimensions are based on a 2k or 4k GTT page size
+* here the main and CCS coordinates must match only within a (64 byte
+* on TGL+) block inside the tile.
+*/
+   intel_tile_block_dims(fb, ccs_plane, _width, _height);
intel_fb_plane_get_subsampling(, , fb, ccs_plane);
 
tile_width *= hsub;
-- 
2.27.0



[Intel-gfx] [CI 0/6] drm/i915/adlp: Add support for remapping CCS FBs

2021-09-06 Thread Imre Deak
Resending [1] to test with the fixed IGT changes at [2]. Sending only a
cover letter doesn't seem to trigger a new patchwork test run, so try
again also sending the first patch.

[1] https://patchwork.freedesktop.org/series/94108/
[2] https://patchwork.freedesktop.org/series/94107/

Test-with: 20210907015807.3932309-1-imre.d...@intel.com

Cc: Juha-Pekka Heikkila 
Cc: Nanley G Chery 

Imre Deak (6):
  drm/i915: Use tile block based dimensions for CCS origin x, y check
  drm/i915/adlp: Require always a power-of-two sized CCS surface stride
  drm/i915/adlp: Assert that VMAs in DPT start at 0
  drm/i915: Follow a new->old platform check order in
intel_fb_stride_alignment
  drm/i915/adlp: Add support for remapping CCS FBs
  drm/fourcc: Add the ADL-P specific pitch requirements of CCS modifiers

 drivers/gpu/drm/i915/display/intel_display.c  |   5 +-
 .../drm/i915/display/intel_display_types.h|   2 -
 drivers/gpu/drm/i915/display/intel_fb.c   | 171 --
 .../drm/i915/display/skl_universal_plane.c|   5 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  29 ++-
 drivers/gpu/drm/i915/i915_vma_types.h |   7 +-
 include/uapi/drm/drm_fourcc.h |  24 ++-
 7 files changed, 174 insertions(+), 69 deletions(-)

-- 
2.27.0



[Intel-gfx] [CI 0/6] drm/i915/adlp: Add support for remapping CCS FBs

2021-09-06 Thread Imre Deak
Resending [1] to test with the fixed IGT changes at [2].

[1] https://patchwork.freedesktop.org/series/94108/
[2] https://patchwork.freedesktop.org/series/94107/

Test-with: 20210907015807.3932309-1-imre.d...@intel.com

Cc: Juha-Pekka Heikkila 
Cc: Nanley G Chery 

Imre Deak (6):
  drm/i915: Use tile block based dimensions for CCS origin x, y check
  drm/i915/adlp: Require always a power-of-two sized CCS surface stride
  drm/i915/adlp: Assert that VMAs in DPT start at 0
  drm/i915: Follow a new->old platform check order in
intel_fb_stride_alignment
  drm/i915/adlp: Add support for remapping CCS FBs
  drm/fourcc: Add the ADL-P specific pitch requirements of CCS modifiers

 drivers/gpu/drm/i915/display/intel_display.c  |   5 +-
 .../drm/i915/display/intel_display_types.h|   2 -
 drivers/gpu/drm/i915/display/intel_fb.c   | 171 --
 .../drm/i915/display/skl_universal_plane.c|   5 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  29 ++-
 drivers/gpu/drm/i915/i915_vma_types.h |   7 +-
 include/uapi/drm/drm_fourcc.h |  24 ++-
 7 files changed, 174 insertions(+), 69 deletions(-)

-- 
2.27.0



[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move display funcs into a display struct. (v2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915: move display funcs into a display struct. (v2)
URL   : https://patchwork.freedesktop.org/series/94396/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20970


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- fi-apl-guc: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-apl-guc/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-apl-guc/boot.html
- fi-kbl-8809g:   [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-kbl-8809g/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-kbl-8809g/boot.html
- fi-snb-2520m:   [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-snb-2520m/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-snb-2520m/boot.html
- fi-bsw-nick:[PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-bsw-nick/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-bsw-nick/boot.html
- fi-tgl-1115g4:  [PASS][9] -> [FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-tgl-1115g4/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-tgl-1115g4/boot.html
- fi-cfl-8109u:   [PASS][11] -> [FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-cfl-8109u/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-cfl-8109u/boot.html
- fi-cfl-8700k:   [PASS][13] -> [FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-cfl-8700k/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-cfl-8700k/boot.html
- fi-bxt-dsi: [PASS][15] -> [FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-bxt-dsi/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-bxt-dsi/boot.html
- fi-cml-u2:  [PASS][17] -> [FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-cml-u2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-cml-u2/boot.html
- fi-pnv-d510:[PASS][19] -> [FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-pnv-d510/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-pnv-d510/boot.html
- fi-ilk-650: [PASS][21] -> [FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-ilk-650/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-ilk-650/boot.html
- fi-bsw-n3050:   [PASS][23] -> [FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-bsw-n3050/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-bsw-n3050/boot.html
- fi-hsw-4770:[PASS][25] -> [FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-hsw-4770/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-hsw-4770/boot.html
- fi-cfl-guc: [PASS][27] -> [FAIL][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-cfl-guc/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-cfl-guc/boot.html
- fi-elk-e7500:   [PASS][29] -> [FAIL][30]
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-elk-e7500/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-elk-e7500/boot.html
- fi-glk-dsi: [PASS][31] -> [FAIL][32]
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-glk-dsi/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-glk-dsi/boot.html
- fi-ivb-3770:[PASS][33] -> [FAIL][34]
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-ivb-3770/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-ivb-3770/boot.html
- fi-rkl-guc: [PASS][35] -> [FAIL][36]
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-rkl-guc/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20970/fi-rkl-guc/boot.html
- fi-snb-2600:

[Intel-gfx] [PATCH] drm/i915: move display funcs into a display struct. (v2)

2021-09-06 Thread Dave Airlie
From: Dave Airlie 

This is the first step in an idea to refactor the display code
into a bit more of a corner.

v2: move display to being a pointer.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/display/intel_audio.c|  24 +--
 drivers/gpu/drm/i915/display/intel_cdclk.c| 148 +-
 drivers/gpu/drm/i915/display/intel_color.c|  64 
 drivers/gpu/drm/i915/display/intel_display.c  | 110 ++---
 .../drm/i915/display/intel_display_power.c|   2 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |  16 +-
 drivers/gpu/drm/i915/display/intel_fdi.c  |   6 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h   |  11 +-
 drivers/gpu/drm/i915/i915_irq.c   |  14 +-
 drivers/gpu/drm/i915/intel_pm.c   | 104 ++--
 11 files changed, 254 insertions(+), 249 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 532237588511..c8c7847498e1 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -848,8 +848,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
 
-   if (dev_priv->display.audio_codec_enable)
-   dev_priv->display.audio_codec_enable(encoder,
+   if (dev_priv->display->funcs.audio_codec_enable)
+   dev_priv->display->funcs.audio_codec_enable(encoder,
 crtc_state,
 conn_state);
 
@@ -893,8 +893,8 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
 
-   if (dev_priv->display.audio_codec_disable)
-   dev_priv->display.audio_codec_disable(encoder,
+   if (dev_priv->display->funcs.audio_codec_disable)
+   dev_priv->display->funcs.audio_codec_disable(encoder,
  old_crtc_state,
  old_conn_state);
 
@@ -922,17 +922,17 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
 void intel_init_audio_hooks(struct drm_i915_private *dev_priv)
 {
if (IS_G4X(dev_priv)) {
-   dev_priv->display.audio_codec_enable = g4x_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = g4x_audio_codec_disable;
+   dev_priv->display->funcs.audio_codec_enable = 
g4x_audio_codec_enable;
+   dev_priv->display->funcs.audio_codec_disable = 
g4x_audio_codec_disable;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
+   dev_priv->display->funcs.audio_codec_enable = 
ilk_audio_codec_enable;
+   dev_priv->display->funcs.audio_codec_disable = 
ilk_audio_codec_disable;
} else if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8) {
-   dev_priv->display.audio_codec_enable = hsw_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = hsw_audio_codec_disable;
+   dev_priv->display->funcs.audio_codec_enable = 
hsw_audio_codec_enable;
+   dev_priv->display->funcs.audio_codec_disable = 
hsw_audio_codec_disable;
} else if (HAS_PCH_SPLIT(dev_priv)) {
-   dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
-   dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
+   dev_priv->display->funcs.audio_codec_enable = 
ilk_audio_codec_enable;
+   dev_priv->display->funcs.audio_codec_disable = 
ilk_audio_codec_disable;
}
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 34fa4130d5c4..1aa45b46f317 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1466,7 +1466,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
*dev_priv,
 * at least what the CDCLK frequency requires.
 */
cdclk_config->voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk_config->cdclk);
+   
dev_priv->display->funcs.calc_voltage_level(cdclk_config->cdclk);
 }
 
 static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
@@ -1777,7 +1777,7 @@ static void bxt_cdclk_init_hw(struct drm_i915_private 
*dev_priv)
cdclk_config.cdclk = bxt_calc_cdclk(dev_priv, 0);
cdclk_config.vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk_config.cdclk);
cdclk_config.voltage_level =
-   dev_priv->display.calc_voltage_level(cdclk_config.cdclk);
+   

[Intel-gfx] RFC: refactor display into a pointer.

2021-09-06 Thread Dave Airlie
This is my alternate first patch for the sequence I proposed earlier.

Of course while I'm looking at funcs I realise a lot of them are kinda
pointless and could be refactored (tangents on tangents).

Dave.




[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Support for Plane Color Lut and CSC features (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: Add Support for Plane Color Lut and CSC features (rev2)
URL   : https://patchwork.freedesktop.org/series/90825/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10553_full -> Patchwork_20969_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@sysfs_heartbeat_interval@mixed@rcs0:
- shard-skl:  [PASS][3] -> [WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl8/igt@sysfs_heartbeat_interval@mi...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl6/igt@sysfs_heartbeat_interval@mi...@rcs0.html

  
 Suppressed 

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

  * igt@gem_eio@hibernate:
- {shard-rkl}:[PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-6/igt@gem_...@hibernate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-2/igt@gem_...@hibernate.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#1839])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@feature_discov...@display-2x.html

  * igt@gem_ctx_persistence@engines-queued:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-snb5/igt@gem_ctx_persiste...@engines-queued.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb6/igt@gem_...@unwedge-stress.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb4/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk5/igt@gem_exec_f...@basic-deadline.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-glk3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][17] -> [SKIP][18] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#112283])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][20] ([i915#2658]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl8/igt@gem_pr...@exhaustion.html

  * igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109312])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gem_soft...@evict-snoop.html

  * 

[Intel-gfx] ✓ Fi.CI.BAT: success for Add Support for Plane Color Lut and CSC features (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: Add Support for Plane Color Lut and CSC features (rev2)
URL   : https://patchwork.freedesktop.org/series/90825/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20969


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

  * igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [PASS][2] -> [DMESG-WARN][3] ([i915#3925])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

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

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u:   [INCOMPLETE][8] ([i915#198]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10553 -> Patchwork_20969

  CI-20190529: 20190529
  CI_DRM_10553: 47b2bd2caa7b29b5741ff2521206657853b85165 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20969: 7336f11261352439ed686c7ea33cfb1d1a167788 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7336f1126135 drm/i915/xelpd: Enable plane gamma
f8a38f97382c drm/i915/xelpd: Program Plane Gamma Registers
e8c016461e9a drm/i915/xelpd: Add register definitions for Plane Gamma
757106bc29dd drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
a3fc5412d19d drm: Add Plane Gamma Lut property
ec7dd2be1f37 drm: Add Plane Gamma Mode property
c80670d0ba61 drm/i915/xelpd: Enable Plane CSC
5c841e35f0e7 drm/i915/xelpd: Define Plane CSC Registers
cccf197af1b9 drm: Add helper to attach Plane ctm property
9a0a55da5520 drm: Add Plane CTM property
7b01dd73b025 drm/i915/xelpd: Load plane color luts from atomic flip
a66cbbe88e63 drm/i915/xelpd: Initialize plane color features
d64e7e814400 drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
853f0116ea83 drm/i915/xelpd: Program Plane Degamma Registers
790f94f18205 drm/i915/xelpd: Add color capabilities of SDR planes
3a31d402f88a drm/i915/xelpd: Enable plane color features
df616ff808c3 drm/i915/xelpd: Add register definitions for Plane Degamma
d92433346e40 drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
e54bf9c1c858 drm: Add Plane Degamma Lut property
39feb4a85cab drm: Add Plane Degamma Mode property
1e2ce83e3017 drm: Add Enhanced Gamma and color lut range attributes
0bd5f1aa34e1 drm: RFC for Plane Color Hardware Pipeline

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Support for Plane Color Lut and CSC features (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: Add Support for Plane Color Lut and CSC features (rev2)
URL   : https://patchwork.freedesktop.org/series/90825/
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:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add Support for Plane Color Lut and CSC features (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: Add Support for Plane Color Lut and CSC features (rev2)
URL   : https://patchwork.freedesktop.org/series/90825/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0bd5f1aa34e1 drm: RFC for Plane Color Hardware Pipeline
-:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#18: 
new file mode 100644

-:23: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#23: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:1:
+==

-:99: ERROR:TRAILING_WHITESPACE: trailing whitespace
#99: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:77:
+^I$

-:133: ERROR:TRAILING_WHITESPACE: trailing whitespace
#133: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:111:
+^I$

total: 2 errors, 2 warnings, 0 checks, 167 lines checked
1e2ce83e3017 drm: Add Enhanced Gamma and color lut range attributes
39feb4a85cab drm: Add Plane Degamma Mode property
e54bf9c1c858 drm: Add Plane Degamma Lut property
-:45: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#45: FILE: drivers/gpu/drm/drm_atomic_uapi.c:603:
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,

total: 0 errors, 0 warnings, 1 checks, 101 lines checked
d92433346e40 drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
df616ff808c3 drm/i915/xelpd: Add register definitions for Plane Degamma
-:37: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#37: FILE: drivers/gpu/drm/i915/i915_reg.h:11407:
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i)   \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))

-:49: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#49: FILE: drivers/gpu/drm/i915/i915_reg.h:11419:
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i)\
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))

-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#61: FILE: drivers/gpu/drm/i915/i915_reg.h:11431:
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i)   \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))

-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_reg.h:11443:
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i)\
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_DATA_2(pipe))

total: 0 errors, 0 warnings, 4 checks, 64 lines checked
3a31d402f88a drm/i915/xelpd: Enable plane color features
790f94f18205 drm/i915/xelpd: Add color capabilities of SDR planes
853f0116ea83 drm/i915/xelpd: Program Plane Degamma Registers
-:68: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#68: FILE: drivers/gpu/drm/i915/display/intel_color.c:2242:
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),

-:74: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#74: FILE: drivers/gpu/drm/i915/display/intel_color.c:2248:
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),

-:80: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#80: FILE: drivers/gpu/drm/i915/display/intel_color.c:2254:
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);

-:84: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#84: FILE: drivers/gpu/drm/i915/display/intel_color.c:2258:
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),

-:114: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#114: FILE: drivers/gpu/drm/i915/display/intel_color.c:2288:
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0), v);

total: 0 errors, 5 warnings, 0 checks, 148 lines checked
d64e7e814400 drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
a66cbbe88e63 drm/i915/xelpd: Initialize plane color features
7b01dd73b025 drm/i915/xelpd: Load plane color luts from atomic flip
9a0a55da5520 drm: Add Plane CTM property
-:41: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#41: FILE: drivers/gpu/drm/drm_atomic_uapi.c:610:
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,

total: 0 errors, 0 warnings, 1 checks, 87 lines checked
cccf197af1b9 drm: Add helper to attach Plane ctm property
5c841e35f0e7 drm/i915/xelpd: Define Plane CSC Registers
-:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add support for remapping CCS FBs (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adlp: Add support for remapping CCS FBs (rev2)
URL   : https://patchwork.freedesktop.org/series/94108/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10553_full -> Patchwork_20968_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-yf_tiled_ccs:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-skl2/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-yf_tiled_ccs.html

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs:
- shard-skl:  [PASS][2] -> [FAIL][3] +5 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-skl8/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_ccs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][4] ([fdo#111827])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-tglb1/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@display-2x:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#1839])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-tglb7/igt@feature_discov...@display-2x.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-snb5/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#3070])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb3/igt@gem_...@in-flight-contexts-1us.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-iclb3/igt@gem_...@in-flight-contexts-1us.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_10553/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-kbl7/igt@gem_exec_f...@basic-deadline.html
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk5/igt@gem_exec_f...@basic-deadline.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-glk3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-kbl3/igt@gem_exec_fair@basic-none-...@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_10553/shard-tglb6/igt@gem_exec_fair@basic-p...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-tglb7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][18] -> [SKIP][19] ([fdo#109271])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][20] -> [FAIL][21] ([i915#2842]) +3 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/shard-glk4/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- 

[Intel-gfx] [RFC v2 21/22] drm/i915/xelpd: Program Plane Gamma Registers

2021-09-06 Thread Uma Shankar
Extract the LUT and program plane gamma registers.
Enabled multi segmented lut as well.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 89 ++
 drivers/gpu/drm/i915/i915_reg.h|  9 ++-
 2 files changed, 94 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index b4cad5c92c85..e5f168a32932 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -27,6 +27,9 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_sprite.h"
+
+#include "skl_universal_plane.h"
+
 #include 
 
 #define CTM_COEFF_SIGN (1ULL << 63)
@@ -2433,16 +2436,102 @@ static void d13_program_plane_degamma_lut(const struct 
drm_plane_state *state,
}
 }
 
+static void d13_program_plane_gamma_lut(const struct drm_plane_state *state,
+   struct drm_color_lut_ext *gamma_lut,
+   u32 offset)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   u32 i, lut_size;
+
+   if (icl_is_hdr_plane(dev_priv, plane)) {
+   intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, 
plane, 0),
+  offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+   if (gamma_lut) {
+   lut_size = 32;
+   for (i = 0; i < lut_size; i++) {
+   u64 word = 
drm_color_lut_extract_ext(gamma_lut[i].green, 24);
+   u32 lut_val = (word & 0xff);
+
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  lut_val);
+   }
+
+   do {
+   /* Program the max register to clamp values > 
1.0. */
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  gamma_lut[i].green);
+   } while (i++ < 34);
+   } else {
+   lut_size = 32;
+   for (i = 0; i < lut_size; i++) {
+   u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+   }
+
+   do {
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  1 << 24);
+   } while (i++ < 34);
+   }
+
+   intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, 
plane, 0), 0);
+   } else {
+   lut_size = 32;
+   /*
+* First 3 planes are HDR, so reduce by 3 to get to the right
+* SDR plane offset
+*/
+   plane = plane - 3;
+
+   intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 
0),
+  offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+   if (gamma_lut) {
+   for (i = 0; i < lut_size; i++)
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+  gamma_lut[i].green & 0x);
+   /* Program the max register to clamp values > 1.0. */
+   while (i < 35)
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+  gamma_lut[i++].green & 0x3);
+   } else {
+   for (i = 0; i < lut_size; i++) {
+   u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0), v);
+   }
+
+   do {
+   intel_de_write(dev_priv, 
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+  (1 << 16));
+   } while (i++ < 34);
+   }
+
+   intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 
0), 0);
+   }
+}
+
 static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
 {
const struct drm_property_blob *degamma_lut_blob =
plane_state->degamma_lut;
+   const struct drm_property_blob *gamma_lut_blob =
+   plane_state->gamma_lut;
struct drm_color_lut_ext *degamma_lut = NULL;
+   struct 

[Intel-gfx] [RFC v2 22/22] drm/i915/xelpd: Enable plane gamma

2021-09-06 Thread Uma Shankar
Enable plane gamma feature in check callbacks. Decide
based on the user input.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 61eff22a3503..139863d4e3a7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -959,7 +959,9 @@ static u32 glk_plane_color_ctl(const struct 
intel_crtc_state *crtc_state,
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
u32 plane_color_ctl = 0;
 
-   plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+   /* FIXME needs hw.gamma_lut */
+   if (!plane_state->uapi.gamma_lut)
+   plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
 
/* FIXME needs hw.degamma_lut */
if (plane_state->uapi.degamma_lut)
-- 
2.26.2



[Intel-gfx] [RFC v2 20/22] drm/i915/xelpd: Add register definitions for Plane Gamma

2021-09-06 Thread Uma Shankar
Add macros to define Plane Gamma registers

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h | 73 +
 1 file changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ceee500e64d7..fc4f8b430518 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11464,6 +11464,79 @@ enum skl_power_gate {
_MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
_PLANE_PRE_CSC_GAMC_DATA_2(pipe))
 
+/* Display13 Plane Gamma Reg */
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A0x70160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B0x71160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A0x70260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B0x71260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe)_PIPE(pipe, 
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A, \
+   
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe)_PIPE(pipe, 
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A, \
+   
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH(pipe, plane, i) \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe), \
+   _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A 0x70164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B 0x71164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A 0x70264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B 0x71264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A, \
+   
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A, \
+   
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_DATA_ENH(pipe, plane, i)  \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe), \
+   _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A 0x701d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B 0x711d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A 0x702d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B 0x712d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_INDEX_ENH_1_A, \
+   
_PLANE_POST_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_INDEX_ENH_2_A, \
+   
_PLANE_POST_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, i)  \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe), \
+   _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_A  0x701dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_B  0x711dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_A  0x702dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_B  0x712dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe)  _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_DATA_ENH_1_A, \
+   
_PLANE_POST_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe)  _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_DATA_ENH_2_A, \
+   
_PLANE_POST_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, i)   \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe), \
+   _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_1_A 0x704d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1_B 0x714d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_A 0x705d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_B 0x715d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_INDEX_1_A, \
+   _PLANE_POST_CSC_GAMC_INDEX_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_INDEX_2_A, \
+   _PLANE_POST_CSC_GAMC_INDEX_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX(pipe, plane, i)  \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_1(pipe), \
+   _PLANE_POST_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_1_A  0x704dc
+#define _PLANE_POST_CSC_GAMC_DATA_1_B  0x714dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_A  0x705dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_B  0x715dc
+#define _PLANE_POST_CSC_GAMC_DATA_1(pipe)  _PIPE(pipe, 
_PLANE_POST_CSC_GAMC_DATA_1_A, \
+   

[Intel-gfx] [RFC v2 18/22] drm: Add Plane Gamma Lut property

2021-09-06 Thread Uma Shankar
Add Plane Gamma Lut as a blob property.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  3 +++
 drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
 drivers/gpu/drm/drm_color_mgmt.c  | 18 ++
 include/drm/drm_plane.h   | 14 ++
 4 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index fafb8af1c9cb..7ddf6e4b956b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -316,6 +316,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+   if (state->gamma_lut)
+   drm_property_blob_get(state->gamma_lut);
 
state->color_mgmt_changed = false;
 }
@@ -366,6 +368,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+   drm_property_blob_put(state->gamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index b5abf03c5d51..a32557a4e0d3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -615,6 +615,13 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
return ret;
} else if (property == plane->gamma_mode_property) {
state->gamma_mode = val;
+   } else if (property == plane->gamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >gamma_lut,
+   val, -1, sizeof(struct 
drm_color_lut_ext),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>fb_damage_clips,
@@ -690,6 +697,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == plane->gamma_mode_property) {
*val = state->gamma_mode;
+   } else if (property == plane->gamma_lut_property) {
+   *val = (state->gamma_lut) ?
+   state->gamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 02367e691cf3..b5b3ff7f654d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -613,6 +613,11 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
  * to query and get the plane gamma color caps and choose the
  * appropriate gamma mode and create lut values accordingly
  *
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as non-linear.
+ *
  */
 int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
   struct drm_plane *plane,
@@ -648,6 +653,13 @@ int drm_plane_create_color_mgmt_properties(struct 
drm_device *dev,
 
plane->gamma_mode_property = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+  "PLANE_GAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+
+   plane->gamma_lut_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -685,6 +697,12 @@ void drm_plane_attach_gamma_properties(struct drm_plane 
*plane)
 
drm_object_attach_property(>base,
   plane->gamma_mode_property, 0);
+
+   if (!plane->gamma_lut_property)
+   return;
+
+   drm_object_attach_property(>base,
+  plane->gamma_lut_property, 0);
 }
 EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
 
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9081867ecbd1..8b1f506bc5d3 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -270,6 +270,14 @@ struct drm_plane_state {
 */
u32 gamma_mode;
 
+   /* @gamma_lut:
+*
+* Lookup table for converting framebuffer pixel data after applying the
+* color conversion matrix @ctm. See drm_plane_enable_color_mgmt(). The
+* blob (if not NULL) is an array of  

[Intel-gfx] [RFC v2 19/22] drm/i915/xelpd: Define and Initialize Plane Gamma Lut range

2021-09-06 Thread Uma Shankar
Define the structure with XE_LPD gamma lut ranges. HDR and SDR planes
have different capabilities, implemented respective structure for
the HDR planes. Degamma and GAMMA has same Lut caps for SDR planes,
extended the same.

Initialize the mode range caps as well.

Signed-off-by: Uma Shankar 
Signed-off-by: Bhanuprakash Modem 
---
 drivers/gpu/drm/i915/display/intel_color.c | 112 ++---
 1 file changed, 99 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index e9c80ed41466..b4cad5c92c85 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2247,7 +2247,7 @@ static const struct drm_color_lut_range d13_degamma_hdr[] 
= {
 };
 
  /* FIXME input bpc? */
-static const struct drm_color_lut_range d13_degamma_sdr[] = {
+static const struct drm_color_lut_range d13_gamma_degamma_sdr[] = {
/* segment 1 */
{
.flags = (DRM_MODE_LUT_GAMMA |
@@ -2297,6 +2297,63 @@ static const struct drm_color_lut_range 
d13_degamma_sdr[] = {
},
 };
 
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_gamma_hdr[] = {
+   /*
+* ToDo: Add Segment 1
+* There is an optional fine segment added with 9 lut values
+* Will be added later
+*/
+
+   /* segment 2 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 32,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 0, .end = (1 << 24) - 1,
+   .min = 0, .max = (1 << 24) - 1,
+   },
+   /* segment 3 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = (1 << 24) - 1, .end = 1 << 24,
+   .min = 0, .max = 1 << 24,
+   },
+   /* Segment 4 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 1 << 24, .end = 3 << 24,
+   .min = 0, .max = (3 << 24),
+   },
+   /* Segment 5 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 3 << 24, .end = 7 << 24,
+   .min = 0, .max = (7 << 24),
+   },
+};
+
 static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
  struct drm_color_lut_ext *degamma_lut,
  u32 offset)
@@ -2406,26 +2463,55 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no 
degamma",
   NULL, 0,
   
LUT_TYPE_DEGAMMA);
-   if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+   if (ret)
+   return ret;
+
+   ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no 
gamma",
+  NULL, 0,
+  
LUT_TYPE_GAMMA);
+   if (ret)
+   return ret;
+
+   if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id)) {
ret = 
drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
   
d13_degamma_hdr,
   
sizeof(d13_degamma_hdr),
   
LUT_TYPE_DEGAMMA);
-   else
-   ret = 
drm_plane_color_add_gamma_degamma_mode_range(plane,
-  
"plane degamma",
-  

[Intel-gfx] [RFC v2 17/22] drm: Add Plane Gamma Mode property

2021-09-06 Thread Uma Shankar
Add Plane Gamma Mode as a blob property. This is an enum property
with values as blob_id's and exposes the various gamma modes
supported and the lut ranges. Getting the blob id in userspace,
user can get the mode supported and also the range of gamma mode
supported with number of lut coefficients. It can then set one of
the modes using this enum property.

Lut values will be sent through a separate GAMMA_LUT blob property.

Signed-off-by: Uma Shankar 
Signed-off-by: Bhanuprakash Modem 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 
 drivers/gpu/drm/drm_color_mgmt.c  | 26 ++
 include/drm/drm_plane.h   | 14 ++
 3 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index e736fd7c1d5b..b5abf03c5d51 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -613,6 +613,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->gamma_mode_property) {
+   state->gamma_mode = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>fb_damage_clips,
@@ -686,6 +688,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+   } else if (property == plane->gamma_mode_property) {
+   *val = state->gamma_mode;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 5c3138497b9c..02367e691cf3 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -606,6 +606,13 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
  * Blob property which allows a userspace to provide CTM coefficients
  * to do color space conversion or any other enhancement by doing a
  * matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_mode_property:
+ * Blob property which advertizes the possible gamma modes and
+ * lut ranges supported by the platform. This  allows userspace
+ * to query and get the plane gamma color caps and choose the
+ * appropriate gamma mode and create lut values accordingly
+ *
  */
 int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
   struct drm_plane *plane,
@@ -634,6 +641,13 @@ int drm_plane_create_color_mgmt_properties(struct 
drm_device *dev,
 
plane->ctm_property = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+  "PLANE_GAMMA_MODE", num_values);
+   if (!prop)
+   return -ENOMEM;
+
+   plane->gamma_mode_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -664,6 +678,16 @@ void drm_plane_attach_ctm_property(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_attach_ctm_property);
 
+void drm_plane_attach_gamma_properties(struct drm_plane *plane)
+{
+   if (!plane->gamma_mode_property)
+   return;
+
+   drm_object_attach_property(>base,
+  plane->gamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
+
 int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
 const char *name,
 const struct 
drm_color_lut_range *ranges,
@@ -676,6 +700,8 @@ int drm_plane_color_add_gamma_degamma_mode_range(struct 
drm_plane *plane,
 
if (type == LUT_TYPE_DEGAMMA)
prop = plane->degamma_mode_property;
+   else
+   prop = plane->gamma_mode_property;
 
if (!prop)
return -EINVAL;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 3d329f71d287..9081867ecbd1 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -263,6 +263,13 @@ struct drm_plane_state {
 */
struct drm_property_blob *ctm;
 
+   /**
+* @gamma_mode: This is a blob_id and exposes the platform capabilities
+* wrt to various gamma modes and the respective lut ranges. This also
+* helps user select a gamma mode amongst the supported ones.
+*/
+   u32 gamma_mode;
+
u8 color_mgmt_changed : 1;
 };
 
@@ -794,6 +801,12 @@ struct drm_plane {
 * degamma LUT.
 */
struct drm_property *ctm_property;
+
+   /**
+* 

[Intel-gfx] [RFC v2 16/22] drm/i915/xelpd: Enable Plane CSC

2021-09-06 Thread Uma Shankar
Implement plane CSC for ICL+

Signed-off-by: Uma Shankar 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  5 +-
 drivers/gpu/drm/i915/display/intel_color.c| 82 +++
 .../drm/i915/display/skl_universal_plane.c|  4 +
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 4 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 8796fc86b2e5..1637f7890f42 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -499,6 +499,7 @@ void skl_update_planes_on_crtc(struct intel_atomic_state 
*state,
intel_atomic_get_new_crtc_state(state, crtc);
struct skl_ddb_entry entries_y[I915_MAX_PLANES];
struct skl_ddb_entry entries_uv[I915_MAX_PLANES];
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 update_mask = new_crtc_state->update_planes;
struct intel_plane *plane;
 
@@ -513,8 +514,10 @@ void skl_update_planes_on_crtc(struct intel_atomic_state 
*state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
 
-   if (new_plane_state->uapi.color_mgmt_changed)
+   if (new_plane_state->uapi.color_mgmt_changed) {
intel_color_load_plane_luts(_plane_state->uapi);
+   
dev_priv->display.load_plane_csc_matrix(_plane_state->uapi);
+   }
 
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index f5a9af858d1b..e9c80ed41466 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2118,6 +2118,83 @@ static void icl_read_luts(struct intel_crtc_state 
*crtc_state)
}
 }
 
+static void icl_load_plane_csc_matrix(const struct drm_plane_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   struct drm_color_ctm *ctm;
+   const u64 *input;
+   u16 coeffs[9] = {};
+   u16 postoff = 0;
+   int i;
+
+   if (!icl_is_hdr_plane(dev_priv, plane) || !state->ctm)
+   return;
+
+   ctm = state->ctm->data;
+   input = ctm->matrix;
+
+   /*
+* Convert fixed point S31.32 input to format supported by the
+* hardware.
+*/
+   for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+   u64 abs_coeff = ((1ULL << 63) - 1) & input[i];
+
+   /*
+* Clamp input value to min/max supported by
+* hardware.
+*/
+   abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);
+
+   /* sign bit */
+   if (CTM_COEFF_NEGATIVE(input[i]))
+   coeffs[i] |= 1 << 15;
+
+   if (abs_coeff < CTM_COEFF_0_125)
+   coeffs[i] |= (3 << 12) |
+   ILK_CSC_COEFF_FP(abs_coeff, 12);
+   else if (abs_coeff < CTM_COEFF_0_25)
+   coeffs[i] |= (2 << 12) |
+   ILK_CSC_COEFF_FP(abs_coeff, 11);
+   else if (abs_coeff < CTM_COEFF_0_5)
+   coeffs[i] |= (1 << 12) |
+   ILK_CSC_COEFF_FP(abs_coeff, 10);
+   else if (abs_coeff < CTM_COEFF_1_0)
+   coeffs[i] |= ILK_CSC_COEFF_FP(abs_coeff, 9);
+   else if (abs_coeff < CTM_COEFF_2_0)
+   coeffs[i] |= (7 << 12) |
+   ILK_CSC_COEFF_FP(abs_coeff, 8);
+   else
+   coeffs[i] |= (6 << 12) |
+   ILK_CSC_COEFF_FP(abs_coeff, 7);
+   }
+
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0),
+  coeffs[0] << 16 | coeffs[1]);
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1),
+  coeffs[2] << 16);
+
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2),
+  coeffs[3] << 16 | coeffs[4]);
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3),
+  coeffs[5] << 16);
+
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4),
+  coeffs[6] << 16 | coeffs[7]);
+   intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5),
+  coeffs[8] << 16);
+
+   intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+   intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+   intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+   intel_de_write(dev_priv, 

[Intel-gfx] [RFC v2 15/22] drm/i915/xelpd: Define Plane CSC Registers

2021-09-06 Thread Uma Shankar
Define Register macros for plane CSC.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h | 43 +
 1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c36a330734f..20c1b8ddded8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7440,6 +7440,49 @@ enum {
 #define PLANE_COLOR_CTL(pipe, plane)   \
_MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe))
 
+/* Plane CSC Registers */
+#define _PLANE_CSC_RY_GY_1_A   0x70210
+#define _PLANE_CSC_RY_GY_2_A   0x70310
+
+#define _PLANE_CSC_RY_GY_1_B   0x71210
+#define _PLANE_CSC_RY_GY_2_B   0x71310
+
+#define _PLANE_CSC_RY_GY_1(pipe)   _PIPE(pipe, _PLANE_CSC_RY_GY_1_A, \
+ _PLANE_CSC_RY_GY_1_B)
+#define _PLANE_CSC_RY_GY_2(pipe)   _PIPE(pipe, _PLANE_INPUT_CSC_RY_GY_2_A, 
\
+ _PLANE_INPUT_CSC_RY_GY_2_B)
+#define PLANE_CSC_COEFF(pipe, plane, index)_MMIO_PLANE(plane, \
+   
_PLANE_CSC_RY_GY_1(pipe) +  (index) * 4, \
+   
_PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
+
+#define _PLANE_CSC_PREOFF_HI_1_A   0x70228
+#define _PLANE_CSC_PREOFF_HI_2_A   0x70328
+
+#define _PLANE_CSC_PREOFF_HI_1_B   0x71228
+#define _PLANE_CSC_PREOFF_HI_2_B   0x71328
+
+#define _PLANE_CSC_PREOFF_HI_1(pipe)   _PIPE(pipe, _PLANE_CSC_PREOFF_HI_1_A, \
+ _PLANE_CSC_PREOFF_HI_1_B)
+#define _PLANE_CSC_PREOFF_HI_2(pipe)   _PIPE(pipe, _PLANE_CSC_PREOFF_HI_2_A, \
+ _PLANE_CSC_PREOFF_HI_2_B)
+#define PLANE_CSC_PREOFF(pipe, plane, index)   _MMIO_PLANE(plane, 
_PLANE_CSC_PREOFF_HI_1(pipe) + \
+   (index) * 4, 
_PLANE_CSC_PREOFF_HI_2(pipe) + \
+   (index) * 4)
+
+#define _PLANE_CSC_POSTOFF_HI_1_A  0x70234
+#define _PLANE_CSC_POSTOFF_HI_2_A  0x70334
+
+#define _PLANE_CSC_POSTOFF_HI_1_B  0x71234
+#define _PLANE_CSC_POSTOFF_HI_2_B  0x71334
+
+#define _PLANE_CSC_POSTOFF_HI_1(pipe)  _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_1_A, \
+ _PLANE_CSC_POSTOFF_HI_1_B)
+#define _PLANE_CSC_POSTOFF_HI_2(pipe)  _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_2_A, \
+ _PLANE_CSC_POSTOFF_HI_2_B)
+#define PLANE_CSC_POSTOFF(pipe, plane, index)  _MMIO_PLANE(plane, 
_PLANE_CSC_POSTOFF_HI_1(pipe) + \
+   (index) * 4, 
_PLANE_CSC_POSTOFF_HI_2(pipe) + \
+   (index) * 4)
+
 #define _SEL_FETCH_PLANE_BASE_1_A  0x70890
 #define _SEL_FETCH_PLANE_BASE_2_A  0x708B0
 #define _SEL_FETCH_PLANE_BASE_3_A  0x708D0
-- 
2.26.2



[Intel-gfx] [RFC v2 14/22] drm: Add helper to attach Plane ctm property

2021-09-06 Thread Uma Shankar
Add a DRM helper to attach ctm property.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_color_mgmt.c | 10 ++
 include/drm/drm_plane.h  |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 83832adf3adf..5c3138497b9c 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -654,6 +654,16 @@ void drm_plane_attach_degamma_properties(struct drm_plane 
*plane)
 }
 EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
 
+void drm_plane_attach_ctm_property(struct drm_plane *plane)
+{
+   if (!plane->ctm_property)
+   return;
+
+   drm_object_attach_property(>base,
+  plane->ctm_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_ctm_property);
+
 int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
 const char *name,
 const struct 
drm_color_lut_range *ranges,
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index c4ed1799ecaf..3d329f71d287 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -889,6 +889,7 @@ int drm_plane_create_color_mgmt_properties(struct 
drm_device *dev,
   struct drm_plane *plane,
   int num_values);
 void drm_plane_attach_degamma_properties(struct drm_plane *plane);
+void drm_plane_attach_ctm_property(struct drm_plane *plane);
 int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
 const char *name,
 const struct 
drm_color_lut_range *ranges,
-- 
2.26.2



[Intel-gfx] [RFC v2 13/22] drm: Add Plane CTM property

2021-09-06 Thread Uma Shankar
Add a blob property for plane CSC usage.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  3 +++
 drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
 drivers/gpu/drm/drm_color_mgmt.c  | 11 +++
 include/drm/drm_plane.h   | 15 +++
 4 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 6e358067cb7a..fafb8af1c9cb 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -314,6 +314,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+   if (state->ctm)
+   drm_property_blob_get(state->ctm);
 
state->color_mgmt_changed = false;
 }
@@ -363,6 +365,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
+   drm_property_blob_put(state->ctm);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 904291b96ba9..e736fd7c1d5b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -605,6 +605,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == plane->ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm), -1,
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>fb_damage_clips,
@@ -676,6 +684,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+   } else if (property == plane->ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 29d0fc1e52b5..83832adf3adf 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -602,6 +602,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
  * engine, thereby making the content as linear for further color
  * processing.
  *
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
  */
 int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
   struct drm_plane *plane,
@@ -623,6 +627,13 @@ int drm_plane_create_color_mgmt_properties(struct 
drm_device *dev,
 
plane->degamma_lut_property = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+  "PLANE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+
+   plane->ctm_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index fbfada0b990d..c4ed1799ecaf 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -255,6 +255,14 @@ struct drm_plane_state {
 */
struct drm_property_blob *degamma_lut;
 
+   /**
+* @ctm:
+*
+* Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+* blob (if not NULL) is a  drm_color_ctm.
+*/
+   struct drm_property_blob *ctm;
+
u8 color_mgmt_changed : 1;
 };
 
@@ -779,6 +787,13 @@ struct drm_plane {
 * used to convert the framebuffer's colors to linear gamma.
 */
struct drm_property *degamma_lut_property;
+
+   /**
+* @plane_ctm_property: Optional Plane property to set the
+* matrix used to convert colors after the lookup in the
+* degamma LUT.
+*/
+   struct drm_property *ctm_property;
 };
 
 #define obj_to_plane(x) container_of(x, struct drm_plane, base)
-- 
2.26.2



[Intel-gfx] [RFC v2 12/22] drm/i915/xelpd: Load plane color luts from atomic flip

2021-09-06 Thread Uma Shankar
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +++
 drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
 drivers/gpu/drm/i915/display/intel_color.c| 9 +
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 47234d898549..8796fc86b2e5 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -513,6 +513,9 @@ void skl_update_planes_on_crtc(struct intel_atomic_state 
*state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
 
+   if (new_plane_state->uapi.color_mgmt_changed)
+   intel_color_load_plane_luts(_plane_state->uapi);
+
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
intel_update_plane(plane, new_crtc_state, 
new_plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 854f37b49681..3001f4d69b4d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -65,5 +65,6 @@ void intel_plane_set_invisible(struct intel_crtc_state 
*crtc_state,
   struct intel_plane_state *plane_state);
 void intel_plane_helper_add(struct intel_plane *plane);
 int intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
 
 #endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 62df5122309a..f5a9af858d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include "intel_atomic_plane.h"
 #include "intel_color.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
@@ -2310,6 +2311,14 @@ static void d13_plane_load_luts(const struct 
drm_plane_state *plane_state)
}
 }
 
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->display.load_plane_luts(plane_state);
+}
+
 int intel_plane_color_init(struct drm_plane *plane)
 {
struct drm_i915_private *dev_priv = to_i915(plane->dev);
-- 
2.26.2



[Intel-gfx] [RFC v2 11/22] drm/i915/xelpd: Initialize plane color features

2021-09-06 Thread Uma Shankar
Initialize plane color features for XE_LPD.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.h  | 1 +
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 62e5a2a77fd4..854f37b49681 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -64,5 +64,6 @@ int intel_atomic_plane_check_clipping(struct 
intel_plane_state *plane_state,
 void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
   struct intel_plane_state *plane_state);
 void intel_plane_helper_add(struct intel_plane *plane);
+int intel_plane_color_init(struct drm_plane *plane);
 
 #endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 4187a670e840..c4e01ae4343c 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2184,6 +2184,8 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
BIT(DRM_SCALING_FILTER_DEFAULT) 
|

BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
 
+   intel_plane_color_init(>base);
+
intel_plane_helper_add(plane);
 
return plane;
-- 
2.26.2



[Intel-gfx] [RFC v2 10/22] drm/i915/xelpd: Add plane color check to glk_plane_color_ctl

2021-09-06 Thread Uma Shankar
Extended glk_plane_color_ctl to have plane color checks. This helps
enabling the degamma or gamma block based on user inputs.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b6..4187a670e840 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -960,6 +960,11 @@ static u32 glk_plane_color_ctl(const struct 
intel_crtc_state *crtc_state,
u32 plane_color_ctl = 0;
 
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+
+   /* FIXME needs hw.degamma_lut */
+   if (plane_state->uapi.degamma_lut)
+   plane_color_ctl |= PLANE_PRE_CSC_GAMMA_ENABLE;
+
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
 
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
-- 
2.26.2



[Intel-gfx] [RFC v2 09/22] drm/i915/xelpd: Program Plane Degamma Registers

2021-09-06 Thread Uma Shankar
Extract the LUT and program plane degamma registers.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 116 +
 drivers/gpu/drm/i915/i915_reg.h|   2 +
 2 files changed, 118 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index fd0bfdf85703..62df5122309a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -126,6 +126,29 @@ static bool crtc_state_is_legacy_gamma(const struct 
intel_crtc_state *crtc_state
lut_is_legacy(crtc_state->hw.gamma_lut);
 }
 
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+static u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision)
+{
+   u64 val = user_input & 0x;
+   u32 max;
+
+   if (bit_precision > 32)
+   return 0;
+
+   max = 0x >> (32 - bit_precision);
+   /* Round only if we're not using full precision. */
+   if (bit_precision < 32) {
+   val += 1UL << (32 - bit_precision - 1);
+   val >>= 32 - bit_precision;
+   }
+
+   return ((user_input & 0x) |
+   clamp_val(val, 0, max));
+}
+
 /*
  * When using limited range, multiply the matrix given by userspace by
  * the matrix that we would use for the limited range.
@@ -2196,6 +2219,97 @@ static const struct drm_color_lut_range 
d13_degamma_sdr[] = {
},
 };
 
+static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
+ struct drm_color_lut_ext *degamma_lut,
+ u32 offset)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   u32 i, lut_size;
+
+   if (icl_is_hdr_plane(dev_priv, plane)) {
+   lut_size = 128;
+
+   intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, 
plane, 0),
+  PLANE_PAL_PREC_AUTO_INCREMENT);
+
+   if (degamma_lut) {
+   for (i = 0; i < lut_size; i++) {
+   u64 word = 
drm_color_lut_extract_ext(degamma_lut[i].green, 24);
+   u32 lut_val = (word & 0xff);
+
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  lut_val);
+   }
+
+   /* Program the max register to clamp values > 1.0. */
+   while (i < 131)
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  degamma_lut[i++].green);
+   } else {
+   for (i = 0; i < lut_size; i++) {
+   u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+   }
+
+   do {
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+  1 << 24);
+   } while (i++ < 130);
+   }
+
+   intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, 
plane, 0), 0);
+   } else {
+   lut_size = 32;
+
+   /*
+* First 3 planes are HDR, so reduce by 3 to get to the right
+* SDR plane offset
+*/
+   plane = plane - 3;
+
+   intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, 
0),
+  PLANE_PAL_PREC_AUTO_INCREMENT);
+
+   if (degamma_lut) {
+   for (i = 0; i < lut_size; i++)
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+  degamma_lut[i].green);
+   /* Program the max register to clamp values > 1.0. */
+   while (i < 35)
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+  degamma_lut[i++].green);
+   } else {
+   for (i = 0; i < lut_size; i++) {
+   u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0), v);
+   }
+
+   do {
+   intel_de_write(dev_priv, 
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+  1 

[Intel-gfx] [RFC v2 07/22] drm/i915/xelpd: Enable plane color features

2021-09-06 Thread Uma Shankar
Enable and initialize plane color features.
Also initialize the color features of HDR planes.

Signed-off-by: Uma Shankar 
Signed-off-by: Bhanuprakash Modem 
---
 drivers/gpu/drm/i915/display/intel_color.c | 22 +-
 drivers/gpu/drm/i915/display/intel_color.h |  2 ++
 drivers/gpu/drm/i915/i915_drv.h|  3 +++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 6403bd74324b..2307a2e4d73d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
 #include "intel_color.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include 
 
 #define CTM_COEFF_SIGN (1ULL << 63)
 
@@ -2093,7 +2094,6 @@ static void icl_read_luts(struct intel_crtc_state 
*crtc_state)
 }
 
  /* FIXME input bpc? */
-__maybe_unused
 static const struct drm_color_lut_range d13_degamma_hdr[] = {
/* segment 1 */
{
@@ -2144,6 +2144,26 @@ static const struct drm_color_lut_range 
d13_degamma_hdr[] = {
},
 };
 
+int intel_plane_color_init(struct drm_plane *plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+   int ret = 0;
+
+   if (DISPLAY_VER(dev_priv) >= 13) {
+   drm_plane_create_color_mgmt_properties(plane->dev, plane, 2);
+   ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no 
degamma",
+  NULL, 0,
+  
LUT_TYPE_DEGAMMA);
+   ret = drm_plane_color_add_gamma_degamma_mode_range(plane, 
"plane degamma",
+  
d13_degamma_hdr,
+  
sizeof(d13_degamma_hdr),
+  
LUT_TYPE_DEGAMMA);
+   drm_plane_attach_degamma_properties(plane);
+   }
+
+   return ret;
+}
+
 void intel_color_init(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
b/drivers/gpu/drm/i915/display/intel_color.h
index 173727aaa24d..b8850bb1b0c9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -10,6 +10,7 @@
 
 struct intel_crtc_state;
 struct intel_crtc;
+struct drm_plane;
 struct drm_property_blob;
 
 void intel_color_init(struct intel_crtc *crtc);
@@ -21,5 +22,6 @@ int intel_color_get_gamma_bit_precision(const struct 
intel_crtc_state *crtc_stat
 bool intel_color_lut_equal(struct drm_property_blob *blob1,
   struct drm_property_blob *blob2,
   u32 gamma_mode, u32 bit_precision);
+int intel_plane_color_init(struct drm_plane *plane);
 
 #endif /* __INTEL_COLOR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be2392bbcecc..a937a20e4c49 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -391,6 +391,9 @@ struct drm_i915_display_funcs {
 */
void (*load_luts)(const struct intel_crtc_state *crtc_state);
void (*read_luts)(struct intel_crtc_state *crtc_state);
+   /* Add Plane Color callbacks */
+   void (*load_plane_csc_matrix)(const struct drm_plane_state 
*plane_state);
+   void (*load_plane_luts)(const struct drm_plane_state *plane_state);
 };
 
 
-- 
2.26.2



[Intel-gfx] [RFC v2 08/22] drm/i915/xelpd: Add color capabilities of SDR planes

2021-09-06 Thread Uma Shankar
Add the Color capabilities of SDR planes.

Signed-off-by: Uma Shankar 
Signed-off-by: Bhanuprakash Modem 
---
 drivers/gpu/drm/i915/display/intel_color.c | 67 --
 1 file changed, 63 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 2307a2e4d73d..fd0bfdf85703 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
 #include "intel_color.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_sprite.h"
 #include 
 
 #define CTM_COEFF_SIGN (1ULL << 63)
@@ -2144,6 +2145,57 @@ static const struct drm_color_lut_range 
d13_degamma_hdr[] = {
},
 };
 
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_degamma_sdr[] = {
+   /* segment 1 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 32,
+   .input_bpc = 16, .output_bpc = 16,
+   .start = 0, .end = (1 << 16) - (1 << 16) / 33,
+   .min = 0, .max = (1 << 16) - 1,
+   },
+   /* segment 2 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 16, .output_bpc = 16,
+   .start = (1 << 16) - (1 << 16) / 33, .end = 1 << 16,
+   .min = 0, .max = 1 << 16,
+   },
+   /* Segment 3 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 16, .output_bpc = 16,
+   .start = 1 << 16, .end = 3 << 16,
+   .min = 0, .max = (8 << 16) - 1,
+   },
+   /* Segment 4 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 16, .output_bpc = 16,
+   .start = 3 << 16, .end = 7 << 16,
+   .min = 0, .max = (8 << 16) - 1,
+   },
+};
+
 int intel_plane_color_init(struct drm_plane *plane)
 {
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -2154,10 +2206,17 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no 
degamma",
   NULL, 0,
   
LUT_TYPE_DEGAMMA);
-   ret = drm_plane_color_add_gamma_degamma_mode_range(plane, 
"plane degamma",
-  
d13_degamma_hdr,
-  
sizeof(d13_degamma_hdr),
-  
LUT_TYPE_DEGAMMA);
+   if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+   ret = 
drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+  
d13_degamma_hdr,
+  
sizeof(d13_degamma_hdr),
+  
LUT_TYPE_DEGAMMA);
+   else
+   ret = 
drm_plane_color_add_gamma_degamma_mode_range(plane,
+  
"plane degamma",
+  
d13_degamma_sdr,
+  
sizeof(d13_degamma_sdr),
+  
LUT_TYPE_DEGAMMA);
drm_plane_attach_degamma_properties(plane);
}
 
-- 
2.26.2



[Intel-gfx] [RFC v2 06/22] drm/i915/xelpd: Add register definitions for Plane Degamma

2021-09-06 Thread Uma Shankar
Add macros to define Plane Degamma registers

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h | 52 +
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 313432ed6196..919982c878ac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -262,6 +262,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
  
INTEL_INFO(dev_priv)->cursor_offsets[PIPE_A] + (reg) + \
  DISPLAY_MMIO_BASE(dev_priv))
 
+/* Plane Gamma Registers */
+#define _MMIO_PLANE_GAMC(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
 #define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
 #define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
@@ -11366,6 +11369,55 @@ enum skl_power_gate {
_PAL_PREC_MULTI_SEG_DATA_A, \
_PAL_PREC_MULTI_SEG_DATA_B)
 
+/* Display13 Plane Degmma Reg */
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A  0x701d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B  0x711d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A  0x702d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B  0x712d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe)  _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A, \
+   
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe)  _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A, \
+   
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i)   \
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A   0x701d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B   0x711d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A   0x702d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B   0x712d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe)   _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_DATA_ENH_1_A, \
+   
_PLANE_PRE_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe)   _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_DATA_ENH_2_A, \
+   
_PLANE_PRE_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i)\
+   _MMIO_PLANE_GAMC(plane, i, 
_PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_A  0x704d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_B  0x714d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_A  0x705d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_B  0x715d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1(pipe)  _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_INDEX_1_A, \
+   _PLANE_PRE_CSC_GAMC_INDEX_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_2(pipe)  _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_INDEX_2_A, \
+   _PLANE_PRE_CSC_GAMC_INDEX_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i)   \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_1_A   0x704d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1_B   0x714d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_A   0x705d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_B   0x715d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1(pipe)   _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_DATA_1_A, \
+   _PLANE_PRE_CSC_GAMC_DATA_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_2(pipe)   _PIPE(pipe, 
_PLANE_PRE_CSC_GAMC_DATA_2_A, \
+   _PLANE_PRE_CSC_GAMC_DATA_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i)\
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+   _PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+
 /* pipe CSC & degamma/gamma LUTs on CHV */
 #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
 #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
-- 
2.26.2



[Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

2021-09-06 Thread Uma Shankar
This is a RFC proposal for plane color hardware blocks.
It exposes the property interface to userspace and calls
out the details or interfaces created and the intended
purpose.

Credits: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
 Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++
 1 file changed, 167 insertions(+)
 create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst

diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst 
b/Documentation/gpu/rfc/drm_color_pipeline.rst
new file mode 100644
index ..0d1ca858783b
--- /dev/null
+++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
@@ -0,0 +1,167 @@
+==
+Display Color Pipeline: Proposed DRM Properties
+==
+
+This is how a typical display color hardware pipeline looks like:
+ +---+
+ |RAM|
+ |  +--++-++-+   |
+ |  | FB 1 ||  FB 2   || FB N|   |
+ |  +--++-++-+   |
+ +---+
+   |  Plane Color Hardware Block |
+ ++
+ | +---v-+   +---v---+   +---v--+ |
+ | | Plane A |   | Plane B   |   | Plane N  | |
+ | | DeGamma |   | Degamma   |   | Degamma  | |
+ | +---+-+   +---+---+   +---+--+ |
+ | | |   ||
+ | +---v-+   +---v---+   +---v--+ |
+ | |Plane A  |   | Plane B   |   | Plane N  | |
+ | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
+ | +---+-+   ++--+   ++-+ |
+ | |  |   |   |
+ | +---v-+   +v--+   +v-+ |
+ | | Plane A |   | Plane B   |   | Plane N  | |
+ | | Gamma   |   | Gamma |   | Gamma| |
+ | +---+-+   ++--+   ++-+ |
+ | |  |   |   |
+ ++
++--v--v---v---|
+||   ||
+||   Pipe Blender||
++++
+|||
+|+---v--+ |
+||  Pipe DeGamma| |
+||  | |
+|+---+--+ |
+||Pipe Color  |
+|+---v--+ Hardware|
+||  Pipe CSC/CTM| |
+||  | |
+|+---+--+ |
+|||
+|+---v--+ |
+||  Pipe Gamma  | |
+||  | |
+|+---+--+ |
+|||
++-+
+ |
+ v
+   Pipe Output
+
+Proposal is to have below properties for a plane:
+
+* Plane Degamma or Pre-Curve:
+   * This will be used to linearize the input framebuffer data.
+   * It will apply the reverse of the color transfer function.
+   * It can be a degamma curve or OETF for HDR.
+   * This linear data can be further acted on by the following
+   * color hardware blocks in the display hardware pipeline
+
+UAPI Name: PLANE_DEGAMMA_MODE
+Description: Enum property with values as blob_id's which advertizes the
+   possible degamma modes and lut ranges supported by the platform.
+   This  allows userspace to query and get the plane degamma color
+   caps and choose the appropriate degamma mode and create lut values
+   accordingly.
+
+UAPI Name: PLANE_DEGAMMA_LUT
+Description: Blob property which allows a userspace to provide LUT values
+to apply degamma curve using the h/w plane degamma processing
+engine, thereby making the content as linear for further color
+processing. Userspace gets the size of LUT and precision etc
+from PLANE_DEGAMA_MODE_PROPERTY
+   
+* Plane CTM
+   * This is a Property to program the color transformation matrix.
+   * This can be used to perform a color space conversion like
+   * BT2020 to BT709 or BT601 etc.
+   * This block is generally kept after the degamma unit so that
+   * linear data can be fed to it for conversion.
+
+UAPI Name: PLANE_CTM
+Description: Blob property which allows a userspace to provide CTM coefficients
+to do color space conversion or any other enhancement by doing a
+matrix multiplication using the h/w CTM processing engine
+
+* Plane Gamma or Post-Curve
+   * This can be used to perform 2 operations:
+   * non-lineralize the 

[Intel-gfx] [RFC v2 03/22] drm: Add Plane Degamma Mode property

2021-09-06 Thread Uma Shankar
Add Plane Degamma Mode as an enum property. Create a helper
function for all plane color management features.

This is an enum property with values as blob_id's and exposes
the various gamma modes supported and the lut ranges. Getting
the blob id in userspace, user can get the mode supported and
also the range of gamma mode supported with number of lut
coefficients. It can then set one of the modes using this
enum property.

Lut values will be sent through separate GAMMA_LUT blob property.

Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-kms.rst | 90 ++
 drivers/gpu/drm/drm_atomic.c  |  1 +
 drivers/gpu/drm/drm_atomic_state_helper.c |  2 +
 drivers/gpu/drm/drm_atomic_uapi.c |  4 +
 drivers/gpu/drm/drm_color_mgmt.c  | 93 ++-
 include/drm/drm_mode_object.h |  2 +-
 include/drm/drm_plane.h   | 23 ++
 7 files changed, 212 insertions(+), 3 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1ef7951ded5e..f4658417bf20 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -545,9 +545,99 @@ Damage Tracking Properties
 Color Management Properties
 ---
 
+Below is how a typical hardware pipeline for color
+will look like:
+
+.. kernel-render:: DOT
+   :alt: Display Color Pipeline
+   :caption: Display Color Pipeline Overview
+
+   digraph "KMS" {
+  node [shape=box]
+
+  subgraph cluster_static {
+  style=dashed
+  label="Display Color Hardware Blocks"
+
+  node [bgcolor=grey style=filled]
+  "Plane Degamma A" -> "Plane CSC/CTM A"
+  "Plane CSC/CTM A" -> "Plane Gamma A"
+  "Pipe Blender" [color=lightblue,style=filled, width=5.25, 
height=0.75];
+  "Plane Gamma A" -> "Pipe Blender"
+ "Pipe Blender" -> "Pipe DeGamma"
+  "Pipe DeGamma" -> "Pipe CSC/CTM"
+  "Pipe CSC/CTM" -> "Pipe Gamma"
+  "Pipe Gamma" -> "Pipe Output"
+  }
+
+  subgraph cluster_static {
+  style=dashed
+
+  node [shape=box]
+  "Plane Degamma B" -> "Plane CSC/CTM B"
+  "Plane CSC/CTM B" -> "Plane Gamma B"
+  "Plane Gamma B" -> "Pipe Blender"
+  }
+
+  subgraph cluster_static {
+  style=dashed
+
+  node [shape=box]
+  "Plane Degamma C" -> "Plane CSC/CTM C"
+  "Plane CSC/CTM C" -> "Plane Gamma C"
+  "Plane Gamma C" -> "Pipe Blender"
+  }
+
+  subgraph cluster_fb {
+  style=dashed
+  label="RAM"
+
+  node [shape=box width=1.7 height=0.2]
+
+  "FB 1" -> "Plane Degamma A"
+  "FB 2" -> "Plane Degamma B"
+  "FB 3" -> "Plane Degamma C"
+  }
+   }
+
+In real world usecases,
+
+1. Plane Degamma can be used to linearize a non linear gamma
+encoded framebuffer. This is needed to do any linear math like
+color space conversion. For ex, linearize frames encoded in SRGB
+or by HDR curve.
+
+2. Later Plane CTM block can convert the content to some different
+colorspace. For ex, SRGB to BT2020 etc.
+
+3. Plane Gamma block can be used later to re-apply the non-linear
+curve. This can also be used to apply Tone Mapping for HDR usecases.
+
+All the layers or framebuffers need to be converted to same color
+space and format before blending. The plane color hardware blocks
+can help with this. Once the Data is blended, similar color processing
+can be done on blended output using pipe color hardware blocks.
+
+DRM Properties have been created to define and expose all these
+hardware blocks to userspace. A userspace application (compositor
+or any color app) can use these interfaces and define policies to
+efficiently use the display hardware for such color operations.
+
+Pipe Color Management Properties
+-
+
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
 
+Plane Color Management Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+   :doc: Plane Color Properties
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+   :doc: export
+
 Tile Group Property
 ---
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..fddf9df15cd5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -709,6 +709,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
   drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
   drm_get_color_range_name(state->color_range));
+   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
 
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 

[Intel-gfx] [RFC v2 04/22] drm: Add Plane Degamma Lut property

2021-09-06 Thread Uma Shankar
Add Plane Degamma Lut as a blob property. User will calculate
the lut values, create the blob and send it to driver using
this property. Lut calculation will be based on the gamma mode
chosen out of the gamma mode exposed.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  4 
 drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
 drivers/gpu/drm/drm_color_mgmt.c  | 19 +++
 include/drm/drm_plane.h   | 14 ++
 4 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index f26b03853711..6e358067cb7a 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -312,6 +312,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
state->commit = NULL;
state->fb_damage_clips = NULL;
 
+   if (state->degamma_lut)
+   drm_property_blob_get(state->degamma_lut);
+
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -359,6 +362,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
 
drm_property_blob_put(state->fb_damage_clips);
+   drm_property_blob_put(state->degamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 3c952123f747..904291b96ba9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -598,6 +598,13 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->color_range = val;
} else if (property == plane->degamma_mode_property) {
state->degamma_mode = val;
+   } else if (property == plane->degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val, -1, sizeof(struct 
drm_color_lut_ext),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>fb_damage_clips,
@@ -666,6 +673,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_range;
} else if (property == plane->degamma_mode_property) {
*val = state->degamma_mode;
+   } else if (property == plane->degamma_lut_property) {
+   *val = (state->degamma_lut) ?
+   state->degamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 085ed0d0db00..29d0fc1e52b5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -596,6 +596,12 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
  * to query and get the plane degamma color caps and choose the
  * appropriate degamma mode and create lut values accordingly
  *
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as linear for further color
+ * processing.
+ *
  */
 int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
   struct drm_plane *plane,
@@ -610,6 +616,13 @@ int drm_plane_create_color_mgmt_properties(struct 
drm_device *dev,
 
plane->degamma_mode_property = prop;
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+  "PLANE_DEGAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+
+   plane->degamma_lut_property = prop;
+
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -621,6 +634,12 @@ void drm_plane_attach_degamma_properties(struct drm_plane 
*plane)
 
drm_object_attach_property(>base,
   plane->degamma_mode_property, 0);
+
+   if (!plane->degamma_lut_property)
+   return;
+
+   drm_object_attach_property(>base,
+  plane->degamma_lut_property, 0);
 }
 EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
 
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index b9064101db2b..fbfada0b990d 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -247,6 +247,14 @@ struct drm_plane_state {
 */
u32 degamma_mode;
 
+   /* @degamma_lut:
+ 

[Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

2021-09-06 Thread Uma Shankar
Define the structure with XE_LPD degamma lut ranges. HDR and SDR
planes have different capabilities, implemented respective
structure for the HDR planes.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index afcb4bf3826c..6403bd74324b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state 
*crtc_state)
}
 }
 
+ /* FIXME input bpc? */
+__maybe_unused
+static const struct drm_color_lut_range d13_degamma_hdr[] = {
+   /* segment 1 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 128,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 0, .end = (1 << 24) - 1,
+   .min = 0, .max = (1 << 24) - 1,
+   },
+   /* segment 2 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = (1 << 24) - 1, .end = 1 << 24,
+   .min = 0, .max = (1 << 27) - 1,
+   },
+   /* Segment 3 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 1 << 24, .end = 3 << 24,
+   .min = 0, .max = (1 << 27) - 1,
+   },
+   /* Segment 4 */
+   {
+   .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+   .count = 1,
+   .input_bpc = 24, .output_bpc = 16,
+   .start = 3 << 24, .end = 7 << 24,
+   .min = 0, .max = (1 << 27) - 1,
+   },
+};
+
 void intel_color_init(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-- 
2.26.2



[Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes

2021-09-06 Thread Uma Shankar
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.

This also defines a new structure to define color lut ranges,
along with related macro definitions and enums. This will help
describe multi segmented lut ranges in the hardware.

Signed-off-by: Uma Shankar 
---
 include/uapi/drm/drm_mode.h | 58 +
 1 file changed, 58 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 90c55383f1ee..1079794c86c3 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -903,6 +903,64 @@ struct hdr_output_metadata {
};
 };
 
+/*
+ * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
+ * can be used for either purpose, but not simultaneously. To expose
+ * modes that support gamma and degamma simultaneously the gamma mode
+ * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
+ * ranges.
+ */
+/* LUT is for gamma (after CTM) */
+#define DRM_MODE_LUT_GAMMA BIT(0)
+/* LUT is for degamma (before CTM) */
+#define DRM_MODE_LUT_DEGAMMA BIT(1)
+/* linearly interpolate between the points */
+#define DRM_MODE_LUT_INTERPOLATE BIT(2)
+/*
+ * the last value of the previous range is the
+ * first value of the current range.
+ */
+#define DRM_MODE_LUT_REUSE_LAST BIT(3)
+/* the curve must be non-decreasing */
+#define DRM_MODE_LUT_NON_DECREASING BIT(4)
+/* the curve is reflected across origin for negative inputs */
+#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
+/* the same curve (red) is used for blue and green channels as well */
+#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
+
+struct drm_color_lut_range {
+   /* DRM_MODE_LUT_* */
+   __u32 flags;
+   /* number of points on the curve */
+   __u16 count;
+   /* input/output bits per component */
+   __u8 input_bpc, output_bpc;
+   /* input start/end values */
+   __s32 start, end;
+   /* output min/max values */
+   __s32 min, max;
+};
+
+enum lut_type {
+   LUT_TYPE_DEGAMMA = 0,
+   LUT_TYPE_GAMMA = 1,
+};
+
+/*
+ * Creating 64 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+   /*
+* Data is U32.32 fixed point format.
+*/
+   __u64 red;
+   __u64 green;
+   __u64 blue;
+   __u64 reserved;
+};
+
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
-- 
2.26.2



[Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features

2021-09-06 Thread Uma Shankar
This is how a typical display color hardware pipeline looks like:
 +---+
 |RAM|
 |  +--++-++-+   |
 |  | FB 1 ||  FB 2   || FB N|   |
 |  +--++-++-+   |
 +---+
   |  Plane Color Hardware Block |
 ++
 | +---v-+   +---v---+   +---v--+ |
 | | Plane A |   | Plane B   |   | Plane N  | |
 | | DeGamma |   | Degamma   |   | Degamma  | |
 | +---+-+   +---+---+   +---+--+ |
 | | |   ||
 | +---v-+   +---v---+   +---v--+ |
 | |Plane A  |   | Plane B   |   | Plane N  | |
 | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
 | +---+-+   ++--+   ++-+ |
 | |  |   |   |
 | +---v-+   +v--+   +v-+ |
 | | Plane A |   | Plane B   |   | Plane N  | |
 | | Gamma   |   | Gamma |   | Gamma| |
 | +---+-+   ++--+   ++-+ |
 | |  |   |   |
 ++
+--v--v---v---|
||   ||
||   Pipe Blender||
+++
|||
|+---v--+ |
||  Pipe DeGamma| |
||  | |
|+---+--+ |
||Pipe Color  |
|+---v--+ Hardware|
||  Pipe CSC/CTM| |
||  | |
|+---+--+ |
|||
|+---v--+ |
||  Pipe Gamma  | |
||  | |
|+---+--+ |
|||
+-+
 |
 v
   Pipe Output

This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data and CSC used for gamut
conversion. It also includes Gamma support used to again non-linearize
data as per panel supported color space. These can be utilize by user
space to convert planes from one format to another, one color space to
another etc.

Userspace can take smart blending decisions and utilize these hardware
supported plane color features to get accurate color profile. The same
can help in consistent color quality from source to panel taking
advantage of advanced color features in hardware.

These patches add the property interfaces and enable helper functions.
This series adds Intel's XE_LPD hw specific plane gamma feature. We
can build up and add other platform/hardware specific implementation
on top of this series.

Credits: Special mention and credits to Ville Syrjala for coming up
with a design for this feature and inputs. This series is based on
his original design and idea.

Note: Userspace support for this new UAPI will be done on Chrome in
alignment with weston and general opensource community.
Discussion ongoing with Harry Wentland, Pekka and community on color
pipeline and UAPI design. Harry's RFC below:
https://patchwork.freedesktop.org/series/89506/
We need to converge on a common UAPI interface which caters to
all the modern color hardware pipelines. 

ToDo: State readout for this feature will be added next.

v2: Added UAPI description and added change in the rfc section of
kernel Documentation folder

Uma Shankar (22):
  drm: RFC for Plane Color Hardware Pipeline
  drm: Add Enhanced Gamma and color lut range attributes
  drm: Add Plane Degamma Mode property
  drm: Add Plane Degamma Lut property
  drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
  drm/i915/xelpd: Add register definitions for Plane Degamma
  drm/i915/xelpd: Enable plane color features
  drm/i915/xelpd: Add color capabilities of SDR planes
  drm/i915/xelpd: Program Plane Degamma Registers
  drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
  drm/i915/xelpd: Initialize plane color features
  drm/i915/xelpd: Load plane color luts from atomic flip
  drm: Add Plane CTM property
  drm: Add helper to attach Plane ctm property
  drm/i915/xelpd: Define Plane CSC Registers
  drm/i915/xelpd: Enable Plane CSC
  drm: Add Plane Gamma Mode property
  drm: Add Plane Gamma Lut property
  drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
  drm/i915/xelpd: Add register definitions for Plane Gamma
  drm/i915/xelpd: Program Plane Gamma Registers
  drm/i915/xelpd: Enable plane gamma

 Documentation/gpu/drm-kms.rst |  90 +++
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp: Add support for remapping CCS FBs (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adlp: Add support for remapping CCS FBs (rev2)
URL   : https://patchwork.freedesktop.org/series/94108/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20968


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

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

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u:   [INCOMPLETE][3] ([i915#198]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20968/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

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

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


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
bat-jsl-1 


Build changes
-

  * IGT: IGT_6197 -> IGTPW_6201
  * Linux: CI_DRM_10553 -> Patchwork_20968

  CI-20190529: 20190529
  CI_DRM_10553: 47b2bd2caa7b29b5741ff2521206657853b85165 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_6201: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6201/index.html
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20968: d59a5a203c014fdbd06b4b01215c5f0c1c433fac @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d59a5a203c01 drm/fourcc: Add the ADL-P specific pitch requirements of CCS 
modifiers
6de7a755ff6b drm/i915/adlp: Add support for remapping CCS FBs
db26d072b678 drm/i915: Follow a new->old platform check order in 
intel_fb_stride_alignment
69f8d6cd402f drm/i915/adlp: Assert that VMAs in DPT start at 0
f008405ab6cc drm/i915/adlp: Require always a power-of-two sized CCS surface 
stride
5ea74ea48d04 drm/i915: Use tile block based dimensions for CCS origin x, y check

== Logs ==

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


Re: [Intel-gfx] [PATCH 01/10] drm/i915: move display funcs into a display struct.

2021-09-06 Thread Dave Airlie
On Mon, 6 Sept 2021 at 18:18, Jani Nikula  wrote:
>
> On Mon, 06 Sep 2021, Dave Airlie  wrote:
> > From: Dave Airlie 
> >
> > This is the first step in an idea to refactor the display code
> > into a bit more of a corner.
>
> So, do we want to make i915->display a pointer?
>
> If we do, and we're about to touch every place accessing the display
> struct, we might just as well have:
>
> struct drm_i915_private {
> struct drm_i915_display _display;
> struct drm_i915_display *display;
> };
>
> and initialize i915->display = >_display, and make all access
> happen via the pointer. If we want to allocate it dynamically at some
> point, it'll be a *much* easier task.
>
> But the first question to figure out is whether we want to do that or
> not.

I think the advantage is that we can hide a lot more structs from the
main struct,
the disadvantage is additional pointer chasing, esp for the drm_device and other
i915_priv members.

Has anyone any non-anecdotal knowledge of how bad the latter problem
actually is?
Other drivers seem to do a lot of it and nobody has complained about it.

I'm happy to move to a pointer for it all to be honest,
Dave.


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)
URL   : https://patchwork.freedesktop.org/series/94278/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10553_full -> Patchwork_20967_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@feature_discov...@display-2x.html

  * igt@gem_ctx_persistence@engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2846])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk5/igt@gem_exec_f...@basic-deadline.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-glk6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-glk3/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_20967/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][10] ([fdo#112283])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#307])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb5/igt@gem_mmap_...@cpuset-medium-copy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@gem_soft...@evict-snoop.html

  * igt@gem_userptr_blits@input-checking:
- shard-apl:  NOTRUN -> [DMESG-WARN][14] ([i915#3002])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-apl7/igt@gem_userptr_bl...@input-checking.html

  * igt@gen7_exec_parse@basic-allowed:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@gen7_exec_pa...@basic-allowed.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][16] -> [DMESG-WARN][17] ([i915#1436] / 
[i915#716])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-skl8/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: NOTRUN -> [WARN][18] ([i915#2684])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@i915_pm_rpm@system-suspend:
- shard-kbl:  [PASS][19] -> [INCOMPLETE][20] ([i915#151] / 
[i915#155])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl2/igt@i915_pm_...@system-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-kbl6/igt@i915_pm_...@system-suspend.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111614])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@kms_big...@x-tiled-64bpp-rotate-270.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111615]) +1 similar issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/shard-tglb6/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- shard-snb:  NOTRUN -> [SKIP][23] ([fdo#109271]) +380 

[Intel-gfx] [PATCH v2 6/6] drm/fourcc: Add the ADL-P specific pitch requirements of CCS modifiers

2021-09-06 Thread Imre Deak
On Alderlake-P for all CCS modifiers the main surface pitch must be
either 8 Y-tile width or the multiple of 16 Y-tile widths. The CCS
surface pitch must be rounded up to power-of-two.

Adjust the modifier descriptions accordingly.

Cc: Nanley G Chery 
Cc: Juha-Pekka Heikkila 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 include/uapi/drm/drm_fourcc.h | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 45a914850be0d..b63b7fa8bbac6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -522,8 +522,16 @@ extern "C" {
  * The main surface is Y-tiled and at plane index 0, the CCS is linear and
  * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
  * main surface. In other words, 4 bits in CCS map to a main surface cache
- * line pair. The main surface pitch is required to be a multiple of four
- * Y-tile widths.
+ * line pair.
+ *
+ * The pitch of the main surface is required to be either 8 or a multiple of
+ * 16 Y-tile widths on Alderlake-P and a multiple of 4 Y-tile widths on other
+ * platforms.
+ *
+ * The pitch of the CCS surface must be calculated using the
+ *ccs_surface_pitch=main_surface_pitch_in_bytes / 512 * 64.
+ * formula. On Alderlake-P this pitch must be rounded up to be power-of-two
+ * sized.
  */
 #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
 
@@ -533,10 +541,12 @@ extern "C" {
  * The main surface is Y-tiled and at plane index 0, the CCS is linear and
  * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
  * main surface. In other words, 4 bits in CCS map to a main surface cache
- * line pair. The main surface pitch is required to be a multiple of four
- * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
+ * line pair.  For semi-planar formats like NV12, CCS planes follow the
  * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
  * planes 2 and 3 for the respective CCS.
+ *
+ * About the requirement on the main and CCS surface pitches see the
+ * description for I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS.
  */
 #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
 
@@ -554,8 +564,10 @@ extern "C" {
  * Clear Color value when applicable. The Converted Clear Color values are
  * consumed by the DE. The last 64 bits are used to store Color Discard Enable
  * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
- * corresponds to an area of 4x1 tiles in the main surface. The main surface
- * pitch is required to be a multiple of 4 tile widths.
+ * corresponds to an area of 4x1 tiles in the main surface.
+ *
+ * About the requirement on the main and CCS surface pitches see the
+ * description for I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS.
  */
 #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
 
-- 
2.27.0



[Intel-gfx] [PATCH v2 5/6] drm/i915/adlp: Add support for remapping CCS FBs

2021-09-06 Thread Imre Deak
Add support for remapping CCS FBs on ADL-P to remove the restriction
of the power-of-two sized stride and the 2MB surface offset alignment
for these FBs.

We can only remap the tiles on the main surface, not the tiles on the
CCS surface, so userspace has to generate the CCS surface aligning to
the POT size padded main surface stride (by programming the AUX
pagetable accordingly). For the required AUX pagetable setup, this
requires that either the main surface stride is 8 tiles or that the
stride is 16 tiles aligned (= 64 kbytes, the area mapped by one AUX
PTE).

v2:
- Init intel_remapped_info::plane_alignment only for remapped views and
  do this from intel_fb_view_init().

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila  (v1)
---
 drivers/gpu/drm/i915/display/intel_display.c  |  5 +-
 .../drm/i915/display/intel_display_types.h|  2 -
 drivers/gpu/drm/i915/display/intel_fb.c   | 93 +++
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 29 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  7 +-
 5 files changed, 89 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 1f447ba776c79..ac68749d0f2aa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -892,8 +892,11 @@ unsigned int intel_remapped_info_size(const struct 
intel_remapped_info *rem_info
unsigned int size = 0;
int i;
 
-   for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++)
+   for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
+   if (rem_info->plane_alignment)
+   size = ALIGN(size, rem_info->plane_alignment);
size += rem_info->plane[i].dst_stride * 
rem_info->plane[i].height;
+   }
 
return size;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c7bcf9183447b..e97741c2f4e32 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -103,8 +103,6 @@ struct intel_fb_view {
 * in the rotated and remapped GTT view all no-CCS formats (up to 2
 * color planes) are supported.
 *
-* TODO: add support for CCS formats in the remapped GTT view.
-*
 * The view information shared by all FB color planes in the FB,
 * like dst x/y and src/dst width, is stored separately in
 * intel_plane_state.
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 479c76c7958ce..fa1f375e696bf 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -357,15 +357,29 @@ void intel_fb_plane_get_subsampling(int *hsub, int *vsub,
 
 static void intel_fb_plane_dims(const struct intel_framebuffer *fb, int 
color_plane, int *w, int *h)
 {
+   struct drm_i915_private *i915 = to_i915(fb->base.dev);
int main_plane = is_ccs_plane(>base, color_plane) ?
 skl_ccs_to_main_plane(>base, color_plane) : 0;
+   unsigned int main_width = fb->base.width;
+   unsigned int main_height = fb->base.height;
int main_hsub, main_vsub;
int hsub, vsub;
 
+   /*
+* On ADL-P the CCS AUX surface layout always aligns with the
+* power-of-two aligned main surface stride. The main surface
+* stride in the allocated FB object may not be power-of-two
+* sized, in which case it is auto-padded to the POT size.
+*/
+   if (IS_ALDERLAKE_P(i915) && is_ccs_plane(>base, color_plane))
+   main_width = gen12_aligned_scanout_stride(fb, 0) /
+fb->base.format->cpp[0];
+
intel_fb_plane_get_subsampling(_hsub, _vsub, >base, 
main_plane);
intel_fb_plane_get_subsampling(, , >base, color_plane);
-   *w = fb->base.width / main_hsub / hsub;
-   *h = fb->base.height / main_vsub / vsub;
+
+   *w = main_width / main_hsub / hsub;
+   *h = main_height / main_vsub / vsub;
 }
 
 static u32 intel_adjust_tile_offset(int *x, int *y,
@@ -547,17 +561,8 @@ static int intel_fb_offset_to_xy(int *x, int *y,
unsigned int height;
u32 alignment;
 
-   /*
-* All DPT color planes must be 512*4k aligned (the amount mapped by a
-* single DPT page). For ADL_P CCS FBs this only works by requiring
-* the allocated offsets to be 2MB aligned.  Once supoort to remap
-* such FBs is added we can remove this requirement, as then all the
-* planes can be remapped to an aligned offset.
-*/
-   if (IS_ALDERLAKE_P(i915) && is_ccs_modifier(fb->modifier))
-   alignment = 512 * 4096;
-   else if (DISPLAY_VER(i915) >= 12 &&
-is_semiplanar_uv_plane(fb, color_plane))
+   if (DISPLAY_VER(i915) >= 12 &&
+ 

[Intel-gfx] [PATCH v2 3/6] drm/i915/adlp: Assert that VMAs in DPT start at 0

2021-09-06 Thread Imre Deak
Atm the DPT object can accommodate only one VMA, so the VMA offset will
be always 0. Add an assert for this.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b63..f50282b60de44 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -993,6 +993,11 @@ static u32 skl_surf_address(const struct intel_plane_state 
*plane_state,
u32 offset = plane_state->view.color_plane[color_plane].offset;
 
if (intel_fb_uses_dpt(fb)) {
+   /*
+* The DPT object contains only one vma, so the VMA's offset
+* within the DPT is always 0.
+*/
+   WARN_ON(plane_state->dpt_vma->node.start);
WARN_ON(offset & 0x1f);
return offset >> 9;
} else {
-- 
2.27.0



[Intel-gfx] [PATCH v2 4/6] drm/i915: Follow a new->old platform check order in intel_fb_stride_alignment

2021-09-06 Thread Imre Deak
Follow the usual new->old order in intel_fb_stride_alignment() platform
check ladder.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index a0db67e85c717..479c76c7958ce 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1158,6 +1158,12 @@ intel_fb_stride_alignment(const struct drm_framebuffer 
*fb, int color_plane)
 
tile_width = intel_tile_width_bytes(fb, color_plane);
if (is_ccs_modifier(fb->modifier)) {
+   /*
+* On TGL the surface stride must be 4 tile aligned, mapped by
+* one 64 byte cacheline on the CCS AUX surface.
+*/
+   if (DISPLAY_VER(dev_priv) >= 12)
+   tile_width *= 4;
/*
 * Display WA #0531: skl,bxt,kbl,glk
 *
@@ -1167,14 +1173,8 @@ intel_fb_stride_alignment(const struct drm_framebuffer 
*fb, int color_plane)
 * require the entire fb to accommodate that to avoid
 * potential runtime errors at plane configuration time.
 */
-   if ((DISPLAY_VER(dev_priv) == 9 || IS_GEMINILAKE(dev_priv)) &&
-   color_plane == 0 && fb->width > 3840)
-   tile_width *= 4;
-   /*
-* The main surface pitch must be padded to a multiple of four
-* tile widths.
-*/
-   else if (DISPLAY_VER(dev_priv) >= 12)
+   else if ((DISPLAY_VER(dev_priv) == 9 || 
IS_GEMINILAKE(dev_priv)) &&
+color_plane == 0 && fb->width > 3840)
tile_width *= 4;
}
return tile_width;
-- 
2.27.0



[Intel-gfx] [PATCH v2 2/6] drm/i915/adlp: Require always a power-of-two sized CCS surface stride

2021-09-06 Thread Imre Deak
At the moment CCS FB strides must be power-of-two sized, but a follow-up
change will add support remapping these FBs, allowing the FB passed in
by userspace to have a non-POT sized stride. For these remapped FBs we
can only remap the main surface, not the CCS surface. This means that
userspace has to always generate the CCS surface aligning to the POT
stride padded main surface (by setting up the CCS AUX pagetables
accordingly). Adjust the CCS surface stride check to enforce this.

No functional change.

v2:
- Fix the gen12_ccs_aux_stride() is not static sparse warning.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 34 ++---
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 0cf568a9cb1c6..a0db67e85c717 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -63,10 +63,36 @@ int skl_ccs_to_main_plane(const struct drm_framebuffer *fb, 
int ccs_plane)
return ccs_plane - fb->format->num_planes / 2;
 }
 
-static int gen12_ccs_aux_stride(struct drm_framebuffer *fb, int ccs_plane)
+static unsigned int gen12_aligned_scanout_stride(const struct 
intel_framebuffer *fb,
+int color_plane)
 {
-   return DIV_ROUND_UP(fb->pitches[skl_ccs_to_main_plane(fb, ccs_plane)],
-   512) * 64;
+   struct drm_i915_private *i915 = to_i915(fb->base.dev);
+   unsigned int stride = fb->base.pitches[color_plane];
+
+   if (IS_ALDERLAKE_P(i915))
+   return roundup_pow_of_two(max(stride,
+ 8u * 
intel_tile_width_bytes(>base, color_plane)));
+
+   return stride;
+}
+
+static unsigned int gen12_ccs_aux_stride(struct intel_framebuffer *fb, int 
ccs_plane)
+{
+   struct drm_i915_private *i915 = to_i915(fb->base.dev);
+   int main_plane = skl_ccs_to_main_plane(>base, ccs_plane);
+   unsigned int main_stride = fb->base.pitches[main_plane];
+   unsigned int main_tile_width = intel_tile_width_bytes(>base, 
main_plane);
+
+   /*
+* On ADL-P the AUX stride must align with a power-of-two aligned main
+* surface stride. The stride of the allocated main surface object can
+* be less than this POT stride, which is then autopadded to the POT
+* size.
+*/
+   if (IS_ALDERLAKE_P(i915))
+   main_stride = gen12_aligned_scanout_stride(fb, main_plane);
+
+   return DIV_ROUND_UP(main_stride, 4 * main_tile_width) * 64;
 }
 
 int skl_main_to_aux_plane(const struct drm_framebuffer *fb, int main_plane)
@@ -1379,7 +1405,7 @@ int intel_framebuffer_init(struct intel_framebuffer 
*intel_fb,
}
 
if (is_gen12_ccs_plane(fb, i) && !is_gen12_ccs_cc_plane(fb, i)) 
{
-   int ccs_aux_stride = gen12_ccs_aux_stride(fb, i);
+   int ccs_aux_stride = gen12_ccs_aux_stride(intel_fb, i);
 
if (fb->pitches[i] != ccs_aux_stride) {
drm_dbg_kms(_priv->drm,
-- 
2.27.0



[Intel-gfx] [PATCH v2 1/6] drm/i915: Use tile block based dimensions for CCS origin x, y check

2021-09-06 Thread Imre Deak
The tile size for all surface types is 4 kbyte (or 2 kbyte on old
platforms), with the exception of the TGL/ADL CCS surface where the tile
size is 64 bytes. To be able to remap CCS FBs the CCS surface tile needs
to be defined as 4 kbyte as well (the granularity of GTT pages in a
remapped view).

The only place using the dimension of the 64 byte CCS area is the initial
check for the main vs. CCS plane origin coordinate match. To prepare for
adding support for remapping CCS FBs let's call the 64 byte CCS area a
'tile block' and add a helper to retrieve the dimensions for it.

No functional change.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 30 -
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index e4b8602ec0cd2..0cf568a9cb1c6 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -143,14 +143,14 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
 
 unsigned int intel_tile_height(const struct drm_framebuffer *fb, int 
color_plane)
 {
-   if (is_gen12_ccs_plane(fb, color_plane))
-   return 1;
-
return intel_tile_size(to_i915(fb->dev)) /
intel_tile_width_bytes(fb, color_plane);
 }
 
-/* Return the tile dimensions in pixel units */
+/*
+ * Return the tile dimensions in pixel units, based on the (2 or 4 kbyte) GTT
+ * page tile size.
+ */
 static void intel_tile_dims(const struct drm_framebuffer *fb, int color_plane,
unsigned int *tile_width,
unsigned int *tile_height)
@@ -162,6 +162,21 @@ static void intel_tile_dims(const struct drm_framebuffer 
*fb, int color_plane,
*tile_height = intel_tile_height(fb, color_plane);
 }
 
+/*
+ * Return the tile dimensions in pixel units, based on the tile block size.
+ * The block covers the full GTT page sized tile on all tiled surfaces and
+ * it's a 64 byte portion of the tile on TGL+ CCS surfaces.
+ */
+static void intel_tile_block_dims(const struct drm_framebuffer *fb, int 
color_plane,
+ unsigned int *tile_width,
+ unsigned int *tile_height)
+{
+   intel_tile_dims(fb, color_plane, tile_width, tile_height);
+
+   if (is_gen12_ccs_plane(fb, color_plane))
+   *tile_height = 1;
+}
+
 unsigned int intel_tile_row_size(const struct drm_framebuffer *fb, int 
color_plane)
 {
unsigned int tile_width, tile_height;
@@ -567,7 +582,12 @@ static int intel_fb_check_ccs_xy(const struct 
drm_framebuffer *fb, int ccs_plane
if (!is_ccs_plane(fb, ccs_plane) || is_gen12_ccs_cc_plane(fb, 
ccs_plane))
return 0;
 
-   intel_tile_dims(fb, ccs_plane, _width, _height);
+   /*
+* While all the tile dimensions are based on a 2k or 4k GTT page size
+* here the main and CCS coordinates must match only within a (64 byte
+* on TGL+) block inside the tile.
+*/
+   intel_tile_block_dims(fb, ccs_plane, _width, _height);
intel_fb_plane_get_subsampling(, , fb, ccs_plane);
 
tile_width *= hsub;
-- 
2.27.0



[Intel-gfx] [PATCH v2 0/6] drm/i915/adlp: Add support for remapping CCS FBs

2021-09-06 Thread Imre Deak
This is v2 of [1] fixing the initialization of plane_alignment in patch
5 and issues reported by checkpatch, sparse. Also the last patch in this
series adds a description to drm_fourcc.h about the main and CCS surface
stride requirements for all CCS modifiers on ADL-P.

The corresponding IGT changes are at:
https://patchwork.freedesktop.org/series/94107/

[1] https://patchwork.freedesktop.org/series/94108/

Test-with: 20210906181736.3914421-1-imre.d...@intel.com

Cc: Juha-Pekka Heikkila 
Cc: Nanley G Chery 

Imre Deak (6):
  drm/i915: Use tile block based dimensions for CCS origin x, y check
  drm/i915/adlp: Require always a power-of-two sized CCS surface stride
  drm/i915/adlp: Assert that VMAs in DPT start at 0
  drm/i915: Follow a new->old platform check order in
intel_fb_stride_alignment
  drm/i915/adlp: Add support for remapping CCS FBs
  drm/fourcc: Add the ADL-P specific pitch requirements of CCS modifiers

 drivers/gpu/drm/i915/display/intel_display.c  |   5 +-
 .../drm/i915/display/intel_display_types.h|   2 -
 drivers/gpu/drm/i915/display/intel_fb.c   | 171 --
 .../drm/i915/display/skl_universal_plane.c|   5 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  29 ++-
 drivers/gpu/drm/i915/i915_vma_types.h |   7 +-
 include/uapi/drm/drm_fourcc.h |  24 ++-
 7 files changed, 174 insertions(+), 69 deletions(-)

-- 
2.27.0



Re: [Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug

2021-09-06 Thread jim . cromie
> I'll try to extract the "executive summary" from this, you tell me if I
> got it right.
>
> So using or not using dynamic debug for DRM debug ends up being about
> shifting the cost between kernel binary size (data section grows by each
> pr_debug call site) and runtime conditionals?

Yes.

> Since the table sizes you mention seem significant enough, I think that
> justifies existence of DRM_USE_DYNAMIC_DEBUG. It would probably be a
> good idea to put some commentary on that there. Ideally including some
> rough estimates both including space cost per call site and space cost
> for a typical distro kernel build?

yeah, agreed.  I presume you mean in Kconfig entry,
since commits have some size info now - I have i915, amdgpu, nouveau;
I can see some prose improvements for 5/8




> Regards,
>
> Tvrtko

thanks
Jim


Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

2021-09-06 Thread jim . cromie
On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
>
> On 03/09/2021 20:22, jim.cro...@gmail.com wrote:
> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 31/08/2021 21:21, Jim Cromie wrote:
> >>> The gvt component of this driver has ~120 pr_debugs, in 9 categories
> >>> quite similar to those in DRM.  Following the interface model of
> >>> drm.debug, add a parameter to map bits to these categorizations.
> >>>
> >>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> >>>"dyndbg bitmap desc",
> >>>{ "gvt:cmd: ",  "command processing" },

> >>> v7:
> >>> . move ccflags addition up to i915/Makefile from i915/gvt
> >>> ---
> >>>drivers/gpu/drm/i915/Makefile  |  4 
> >>>drivers/gpu/drm/i915/i915_params.c | 35
++
> >>
> >> Can this work if put under gvt/ or at least intel_gvt.h|c?

I tried this.
I moved the code block into gvt/debug.c (new file)
added it to Makefile GVT_SOURCES
dunno why it wont make.
frustratig basic err, Im not seeing.
It does seem proper placement, will resolve...


> >>
> >
> > I thought it belonged here more, at least according to the name of the
> > config.var
>
> Hmm bear with me please - the categories this patch creates are intended
> to be used explicitly from the GVT "sub-module", or they somehow even
> get automatically used with no further intervention to callers required?
>

2009 - v5.9.0  the only users were admins reading/echoing
/proc/dynamic_debug/control
presumably cuz they wanted more info in the logs, episodically.
v5.9.0 exported dynamic_debug_exec_queries for in-kernel use,
reusing the stringy: echo $query_command > control  idiom.
My intention was to let in-kernel users roll their own drm.debug type
interface,
or whatever else they needed.  nobodys using it yet.

patch 1/8 implements that drm.debug interface.
5/8 is the primary use case
3/8 (this patch) & 4/8 are patches of opportunity, test cases, proof of
function/utility.
its value as such is easier control of those pr-debugs than given by echo >
control

Sean Paul  seanp...@chromium.org worked up a patchset to do runtime
steering of drm-debug stream,
in particular watching for drm:atomic:fail: type activity (a subcategory
which doesnt exist yet).
5/8 conflicts with his patchset, I have an rfc approach to that, so his
concerns are mine too.


note:  if this patchset goes in, we dont *really* need the export anymore,
since the main use case is covered.  We could un-export, and re-add later
if its needed for a different use case.  Further, it seems likely that the
callbacks
(refactored) would be a better basis for new in-kernel users.
If not that, then full exposure of struct ddebug_query to in-kernel use


not quite sure how we got 2 chunks, but theres 1 more q below.

On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:

>
> On 03/09/2021 20:22, jim.cro...@gmail.com wrote:
> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 31/08/2021 21:21, Jim Cromie wrote:
> >>> The gvt component of this driver has ~120 pr_debugs, in 9 categories
> >>> quite similar to those in DRM.  Following the interface model of
> >>> drm.debug, add a parameter to map bits to these categorizations.
> >>>
> >>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> >>>"dyndbg bitmap desc",
> >>>{ "gvt:cmd: ",  "command processing" },
> >>>{ "gvt:core: ", "core help" },
> >>>{ "gvt:dpy: ",  "display help" },
> >>>{ "gvt:el: ",   "help" },
> >>>{ "gvt:irq: ",  "help" },
> >>>{ "gvt:mm: ",   "help" },
> >>>{ "gvt:mmio: ", "help" },
> >>>{ "gvt:render: ", "help" },
> >>>{ "gvt:sched: " "help" });
> >>>
> >
> > BTW, Ive dropped the help field, its already handled, dont need to
> clutter.
> >
> >
> >>> The actual patch has a few details different, cmd_help() macro emits
> >>> the initialization construct.
> >>>
> >>> if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
> >>> cflags, by gvt/Makefile.
> >>>
> >>> Signed-off-by: Jim Cromie 
> >>> ---
> >>> v5:
> >>> . static decl of vector of bit->class descriptors - Emil.V
> >>> . relocate gvt-makefile chunk from elsewhere
> >>> v7:
> >>> . move ccflags addition up to i915/Makefile from i915/gvt
> >>> ---
> >>>drivers/gpu/drm/i915/Makefile  |  4 
> >>>drivers/gpu/drm/i915/i915_params.c | 35
> ++
> >>
> >> Can this work if put under gvt/ or at least intel_gvt.h|c?
> >>
> >
> > I thought it belonged here more, at least according to the name of the
> > config.var
>
> Hmm bear with me please - the categories this patch creates are intended
> to be used explicitly from the GVT "sub-module", or they somehow even
> get automatically used with no further intervention to callers required?
>
> > CONFIG_DRM_USE_DYNAMIC_DEBUG.
> >
> > I suppose its not a great name, its narrow 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)
URL   : https://patchwork.freedesktop.org/series/94278/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20967


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#1888])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u:   [INCOMPLETE][6] ([i915#198]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20967/fi-skl-6600u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

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


Participating hosts (45 -> 39)
--

  Missing(6): bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10553 -> Patchwork_20967

  CI-20190529: 20190529
  CI_DRM_10553: 47b2bd2caa7b29b5741ff2521206657853b85165 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20967: c126fbafb4e813c9ee4ce8c2f08303b7f31bff9a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c126fbafb4e8 drm/i915: Reduce the number of objects subject to memcpy recover
8c5683b42483 drm/i915: Don't back up pinned LMEM context images and rings 
during suspend
267f6f9b0db9 drm/i915/gt: Register the migrate contexts with their engines
7150eea69e42 drm/i915 Implement LMEM backup and restore for suspend / resume
db26c8c667ad drm/i915/gem: Implement a function to process all gem objects of a 
region
aaef4ee507ef drm/i915/ttm: Implement a function to copy the contents of two 
TTM-base objects

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915: Suspend / resume backup- and restore of LMEM. (rev2)
URL   : https://patchwork.freedesktop.org/series/94278/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
aaef4ee507ef drm/i915/ttm: Implement a function to copy the contents of two 
TTM-base objects
db26c8c667ad drm/i915/gem: Implement a function to process all gem objects of a 
region
7150eea69e42 drm/i915 Implement LMEM backup and restore for suspend / resume
-:291: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#291: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 498 lines checked
267f6f9b0db9 drm/i915/gt: Register the migrate contexts with their engines
8c5683b42483 drm/i915: Don't back up pinned LMEM context images and rings 
during suspend
c126fbafb4e8 drm/i915: Reduce the number of objects subject to memcpy recover




[Intel-gfx] [PATCH v2 4/6] drm/i915/gt: Register the migrate contexts with their engines

2021-09-06 Thread Thomas Hellström
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.

Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the pinned
contexts.

This fixes the kms_pipe_crc_basic@suspend-read-crc-pipe-a selftest for now,
but proper LMEM backup / restore is needed for full suspend functionality.
However, note that even with full LMEM backup / restore it may be
desirable to keep the reset since backing up the migrate context images
must happen using memcpy() after the migrate context has become inactive,
and for performance- and other reasons we want to avoid memcpy() from
LMEM.

Also traverse the list at guc_init_lrc_mapping() calling
guc_kernel_context_pin() for the pinned contexts, like is already done
for the kernel context.

v2:
- Don't reset the contexts on each __engine_unpark() but rather at
  resume time (Chris Wilson).
v3:
- Reset contexts in the engine sanitize callback. (Chris Wilson)

Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
Cc: Brost Matthew 
Cc: Chris Wilson 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_context_types.h |  8 +++
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  4 
 drivers/gpu/drm/i915/gt/intel_engine_pm.c | 23 +++
 drivers/gpu/drm/i915/gt/intel_engine_pm.h |  2 ++
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  7 ++
 .../drm/i915/gt/intel_execlists_submission.c  |  2 ++
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  3 +++
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++---
 9 files changed, 60 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e54351a170e2..a63631ea0ec4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -152,6 +152,14 @@ struct intel_context {
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
 
+   /**
+* pinned_contexts_link: List link for the engine's pinned contexts.
+* This is only used if this is a perma-pinned kernel context and
+* the list is assumed to only be manipulated during driver load
+* or unload time so no mutex protection currently.
+*/
+   struct list_head pinned_contexts_link;
+
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
 
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 332efea696a5..c606a4714904 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -320,6 +320,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id)
 
BUILD_BUG_ON(BITS_PER_TYPE(engine->mask) < I915_NUM_ENGINES);
 
+   INIT_LIST_HEAD(>pinned_contexts_list);
engine->id = id;
engine->legacy_idx = INVALID_ENGINE;
engine->mask = BIT(id);
@@ -875,6 +876,8 @@ intel_engine_create_pinned_context(struct intel_engine_cs 
*engine,
return ERR_PTR(err);
}
 
+   list_add_tail(>pinned_contexts_link, >pinned_contexts_list);
+
/*
 * Give our perma-pinned kernel timelines a separate lockdep class,
 * so that we can use them from within the normal user timelines
@@ -897,6 +900,7 @@ void intel_engine_destroy_pinned_context(struct 
intel_context *ce)
list_del(>timeline->engine_link);
mutex_unlock(>vm->mutex);
 
+   list_del(>pinned_contexts_link);
intel_context_unpin(ce);
intel_context_put(ce);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 1f07ac4e0672..dacd62773735 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -298,6 +298,29 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
intel_engine_init_heartbeat(engine);
 }
 
+/**
+ * intel_engine_reset_pinned_contexts - Reset the pinned contexts of
+ * an engine.
+ * @engine: The engine whose pinned contexts we want to reset.
+ *
+ * Typically the pinned context LMEM images lose or get their content
+ * corrupted on suspend. This function resets their images.
+ */
+void intel_engine_reset_pinned_contexts(struct intel_engine_cs *engine)
+{
+   struct intel_context *ce;
+
+   list_for_each_entry(ce, >pinned_contexts_list,
+   pinned_contexts_link) {
+   /* kernel context gets reset at __engine_unpark() */
+   if (ce == engine->kernel_context)
+   continue;
+
+   dbg_poison_ce(ce);
+   ce->ops->reset(ce);
+   }
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 

[Intel-gfx] [PATCH v2 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

2021-09-06 Thread Thomas Hellström
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.

Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.

Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.

Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.

Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  6 --
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c |  5 +++--
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +++--
 drivers/gpu/drm/i915/gt/intel_migrate.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 ++--
 17 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd169cf2f75a..3dbebced0950 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1312,7 +1312,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1490,7 +1490,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (args->flags)
return -EINVAL;
 
-   ppgtt = i915_ppgtt_create(>gt);
+   ppgtt = i915_ppgtt_create(>gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 66123ba46247..477b98b656b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
 #define I915_BO_ALLOC_USERBIT(3)
 /* Object may lose its contents on suspend / resume */
 #define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY  BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY  BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 9746c255ddcc..cdd344f64404 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -98,9 +98,11 @@ int i915_gem_backup_suspend(struct drm_i915_private *i915)
 * More objects may have become unpinned as requests were
 * retired. Now try to evict again. The gt may be wedged here
 * in which case we automatically fall back to memcpy.
+* We allow also backing up pinned objects that have not been
+* marked for early recover, and that may contain, for example,
+* page-tables for the migrate context.
 */
-
-   ret = lmem_suspend(i915, true, false);
+   ret = lmem_suspend(i915, true, true);
if (ret)
   

[Intel-gfx] [PATCH v2 5/6] drm/i915: Don't back up pinned LMEM context images and rings during suspend

2021-09-06 Thread Thomas Hellström
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.

Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.

Signed-off-by: Thomas Hellström 
---
 .../gpu/drm/i915/gem/i915_gem_object_types.h| 17 ++---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c  |  3 +++
 drivers/gpu/drm/i915/gt/intel_lrc.c |  3 ++-
 drivers/gpu/drm/i915/gt/intel_ring.c|  3 ++-
 4 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 734cc8e16481..66123ba46247 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -288,16 +288,19 @@ struct drm_i915_gem_object {
I915_SELFTEST_DECLARE(struct list_head st_link);
 
unsigned long flags;
-#define I915_BO_ALLOC_CONTIGUOUS BIT(0)
-#define I915_BO_ALLOC_VOLATILE   BIT(1)
-#define I915_BO_ALLOC_CPU_CLEAR  BIT(2)
-#define I915_BO_ALLOC_USER   BIT(3)
+#define I915_BO_ALLOC_CONTIGUOUS  BIT(0)
+#define I915_BO_ALLOC_VOLATILEBIT(1)
+#define I915_BO_ALLOC_CPU_CLEAR   BIT(2)
+#define I915_BO_ALLOC_USERBIT(3)
+/* Object may lose its contents on suspend / resume */
+#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
-I915_BO_ALLOC_USER)
-#define I915_BO_READONLY BIT(4)
-#define I915_TILING_QUIRK_BIT5 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_USER | \
+I915_BO_ALLOC_PM_VOLATILE)
+#define I915_BO_READONLY  BIT(5)
+#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
 
/**
 * @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 3884bf45dab8..eaceecfc3f19 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -61,6 +61,9 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region 
*apply,
if (!pm_apply->backup_pinned)
return 0;
 
+   if (obj->flags & I915_BO_ALLOC_PM_VOLATILE)
+   return 0;
+
sys_region = i915->mm.regions[INTEL_REGION_SMEM];
backup = i915_gem_object_create_region(sys_region,
   obj->base.size,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6ba8daea2f56..3ef9eaf8c50e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -942,7 +942,8 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
context_size += PAGE_SIZE;
}
 
-   obj = i915_gem_object_create_lmem(engine->i915, context_size, 0);
+   obj = i915_gem_object_create_lmem(engine->i915, context_size,
+ I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(engine->i915, context_size);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 7c4d5158e03b..2fdd52b62092 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -112,7 +112,8 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt 
*ggtt, int size)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
 
-   obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE);
+   obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
+ I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
-- 
2.31.1



[Intel-gfx] [PATCH v2 2/6] drm/i915/gem: Implement a function to process all gem objects of a region

2021-09-06 Thread Thomas Hellström
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.

Define a function that does this for us and that takes an argument that
defines the action to be performed on each object.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_region.c | 70 ++
 drivers/gpu/drm/i915/gem/i915_gem_region.h | 33 ++
 2 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1f557b2178ed..a016ccec36f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -80,3 +80,73 @@ i915_gem_object_create_region(struct intel_memory_region 
*mem,
i915_gem_object_free(obj);
return ERR_PTR(err);
 }
+
+/**
+ * i915_gem_process_region - Iterate over all objects of a region using ops
+ * to process and optionally skip objects
+ * @mr: The memory region
+ * @apply: ops and private data
+ *
+ * This function can be used to iterate over the regions object list,
+ * checking whether to skip objects, and, if not, lock the objects and
+ * process them using the supplied ops. Note that this function temporarily
+ * removes objects from the region list while iterating, so that if run
+ * concurrently with itself may not iterate over all objects.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
+int i915_gem_process_region(struct intel_memory_region *mr,
+   struct i915_gem_apply_to_region *apply)
+{
+   const struct i915_gem_apply_to_region_ops *ops = apply->ops;
+   struct drm_i915_gem_object *obj;
+   struct list_head still_in_list;
+   int ret = 0;
+
+   /*
+* In the future, a non-NULL apply->ww could mean the caller is
+* already in a locking transaction and provides its own context.
+*/
+   GEM_WARN_ON(apply->ww);
+
+   INIT_LIST_HEAD(_in_list);
+   mutex_lock(>objects.lock);
+   for (;;) {
+   struct i915_gem_ww_ctx ww;
+
+   obj = list_first_entry_or_null(>objects.list, typeof(*obj),
+  mm.region_link);
+   if (!obj)
+   break;
+
+   list_move_tail(>mm.region_link, _in_list);
+   if (!kref_get_unless_zero(>base.refcount))
+   continue;
+
+   /*
+* Note: Someone else might be migrating the object at this
+* point. The object's region is not stable until we lock
+* the object.
+*/
+   mutex_unlock(>objects.lock);
+   apply->ww = 
+   for_i915_gem_ww(, ret, apply->interruptible) {
+   ret = i915_gem_object_lock(obj, apply->ww);
+   if (ret)
+   continue;
+
+   if (obj->mm.region == mr)
+   ret = ops->process_obj(apply, obj);
+   /* Implicit object unlock */
+   }
+
+   i915_gem_object_put(obj);
+   mutex_lock(>objects.lock);
+   if (ret)
+   break;
+   }
+   list_splice_tail(_in_list, >objects.list);
+   mutex_unlock(>objects.lock);
+
+   return ret;
+}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h 
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index 1008e580a89a..f62195847056 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -12,6 +12,37 @@ struct intel_memory_region;
 struct drm_i915_gem_object;
 struct sg_table;
 
+struct i915_gem_apply_to_region;
+
+/**
+ * struct i915_gem_apply_to_region_ops - ops to use when iterating over all
+ * region objects.
+ */
+struct i915_gem_apply_to_region_ops {
+   /**
+* process_obj - Process the current object
+* @apply: Embed this for provate data
+* @obj: The current object.
+*/
+   int (*process_obj)(struct i915_gem_apply_to_region *apply,
+  struct drm_i915_gem_object *obj);
+};
+
+/**
+ * struct i915_gem_apply_to_region - Argument to the struct
+ * i915_gem_apply_to_region_ops functions.
+ * @ops: The ops for the operation.
+ * @ww: Locking context used for the transaction.
+ * @interruptible: Whether to perform object locking interruptible.
+ *
+ * This structure is intended to be embedded in a private struct if needed
+ */
+struct i915_gem_apply_to_region {
+   const struct i915_gem_apply_to_region_ops *ops;
+   struct i915_gem_ww_ctx *ww;
+   u32 interruptible:1;
+};
+
 void i915_gem_object_init_memory_region(struct drm_i915_gem_object *obj,
   

[Intel-gfx] [PATCH v2 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume

2021-09-06 Thread Thomas Hellström
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.

Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict evictable objects using the gpu blitter. This will
be modified in an upcoming patch to backup pinned objects that are not used
by the blitter itself.
3: Backup remaining pinned objects using memcpy.

Also move uC suspend to after 2) to make sure we have a functional GuC
during 2) if using GuC submission.

v2:
- Major refactor to make sure gem_exec_suspend@hang-SX subtests work, and
  suspend / resume works with a slightly modified GuC submission enabling
  patch series.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  92 +++-
 drivers/gpu/drm/i915/gem/i915_gem_pm.h|   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  29 ++-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |  10 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c| 205 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h|  24 ++
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c   |  10 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 11 files changed, 364 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c36c8a4f0716..3379a0a6c91e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
gem/i915_gem_ttm.o \
+   gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2471f36aaff3..734cc8e16481 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -534,6 +534,7 @@ struct drm_i915_gem_object {
struct {
struct sg_table *cached_io_st;
struct i915_gem_object_page_iter get_io_page;
+   struct drm_i915_gem_object *backup;
bool created:1;
} ttm;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 8b9d7d14c4bd..9746c255ddcc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -5,6 +5,7 @@
  */
 
 #include "gem/i915_gem_pm.h"
+#include "gem/i915_gem_ttm_pm.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_gt_requests.h"
@@ -39,7 +40,79 @@ void i915_gem_suspend(struct drm_i915_private *i915)
i915_gem_drain_freed_objects(i915);
 }
 
-void i915_gem_suspend_late(struct drm_i915_private *i915)
+static int lmem_restore(struct drm_i915_private *i915, bool allow_gpu)
+{
+   struct intel_memory_region *mr;
+   int ret = 0, id;
+
+   for_each_memory_region(mr, i915, id) {
+   if (mr->type == INTEL_MEMORY_LOCAL) {
+   ret = i915_ttm_restore_region(mr, allow_gpu);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
+}
+
+static int lmem_suspend(struct drm_i915_private *i915, bool allow_gpu,
+   bool backup_pinned)
+{
+   struct intel_memory_region *mr;
+   int ret = 0, id;
+
+   for_each_memory_region(mr, i915, id) {
+   if (mr->type == INTEL_MEMORY_LOCAL) {
+   ret = i915_ttm_backup_region(mr, allow_gpu, 
backup_pinned);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
+}
+
+static void lmem_recover(struct drm_i915_private *i915)
+{
+   struct intel_memory_region *mr;
+   int id;
+
+   for_each_memory_region(mr, i915, id)
+   if (mr->type == INTEL_MEMORY_LOCAL)
+   i915_ttm_recover_region(mr);
+}
+
+int i915_gem_backup_suspend(struct drm_i915_private *i915)
+{
+   int ret;
+
+   /* Opportunistically try to evict unpinned objects */
+   ret = lmem_suspend(i915, true, false);
+   if (ret)
+   goto out_recover;
+
+   i915_gem_suspend(i915);
+
+   /*
+* More objects may have become unpinned as requests were
+* retired. Now try to evict again. The gt may be wedged here
+* in which case we automatically fall back to memcpy.
+*/
+
+   ret = lmem_suspend(i915, true, false);
+   if (ret)
+   goto out_recover;
+
+   return 0;
+
+out_recover:
+   

[Intel-gfx] [PATCH v2 1/6] drm/i915/ttm: Implement a function to copy the contents of two TTM-base objects

2021-09-06 Thread Thomas Hellström
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable accelerated copies.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h |  4 ++
 2 files changed, 64 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 59ca53a3ef6a..df2dcbad1eb9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -432,6 +432,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
   bool clear,
   struct ttm_resource *dst_mem,
+  struct ttm_tt *dst_ttm,
   struct sg_table *dst_st)
 {
struct drm_i915_private *i915 = container_of(bo->bdev, typeof(*i915),
@@ -441,14 +442,14 @@ static int i915_ttm_accel_move(struct ttm_buffer_object 
*bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct sg_table *src_st;
struct i915_request *rq;
-   struct ttm_tt *ttm = bo->ttm;
+   struct ttm_tt *src_ttm = bo->ttm;
enum i915_cache_level src_level, dst_level;
int ret;
 
if (!i915->gt.migrate.context)
return -EINVAL;
 
-   dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
+   dst_level = i915_ttm_cache_level(i915, dst_mem, dst_ttm);
if (clear) {
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
@@ -465,10 +466,10 @@ static int i915_ttm_accel_move(struct ttm_buffer_object 
*bo,
}
intel_engine_pm_put(i915->gt.migrate.context->engine);
} else {
-   src_st = src_man->use_tt ? i915_ttm_tt_get_st(ttm) :
+   src_st = src_man->use_tt ? i915_ttm_tt_get_st(src_ttm) :
obj->ttm.cached_io_st;
 
-   src_level = i915_ttm_cache_level(i915, bo->resource, ttm);
+   src_level = i915_ttm_cache_level(i915, bo->resource, src_ttm);
intel_engine_pm_get(i915->gt.migrate.context->engine);
ret = intel_context_migrate_copy(i915->gt.migrate.context,
 NULL, src_st->sgl, src_level,
@@ -488,11 +489,14 @@ static int i915_ttm_accel_move(struct ttm_buffer_object 
*bo,
 
 static void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
struct ttm_resource *dst_mem,
-   struct sg_table *dst_st)
+   struct ttm_tt *dst_ttm,
+   struct sg_table *dst_st,
+   bool allow_accel)
 {
-   int ret;
+   int ret = -EINVAL;
 
-   ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
+   if (allow_accel)
+   ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_ttm, dst_st);
if (ret) {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct intel_memory_region *dst_reg, *src_reg;
@@ -507,7 +511,7 @@ static void __i915_ttm_move(struct ttm_buffer_object *bo, 
bool clear,
GEM_BUG_ON(!dst_reg || !src_reg);
 
dst_iter = !cpu_maps_iomem(dst_mem) ?
-   ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
+   ttm_kmap_iter_tt_init(&_dst_iter.tt, dst_ttm) :
ttm_kmap_iter_iomap_init(&_dst_iter.io, _reg->iomap,
 dst_st, dst_reg->region.start);
 
@@ -562,7 +566,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool 
evict,
 
clear = !cpu_maps_iomem(bo->resource) && (!ttm || 
!ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
-   __i915_ttm_move(bo, clear, dst_mem, dst_st);
+   __i915_ttm_move(bo, clear, dst_mem, bo->ttm, dst_st, true);
 
ttm_bo_move_sync_cleanup(bo, dst_mem);
i915_ttm_adjust_domains_after_move(obj);
@@ -973,3 +977,50 @@ i915_gem_ttm_system_setup(struct drm_i915_private *i915,
intel_memory_region_set_name(mr, "system-ttm");
return mr;
 }
+
+/**
+ * i915_gem_obj_copy_ttm - Copy the contents of one ttm-based gem object to
+ * another
+ * @dst: The destination object
+ * @src: The source object
+ * @allow_accel: Allow using the blitter. Otherwise TTM memcpy is used.
+ * @intr: Whether to perform waits interruptible:
+ *
+ * Note: The caller is responsible for assuring that the underlying
+ * TTM objects are populated if needed and locked.
+ *
+ * Return: Zero on 

[Intel-gfx] [PATCH v2 0/6] drm/i915: Suspend / resume backup- and restore of LMEM.

2021-09-06 Thread Thomas Hellström
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy resume.

The first two patches are prereq patches implementing object content copy
and a generic means of iterating through all objects in a region.
The third patch adds the backup / recover / restore functions and the
two last patches deal with restricting the number of objects we need to
use memcpy for.

v2:
- Some polishing of patch 4/6, see patch commit message for details (Chris
  Wilson)
- Rework of patch 3/6.

Thomas Hellström (6):
  drm/i915/ttm: Implement a function to copy the contents of two
TTM-base objects
  drm/i915/gem: Implement a function to process all gem objects of a
region
  drm/i915 Implement LMEM backup and restore for suspend / resume
  drm/i915/gt: Register the migrate contexts with their engines
  drm/i915: Don't back up pinned LMEM context images and rings during
suspend
  drm/i915: Reduce the number of objects subject to memcpy recover

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   4 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  94 +++-
 drivers/gpu/drm/i915/gem/i915_gem_pm.h|   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_region.c|  70 ++
 drivers/gpu/drm/i915/gem/i915_gem_region.h|  33 +++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  98 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |  14 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c| 210 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h|  24 ++
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   2 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |   5 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |   4 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |   8 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   4 +
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  23 ++
 drivers/gpu/drm/i915/gt/intel_engine_pm.h |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   7 +
 .../drm/i915/gt/intel_execlists_submission.c  |   2 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c|   2 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   9 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  13 +-
 drivers/gpu/drm/i915/gt/intel_ring.c  |   3 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +
 drivers/gpu/drm/i915/gt/mock_engine.c |   2 +
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  12 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.c   |  10 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   4 +-
 38 files changed, 649 insertions(+), 60 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h

-- 
2.31.1



Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/display: Drop PSR frontbuffer rendering support

2021-09-06 Thread Gwan-gyeong Mun

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 8/25/21 3:58 AM, José Roberto de Souza wrote:

After commit "drm/i915/display/skl+: Drop frontbuffer rendering
support" frontbuffer rendering is not supported for display 9 and
newer and as PSR is only supported by default in display 9 and newer
we can now drop all frontbuffer rendering support for PSR code.

Some DC3CO code was commented with a macro, because the function
caller is being dropped. As DC3CO is already disabled by default
because it requires changes in its sequences

Two DC3CO functions lost their callers while dropping frontbuffer
rendering but as DC3CO is already disabled by default because it
requires fixes, will leave this task to whoever will fix DC3CO.

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  .../drm/i915/display/intel_display_debugfs.c  |   2 -
  .../drm/i915/display/intel_display_types.h|   2 -
  .../gpu/drm/i915/display/intel_frontbuffer.c  |   2 -
  drivers/gpu/drm/i915/display/intel_psr.c  | 186 ++
  drivers/gpu/drm/i915/display/intel_psr.h  |   8 +-
  5 files changed, 18 insertions(+), 182 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca819f9e353d0..6d733b276d5b0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -374,8 +374,6 @@ static int intel_psr_status(struct seq_file *m, struct 
intel_dp *intel_dp)
seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
   enableddisabled(enabled), val);
psr_source_status(intel_dp, m);
-   seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
-  psr->busy_frontbuffer_bits);
  
  	/*

 * SKL+ Perf counter is reset to 0 everytime DC state is entered
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c2725d07b9303..18616435dcb18 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1512,7 +1512,6 @@ struct intel_psr {
enum transcoder transcoder;
bool active;
struct work_struct work;
-   unsigned int busy_frontbuffer_bits;
bool sink_psr2_support;
bool link_standby;
bool colorimetry_support;
@@ -1523,7 +1522,6 @@ struct intel_psr {
ktime_t last_entry_attempt;
ktime_t last_exit;
bool sink_not_reliable;
-   bool irq_aux_error;
u16 su_w_granularity;
u16 su_y_granularity;
u32 dc3co_exitline;
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 3860f87dac31c..1d8314d3712f4 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -93,7 +93,6 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
  
  	might_sleep();

intel_drrs_flush(i915, frontbuffer_bits);
-   intel_psr_flush(i915, frontbuffer_bits, origin);
intel_fbc_flush(i915, frontbuffer_bits, origin);
  }
  
@@ -195,7 +194,6 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,

trace_intel_frontbuffer_invalidate(frontbuffer_bits, origin);
  
  	might_sleep();

-   intel_psr_invalidate(i915, frontbuffer_bits, origin);
intel_drrs_invalidate(i915, frontbuffer_bits);
intel_fbc_invalidate(i915, frontbuffer_bits, origin);
  }
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 3f6fb7d67f84d..8c9bd5846a8d0 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -224,15 +224,12 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, u32 
psr_iir)
drm_warn(_priv->drm, "[transcoder %s] PSR aux error\n",
 transcoder_name(cpu_transcoder));
  
-		intel_dp->psr.irq_aux_error = true;

-
/*
 * If this interruption is not masked it will keep
 * interrupting so fast that it prevents the scheduled
 * work to run.
 * Also after a PSR error, we don't want to arm PSR
 * again so we don't care about unmask the interruption
-* or unset irq_aux_error.
 */
val = intel_de_read(dev_priv, imr_reg);
val |= EDP_PSR_ERROR(trans_shift);
@@ -614,14 +611,6 @@ static void psr2_program_idle_frames(struct intel_dp 
*intel_dp,
intel_de_write(dev_priv, EDP_PSR2_CTL(intel_dp->psr.transcoder), val);
  }
  
-static void tgl_psr2_enable_dc3co(struct intel_dp *intel_dp)

-{
-   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-
-   psr2_program_idle_frames(intel_dp, 0);
-   intel_display_power_set_target_dc_state(dev_priv, DC_STATE_EN_DC3CO);
-}
-
  static 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Tvrtko Ursulin



On 06/09/2021 14:48, Matthew Auld wrote:

On 06/09/2021 13:53, Tvrtko Ursulin wrote:


On 06/09/2021 13:30, Matthew Auld wrote:

On 06/09/2021 13:19, Tvrtko Ursulin wrote:


On 06/09/2021 10:17, Matthew Auld wrote:
Since the object might still be active here, the shrink_all will 
simply

ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the 
failure.

Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
  .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 
++-

  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c

index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
  struct i915_vma *vma;
  unsigned int flags = PIN_USER;
  unsigned int n;
+    bool should_swap;
  int err = 0;
  /*
@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
  break;
  }
  i915_gem_context_unlock_engines(ctx);
+    /*
+ * Nuke everything *before* we unpin the pages so we can be 
reasonably
+ * sure that when later checking get_nr_swap_pages() that some 
random

+ * leftover object doesn't steal the remaining swap space.
+ */
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
  i915_vma_unpin(vma);
  if (err)
  goto out_put;
+
  /*
- * Now that the pages are *unpinned* shrink-all should invoke
- * shmem to truncate our pages.
+ * Now that the pages are *unpinned* shrinking should invoke
+ * shmem to truncate our pages, if we have available swap.
   */
-    i915_gem_shrink_all(i915);
-    if (i915_gem_object_has_pages(obj)) {
-    pr_err("shrink-all didn't truncate the pages\n");
+    should_swap = get_nr_swap_pages() > 0;
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
+    if (should_swap == i915_gem_object_has_pages(obj)) {


Hmm is there any value running the test if no swap (given objects 
used by the test are "willneed"), or you could simplify and just do 
early skip?


Maybe. My thinking was that this adds some coverage if say the device 
is not configured with swap. i.e assert that the pages don't 
magically disappear, and that their contents still persist etc.


Happy to make it skip instead though?


So reducing it to a basic shrinker test in that case. Hm.. do you know 
if we have a non THP specific tests for that already somewhere in 
selftests (I can't spot any), or just in IGT?


Just IGT I think, outside of some cases where we call gem_shrink in very 
specific places, which would be hard to do from an IGT.




If we indeed don't have it in selftests, then I guess question is 
whether it is warranted to "hide" such a basic test in the THP 
"drawer", or instead adding a generic shrinker test should be 
considered. (And one could then follow with a question should a basic 
generic test have a THP sub-test.)


The reason for the selftest vs IGT is mostly because userspace doesn't 
have any knowledge of the underlying pages, or whether THP is used. IIRC 
there was some issue with THP + our shmem backend in the past, so also 
adding some basic coverage for THP + i915-gem shrinker seemed 
reasonable. Even if we don't have swap space, I think it still makes 
some sense to call into gem_shrink with our target THP object.


Okay, as you have probably guessed I have no strong feelings either way, 
so you can freely upgrade my r-b to current.


Regards,

Tvrtko





It's hard to say where the boundary for selftests-vs-IGT coverage 
should be in this case. I mean would it be warranted to add such a 
generic shrinker selftest. It is mostly testable from userspace, but 
kernel can do a few more introspections and sanity checks at cost of 
growing kernel code.


Regards,

Tvrtko





Regards,

Tvrtko


+    pr_err("unexpected pages mismatch, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }
-    if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {
-    pr_err("residual page-size bits left\n");
+    if (should_swap == (obj->mm.page_sizes.sg || 
obj->mm.page_sizes.phys)) {
+    pr_err("unexpected residual page-size bits, 
should_swap=%s\n",

+   yesno(should_swap));
  err = -EINVAL;
  goto 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Matthew Auld

On 06/09/2021 13:53, Tvrtko Ursulin wrote:


On 06/09/2021 13:30, Matthew Auld wrote:

On 06/09/2021 13:19, Tvrtko Ursulin wrote:


On 06/09/2021 10:17, Matthew Auld wrote:

Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the 
failure.

Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
  .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 
++-

  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c

index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
  struct i915_vma *vma;
  unsigned int flags = PIN_USER;
  unsigned int n;
+    bool should_swap;
  int err = 0;
  /*
@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
  break;
  }
  i915_gem_context_unlock_engines(ctx);
+    /*
+ * Nuke everything *before* we unpin the pages so we can be 
reasonably
+ * sure that when later checking get_nr_swap_pages() that some 
random

+ * leftover object doesn't steal the remaining swap space.
+ */
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
  i915_vma_unpin(vma);
  if (err)
  goto out_put;
+
  /*
- * Now that the pages are *unpinned* shrink-all should invoke
- * shmem to truncate our pages.
+ * Now that the pages are *unpinned* shrinking should invoke
+ * shmem to truncate our pages, if we have available swap.
   */
-    i915_gem_shrink_all(i915);
-    if (i915_gem_object_has_pages(obj)) {
-    pr_err("shrink-all didn't truncate the pages\n");
+    should_swap = get_nr_swap_pages() > 0;
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
+    if (should_swap == i915_gem_object_has_pages(obj)) {


Hmm is there any value running the test if no swap (given objects 
used by the test are "willneed"), or you could simplify and just do 
early skip?


Maybe. My thinking was that this adds some coverage if say the device 
is not configured with swap. i.e assert that the pages don't magically 
disappear, and that their contents still persist etc.


Happy to make it skip instead though?


So reducing it to a basic shrinker test in that case. Hm.. do you know 
if we have a non THP specific tests for that already somewhere in 
selftests (I can't spot any), or just in IGT?


Just IGT I think, outside of some cases where we call gem_shrink in very 
specific places, which would be hard to do from an IGT.




If we indeed don't have it in selftests, then I guess question is 
whether it is warranted to "hide" such a basic test in the THP "drawer", 
or instead adding a generic shrinker test should be considered. (And one 
could then follow with a question should a basic generic test have a THP 
sub-test.)


The reason for the selftest vs IGT is mostly because userspace doesn't 
have any knowledge of the underlying pages, or whether THP is used. IIRC 
there was some issue with THP + our shmem backend in the past, so also 
adding some basic coverage for THP + i915-gem shrinker seemed 
reasonable. Even if we don't have swap space, I think it still makes 
some sense to call into gem_shrink with our target THP object.




It's hard to say where the boundary for selftests-vs-IGT coverage should 
be in this case. I mean would it be warranted to add such a generic 
shrinker selftest. It is mostly testable from userspace, but kernel can 
do a few more introspections and sanity checks at cost of growing kernel 
code.


Regards,

Tvrtko





Regards,

Tvrtko


+    pr_err("unexpected pages mismatch, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }
-    if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {
-    pr_err("residual page-size bits left\n");
+    if (should_swap == (obj->mm.page_sizes.sg || 
obj->mm.page_sizes.phys)) {

+    pr_err("unexpected residual page-size bits, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }



Re: [Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Tvrtko Ursulin



On 06/09/2021 13:30, Matthew Auld wrote:

On 06/09/2021 13:19, Tvrtko Ursulin wrote:


On 06/09/2021 10:17, Matthew Auld wrote:

Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the failure.
Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
  .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 ++-
  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c

index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
  struct i915_vma *vma;
  unsigned int flags = PIN_USER;
  unsigned int n;
+    bool should_swap;
  int err = 0;
  /*
@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
  break;
  }
  i915_gem_context_unlock_engines(ctx);
+    /*
+ * Nuke everything *before* we unpin the pages so we can be 
reasonably
+ * sure that when later checking get_nr_swap_pages() that some 
random

+ * leftover object doesn't steal the remaining swap space.
+ */
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
  i915_vma_unpin(vma);
  if (err)
  goto out_put;
+
  /*
- * Now that the pages are *unpinned* shrink-all should invoke
- * shmem to truncate our pages.
+ * Now that the pages are *unpinned* shrinking should invoke
+ * shmem to truncate our pages, if we have available swap.
   */
-    i915_gem_shrink_all(i915);
-    if (i915_gem_object_has_pages(obj)) {
-    pr_err("shrink-all didn't truncate the pages\n");
+    should_swap = get_nr_swap_pages() > 0;
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
+    if (should_swap == i915_gem_object_has_pages(obj)) {


Hmm is there any value running the test if no swap (given objects used 
by the test are "willneed"), or you could simplify and just do early 
skip?


Maybe. My thinking was that this adds some coverage if say the device is 
not configured with swap. i.e assert that the pages don't magically 
disappear, and that their contents still persist etc.


Happy to make it skip instead though?


So reducing it to a basic shrinker test in that case. Hm.. do you know 
if we have a non THP specific tests for that already somewhere in 
selftests (I can't spot any), or just in IGT?


If we indeed don't have it in selftests, then I guess question is 
whether it is warranted to "hide" such a basic test in the THP "drawer", 
or instead adding a generic shrinker test should be considered. (And one 
could then follow with a question should a basic generic test have a THP 
sub-test.)


It's hard to say where the boundary for selftests-vs-IGT coverage should 
be in this case. I mean would it be warranted to add such a generic 
shrinker selftest. It is mostly testable from userspace, but kernel can 
do a few more introspections and sanity checks at cost of growing kernel 
code.


Regards,

Tvrtko





Regards,

Tvrtko


+    pr_err("unexpected pages mismatch, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }
-    if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {
-    pr_err("residual page-size bits left\n");
+    if (should_swap == (obj->mm.page_sizes.sg || 
obj->mm.page_sizes.phys)) {

+    pr_err("unexpected residual page-size bits, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }



Re: [Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Matthew Auld

On 06/09/2021 13:19, Tvrtko Ursulin wrote:


On 06/09/2021 10:17, Matthew Auld wrote:

Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the failure.
Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
  .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 ++-
  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c

index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
  struct i915_vma *vma;
  unsigned int flags = PIN_USER;
  unsigned int n;
+    bool should_swap;
  int err = 0;
  /*
@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
  break;
  }
  i915_gem_context_unlock_engines(ctx);
+    /*
+ * Nuke everything *before* we unpin the pages so we can be 
reasonably
+ * sure that when later checking get_nr_swap_pages() that some 
random

+ * leftover object doesn't steal the remaining swap space.
+ */
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
  i915_vma_unpin(vma);
  if (err)
  goto out_put;
+
  /*
- * Now that the pages are *unpinned* shrink-all should invoke
- * shmem to truncate our pages.
+ * Now that the pages are *unpinned* shrinking should invoke
+ * shmem to truncate our pages, if we have available swap.
   */
-    i915_gem_shrink_all(i915);
-    if (i915_gem_object_has_pages(obj)) {
-    pr_err("shrink-all didn't truncate the pages\n");
+    should_swap = get_nr_swap_pages() > 0;
+    i915_gem_shrink(NULL, i915, -1UL, NULL,
+    I915_SHRINK_BOUND |
+    I915_SHRINK_UNBOUND |
+    I915_SHRINK_ACTIVE);
+    if (should_swap == i915_gem_object_has_pages(obj)) {


Hmm is there any value running the test if no swap (given objects used 
by the test are "willneed"), or you could simplify and just do early skip?


Maybe. My thinking was that this adds some coverage if say the device is 
not configured with swap. i.e assert that the pages don't magically 
disappear, and that their contents still persist etc.


Happy to make it skip instead though?



Regards,

Tvrtko


+    pr_err("unexpected pages mismatch, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }
-    if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {
-    pr_err("residual page-size bits left\n");
+    if (should_swap == (obj->mm.page_sizes.sg || 
obj->mm.page_sizes.phys)) {

+    pr_err("unexpected residual page-size bits, should_swap=%s\n",
+   yesno(should_swap));
  err = -EINVAL;
  goto out_put;
  }



Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

2021-09-06 Thread Tvrtko Ursulin



On 03/09/2021 20:22, jim.cro...@gmail.com wrote:

On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
 wrote:



On 31/08/2021 21:21, Jim Cromie wrote:

The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM.  Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.

DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
   "dyndbg bitmap desc",
   { "gvt:cmd: ",  "command processing" },
   { "gvt:core: ", "core help" },
   { "gvt:dpy: ",  "display help" },
   { "gvt:el: ",   "help" },
   { "gvt:irq: ",  "help" },
   { "gvt:mm: ",   "help" },
   { "gvt:mmio: ", "help" },
   { "gvt:render: ", "help" },
   { "gvt:sched: " "help" });



BTW, Ive dropped the help field, its already handled, dont need to clutter.



The actual patch has a few details different, cmd_help() macro emits
the initialization construct.

if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
cflags, by gvt/Makefile.

Signed-off-by: Jim Cromie 
---
v5:
. static decl of vector of bit->class descriptors - Emil.V
. relocate gvt-makefile chunk from elsewhere
v7:
. move ccflags addition up to i915/Makefile from i915/gvt
---
   drivers/gpu/drm/i915/Makefile  |  4 
   drivers/gpu/drm/i915/i915_params.c | 35 ++


Can this work if put under gvt/ or at least intel_gvt.h|c?



I thought it belonged here more, at least according to the name of the
config.var


Hmm bear with me please - the categories this patch creates are intended 
to be used explicitly from the GVT "sub-module", or they somehow even 
get automatically used with no further intervention to callers required?



CONFIG_DRM_USE_DYNAMIC_DEBUG.

I suppose its not a great name, its narrow purpose is to swap
drm-debug api to use dyndbg.   drm-evrything already "uses"
dyndbg if CONFIG_DYNAMIC_DEBUG=y, those gvt/pr_debugs in particular.

Theres also CONFIG_DYNAMIC_DEBUG_CORE=y,
which drm basically ignores currently.

So with the name CONFIG_DRM_USE_DYNAMIC_DEBUG
it seemed proper to arrange for that  to be true on DD-CORE=y builds,
by adding -DDYNAMIC_DEBUG_MODULE

Does that make some sense ?
How to best resolve the frictions ?
new CONFIG names ?


   2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49b..5a4e371a3ec2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -30,6 +30,10 @@ CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, 
override-init)

   subdir-ccflags-y += -I$(srctree)/$(src)

+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+ccflags-y += -DDYNAMIC_DEBUG_MODULE
+#endif


Ignores whether CONFIG_DRM_I915_GVT is enabled or not?



not intentionally.
I think theres 2 things youre noting:

1 - make frag into gvt/Makefile
I had it there earlier, not sure why I moved it up.
maybe some confusion on proper scope of the flag.


2 - move new declaration code in i915-param.c inside the gvt ifdef

Im good with that.
I'll probably copy the ifdef wrapper down rather than move the decl up.
ie:

#if __and(IS_ENABLED(CONFIG_DRM_I915_GVT),
   IS_ENABLED(CONFIG_DRM_USE_DYNAMIC_DEBUG))

unsigned long __gvt_debug;
EXPORT_SYMBOL(__gvt_debug);



+
   # Please keep these build lists sorted!

   # core driver code
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index e07f4cfea63a..e645e149485e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)
   I915_PARAMS_FOR_EACH(FREE);
   #undef FREE
   }
+
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+/* todo: needs DYNAMIC_DEBUG_MODULE in some cases */
+
+unsigned long __gvt_debug;
+EXPORT_SYMBOL(__gvt_debug);
+
+#define _help(key)   "\t\"" key "\"\t: help for " key "\n"
+
+#define I915_GVT_CATEGORIES(name) \
+ " Enable debug output via /sys/module/i915/parameters/" #name   \
+ ", where each bit enables a debug category.\n"  \
+ _help("gvt:cmd:")   \
+ _help("gvt:core:")  \
+ _help("gvt:dpy:")   \
+ _help("gvt:el:")\
+ _help("gvt:irq:")   \
+ _help("gvt:mm:")\
+ _help("gvt:mmio:")  \
+ _help("gvt:render:")\
+ _help("gvt:sched:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
+ I915_GVT_CATEGORIES(debug_gvt),
+ _DD_cat_("gvt:cmd:"),
+ _DD_cat_("gvt:core:"),
+ _DD_cat_("gvt:dpy:"),
+ 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Tvrtko Ursulin



On 06/09/2021 10:17, Matthew Auld wrote:

Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the failure.
Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
  .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 ++-
  1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
struct i915_vma *vma;
unsigned int flags = PIN_USER;
unsigned int n;
+   bool should_swap;
int err = 0;
  
  	/*

@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
break;
}
i915_gem_context_unlock_engines(ctx);
+   /*
+* Nuke everything *before* we unpin the pages so we can be reasonably
+* sure that when later checking get_nr_swap_pages() that some random
+* leftover object doesn't steal the remaining swap space.
+*/
+   i915_gem_shrink(NULL, i915, -1UL, NULL,
+   I915_SHRINK_BOUND |
+   I915_SHRINK_UNBOUND |
+   I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
goto out_put;
  
+

/*
-* Now that the pages are *unpinned* shrink-all should invoke
-* shmem to truncate our pages.
+* Now that the pages are *unpinned* shrinking should invoke
+* shmem to truncate our pages, if we have available swap.
 */
-   i915_gem_shrink_all(i915);
-   if (i915_gem_object_has_pages(obj)) {
-   pr_err("shrink-all didn't truncate the pages\n");
+   should_swap = get_nr_swap_pages() > 0;
+   i915_gem_shrink(NULL, i915, -1UL, NULL,
+   I915_SHRINK_BOUND |
+   I915_SHRINK_UNBOUND |
+   I915_SHRINK_ACTIVE);
+   if (should_swap == i915_gem_object_has_pages(obj)) {


Hmm is there any value running the test if no swap (given objects used 
by the test are "willneed"), or you could simplify and just do early skip?


Regards,

Tvrtko


+   pr_err("unexpected pages mismatch, should_swap=%s\n",
+  yesno(should_swap));
err = -EINVAL;
goto out_put;
}
  
-	if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {

-   pr_err("residual page-size bits left\n");
+   if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
+   pr_err("unexpected residual page-size bits, should_swap=%s\n",
+  yesno(should_swap));
err = -EINVAL;
goto out_put;
}



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: fixup igt_shrink_thp (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: fixup igt_shrink_thp (rev2)
URL   : https://patchwork.freedesktop.org/series/93128/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10552_full -> Patchwork_20966_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2846])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk9/igt@gem_exec_f...@basic-deadline.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-glk8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +155 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-apl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-apl3/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#1888] / [i915#307])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk1/igt@gem_mmap_...@cpuset-medium-copy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-glk3/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_pread@exhaustion:
- shard-snb:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-snb2/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-skl10/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-glk:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-glk1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-snb:  NOTRUN -> [DMESG-WARN][19] ([i915#3002])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-snb6/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][20] ([i915#2724])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-snb2/igt@gem_userptr_bl...@vma-merge.html
- shard-apl:  NOTRUN -> [FAIL][21] ([i915#3318])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-apl1/igt@gem_userptr_bl...@vma-merge.html
- shard-glk:  NOTRUN -> [FAIL][22] ([i915#3318])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-glk1/igt@gem_userptr_bl...@vma-merge.html
- shard-skl:  NOTRUN -> [FAIL][23] ([i915#3318])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/shard-skl10/igt@gem_userptr_bl...@vma-merge.html

  * 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

2021-09-06 Thread Petri Latvala
On Mon, Sep 06, 2021 at 11:04:13AM +0100, Tvrtko Ursulin wrote:
> 
> On 03/09/2021 14:01, Petri Latvala wrote:
> > On Fri, Sep 03, 2021 at 12:29:51PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 03/09/2021 01:31, jim.cro...@gmail.com wrote:
> > > > 
> > > > 
> > > > On Tue, Aug 31, 2021 at 5:38 PM Patchwork
> > > >  > > > > wrote:
> > > > 
> > > >  __
> > > >  *Patch Details*
> > > >  *Series:*  use DYNAMIC_DEBUG to implement DRM.debug (rev2)
> > > >  *URL:* https://patchwork.freedesktop.org/series/93914/
> > > >  
> > > >  *State:*   failure
> > > >  *Details:*
> > > >  https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.html
> > > >  
> > > > 
> > > > 
> > > > 
> > > >CI Bug Log - changes from CI_DRM_10541_full -> 
> > > > Patchwork_20931_full
> > > > 
> > > > 
> > > >  Summary
> > > > 
> > > >  *FAILURE*
> > > > 
> > > >  Serious unknown changes coming with Patchwork_20931_full absolutely
> > > >  need to be
> > > >  verified manually.
> > > > 
> > > >  If you think the reported changes have nothing to do with the 
> > > > changes
> > > >  introduced in Patchwork_20931_full, please notify your bug team to
> > > >  allow them
> > > >  to document this new failure mode, which will reduce false 
> > > > positives
> > > >  in CI.
> > > > 
> > > > 
> > > > hi Team !
> > > > 
> > > > I think I need a bit of orientation.
> > > > 
> > > > 
> > > >  Possible new issues
> > > > 
> > > >  Here are the unknown changes that may have been introduced in
> > > >  Patchwork_20931_full:
> > > > 
> > > > 
> > > >IGT changes
> > > > 
> > > > 
> > > >  Possible regressions
> > > > 
> > > >* igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
> > > >o shard-skl: NOTRUN -> INCOMPLETE
> > > >  
> > > > 
> > > > 
> > > > 
> > > >  Warnings
> > > > 
> > > >* igt@i915_pm_dc@dc9-dpms:
> > > >o shard-skl: SKIP
> > > >  
> > > > 
> > > >  ([fdo#109271]) -> FAIL
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Im assuming the FAIL is the sticking point,
> > > 
> > > Both INCOMPLETE and FAIL will cause a failure to be declared, but in this 
> > > case it looks to me this series is not at fault.
> > > 
> > > 1)
> > > 
> > > The gem_exec_schedule failure looks like a test runner timeout issue (and 
> > > apparently test does not handle well running the the fence timeout 
> > > enabled).
> > > 
> > > @Petri - does the below look like IGT runner running our of time budget 
> > > for the test run? Would it log
> > > 
> > > [1051.943629] [114/138] ( 11s left) gem_exec_schedule 
> > > (u-submit-golden-slice)
> > > Starting subtest: u-submit-golden-slice
> > > Starting dynamic subtest: rcs0
> > > Dynamic subtest rcs0: SUCCESS (80.175s)
> > > Starting dynamic subtest: bcs0
> > > Dynamic subtest bcs0: SUCCESS (80.195s)
> > > Starting dynamic subtest: vcs0
> > > Dynamic subtest vcs0: SUCCESS (80.243s)
> > > Starting dynamic subtest: vecs0
> > > 
> > > Interesting part is that according to dmesg it never got to the vecs0 
> > > dynamic subtest - any idea what happened there?
> > 
> > Yep, we ran out of time. We still had 11 seconds left to execute
> > something but then that test took centuries.
> 
> Okay at least that's explained then.
> 
> Perhaps could make that act of termination logged in igt_runner log?

We do log everything we can, but unfortunately this was such an
extreme case that it hit the timeout that just cuts off AC power.

run.log has this act logged.

> 
> Also, any explanation on why dmesg and igt_runner log disagree on how far
> the test progressed (in terms of which subtest was active when things
> ended)?
>

Looks like a race condition with the above mentioned AC cutoff. The
test printed that vcs0 is finished and vecs0 starts, that info was
printed to igt_runner's stdout, but the write() to the test logs
didn't get called before cutoff.


-- 
Petri Latvala


> Regards,
> 
> Tvrtko
> 
> 
> > 
> > 
> > > 
> > > 2)
> > > 
> > > I915_pm_dc I'd say you just gotten unlucky that test went from always 
> > > skipping on SKL to trying to run it and then it failed. But I don't know 
> > > enough about the test to tell you why. Adding Jigar and Anshuman as test 
> > > author and reviewer who might be able to shed some light here.
> > > 
> > > Regards,
> > > 
> > > Tvrtko
> > > 
> > > > I found code that seemed to be relevant
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Add privacy-screen class and connector properties (rev4)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm: Add privacy-screen class and connector properties (rev4)
URL   : https://patchwork.freedesktop.org/series/79259/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10552_full -> Patchwork_20965_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_userptr_blits@huge-split:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-snb5/igt@gem_userptr_bl...@huge-split.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb7/igt@gem_userptr_bl...@huge-split.html

  * igt@gem_workarounds@basic-read-fd:
- shard-snb:  NOTRUN -> [TIMEOUT][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb2/igt@gem_workarou...@basic-read-fd.html

  
 Suppressed 

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

  * igt@i915_pm_rps@reset:
- {shard-rkl}:[PASS][4] -> [FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@i915_pm_...@reset.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@i915_pm_...@reset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][6] ([fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@feature_discov...@chamelium.html

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

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][9] ([i915#3354])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +155 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-apl:  [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar 
issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/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_20965/shard-apl2/igt@gem_pr...@exhaustion.html
- shard-snb:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb6/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN 

Re: [Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug

2021-09-06 Thread Tvrtko Ursulin



On 03/09/2021 22:57, jim.cro...@gmail.com wrote:

On Fri, Sep 3, 2021 at 5:15 AM Tvrtko Ursulin
 wrote:



On 31/08/2021 21:21, Jim Cromie wrote:

drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names).  There are thousands of these callsites, each
categorized in this systematized way.

These callsites can be enabled at runtime by their category, each
controlled by a bit in drm.debug (/sys/modules/drm/parameter/debug).
In the current "basic" implementation, drm_debug_enabled() tests these
bits in __drm_debug each time an API[1] call is executed; while cheap
individually, the costs accumulate with uptime.

This patch uses dynamic-debug with jump-label to patch enabled calls
onto their respective NOOP slots, avoiding all runtime bit-checks of
__drm_debug by drm_debug_enabled().

Dynamic debug has no concept of category, but we can emulate one by
replacing enum categories with a set of prefix-strings; "drm:core:",
"drm:kms:" "drm:driver:" etc, and prepend them (at compile time) to
the given formats.

Then we can use:
`echo module drm format "^drm:core: " +p > control`

to enable the whole category with one query.


Probably stupid question - enabling stuff at boot time still works as
described in Documentation/admin-guide/dynamic-debug-howto.rst?



yes.  its turned on in earlyinit, and cmdline args are a processed then,
and when modules are added



Second question, which perhaps has been covered in the past so apologies
if redundant - what is the advantage of allowing this to be
configurable, versus perhaps always enabling it? Like what would be the
reasons someone wouldn't just want to have CONFIG_DYNAMIC_DEBUG compiled
in? Kernel binary size?



Im unaware of anything on this topic, but I can opine :-)
Its been configurable since I saw it and thought "jump-labels are cool!"

code is small
[jimc@frodo local-i915m]$ size lib/dynamic_debug.o
textdata bss dec hex filename
   240168041  64   321217d79 lib/dynamic_debug.o

Its data tables are big, particularly the __dyndbg section
builtins:
dyndbg: 108 debug prints in module mptcp
dyndbg:   2 debug prints in module i386
dyndbg:   2 debug prints in module xen
dyndbg:   2 debug prints in module fixup
dyndbg:   7 debug prints in module irq
dyndbg: 3039 prdebugs in 283 modules, 11 KiB in ddebug tables, 166 kiB
in __dyndbg section

bash-5.1#
bash-5.1# for m in i915 amdgpu ; do modprobe $m dyndbg=+_ ; done
dyndbg: 384 debug prints in module drm
dyndbg: 211 debug prints in module drm_kms_helper
dyndbg:   2 debug prints in module ttm
dyndbg:   8 debug prints in module video
dyndbg: 1727 debug prints in module i915
dyndbg: processed 1 queries, with 3852 matches, 0 errs
dyndbg: 3852 debug prints in module amdgpu
[drm] amdgpu kernel modesetting enabled.
amdgpu: CRAT table disabled by module option
amdgpu: Virtual CRAT table created for CPU
amdgpu: Topology: Add CPU node
bash-5.1#

At 56 bytes / callsite, it adds up.
And teaching DRM to use it enlarges its use dramatically,
not just in drm itself, but in many drivers

amdgpu has 3852 callsite, (vs 3039 in my kernel), so it has ~240kb.
It has extra (large chunks generated by macros) to trim,
but i915 has ~1700, and drm has ~380

I have WIP to reduce the table space, by splitting it into 2 separate ones;
guts and decorations (module, function, file pointers).
The decoration recs are redundant, 45% are copies of previous
(function changes fastest)
It needs much rework, but it should get 20% overall.
decorations are 24/56 of footprint.


I'll try to extract the "executive summary" from this, you tell me if I 
got it right.


So using or not using dynamic debug for DRM debug ends up being about 
shifting the cost between kernel binary size (data section grows by each 
pr_debug call site) and runtime conditionals?


Since the table sizes you mention seem significant enough, I think that 
justifies existence of DRM_USE_DYNAMIC_DEBUG. It would probably be a 
good idea to put some commentary on that there. Ideally including some 
rough estimates both including space cost per call site and space cost 
for a typical distro kernel build?


Regards,

Tvrtko


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: fixup igt_shrink_thp (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: fixup igt_shrink_thp (rev2)
URL   : https://patchwork.freedesktop.org/series/93128/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10552 -> Patchwork_20966


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-tgl-y:   NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +9 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/fi-tgl-y/igt@amdgpu/amd_cs_...@nop-compute0.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#3921])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [FAIL][5] ([i915#1888]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][7] ([i915#1993]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [DMESG-WARN][9] ([i915#3958]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20966/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.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#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (46 -> 38)
--

  Missing(8): bat-adls-5 bat-dg1-6 fi-bsw-n3050 bat-dg1-5 fi-bsw-cyan 
bat-adlp-4 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10552 -> Patchwork_20966

  CI-20190529: 20190529
  CI_DRM_10552: 931230aae7f70bb270bb3a50b160a765699f87c2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20966: c703d855f95d0bfc6c328cb7ae88c480e1ee2a98 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c703d855f95d drm/i915/selftests: fixup igt_shrink_thp

== Logs ==

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


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)

2021-09-06 Thread Tvrtko Ursulin



On 03/09/2021 14:01, Petri Latvala wrote:

On Fri, Sep 03, 2021 at 12:29:51PM +0100, Tvrtko Ursulin wrote:


On 03/09/2021 01:31, jim.cro...@gmail.com wrote:



On Tue, Aug 31, 2021 at 5:38 PM Patchwork
mailto:patchw...@emeril.freedesktop.org>> wrote:

 __
 *Patch Details*
 *Series:*  use DYNAMIC_DEBUG to implement DRM.debug (rev2)
 *URL:* https://patchwork.freedesktop.org/series/93914/
 
 *State:*   failure
 *Details:*
 https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.html
 


   CI Bug Log - changes from CI_DRM_10541_full -> Patchwork_20931_full


 Summary

 *FAILURE*

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

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_20931_full, please notify your bug team to
 allow them
 to document this new failure mode, which will reduce false positives
 in CI.


hi Team !

I think I need a bit of orientation.


 Possible new issues

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


   IGT changes


 Possible regressions

   * igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
   o shard-skl: NOTRUN -> INCOMPLETE
 



 Warnings

   * igt@i915_pm_dc@dc9-dpms:
   o shard-skl: SKIP
 

 ([fdo#109271]) -> FAIL
 




Im assuming the FAIL is the sticking point,


Both INCOMPLETE and FAIL will cause a failure to be declared, but in this case 
it looks to me this series is not at fault.

1)

The gem_exec_schedule failure looks like a test runner timeout issue (and 
apparently test does not handle well running the the fence timeout enabled).

@Petri - does the below look like IGT runner running our of time budget for the 
test run? Would it log

[1051.943629] [114/138] ( 11s left) gem_exec_schedule (u-submit-golden-slice)
Starting subtest: u-submit-golden-slice
Starting dynamic subtest: rcs0
Dynamic subtest rcs0: SUCCESS (80.175s)
Starting dynamic subtest: bcs0
Dynamic subtest bcs0: SUCCESS (80.195s)
Starting dynamic subtest: vcs0
Dynamic subtest vcs0: SUCCESS (80.243s)
Starting dynamic subtest: vecs0

Interesting part is that according to dmesg it never got to the vecs0 dynamic 
subtest - any idea what happened there?


Yep, we ran out of time. We still had 11 seconds left to execute
something but then that test took centuries.


Okay at least that's explained then.

Perhaps could make that act of termination logged in igt_runner log?

Also, any explanation on why dmesg and igt_runner log disagree on how 
far the test progressed (in terms of which subtest was active when 
things ended)?


Regards,

Tvrtko







2)

I915_pm_dc I'd say you just gotten unlucky that test went from always skipping 
on SKL to trying to run it and then it failed. But I don't know enough about 
the test to tell you why. Adding Jigar and Anshuman as test author and reviewer 
who might be able to shed some light here.

Regards,

Tvrtko


I found code that seemed to be relevant

[jimc@frodo igt-ci-tags.git]$ git remote -v
origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
 (fetch)
origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
 (push)

I built it, got an error, threw that to google,
found a patch on i-g-t from
commit 1ff3e5ae99ceb66d2926d58635d0379ce971065a (HEAD -> master)
Author: Lyude Paul mailto:ly...@redhat.com>>
Date:   Mon Apr 15 14:57:23 2019 -0400

and applied it
it fixed the one problem

then I looked at previous head

commit f052e49a43cc9704ea5f240df15dd9d3dfed68ab (origin/master, origin/HEAD)
Author: Simon Ser mailto:simon@intel.com>>
Date:   Wed Apr 24 19:15:26 2019 +0300

It sure seems that tree is stale.


That tree's master ref does not get updated. It's only for storing tags.

That test result comparison was too long to fit into patchwork so the
build information at the bottom is missing, but the BAT results have
it:

IGT_6193: 080869f804cb86b25a38889e5ce9a870571cd8c4 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git





Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

2021-09-06 Thread Gwan-gyeong Mun

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 9/4/21 3:26 AM, Souza, Jose wrote:

On Fri, 2021-09-03 at 22:09 +, Souza, Jose wrote:

On Thu, 2021-09-02 at 21:42 +0300, Gwan-gyeong Mun wrote:


On 8/25/21 3:58 AM, José Roberto de Souza wrote:

By now all the userspace applications should have migrated to atomic
or at least be calling DRM_IOCTL_MODE_DIRTYFB.

With that we can kill frontbuffer rendering support in i915 for
modern platforms.

So here converting legacy APIs into atomic commits so it can be
properly handled by driver i915.

Several IGT tests will fail with this changes, because some tests
were stressing those frontbuffer rendering scenarios that no userspace
should be using by now, fixes to IGT should be sent soon.

v2:
- return earlier to not set fb_tracking.busy/flip_bits
- added a warn on to make sure we are not setting the busy/flip_bits

Cc: Daniel Vetter 
Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
   drivers/gpu/drm/i915/display/intel_cursor.c|  6 ++
   drivers/gpu/drm/i915/display/intel_fb.c|  8 +++-
   .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++
   drivers/gpu/drm/i915/i915_drv.h|  2 ++
   4 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index c7618fef01439..5aa996c3b7980 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
  u32 src_w, u32 src_h,
  struct drm_modeset_acquire_ctx *ctx)
   {
+struct drm_i915_private *i915 = to_i915(_crtc->dev);
   struct intel_plane *plane = to_intel_plane(_plane);
   struct intel_crtc *crtc = to_intel_crtc(_crtc);
   struct intel_plane_state *old_plane_state =
@@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
* PSR2 selective fetch also requires the slow path as
* PSR2 plane and transcoder registers can only be updated during
* vblank.
- *
- * FIXME bigjoiner fastpath would be good
*/
   if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
-crtc_state->update_pipe || crtc_state->bigjoiner ||
-crtc_state->enable_psr2_sel_fetch)
+crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
   goto slow;

   /*
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index e4b8602ec0cd2..3eb60785c9f29 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/

+#include 
   #include 
   #include 

@@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct 
drm_framebuffer *fb,
   unsigned int num_clips)
   {
   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+struct drm_i915_private *i915 = to_i915(obj->base.dev);

   i915_gem_object_flush_if_display(obj);
-intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);

+if (!HAS_FRONTBUFFER_RENDERING(i915))
+return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+ num_clips);

Hi,
Even if the userspace informs us of the dirty (damage) region of the
front buffer being used, GEN9 to GEN12 still uses the HW Tracking
function for PSR and FBC.
And if you look at the description of the intel_psr_flush() function,
you can see that there are the following restrictions.

"Since the hardware frontbuffer tracking has gaps we need to integrate
with the software frontbuffer tracking."

If this restriction is still valid from GEN9 to GEN12, even if the
existing frontbuffer tracking function is not used, when
intel_user_framebuffer_dirty() is called, in the case of PSR,
psr_force_hw_tracking_exit() is called or intel_psr_exit() and
schedule_work(psr.work) seems to be required.


As this will trigger calls to the functions that write the plane registers PSR 
HW tracking and FBC tracking will understand a page flip happened even
if going from and to the same surface.

But will double check it.


Yep, no issues with PSR or FBC. HW understand as a flip and it is properly 
handled.





In the case of FBC, it seems that calls to FBC deactive / FBC activate
should be added.

If GEN9 to GEN12 do not have the above restrictions, please ignore this
comment.

G.G.

+
+intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
   return 0;
   }

diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 0492446cd04ad..3860f87dac31c 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -112,6 +112,9 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
   void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
   unsigned frontbuffer_bits)
   {
+if 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_s: Remove require_force_probe protection

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adl_s: Remove require_force_probe protection
URL   : https://patchwork.freedesktop.org/series/94338/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550_full -> Patchwork_20955_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb6/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-iclb3/igt@feature_discov...@display-2x.html

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

  * igt@gem_ctx_persistence@engines-hostile-preempt:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb7/igt@gem_ctx_persiste...@engines-hostile-preempt.html

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> ([SKIP][5], [SKIP][6]) ([fdo#109271] / 
[i915#1099])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hostile.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_ctx_shared@q-in-order:
- shard-snb:  NOTRUN -> ([SKIP][7], [SKIP][8]) ([fdo#109271]) +142 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb6/igt@gem_ctx_sha...@q-in-order.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-snb7/igt@gem_ctx_sha...@q-in-order.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][9] -> ([TIMEOUT][10], [TIMEOUT][11]) 
([i915#2369] / [i915#3063] / [i915#3648])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb8/igt@gem_...@unwedge-stress.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb1/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][12] -> ([FAIL][13], [PASS][14]) ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-glk2/igt@gem_exec_f...@basic-deadline.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-glk7/igt@gem_exec_f...@basic-deadline.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-glk2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][15] -> ([FAIL][16], [FAIL][17]) ([i915#2842]) 
+2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][19] -> ([PASS][20], [FAIL][21]) ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][22] -> ([FAIL][23], [FAIL][24]) ([i915#2842])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][25] -> ([FAIL][26], [PASS][27]) ([i915#2842]) 
+1 similar issue
   [25]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: fixup igt_shrink_thp (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: fixup igt_shrink_thp (rev2)
URL   : https://patchwork.freedesktop.org/series/93128/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c703d855f95d drm/i915/selftests: fixup igt_shrink_thp
-:52: CHECK:LINE_SPACING: Please don't use multiple blank lines
#52: FILE: drivers/gpu/drm/i915/gem/selftests/huge_pages.c:1584:
 
+

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




Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate

2021-09-06 Thread Gwan-gyeong Mun

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 9/4/21 1:10 AM, José Roberto de Souza wrote:

Both functions are pretty much equal, with minor changes that can be
handled by a single parameter.

v3:
- not scheduling work from invalidate operations

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_drrs.c | 82 +--
  1 file changed, 32 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index fa0411341a0da..15e5f91cf331d 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -299,18 +299,9 @@ static void intel_drrs_downclock_work(struct work_struct 
*work)
mutex_unlock(_priv->drrs.mutex);
  }
  
-/**

- * intel_drrs_invalidate - Disable Idleness DRRS
- * @dev_priv: i915 device
- * @frontbuffer_bits: frontbuffer plane tracking bits
- *
- * This function gets called everytime rendering on the given planes start.
- * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
- *
- * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
- */
-void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
-  unsigned int frontbuffer_bits)
+static void intel_drrs_frontbuffer_update(struct drm_i915_private *dev_priv,
+ unsigned int frontbuffer_bits,
+ bool invalidate)
  {
struct intel_dp *intel_dp;
struct drm_crtc *crtc;
@@ -333,16 +324,42 @@ void intel_drrs_invalidate(struct drm_i915_private 
*dev_priv,
pipe = to_intel_crtc(crtc)->pipe;
  
  	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);

-   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   if (invalidate)
+   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   else
+   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
  
-	/* invalidate means busy screen hence upclock */

+   /* flush/invalidate means busy screen hence upclock */
if (frontbuffer_bits)
intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
 DRRS_HIGH_RR);
  
+	/*

+* flush also means no more activity hence schedule downclock, if all
+* other fbs are quiescent too
+*/
+   if (!invalidate && !dev_priv->drrs.busy_frontbuffer_bits)
+   schedule_delayed_work(_priv->drrs.work,
+ msecs_to_jiffies(1000));
mutex_unlock(_priv->drrs.mutex);
  }
  
+/**

+ * intel_drrs_invalidate - Disable Idleness DRRS
+ * @dev_priv: i915 device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * This function gets called everytime rendering on the given planes start.
+ * Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR).
+ *
+ * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
+ */
+void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
+  unsigned int frontbuffer_bits)
+{
+   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, true);
+}
+
  /**
   * intel_drrs_flush - Restart Idleness DRRS
   * @dev_priv: i915 device
@@ -358,42 +375,7 @@ void intel_drrs_invalidate(struct drm_i915_private 
*dev_priv,
  void intel_drrs_flush(struct drm_i915_private *dev_priv,
  unsigned int frontbuffer_bits)
  {
-   struct intel_dp *intel_dp;
-   struct drm_crtc *crtc;
-   enum pipe pipe;
-
-   if (dev_priv->drrs.type == DRRS_NOT_SUPPORTED)
-   return;
-
-   cancel_delayed_work(_priv->drrs.work);
-
-   mutex_lock(_priv->drrs.mutex);
-
-   intel_dp = dev_priv->drrs.dp;
-   if (!intel_dp) {
-   mutex_unlock(_priv->drrs.mutex);
-   return;
-   }
-
-   crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
-   pipe = to_intel_crtc(crtc)->pipe;
-
-   frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
-   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
-
-   /* flush means busy screen hence upclock */
-   if (frontbuffer_bits)
-   intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
-DRRS_HIGH_RR);
-
-   /*
-* flush also means no more activity hence schedule downclock, if all
-* other fbs are quiescent too
-*/
-   if (!dev_priv->drrs.busy_frontbuffer_bits)
-   schedule_delayed_work(_priv->drrs.work,
- msecs_to_jiffies(1000));
-   mutex_unlock(_priv->drrs.mutex);
+   intel_drrs_frontbuffer_update(dev_priv, frontbuffer_bits, false);
  }
  
  /**




[Intel-gfx] [PATCH] drm/i915/selftests: fixup igt_shrink_thp

2021-09-06 Thread Matthew Auld
Since the object might still be active here, the shrink_all will simply
ignore it, which blows up in the test, since the pages will still be
there. Currently THP is disabled which should result in the test being
skipped, but if we ever re-enable THP we might start seeing the failure.
Fix this by forcing I915_SHRINK_ACTIVE.

v2: Some machine in the shard runs doesn't seem to have any available
swap when running this test. Try to handle this.

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin  #v1
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   | 31 ++-
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index a094f3ce1a90..46ea1997c114 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1519,6 +1519,7 @@ static int igt_shrink_thp(void *arg)
struct i915_vma *vma;
unsigned int flags = PIN_USER;
unsigned int n;
+   bool should_swap;
int err = 0;
 
/*
@@ -1567,23 +1568,39 @@ static int igt_shrink_thp(void *arg)
break;
}
i915_gem_context_unlock_engines(ctx);
+   /*
+* Nuke everything *before* we unpin the pages so we can be reasonably
+* sure that when later checking get_nr_swap_pages() that some random
+* leftover object doesn't steal the remaining swap space.
+*/
+   i915_gem_shrink(NULL, i915, -1UL, NULL,
+   I915_SHRINK_BOUND |
+   I915_SHRINK_UNBOUND |
+   I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
goto out_put;
 
+
/*
-* Now that the pages are *unpinned* shrink-all should invoke
-* shmem to truncate our pages.
+* Now that the pages are *unpinned* shrinking should invoke
+* shmem to truncate our pages, if we have available swap.
 */
-   i915_gem_shrink_all(i915);
-   if (i915_gem_object_has_pages(obj)) {
-   pr_err("shrink-all didn't truncate the pages\n");
+   should_swap = get_nr_swap_pages() > 0;
+   i915_gem_shrink(NULL, i915, -1UL, NULL,
+   I915_SHRINK_BOUND |
+   I915_SHRINK_UNBOUND |
+   I915_SHRINK_ACTIVE);
+   if (should_swap == i915_gem_object_has_pages(obj)) {
+   pr_err("unexpected pages mismatch, should_swap=%s\n",
+  yesno(should_swap));
err = -EINVAL;
goto out_put;
}
 
-   if (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys) {
-   pr_err("residual page-size bits left\n");
+   if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
+   pr_err("unexpected residual page-size bits, should_swap=%s\n",
+  yesno(should_swap));
err = -EINVAL;
goto out_put;
}
-- 
2.26.3



[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add privacy-screen class and connector properties (rev4)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm: Add privacy-screen class and connector properties (rev4)
URL   : https://patchwork.freedesktop.org/series/79259/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10552 -> Patchwork_20965


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#3921])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050:   [PASS][5] -> [DMESG-FAIL][6] ([i915#2927] / 
[i915#3428])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#2203] / 
[i915#2868])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@runner@aborted:
- fi-bsw-n3050:   NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#1436] / 
[i915#3428])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [FAIL][10] ([i915#1888]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][12] ([i915#1993]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [DMESG-WARN][14] ([i915#3958]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958


Participating hosts (46 -> 37)
--

  Missing(9): fi-kbl-soraka bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan 
bat-adlp-4 fi-kbl-guc fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10552 -> Patchwork_20965

  CI-20190529: 20190529
  CI_DRM_10552: 931230aae7f70bb270bb3a50b160a765699f87c2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20965: ff55a0aefb5373fb248923443c4b42003c5e3f6d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ff55a0aefb53 drm/i915: Add privacy-screen support
d68628f78bef platform/x86: thinkpad_acpi: Register a privacy-screen device
4493056b11ea platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI 
handles only once

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Some code improvements and code style fixes for DRRS

2021-09-06 Thread Gwan-gyeong Mun

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 9/4/21 1:10 AM, José Roberto de Souza wrote:

It started as a code style fix for the lines above 100 col but it
turned out to simplifications to intel_drrs_set_state().
Now it receives the desired refresh rate type, high or low.

v3:
- Fixed the mode refesh rate debug message

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_drrs.c | 58 ---
  1 file changed, 20 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index a2b65eca14418..fa0411341a0da 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -89,19 +89,13 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
  
  static void intel_drrs_set_state(struct drm_i915_private *dev_priv,

 const struct intel_crtc_state *crtc_state,
-int refresh_rate)
+enum drrs_refresh_rate_type refresh_type)
  {
struct intel_dp *intel_dp = dev_priv->drrs.dp;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
+   struct drm_display_mode *mode;
  
-	if (refresh_rate <= 0) {

-   drm_dbg_kms(_priv->drm,
-   "Refresh rate should be positive non-zero.\n");
-   return;
-   }
-
-   if (intel_dp == NULL) {
+   if (!intel_dp) {
drm_dbg_kms(_priv->drm, "DRRS not supported.\n");
return;
}
@@ -117,15 +111,8 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
return;
}
  
-	if (drm_mode_vrefresh(intel_dp->attached_connector->panel.downclock_mode) ==

-   refresh_rate)
-   index = DRRS_LOW_RR;
-
-   if (index == dev_priv->drrs.refresh_rate_type) {
-   drm_dbg_kms(_priv->drm,
-   "DRRS requested for previously set 
RR...ignoring\n");
+   if (refresh_type == dev_priv->drrs.refresh_rate_type)
return;
-   }
  
  	if (!crtc_state->hw.active) {

drm_dbg_kms(_priv->drm,
@@ -134,7 +121,7 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
}
  
  	if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {

-   switch (index) {
+   switch (refresh_type) {
case DRRS_HIGH_RR:
intel_dp_set_m_n(crtc_state, M1_N1);
break;
@@ -151,7 +138,7 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
u32 val;
  
  		val = intel_de_read(dev_priv, reg);

-   if (index > DRRS_HIGH_RR) {
+   if (refresh_type == DRRS_LOW_RR) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
else
@@ -165,10 +152,14 @@ static void intel_drrs_set_state(struct drm_i915_private 
*dev_priv,
intel_de_write(dev_priv, reg, val);
}
  
-	dev_priv->drrs.refresh_rate_type = index;

+   dev_priv->drrs.refresh_rate_type = refresh_type;
  
+	if (refresh_type == DRRS_LOW_RR)

+   mode = intel_dp->attached_connector->panel.downclock_mode;
+   else
+   mode = intel_dp->attached_connector->panel.fixed_mode;
drm_dbg_kms(_priv->drm, "eDP Refresh Rate set to : %dHz\n",
-   refresh_rate);
+   drm_mode_vrefresh(mode));
  }
  
  static void

@@ -216,13 +207,7 @@ intel_drrs_disable_locked(struct intel_dp *intel_dp,
  {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
  
-	if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {

-   int refresh;
-
-   refresh = 
drm_mode_vrefresh(intel_dp->attached_connector->panel.fixed_mode);
-   intel_drrs_set_state(dev_priv, crtc_state, refresh);
-   }
-
+   intel_drrs_set_state(dev_priv, crtc_state, DRRS_HIGH_RR);
dev_priv->drrs.dp = NULL;
  }
  
@@ -290,6 +275,7 @@ static void intel_drrs_downclock_work(struct work_struct *work)

struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), drrs.work.work);
struct intel_dp *intel_dp;
+   struct drm_crtc *crtc;
  
  	mutex_lock(_priv->drrs.mutex);
  
@@ -306,12 +292,8 @@ static void intel_drrs_downclock_work(struct work_struct *work)

if (dev_priv->drrs.busy_frontbuffer_bits)
goto unlock;
  
-	if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR) {

-   struct drm_crtc *crtc = 
dp_to_dig_port(intel_dp)->base.base.crtc;
-
-   intel_drrs_set_state(dev_priv, to_intel_crtc(crtc)->config,
-

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm

2021-09-06 Thread Daniel Vetter
On Fri, Sep 03, 2021 at 09:05:00AM +0100, Tvrtko Ursulin wrote:
> 
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > The important part isn't so much that this does an rcu lookup - that's
> > more an implementation detail, which will also be removed.
> > 
> > The thing that makes this different from other functions is that it's
> > gettting you the vm that batchbuffers will run in for that gem
> > context, which is either a full ppgtt stored in gem->ctx, or the ggtt.
> > 
> > We'll make more use of this function later on.
> > 
> > Reviewed-by: Maarten Lankhorst 
> > Signed-off-by: Daniel Vetter 
> > Cc: Jon Bloomfield 
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Joonas Lahtinen 
> > Cc: Daniel Vetter 
> > Cc: "Thomas Hellström" 
> > Cc: Matthew Auld 
> > Cc: Lionel Landwerlin 
> > Cc: Dave Airlie 
> > Cc: Jason Ekstrand 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.h   | 2 +-
> >   drivers/gpu/drm/i915/gem/selftests/huge_pages.c   | 4 ++--
> >   drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
> >   drivers/gpu/drm/i915/gt/selftest_execlists.c  | 2 +-
> >   drivers/gpu/drm/i915/gt/selftest_hangcheck.c  | 2 +-
> >   drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++--
> >   drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
> >   7 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> > index 18060536b0c2..da6e8b506d96 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> > @@ -155,7 +155,7 @@ i915_gem_context_vm(struct i915_gem_context *ctx)
> >   }
> >   static inline struct i915_address_space *
> > -i915_gem_context_get_vm_rcu(struct i915_gem_context *ctx)
> > +i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
> >   {
> > struct i915_address_space *vm;
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
> > b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> > index a094f3ce1a90..6c68fe26bb32 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> > @@ -1456,7 +1456,7 @@ static int igt_tmpfs_fallback(void *arg)
> > struct i915_gem_context *ctx = arg;
> > struct drm_i915_private *i915 = ctx->i915;
> > struct vfsmount *gemfs = i915->mm.gemfs;
> > -   struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
> > +   struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);
> > struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > u32 *vaddr;
> > @@ -1512,7 +1512,7 @@ static int igt_shrink_thp(void *arg)
> >   {
> > struct i915_gem_context *ctx = arg;
> > struct drm_i915_private *i915 = ctx->i915;
> > -   struct i915_address_space *vm = i915_gem_context_get_vm_rcu(ctx);
> > +   struct i915_address_space *vm = i915_gem_context_get_eb_vm(ctx);
> 
> Problem here (and probably elsewhere) is that this test does no "eb", nor
> even submits any requests for execution.
> 
> More so, execbuf path does currently rely on intel_context->vm which is
> always set. So I really wonder how it would look, what I touched on
> elsewhere in the thread, if we instead made ctx->vm always point to
> something. It would align the rules between intel_context and GEM context
> and may end up with a more consistent situation.

The entire thing is substantially more messy, and my few quick attempts at
fixing this went flat.

The thing is, this _is_ the vm we use for execbuf, patch 8 changes intel
context initialization to also use this function. I do think it would make
sense to always set the right vm in gem_ctx->vm, but when I tried to do
that I've also tried to implement a bit stricter rules for
intel_context->vm. Currently that's initialized to the single gt vm deep
down in the per-type (virtual vs engine ctx) code, and then later on we'd
overwrite that. My idea was that we'd no longer set the intel_context->vm
in low-level code at all, but instead the variuos callers that create the
ctx either pass the right vm down, or set it after initial setup is done.

This way we'd be guaranteed that we never accidentally run a userspace
context on the kernel's gt vm, which would be bad.

The problem was that the entire refactor became really messy, and it was
conflicting against the GuC stuff and the changed engines there, so I
figured I'll drop it. There's more locking cleanup tbd, so I'll keep that
on the list of things. Maybe once intel_context creation is a bit more
untangled.
-Daniel

> 
> Regards,
> 
> Tvrtko
> 
> > struct drm_i915_gem_object *obj;
> > struct i915_gem_engines_iter it;
> > struct intel_context *ce;
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> > index 4d2758718d21..fc7fb33a3a52 100644
> > --- 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add privacy-screen class and connector properties (rev4)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm: Add privacy-screen class and connector properties (rev4)
URL   : https://patchwork.freedesktop.org/series/79259/
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:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add privacy-screen class and connector properties (rev4)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm: Add privacy-screen class and connector properties (rev4)
URL   : https://patchwork.freedesktop.org/series/79259/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
bc1b50a446f7 drm/connector: Add support for privacy-screen properties (v4)
-:30: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-authored-by:
#30: 
Co-authored-by: Hans de Goede 

-:150: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#150: FILE: drivers/gpu/drm/drm_connector.c:2408:
+   drm_property_create_enum(connector->dev, DRM_MODE_PROP_ENUM,
+   "privacy-screen sw-state",

-:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#155: FILE: drivers/gpu/drm/drm_connector.c:2413:
+   drm_property_create_enum(connector->dev,
+   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_ENUM,

total: 0 errors, 1 warnings, 2 checks, 205 lines checked
103f4901ff19 drm: Add privacy-screen class (v3)
-:131: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#131: 
new file mode 100644

-:168: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev' - possible 
side-effects?
#168: FILE: drivers/gpu/drm/drm_privacy_screen.c:33:
+#define to_drm_privacy_screen(dev) \
+   container_of(dev, struct drm_privacy_screen, dev)

-:216: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#216: FILE: drivers/gpu/drm/drm_privacy_screen.c:81:
+static struct drm_privacy_screen *drm_privacy_screen_get_by_name(

-:417: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#417: FILE: drivers/gpu/drm/drm_privacy_screen.c:282:
+}
+/*

-:479: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#479: FILE: drivers/gpu/drm/drm_privacy_screen.c:344:
+struct drm_privacy_screen *drm_privacy_screen_register(

-:575: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#575: FILE: include/drm/drm_privacy_screen_consumer.h:33:
+}
+static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)

-:578: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#578: FILE: include/drm/drm_privacy_screen_consumer.h:36:
+}
+static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen 
*priv,

-:583: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#583: FILE: include/drm/drm_privacy_screen_consumer.h:41:
+}
+static inline void drm_privacy_screen_get_state(struct drm_privacy_screen 
*priv,

-:674: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#674: FILE: include/drm/drm_privacy_screen_driver.h:76:
+struct drm_privacy_screen *drm_privacy_screen_register(

-:721: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#721: FILE: include/drm/drm_privacy_screen_machine.h:37:
+}
+static inline void drm_privacy_screen_lookup_exit(void)

total: 0 errors, 1 warnings, 9 checks, 640 lines checked
4c5269c0a347 drm/privacy-screen: Add X86 specific arch init code
-:30: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#30: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 110 lines checked
5112840ff391 drm/privacy-screen: Add notifier support
-:122: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#122: FILE: include/drm/drm_privacy_screen_consumer.h:53:
 }
+static inline int drm_privacy_screen_register_notifier(struct 
drm_privacy_screen *priv,

-:127: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#127: FILE: include/drm/drm_privacy_screen_consumer.h:58:
+}
+static inline int drm_privacy_screen_unregister_notifier(struct 
drm_privacy_screen *priv,

total: 0 errors, 0 warnings, 2 checks, 123 lines checked
016dd07be125 drm/connector: Add a drm_connector privacy-screen helper functions
-:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#59: FILE: drivers/gpu/drm/drm_connector.c:555:
+   drm_privacy_screen_register_notifier(connector->privacy_screen,
+  >privacy_screen_notifier);

-:69: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#69: FILE: drivers/gpu/drm/drm_connector.c:593:
+   drm_privacy_screen_unregister_notifier(

-:80: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#80: FILE: drivers/gpu/drm/drm_connector.c:2461:
+static void drm_connector_update_privacy_screen_properties(

-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/drm_connector.c:2471:
+   drm_object_property_set_value(>base,
+   connector->privacy_screen_hw_state_property, hw_state);

-:93: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#93: FILE: drivers/gpu/drm/drm_connector.c:2474:
+static 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915: Mark GPU wedging on driver unregister unrecoverable (rev2)
URL   : https://patchwork.freedesktop.org/series/94247/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550_full -> Patchwork_20953_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@feature_discov...@display-2x.html

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

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb3/igt@gem_...@in-flight-contexts-10ms.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb8/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][12] ([fdo#112283])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_exec_par...@secure-non-master.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][15] ([i915#2658]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-kbl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#768])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-x-tiled.html

  * igt@gem_softpin@evict-snoop:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109312])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gem_soft...@evict-snoop.html

  * igt@gem_workarounds@suspend-resume:
- shard-skl:  [PASS][18] -> [INCOMPLETE][19] ([i915#198])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-skl7/igt@gem_workarou...@suspend-resume.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-skl6/igt@gem_workarou...@suspend-resume.html
- shard-apl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-apl6/igt@gem_workarou...@suspend-resume.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-apl2/igt@gem_workarou...@suspend-resume.html

  * igt@gen7_exec_parse@basic-allowed:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#109289])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20953/shard-iclb8/igt@gen7_exec_pa...@basic-allowed.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][23] -> [DMESG-WARN][24] ([i915#1436] / 
[i915#716])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Remove require_force_probe protection

2021-09-06 Thread Patchwork
== Series Details ==

Series: drm/i915/adl_s: Remove require_force_probe protection
URL   : https://patchwork.freedesktop.org/series/94338/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10550 -> Patchwork_20955


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [DMESG-FAIL][2] ([i915#1993]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][4] ([i915#3921]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][6] ([i915#3449]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10550/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20955/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

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


Participating hosts (45 -> 38)
--

  Missing(7): fi-rkl-11600 bat-adls-5 bat-dg1-5 fi-bsw-cyan bat-adlp-4 
fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10550 -> Patchwork_20955

  CI-20190529: 20190529
  CI_DRM_10550: 07f6ce3dba287a2aa8a62cdd3b7d46ea0676007f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20955: 61c59049f078c498c7aef94d7e2769c1e8aa5a08 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

61c59049f078 drm/i915/adl_s: Remove require_force_probe protection

== Logs ==

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


Re: [Intel-gfx] [PATCH 01/10] drm/i915: move display funcs into a display struct.

2021-09-06 Thread Jani Nikula
On Mon, 06 Sep 2021, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This is the first step in an idea to refactor the display code
> into a bit more of a corner.

So, do we want to make i915->display a pointer?

If we do, and we're about to touch every place accessing the display
struct, we might just as well have:

struct drm_i915_private {
struct drm_i915_display _display;
struct drm_i915_display *display;
};

and initialize i915->display = >_display, and make all access
happen via the pointer. If we want to allocate it dynamically at some
point, it'll be a *much* easier task.

But the first question to figure out is whether we want to do that or
not.


BR,
Jani.


>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c|  24 +--
>  drivers/gpu/drm/i915/display/intel_cdclk.c| 148 +-
>  drivers/gpu/drm/i915/display/intel_color.c|  64 
>  drivers/gpu/drm/i915/display/intel_display.c  | 110 ++---
>  .../drm/i915/display/intel_display_power.c|   2 +-
>  drivers/gpu/drm/i915/display/intel_dpll.c |  16 +-
>  drivers/gpu/drm/i915/display/intel_fdi.c  |   6 +-
>  drivers/gpu/drm/i915/display/intel_hotplug.c  |   4 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  10 +-
>  drivers/gpu/drm/i915/i915_irq.c   |  14 +-
>  drivers/gpu/drm/i915/intel_pm.c   | 104 ++--
>  11 files changed, 253 insertions(+), 249 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 532237588511..fd56191c8a68 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -848,8 +848,8 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>  
>   connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
>  
> - if (dev_priv->display.audio_codec_enable)
> - dev_priv->display.audio_codec_enable(encoder,
> + if (dev_priv->display.funcs.audio_codec_enable)
> + dev_priv->display.funcs.audio_codec_enable(encoder,
>crtc_state,
>conn_state);
>  
> @@ -893,8 +893,8 @@ void intel_audio_codec_disable(struct intel_encoder 
> *encoder,
>   enum port port = encoder->port;
>   enum pipe pipe = crtc->pipe;
>  
> - if (dev_priv->display.audio_codec_disable)
> - dev_priv->display.audio_codec_disable(encoder,
> + if (dev_priv->display.funcs.audio_codec_disable)
> + dev_priv->display.funcs.audio_codec_disable(encoder,
> old_crtc_state,
> old_conn_state);
>  
> @@ -922,17 +922,17 @@ void intel_audio_codec_disable(struct intel_encoder 
> *encoder,
>  void intel_init_audio_hooks(struct drm_i915_private *dev_priv)
>  {
>   if (IS_G4X(dev_priv)) {
> - dev_priv->display.audio_codec_enable = g4x_audio_codec_enable;
> - dev_priv->display.audio_codec_disable = g4x_audio_codec_disable;
> + dev_priv->display.funcs.audio_codec_enable = 
> g4x_audio_codec_enable;
> + dev_priv->display.funcs.audio_codec_disable = 
> g4x_audio_codec_disable;
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> - dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
> - dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
> + dev_priv->display.funcs.audio_codec_enable = 
> ilk_audio_codec_enable;
> + dev_priv->display.funcs.audio_codec_disable = 
> ilk_audio_codec_disable;
>   } else if (IS_HASWELL(dev_priv) || DISPLAY_VER(dev_priv) >= 8) {
> - dev_priv->display.audio_codec_enable = hsw_audio_codec_enable;
> - dev_priv->display.audio_codec_disable = hsw_audio_codec_disable;
> + dev_priv->display.funcs.audio_codec_enable = 
> hsw_audio_codec_enable;
> + dev_priv->display.funcs.audio_codec_disable = 
> hsw_audio_codec_disable;
>   } else if (HAS_PCH_SPLIT(dev_priv)) {
> - dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
> - dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
> + dev_priv->display.funcs.audio_codec_enable = 
> ilk_audio_codec_enable;
> + dev_priv->display.funcs.audio_codec_disable = 
> ilk_audio_codec_disable;
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 34fa4130d5c4..becbf0fc4c4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1466,7 +1466,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
> *dev_priv,
>* at least what the CDCLK frequency requires.
>*/
>   

Re: [Intel-gfx] [PATCH] drm/i915/audio: Use BIOS provided value for RKL HDA link

2021-09-06 Thread Kai Vehmanen
Hi,

On Mon, 6 Sep 2021, Kai-Heng Feng wrote:

> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
> driver") makes HDMI audio on Lenovo P350 disappear.
> 
> So in addition to TGL, extend the logic to RKL to use BIOS provided
> value to fix the regression.

thanks Kai-Heng! We were not aware of commercial RKL systems following the
old BIOS guidance, but given you just hit one, then this definitely is
needed:

Reviewed-by: Kai Vehmanen   

Br, Kai


[Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support

2021-09-06 Thread Hans de Goede
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.

One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:

for_each_new_connector_in_state(>base, connector, ...
drm_connector_update_privacy_screen(connector, state);

It may seem more logical to instead take care of updating the
privacy-screen state by marking the crtc as needing a modeset and then
do this in both the encoder update_pipe (for fast-sets) and enable
(for full modesets) callbacks. But ATM these callbacks only get passed
the new connector_state and these callbacks are all called after
drm_atomic_helper_swap_state() at which point there is no way to get
the old state from the new state.

Without access to the old state, we do not know if the sw_state of
the privacy-screen has changes so we would need to call
drm_privacy_screen_set_sw_state() unconditionally. This is undesirable
since all current known privacy-screen providers use ACPI calls which
are somewhat expensive to make.

Also, as all providers use ACPI calls, rather then poking GPU registers,
there is no need to order this together with other encoder operations.
Since no GPU poking is involved having this as a separate step of the
commit process actually is the logical thing to do.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_display.c |  5 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 10 ++
 drivers/gpu/drm/i915/i915_pci.c  | 12 
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5560d2f4c352..7285873d329a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10140,6 +10140,8 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
struct drm_device *dev = state->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
+   struct drm_connector_state *new_connector_state;
+   struct drm_connector *connector;
struct intel_crtc *crtc;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
@@ -10237,6 +10239,9 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_color_load_luts(new_crtc_state);
}
 
+   for_each_new_connector_in_state(>base, connector, 
new_connector_state, i)
+   drm_connector_update_privacy_screen(connector, >base);
+
/*
 * Now that the vblank has passed, we can go ahead and program the
 * optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7f8e8865048f..3aa2072cccf6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "g4x_dp.h"
@@ -5217,6 +5218,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
struct drm_connector *connector = _connector->base;
struct drm_display_mode *fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
+   struct drm_privacy_screen *privacy_screen;
bool has_dpcd;
enum pipe pipe = INVALID_PIPE;
struct edid *edid;
@@ -5308,6 +5310,14 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
fixed_mode->hdisplay, fixed_mode->vdisplay);
}
 
+   privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
+   if (!IS_ERR(privacy_screen)) {
+   drm_connector_attach_privacy_screen_provider(connector,
+privacy_screen);
+   } else if (PTR_ERR(privacy_screen) != -ENODEV) {
+   drm_warn(_priv->drm, "Error getting privacy-screen\n");
+   }
+
return true;
 
 out_vdd_off:
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 146f7e39182a..d6913f567a1c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -25,6 +25,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "i915_drv.h"
@@ -1167,6 +1168,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 {
struct intel_device_info *intel_info =
(struct intel_device_info *) ent->driver_data;
+   struct drm_privacy_screen *privacy_screen;
int err;
 
if (intel_info->require_force_probe &&
@@ -1195,7 +1197,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
+   /*
+* We 

[Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device

2021-09-06 Thread Hans de Goede
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.

Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is news standardized
interface which all user-space code should use to query and control
the privacy-screen.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
  lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
  when the state is changed by pressing the Fn + D hotkey combo
---
 drivers/platform/x86/Kconfig |  2 +
 drivers/platform/x86/thinkpad_acpi.c | 91 
 2 files changed, 68 insertions(+), 25 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index d12db6c316ea..ae00a27f9f95 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -509,7 +509,9 @@ config THINKPAD_ACPI
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
depends on I2C
+   depends on DRM
select ACPI_PLATFORM_PROFILE
+   select DRM_PRIVACY_SCREEN
select HWMON
select NVRAM
select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index b8f2556c4797..044b238730ba 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dual_accel_detect.h"
 
 /* ThinkPad CMOS commands */
@@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP   = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+   TP_HKEY_EV_PRIVACYGUARD_TOGGLE  = 0x130f, /* Toggle priv.guard on/off */
 
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK   = 0x2304, /* undock requested, S3 */
@@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
 {
unsigned int scancode;
 
+   switch (hkey) {
+   case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+   tpacpi_driver_event(hkey);
+   return true;
+   }
+
/* Extended keycodes start at 0x300 and our offset into the map
 * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
 * will be positive, but might not be in the correct range.
@@ -9819,30 +9827,40 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static struct drm_privacy_screen *lcdshadow_dev;
 static acpi_handle lcdshadow_get_handle;
 static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
 
-static int lcdshadow_on_off(bool state)
+static int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status state)
 {
int output;
 
+   if (WARN_ON(!mutex_is_locked(>lock)))
+   return -EIO;
+
if (!acpi_evalf(lcdshadow_set_handle, , NULL, "dd", (int)state))
return -EIO;
 
-   lcdshadow_state = state;
+   priv->hw_state = priv->sw_state = state;
return 0;
 }
 
-static int lcdshadow_set(bool on)
+static void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
 {
-   if (lcdshadow_state < 0)
-   return lcdshadow_state;
-   if (lcdshadow_state == on)
-   return 0;
-   return lcdshadow_on_off(on);
+   int output;
+
+   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
+   return;
+
+   priv->hw_state = priv->sw_state = output & 0x1;
 }
 
+static const struct drm_privacy_screen_ops lcdshadow_ops = {
+   .set_sw_state = lcdshadow_set_sw_state,
+   .get_hw_state = lcdshadow_get_hw_state,
+};
+
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
acpi_status status1, status2;
@@ -9850,36 +9868,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct 
*iibm)
 
status1 = acpi_get_handle(hkey_handle, "GSSS", _get_handle);
status2 = acpi_get_handle(hkey_handle, "", _set_handle);
-   if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
-   lcdshadow_state = -ENODEV;
+   if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
return 0;
-   }
 
-   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0)) {
-   lcdshadow_state = -EIO;
+   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
return 

[Intel-gfx] [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once

2021-09-06 Thread Hans de Goede
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/thinkpad_acpi.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 83c88a8ebaf2..b8f2556c4797 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9819,19 +9819,15 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
 static int lcdshadow_state;
 
 static int lcdshadow_on_off(bool state)
 {
-   acpi_handle set_shadow_handle;
int output;
 
-   if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "", 
_shadow_handle))) {
-   pr_warn("Thinkpad ACPI has no %s interface.\n", "");
-   return -EIO;
-   }
-
-   if (!acpi_evalf(set_shadow_handle, , NULL, "dd", (int)state))
+   if (!acpi_evalf(lcdshadow_set_handle, , NULL, "dd", (int)state))
return -EIO;
 
lcdshadow_state = state;
@@ -9849,15 +9845,17 @@ static int lcdshadow_set(bool on)
 
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
-   acpi_handle get_shadow_handle;
+   acpi_status status1, status2;
int output;
 
-   if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS", 
_shadow_handle))) {
+   status1 = acpi_get_handle(hkey_handle, "GSSS", _get_handle);
+   status2 = acpi_get_handle(hkey_handle, "", _set_handle);
+   if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
lcdshadow_state = -ENODEV;
return 0;
}
 
-   if (!acpi_evalf(get_shadow_handle, , NULL, "dd", 0)) {
+   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0)) {
lcdshadow_state = -EIO;
return -EIO;
}
-- 
2.31.1



[Intel-gfx] [PATCH 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper

2021-09-06 Thread Hans de Goede
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.

This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/thinkpad_acpi.c | 30 ++--
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 50ff04c84650..83c88a8ebaf2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3885,6 +3885,24 @@ static bool 
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
 }
 
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+   unsigned int scancode;
+
+   /* Extended keycodes start at 0x300 and our offset into the map
+* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+* will be positive, but might not be in the correct range.
+*/
+   scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+   if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+   scancode < TPACPI_HOTKEY_MAP_LEN) {
+   tpacpi_input_send_key(scancode);
+   return true;
+   }
+
+   return false;
+}
+
 static bool hotkey_notify_hotkey(const u32 hkey,
 bool *send_acpi_ev,
 bool *ignore_acpi_ev)
@@ -3919,17 +3937,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
 
case 3:
-   /* Extended keycodes start at 0x300 and our offset into the map
-* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
-* will be positive, but might not be in the correct range.
-*/
-   scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
-   if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
-   scancode < TPACPI_HOTKEY_MAP_LEN) {
-   tpacpi_input_send_key(scancode);
-   return true;
-   }
-   break;
+   return hotkey_notify_extended_hotkey(hkey);
}
 
return false;
-- 
2.31.1



[Intel-gfx] [PATCH 5/9] drm/connector: Add a drm_connector privacy-screen helper functions

2021-09-06 Thread Hans de Goede
Add 2 drm_connector privacy-screen helper functions:

1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.

2. drm_connector_update_privacy_screen(), Check if the passed in atomic
state contains a privacy-screen sw_state change for the connector and if
it does, call drm_privacy_screen_set_sw_state() with the new sw_state.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c | 113 
 include/drm/drm_connector.h |  12 
 2 files changed, 125 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd1ca68881ba..8af678652e69 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -462,6 +464,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
 
+   if (connector->privacy_screen) {
+   drm_privacy_screen_put(connector->privacy_screen);
+   connector->privacy_screen = NULL;
+   }
+
if (connector->tile_group) {
drm_mode_put_tile_group(dev, connector->tile_group);
connector->tile_group = NULL;
@@ -543,6 +550,10 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
 
+   if (connector->privacy_screen)
+   drm_privacy_screen_register_notifier(connector->privacy_screen,
+  >privacy_screen_notifier);
+
mutex_lock(_list_lock);
list_add_tail(>global_connector_list_entry, _list);
mutex_unlock(_list_lock);
@@ -578,6 +589,11 @@ void drm_connector_unregister(struct drm_connector 
*connector)
list_del_init(>global_connector_list_entry);
mutex_unlock(_list_lock);
 
+   if (connector->privacy_screen)
+   drm_privacy_screen_unregister_notifier(
+   connector->privacy_screen,
+   >privacy_screen_notifier);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
 
@@ -2442,6 +2458,103 @@ drm_connector_attach_privacy_screen_properties(struct 
drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
 
+static void drm_connector_update_privacy_screen_properties(
+   struct drm_connector *connector)
+{
+   enum drm_privacy_screen_status sw_state, hw_state;
+
+   drm_privacy_screen_get_state(connector->privacy_screen,
+_state, _state);
+
+   connector->state->privacy_screen_sw_state = sw_state;
+   drm_object_property_set_value(>base,
+   connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+   struct notifier_block *nb, unsigned long action, void *data)
+{
+   struct drm_connector *connector =
+   container_of(nb, struct drm_connector, privacy_screen_notifier);
+   struct drm_device *dev = connector->dev;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   drm_connector_update_privacy_screen_properties(connector);
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   drm_sysfs_connector_status_event(connector,
+   connector->privacy_screen_sw_state_property);
+   drm_sysfs_connector_status_event(connector,
+   connector->privacy_screen_hw_state_property);
+
+   return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen_provider(
+   struct drm_connector *connector, struct drm_privacy_screen *priv)
+{
+   connector->privacy_screen = priv;
+   connector->privacy_screen_notifier.notifier_call =
+   drm_connector_privacy_screen_notifier;
+
+   drm_connector_create_privacy_screen_properties(connector);
+   

[Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support

2021-09-06 Thread Hans de Goede
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_privacy_screen.c  | 67 +++
 include/drm/drm_privacy_screen_consumer.h | 15 +
 include/drm/drm_privacy_screen_driver.h   |  4 ++
 3 files changed, 86 insertions(+)

diff --git a/drivers/gpu/drm/drm_privacy_screen.c 
b/drivers/gpu/drm/drm_privacy_screen.c
index 294a09194bfb..7a5f878c3171 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -255,6 +255,49 @@ void drm_privacy_screen_get_state(struct 
drm_privacy_screen *priv,
 }
 EXPORT_SYMBOL(drm_privacy_screen_get_state);
 
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(>notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with 
drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+  struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(>notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
 /*** drm_privacy_screen_driver.h functions ***/
 
 static ssize_t sw_state_show(struct device *dev,
@@ -352,6 +395,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
return ERR_PTR(-ENOMEM);
 
mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>notifier_head);
 
priv->dev.class = drm_class;
priv->dev.type = _privacy_screen_type;
@@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct 
drm_privacy_screen *priv)
device_unregister(>dev);
 }
 EXPORT_SYMBOL(drm_privacy_screen_unregister);
+
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+   if (WARN_ON(mutex_is_locked(>lock)))
+   return;
+
+   blocking_notifier_call_chain(>notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
diff --git a/include/drm/drm_privacy_screen_consumer.h 
b/include/drm/drm_privacy_screen_consumer.h
index 0cbd23b0453d..7f66a90d15b7 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct 
drm_privacy_screen *priv,
 void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
  enum drm_privacy_screen_status *sw_state_ret,
  enum drm_privacy_screen_status *hw_state_ret);
+
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb);
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+   

[Intel-gfx] [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code

2021-09-06 Thread Hans de Goede
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.

This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Makefile |  2 +-
 drivers/gpu/drm/drm_privacy_screen_x86.c | 86 
 include/drm/drm_privacy_screen_machine.h |  5 ++
 3 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 788fc37096f6..12997ca5670d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_PCI) += drm_pci.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o 
drm_privacy_screen_x86.o
 
 obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
 
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c 
b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index ..a2cafb294ca6
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede 
+ */
+
+#include 
+#include 
+
+#ifdef CONFIG_X86
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+   struct drm_privacy_screen_lookup lookup;
+   bool (*detect)(void);
+};
+
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+ void *context, void **return_value)
+{
+   *(acpi_handle *)return_value = handle;
+   return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+   union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+   struct acpi_object_list args = { .count = 1, .pointer = , };
+   acpi_handle ec_handle = NULL;
+   unsigned long long output;
+   acpi_status status;
+
+   /* Get embedded-controller handle */
+   status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, _handle);
+   if (ACPI_FAILURE(status) || !ec_handle)
+   return false;
+
+   /* And call the privacy-screen get-status method */
+   status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", , );
+   if (ACPI_FAILURE(status))
+   return false;
+
+   return (output & 0x1) ? true : false;
+}
+#endif
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+   {
+   .lookup = {
+   .dev_id = NULL,
+   .con_id = NULL,
+   .provider = "privacy_screen-thinkpad_acpi",
+   },
+   .detect = detect_thinkpad_privacy_screen,
+   },
+#endif
+};
+
+void __init drm_privacy_screen_lookup_init(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+   if (!arch_init_data[i].detect())
+   continue;
+
+   pr_info("Found '%s' privacy-screen provider\n",
+   arch_init_data[i].lookup.provider);
+
+   /* Make a copy because arch_init_data is __initconst */
+   arch_lookup = arch_init_data[i].lookup;
+   drm_privacy_screen_lookup_add(_lookup);
+   break;
+   }
+}
+
+void drm_privacy_screen_lookup_exit(void)
+{
+   if (arch_lookup.provider)
+   drm_privacy_screen_lookup_remove(_lookup);
+}
+#endif /* ifdef CONFIG_X86 */
diff --git a/include/drm/drm_privacy_screen_machine.h 
b/include/drm/drm_privacy_screen_machine.h
index aaa0d38cce92..02e5371904d3 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
 void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
 void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup 
*lookup);
 
+#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
+void drm_privacy_screen_lookup_init(void);
+void drm_privacy_screen_lookup_exit(void);
+#else
 static inline void drm_privacy_screen_lookup_init(void)
 {
 }
 static inline void drm_privacy_screen_lookup_exit(void)
 {
 }
+#endif
 
 #endif
-- 
2.31.1



[Intel-gfx] [PATCH 2/9] drm: Add privacy-screen class (v3)

2021-09-06 Thread Hans de Goede
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.

This commit adds a privacy-screen class allowing the driver for these
other devices to register themselves as a privacy-screen provider; and
allowing the drm/kms code to get a privacy-screen provider associated
with a specific GPU/connector combo.

Changes in v2:
- Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
  code gets built as part of the main drm module rather then making it
  a tristate which builds its own module.
- Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
  drm_privacy_screen_consumer.h and define stubs when the check fails.
  Together these 2 changes fix several dependency issues.
- Remove module related code now that this is part of the main drm.ko
- Use drm_class as class for the privacy-screen devices instead of
  adding a separate class for this

Changes in v3:
- Make the static inline drm_privacy_screen_get_state() stub set sw_state
  and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
  variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set

Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 Documentation/gpu/drm-kms-helpers.rst |  15 +
 MAINTAINERS   |   8 +
 drivers/gpu/drm/Kconfig   |   4 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_drv.c |   4 +
 drivers/gpu/drm/drm_privacy_screen.c  | 401 ++
 include/drm/drm_privacy_screen_consumer.h |  50 +++
 include/drm/drm_privacy_screen_driver.h   |  80 +
 include/drm/drm_privacy_screen_machine.h  |  41 +++
 9 files changed, 604 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
 create mode 100644 include/drm/drm_privacy_screen_consumer.h
 create mode 100644 include/drm/drm_privacy_screen_driver.h
 create mode 100644 include/drm/drm_privacy_screen_machine.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 389892f36185..5d8715d2f998 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
 
 .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+Privacy-screen class
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
+   :internal:
+
+.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index ede4a37a53b3..a272ca600f98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6376,6 +6376,14 @@ F:   drivers/gpu/drm/drm_panel.c
 F: drivers/gpu/drm/panel/
 F: include/drm/drm_panel.h
 
+DRM PRIVACY-SCREEN CLASS
+M: Hans de Goede 
+L: dri-de...@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/drm_privacy_screen*
+F: include/drm/drm_privacy_screen*
+
 DRM TTM SUBSYSTEM
 M: Christian Koenig 
 M: Huang Rui 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b17e231ca6f7..7249b010ab90 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
 config DRM_LIB_RANDOM
bool
default n
+
+config DRM_PRIVACY_SCREEN
+   bool
+   default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..788fc37096f6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_PCI) += drm_pci.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
 
 obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
 
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..dc293b771c3f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
 
 static void drm_core_exit(void)
 {
+   drm_privacy_screen_lookup_exit();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
 
+   drm_privacy_screen_lookup_init();
+
drm_core_init_complete = true;
 
DRM_DEBUG("Initialized\n");
diff --git 

[Intel-gfx] [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)

2021-09-06 Thread Hans de Goede
From: Rajat Jain 

Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.

Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
  "privacy-screen hw-state", to deal with devices where the OS might be
  locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
  happens when changes to the state are made outside of the DRM code's
  control, etc.

Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties

Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
  names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
  all possible enum values separated by commas in its output, so having a
  comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
  since this property is immutable its value must be directly stored in the
  obj->properties->values array

Signed-off-by: Rajat Jain 
Co-authored-by: Hans de Goede 
Acked-by: Pekka Paalanen 
Reviewed-by: Mario Limonciello 
Reviewed-by: Emil Velikov 
Signed-off-by: Hans de Goede 
---
 Documentation/gpu/drm-kms.rst |   2 +
 drivers/gpu/drm/drm_atomic_uapi.c |   4 ++
 drivers/gpu/drm/drm_connector.c   | 101 ++
 include/drm/drm_connector.h   |  44 +
 4 files changed, 151 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1ef7951ded5e..d14bf1c35d7e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -506,6 +506,8 @@ Property Types and Blob Property Support
 .. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
 
+.. _standard_connector_properties:
+
 Standard Connector Properties
 -
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 909f31833181..cdd31fc78bfc 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -797,6 +797,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
   fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+   } else if (property == connector->privacy_screen_sw_state_property) {
+   state->privacy_screen_sw_state = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -874,6 +876,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+   } else if (property == connector->privacy_screen_sw_state_property) {
+   *val = state->privacy_screen_sw_state;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e0a30e0ee86a..dd1ca68881ba 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
= {
  * For DVI-I and TVout there is also a matching property "select 
subconnector"
  * allowing to switch between signal types.
  * DP subconnector corresponds to a downstream port.
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ * These 2 optional properties can be used to query the state of the
+ * electronic privacy screen that is available on some displays; and in
+ * some cases also control the state. If a driver implements these
+ * properties then both properties must be present.
+ *
+ * "privacy-screen hw-state" is read-only and reflects the actual state
+ * of the privacy-screen, possible values: "Enabled", "Disabled,
+ * "Enabled-locked", "Disabled-locked". The locked states indicate
+ * that the state cannot be changed through the DRM API. E.g. there
+ * might be devices where the firmware-setup options, or a hardware
+ * slider-switch, offer always on / off modes.
+ *
+ * "privacy-screen sw-state" can be set to change the privacy-screen state
+ * when not locked. In this case the driver must update the hw-state
+ * property to reflect the new state on completion of the commit of the
+ * sw-state property. Setting the sw-state property when the hw-state is
+ * locked must be interpreted by the driver as a request to change the
+ * state to the set state when the hw-state becomes unlocked. E.g. if
+ * "privacy-screen hw-state" is "Enabled-locked" and the 

[Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties

2021-09-06 Thread Hans de Goede
Hi all,

Here is the privacy-screen related code which I last posted in April 2021
To the best of my knowledge there is consensus about / everyone is in
agreement with the new userspace API (2 connector properties) this
patch-set add (patch 1 of the series).

This is unchanged (except for a rebase on drm-tip), what has changed is
that the first userspace consumer of the new properties is now fully ready
for merging (it is just waiting for the kernel bits to land first):

 - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032

Having a userspace-consumer of the API fully ready for merging, clears the
last blocker for this series. It has already has been reviewed before
by Emil Velikov, but it could really do with another review.

The new API works as designed and add the following features to GNOME:

1. Showing an OSD notification when the privacy-screen is toggled on/off
   through hotkeys handled by the embedded-controller
2. Allowing control of the privacy-screen from the GNOME control-panel,
   including the on/off slider shown there updating to match the hw-setting
   when the setting is changed with the control-panel open.
3. Restoring the last user-setting at login

This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 2-4 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 5).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 6-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.

I believe that it would be best to merge the entire series, including
the thinkpad_acpi changes through drm-misc in one go. As the pdx86
subsys maintainer I hereby give my ack for merging the thinkpad_acpi
changes through drm-misc.

There is one small caveat with this series, which it is good to be
aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
with an eprivacy screen, until the thinkpad_acpi driver is loaded.
This means that initrd generation tools will need to be updated to
include thinkpad_acpi when the i915 driver is added to the initrd.
Without this the loading of the i915 driver will be delayed to after
the switch to real rootfs.

Regards,

Hans


Hans de Goede (8):
  drm: Add privacy-screen class (v3)
  drm/privacy-screen: Add X86 specific arch init code
  drm/privacy-screen: Add notifier support
  drm/connector: Add a drm_connector privacy-screen helper functions
  platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
helper
  platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
handles only once
  platform/x86: thinkpad_acpi: Register a privacy-screen device
  drm/i915: Add privacy-screen support

Rajat Jain (1):
  drm/connector: Add support for privacy-screen properties (v4)

 Documentation/gpu/drm-kms-helpers.rst|  15 +
 Documentation/gpu/drm-kms.rst|   2 +
 MAINTAINERS  |   8 +
 drivers/gpu/drm/Kconfig  |   4 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_atomic_uapi.c|   4 +
 drivers/gpu/drm/drm_connector.c  | 214 +
 drivers/gpu/drm/drm_drv.c|   4 +
 drivers/gpu/drm/drm_privacy_screen.c | 468 +++
 drivers/gpu/drm/drm_privacy_screen_x86.c |  86 
 drivers/gpu/drm/i915/display/intel_display.c |   5 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  10 +
 drivers/gpu/drm/i915/i915_pci.c  |  12 +
 drivers/platform/x86/Kconfig |   2 +
 drivers/platform/x86/thinkpad_acpi.c | 131 --
 include/drm/drm_connector.h  |  56 +++
 include/drm/drm_privacy_screen_consumer.h|  65 +++
 include/drm/drm_privacy_screen_driver.h  |  84 
 include/drm/drm_privacy_screen_machine.h |  46 ++
 19 files changed, 1175 insertions(+), 42 deletions(-)
 create mode 100644 

Re: [Intel-gfx] linux-next: build failure after merge of the drm tree

2021-09-06 Thread Daniel Vetter
On Mon, Sep 6, 2021 at 12:49 AM Stephen Rothwell  wrote:
> Hi all,
>
> On Thu, 2 Sep 2021 07:50:38 +1000 Stephen Rothwell  
> wrote:
> >
> > On Fri, 20 Aug 2021 15:23:34 +0900 Masahiro Yamada  
> > wrote:
> > >
> > > On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell  
> > > wrote:
> > > >
>  > > After merging the drm tree, today's linux-next build (x86_64 
> allmodconfig)
> > > > failed like this:
> > > >
> > > > In file included from drivers/gpu/drm/i915/i915_debugfs.c:39:
> > > > drivers/gpu/drm/i915/gt/intel_gt_requests.h:9:10: fatal error: 
> > > > stddef.h: No such file or directory
> > > > 9 | #include 
> > > >   |  ^~
> > > >
> > > > Caused by commit
> > > >
> > > >   564f963eabd1 ("isystem: delete global -isystem compile option")
> > > >
> > > > from the kbuild tree interacting with commit
> > > >
> > > >   b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work 
> > > > with GuC")
> > > >
> > > > I have applied the following patch for today.
> > >
> > >
> > > Thanks.
> > >
> > > This fix-up does not depend on my kbuild tree in any way.
> > >
> > > So, the drm maintainer can apply it to his tree.
> > >
> > > Perhaps with
> > >
> > > Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to
> > > work with GuC")
> >
> > OK, so that didn't happen so I will now apply the merge fix up to the
> > merge of the kbuild tree.
> >
> > > > From: Stephen Rothwell 
> > > > Date: Fri, 20 Aug 2021 12:24:19 +1000
> > > > Subject: [PATCH] drm/i915: use linux/stddef.h due to "isystem: 
> > > > trim/fixup stdarg.h and other headers"
> > > >
> > > > Signed-off-by: Stephen Rothwell 
> > > > ---
> > > >  drivers/gpu/drm/i915/gt/intel_gt_requests.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h 
> > > > b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > > index 51dbe0e3294e..d2969f68dd64 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > > > @@ -6,7 +6,7 @@
> > > >  #ifndef INTEL_GT_REQUESTS_H
> > > >  #define INTEL_GT_REQUESTS_H
> > > >
> > > > -#include 
> > > > +#include 
> > > >
> > > >  struct intel_engine_cs;
> > > >  struct intel_gt;
> > > > --
> > > > 2.32.0
>
> Ping?  I am still applying this ...

Apologies, this fell through a lot of cracks. I applied this to drm-next now.

Matt/John, as author/committer it's your job to make sure issues and
fixes for the stuff you're pushing don't get lost. I'd have expected
John to apply this to at least drm-intel-gt-next (it's not even
there).

Joonas, I think this is the 2nd or 3rd or so issue this release cycle
where some compile fix got stuck a bit because drm-intel-gt-next isn't
in linux-next. Can we please fix that? It probably needs some changes
to the dim script.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


  1   2   >