date:20220303

Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS

2022-03-03 Thread Lucas De Marchi


On Thu, Mar 03, 2022 at 02:34:34PM -0800, Matt Roper wrote:

In the past we've always assumed that an RCS engine is present on every
platform.  However now that we have compute engines there may be
platforms that have CCS engines but no RCS, or platforms that are
designed to have both, but have the RCS engine fused off.

Various engine-centric initialization that only needs to be done a
single time for the group of RCS+CCS engines can't rely on being setup
with the RCS now; instead we add a I915_ENGINE_FIRST_RENDER_COMPUTE flag
that will be assigned to a single engine in the group; whichever engine
has this flag will be responsible for some of the general setup
(RCU_MODE programming, initialization of certain workarounds, etc.).

Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the memcpy_from_wc function from drm (rev3)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Use the memcpy_from_wc function from drm (rev3)
URL   : https://patchwork.freedesktop.org/series/100581/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22475_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@api_intel_allocator@fork-simple-stress-signal:
- {shard-dg1}:[PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-dg1-15/igt@api_intel_alloca...@fork-simple-stress-signal.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/shard-dg1-15/igt@api_intel_alloca...@fork-simple-stress-signal.html

  * igt@i915_selftest@live@hangcheck:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/shard-rkl-5/igt@i915_selftest@l...@hangcheck.html

  * 
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
- shard-iclb: [PASS][4] -> [SKIP][5] +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html

  * igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][6] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/shard-dg1-16/igt@prime_mmap@test_forked.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][7], [PASS][8], [PASS][9], [PASS][10], 
[PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], 
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], 
[PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], 
[PASS][29], [PASS][30], [PASS][31]) ([i915#4386]) -> ([PASS][32], [PASS][33], 
[PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], 
[PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], 
[PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], 
[PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/d

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev2)
URL   : https://patchwork.freedesktop.org/series/100991/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22474_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- shard-snb:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-snb7/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@fences:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@i915_pm_...@fences.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-iclb7/igt@i915_pm_...@fences.html

  
 Suppressed 

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

  * igt@gem_exec_schedule@smoketest-all:
- {shard-rkl}:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-rkl-2/igt@gem_exec_sched...@smoketest-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-rkl-5/igt@gem_exec_sched...@smoketest-all.html

  * igt@i915_module_load@reload:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-rkl-5/igt@i915_module_l...@reload.html

  * 
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][8] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html

  * igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][9] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/shard-dg1-13/igt@prime_mmap@test_forked.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [PASS][16], [FAIL][17], [PASS][18], [PASS][19], 
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][34]) ([i915#4386]) -> ([PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], 
[PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
   [25]: 
https://intel-g

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl-n: Add stepping info

2022-03-03 Thread Matt Roper

On Thu, Mar 03, 2022 at 08:47:08PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/adl-n: Add stepping info
> URL   : https://patchwork.freedesktop.org/series/100995/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11318_full -> Patchwork_22472_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 

Pushed to drm-intel-next.  Thanks for the patch.


Matt

>   
> 
> Participating hosts (13 -> 13)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22472_full:
> 
> ### IGT changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_exec_balancer@full-pulse:
> - {shard-dg1}:[SKIP][1] -> [FAIL][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-dg1-15/igt@gem_exec_balan...@full-pulse.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-dg1-12/igt@gem_exec_balan...@full-pulse.html
> 
>   * 
> {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
> - {shard-rkl}:NOTRUN -> [SKIP][3] +1 similar issue
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html
> 
>   * igt@prime_mmap_coherency@ioctl-errors:
> - {shard-dg1}:NOTRUN -> [SKIP][4] +2 similar issues
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-dg1-16/igt@prime_mmap_cohere...@ioctl-errors.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22472_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Possible fixes 
> 
>   * boot:
> - shard-glk:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
> [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], 
> [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], 
> [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], 
> [PASS][27], [PASS][28], [FAIL][29]) ([i915#4392]) -> ([PASS][30], [PASS][31], 
> [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
> [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
> [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
> [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk1/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk1/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
>[25]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
>[26]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk5/boot.html
>[27]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk5/boot.html
>[28]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
>[29]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
>[30]: 
> https://intel-gfx-ci.01.org/tree

Re: [Intel-gfx] [PATCH] drm/i915/adl-n: Add stepping info

2022-03-03 Thread Surendrakumar Upadhyay, TejaskumarX

Please help to merge.

Thanks,
Tejas

> -Original Message-
> From: Roper, Matthew D 
> Sent: 04 March 2022 10:09
> To: Surendrakumar Upadhyay, TejaskumarX
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/adl-n: Add stepping info
> 
> On Thu, Mar 03, 2022 at 05:02:52PM +0530, Tejas Upadhyay wrote:
> > Add ADL-N stepping-substepping info in accordance to BSpec.
> >
> > Bspec: 68397
> >
> > Cc: Matt Roper 
> > Signed-off-by: Tejas Upadhyay
> > 
> 
> Reviewed-by: Matt Roper 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_step.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_step.c
> > b/drivers/gpu/drm/i915/intel_step.c
> > index 4fd69ecd1481..74e8e4680028 100644
> > --- a/drivers/gpu/drm/i915/intel_step.c
> > +++ b/drivers/gpu/drm/i915/intel_step.c
> > @@ -131,6 +131,10 @@ static const struct intel_step_info
> adls_rpls_revids[] = {
> > [0xC] = { COMMON_GT_MEDIA_STEP(D0), .display_step = STEP_C0 },
> };
> >
> > +static const struct intel_step_info adlp_n_revids[] = {
> > +   [0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
> };
> > +
> >  void intel_step_init(struct drm_i915_private *i915)  {
> > const struct intel_step_info *revids = NULL; @@ -150,6 +154,9 @@
> > void intel_step_init(struct drm_i915_private *i915)
> > } else if (IS_XEHPSDV(i915)) {
> > revids = xehpsdv_revids;
> > size = ARRAY_SIZE(xehpsdv_revids);
> > +   } else if (IS_ADLP_N(i915)) {
> > +   revids = adlp_n_revids;
> > +   size = ARRAY_SIZE(adlp_n_revids);
> > } else if (IS_ALDERLAKE_P(i915)) {
> > revids = adlp_revids;
> > size = ARRAY_SIZE(adlp_revids);
> > --
> > 2.34.1
> >
> 
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795

Re: [Intel-gfx] [PATCH] drm/i915/adl-n: Add stepping info

2022-03-03 Thread Matt Roper

On Thu, Mar 03, 2022 at 05:02:52PM +0530, Tejas Upadhyay wrote:
> Add ADL-N stepping-substepping info in
> accordance to BSpec.
> 
> Bspec: 68397
> 
> Cc: Matt Roper 
> Signed-off-by: Tejas Upadhyay 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_step.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_step.c 
> b/drivers/gpu/drm/i915/intel_step.c
> index 4fd69ecd1481..74e8e4680028 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -131,6 +131,10 @@ static const struct intel_step_info adls_rpls_revids[] = 
> {
>   [0xC] = { COMMON_GT_MEDIA_STEP(D0), .display_step = STEP_C0 },
>  };
>  
> +static const struct intel_step_info adlp_n_revids[] = {
> + [0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
> +};
> +
>  void intel_step_init(struct drm_i915_private *i915)
>  {
>   const struct intel_step_info *revids = NULL;
> @@ -150,6 +154,9 @@ void intel_step_init(struct drm_i915_private *i915)
>   } else if (IS_XEHPSDV(i915)) {
>   revids = xehpsdv_revids;
>   size = ARRAY_SIZE(xehpsdv_revids);
> + } else if (IS_ADLP_N(i915)) {
> + revids = adlp_n_revids;
> + size = ARRAY_SIZE(adlp_n_revids);
>   } else if (IS_ALDERLAKE_P(i915)) {
>   revids = adlp_revids;
>   size = ARRAY_SIZE(adlp_revids);
> -- 
> 2.34.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write

2022-03-03 Thread Katragadda, MastanX

Hi Tvrtko
 
Can we need extend this patch by adding selftest?

Thanks,
Mastan
 
-Original Message-
From: Auld, Matthew  
Sent: 03 March 2022 16:14
To: Tvrtko Ursulin ; Katragadda, MastanX 
; intel-gfx@lists.freedesktop.org
Cc: Surendrakumar Upadhyay, TejaskumarX 

Subject: Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access 
leads to OOB read/write

On 03/03/2022 09:00, Tvrtko Ursulin wrote:
> 
> + Matt
> 
> On 03/03/2022 06:04, Mastan Katragadda wrote:
>> Intel ID: PSIRT-PTK0002429
>>
>> A missing bounds check in vm_access()can lead to an out-of-bounds 
>> read or write in the adjacent memory area.The len attribute is not 
>> validated before the memcpy at  [1]or [2] occurs.
> 
> s/[1]or [2]/later in the function/ ?
> 
>>
>> [  183.637831] BUG: unable to handle page fault for address: 
>> c9c86000
>> [  183.637934] #PF: supervisor read access in kernel mode [  
>> 183.637997] #PF: error_code(0x) - not-present page [  183.638059] 
>> PGD 10067 P4D 10067 PUD 100258067 PMD 106341067 PTE 0 [  
>> 183.638144] Oops:  [#2] PREEMPT SMP NOPTI
>> [  183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G  D   
>> 5.17.0-rc6-ci-drm-11296+ #1
>> [  183.638298] Hardware name: Intel Corporation CoffeeLake Client 
>> Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319
>> 05/30/2019
>> [  183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [  183.640213] RSP: 
>> 0018:c90001763d48 EFLAGS: 00010246 [  183.641117] RAX: 
>> 888109c14000 RBX: 888111bece40 RCX:
>> 0ffc
>> [  183.642029] RDX: 1000 RSI: c9c86000 RDI: 
>> 888109c14004
>> [  183.642946] RBP: 0ffc R08: 816b R09: 
>> 
>> [  183.643848] R10: c9c85000 R11: 0048 R12: 
>> 1000
>> [  183.644742] R13: 888111bed190 R14: 888109c14000 R15: 
>> 1000
>> [  183.645653] FS:  7fe5ef807540() GS:88845b38()
>> knlGS:
>> [  183.646570] CS:  0010 DS:  ES:  CR0: 80050033 [  
>> 183.647481] CR2: c9c86000 CR3: 00010ff02006 CR4:
>> 003706e0
>> [  183.648384] DR0:  DR1:  DR2: 
>> 
>> [  183.649271] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [  183.650142] Call Trace:
>> [  183.650988]  
>> [  183.651793]  vm_access+0x1f0/0x2a0 [i915] [  183.652726]  
>> __access_remote_vm+0x224/0x380 [  183.653561]  
>> mem_rw.isra.0+0xf9/0x190 [  183.654402]  vfs_read+0x9d/0x1b0 [  
>> 183.655238]  ksys_read+0x63/0xe0 [  183.656065]  
>> do_syscall_64+0x38/0xc0 [  183.656882]  
>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>> [  183.657663] RIP: 0033:0x7fe5ef725142 [  183.659351] RSP: 
>> 002b:7ffe1e81c7e8 EFLAGS: 0246 ORIG_RAX:
>> 
>> [  183.660227] RAX: ffda RBX: 557055dfb780 RCX: 
>> 7fe5ef725142
>> [  183.661104] RDX: 1000 RSI: 7ffe1e81d880 RDI: 
>> 0005
>> [  183.661972] RBP: 7ffe1e81e890 R08: 0030 R09: 
>> 0046
>> [  183.662832] R10: 557055dfc2e0 R11: 0246 R12: 
>> 557055dfb1c0
>> [  183.663691] R13: 7ffe1e81e980 R14:  R15: 
>> 
>> [  183.664566]  
>>
>> Changes since v1:
>>   - Updated if condition with range_overflows_t [Chris Wilson]
>>
>> Signed-off-by: Mastan Katragadda 
>> Suggested-by: Adam Zabrocki 
>> Reported-by: Jackson Cody 
>> Cc: Chris Wilson 
>> Cc: Bloomfield Jon 
>> Cc: Dutt Sudeep 
> 
> Fixes: 9f909e215fea ("drm/i915: Implement vm_ops->access for gdb 
> access into mmaps")
> Cc:  # v5.8+
> 
> Right?
> 
> There was a selftest added with the referenced patch and it sounds 
> like it would be a good idea to extend it to cover this scenario.  As 
> a separate patch though so this one is easy to backport.

Agreed, a simple regression test(either selftest or igt) for this would be 
nice, if possible.

> 
> Regards,
> 
> Tvrtko
> 
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index efe69d6b86f4..c3ea243d414d 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -455,7 +455,7 @@ vm_access(struct vm_area_struct *area, unsigned 
>> long addr,
>>   return -EACCES;
>>   addr -= area->vm_start;
>> -    if (addr >= obj->base.size)
>> +    if (range_overflows_t(u64, addr, len, obj->base.size))
>>   return -EINVAL;

Other users like ttm_bo_vm_access are also checking if len <= 0, should we also 
add an explicit check for that here? Otherwise LGTM.

>>   i915_gem_ww_ctx_init(&ww, true);

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)
URL   : https://patchwork.freedesktop.org/series/98801/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11322 -> Patchwork_22484


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(4): fi-bsw-cyan bat-jsl-2 fi-icl-u2 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u:   [PASS][2] -> [INCOMPLETE][3] ([i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][4] -> [INCOMPLETE][5] ([i915#2940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [PASS][6] -> [INCOMPLETE][7] ([i915#4418])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][8] ([i915#3921])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][9] -> [DMESG-FAIL][10] ([i915#5026])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][12] ([fdo#109271]) +13 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +57 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][14] ([i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-skl-6600u/igt@run...@aborted.html
- bat-dg1-5:  NOTRUN -> [FAIL][15] ([i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/bat-dg1-5/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#1436] / 
[i915#3428] / [i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-bsw-nick/igt@run...@aborted.html
- fi-blb-e6850:   NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][18] ([i915#3303]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [DMESG-FAIL][20] ([i915#4494] / [i915#4957]) -> 
[PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][22] -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add preemption changes for Wa_14015141709

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/dg2: Add preemption changes for Wa_14015141709
URL   : https://patchwork.freedesktop.org/series/101023/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11322 -> Patchwork_22483


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 42)
--

  Missing(3): fi-bsw-cyan fi-icl-u2 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@workarounds:
- {bat-adlp-6}:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/bat-adlp-6/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][3] -> [DMESG-FAIL][4] ([i915#5026])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][5] -> [FAIL][6] ([i915#4547])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][7] ([i915#4312])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-skl-6600u/igt@run...@aborted.html
- fi-blb-e6850:   NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@guc_multi_lrc:
- {bat-rpls-2}:   [DMESG-WARN][9] ([i915#4391]) -> [PASS][10] +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-rpls-2/igt@i915_selftest@live@guc_multi_lrc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/bat-rpls-2/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][13] ([i915#2867]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [DMESG-FAIL][15] ([i915#5087]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][17] ([i915#3576]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/bat-adlp-6/igt@kms_busy@ba...@flip.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][19] ([i915#3303]) -> [INCOMPLETE][20] 
([i915#4785])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.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#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)
URL   : https://patchwork.freedesktop.org/series/98801/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b7eb4985f027 drm/i915/display/vrr: Reset VRR capable property on a long hpd
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel 
settings.

-:22: WARNING:TYPO_SPELLING: 'reseting' may be misspelled - perhaps 'resetting'?
#22: 
v5: Fixes the regression on older platforms by reseting the VRR
   

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: Add preemption changes for Wa_14015141709

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/dg2: Add preemption changes for Wa_14015141709
URL   : https://patchwork.freedesktop.org/series/101023/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Add preemption changes for Wa_14015141709

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/dg2: Add preemption changes for Wa_14015141709
URL   : https://patchwork.freedesktop.org/series/101023/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1deb35fff8c4 drm/i915/dg2: Add preemption changes for Wa_14015141709
-:127: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#127: FILE: drivers/gpu/drm/i915/i915_drv.h:1410:
+#define HAS_PERCTX_PREEMPT_CTRL(i915) \
+   ((GRAPHICS_VER(i915) >= 9) &&  GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Improve anti-pre-emption w/a for compute workloads (rev4)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads (rev4)
URL   : https://patchwork.freedesktop.org/series/100428/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11322 -> Patchwork_22482


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 43)
--

  Additional (1): fi-pnv-d510 
  Missing(3): bat-rpls-2 fi-bsw-cyan fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u:   [PASS][1] -> [INCOMPLETE][2] ([i915#4547])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][3] ([i915#3921])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][5] ([fdo#109271]) +13 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +57 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][7] ([i915#4312])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][10] ([i915#3576]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/bat-adlp-6/igt@kms_busy@ba...@flip.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) -> 
[DMESG-FAIL][13] ([i915#4957])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957


Build changes
-

  * Linux: CI_DRM_11322 -> Patchwork_22482

  CI-20190529: 20190529
  CI_DRM_11322: 7328c1d5b59036c9eee129e43b07b417e6c127e1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6362: 698695136f8ade2391f2d8f45300eae2df02e947 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22482: 53812ed93f893158ffa88c09603ea2cf8a7d48f5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

53812ed93f89 drm/i915: Improve long running OCL w/a for GuC submission
de2bbe1afe48 drm/i915: Make the heartbeat play nice with long pre-emption 
timeouts
1f742dfb98cf drm/i915: Fix compute pre-emption w/a to apply to compute engines
5ef6e2a52bd2 drm/i915/guc: Limit scheduling properties to avoid overflow

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Improve anti-pre-emption w/a for compute workloads (rev4)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads (rev4)
URL   : https://patchwork.freedesktop.org/series/100428/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Improve anti-pre-emption w/a for compute workloads (rev4)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads (rev4)
URL   : https://patchwork.freedesktop.org/series/100428/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5ef6e2a52bd2 drm/i915/guc: Limit scheduling properties to avoid overflow
-:42: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'field' - possible 
side-effects?
#42: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:446:
+#define CLAMP_PROP(field) \
+   do { \
+   u64 clamp = intel_clamp_##field(engine, engine->props.field); \
+   if (clamp != engine->props.field) { \
+   drm_notice(&engine->i915->drm, \
+  "Warning, clamping %s to %lld to prevent 
overflow\n", \
+  #field, clamp); \
+   engine->props.field = clamp; \
+   } \
+   } while (0)

total: 0 errors, 0 warnings, 1 checks, 191 lines checked
1f742dfb98cf drm/i915: Fix compute pre-emption w/a to apply to compute engines
de2bbe1afe48 drm/i915: Make the heartbeat play nice with long pre-emption 
timeouts
53812ed93f89 drm/i915: Improve long running OCL w/a for GuC submission

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Count engine instances per uabi class

2022-03-03 Thread Umesh Nerlige Ramappa


On Wed, Mar 02, 2022 at 09:03:18AM +, Tvrtko Ursulin wrote:


On 01/03/2022 19:34, Umesh Nerlige Ramappa wrote:

On Tue, Feb 22, 2022 at 02:04:21PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This will be useful to have at hand in a following patch.

Signed-off-by: Tvrtko Ursulin 
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h |  1 +
2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c

index 9ce85a845105..5dd559253078 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -190,7 +190,6 @@ static void add_legacy_ring(struct legacy_ring *ring,
void intel_engines_driver_register(struct drm_i915_private *i915)
{
struct legacy_ring ring = {};
-    u8 uabi_instances[4] = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
LIST_HEAD(engines);
@@ -211,8 +210,10 @@ void intel_engines_driver_register(struct 
drm_i915_private *i915)

    GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
    engine->uabi_class = uabi_classes[engine->class];

-    GEM_BUG_ON(engine->uabi_class >= ARRAY_SIZE(uabi_instances));
-    engine->uabi_instance = uabi_instances[engine->uabi_class]++;
+    GEM_BUG_ON(engine->uabi_class >=
+   ARRAY_SIZE(i915->engine_uabi_class_count));
+    engine->uabi_instance =
+    i915->engine_uabi_class_count[engine->uabi_class]++;

    /* Replace the internal name with the final user facing name */
    memcpy(old, engine->name, sizeof(engine->name));
@@ -242,8 +243,8 @@ void intel_engines_driver_register(struct 
drm_i915_private *i915)

    int class, inst;
    int errors = 0;

-    for (class = 0; class < ARRAY_SIZE(uabi_instances); class++) {
-    for (inst = 0; inst < uabi_instances[class]; inst++) {
+    for (class = 0; class < 
ARRAY_SIZE(i915->engine_uabi_class_count); class++) {
+    for (inst = 0; inst < 
i915->engine_uabi_class_count[class]; inst++) {

    engine = intel_engine_lookup_user(i915,
  class, inst);
    if (!engine) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index b9d38276801d..68d8a751008b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -533,6 +533,7 @@ struct drm_i915_private {
struct pci_dev *bridge_dev;

struct rb_root uabi_engines;
+    unsigned int 
engine_uabi_class_count[I915_LAST_UABI_ENGINE_CLASS + 1];


lgtm,
Reviewed-by: Umesh Nerlige Ramappa 


Thanks Umesh - for the series or just this patch? I'd need to update 
your r-b's on patches 3, 6 and 8 to latest as well.


I checked out the diff between this series and the previous one. The 
changes look good.


For the series:
Reviewed-by: Umesh Nerlige Ramappa 

Thanks,
Umesh


Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS

2022-03-03 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/xehp: Support platforms with CCS 
engines but no RCS
URL   : https://patchwork.freedesktop.org/series/101019/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11321 -> Patchwork_22481


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  Additional (2): fi-bdw-5557u fi-pnv-d510 
  Missing(2): fi-bsw-cyan fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [DMESG-FAIL][1] ([i915#5087]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/bat-rpls-2/igt@i915_selftest@l...@requests.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u:   [PASS][4] -> [INCOMPLETE][5] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#3303])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][8] -> [DMESG-FAIL][9] ([i915#5026])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][10] -> [DMESG-WARN][11] ([i915#295]) +12 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][12] ([fdo#109271]) +57 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][13] ([i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-skl-6600u/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][14] ([i915#2426] / [i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-bdw-5557u/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-hsw-4770/igt@run...@aborted.html
- fi-blb-e6850:   NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][17] ([i915#3921]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/fi-snb-2600/igt@i915_selftest@l...@hangcheck.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#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/i

[Intel-gfx] [PATCH v7] drm/i915/display/vrr: Reset VRR capable property on a long hpd

2022-03-03 Thread Manasi Navare

With some VRR panels, user can turn VRR ON/OFF on the fly from the panel 
settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA 
bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.

Fix this by explicitly resetting the connector property.

v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)
v5: Fixes the regression on older platforms by reseting the VRR
only if HAS_VRR
v6: Remove the checks from driver, add in drm core before
setting VRR prop (Ville)
v7: Move VRR set/reset to set/unset_edid (Ville)

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable property 
on a long hpd")
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d6ef33096bb6..1d0f8fc39005 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4385,13 +4385,20 @@ intel_dp_update_420(struct intel_dp *intel_dp)
 static void
 intel_dp_set_edid(struct intel_dp *intel_dp)
 {
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
struct edid *edid;
+   bool vrr_capable;
 
intel_dp_unset_edid(intel_dp);
edid = intel_dp_get_edid(intel_dp);
connector->detect_edid = edid;
 
+   vrr_capable = intel_vrr_is_capable(&connector->base);
+   drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
+   connector->base.base.id, connector->base.name, 
str_yes_no(vrr_capable));
+   drm_connector_set_vrr_capable_property(&connector->base, vrr_capable);
+
intel_dp_update_dfp(intel_dp, edid);
intel_dp_update_420(intel_dp);
 
@@ -4424,6 +4431,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
+
+   drm_connector_set_vrr_capable_property(&connector->base,
+  false);
 }
 
 static int
@@ -4574,14 +4584,9 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
int num_modes = 0;
 
edid = intel_connector->detect_edid;
-   if (edid) {
+   if (edid)
num_modes = intel_connector_update_modes(connector, edid);
 
-   if (intel_vrr_is_capable(connector))
-   drm_connector_set_vrr_capable_property(connector,
-  true);
-   }
-
/* Also add fixed mode, which may or may not be present in EDID */
if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
intel_connector->panel.fixed_mode) {
-- 
2.19.1

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Fix compute pre-emption w/a to apply to compute engines

2022-03-03 Thread Matt Roper

On Thu, Mar 03, 2022 at 02:37:35PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> An earlier patch added support for compute engines. However, it missed
> enabling the anti-pre-emption w/a for the new engine class. So move
> the 'compute capable' flag earlier and use it for the pre-emption w/a
> test.
> 
> Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup functions")
> Cc: Tvrtko Ursulin 
> Cc: Daniele Ceraolo Spurio 
> Cc: Aravind Iddamsetty 
> Cc: Matt Roper 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Lucas De Marchi 
> Cc: John Harrison 
> Cc: Jason Ekstrand 
> Cc: "Michał Winiarski" 
> Cc: Matthew Brost 
> Cc: Chris Wilson 
> Cc: Tejas Upadhyay 
> Cc: Umesh Nerlige Ramappa 
> Cc: "Thomas Hellström" 
> Cc: Stuart Summers 
> Cc: Matthew Auld 
> Cc: Jani Nikula 
> Cc: Ramalingam C 
> Cc: Akeem G Abodunrin 
> Signed-off-by: John Harrison 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 22e70e4e007c..4185c7338581 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -421,6 +421,12 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> intel_engine_id id,
>   engine->logical_mask = BIT(logical_instance);
>   __sprint_engine_name(engine);
>  
> + /* features common between engines sharing EUs */
> + if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
> + engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
> + engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
> + }
> +
>   engine->props.heartbeat_interval_ms =
>   CONFIG_DRM_I915_HEARTBEAT_INTERVAL;
>   engine->props.max_busywait_duration_ns =
> @@ -433,15 +439,9 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> intel_engine_id id,
>   CONFIG_DRM_I915_TIMESLICE_DURATION;
>  
>   /* Override to uninterruptible for OpenCL workloads. */
> - if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
> + if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
> I915_ENGINE_HAS_RCS_REG_STATE))
>   engine->props.preempt_timeout_ms = 0;
>  
> - /* features common between engines sharing EUs */
> - if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
> - engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
> - engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
> - }
> -
>   /* Cap properties according to any system limits */
>  #define CLAMP_PROP(field) \
>   do { \
> -- 
> 2.25.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS

2022-03-03 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/xehp: Support platforms with CCS 
engines but no RCS
URL   : https://patchwork.freedesktop.org/series/101019/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Prep work for next GuC release (rev4)

2022-03-03 Thread John Harrison


On 3/2/2022 01:27, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   Prep work for next GuC release (rev4)
*URL:*  https://patchwork.freedesktop.org/series/99805/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22457/index.html



  CI Bug Log - changes from CI_DRM_11308_full -> Patchwork_22457_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_22457_full absolutely 
need to be

verified manually.

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



Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

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



  IGT changes


Possible regressions

  * 
igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-edp-1-scaler-with-clipping-clamping:

  o shard-iclb: PASS


-> INCOMPLETE




Unrelated display test on an execlist only platform.

John.



 *


Suppressed

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

 *


{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-25@pipe-a-edp-1-downscale-with-pixel-format}:

  o shard-iclb: NOTRUN -> SKIP


+2 similar issues
 *

{igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-25}:

  o {shard-rkl}: NOTRUN -> SKIP


+6 similar issues
 *


{igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:

  o shard-iclb: PASS


-> SKIP


+5 similar issues


New tests

New tests have been introduced between CI_DRM_11308_full and 
Patchwork_22457_full:



  New IGT tests (1)

  * 
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:

  o Statuses : 1 pass(s)
  o Exec time: [1.28] s


Known issues

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



  CI changes


Issues hit

  * boot:
  o shard-glk: (PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

,
PASS

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add RCS mask to GuC ADS params

2022-03-03 Thread John Harrison


On 3/3/2022 14:34, Matt Roper wrote:

From: Stuart Summers 

If RCS is not enumerated, GuC will return invalid parameters.
Make sure we do not send RCS supported when we have not enumerated
it.

Cc: Vinay Belgaumkar 
Signed-off-by: Stuart Summers 
Signed-off-by: Matt Roper 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 32c2053f2f08..acc4a3766dc1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -433,7 +433,7 @@ static void guc_mmio_reg_state_init(struct intel_guc *guc)
  static void fill_engine_enable_masks(struct intel_gt *gt,
 struct iosys_map *info_map)
  {
-   info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 1);
+   info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 
RCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_COMPUTE_CLASS], 
CCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS], 
VDBOX_MASK(gt));

[Intel-gfx] [PATCH] drm/i915/dg2: Add preemption changes for Wa_14015141709

2022-03-03 Thread Matt Roper

From: Akeem G Abodunrin 

Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to specify the preemption granularity (such as batch-level vs
command-level vs object-level).

As a result of this - for debugging purposes, this patch adds debugfs
interface to configure (disable/enable) preemption globally.

Jira: VLK-27831

Cc: Matt Roper 
Cc: Prathap Kumar Valsan 
Cc: John Harrison 
Cc: Joonas Lahtinen 
Signed-off-by: Akeem G Abodunrin 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  3 ++
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c | 50 +
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 4 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 19cd34f24263..21ede1887b9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -468,6 +468,9 @@
 #define VF_PREEMPTION  _MMIO(0x83a4)
 #define   PREEMPTION_VERTEX_COUNT  REG_GENMASK(15, 0)
 
+#define GEN12_VFG_PREEMPTION_CHICKEN   _MMIO(0x83b4)
+#define   GEN12_VFG_PREEMPT_CHICKEN_DISABLEREG_BIT(8)
+
 #define GEN8_RC6_CTX_INFO  _MMIO(0x8504)
 
 #define GEN12_SQCM _MMIO(0x8724)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index c014b40d2e9f..18dc82f29776 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
 FF_DOP_CLOCK_GATE_DISABLE);
}
 
-   if (IS_GRAPHICS_VER(i915, 9, 12)) {
+   if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
/* 
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
wa_masked_en(wal,
 GEN7_FF_SLICE_CS_CHICKEN1,
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 747fe9f41e1f..40e6e17e2950 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -571,6 +571,55 @@ static int i915_wa_registers(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static void i915_global_preemption_config(struct drm_i915_private *i915,
+ u32 val)
+{
+   const u32 bit = GEN12_VFG_PREEMPT_CHICKEN_DISABLE;
+
+   if (val)
+   intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
+  _MASKED_BIT_DISABLE(bit));
+   else
+   intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
+  _MASKED_BIT_ENABLE(bit));
+}
+
+static int i915_global_preempt_support_get(void *data, u64 *val)
+{
+   struct drm_i915_private *i915 = data;
+   intel_wakeref_t wakeref;
+   u32 curr_status = 0;
+
+   if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
+   return -EINVAL;
+
+   with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+   curr_status = intel_uncore_read(&i915->uncore,
+   GEN12_VFG_PREEMPTION_CHICKEN);
+   *val = (curr_status & GEN12_VFG_PREEMPT_CHICKEN_DISABLE) ? 0 : 1;
+
+   return 0;
+}
+
+static int i915_global_preempt_support_set(void *data, u64 val)
+{
+   struct drm_i915_private *i915 = data;
+   intel_wakeref_t wakeref;
+
+   if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
+   return -EINVAL;
+
+   with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+   i915_global_preemption_config(i915, val);
+
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_global_preempt_support_fops,
+   i915_global_preempt_support_get,
+   i915_global_preempt_support_set,
+   "%lld\n");
+
 static int i915_wedged_get(void *data, u64 *val)
 {
struct drm_i915_private *i915 = data;
@@ -765,6 +814,7 @@ static const struct i915_debugfs_files {
const struct file_operations *fops;
 } i915_debugfs_files[] = {
{"i915_perf_noa_delay", &i915_perf_noa_delay_fops},
+   {"i915_global_preempt_support", &i915_global_preempt_support_fops},
{"i915_wedged", &i915_wedged_fops},
{"i915_gem_drop_caches", &i915_drop_caches_fops},
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 457bc1993d19..8c3f69c87d36 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1407,6 +1407,9 @@ IS_SUBPLATFORM(con

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Make the PIPESC rect relative to the entire bigjoiner area

2022-03-03 Thread Navare, Manasi

On Wed, Feb 23, 2022 at 03:13:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> When using bigjoiner it's useful to know the offset of each
> individual pipe in the whole set of joined pipes. Let's include
> that information in our PIPESRC rectangle. With this we can make
> the plane clipping code blissfully unaware of bigjoiner usage, as
> all we have to do is remove the pipe's offset from the final plane
> destination coordinates.
> 
> v2: Use intel_bigjoiner_num_pipes()
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  7 +++---
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  8 ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 21 ++
>  drivers/gpu/drm/i915/display/intel_overlay.c  | 22 +--
>  4 files changed, 40 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 3cbf66146da0..92ae4eebc62f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -824,10 +824,6 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
>   return -ERANGE;
>   }
>  
> - /* right side of the image is on the slave crtc, adjust dst to match */
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(dst, -drm_rect_width(&crtc_state->pipe_src), 
> 0);
> -
>   /*
>* FIXME: This might need further adjustment for seamless scaling
>* with phase information, for the 2p2 and 2p1 scenarios.
> @@ -844,6 +840,9 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
>   return -EINVAL;
>   }
>  
> + /* final plane coordinates will be relative to the plane's pipe */
> + drm_rect_translate(dst, -clip->x1, -clip->y1);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index da6cf0515164..9279e2783e7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -152,9 +152,11 @@ static int intel_check_cursor(struct intel_crtc_state 
> *crtc_state,
>   /* Use the unclipped src/dst rectangles, which we program to hw */
>   plane_state->uapi.src = src;
>   plane_state->uapi.dst = dst;
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(&plane_state->uapi.dst,
> --drm_rect_width(&crtc_state->pipe_src), 0);
> +
> + /* final plane coordinates will be relative to the plane's pipe */
> + drm_rect_translate(&plane_state->uapi.dst,
> +-crtc_state->pipe_src.x1,
> +-crtc_state->pipe_src.y1);
>  
>   ret = intel_cursor_check_surface(plane_state);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7a09bb33c1eb..a9c15f27b948 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3204,6 +3204,23 @@ static void intel_get_transcoder_timings(struct 
> intel_crtc *crtc,
>   }
>  }
>  
> +static void intel_bigjoiner_adjust_pipe_src(struct intel_crtc_state 
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> + enum pipe master_pipe, pipe = crtc->pipe;
> + int width;
> +
> + if (num_pipes < 2)
> + return;
> +
> + master_pipe = bigjoiner_master_pipe(crtc_state);
> + width = drm_rect_width(&crtc_state->pipe_src);
> +
> + drm_rect_translate_to(&crtc_state->pipe_src,
> +   (pipe - master_pipe) * width, 0);
> +}
> +
>  static void intel_get_pipe_src_size(struct intel_crtc *crtc,
>   struct intel_crtc_state *pipe_config)
>  {
> @@ -3216,6 +3233,8 @@ static void intel_get_pipe_src_size(struct intel_crtc 
> *crtc,
>   drm_rect_init(&pipe_config->pipe_src, 0, 0,
> REG_FIELD_GET(PIPESRC_WIDTH_MASK, tmp) + 1,
> REG_FIELD_GET(PIPESRC_HEIGHT_MASK, tmp) + 1);
> +
> + intel_bigjoiner_adjust_pipe_src(pipe_config);
>  }
>  
>  static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state)
> @@ -5853,6 +5872,8 @@ intel_modeset_pipe_config_late(struct intel_crtc_state 
> *crtc_state)
>   struct drm_connector *connector;
>   int i;
>  
> + intel_bigjoiner_adjust_pipe_src(crtc_state);
> +
>   for_each_new_connector_in_state(&state->base, connector,
>   conn_state, i) {
>   struct intel_encoder *encoder =
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index

[Intel-gfx] [PATCH v3 4/4] drm/i915: Improve long running OCL w/a for GuC submission

2022-03-03 Thread John . C . Harrison

From: John Harrison 

A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.

However, this does not work well in GuC submission mode. In GuC mode,
the pre-emption timeout is how GuC detects hung contexts and triggers
a per engine reset. Thus, disabling the timeout means also losing all
per engine reset ability. A full GT reset will still occur when the
heartbeat finally expires, but that is a much more destructive and
undesirable mechanism.

The purpose of the workaround is actually to give OpenCL tasks longer
to reach a pre-emption point after a pre-emption request has been
issued. This is necessary because Gen12 does not support mid-thread
pre-emption and OpenCL can have long running threads.

So, rather than disabling the timeout completely, just set it to a
'long' value.

v2: Review feedback from Tvrtko - must hard code the 'long' value
instead of determining it algorithmically. So make it an extra CONFIG
definition. Also, remove the execlist centric comment from the
existing pre-emption timeout CONFIG option given that it applies to
more than just execlists.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio  (v1)
Acked-by: Michal Mrozek 
---
 drivers/gpu/drm/i915/Kconfig.profile  | 26 +++
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 ++--
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile
index 39328567c200..7cc38d25ee5c 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT
default 640 # milliseconds
help
  How long to wait (in milliseconds) for a preemption event to occur
- when submitting a new context via execlists. If the current context
- does not hit an arbitration point and yield to HW before the timer
- expires, the HW will be reset to allow the more important context
- to execute.
+ when submitting a new context. If the current context does not hit
+ an arbitration point and yield to HW before the timer expires, the
+ HW will be reset to allow the more important context to execute.
+
+ This is adjustable via
+ /sys/class/drm/card?/engine/*/preempt_timeout_ms
+
+ May be 0 to disable the timeout.
+
+ The compiled in default may get overridden at driver probe time on
+ certain platforms and certain engines which will be reflected in the
+ sysfs control.
+
+config DRM_I915_PREEMPT_TIMEOUT_COMPUTE
+   int "Preempt timeout for compute engines (ms, jiffy granularity)"
+   default 7500 # milliseconds
+   help
+ How long to wait (in milliseconds) for a preemption event to occur
+ when submitting a new context to a compute capable engine. If the
+ current context does not hit an arbitration point and yield to HW
+ before the timer expires, the HW will be reset to allow the more
+ important context to execute.
 
  This is adjustable via
  /sys/class/drm/card?/engine/*/preempt_timeout_ms
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4185c7338581..cc0954ad836a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -438,9 +438,14 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->props.timeslice_duration_ms =
CONFIG_DRM_I915_TIMESLICE_DURATION;
 
-   /* Override to uninterruptible for OpenCL workloads. */
+   /*
+* Mid-thread pre-emption is not available in Gen12. Unfortunately,
+* some OpenCL workloads run quite long threads. That means they get
+* reset due to not pre-empting in a timely manner. So, bump the
+* pre-emption timeout value to be much higher for compute engines.
+*/
if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
I915_ENGINE_HAS_RCS_REG_STATE))
-   engine->props.preempt_timeout_ms = 0;
+   engine->props.preempt_timeout_ms = 
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE;
 
/* Cap properties according to any system limits */
 #define CLAMP_PROP(field) \
-- 
2.25.1

[Intel-gfx] [PATCH v3 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

2022-03-03 Thread John . C . Harrison

From: John Harrison 

Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence the
next patch will re-enable the timeout but bumped up by an order of
magnitude.

However, the heartbeat might not respect that. Depending upon current
activity, a pre-emption to the heartbeat pulse might not even be
attempted until the last heartbeat period. Which means that only one
period is granted for the pre-emption to occur. With the aforesaid
bump, the pre-emption timeout could be significantly larger than this
heartbeat period.

So adjust the heartbeat code to take the pre-emption timeout into
account. When it reaches the final (high priority) period, it now
ensures the delay before hitting reset is bigger than the pre-emption
timeout.

v2: Fix for selftests which adjust the heartbeat period manually.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c   | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index a3698f611f45..0dc53def8e42 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -22,9 +22,27 @@
 
 static bool next_heartbeat(struct intel_engine_cs *engine)
 {
+   struct i915_request *rq;
long delay;
 
delay = READ_ONCE(engine->props.heartbeat_interval_ms);
+
+   rq = engine->heartbeat.systole;
+
+   if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER &&
+   delay == engine->defaults.heartbeat_interval_ms) {
+   long longer;
+
+   /*
+* The final try is at the highest priority possible. Up until 
now
+* a pre-emption might not even have been attempted. So make 
sure
+* this last attempt allows enough time for a pre-emption to 
occur.
+*/
+   longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
+   if (longer > delay)
+   delay = longer;
+   }
+
if (!delay)
return false;
 
-- 
2.25.1

[Intel-gfx] [PATCH v3 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow

2022-03-03 Thread John . C . Harrison

From: John Harrison 

GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
then get confused by early timeouts, add limits when setting these
values.

v2: Add helper functins for clamping (review feedback from Tvrtko).

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio  (v1)
---
 drivers/gpu/drm/i915/gt/intel_engine.h  |  6 ++
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 69 +
 drivers/gpu/drm/i915/gt/sysfs_engines.c | 25 +---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  9 +++
 4 files changed, 99 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1c0ab05c3c40..d7044c4e526e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -351,4 +351,10 @@ intel_engine_get_hung_context(struct intel_engine_cs 
*engine)
return engine->hung_ce;
 }
 
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 
value);
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64 
value);
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64 
value);
+
 #endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7447411a5b26..22e70e4e007c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -442,6 +442,26 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
}
 
+   /* Cap properties according to any system limits */
+#define CLAMP_PROP(field) \
+   do { \
+   u64 clamp = intel_clamp_##field(engine, engine->props.field); \
+   if (clamp != engine->props.field) { \
+   drm_notice(&engine->i915->drm, \
+  "Warning, clamping %s to %lld to prevent 
overflow\n", \
+  #field, clamp); \
+   engine->props.field = clamp; \
+   } \
+   } while (0)
+
+   CLAMP_PROP(heartbeat_interval_ms);
+   CLAMP_PROP(max_busywait_duration_ns);
+   CLAMP_PROP(preempt_timeout_ms);
+   CLAMP_PROP(stop_timeout_ms);
+   CLAMP_PROP(timeslice_duration_ms);
+
+#undef CLAMP_PROP
+
engine->defaults = engine->props; /* never to change again */
 
engine->context_size = intel_engine_context_size(gt, engine->class);
@@ -464,6 +484,55 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
return 0;
 }
 
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 
value)
+{
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64 
value)
+{
+   value = min(value, jiffies_to_nsecs(2));
+
+   return value;
+}
+
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+   /*
+* NB: The GuC API only supports 32bit values. However, the limit is 
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+   if (intel_guc_submission_is_wanted(&engine->gt->uc.guc))
+   value = min_t(u64, value, GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS);
+
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64 
value)
+{
+   /*
+* NB: The GuC API only supports 32bit values. However, the limit is 
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+   if (intel_guc_submission_is_wanted(&engine->gt->uc.guc))
+   value = min_t(u64, value, GUC_POLICY_MAX_EXEC_QUANTUM_MS);
+
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
 static void __setup_engine_capabilities(struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c 
b/drivers/gpu/drm/i915/gt/sysfs_engines.c
index 967031056202..f2d9858d827c 100644
--- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
@@ -144

[Intel-gfx] [PATCH v3 2/4] drm/i915: Fix compute pre-emption w/a to apply to compute engines

2022-03-03 Thread John . C . Harrison

From: John Harrison 

An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.

Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup functions")
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Cc: Aravind Iddamsetty 
Cc: Matt Roper 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Lucas De Marchi 
Cc: John Harrison 
Cc: Jason Ekstrand 
Cc: "Michał Winiarski" 
Cc: Matthew Brost 
Cc: Chris Wilson 
Cc: Tejas Upadhyay 
Cc: Umesh Nerlige Ramappa 
Cc: "Thomas Hellström" 
Cc: Stuart Summers 
Cc: Matthew Auld 
Cc: Jani Nikula 
Cc: Ramalingam C 
Cc: Akeem G Abodunrin 
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 22e70e4e007c..4185c7338581 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -421,6 +421,12 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->logical_mask = BIT(logical_instance);
__sprint_engine_name(engine);
 
+   /* features common between engines sharing EUs */
+   if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
+   engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
+   engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
+   }
+
engine->props.heartbeat_interval_ms =
CONFIG_DRM_I915_HEARTBEAT_INTERVAL;
engine->props.max_busywait_duration_ns =
@@ -433,15 +439,9 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
CONFIG_DRM_I915_TIMESLICE_DURATION;
 
/* Override to uninterruptible for OpenCL workloads. */
-   if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
+   if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
I915_ENGINE_HAS_RCS_REG_STATE))
engine->props.preempt_timeout_ms = 0;
 
-   /* features common between engines sharing EUs */
-   if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
-   engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
-   engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
-   }
-
/* Cap properties according to any system limits */
 #define CLAMP_PROP(field) \
do { \
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/4] Improve anti-pre-emption w/a for compute workloads

2022-03-03 Thread John . C . Harrison

From: John Harrison 

Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission as
the heartbeat is a full GT reset rather than a per engine reset and so
is much more destructive. Instead, just bump the pre-emption timeout
to a big value. Also, update the heartbeat to allow such a long
pre-emption delay in the final heartbeat period.

v2: Add clamping helpers.
v3: Remove long timeout algorithm and replace with hard coded value
(review feedback from Tvrtko). Also, fix execlist selftest failure and
fix bug in compute enabling patch related to pre-emption timeouts.

Signed-off-by: John Harrison 


John Harrison (4):
  drm/i915/guc: Limit scheduling properties to avoid overflow
  drm/i915: Fix compute pre-emption w/a to apply to compute engines
  drm/i915: Make the heartbeat play nice with long pre-emption timeouts
  drm/i915: Improve long running OCL w/a for GuC submission

 drivers/gpu/drm/i915/Kconfig.profile  | 26 +-
 drivers/gpu/drm/i915/gt/intel_engine.h|  6 ++
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 92 +--
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 18 
 drivers/gpu/drm/i915/gt/sysfs_engines.c   | 25 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  9 ++
 6 files changed, 153 insertions(+), 23 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH 2/2] drm/i915: Add RCS mask to GuC ADS params

2022-03-03 Thread Matt Roper

From: Stuart Summers 

If RCS is not enumerated, GuC will return invalid parameters.
Make sure we do not send RCS supported when we have not enumerated
it.

Cc: Vinay Belgaumkar 
Signed-off-by: Stuart Summers 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 32c2053f2f08..acc4a3766dc1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -433,7 +433,7 @@ static void guc_mmio_reg_state_init(struct intel_guc *guc)
 static void fill_engine_enable_masks(struct intel_gt *gt,
 struct iosys_map *info_map)
 {
-   info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 1);
+   info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 
RCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_COMPUTE_CLASS], 
CCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS], 
VDBOX_MASK(gt));
-- 
2.34.1

[Intel-gfx] [PATCH 1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS

2022-03-03 Thread Matt Roper

In the past we've always assumed that an RCS engine is present on every
platform.  However now that we have compute engines there may be
platforms that have CCS engines but no RCS, or platforms that are
designed to have both, but have the RCS engine fused off.

Various engine-centric initialization that only needs to be done a
single time for the group of RCS+CCS engines can't rely on being setup
with the RCS now; instead we add a I915_ENGINE_FIRST_RENDER_COMPUTE flag
that will be assigned to a single engine in the group; whichever engine
has this flag will be responsible for some of the general setup
(RCU_MODE programming, initialization of certain workarounds, etc.).

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 5 +
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c  | 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c   | 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 7 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7447411a5b26..8080479f27aa 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -436,6 +436,11 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
engine->props.preempt_timeout_ms = 0;
 
+   if ((engine->class == COMPUTE_CLASS && !RCS_MASK(engine->gt) &&
+__ffs(CCS_MASK(engine->gt)) == engine->instance) ||
+engine->class == RENDER_CLASS)
+   engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE;
+
/* features common between engines sharing EUs */
if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 19ff8758e34d..4fbf45a74ec0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -97,6 +97,7 @@ struct i915_ctx_workarounds {
 #define I915_MAX_VCS   8
 #define I915_MAX_VECS  4
 #define I915_MAX_CCS   4
+#define I915_MAX_RCS   1
 
 /*
  * Engine IDs definitions.
@@ -526,6 +527,7 @@ struct intel_engine_cs {
 #define I915_ENGINE_WANT_FORCED_PREEMPTION BIT(8)
 #define I915_ENGINE_HAS_RCS_REG_STATE  BIT(9)
 #define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
+#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
unsigned int flags;
 
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 1c602d4ae297..e1470bb60f34 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2912,7 +2912,7 @@ static int execlists_resume(struct intel_engine_cs 
*engine)
 
enable_execlists(engine);
 
-   if (engine->class == RENDER_CLASS)
+   if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
xehp_enable_ccs_engines(engine);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index c014b40d2e9f..beca8735bae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2633,7 +2633,7 @@ engine_init_workarounds(struct intel_engine_cs *engine, 
struct i915_wa_list *wal
 * to a single RCS/CCS engine's workaround list since
 * they're reset as part of the general render domain reset.
 */
-   if (engine->class == RENDER_CLASS)
+   if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
general_render_compute_wa_init(engine, wal);
 
if (engine->class == RENDER_CLASS)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 9bb551b83e7a..32c2053f2f08 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -335,7 +335,7 @@ static int guc_mmio_regset_init(struct temp_regset *regset,
ret |= GUC_MMIO_REG_ADD(regset, RING_HWS_PGA(base), false);
ret |= GUC_MMIO_REG_ADD(regset, RING_IMR(base), false);
 
-   if (engine->class == RENDER_CLASS &&
+   if ((engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE) &&
CCS_MASK(engine->gt))
ret |= GUC_MMIO_REG_ADD(regset, GEN12_RCU_MODE, true);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 1ce7e04aa837..8a8bb87e77a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/

Re: [Intel-gfx] [PATCH v2 12/13] drm/i915: Use bigjoiner_pipes more

2022-03-03 Thread Navare, Manasi

On Thu, Feb 24, 2022 at 12:35:59PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 23, 2022 at 12:00:28PM -0800, Navare, Manasi wrote:
> > On Wed, Feb 23, 2022 at 03:13:14PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Replace the hardcoded 2 pipe assumptions when we're massaging
> > > pipe_mode and the pipe_src rect to be suitable for bigjoiner.
> > > Instead we can just count the number of pipes in the bitmask.
> > > 
> > > v2: Introduce intel_bigjoiner_num_pipes()
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 31 +---
> > >  1 file changed, 20 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 9b4013ed3d98..7a09bb33c1eb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -368,6 +368,11 @@ bool intel_crtc_is_bigjoiner_master(const struct 
> > > intel_crtc_state *crtc_state)
> > >   crtc->pipe == bigjoiner_master_pipe(crtc_state);
> > >  }
> > >  
> > > +static int intel_bigjoiner_num_pipes(const struct intel_crtc_state 
> > > *crtc_state)
> > > +{
> > > + return hweight8(crtc_state->bigjoiner_pipes);
> > > +}
> > 
> > Okay yes makes sense. Although bigjoiner will always be between just 2 
> > pipes so why not hardcode to 2 and
> > use the  if (!crtc_state->bigjoiner_pipes) as the check instead of 
> > num_pipes < 2.
> > When we have a joiner for 4 pipes, in that case also bigjoiner will still 
> > be only between 2 pipes.
> > So in bigjoiner_pipe mask, it will always only have 2 pipes.
> 
> It'll be whatever pipes we have when we have more pipes.

Okay agreed might be good from scalability pov

Reviewed-by: Manasi Navare 

Manasi

> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH v2 10/13] drm/i915: Start tracking PIPESRC as a drm_rect

2022-03-03 Thread Navare, Manasi

On Wed, Feb 23, 2022 at 03:13:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Instead of just having the pipe_src_{w,h} let's use a full
> drm_rect for it. This will be particularly useful to astract
> away some bigjoiner details.
> 
> v2: No hweight() stuff yet
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 15 ++--
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 55 ++-
>  .../drm/i915/display/intel_display_debugfs.c  |  4 +-
>  .../drm/i915/display/intel_display_types.h|  2 +-
>  drivers/gpu/drm/i915/display/intel_overlay.c  | 12 ++--
>  drivers/gpu/drm/i915/display/intel_panel.c| 70 +--
>  drivers/gpu/drm/i915/display/skl_scaler.c | 12 ++--
>  .../drm/i915/display/skl_universal_plane.c|  2 +-
>  9 files changed, 96 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index c53aa6a4c7a0..3cbf66146da0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -803,8 +803,8 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
>   struct drm_framebuffer *fb = plane_state->hw.fb;
>   struct drm_rect *src = &plane_state->uapi.src;
>   struct drm_rect *dst = &plane_state->uapi.dst;
> + const struct drm_rect *clip = &crtc_state->pipe_src;
>   unsigned int rotation = plane_state->hw.rotation;
> - struct drm_rect clip = {};
>   int hscale, vscale;
>  
>   if (!fb) {
> @@ -824,28 +824,23 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
>   return -ERANGE;
>   }
>  
> - if (crtc_state->hw.enable) {
> - clip.x2 = crtc_state->pipe_src_w;
> - clip.y2 = crtc_state->pipe_src_h;
> - }
> -
>   /* right side of the image is on the slave crtc, adjust dst to match */
>   if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - drm_rect_translate(dst, -crtc_state->pipe_src_w, 0);
> + drm_rect_translate(dst, -drm_rect_width(&crtc_state->pipe_src), 
> 0);
>  
>   /*
>* FIXME: This might need further adjustment for seamless scaling
>* with phase information, for the 2p2 and 2p1 scenarios.
>*/
> - plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, &clip);
> + plane_state->uapi.visible = drm_rect_clip_scaled(src, dst, clip);
>  
>   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
>  
>   if (!can_position && plane_state->uapi.visible &&
> - !drm_rect_equals(dst, &clip)) {
> + !drm_rect_equals(dst, clip)) {
>   drm_dbg_kms(&i915->drm, "Plane must cover entire CRTC\n");
>   drm_rect_debug_print("dst: ", dst, false);
> - drm_rect_debug_print("clip: ", &clip, false);
> + drm_rect_debug_print("clip: ", clip, false);
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 3e80763aa828..1f448f4e9aaf 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -154,7 +154,7 @@ static int intel_check_cursor(struct intel_crtc_state 
> *crtc_state,
>   plane_state->uapi.dst = dst;
>   if (intel_crtc_is_bigjoiner_slave(crtc_state))
>   drm_rect_translate(&plane_state->uapi.dst,
> --crtc_state->pipe_src_w, 0);
> +-drm_rect_width(&crtc_state->pipe_src), 0);
>  
>   ret = intel_cursor_check_surface(plane_state);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f0d51555617e..d3ffa62952bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2687,8 +2687,8 @@ static u32 ilk_pipe_pixel_rate(const struct 
> intel_crtc_state *crtc_state)
>   return pixel_rate;
>  
>   drm_rect_init(&src, 0, 0,
> -   crtc_state->pipe_src_w << 16,
> -   crtc_state->pipe_src_h << 16);
> +   drm_rect_width(&crtc_state->pipe_src) << 16,
> +   drm_rect_height(&crtc_state->pipe_src) << 16);
>  
>   return intel_adjusted_rate(&src, &crtc_state->pch_pfit.dst,
>  pixel_rate);
> @@ -2792,8 +2792,8 @@ static void intel_crtc_readout_derived_state(struct 
> intel_crtc_state *crtc_state
>   /* Populate the "user" mode with full numbers */
>   drm_mode_copy(mode, pipe_mode);
>   intel_mode_from_crtc_timings(mode, mode);
> - mode->hdisplay = crtc_state->pipe_src_w << crtc_state->bigjoiner;
> -

[Intel-gfx] ✓ Fi.CI.BAT: success for Bump DMC to v2.16 on ADL-P (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Bump DMC to v2.16 on ADL-P (rev2)
URL   : https://patchwork.freedesktop.org/series/100666/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22480


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 43)
--

  Additional (2): fi-icl-u2 fi-pnv-d510 
  Missing(5): fi-bdw-5557u shard-tglu shard-rkl shard-dg1 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +39 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][8] -> [FAIL][9] ([i915#4032])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live:
- fi-skl-6600u:   NOTRUN -> [FAIL][10] ([i915#4547])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@i915_selft...@live.html

  * igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][11] ([i915#2927] / [i915#4528])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][12] -> [INCOMPLETE][13] ([i915#4983])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][17] ([fdo#109271]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([fdo#109285])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size

2022-03-03 Thread Patchwork

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
URL   : https://patchwork.freedesktop.org/series/101016/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22479


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 39)
--

  Missing(7): fi-rkl-guc shard-tglu fi-kbl-7500u fi-kbl-8809g shard-rkl 
shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gt_lrc:
- {bat-dg2-9}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
- {bat-adlp-6}:   [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html

  * igt@kms_frontbuffer_tracking@basic:
- {bat-dg2-9}:NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- {bat-dg2-9}:NOTRUN -> [DMESG-WARN][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg2-9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@prime_vgem@basic-write:
- {bat-dg2-9}:NOTRUN -> [SKIP][6] +16 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg2-9/igt@prime_v...@basic-write.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][8] -> [FAIL][9] ([i915#4032])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [PASS][10] -> [INCOMPLETE][11] ([i915#4418])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@runner@aborted:
- bat-dg1-5:  NOTRUN -> [FAIL][12] ([i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg1-5/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][13] ([i915#2426] / [i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@fbdev@eof:
- {bat-dg2-9}:[FAIL][14] ([i915#5186]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg2-9/igt@fb...@eof.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg2-9/igt@fb...@eof.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][16] ([i915#4957]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[INCOMPLETE][18] ([i915#4785]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][20] -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@vma:
- {bat-rpls-2}:   [DMESG-WARN][22] ([i915#4391]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@vma.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/bat-rpls-2/igt@i915_selftest@l...@v

[Intel-gfx] 2022 X.Org Board of Directors Elections timeline extended, Request for nominations

2022-03-03 Thread Lyude Paul

We are seeking nominations for candidates for election to the X.org Foundation
Board of Directors. However, as we presently do not have enough nominations to
start the election - the decision has been made to extend the timeline by 2
weeks. Note this is a fairly regular part of the elections process.

The new deadline for nominations to the X.org Board of Directors is 23:59 UTC
on 20th March 2022.

The Board consists of directors elected from the membership.  Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.

The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by the
Board of Directors.

A member may nominate themselves or any other member they feel is qualified.
Nominations should be sent to the Election Committee at elections at x.org.

Nominees shall be required to be current members of the X.Org Foundation, and
submit a personal statement of up to 200 words that will be provided to
prospective voters.  The collected statements, along with the statement of
contribution to the X.Org Foundation in the member's account page on
http://members.x.org, will be made available to all voters to help them make
their voting decisions.

Nominations, membership applications or renewals and completed personal
statements must be received no later than 23:59 UTC on 20th March 2022.

The slate of candidates will be published 28th March 2022 and candidate Q&A
will begin then. The deadline for Xorg membership applications and renewals is
31st March 2022.

Cheers,
   Lyude Paul, on behalf of the X.Org BoD

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/selftests: fix a shift-out-of-bounds bug

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/selftests: fix a shift-out-of-bounds bug
URL   : https://patchwork.freedesktop.org/series/101012/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22478


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 42)
--

  Additional (2): fi-icl-u2 fi-pnv-d510 
  Missing(6): fi-bdw-5557u shard-tglu fi-bdw-gvtdvm shard-rkl shard-dg1 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +57 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][8] -> [FAIL][9] ([i915#4032])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([fdo#109278]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][13] ([fdo#109271]) +4 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-icl-u2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [INCOMPLETE][17] ([i915#4547]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][19] ([i915#4957]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-6/igt@i915_selftest@l...@hangcheck.ht

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl-n: Add stepping info

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/adl-n: Add stepping info
URL   : https://patchwork.freedesktop.org/series/100995/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11318_full -> Patchwork_22472_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_balancer@full-pulse:
- {shard-dg1}:[SKIP][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-dg1-15/igt@gem_exec_balan...@full-pulse.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-dg1-12/igt@gem_exec_balan...@full-pulse.html

  * 
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][3] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html

  * igt@prime_mmap_coherency@ioctl-errors:
- {shard-dg1}:NOTRUN -> [SKIP][4] +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-dg1-16/igt@prime_mmap_cohere...@ioctl-errors.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], 
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], 
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], 
[PASS][27], [PASS][28], [FAIL][29]) ([i915#4392]) -> ([PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk1/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk1/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk8/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk6/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk5/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk5/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/shard-glk4/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-glk1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-glk1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-glk1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/shard-glk2/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_2247

[Intel-gfx] [CI 2/2] drm/i915/dpt: setup dummy scratch

2022-03-03 Thread Matthew Auld

We currently blow up in i915_vm_lock_objects when binding the dpt, due
to what looks like NULL scratch[0]. Likely the moving fence has not been
unset yet(even though it should have signalled), due to some previous
move. For now let's just create something which more closely resembles a
proper vm.

Signed-off-by: Matthew Auld 
Cc: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 53 
 1 file changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 15b2716172f7..ab74ce2bce04 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -4,6 +4,7 @@
  */
 
 #include "gem/i915_gem_domain.h"
+#include "gem/i915_gem_internal.h"
 #include "gt/gen8_ppgtt.h"
 
 #include "i915_drv.h"
@@ -116,6 +117,7 @@ static void dpt_cleanup(struct i915_address_space *vm)
 {
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
 
+   i915_gem_object_put(vm->scratch[0]);
i915_gem_object_put(dpt->obj);
 }
 
@@ -230,17 +232,40 @@ void intel_dpt_suspend(struct drm_i915_private *i915)
mutex_unlock(&i915->drm.mode_config.fb_lock);
 }
 
+static int scratch_dummy_obj_get_pages(struct drm_i915_gem_object *obj)
+{
+   obj->mm.pages = ZERO_SIZE_PTR;
+   return 0;
+}
+
+static void scratch_dummy_obj_put_pages(struct drm_i915_gem_object *obj,
+   struct sg_table *pages)
+{
+}
+
+static const struct drm_i915_gem_object_ops scratch_dummy_obj_ops = {
+   .name = "scratch_dummy_obj",
+   .get_pages = scratch_dummy_obj_get_pages,
+   .put_pages = scratch_dummy_obj_put_pages,
+};
+
 struct i915_address_space *
 intel_dpt_create(struct intel_framebuffer *fb)
 {
struct drm_gem_object *obj = &intel_fb_obj(&fb->base)->base;
struct drm_i915_private *i915 = to_i915(obj->dev);
-   struct drm_i915_gem_object *dpt_obj;
+   struct drm_i915_gem_object *dpt_obj, *scratch;
struct i915_address_space *vm;
struct i915_dpt *dpt;
size_t size;
int ret;
 
+   scratch = __i915_gem_object_create_internal(i915,
+   &scratch_dummy_obj_ops,
+   SZ_4K);
+   if (IS_ERR(scratch))
+   return ERR_CAST(scratch);
+
if (intel_fb_needs_pot_stride_remap(fb))
size = 
intel_remapped_info_size(&fb->remapped_view.gtt.remapped);
else
@@ -252,23 +277,23 @@ intel_dpt_create(struct intel_framebuffer *fb)
dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
else
dpt_obj = i915_gem_object_create_stolen(i915, size);
-   if (IS_ERR(dpt_obj))
-   return ERR_CAST(dpt_obj);
+   if (IS_ERR(dpt_obj)) {
+   ret = PTR_ERR(dpt_obj);
+   goto err_put_scratch;
+   }
 
ret = i915_gem_object_lock_interruptible(dpt_obj, NULL);
if (!ret) {
ret = i915_gem_object_set_cache_level(dpt_obj, I915_CACHE_NONE);
i915_gem_object_unlock(dpt_obj);
}
-   if (ret) {
-   i915_gem_object_put(dpt_obj);
-   return ERR_PTR(ret);
-   }
+   if (ret)
+   goto err_put_dpt;
 
dpt = kzalloc(sizeof(*dpt), GFP_KERNEL);
if (!dpt) {
-   i915_gem_object_put(dpt_obj);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto err_put_dpt;
}
 
vm = &dpt->vm;
@@ -281,6 +306,10 @@ intel_dpt_create(struct intel_framebuffer *fb)
 
i915_address_space_init(vm, VM_CLASS_DPT);
 
+   scratch->base.resv = i915_vm_resv_get(vm);
+   scratch->shares_resv_from = vm;
+   vm->scratch[0] = scratch;
+
vm->insert_page = dpt_insert_page;
vm->clear_range = dpt_clear_range;
vm->insert_entries = dpt_insert_entries;
@@ -294,6 +323,12 @@ intel_dpt_create(struct intel_framebuffer *fb)
dpt->obj = dpt_obj;
 
return &dpt->vm;
+
+err_put_dpt:
+   i915_gem_object_put(dpt_obj);
+err_put_scratch:
+   i915_gem_object_put(scratch);
+   return ERR_PTR(ret);
 }
 
 void intel_dpt_destroy(struct i915_address_space *vm)
-- 
2.34.1

[Intel-gfx] [CI 1/2] drm/i915/fbdev: fixup setting screen_size

2022-03-03 Thread Matthew Auld

Since we are actually mapping the object and not the vma, when dealing
with LMEM, we should be careful and use the obj->base.size here, since
the vma could have all kinds of funny padding constraints.

Signed-off-by: Matthew Auld 
Cc: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 2cd62a187df3..3167ae334684 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -290,7 +290,10 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unpin;
}
info->screen_base = vaddr;
-   info->screen_size = vma->node.size;
+   if (i915_gem_object_is_lmem(obj))
+   info->screen_size = vma->obj->base.size;
+   else
+   info->screen_size = vma->node.size;
 
drm_fb_helper_fill_info(info, &ifbdev->helper, sizes);
 
-- 
2.34.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/selftests: fix a shift-out-of-bounds bug

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/selftests: fix a shift-out-of-bounds bug
URL   : https://patchwork.freedesktop.org/series/101012/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
233edfd3e6e2 drm/selftests: fix a shift-out-of-bounds bug
-:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#47: 


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix bandwith related cdclk calculations (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix bandwith related cdclk calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/98975/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22477


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 42)
--

  Additional (1): fi-icl-u2 
  Missing(5): fi-bdw-5557u shard-tglu shard-rkl shard-dg1 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][5] -> [FAIL][6] ([i915#4032])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([fdo#109278]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][9] ([fdo#109285])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([i915#3301])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-icl-u2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][11] ([i915#4785]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [INCOMPLETE][15] ([i915#4983]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@vma:
- {bat-rpls-2}:   [DMESG-WARN][17] ([i915#4391]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@vma.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-rpls-2/igt@i915_selftest@l...@vma.html

  * igt@i915_selftest@live@workarounds:
- {bat-adlp-6}:   [DMESG-WARN][19] ([i915#5068]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-adlp-6/igt@i915_selftest@l...@workarounds.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][21] ([i915#4957]) -> [DMESG-FAIL][22] 
([i915#4494] / [i915#4957])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/bat-dg1-6/igt

Re: [Intel-gfx] [PATCH 4/5] drm/i915/gmbus: alloc intel_gmbus dynamically

2022-03-03 Thread Ville Syrjälä

On Thu, Mar 03, 2022 at 08:19:30PM +0200, Jani Nikula wrote:
> Allocate the individual intel_gmbus structs dynamically. This lets us
> hide struct intel_gmbus inside intel_gmbus.c completely. Also use the
> cleanup function on the error path to avoid duplication.
> 
> Leave #include  in i915_drv.h for now, as it pulls in a
> bunch of implicit dependencies.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_gmbus.c | 42 +++---
>  drivers/gpu/drm/i915/i915_drv.h| 14 ++--
>  2 files changed, 31 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index fd908e524875..2bb3494b93e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -38,6 +38,16 @@
>  #include "intel_display_types.h"
>  #include "intel_gmbus.h"
>  
> +struct intel_gmbus {
> + struct i2c_adapter adapter;
> +#define GMBUS_FORCE_BIT_RETRY (1U << 31)
> + u32 force_bit;
> + u32 reg0;
> + i915_reg_t gpio_reg;
> + struct i2c_algo_bit_data bit_algo;
> + struct drm_i915_private *dev_priv;
> +};
> +
>  struct gmbus_pin {
>   const char *name;
>   enum i915_gpio gpio;
> @@ -881,7 +891,11 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
>   if (!gmbus_pin)
>   continue;
>  
> - bus = &dev_priv->gmbus[pin];
> + bus = kzalloc(sizeof(*bus), GFP_KERNEL);
> + if (!bus) {
> + ret = -ENOMEM;
> + goto err;
> + }
>  
>   bus->adapter.owner = THIS_MODULE;
>   bus->adapter.class = I2C_CLASS_DDC;
> @@ -911,8 +925,12 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
>   intel_gpio_setup(bus, GPIO(gmbus_pin->gpio));
>  
>   ret = i2c_add_adapter(&bus->adapter);
> - if (ret)
> + if (ret) {
> + kfree(bus);
>   goto err;
> + }
> +
> + dev_priv->gmbus[pin] = bus;
>   }
>  
>   intel_gmbus_reset(dev_priv);
> @@ -920,24 +938,19 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
>   return 0;
>  
>  err:
> - while (pin--) {
> - if (!intel_gmbus_is_valid_pin(dev_priv, pin))
> - continue;
> + intel_gmbus_teardown(dev_priv);
>  
> - bus = &dev_priv->gmbus[pin];
> - i2c_del_adapter(&bus->adapter);
> - }
>   return ret;
>  }
>  
>  struct i2c_adapter *intel_gmbus_get_adapter(struct drm_i915_private 
> *dev_priv,
>   unsigned int pin)
>  {
> - if (drm_WARN_ON(&dev_priv->drm,
> - !intel_gmbus_is_valid_pin(dev_priv, pin)))
> + if (drm_WARN_ON(&dev_priv->drm, pin >= ARRAY_SIZE(dev_priv->gmbus) ||
> + !dev_priv->gmbus[pin]))
>   return NULL;
>  
> - return &dev_priv->gmbus[pin].adapter;
> + return &dev_priv->gmbus[pin]->adapter;
>  }
>  
>  void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
> @@ -969,10 +982,13 @@ void intel_gmbus_teardown(struct drm_i915_private 
> *dev_priv)
>   unsigned int pin;
>  
>   for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
> - if (!intel_gmbus_is_valid_pin(dev_priv, pin))
> + bus = dev_priv->gmbus[pin];

nit: Would like the 'bus' variable to be declared inside the loop.
Same for intel_gmbus_setup().

> + if (!bus)
>   continue;
>  
> - bus = &dev_priv->gmbus[pin];
>   i2c_del_adapter(&bus->adapter);
> +
> + kfree(bus);
> + dev_priv->gmbus[pin] = NULL;

I see we don't actually check intel_gmbus_setup() return value at all so
intel_gmbus_teardown() can get called twice. So this NULLing is essential
should intel_gmbus_setup() ever fail.

Series is
Reviewed-by: Ville Syrjälä 

>   }
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 457bc1993d19..869a2bda347b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -35,7 +35,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -99,6 +98,7 @@ struct intel_dpll_funcs;
>  struct intel_encoder;
>  struct intel_fbdev;
>  struct intel_fdi_funcs;
> +struct intel_gmbus;
>  struct intel_hotplug_funcs;
>  struct intel_initial_plane_config;
>  struct intel_limit;
> @@ -231,16 +231,6 @@ struct i915_drrs {
>  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
>  #define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
>  
> -struct intel_gmbus {
> - struct i2c_adapter adapter;
> -#define GMBUS_FORCE_BIT_RETRY (1U << 31)
> - u32 force_bit;
> - u32 reg0;
> - i915_reg_t gpio_reg;
> - struct i2c_algo_bit_data bit_algo;
> - struct drm_i915_private *dev_priv;
>

Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Add cdclk check to atomic check

2022-03-03 Thread Srivatsa, Anusha




> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, March 3, 2022 1:59 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Add cdclk check to atomic
> check
> 
> On Wed, 02 Mar 2022, Anusha Srivatsa  wrote:
> > Checking cdclk conditions during atomic check and preparing for commit
> > phase so we can have atomic commit as simple as possible. Add the
> > specific steps to be taken during cdclk changes, prepare for
> > squashing, crawling and modeset scenarios.
> >
> > Rename functions intel_cdclk_can_squash() and
> > intel_cdclk_can_crawl() since they no longer simply check if squashing
> > and crawling can be performed.
> 
> IMO the patch is doing too much at once. There's adding parameters (can be
> done separately at first), there's renames (can be done separately
> afterwards), there's functional changes, all in one.
> 
> If you got a bisect result pointing at this commit as regressing, would you
> able to easily figure out what went wrong?

Agreed. Splitting would be good.

> Some comments inline too.
> 
> BR,
> Jani.
> 
> >
> > Cc: Stanislav Lisovskiy 
> > Cc: Matt Roper 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c| 169 +++---
> >  drivers/gpu/drm/i915/display/intel_cdclk.h|  16 +-
> >  .../drm/i915/display/intel_display_power.c|   2 +-
> >  3 files changed, 123 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fda8b701..04f3f77ef0a8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1700,12 +1700,23 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> >   const struct intel_cdclk_config *cdclk_config,
> >   enum pipe pipe)
> >  {
> > +   struct intel_atomic_state *state;
> > +   struct intel_cdclk_state *new_cdclk_state;
> > +   struct cdclk_steps *cdclk_steps;
> > +   struct intel_cdclk_state *cdclk_state;
> > int cdclk = cdclk_config->cdclk;
> > int vco = cdclk_config->vco;
> > +   u32 squash_ctl = 0;
> > u32 val;
> > u16 waveform;
> > int clock;
> > int ret;
> > +   int i;
> > +
> > +   cdclk_state =  to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> > +   state = cdclk_state->base.state;
> > +   new_cdclk_state = intel_atomic_get_new_cdclk_state(state);
> > +   cdclk_steps = new_cdclk_state->steps;
> >
> > /* Inform power controller of upcoming frequency change. */
> > if (DISPLAY_VER(dev_priv) >= 11)
> > @@ -1728,40 +1739,43 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > return;
> > }
> >
> > -   if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 &&
> vco > 0) {
> > -   if (dev_priv->cdclk.hw.vco != vco)
> > +   for (i = 0; i < CDCLK_ACTIONS; i++) {
> > +   switch (cdclk_steps[i].action) {
> > +   case CDCLK_MODESET:
> > +   if (DISPLAY_VER(dev_priv) >= 11) {
> > +   if (dev_priv->cdclk.hw.vco != 0 &&
> > +   dev_priv->cdclk.hw.vco != vco)
> > +   icl_cdclk_pll_disable(dev_priv);
> > +
> > +   if (dev_priv->cdclk.hw.vco != vco)
> > +   icl_cdclk_pll_enable(dev_priv, vco);
> > +   } else {
> > +   if (dev_priv->cdclk.hw.vco != 0 &&
> > +   dev_priv->cdclk.hw.vco != vco)
> > +   bxt_de_pll_disable(dev_priv);
> > +
> > +   if (dev_priv->cdclk.hw.vco != vco)
> > +   bxt_de_pll_enable(dev_priv, vco);
> > +   }
> > +   clock = cdclk;
> > +   break;
> > +   case CDCLK_CRAWL:
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > -   } else if (DISPLAY_VER(dev_priv) >= 11) {
> > -   if (dev_priv->cdclk.hw.vco != 0 &&
> > -   dev_priv->cdclk.hw.vco != vco)
> > -   icl_cdclk_pll_disable(dev_priv);
> > -
> > -   if (dev_priv->cdclk.hw.vco != vco)
> > -   icl_cdclk_pll_enable(dev_priv, vco);
> > -   } else {
> > -   if (dev_priv->cdclk.hw.vco != 0 &&
> > -   dev_priv->cdclk.hw.vco != vco)
> > -   bxt_de_pll_disable(dev_priv);
> > -
> > -   if (dev_priv->cdclk.hw.vco != vco)
> > -   bxt_de_pll_enable(dev_priv, vco);
> > -   }
> > -
> > -   waveform = cdclk_squash_waveform(dev_priv, cdclk);
> > -
> > -   if (waveform)
> > -   clock = vco / 2;
> > -   else
> > -   clock = cdclk;
> > -
> > -   if (has_cdclk_squasher(dev_priv)) {
> > -   u32 squash_ctl = 0;
> > -
> > -   if (waveform)
> > +   c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix bandwith related cdclk calculations (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix bandwith related cdclk calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/98975/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix bandwith related cdclk calculations (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix bandwith related cdclk calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/98975/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c60dc5b8150b drm/i915: Tweak plane ddb allocation tracking
f73e140093bf drm/i915: Split plane data_rate into data_rate+data_rate_y
bf50385f5dac drm/i915: Pre-calculate plane relative data rate
-:399: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#399: FILE: drivers/gpu/drm/i915/intel_pm.c:5154:
+   iter.start + 
iter.uv_total[plane_id]);

total: 0 errors, 1 warnings, 0 checks, 352 lines checked
3d55cf48c60c drm/i915: Remove total[] and uv_total[] from ddb allocation
a20ee8c5b4c8 drm/i915: Nuke intel_bw_calc_min_cdclk()
fd80e1100608 drm/i915: Round up when calculating display bandwidth requirements
600f71268f91 drm/i915: Properly write lock bw_state when it changes
bf90a2f0ae6e drm/i915: Fix DBUF bandwidth vs. cdclk handling
9ce73d6df0c4 drm/i915: Add "maximum pipe read bandwidth" checks

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/gmbus: combine gmbus pin lookups to one function

2022-03-03 Thread Patchwork

== Series Details ==

Series: series starting with [1/5] drm/i915/gmbus: combine gmbus pin lookups to 
one function
URL   : https://patchwork.freedesktop.org/series/101007/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22476


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (2): fi-icl-u2 fi-pnv-d510 
  Missing(4): shard-rkl shard-dg1 shard-tglu fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u:   [PASS][3] -> [INCOMPLETE][4] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +57 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][8] -> [FAIL][9] ([i915#4032])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_mocs:
- fi-tgl-1115g4:  [PASS][10] -> [DMESG-WARN][11] ([i915#2867]) +24 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4:  [PASS][12] -> [DMESG-FAIL][13] ([i915#3987])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  NOTRUN -> [SKIP][17] ([fdo#109278]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([fdo#109285])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][19] ([i915#3301])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22476/fi-icl-u2/igt@prime_v...@basic-userptr.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][21] ([i915#4785]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-hsw-4770/igt@i915_selftest@l...@hang

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the memcpy_from_wc function from drm (rev3)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Use the memcpy_from_wc function from drm (rev3)
URL   : https://patchwork.freedesktop.org/series/100581/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22475


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 36)
--

  Additional (1): fi-icl-u2 
  Missing(11): fi-bdw-samus shard-tglu bat-dg1-6 bat-dg1-5 shard-rkl 
bat-dg2-9 bat-adlp-6 bat-rpls-2 shard-dg1 bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   NOTRUN -> [INCOMPLETE][2] ([i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([fdo#109278]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([fdo#109285])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#3301])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-icl-u2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][9] ([i915#5127]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][11] ([i915#4785]) -> [INCOMPLETE][12] 
([i915#3303])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22475/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_11320 -> Patchwork_22475

  CI-20190529: 20190529
  CI_DRM_11320: 6be3

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/gmbus: combine gmbus pin lookups to one function

2022-03-03 Thread Patchwork

== Series Details ==

Series: series starting with [1/5] drm/i915/gmbus: combine gmbus pin lookups to 
one function
URL   : https://patchwork.freedesktop.org/series/101007/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v2 9/9] drm/i915: Add "maximum pipe read bandwidth" checks

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Make sure the CDCLK is high enough to support the so called
"maximum pipe read bandwidth" limitation. Specified as
51.2 x CDCLK.

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

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index ed86f3e3c66c..e5e772c4fcfb 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -599,6 +599,18 @@ static unsigned int intel_bw_crtc_data_rate(const struct 
intel_crtc_state *crtc_
return data_rate;
 }
 
+/* "Maximum Pipe Read Bandwidth" */
+static int intel_bw_crtc_min_cdclk(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+   if (DISPLAY_VER(i915) < 12)
+   return 0;
+
+   return 
DIV_ROUND_UP_ULL(mul_u32_u32(intel_bw_crtc_data_rate(crtc_state), 10), 512);
+}
+
 void intel_bw_crtc_update(struct intel_bw_state *bw_state,
  const struct intel_crtc_state *crtc_state)
 {
@@ -696,6 +708,9 @@ static bool intel_bw_state_changed(struct drm_i915_private 
*i915,
old_crtc_bw->active_planes[slice] != 
new_crtc_bw->active_planes[slice])
return true;
}
+
+   if (old_bw_state->min_cdclk[pipe] != 
new_bw_state->min_cdclk[pipe])
+   return true;
}
 
return false;
@@ -788,7 +803,15 @@ intel_bw_dbuf_min_cdclk(struct drm_i915_private *i915,
 int intel_bw_min_cdclk(struct drm_i915_private *i915,
   const struct intel_bw_state *bw_state)
 {
-   return intel_bw_dbuf_min_cdclk(i915, bw_state);
+   enum pipe pipe;
+   int min_cdclk;
+
+   min_cdclk = intel_bw_dbuf_min_cdclk(i915, bw_state);
+
+   for_each_pipe(i915, pipe)
+   min_cdclk = max(bw_state->min_cdclk[pipe], min_cdclk);
+
+   return min_cdclk;
 }
 
 int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
@@ -814,6 +837,9 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state 
*state,
old_bw_state = intel_atomic_get_old_bw_state(state);
 
skl_crtc_calc_dbuf_bw(new_bw_state, crtc_state);
+
+   new_bw_state->min_cdclk[crtc->pipe] =
+   intel_bw_crtc_min_cdclk(crtc_state);
}
 
if (!old_bw_state)
@@ -830,9 +856,9 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state 
*state,
 
/*
 * No need to check against the cdclk state if
-* the min cdclk for the dbuf doesn't increase.
+* the min cdclk doesn't increase.
 *
-* Ie. we only ever increase the cdclk due to dbuf
+* Ie. we only ever increase the cdclk due to bandwidth
 * requirements. This can reduce back and forth
 * display blinking due to constant cdclk changes.
 */
@@ -845,9 +871,9 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state 
*state,
 
/*
 * No need to recalculate the cdclk state if
-* the min cdclk for the dbuf doesn't increase.
+* the min cdclk doesn't increase.
 *
-* Ie. we only ever increase the cdclk due to dbuf
+* Ie. we only ever increase the cdclk due to bandwidth
 * requirements. This can reduce back and forth
 * display blinking due to constant cdclk changes.
 */
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
index 92fc09a8c824..cb7ee3a24a58 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -41,6 +41,7 @@ struct intel_bw_state {
 */
u16 qgv_points_mask;
 
+   int min_cdclk[I915_MAX_PIPES];
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_planes[I915_MAX_PIPES];
 };
-- 
2.34.1

[Intel-gfx] [PATCH v2 7/9] drm/i915: Properly write lock bw_state when it changes

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

The current code also forgets to call intel_atomic_lock_global_state()
when other stuff besides the final min_cdlck changes in the state.
That means we may throw away data which actually has changed, and
thus we can't be at all sure what the code ends up doing during
subsequent commits. Do the write lock properly.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 0759bb95ea4b..56eebccd16e2 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -678,6 +678,28 @@ intel_atomic_get_bw_state(struct intel_atomic_state *state)
return to_intel_bw_state(bw_state);
 }
 
+static bool intel_bw_state_changed(struct drm_i915_private *i915,
+  const struct intel_bw_state *old_bw_state,
+  const struct intel_bw_state *new_bw_state)
+{
+   enum pipe pipe;
+
+   for_each_pipe(i915, pipe) {
+   const struct intel_dbuf_bw *old_crtc_bw =
+   &old_bw_state->dbuf_bw[pipe];
+   const struct intel_dbuf_bw *new_crtc_bw =
+   &new_bw_state->dbuf_bw[pipe];
+   enum dbuf_slice slice;
+
+   for_each_dbuf_slice(i915, slice) {
+   if (old_crtc_bw->used_bw[slice] != 
new_crtc_bw->used_bw[slice])
+   return true;
+   }
+   }
+
+   return old_bw_state->min_cdclk != new_bw_state->min_cdclk;
+}
+
 static void skl_crtc_calc_dbuf_bw(struct intel_bw_state *bw_state,
  const struct intel_crtc_state *crtc_state)
 {
@@ -765,7 +787,7 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state 
*state)
 
new_bw_state->min_cdclk = DIV_ROUND_UP(max_bw, 64);
 
-   if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
+   if (intel_bw_state_changed(dev_priv, old_bw_state, new_bw_state)) {
int ret = intel_atomic_lock_global_state(&new_bw_state->base);
 
if (ret)
-- 
2.34.1

[Intel-gfx] [PATCH v2 8/9] drm/i915: Fix DBUF bandwidth vs. cdclk handling

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Make the dbuf bandwidth min cdclk calculations match the spec
more closely. Supposedly the arbiter can only guarantee an equal
share of the total bandwidth of the slice to each active plane
on that slice. So we take the max bandwidth of any of the planes
on each slice and multiply that by the number of active planes
on the slice to get a worst case estimate on how much bandwidth
we require.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bw.c| 159 +++--
 drivers/gpu/drm/i915/display/intel_bw.h|  10 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c |  67 -
 drivers/gpu/drm/i915/display/intel_cdclk.h |   2 +
 4 files changed, 148 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 56eebccd16e2..ed86f3e3c66c 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -692,12 +692,34 @@ static bool intel_bw_state_changed(struct 
drm_i915_private *i915,
enum dbuf_slice slice;
 
for_each_dbuf_slice(i915, slice) {
-   if (old_crtc_bw->used_bw[slice] != 
new_crtc_bw->used_bw[slice])
+   if (old_crtc_bw->max_bw[slice] != 
new_crtc_bw->max_bw[slice] ||
+   old_crtc_bw->active_planes[slice] != 
new_crtc_bw->active_planes[slice])
return true;
}
}
 
-   return old_bw_state->min_cdclk != new_bw_state->min_cdclk;
+   return false;
+}
+
+static void skl_plane_calc_dbuf_bw(struct intel_bw_state *bw_state,
+  struct intel_crtc *crtc,
+  enum plane_id plane_id,
+  const struct skl_ddb_entry *ddb,
+  unsigned int data_rate)
+{
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   struct intel_dbuf_bw *crtc_bw = &bw_state->dbuf_bw[crtc->pipe];
+   unsigned int dbuf_mask = skl_ddb_dbuf_slice_mask(i915, ddb);
+   enum dbuf_slice slice;
+
+   /*
+* The arbiter can only really guarantee an
+* equal share of the total bw to each plane.
+*/
+   for_each_dbuf_slice_in_mask(i915, slice, dbuf_mask) {
+   crtc_bw->max_bw[slice] = max(crtc_bw->max_bw[slice], data_rate);
+   crtc_bw->active_planes[slice] |= BIT(plane_id);
+   }
 }
 
 static void skl_crtc_calc_dbuf_bw(struct intel_bw_state *bw_state,
@@ -708,46 +730,77 @@ static void skl_crtc_calc_dbuf_bw(struct intel_bw_state 
*bw_state,
struct intel_dbuf_bw *crtc_bw = &bw_state->dbuf_bw[crtc->pipe];
enum plane_id plane_id;
 
-   memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
+   memset(crtc_bw, 0, sizeof(*crtc_bw));
 
if (!crtc_state->hw.active)
return;
 
for_each_plane_id_on_crtc(crtc, plane_id) {
-   const struct skl_ddb_entry *ddb =
-   &crtc_state->wm.skl.plane_ddb[plane_id];
-   unsigned int data_rate = crtc_state->data_rate[plane_id];
-   unsigned int dbuf_mask = skl_ddb_dbuf_slice_mask(i915, ddb);
-   enum dbuf_slice slice;
-
-   for_each_dbuf_slice_in_mask(i915, slice, dbuf_mask)
-   crtc_bw->used_bw[slice] += data_rate;
+   /*
+* We assume cursors are small enough
+* to not cause bandwidth problems.
+*/
+   if (plane_id == PLANE_CURSOR)
+   continue;
+
+   skl_plane_calc_dbuf_bw(bw_state, crtc, plane_id,
+  &crtc_state->wm.skl.plane_ddb[plane_id],
+  crtc_state->data_rate[plane_id]);
+
+   if (DISPLAY_VER(i915) < 11)
+   skl_plane_calc_dbuf_bw(bw_state, crtc, plane_id,
+  
&crtc_state->wm.skl.plane_ddb_y[plane_id],
+  crtc_state->data_rate[plane_id]);
}
+}
+
+/* "Maximum Data Buffer Bandwidth" */
+static int
+intel_bw_dbuf_min_cdclk(struct drm_i915_private *i915,
+   const struct intel_bw_state *bw_state)
+{
+   unsigned int total_max_bw = 0;
+   enum dbuf_slice slice;
 
-   if (DISPLAY_VER(i915) >= 11)
-   return;
+   for_each_dbuf_slice(i915, slice) {
+   int num_active_planes = 0;
+   unsigned int max_bw = 0;
+   enum pipe pipe;
 
-   for_each_plane_id_on_crtc(crtc, plane_id) {
-   const struct skl_ddb_entry *ddb =
-   &crtc_state->wm.skl.plane_ddb_y[plane_id];
-   unsigned int data_rate = crtc_state->data_rate_y[plane_id];
-   unsigned int dbuf_mask = skl_ddb_dbuf_slice_mask(i915, ddb);
-   enum dbuf

[Intel-gfx] [PATCH v2 6/9] drm/i915: Round up when calculating display bandwidth requirements

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

We should round up when doing bandwidth calculations to make sure
our estimates don't fall short of the actual number.

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

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index df98b1d7a6f7..0759bb95ea4b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -638,7 +638,7 @@ static unsigned int intel_bw_data_rate(struct 
drm_i915_private *dev_priv,
data_rate += bw_state->data_rate[pipe];
 
if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
-   data_rate = data_rate * 105 / 100;
+   data_rate = DIV_ROUND_UP(data_rate * 105, 100);
 
return data_rate;
 }
@@ -763,7 +763,7 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state 
*state)
}
}
 
-   new_bw_state->min_cdclk = max_bw / 64;
+   new_bw_state->min_cdclk = DIV_ROUND_UP(max_bw, 64);
 
if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
int ret = intel_atomic_lock_global_state(&new_bw_state->base);
-- 
2.34.1

[Intel-gfx] [PATCH v2 5/9] drm/i915: Nuke intel_bw_calc_min_cdclk()

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
(at least documented) dbuf min cdclk limit on pre-skl so let's just get
rid of all this confusion.

Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bw.c| 49 ++
 drivers/gpu/drm/i915/display/intel_bw.h|  1 -
 drivers/gpu/drm/i915/display/intel_cdclk.c | 31 +-
 3 files changed, 5 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index fa51fa85e431..df98b1d7a6f7 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -717,7 +717,7 @@ static void skl_crtc_calc_dbuf_bw(struct intel_bw_state 
*bw_state,
}
 }
 
-int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
+int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_bw_state *new_bw_state = NULL;
@@ -728,6 +728,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
enum pipe pipe;
int i;
 
+   if (DISPLAY_VER(dev_priv) < 9)
+   return 0;
+
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
new_bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(new_bw_state))
@@ -772,50 +775,6 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
return 0;
 }
 
-int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
-{
-   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   struct intel_bw_state *new_bw_state = NULL;
-   struct intel_bw_state *old_bw_state = NULL;
-   const struct intel_crtc_state *crtc_state;
-   struct intel_crtc *crtc;
-   int min_cdclk = 0;
-   enum pipe pipe;
-   int i;
-
-   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
-   new_bw_state = intel_atomic_get_bw_state(state);
-   if (IS_ERR(new_bw_state))
-   return PTR_ERR(new_bw_state);
-
-   old_bw_state = intel_atomic_get_old_bw_state(state);
-   }
-
-   if (!old_bw_state)
-   return 0;
-
-   for_each_pipe(dev_priv, pipe) {
-   struct intel_cdclk_state *cdclk_state;
-
-   cdclk_state = intel_atomic_get_new_cdclk_state(state);
-   if (!cdclk_state)
-   return 0;
-
-   min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);
-   }
-
-   new_bw_state->min_cdclk = min_cdclk;
-
-   if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
-   int ret = intel_atomic_lock_global_state(&new_bw_state->base);
-
-   if (ret)
-   return ret;
-   }
-
-   return 0;
-}
-
 static u16 icl_qgv_points_mask(struct drm_i915_private *i915)
 {
unsigned int num_psf_gv_points = i915->max_bw[0].num_psf_gv_points;
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
index 0ceaed1c9656..6acdf1245b3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -65,6 +65,5 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state,
 int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
  u32 points_mask);
 int intel_bw_calc_min_cdclk(struct intel_atomic_state *state);
-int skl_bw_calc_min_cdclk(struct intel_atomic_state *state);
 
 #endif /* __INTEL_BW_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index fda8b701..5d0c2f8b0533 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -72,7 +72,6 @@ struct intel_cdclk_funcs {
void (*set_cdclk)(struct drm_i915_private *i915,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe);
-   int (*bw_calc_min_cdclk)(struct intel_atomic_state *state);
int (*modeset_calc_cdclk)(struct intel_cdclk_state *state);
u8 (*calc_voltage_level)(int cdclk);
 };
@@ -83,12 +82,6 @@ void intel_cdclk_get_cdclk(struct drm_i915_private *dev_priv,
dev_priv->cdclk_funcs->get_cdclk(dev_priv, cdclk_config);
 }
 
-static int intel_cdclk_bw_calc_min_cdclk(struct intel_atomic_state *state)
-{
-   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   return dev_priv->cdclk_funcs->bw_calc_min_cdclk(state);
-}
-
 static void intel_cdclk_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe)
@@ -2683,7 +2676,7 @@ int intel_cdclk_atomic_check(struct

[Intel-gfx] [PATCH v2 3/9] drm/i915: Pre-calculate plane relative data rate

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Handle the plane relative data rate in exactly the same
way as we already handle the real data rate. Ie. pre-calculate
it during intel_plane_atomic_check_with_state(), and assign/clear
it for the Y plane as needed. This should guarantee that the
tracking is 100% consistent, and makes me have to think less
when the same apporach is used by both types of data rate.

We might even want to consider replacing the relative
data rate with the real data rate entirely, but it's not
clear if that will produce less optimal plane ddb
allocations. So for now lets keep using the current approach.

v2: Rebase due to async flip wm optimization

Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  64 ++
 drivers/gpu/drm/i915/display/intel_display.c  |   5 +
 .../drm/i915/display/intel_display_types.h|   6 +-
 drivers/gpu/drm/i915/intel_pm.c   | 187 --
 4 files changed, 108 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index b0aa65845f90..6ed2bf5b3942 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -193,6 +193,57 @@ unsigned int intel_plane_data_rate(const struct 
intel_crtc_state *crtc_state,
fb->format->cpp[color_plane];
 }
 
+static bool
+use_min_ddb(const struct intel_crtc_state *crtc_state,
+   struct intel_plane *plane)
+{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+   return DISPLAY_VER(i915) >= 13 &&
+  crtc_state->uapi.async_flip &&
+  plane->async_flip;
+}
+
+static unsigned int
+intel_plane_relative_data_rate(const struct intel_crtc_state *crtc_state,
+  const struct intel_plane_state *plane_state,
+  int color_plane)
+{
+   struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+   const struct drm_framebuffer *fb = plane_state->hw.fb;
+   int width, height;
+
+   if (plane->id == PLANE_CURSOR)
+   return 0;
+
+   if (!plane_state->uapi.visible)
+   return 0;
+
+   /*
+* We calculate extra ddb based on ratio plane rate/total data rate
+* in case, in some cases we should not allocate extra ddb for the 
plane,
+* so do not count its data rate, if this is the case.
+*/
+   if (use_min_ddb(crtc_state, plane))
+   return 0;
+
+   /*
+* Src coordinates are already rotated by 270 degrees for
+* the 90/270 degree plane rotation cases (to match the
+* GTT mapping), hence no need to account for rotation here.
+*/
+   width = drm_rect_width(&plane_state->uapi.src) >> 16;
+   height = drm_rect_height(&plane_state->uapi.src) >> 16;
+
+   /* UV plane does 1/2 pixel sub-sampling */
+   if (color_plane == 1) {
+   width /= 2;
+   height /= 2;
+   }
+
+   return width * height * fb->format->cpp[color_plane];
+}
+
 int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
   struct intel_plane *plane,
   bool *need_cdclk_calc)
@@ -314,6 +365,8 @@ void intel_plane_set_invisible(struct intel_crtc_state 
*crtc_state,
crtc_state->c8_planes &= ~BIT(plane->id);
crtc_state->data_rate[plane->id] = 0;
crtc_state->data_rate_y[plane->id] = 0;
+   crtc_state->rel_data_rate[plane->id] = 0;
+   crtc_state->rel_data_rate_y[plane->id] = 0;
crtc_state->min_cdclk[plane->id] = 0;
 
plane_state->uapi.visible = false;
@@ -545,9 +598,20 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
intel_plane_data_rate(new_crtc_state, new_plane_state, 
0);
new_crtc_state->data_rate[plane->id] =
intel_plane_data_rate(new_crtc_state, new_plane_state, 
1);
+
+   new_crtc_state->rel_data_rate_y[plane->id] =
+   intel_plane_relative_data_rate(new_crtc_state,
+  new_plane_state, 0);
+   new_crtc_state->rel_data_rate[plane->id] =
+   intel_plane_relative_data_rate(new_crtc_state,
+  new_plane_state, 1);
} else if (new_plane_state->uapi.visible) {
new_crtc_state->data_rate[plane->id] =
intel_plane_data_rate(new_crtc_state, new_plane_state, 
0);
+
+   new_crtc_state->rel_data_rate[plane->id] =
+   intel_plane_relative_data_rate(new_crtc_state,
+  new_plane_state, 0);
}
 
return intel_plane_atomic_calc_changes(old_crtc_state, new_crtc_state,

[Intel-gfx] [PATCH v2 4/9] drm/i915: Remove total[] and uv_total[] from ddb allocation

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

There's really no need to maintain these total[] arrays to
track the size of each plane's ddb allocation. We just stick
the results straight into the crtc_state ddb tracking structures.

The main annoyance with all this is the mismatch between
wm_uv vs. ddb_y on pre-icl. If only the hw was consistent in
what it considers the primary source of information we could
avoid some of the uglyness. But since that is not the case
we need a bit of special casing for planar formats.

v2: Keep the ddb entry zeroed when the plane is disabled

Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 122 
 1 file changed, 62 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d292a9e65e3f..641624937029 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4969,18 +4969,18 @@ skl_plane_trans_wm(const struct skl_pipe_wm *pipe_wm,
  * So this is actually safe to do.
  */
 static void
-skl_check_wm_level(struct skl_wm_level *wm, u64 total)
+skl_check_wm_level(struct skl_wm_level *wm, const struct skl_ddb_entry *ddb)
 {
-   if (wm->min_ddb_alloc > total)
+   if (wm->min_ddb_alloc > skl_ddb_entry_size(ddb))
memset(wm, 0, sizeof(*wm));
 }
 
 static void
 skl_check_nv12_wm_level(struct skl_wm_level *wm, struct skl_wm_level *uv_wm,
-   u64 total, u64 uv_total)
+   const struct skl_ddb_entry *ddb_y, const struct 
skl_ddb_entry *ddb)
 {
-   if (wm->min_ddb_alloc > total ||
-   uv_wm->min_ddb_alloc > uv_total) {
+   if (wm->min_ddb_alloc > skl_ddb_entry_size(ddb_y) ||
+   uv_wm->min_ddb_alloc > skl_ddb_entry_size(ddb)) {
memset(wm, 0, sizeof(*wm));
memset(uv_wm, 0, sizeof(*uv_wm));
}
@@ -5000,17 +5000,16 @@ static bool icl_need_wm1_wa(struct drm_i915_private 
*i915,
 
 struct skl_plane_ddb_iter {
u64 data_rate;
-   u16 total[I915_MAX_PLANES];
-   u16 uv_total[I915_MAX_PLANES];
u16 start, size;
 };
 
-static u16
+static void
 skl_allocate_plane_ddb(struct skl_plane_ddb_iter *iter,
+  struct skl_ddb_entry *ddb,
   const struct skl_wm_level *wm,
   u64 data_rate)
 {
-   u16 extra = 0;
+   u16 size, extra = 0;
 
if (data_rate) {
extra = min_t(u16, iter->size,
@@ -5020,7 +5019,15 @@ skl_allocate_plane_ddb(struct skl_plane_ddb_iter *iter,
iter->data_rate -= data_rate;
}
 
-   return wm->min_ddb_alloc + extra;
+   /*
+* Keep ddb entry of all disabled planes explicitly zeroed
+* to avoid skl_ddb_add_affected_planes() adding them to
+* the state when other planes change their allocations.
+*/
+   size = wm->min_ddb_alloc + extra;
+   if (size)
+   iter->start = skl_ddb_entry_init(ddb, iter->start,
+iter->start + size);
 }
 
 static int
@@ -5034,8 +5041,9 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
*state,
intel_atomic_get_new_dbuf_state(state);
const struct skl_ddb_entry *alloc = &dbuf_state->ddb[crtc->pipe];
int num_active = hweight8(dbuf_state->active_pipes);
-   struct skl_plane_ddb_iter iter = {};
+   struct skl_plane_ddb_iter iter;
enum plane_id plane_id;
+   u16 cursor_size;
u32 blocks;
int level;
 
@@ -5046,15 +5054,16 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
*state,
if (!crtc_state->hw.active)
return 0;
 
+   iter.start = alloc->start;
iter.size = skl_ddb_entry_size(alloc);
if (iter.size == 0)
return 0;
 
/* Allocate fixed number of blocks for cursor. */
-   iter.total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state, 
num_active);
-   iter.size -= iter.total[PLANE_CURSOR];
+   cursor_size = skl_cursor_allocation(crtc_state, num_active);
+   iter.size -= cursor_size;
skl_ddb_entry_init(&crtc_state->wm.skl.plane_ddb[PLANE_CURSOR],
-  alloc->end - iter.total[PLANE_CURSOR], alloc->end);
+  alloc->end - cursor_size, alloc->end);
 
iter.data_rate = skl_total_relative_data_rate(crtc_state);
 
@@ -5069,7 +5078,10 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
*state,
&crtc_state->wm.skl.optimal.planes[plane_id];
 
if (plane_id == PLANE_CURSOR) {
-   if (wm->wm[level].min_ddb_alloc > 
iter.total[PLANE_CURSOR]) {
+   const struct skl_ddb_entry *ddb =
+   &crtc_state->wm.skl.plane_ddb[plane_id];
+
+   if (wm->wm[level].min_ddb_alloc > 
skl_ddb_entry_size(

[Intel-gfx] [PATCH v2 2/9] drm/i915: Split plane data_rate into data_rate+data_rate_y

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Split the currently combined plane data_rate into the proper
Y vs. CbCr components. This matches how we now track the
plane dbuf allocations, and thus will make the dbuf bandwidth
calculations actually produce the correct numbers for each
dbuf slice.

Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c | 34 --
 .../gpu/drm/i915/display/intel_atomic_plane.h |  3 +-
 drivers/gpu/drm/i915/display/intel_bw.c   | 36 +--
 drivers/gpu/drm/i915/display/intel_display.c  |  4 +++
 .../drm/i915/display/intel_display_types.h|  3 ++
 5 files changed, 42 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 0da9e2fa79eb..b0aa65845f90 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -181,29 +181,16 @@ unsigned int intel_plane_pixel_rate(const struct 
intel_crtc_state *crtc_state,
 }
 
 unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
-  const struct intel_plane_state *plane_state)
+  const struct intel_plane_state *plane_state,
+  int color_plane)
 {
const struct drm_framebuffer *fb = plane_state->hw.fb;
-   unsigned int cpp;
-   unsigned int pixel_rate;
 
if (!plane_state->uapi.visible)
return 0;
 
-   pixel_rate = intel_plane_pixel_rate(crtc_state, plane_state);
-
-   cpp = fb->format->cpp[0];
-
-   /*
-* Based on HSD#:1408715493
-* NV12 cpp == 4, P010 cpp == 8
-*
-* FIXME what is the logic behind this?
-*/
-   if (fb->format->is_yuv && fb->format->num_planes > 1)
-   cpp *= 4;
-
-   return pixel_rate * cpp;
+   return intel_plane_pixel_rate(crtc_state, plane_state) *
+   fb->format->cpp[color_plane];
 }
 
 int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
@@ -326,6 +313,7 @@ void intel_plane_set_invisible(struct intel_crtc_state 
*crtc_state,
crtc_state->nv12_planes &= ~BIT(plane->id);
crtc_state->c8_planes &= ~BIT(plane->id);
crtc_state->data_rate[plane->id] = 0;
+   crtc_state->data_rate_y[plane->id] = 0;
crtc_state->min_cdclk[plane->id] = 0;
 
plane_state->uapi.visible = false;
@@ -551,8 +539,16 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
if (new_plane_state->uapi.visible || old_plane_state->uapi.visible)
new_crtc_state->update_planes |= BIT(plane->id);
 
-   new_crtc_state->data_rate[plane->id] =
-   intel_plane_data_rate(new_crtc_state, new_plane_state);
+   if (new_plane_state->uapi.visible &&
+   intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier)) {
+   new_crtc_state->data_rate_y[plane->id] =
+   intel_plane_data_rate(new_crtc_state, new_plane_state, 
0);
+   new_crtc_state->data_rate[plane->id] =
+   intel_plane_data_rate(new_crtc_state, new_plane_state, 
1);
+   } else if (new_plane_state->uapi.visible) {
+   new_crtc_state->data_rate[plane->id] =
+   intel_plane_data_rate(new_crtc_state, new_plane_state, 
0);
+   }
 
return intel_plane_atomic_calc_changes(old_crtc_state, new_crtc_state,
   old_plane_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 f4763a53541e..74b6d3b169a7 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -25,7 +25,8 @@ unsigned int intel_plane_pixel_rate(const struct 
intel_crtc_state *crtc_state,
const struct intel_plane_state 
*plane_state);
 
 unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
-  const struct intel_plane_state *plane_state);
+  const struct intel_plane_state *plane_state,
+  int color_plane);
 void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
   const struct intel_plane_state 
*from_plane_state,
   struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index e8fc14ff133f..fa51fa85e431 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -578,6 +578,7 @@ static unsigned int intel_bw_crtc_num_active_planes(const 
struct intel_crtc_stat
 static unsigned int intel_bw_crtc_data_rate(co

[Intel-gfx] [PATCH v2 1/9] drm/i915: Tweak plane ddb allocation tracking

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Let's store the plane allocation in a manner which more closely
matches how the hw operates. That is, we store the packed/CbCr
ddb in one struct, and the Y ddb in another. Currently we're
storing packed/Y in one struct, CbCr in the other.

This also works pretty well for icl+ where the UV plane is
the main plane and the Y plane is subservient to it. Although
in this case we do not even use ddb_y as we do the ddb allocation
in terms of hw planes.

v2: Rebase

Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  32 +++---
 drivers/gpu/drm/i915/display/intel_bw.c   |   6 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   8 +-
 .../drm/i915/display/intel_display_debugfs.c  |   4 +-
 .../drm/i915/display/intel_display_types.h|   7 +-
 drivers/gpu/drm/i915/intel_pm.c   | 108 --
 6 files changed, 74 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 5712688232fb..0da9e2fa79eb 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -616,8 +616,8 @@ int intel_plane_atomic_check(struct intel_atomic_state 
*state,
 static struct intel_plane *
 skl_next_plane_to_commit(struct intel_atomic_state *state,
 struct intel_crtc *crtc,
-struct skl_ddb_entry entries_y[I915_MAX_PLANES],
-struct skl_ddb_entry entries_uv[I915_MAX_PLANES],
+struct skl_ddb_entry ddb[I915_MAX_PLANES],
+struct skl_ddb_entry ddb_y[I915_MAX_PLANES],
 unsigned int *update_mask)
 {
struct intel_crtc_state *crtc_state =
@@ -636,17 +636,15 @@ skl_next_plane_to_commit(struct intel_atomic_state *state,
!(*update_mask & BIT(plane_id)))
continue;
 
-   if 
(skl_ddb_allocation_overlaps(&crtc_state->wm.skl.plane_ddb_y[plane_id],
-   entries_y,
-   I915_MAX_PLANES, plane_id) ||
-   
skl_ddb_allocation_overlaps(&crtc_state->wm.skl.plane_ddb_uv[plane_id],
-   entries_uv,
-   I915_MAX_PLANES, plane_id))
+   if 
(skl_ddb_allocation_overlaps(&crtc_state->wm.skl.plane_ddb[plane_id],
+   ddb, I915_MAX_PLANES, plane_id) 
||
+   
skl_ddb_allocation_overlaps(&crtc_state->wm.skl.plane_ddb_y[plane_id],
+   ddb_y, I915_MAX_PLANES, 
plane_id))
continue;
 
*update_mask &= ~BIT(plane_id);
-   entries_y[plane_id] = crtc_state->wm.skl.plane_ddb_y[plane_id];
-   entries_uv[plane_id] = 
crtc_state->wm.skl.plane_ddb_uv[plane_id];
+   ddb[plane_id] = crtc_state->wm.skl.plane_ddb[plane_id];
+   ddb_y[plane_id] = crtc_state->wm.skl.plane_ddb_y[plane_id];
 
return plane;
}
@@ -728,19 +726,17 @@ static void skl_crtc_planes_update_arm(struct 
intel_atomic_state *state,
intel_atomic_get_old_crtc_state(state, crtc);
struct intel_crtc_state *new_crtc_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 skl_ddb_entry ddb[I915_MAX_PLANES];
+   struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
u32 update_mask = new_crtc_state->update_planes;
struct intel_plane *plane;
 
-   memcpy(entries_y, old_crtc_state->wm.skl.plane_ddb_y,
+   memcpy(ddb, old_crtc_state->wm.skl.plane_ddb,
+  sizeof(old_crtc_state->wm.skl.plane_ddb));
+   memcpy(ddb_y, old_crtc_state->wm.skl.plane_ddb_y,
   sizeof(old_crtc_state->wm.skl.plane_ddb_y));
-   memcpy(entries_uv, old_crtc_state->wm.skl.plane_ddb_uv,
-  sizeof(old_crtc_state->wm.skl.plane_ddb_uv));
 
-   while ((plane = skl_next_plane_to_commit(state, crtc,
-entries_y, entries_uv,
-&update_mask))) {
+   while ((plane = skl_next_plane_to_commit(state, crtc, ddb, ddb_y, 
&update_mask))) {
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
 
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index ad1564ca7269..e8fc14ff133f 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -688,16 +688,16 @@ static void skl_crtc_calc_dbuf_bw(struct intel_bw_state 
*bw_st

[Intel-gfx] [PATCH v2 0/9] drm/i915: Fix bandwith related cdclk calculations

2022-03-03 Thread Ville Syrjala

From: Ville Syrjälä 

Fix up the dbuf bandwidth cdclk calculations to match the spec,
and also implement the cdclk based pipe max bandwidth limit.

TODO: intel_bw contains two orthogonal things (qgv vs. cdclk).
  We should probably just split it into two parts to life
  less confusing. But as usual naming is hard so I didn't
  go for that yet...

v2: Rebased due to the async flip wm0/ddb stuff

Ville Syrjälä (9):
  drm/i915: Tweak plane ddb allocation tracking
  drm/i915: Split plane data_rate into data_rate+data_rate_y
  drm/i915: Pre-calculate plane relative data rate
  drm/i915: Remove total[] and uv_total[] from ddb allocation
  drm/i915: Nuke intel_bw_calc_min_cdclk()
  drm/i915: Round up when calculating display bandwidth requirements
  drm/i915: Properly write lock bw_state when it changes
  drm/i915: Fix DBUF bandwidth vs. cdclk handling
  drm/i915: Add "maximum pipe read bandwidth" checks

 .../gpu/drm/i915/display/intel_atomic_plane.c | 120 --
 .../gpu/drm/i915/display/intel_atomic_plane.h |   3 +-
 drivers/gpu/drm/i915/display/intel_bw.c   | 254 -
 drivers/gpu/drm/i915/display/intel_bw.h   |  12 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c|  96 ++---
 drivers/gpu/drm/i915/display/intel_cdclk.h|   2 +
 drivers/gpu/drm/i915/display/intel_display.c  |  17 +-
 .../drm/i915/display/intel_display_debugfs.c  |   4 +-
 .../drm/i915/display/intel_display_types.h|  16 +-
 drivers/gpu/drm/i915/intel_pm.c   | 359 ++
 10 files changed, 431 insertions(+), 452 deletions(-)

-- 
2.34.1

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

2022-03-03 Thread John Harrison


On 3/3/2022 01:55, Tvrtko Ursulin wrote:

On 02/03/2022 17:55, John Harrison wrote:

I was assuming 2.5s tP is enough and basing all calculation on that. 
Heartbeat or timeslicing regardless. I thought we established 
neither of us knows how long is enough.


Are you now saying 2.5s is definitely not enough? How is that usable 
for a default out of the box desktop?

Show me your proof that 2.5s is enough.

7.5s is what we have been using internally for a very long time. It 
has approval from all relevant parties. If you wish to pick a new 
random number then please provide data to back it up along with buy 
in from all UMD teams and project management.


And upstream disabled preemption has acks from compute. "Internally" 
is as far away from out of the box desktop experiences we have been 
arguing about. In fact you have argued compute disables the hearbeat 
anyway.


Lets jump to the end of this reply please for actions.

And I don't have a problem with extending the last pulse. It is 
fundamentally correct to do regardless of the backend. I just raised 
the question of whether to extend all heartbeats to account for 
preemption (and scheduling delays). (What is the point of bumping 
their priority and re-scheduling if we didn't give enough time to 
the engine to react? So opposite of the question you raise.)
The point is that it we are giving enough time to react. Raising the 
priority of a pre-emption that has already been triggered will have 
no effect. So as long as the total time from when the pre-emption is 
triggered (prio becomes sufficiently high) to the point when the 
reset is decided is longer than the pre-emption timeout then it 
works. Given that, it is unnecessary to increase the intermediate 
periods. It has no advantage and has the disadvantage of making the 
total time unreasonably long.


So again, what is the point of making every period longer? What 
benefit does it *actually* give?


Less special casing and pointless prio bumps ahead of giving time to 
engine to even react. You wouldn't have to have the last pulse 2 * tP 
but normal tH + tP. So again, it is nicer for me to derive all 
heartbeat pulses from the same input parameters.


The whole "it is very long" argument is IMO moot because now proposed 
7.5s preempt period is I suspect wholly impractical for desktop. 
Combined with the argument that real compute disables heartbeats 
anyway even extra so.
The whole thing is totally fubar already. Right now pre-emption is 
totally disabled. So you are currently waiting for the entire heartbeat 
sequence to complete and then nuking the entire machine. So arguing that 
7.5s is too long is pointless. 7.5s is a big improvement over what is 
currently enabled.


And 'nice' would be having hardware that worked in a sensible manner. 
There is no nice here. There is only 'what is the least worst option'. 
And the least worst option for an end user is a long pre-emption timeout 
with a not massively long heartbeat. If that means a very slight 
complication in the heartbeat code, that is a trivial concern.






Fine. "tP(RCS) = 7500;" can I merge the patch now?
I could live with setting preempt timeout to 7.5s. The downside is 
slower time to restoring frozen desktops. Worst case today 5 * 2.5s, 
with changes 4 * 2.5s + 2 * 7.5s; so from 12.5s to 25s, doubling..
But that is worst case scenario (when something much more severe than an 
application hang has occurred). Regular case would be second heartbeat 
period + pre-emption timeout and an engine only reset not a full GT 
reset. So it's still better than what we have at present.




Actions:

1)
Get a number from compute/OpenCL people for what they say is minimum 
preempt timeout for default out of the box Linux desktop experience.
That would be the one that has been agreed upon by both linux software 
arch and all UMD teams and has been in use for the past year or more in 
the internal tree.




This does not mean them running some tests and can't be bothered to 
setup up the machine for the extreme use cases, but workloads average 
users can realistically be expected to run.


Say for instance some image manipulation software which is OpenCL 
accelerated or similar. How long unpreemptable sections are expected 
there. Or similar. I am not familiar what all OpenCL accelerated use 
cases there are on Linux.


And this number should be purely about minimum preempt timeout, not 
considering heartbeats. This is because preempt timeout may kick in 
sooner than stopped heartbeat if the user workload is low priority.


And driver is simply hosed in the intervening six months or more that it 
takes for the right people to find the time to do this.


Right now, it is broken. This patch set improves things. Actual numbers 
can be refined later as/when some random use case that we hadn't 
previously thought of pops up. But not fixing the basic problem at all 
until we have an absolutely perfect for all parties solution is 
pointless. Not least becaus

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Use the memcpy_from_wc function from drm (rev3)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: Use the memcpy_from_wc function from drm (rev3)
URL   : https://patchwork.freedesktop.org/series/100581/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (rev2)
URL   : https://patchwork.freedesktop.org/series/100991/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11320 -> Patchwork_22474


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(3): shard-dg1 fi-bdw-samus fi-kbl-8809g 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html

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

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  [PASS][5] -> [FAIL][6] ([i915#4032])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-5/igt@i915_pm_...@basic-api.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +57 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-pnv-d510/igt@prime_v...@basic-userptr.html

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

  
 Possible fixes 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [INCOMPLETE][11] ([i915#4547]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][13] ([i915#4785]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [INCOMPLETE][17] ([i915#4983]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@workarounds:
- {bat-adlp-6}:   [DMESG-WARN][19] ([i915#5068]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22474/bat-adlp-6/igt@i915_selftest@l...@workarounds.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][21] ([i915#4957]) -> [DMESG-FAIL][22] 
([i915#4494] / [i915#4957])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork

[Intel-gfx] [PATCH 1/5] drm/i915/gmbus: combine gmbus pin lookups to one function

2022-03-03 Thread Jani Nikula

Combine the platform specific if ladders for array lookup and size
checks into one. This is cleaner and avoids duplication, but hopefully
also helps any static analyzers that seem to have trouble with the
bounds checks.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 62 ++
 1 file changed, 29 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 2fad03250661..9cbf7f9a1e2e 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -106,51 +106,47 @@ static const struct gmbus_pin gmbus_pins_dg2[] = {
[GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
 };
 
-/* pin is expected to be valid */
-static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
+static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *i915,
 unsigned int pin)
 {
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
-   return &gmbus_pins_dg2[pin];
-   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
-   return &gmbus_pins_dg1[pin];
-   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
-   return &gmbus_pins_icp[pin];
-   else if (HAS_PCH_CNP(dev_priv))
-   return &gmbus_pins_cnp[pin];
-   else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
-   return &gmbus_pins_bxt[pin];
-   else if (DISPLAY_VER(dev_priv) == 9)
-   return &gmbus_pins_skl[pin];
-   else if (IS_BROADWELL(dev_priv))
-   return &gmbus_pins_bdw[pin];
-   else
-   return &gmbus_pins[pin];
-}
-
-bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
- unsigned int pin)
-{
-   unsigned int size;
+   const struct gmbus_pin *pins;
+   size_t size;
 
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
+   if (INTEL_PCH_TYPE(i915) >= PCH_DG2) {
+   pins = gmbus_pins_dg2;
size = ARRAY_SIZE(gmbus_pins_dg2);
-   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+   } else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
+   pins = gmbus_pins_dg1;
size = ARRAY_SIZE(gmbus_pins_dg1);
-   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+   } else if (INTEL_PCH_TYPE(i915) >= PCH_ICP) {
+   pins = gmbus_pins_icp;
size = ARRAY_SIZE(gmbus_pins_icp);
-   else if (HAS_PCH_CNP(dev_priv))
+   } else if (HAS_PCH_CNP(i915)) {
+   pins = gmbus_pins_cnp;
size = ARRAY_SIZE(gmbus_pins_cnp);
-   else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
+   } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
+   pins = gmbus_pins_bxt;
size = ARRAY_SIZE(gmbus_pins_bxt);
-   else if (DISPLAY_VER(dev_priv) == 9)
+   } else if (DISPLAY_VER(i915) == 9) {
+   pins = gmbus_pins_skl;
size = ARRAY_SIZE(gmbus_pins_skl);
-   else if (IS_BROADWELL(dev_priv))
+   } else if (IS_BROADWELL(i915)) {
+   pins = gmbus_pins_bdw;
size = ARRAY_SIZE(gmbus_pins_bdw);
-   else
+   } else {
+   pins = gmbus_pins;
size = ARRAY_SIZE(gmbus_pins);
+   }
+
+   if (pin >= size || !pins[pin].name)
+   return NULL;
 
-   return pin < size && get_gmbus_pin(dev_priv, pin)->name;
+   return &pins[pin];
+}
+
+bool intel_gmbus_is_valid_pin(struct drm_i915_private *i915, unsigned int pin)
+{
+   return get_gmbus_pin(i915, pin);
 }
 
 /* Intel GPIO access functions */
-- 
2.30.2

[Intel-gfx] [PATCH 5/5] drm/i915: include linux/highmem.h and linux/swap.h where needed

2022-03-03 Thread Jani Nikula

Include linux/highmem.h and linux/swap.h explicitly where needed so we
can drop the linux/i2c.h include from i915_drv.h where it pulled in the
dependencies implicitly.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c| 1 +
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 ++-
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c| 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 1 +
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c   | 2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c   | 1 +
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 ++
 drivers/gpu/drm/i915/i915_drv.h| 1 -
 drivers/gpu/drm/i915/i915_gpu_error.c  | 1 +
 10 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9ae294eb7fb4..5db83aaf93ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -64,6 +64,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 89aa0557ade1..35e6140d1d5d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -4,8 +4,9 @@
  * Copyright © 2008,2010 Intel Corporation
  */
 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 372bc220faeb..c1c3b510b9e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 1e049921969a..ef15967be51a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_selftest.h"
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index a132e241c3ee..c4c2c91a2ee7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -4,6 +4,7 @@
  * Copyright © 2016 Intel Corporation
  */
 
+#include 
 #include 
 
 #include "gem/i915_gem_internal.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 76880fb8fc19..6ebda3d65086 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -3,6 +3,8 @@
  * Copyright © 2008-2015 Intel Corporation
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "i915_reg.h"
 #include "i915_scatterlist.h"
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 55512db29183..bb864655c495 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5f6e41636655..f93e6122f247 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -25,6 +25,8 @@
  *
  */
 
+#include 
+
 #include 
 
 #include "gt/intel_engine.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 869a2bda347b..fa79dfd85c9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -34,7 +34,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4967e79806f8..5e09a4e4b01a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.30.2

[Intel-gfx] [PATCH 3/5] drm/i915/gmbus: pass gpio reg to intel_gpio_setup()

2022-03-03 Thread Jani Nikula

Avoid the additional gmbus lookup on the pin.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 9dc66447d308..fd908e524875 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -322,14 +322,13 @@ intel_gpio_post_xfer(struct i2c_adapter *adapter)
 }
 
 static void
-intel_gpio_setup(struct intel_gmbus *bus, unsigned int pin)
+intel_gpio_setup(struct intel_gmbus *bus, i915_reg_t gpio_reg)
 {
-   struct drm_i915_private *dev_priv = bus->dev_priv;
struct i2c_algo_bit_data *algo;
 
algo = &bus->bit_algo;
 
-   bus->gpio_reg = GPIO(get_gmbus_pin(dev_priv, pin)->gpio);
+   bus->gpio_reg = gpio_reg;
bus->adapter.algo_data = algo;
algo->setsda = set_data;
algo->setscl = set_clock;
@@ -909,7 +908,7 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
if (IS_I830(dev_priv))
bus->force_bit = 1;
 
-   intel_gpio_setup(bus, pin);
+   intel_gpio_setup(bus, GPIO(gmbus_pin->gpio));
 
ret = i2c_add_adapter(&bus->adapter);
if (ret)
-- 
2.30.2

[Intel-gfx] [PATCH 4/5] drm/i915/gmbus: alloc intel_gmbus dynamically

2022-03-03 Thread Jani Nikula

Allocate the individual intel_gmbus structs dynamically. This lets us
hide struct intel_gmbus inside intel_gmbus.c completely. Also use the
cleanup function on the error path to avoid duplication.

Leave #include  in i915_drv.h for now, as it pulls in a
bunch of implicit dependencies.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 42 +++---
 drivers/gpu/drm/i915/i915_drv.h| 14 ++--
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index fd908e524875..2bb3494b93e2 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -38,6 +38,16 @@
 #include "intel_display_types.h"
 #include "intel_gmbus.h"
 
+struct intel_gmbus {
+   struct i2c_adapter adapter;
+#define GMBUS_FORCE_BIT_RETRY (1U << 31)
+   u32 force_bit;
+   u32 reg0;
+   i915_reg_t gpio_reg;
+   struct i2c_algo_bit_data bit_algo;
+   struct drm_i915_private *dev_priv;
+};
+
 struct gmbus_pin {
const char *name;
enum i915_gpio gpio;
@@ -881,7 +891,11 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
if (!gmbus_pin)
continue;
 
-   bus = &dev_priv->gmbus[pin];
+   bus = kzalloc(sizeof(*bus), GFP_KERNEL);
+   if (!bus) {
+   ret = -ENOMEM;
+   goto err;
+   }
 
bus->adapter.owner = THIS_MODULE;
bus->adapter.class = I2C_CLASS_DDC;
@@ -911,8 +925,12 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
intel_gpio_setup(bus, GPIO(gmbus_pin->gpio));
 
ret = i2c_add_adapter(&bus->adapter);
-   if (ret)
+   if (ret) {
+   kfree(bus);
goto err;
+   }
+
+   dev_priv->gmbus[pin] = bus;
}
 
intel_gmbus_reset(dev_priv);
@@ -920,24 +938,19 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
return 0;
 
 err:
-   while (pin--) {
-   if (!intel_gmbus_is_valid_pin(dev_priv, pin))
-   continue;
+   intel_gmbus_teardown(dev_priv);
 
-   bus = &dev_priv->gmbus[pin];
-   i2c_del_adapter(&bus->adapter);
-   }
return ret;
 }
 
 struct i2c_adapter *intel_gmbus_get_adapter(struct drm_i915_private *dev_priv,
unsigned int pin)
 {
-   if (drm_WARN_ON(&dev_priv->drm,
-   !intel_gmbus_is_valid_pin(dev_priv, pin)))
+   if (drm_WARN_ON(&dev_priv->drm, pin >= ARRAY_SIZE(dev_priv->gmbus) ||
+   !dev_priv->gmbus[pin]))
return NULL;
 
-   return &dev_priv->gmbus[pin].adapter;
+   return &dev_priv->gmbus[pin]->adapter;
 }
 
 void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
@@ -969,10 +982,13 @@ void intel_gmbus_teardown(struct drm_i915_private 
*dev_priv)
unsigned int pin;
 
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
-   if (!intel_gmbus_is_valid_pin(dev_priv, pin))
+   bus = dev_priv->gmbus[pin];
+   if (!bus)
continue;
 
-   bus = &dev_priv->gmbus[pin];
i2c_del_adapter(&bus->adapter);
+
+   kfree(bus);
+   dev_priv->gmbus[pin] = NULL;
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 457bc1993d19..869a2bda347b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -35,7 +35,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
@@ -99,6 +98,7 @@ struct intel_dpll_funcs;
 struct intel_encoder;
 struct intel_fbdev;
 struct intel_fdi_funcs;
+struct intel_gmbus;
 struct intel_hotplug_funcs;
 struct intel_initial_plane_config;
 struct intel_limit;
@@ -231,16 +231,6 @@ struct i915_drrs {
 #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
 #define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
 
-struct intel_gmbus {
-   struct i2c_adapter adapter;
-#define GMBUS_FORCE_BIT_RETRY (1U << 31)
-   u32 force_bit;
-   u32 reg0;
-   i915_reg_t gpio_reg;
-   struct i2c_algo_bit_data bit_algo;
-   struct drm_i915_private *dev_priv;
-};
-
 struct i915_suspend_saved_registers {
u32 saveDSPARB;
u32 saveSWF0[16];
@@ -510,7 +500,7 @@ struct drm_i915_private {
 
struct intel_dmc dmc;
 
-   struct intel_gmbus gmbus[GMBUS_NUM_PINS];
+   struct intel_gmbus *gmbus[GMBUS_NUM_PINS];
 
/** gmbus_mutex protects against concurrent usage of the single hw gmbus
 * controller on different i2c buses. */
-- 
2.30.2

[Intel-gfx] [PATCH 2/5] drm/i915/gmbus: reduce gmbus pin lookups in gmbus setup

2022-03-03 Thread Jani Nikula

Avoid separate pin lookups for validity and name.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 9cbf7f9a1e2e..9dc66447d308 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -876,7 +876,10 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
init_waitqueue_head(&dev_priv->gmbus_wait_queue);
 
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
-   if (!intel_gmbus_is_valid_pin(dev_priv, pin))
+   const struct gmbus_pin *gmbus_pin;
+
+   gmbus_pin = get_gmbus_pin(dev_priv, pin);
+   if (!gmbus_pin)
continue;
 
bus = &dev_priv->gmbus[pin];
@@ -885,8 +888,7 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
bus->adapter.class = I2C_CLASS_DDC;
snprintf(bus->adapter.name,
 sizeof(bus->adapter.name),
-"i915 gmbus %s",
-get_gmbus_pin(dev_priv, pin)->name);
+"i915 gmbus %s", gmbus_pin->name);
 
bus->adapter.dev.parent = &pdev->dev;
bus->dev_priv = dev_priv;
-- 
2.30.2

[Intel-gfx] [PATCH v2 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address

2022-03-03 Thread Balasubramani Vivekanandan

Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
implementation in i915 driver and use the functions from drm_cache.c.

A variant of drm_memcpy_from_wc() is added in drm_cache.c which accepts
address as argument instead of iosys_map for destination. It is a very
common scenario in i915 to copy from a WC memory type, which may be an
io memory or a system memory to a destination address pointing to system
memory. To avoid the overhead of creating iosys_map type for the
destination, new variant is created to accept the address directly.

Also a new function is exported in drm_cache.c to find if the fast copy
is supported by the platform or not. It is required for i915.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Hellstr_m 
Cc: Lucas De Marchi 

Signed-off-by: Balasubramani Vivekanandan 
---
 drivers/gpu/drm/drm_cache.c | 54 +
 include/drm/drm_cache.h |  3 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a21c1350eb09..97959eecc300 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -358,6 +358,54 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
 }
 EXPORT_SYMBOL(drm_memcpy_from_wc);
 
+/**
+ * drm_memcpy_from_wc_vaddr - Perform the fastest available memcpy from a 
source
+ * that may be WC to a destination in system memory.
+ * @dst: The destination pointer
+ * @src: The source pointer
+ * @len: The size of the area to transfer in bytes
+ *
+ * Same as drm_memcpy_from_wc except destination is accepted as system memory
+ * address. Useful in situations where passing destination address as iosys_map
+ * is simply an overhead and can be avoided.
+ */
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ unsigned long len)
+{
+   if (WARN_ON(in_interrupt())) {
+   iosys_map_memcpy_from(dst, src, 0, len);
+   return;
+   }
+
+   if (static_branch_likely(&has_movntdqa)) {
+   __drm_memcpy_from_wc(dst,
+src->is_iomem ?
+(void const __force *)src->vaddr_iomem :
+src->vaddr,
+len);
+   return;
+   }
+
+   iosys_map_memcpy_from(dst, src, 0, len);
+}
+EXPORT_SYMBOL(drm_memcpy_from_wc_vaddr);
+
+/*
+ * drm_memcpy_fastcopy_supported - Returns if fast copy using non-temporal
+ * instructions is supported
+ *
+ * Returns true if platform has support for fast copying from wc memory type
+ * using non-temporal instructions. Else false.
+ */
+bool drm_memcpy_fastcopy_supported(void)
+{
+   if (static_branch_likely(&has_movntdqa))
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
 /*
  * drm_memcpy_init_early - One time initialization of the WC memcpy code
  */
@@ -382,6 +430,12 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
 }
 EXPORT_SYMBOL(drm_memcpy_from_wc);
 
+bool drm_memcpy_fastcopy_supported(void)
+{
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
 void drm_memcpy_init_early(void)
 {
 }
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 22deb216b59c..8f48e4dcd7dc 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -77,4 +77,7 @@ void drm_memcpy_init_early(void);
 void drm_memcpy_from_wc(struct iosys_map *dst,
const struct iosys_map *src,
unsigned long len);
+bool drm_memcpy_fastcopy_supported(void);
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ unsigned long len);
 #endif
-- 
2.25.1

[Intel-gfx] [PATCH v2 0/7] drm/i915: Use the memcpy_from_wc function from drm

2022-03-03 Thread Balasubramani Vivekanandan

drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc().
drm_memcpy_from_wc() was the recent addition through the series
https://patchwork.freedesktop.org/patch/436276/?series=90681&rev=6

The goal of this patch series is to change all users of
i915_memcpy_from_wc() to drm_memcpy_from_wc() and a have common
implementation in drm and eventually remove the copy from i915.

Another benefit of using memcpy functions from drm is that
drm_memcpy_from_wc() is available for non-x86 architectures.
i915_memcpy_from_wc() is implemented only for x86 and prevents building
i915 for ARM64.
drm_memcpy_from_wc() does fast copy using non-temporal instructions for
x86 and for other architectures makes use of memcpy() family of
functions as fallback.

Another major difference is unlike i915_memcpy_from_wc(),
drm_memcpy_from_wc() will not fail if the passed address argument is not
alignment to be used with non-temporal load instructions or if the
platform lacks support for those instructions (non-temporal load
instructions are provided through SSE4.1 instruction set extension).
Instead drm_memcpy_from_wc() continues with fallback functions to
complete the copy.
This relieves the caller from checking the return value of
i915_memcpy_from_wc() and explicitly using a fallback.

Follow up series will be created to remove the memcpy_from_wc functions
from i915 once the dependency is completely removed.

v2: Fixed missing check to find if the address is from system memory or
io memory and use the right initialization function to construct the
iosys_map structure (Review feedback from Lucas)

Cc: Jani Nikula 
Cc: Lucas De Marchi  
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chris Wilson  
Cc: Thomas Hellstr_m  
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Nirmoy Das 

Balasubramani Vivekanandan (7):
  drm: Relax alignment constraint for destination address
  drm: Add drm_memcpy_from_wc() variant which accepts destination
address
  drm/i915: use the memcpy_from_wc call from the drm
  drm/i915/guc: use the memcpy_from_wc call from the drm
  drm/i915/selftests: use the memcpy_from_wc call from the drm
  drm/i915/gt: Avoid direct dereferencing of io memory
  drm/i915: Avoid dereferencing io mapped memory

 drivers/gpu/drm/drm_cache.c   | 98 +--
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  6 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  | 21 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 15 ++-
 drivers/gpu/drm/i915/i915_gpu_error.c | 45 +
 .../drm/i915/selftests/intel_memory_region.c  | 41 +---
 include/drm/drm_cache.h   |  3 +
 7 files changed, 174 insertions(+), 55 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v2 1/7] drm: Relax alignment constraint for destination address

2022-03-03 Thread Balasubramani Vivekanandan

There is no need for the destination address to be aligned to 16 byte
boundary to be able to use the non-temporal instructions while copying.
Non-temporal instructions are used only for loading from the source
address which has alignment constraints.
We only need to take care of using the right instructions, based on
whether destination address is aligned or not, while storing the data to
the destination address.

__memcpy_ntdqu is copied from i915/i915_memcpy.c

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chris Wilson 

Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/drm_cache.c | 44 -
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index c3e6e615bf09..a21c1350eb09 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -278,18 +278,50 @@ static void __memcpy_ntdqa(void *dst, const void *src, 
unsigned long len)
kernel_fpu_end();
 }
 
+static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
+{
+   kernel_fpu_begin();
+
+   while (len >= 4) {
+   asm("movntdqa   (%0), %%xmm0\n"
+   "movntdqa 16(%0), %%xmm1\n"
+   "movntdqa 32(%0), %%xmm2\n"
+   "movntdqa 48(%0), %%xmm3\n"
+   "movups %%xmm0,   (%1)\n"
+   "movups %%xmm1, 16(%1)\n"
+   "movups %%xmm2, 32(%1)\n"
+   "movups %%xmm3, 48(%1)\n"
+   :: "r" (src), "r" (dst) : "memory");
+   src += 64;
+   dst += 64;
+   len -= 4;
+   }
+   while (len--) {
+   asm("movntdqa (%0), %%xmm0\n"
+   "movups %%xmm0, (%1)\n"
+   :: "r" (src), "r" (dst) : "memory");
+   src += 16;
+   dst += 16;
+   }
+
+   kernel_fpu_end();
+}
+
 /*
  * __drm_memcpy_from_wc copies @len bytes from @src to @dst using
- * non-temporal instructions where available. Note that all arguments
- * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
- * of 16.
+ * non-temporal instructions where available. Note that @src must be aligned to
+ * 16 bytes and @len must be a multiple of 16.
  */
 static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
 {
-   if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+   if (unlikely(((unsigned long)src | len) & 15)) {
memcpy(dst, src, len);
-   else if (likely(len))
-   __memcpy_ntdqa(dst, src, len >> 4);
+   } else if (likely(len)) {
+   if (IS_ALIGNED((unsigned long)dst, 16))
+   __memcpy_ntdqa(dst, src, len >> 4);
+   else
+   __memcpy_ntdqu(dst, src, len >> 4);
+   }
 }
 
 /**
-- 
2.25.1

[Intel-gfx] [PATCH v2 7/7] drm/i915: Avoid dereferencing io mapped memory

2022-03-03 Thread Balasubramani Vivekanandan

Pointer passed to zlib_deflate() for compression could point to io
mapped memory and might end up in direct derefencing.
io mapped memory is copied to a temporary buffer, which is then shared
to zlib_deflate(), only for the case where platform supports fast copy
using non-temporal instructions. If the platform lacks support,
then io mapped memory is directly used.

Direct dereferencing of io memory makes driver not portable outside
x86 and should be avoided.

With this patch, io memory is always copied to a temporary buffer
irrespective of platform support for fast copy. The
i915_has_memcpy_from_wc() check is removed. And
drm_memcpy_from_wc_vaddr() is now used for copying instead of
i915_memcpy_from_wc() for 2 reasons.
- i915_memcpy_from_wc() will be deprecated.
- drm_memcpy_from_wc_vaddr() will not fail if the fast copy is not
supported instead continues copying using memcpy_fromio as fallback.

Signed-off-by: Balasubramani Vivekanandan 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 45 +++
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4967e79806f8..1ca5072b85db 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -259,9 +259,12 @@ static bool compress_init(struct i915_vma_compress *c)
return false;
}
 
-   c->tmp = NULL;
-   if (i915_has_memcpy_from_wc())
-   c->tmp = pool_alloc(&c->pool, ALLOW_FAIL);
+   c->tmp = pool_alloc(&c->pool, ALLOW_FAIL);
+   if (!c->tmp) {
+   kfree(zstream->workspace);
+   pool_fini(&c->pool);
+   return false;
+   }
 
return true;
 }
@@ -293,15 +296,17 @@ static void *compress_next_page(struct i915_vma_compress 
*c,
 }
 
 static int compress_page(struct i915_vma_compress *c,
-void *src,
-struct i915_vma_coredump *dst,
-bool wc)
+struct iosys_map *src,
+struct i915_vma_coredump *dst)
 {
struct z_stream_s *zstream = &c->zstream;
 
-   zstream->next_in = src;
-   if (wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+   if (src->is_iomem) {
+   drm_memcpy_from_wc_vaddr(c->tmp, src, PAGE_SIZE);
zstream->next_in = c->tmp;
+   } else {
+   zstream->next_in = src->vaddr;
+   }
zstream->avail_in = PAGE_SIZE;
 
do {
@@ -390,9 +395,8 @@ static bool compress_start(struct i915_vma_compress *c)
 }
 
 static int compress_page(struct i915_vma_compress *c,
-void *src,
-struct i915_vma_coredump *dst,
-bool wc)
+struct iosys_map *src,
+struct i915_vma_coredump *dst)
 {
void *ptr;
 
@@ -400,8 +404,7 @@ static int compress_page(struct i915_vma_compress *c,
if (!ptr)
return -ENOMEM;
 
-   if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
-   memcpy(ptr, src, PAGE_SIZE);
+   drm_memcpy_from_wc_vaddr(ptr, src, PAGE_SIZE);
list_add_tail(&virt_to_page(ptr)->lru, &dst->page_list);
cond_resched();
 
@@ -1055,6 +1058,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
if (drm_mm_node_allocated(&ggtt->error_capture)) {
void __iomem *s;
dma_addr_t dma;
+   struct iosys_map src;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
mutex_lock(&ggtt->error_mutex);
@@ -1063,9 +1067,8 @@ i915_vma_coredump_create(const struct intel_gt *gt,
mb();
 
s = io_mapping_map_wc(&ggtt->iomap, slot, PAGE_SIZE);
-   ret = compress_page(compress,
-   (void  __force *)s, dst,
-   true);
+   iosys_map_set_vaddr_iomem(&src, s);
+   ret = compress_page(compress, &src, dst);
io_mapping_unmap(s);
 
mb();
@@ -1077,6 +1080,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
} else if (vma_res->bi.lmem) {
struct intel_memory_region *mem = vma_res->mr;
dma_addr_t dma;
+   struct iosys_map src;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
void __iomem *s;
@@ -1084,15 +1088,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
s = io_mapping_map_wc(&mem->iomap,
  dma - mem->region.start,
  PAGE_SIZE);
-   ret = compress_page(compress,
-   (void __force *)s, dst,
-

[Intel-gfx] [PATCH v2 6/7] drm/i915/gt: Avoid direct dereferencing of io memory

2022-03-03 Thread Balasubramani Vivekanandan

io mapped memory should not be directly dereferenced to ensure
portability. io memory should be read/written/copied using helper
functions.
i915_memcpy_from_wc() function was used to copy the data from io memory to
a temporary buffer and pointer to the temporary buffer was passed to CRC
calculation function.
But i915_memcpy_from_wc() only does a copy if the platform supports fast
copy using non-temporal instructions. Otherwise the pointer to io memory
was passed for CRC calculation. CRC function will directly dereference
io memory and would not work properly on non-x86 platforms.
To make it portable, it should be ensured always temporary buffer is
used for CRC and not io memory.
drm_memcpy_from_wc_vaddr() is now used for copying instead of
i915_memcpy_from_wc() for 2 reasons.
- i915_memcpy_from_wc() will be deprecated.
- drm_memcpy_from_wc_vaddr() will not fail if the fast copy is not
supported but uses memcpy_fromio as fallback for copying.

Cc: Matthew Brost 
Cc: Michał Winiarski 

Signed-off-by: Balasubramani Vivekanandan 
---
 drivers/gpu/drm/i915/gt/selftest_reset.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c 
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..79d2bd7ef3b9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -3,6 +3,7 @@
  * Copyright © 2018 Intel Corporation
  */
 
+#include 
 #include 
 
 #include "gem/i915_gem_stolen.h"
@@ -82,7 +83,7 @@ __igt_reset_stolen(struct intel_gt *gt,
for (page = 0; page < num_pages; page++) {
dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
void __iomem *s;
-   void *in;
+   struct iosys_map src_map;
 
ggtt->vm.insert_page(&ggtt->vm, dma,
 ggtt->error_capture.start,
@@ -98,10 +99,9 @@ __igt_reset_stolen(struct intel_gt *gt,
 ((page + 1) << PAGE_SHIFT) - 1))
memset_io(s, STACK_MAGIC, PAGE_SIZE);
 
-   in = (void __force *)s;
-   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
-   in = tmp;
-   crc[page] = crc32_le(0, in, PAGE_SIZE);
+   iosys_map_set_vaddr_iomem(&src_map, s);
+   drm_memcpy_from_wc_vaddr(tmp, &src_map, PAGE_SIZE);
+   crc[page] = crc32_le(0, tmp, PAGE_SIZE);
 
io_mapping_unmap(s);
}
@@ -122,7 +122,7 @@ __igt_reset_stolen(struct intel_gt *gt,
for (page = 0; page < num_pages; page++) {
dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
void __iomem *s;
-   void *in;
+   struct iosys_map src_map;
u32 x;
 
ggtt->vm.insert_page(&ggtt->vm, dma,
@@ -134,10 +134,9 @@ __igt_reset_stolen(struct intel_gt *gt,
  ggtt->error_capture.start,
  PAGE_SIZE);
 
-   in = (void __force *)s;
-   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
-   in = tmp;
-   x = crc32_le(0, in, PAGE_SIZE);
+   iosys_map_set_vaddr_iomem(&src_map, s);
+   drm_memcpy_from_wc_vaddr(tmp, &src_map, PAGE_SIZE);
+   x = crc32_le(0, tmp, PAGE_SIZE);
 
if (x != crc[page] &&
!__drm_mm_interval_first(>->i915->mm.stolen,
@@ -146,7 +145,7 @@ __igt_reset_stolen(struct intel_gt *gt,
pr_debug("unused stolen page %pa modified by GPU 
reset\n",
 &page);
if (count++ == 0)
-   igt_hexdump(in, PAGE_SIZE);
+   igt_hexdump(tmp, PAGE_SIZE);
max = page;
}
 
-- 
2.25.1

[Intel-gfx] [PATCH v2 3/7] drm/i915: use the memcpy_from_wc call from the drm

2022-03-03 Thread Balasubramani Vivekanandan

memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.

Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 372bc220faeb..5de657c3190e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -438,6 +438,8 @@ i915_gem_object_read_from_page_iomap(struct 
drm_i915_gem_object *obj, u64 offset
 {
void __iomem *src_map;
void __iomem *src_ptr;
+   struct iosys_map src;
+
dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >> 
PAGE_SHIFT);
 
src_map = io_mapping_map_wc(&obj->mm.region->iomap,
@@ -445,8 +447,8 @@ i915_gem_object_read_from_page_iomap(struct 
drm_i915_gem_object *obj, u64 offset
PAGE_SIZE);
 
src_ptr = src_map + offset_in_page(offset);
-   if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
-   memcpy_fromio(dst, src_ptr, size);
+   iosys_map_set_vaddr_iomem(&src, src_ptr);
+   drm_memcpy_from_wc_vaddr(dst, &src, size);
 
io_mapping_unmap(src_map);
 }
-- 
2.25.1

[Intel-gfx] [PATCH v2 4/7] drm/i915/guc: use the memcpy_from_wc call from the drm

2022-03-03 Thread Balasubramani Vivekanandan

memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.

v2: Check if the log object allocated from local memory or system memory
and according setup the iosys_map (Lucas)

Cc: Lucas De Marchi 

Signed-off-by: Balasubramani Vivekanandan 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index a24dc6441872..b9db765627ea 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -3,6 +3,7 @@
  * Copyright © 2014-2019 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -206,6 +207,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log 
*log)
enum guc_log_buffer_type type;
void *src_data, *dst_data;
bool new_overflow;
+   struct iosys_map src_map;
 
mutex_lock(&log->relay.lock);
 
@@ -282,14 +284,21 @@ static void guc_read_update_log_buffer(struct 
intel_guc_log *log)
}
 
/* Just copy the newly written data */
+   if (i915_gem_object_is_lmem(log->vma->obj))
+   iosys_map_set_vaddr_iomem(&src_map, (void __iomem 
*)src_data);
+   else
+   iosys_map_set_vaddr(&src_map, src_data);
+
if (read_offset > write_offset) {
-   i915_memcpy_from_wc(dst_data, src_data, write_offset);
+   drm_memcpy_from_wc_vaddr(dst_data, &src_map,
+write_offset);
bytes_to_copy = buffer_size - read_offset;
} else {
bytes_to_copy = write_offset - read_offset;
}
-   i915_memcpy_from_wc(dst_data + read_offset,
-   src_data + read_offset, bytes_to_copy);
+   iosys_map_incr(&src_map, read_offset);
+   drm_memcpy_from_wc_vaddr(dst_data + read_offset, &src_map,
+bytes_to_copy);
 
src_data += buffer_size;
dst_data += buffer_size;
-- 
2.25.1

[Intel-gfx] [PATCH v2 5/7] drm/i915/selftests: use the memcpy_from_wc call from the drm

2022-03-03 Thread Balasubramani Vivekanandan

memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.

v2: check if the source and destination memory address is from local
memory or system memory and initialize the iosys_map accordingly
(Lucas)

Cc: Lucas De Marchi 
Cc: Matthew Auld 
Cc: Thomas Hellstr_m 

Signed-off-by: Balasubramani Vivekanandan 
---
 .../drm/i915/selftests/intel_memory_region.c  | 41 +--
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c 
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index ba32893e0873..d16ecb905f3b 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -7,6 +7,7 @@
 #include 
 
 #include 
+#include 
 
 #include "../i915_selftest.h"
 
@@ -1133,7 +1134,7 @@ static const char *repr_type(u32 type)
 
 static struct drm_i915_gem_object *
 create_region_for_mapping(struct intel_memory_region *mr, u64 size, u32 type,
- void **out_addr)
+ struct iosys_map *out_addr)
 {
struct drm_i915_gem_object *obj;
void *addr;
@@ -1153,7 +1154,11 @@ create_region_for_mapping(struct intel_memory_region 
*mr, u64 size, u32 type,
return addr;
}
 
-   *out_addr = addr;
+   if (i915_gem_object_is_lmem(obj))
+   iosys_map_set_vaddr_iomem(out_addr, (void __iomem *)addr);
+   else
+   iosys_map_set_vaddr(out_addr, addr);
+
return obj;
 }
 
@@ -1164,24 +1169,33 @@ static int wrap_ktime_compare(const void *A, const void 
*B)
return ktime_compare(*a, *b);
 }
 
-static void igt_memcpy_long(void *dst, const void *src, size_t size)
+static void igt_memcpy_long(struct iosys_map *dst, struct iosys_map *src,
+   size_t size)
 {
-   unsigned long *tmp = dst;
-   const unsigned long *s = src;
+   unsigned long *tmp = dst->is_iomem ?
+   (unsigned long __force *)dst->vaddr_iomem :
+   dst->vaddr;
+   const unsigned long *s = src->is_iomem ?
+   (unsigned long __force *)src->vaddr_iomem :
+   src->vaddr;
 
size = size / sizeof(unsigned long);
while (size--)
*tmp++ = *s++;
 }
 
-static inline void igt_memcpy(void *dst, const void *src, size_t size)
+static inline void igt_memcpy(struct iosys_map *dst, struct iosys_map *src,
+ size_t size)
 {
-   memcpy(dst, src, size);
+   memcpy(dst->is_iomem ? (void __force *)dst->vaddr_iomem : dst->vaddr,
+  src->is_iomem ? (void __force *)src->vaddr_iomem : src->vaddr,
+  size);
 }
 
-static inline void igt_memcpy_from_wc(void *dst, const void *src, size_t size)
+static inline void igt_memcpy_from_wc(struct iosys_map *dst, struct iosys_map 
*src,
+ size_t size)
 {
-   i915_memcpy_from_wc(dst, src, size);
+   drm_memcpy_from_wc(dst, src, size);
 }
 
 static int _perf_memcpy(struct intel_memory_region *src_mr,
@@ -1191,7 +1205,8 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
struct drm_i915_private *i915 = src_mr->i915;
const struct {
const char *name;
-   void (*copy)(void *dst, const void *src, size_t size);
+   void (*copy)(struct iosys_map *dst, struct iosys_map *src,
+size_t size);
bool skip;
} tests[] = {
{
@@ -1205,11 +1220,11 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
{
"memcpy_from_wc",
igt_memcpy_from_wc,
-   !i915_has_memcpy_from_wc(),
+   !drm_memcpy_fastcopy_supported(),
},
};
struct drm_i915_gem_object *src, *dst;
-   void *src_addr, *dst_addr;
+   struct iosys_map src_addr, dst_addr;
int ret = 0;
int i;
 
@@ -1237,7 +1252,7 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
 
t0 = ktime_get();
 
-   tests[i].copy(dst_addr, src_addr, size);
+   tests[i].copy(&dst_addr, &src_addr, size);
 
t1 = ktime_get();
t[pass] = ktime_sub(t1, t0);
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/selftests: check the return value of kstrdup()

2022-03-03 Thread Xiaoke Wang

Matthew Auld wrote:
> Scratch that. it looks like the for() already accounts for this, as
> pointed out by Chris.

Yes, you are right. 
I rechecked and found this one is indeed an ordinary code smell.
Thank you for taking the time.


Xiaoke Wang

Re: [Intel-gfx] [PATCH v12 1/6] drm: Add arch arm64 for drm_clflush_virt_range

2022-03-03 Thread Robin Murphy


On 2022-03-02 15:55, Michael Cheng wrote:

Thanks for the feedback Robin!

Sorry my choices of word weren't that great, but what I meant is to 
understand how ARM flushes a range of dcache for device drivers, and not 
an equal to x86 clflush.


I believe the concern is if the CPU writes an update, that update might 
only be sitting in the CPU cache and never make it to device memory 
where the device can see it; there are specific places that we are 
supposed to flush the CPU caches to make sure our updates are visible to 
the hardware.


Ah, OK, if it's more about ordering, and it's actually write buffers 
rather than caches that you care about flushing, then we might be a lot 
safer, phew!


For a very simple overview, in a case where the device itself needs to 
observe memory writes in the correct order, e.g.:


data_descriptor.valid = 1;

clflush(&data_descriptor);

command_descriptor.data = &data_descriptor

writel(/* control register to read command to then read data */)

then dma_wmb() between the first two writes should be the right tool to 
ensure that the command does not observe the command update while the 
data update is still sat somewhere in a CPU write buffer.


If you want a slightly stronger notion that, at a given point, all prior 
writes have actually been issued and should now be visible (rather than 
just that they won't become visible in the wrong order whenever they 
do), then wmb() should suffice on arm64.


Note that wioth arm64 memory types, a Non-Cacheable mapping of DRAM for 
a non-coherent DMA mapping, or of VRAM in a prefetchable BAR, can still 
be write-buffered, so barriers still matter even when actual cache 
maintenance ops don't (and as before if you're trying to perform cache 
maintenance outside the DMA API then you've already lost anyway). MMIO 
registers should be mapped as Device memory via ioremap(), which is not 
bufferable, hence the barrier implicit in writel() effectively pushes 
out any prior buffered writes ahead of a register write, which is why we 
don't need to worry about this most of the time.


This is only a very rough overview, though, and I'm not familiar enough 
with x86 semantics, your hardware, or the exact use-case to be able to 
say whether barriers alone are anywhere near the right answer or not.


Robin.



+Matt Roper

Matt, Lucas, any feed back here?

On 2022-03-02 4:49 a.m., Robin Murphy wrote:

On 2022-02-25 19:27, Michael Cheng wrote:

Hi Robin,

[ +arm64 maintainers for their awareness, which would have been a 
good thing to do from the start ]


  * Thanks for adding the arm64 maintainer and sorry I didn't rope them
    in sooner.

Why does i915 need to ensure the CPU's instruction cache is coherent 
with its data cache? Is it a self-modifying driver?


  * Also thanks for pointing this out. Initially I was using
    dcache_clean_inval_poc, which seem to be the equivalently to what
    x86 is doing for dcache flushing, but it was giving me build errors
    since its not on the global list of kernel symbols. And after
    revisiting the documentation for caches_clean_inval_pou, it won't
    fly for what we are trying to do. Moving forward, what would you (or
    someone in the ARM community) suggest we do? Could it be possible to
    export dcache_clean_inval_poc as a global symbol?


Unlikely, unless something with a legitimate need for CPU-centric 
cache maintenance like kexec or CPU hotplug ever becomes modular.


In the case of a device driver, it's not even the basic issues of 
assuming to find direct equivalents to x86 semantics in other CPU 
architectures, or effectively reinventing parts of the DMA API, it's 
even bigger than that. Once you move from being integrated in a single 
vendor's system architecture to being on a discrete card, you 
fundamentally *no longer have any control over cache coherency*. 
Whether the host CPU architecture happens to be AArch64, RISC-V, or 
whatever doesn't really matter, you're at the mercy of 3rd-party PCIe 
and interconnect IP vendors, and SoC integrators. You'll find yourself 
in systems where PCIe simply cannot snoop any caches, where you'd 
better have the correct DMA API calls in place to have any hope of 
even the most basic functionality working properly; you'll find 
yourself in systems where even if the PCIe root complex claims to 
support No Snoop, your uncached traffic will still end up snooping 
stale data that got prefetched back into caches you thought you'd 
invalidated; you'll find yourself in systems where your memory 
attributes may or may not get forcibly rewritten by an IOMMU depending 
on the kernel config and/or command line.


It's not about simply finding a substitute for clflush, it's that the 
reasons you have for using clflush in the first place can no longer be 
assumed to be valid.


Robin.


On 2022-02-25 10:24 a.m., Robin Murphy wrote:
[ +arm64 maintainers for their awareness, which would have been a 
good thing to do from the star

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Jakob Koschel




> On 3. Mar 2022, at 05:58, David Laight  wrote:
> 
> From: Xiaomeng Tong
>> Sent: 03 March 2022 02:27
>> 
>> On Wed, 2 Mar 2022 14:04:06 +, David Laight
>>  wrote:
>>> I think that it would be better to make any alternate loop macro
>>> just set the variable to NULL on the loop exit.
>>> That is easier to code for and the compiler might be persuaded to
>>> not redo the test.
>> 
>> No, that would lead to a NULL dereference.
> 
> Why, it would make it b ethe same as the 'easy to use':
>   for (item = head; item; item = item->next) {
>   ...
>   if (...)
>   break;
>   ...
>   }
>   if (!item)
>   return;
> 
>> The problem is the mis-use of iterator outside the loop on exit, and
>> the iterator will be the HEAD's container_of pointer which pointers
>> to a type-confused struct. Sidenote: The *mis-use* here refers to
>> mistakely access to other members of the struct, instead of the
>> list_head member which acutally is the valid HEAD.
> 
> The problem is that the HEAD's container_of pointer should never
> be calculated at all.
> This is what is fundamentally broken about the current definition.
> 
>> IOW, you would dereference a (NULL + offset_of_member) address here.
> 
> Where?
> 
>> Please remind me if i missed something, thanks.
>> 
>> Can you share your "alternative definitions" details? thanks!
> 
> The loop should probably use as extra variable that points
> to the 'list node' in the next structure.
> Something like:
>   for (xxx *iter = head->next;
>   iter == &head ? ((item = NULL),0) : ((item = 
> list_item(iter),1));
>   iter = item->member->next) {
>  ...
> With a bit of casting you can use 'item' to hold 'iter'.

I think this would make sense, it would mean you only assign the containing
element on valid elements.

I was thinking something along the lines of:

#define list_for_each_entry(pos, head, member)  
\
for (struct list_head *list = head->next, typeof(pos) pos;  \
 list == head ? 0 : (( pos = list_entry(pos, list, member), 1));
\
 list = list->next)

Although the initialization block of the for loop is not valid C, I'm
not sure there is any way to declare two variables of a different type
in the initialization part of the loop.

I believe all this does is get rid of the &pos->member == (head) check
to terminate the list.
It alone will not fix any of the other issues that using the iterator
variable after the loop currently has.


AFAIK Adrián Moreno is working on doing something along those lines
for the list iterator in openvswitch (that was similar to the kernel
one before) [1].

I *think* they don't declare 'pos' within the loop which we *do want*
to avoid any uses of it after the loop.
(If pos is not declared in the initialization block, shadowing the
*outer* pos, it would just point to the last element of the list or stay
uninitialized if the list is empty).


[1] https://www.mail-archive.com/ovs-dev@openvswitch.org/msg63497.html


> 
>> 
>>> OTOH there may be alternative definitions that can be used to get
>>> the compiler (or other compiler-like tools) to detect broken code.
>>> Even if the definition can't possibly generate a working kerrnel.
>> 
>> The "list_for_each_entry_inside(pos, type, head, member)" way makes
>> the iterator invisiable outside the loop, and would be catched by
>> compiler if use-after-loop things happened.
> 
> It is also a compete PITA for anything doing a search.
> 
>   David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)
> 

- Jakob

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Xiaomeng Tong

> I think this would make sense, it would mean you only assign the containing
> element on valid elements.
>
> I was thinking something along the lines of:
>
> #define list_for_each_entry(pos, head, member)
> \
>   for (struct list_head *list = head->next, typeof(pos) pos;  \
>list == head ? 0 : (( pos = list_entry(pos, list, member), 1));
> \
>list = list->next)
>
> Although the initialization block of the for loop is not valid C, I'm
> not sure there is any way to declare two variables of a different type
> in the initialization part of the loop.

It can be done using a *nested loop*, like this:

#define list_for_each_entry(pos, head, member)  
\
for (struct list_head *list = head->next, cond = (struct list_head 
*)-1; cond == (struct list_head *)-1; cond = NULL) \
  for (typeof(pos) pos; \
 list == head ? 0 : (( pos = list_entry(pos, list, member), 1));
\
 list = list->next)

>
> I believe all this does is get rid of the &pos->member == (head) check
> to terminate the list.

Indeed, although the original way is harmless.

> It alone will not fix any of the other issues that using the iterator
> variable after the loop currently has.

Yes, but I stick with the list_for_each_entry_inside(pos, type, head, member)
way to make the iterator invisiable outside the loop (before and after the 
loop).
It is maintainable longer-term than "type(pos) pos" one and perfect.
see my explain:
https://lore.kernel.org/lkml/20220302093106.8402-1-xiam0nd.t...@gmail.com/
and list_for_each_entry_inside(pos, type, head, member) patch here:
https://lore.kernel.org/lkml/20220301075839.4156-3-xiam0nd.t...@gmail.com/

--
Xiaomeng Tong

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Xiaomeng Tong

> From: Xiaomeng Tong
> > Sent: 03 March 2022 07:27
> > 
> > On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > > The problem is the mis-use of iterator outside the loop on exit, and
> > > > the iterator will be the HEAD's container_of pointer which pointers
> > > > to a type-confused struct. Sidenote: The *mis-use* here refers to
> > > > mistakely access to other members of the struct, instead of the
> > > > list_head member which acutally is the valid HEAD.
> > >
> > > The problem is that the HEAD's container_of pointer should never
> > > be calculated at all.
> > > This is what is fundamentally broken about the current definition.
> > 
> > Yes, the rule is "the HEAD's container_of pointer should never be
> > calculated at all outside the loop", but how do you make sure everyone
> > follows this rule?
> > Everyone makes mistakes, but we can eliminate them all from the beginning
> > with the help of compiler which can catch such use-after-loop things.
> > 
> > > > IOW, you would dereference a (NULL + offset_of_member) address here.
> > >
> > >Where?
> > 
> > In the case where a developer do not follows the above rule, and mistakely
> > access a non-list-head member of the HEAD's container_of pointer outside
> > the loop. For example:
> > struct req{
> >   int a;
> >   struct list_head h;
> > }
> > struct req *r;
> > list_for_each_entry(r, HEAD, h) {
> >   if (r->a == 0x10)
> > break;
> > }
> > // the developer made a mistake: he didn't take this situation into
> > // account where all entries in the list are *r->a != 0x10*, and now
> > // the r is the HEAD's container_of pointer.
> > r->a = 0x20;
> > Thus the "r->a = 0x20" would dereference a (NULL + offset_of_member)
> > address here.
> 
> That is just a bug.
> No different to failing to check anything else might 'return'
> a NULL pointer.

Yes, but it‘s a mistake everyone has made and will make, we should avoid
this at the beginning with the help of compiler.

> Because it is a NULL dereference you find out pretty quickly.

AFAIK，NULL dereference is a undefined bahavior, can compiler quickly
catch it? Or it can only be applied to some simple/restricted cases.

> The existing loop leaves you with a valid pointer to something
> that isn't a list item.
> 
> > > > Please remind me if i missed something, thanks.
> > > >
> > > > Can you share your "alternative definitions" details? thanks!
> > >
> > > The loop should probably use as extra variable that points
> > > to the 'list node' in the next structure.
> > > Something like:
> > >   for (xxx *iter = head->next;
> > >   iter == &head ? ((item = NULL),0) : ((item = 
> > > list_item(iter),1));
> > >   iter = item->member->next) {
> > >  ...
> > > With a bit of casting you can use 'item' to hold 'iter'.
> > 
> > you still can not make sure everyone follows this rule:
> > "do not use iterator outside the loop" without the help of compiler,
> > because item is declared outside the loop.
> 
> That one has 'iter' defined in the loop.

Oh, sorry, I misunderstood. Then this is the same way with my way of
list_for_each_entry_inside(pos, type, head, member), which declare
the iterator inside the loop.
You go further and make things like "&pos->member == (head)" goes away
to avoid calculate the HEAD's container_of pointer, although the
calculation is harmless.

> 
> > BTW, to avoid ambiguity，the "alternative definitions" here i asked is
> > something from you in this context:
> > "OTOH there may be alternative definitions that can be used to get
> > the compiler (or other compiler-like tools) to detect broken code.
> > Even if the definition can't possibly generate a working kerrnel."
> 
> I was thinking of something like:
>   if ((pos = list_first)), 1) pos = NULL else
> so that unchecked dereferences after the loop will be detectable
> as NULL pointer offsets - but that in itself isn't enough to avoid
> other warnings.
> 

Do you mean put this right after the loop (I changed somthing that i
do not understand, please correct me if i am worng, thanks):
   if (pos == list_first) pos = NULL; else
and compiler can detect the following NULL derefernce?
But if the NULL derefernce is just right after the loop originally,
it will be masked by the *else* keyword。

> > > > The "list_for_each_entry_inside(pos, type, head, member)" way makes
> > > > the iterator invisiable outside the loop, and would be catched by
> > > > compiler if use-after-loop things happened.
> > 
> > > It is also a compete PITA for anything doing a search.
> > 
> > You mean it would be a burden on search? can you show me some examples?
> 
> The whole business of having to save the pointer to the located item
> before breaking the loop, remembering to have set it to NULL earlier etc.

Ok, i see. And then you need pass a "item" to the list_for_each_entry macro
as a new argument.

> 
> It is so much better if y

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Xiaomeng Tong

correct for typo:

-for (struct list_head *list = head->next, cond = (struct list_head *)-1; cond 
== (struct list_head *)-1; cond = NULL) \
+for (struct list_head *list = head->next, *cond = (struct list_head *)-1; cond 
== (struct list_head *)-1; cond = NULL) \

--
Xiaomeng Tong

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Xiaomeng Tong

On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > The problem is the mis-use of iterator outside the loop on exit, and
> > the iterator will be the HEAD's container_of pointer which pointers
> > to a type-confused struct. Sidenote: The *mis-use* here refers to
> > mistakely access to other members of the struct, instead of the
> > list_head member which acutally is the valid HEAD.
>
> The problem is that the HEAD's container_of pointer should never
> be calculated at all.
> This is what is fundamentally broken about the current definition.

Yes, the rule is "the HEAD's container_of pointer should never be
calculated at all outside the loop", but how do you make sure everyone
follows this rule?
Everyone makes mistakes, but we can eliminate them all from the beginning
with the help of compiler which can catch such use-after-loop things.

> > IOW, you would dereference a (NULL + offset_of_member) address here.
>
>Where?

In the case where a developer do not follows the above rule, and mistakely
access a non-list-head member of the HEAD's container_of pointer outside
the loop. For example:
struct req{
  int a;
  struct list_head h;
}
struct req *r;
list_for_each_entry(r, HEAD, h) {
  if (r->a == 0x10)
break;
}
// the developer made a mistake: he didn't take this situation into
// account where all entries in the list are *r->a != 0x10*, and now
// the r is the HEAD's container_of pointer. 
r->a = 0x20;
Thus the "r->a = 0x20" would dereference a (NULL + offset_of_member)
address here.

> > Please remind me if i missed something, thanks.
> >
> > Can you share your "alternative definitions" details? thanks!
>
> The loop should probably use as extra variable that points
> to the 'list node' in the next structure.
> Something like:
>   for (xxx *iter = head->next;
>   iter == &head ? ((item = NULL),0) : ((item = 
> list_item(iter),1));
>   iter = item->member->next) {
>  ...
> With a bit of casting you can use 'item' to hold 'iter'.

you still can not make sure everyone follows this rule: 
"do not use iterator outside the loop" without the help of compiler,
because item is declared outside the loop.

BTW, to avoid ambiguity，the "alternative definitions" here i asked is
something from you in this context:
"OTOH there may be alternative definitions that can be used to get
the compiler (or other compiler-like tools) to detect broken code.
Even if the definition can't possibly generate a working kerrnel."

> > 
> > > OTOH there may be alternative definitions that can be used to get
> > > the compiler (or other compiler-like tools) to detect broken code.
> > > Even if the definition can't possibly generate a working kerrnel.
> > 
> > The "list_for_each_entry_inside(pos, type, head, member)" way makes
> > the iterator invisiable outside the loop, and would be catched by
> > compiler if use-after-loop things happened.

> It is also a compete PITA for anything doing a search.

You mean it would be a burden on search? can you show me some examples?

Or you mean it is too long the list_for_each_entry_inside* string to live
in one single line, and should spilt into two line? If it is the case, there
are 2 way to mitigate it.
1. pass a shorter t as struct type to the macro
2. after all list_for_each_entry macros be replaced with
list_for_each_entry_inside, remove the list_for_each_entry implementations
and rename all list_for_each_entry_inside use back to the origin
list_for_each_entry in a single patch.

For me, it is acceptable and not a such big problem.

--
Xiaomeng Tong

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Xiaomeng Tong

On Wed, 2 Mar 2022 14:04:06 +, David Laight
 wrote:
> I think that it would be better to make any alternate loop macro
> just set the variable to NULL on the loop exit.
> That is easier to code for and the compiler might be persuaded to
> not redo the test.

No, that would lead to a NULL dereference.

The problem is the mis-use of iterator outside the loop on exit, and
the iterator will be the HEAD's container_of pointer which pointers
to a type-confused struct. Sidenote: The *mis-use* here refers to
mistakely access to other members of the struct, instead of the
list_head member which acutally is the valid HEAD.

IOW, you would dereference a (NULL + offset_of_member) address here.

Please remind me if i missed something, thanks.

> OTOH there may be alternative definitions that can be used to get
> the compiler (or other compiler-like tools) to detect broken code.
> Even if the definition can't possibly generate a working kerrnel.

The "list_for_each_entry_inside(pos, type, head, member)" way makes
the iterator invisiable outside the loop, and would be catched by
compiler if use-after-loop things happened.

Can you share your "alternative definitions" details? thanks!

--
Xiaomeng Tong

Re: [Intel-gfx] [PATCH v9] drm/amdgpu: add drm buddy support to amdgpu

2022-03-03 Thread Christian König





Am 01.03.22 um 21:38 schrieb Arunpravin:

- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy

v2(Matthew Auld):
   - replace spinlock with mutex as we call kmem_cache_zalloc
 (..., GFP_KERNEL) in drm_buddy_alloc() function

   - lock drm_buddy_block_trim() function as it calls
 mark_free/mark_split are all globally visible

v3(Matthew Auld):
   - remove trim method error handling as we address the failure case
 at drm_buddy_block_trim() function

v4:
   - fix warnings reported by kernel test robot 

v5:
   - fix merge conflict issue

v6:
   - fix warnings reported by kernel test robot 

v7:
   - remove DRM_BUDDY_RANGE_ALLOCATION flag usage

v8:
   - keep DRM_BUDDY_RANGE_ALLOCATION flag usage
   - resolve conflicts created by drm/amdgpu: remove VRAM accounting v2

v9(Christian):
   - rename label name as fallback
   - move struct amdgpu_vram_mgr to amdgpu_vram_mgr.h
   - remove unnecessary flags from struct amdgpu_vram_reservation
   - rewrite block NULL check condition
   - change else style as per coding standard
   - rewrite the node max size
   - add a helper function to fetch the first entry from the list

Signed-off-by: Arunpravin 
---
  drivers/gpu/drm/Kconfig   |   1 +
  .../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h|  97 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  10 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 249 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h  |  68 +
  5 files changed, 289 insertions(+), 136 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f1422bee3dcc..5133c3f028ab 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   select DRM_BUDDY
help
  Choose this option if you have a recent AMD Radeon graphics card.
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h

index acfa207cf970..864c609ba00b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,15 @@
  #include 
  #include 
  
+#include "amdgpu_vram_mgr.h"

+
  /* state back for walking over vram_mgr and gtt_mgr allocations */
  struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
-   struct drm_mm_node  *node;
+   void*node;
+   uint32_tmem_type;
  };
  
  /**

@@ -52,27 +55,63 @@ static inline void amdgpu_res_first(struct ttm_resource 
*res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
  {
+   struct drm_buddy_block *block;
+   struct list_head *head, *next;
struct drm_mm_node *node;
  
-	if (!res || res->mem_type == TTM_PL_SYSTEM) {

-   cur->start = start;
-   cur->size = size;
-   cur->remaining = size;
-   cur->node = NULL;
-   WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
-   return;
-   }
+   if (!res)
+   goto fallback;
  
  	BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
  
-	node = to_ttm_range_mgr_node(res)->mm_nodes;

-   while (start >= node->size << PAGE_SHIFT)
-   start -= node++->size << PAGE_SHIFT;
+   cur->mem_type = res->mem_type;
+
+   switch (cur->mem_type) {
+   case TTM_PL_VRAM:
+   head = &to_amdgpu_vram_mgr_node(res)->blocks;
+
+   block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+   if (!block)
+   goto fallback;
+
+   while (start >= amdgpu_node_size(block)) {
+   start -= amdgpu_node_size(block);
+
+   next = block->link.next;
+   if (next != head)
+   block = list_entry(next, struct 
drm_buddy_block, link);
+   }
+
+   cur->start = amdgpu_node_start(block) + start;
+   cur->size = min(amdgpu_node_size(block) - start, size);
+   cur->remaining = size;
+   cur->node = block;
+   break;
+   case TTM_PL_TT:
+   node = to_ttm_range_mgr_node(res)->mm_nodes;
+   while (start >= node->size << PAGE_SHIFT)
+   start -= node++->size << PAGE_SHIFT;
+
+   cur->start = (node->start << PAGE_SHIFT) + start;
+   cur->size = min((node->size << PAGE_SHIFT) - start, size);
+   cur->rema

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Remove the vm open count

2022-03-03 Thread Matthew Auld

On Wed, 2 Mar 2022 at 10:22, Thomas Hellström
 wrote:
>
> vms are not getting properly closed. Rather than fixing that,
> Remove the vm open count and instead rely on the vm refcount.
>
> The vm open count existed solely to break the strong references the
> vmas had on the vms. Now instead make those references weak and
> ensure vmas are destroyed when the vm is destroyed.
>
> Unfortunately if the vm destructor and the object destructor both
> wants to destroy a vma, that may lead to a race in that the vm
> destructor just unbinds the vma and leaves the actual vma destruction
> to the object destructor. However in order for the object destructor
> to ensure the vma is unbound it needs to grab the vm mutex. In order
> to keep the vm mutex alive until the object destructor is done with
> it, somewhat hackishly grab a vm_resv refcount that is released late
> in the vma destruction process, when the vm mutex is no longer needed.
>
> v2: Address review-comments from Niranjana
> - Clarify that the struct i915_address_space::skip_pte_rewrite is a hack and
>   should ideally be replaced in an upcoming patch.
> - Remove an unneeded continue in clear_vm_list and update comment.
>
> Co-developed-by: Niranjana Vishwanathapura 
> 
> Signed-off-by: Niranjana Vishwanathapura 
> Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-03-03 Thread Abhinav Kumar





On 3/2/2022 10:31 AM, Laurent Pinchart wrote:

Hi Abhinav,

On Wed, Mar 02, 2022 at 10:28:03AM -0800, Abhinav Kumar wrote:

On 2/28/2022 5:42 AM, Laurent Pinchart wrote:

On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:

On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:

On Mon, 28 Feb 2022, Laurent Pinchart wrote:

On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:

On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:

On Wed, 02 Feb 2022, Laurent Pinchart wrote:

On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:

On Wed, 02 Feb 2022, Laurent Pinchart wrote:

On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:

Changing rcar_du driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
   drivers/gpu/drm/rcar-du/rcar_du_crtc.h  | 2 ++
   drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
   2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 66e8839db708..68f387a04502 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -72,6 +72,8 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;

+ struct drm_connector connector;
+ struct drm_encoder encoder;


Those fields are, at best, poorly named. Furthermore, there's no need in
this driver or in other drivers using drm_writeback_connector to create
an encoder or connector manually. Let's not polute all drivers because
i915 doesn't have its abstractions right.


i915 uses the quite common model for struct inheritance:

   struct intel_connector {
   struct drm_connector base;
   /* ... */
   }

Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
radeon, tilcdc, and vboxvideo.

We could argue about the relative merits of that abstraction, but I
think the bottom line is that it's popular and the drivers using it are
not going to be persuaded to move away from it.


Nobody said inheritance is bad.


It's no coincidence that the drivers who've implemented writeback so far
(komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
because the drm_writeback_connector midlayer does, forcing the issue.


Are you sure it's not a coincidence ? :-)

The encoder and especially connector created by drm_writeback_connector
are there only because KMS requires a drm_encoder and a drm_connector to
be exposed to userspace (and I could argue that using a connector for
writeback is a hack, but that won't change). The connector is "virtual",
I still fail to see why i915 or any other driver would need to wrap it
into something else. The whole point of the drm_writeback_connector
abstraction is that drivers do not have to manage the writeback
drm_connector manually, they shouldn't touch it at all.


The thing is, drm_writeback_connector_init() calling
drm_connector_init() on the drm_connector embedded in
drm_writeback_connector leads to that connector being added to the
drm_device's list of connectors. Ditto for the encoder.

All the driver code that handles drm_connectors would need to take into
account they might not be embedded in intel_connector. Throughout the
driver. Ditto for the encoders.


The assumption that a connector is embedded in intel_connector doesn't
really play that well with how bridge and panel connectors work.. so
in general this seems like a good thing to unwind.

But as a point of practicality, i915 is a large driver covering a lot
of generations of hw with a lot of users.  So I can understand
changing this design isn't something that can happen quickly or
easily.  IMO we should allow i915 to create it's own connector for
writeback, and just document clearly that this isn't the approach new
drivers should take.  I mean, I understand idealism, but sometimes a
dose of pragmatism is needed. :-)


i915 is big, but so is Intel. It's not fair to treat everybody else as a
second class citizen and let Intel get away without doing its homework.


Laurent, as you accuse us of not doing our homework, I'll point out that
we've been embedding drm crtc, encoder and connector ever since
modesetting support was added to i915 in 2008, since before *any* of the
things you now use as a rationale for asking us to do a massive rewrite
of the driver existed.

It's been ok to embed those structures for well over ten years. It's a
common pattern, basically throughout the kernel. Other drivers do it
too, not just i915. There hasn't been the slightest hint this should not
be done until this very conversation.


I want to see this refactoring effort moving forward in i915 (and moving
to drm_bridge would then be a good idea too). If writeback support in
i915 urgent, then we can discuss *temporary* pragmatic

[Intel-gfx] ✗ Fi.CI.IGT: failure for Remove usage of list iterator past the loop body (rev5)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Remove usage of list iterator past the loop body (rev5)
URL   : https://patchwork.freedesktop.org/series/100822/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11317_full -> Patchwork_22471_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@hibernate:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-iclb8/igt@gem_...@hibernate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-iclb3/igt@gem_...@hibernate.html
- shard-snb:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-snb5/igt@gem_...@hibernate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-snb5/igt@gem_...@hibernate.html
- shard-apl:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/igt@gem_...@hibernate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-apl2/igt@gem_...@hibernate.html

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-kbl:  [PASS][7] -> [INCOMPLETE][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-kbl6/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-kbl6/igt@gem_exec_suspend@basic-s4-devi...@smem.html
- shard-glk:  [PASS][9] -> [INCOMPLETE][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-glk1/igt@gem_exec_suspend@basic-s4-devi...@smem.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][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-rkl-2/igt@gem_...@hibernate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-rkl-5/igt@gem_...@hibernate.html

  * igt@kms_hdmi_inject@inject-audio:
- {shard-rkl}:[PASS][13] -> [SKIP][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-rkl-6/igt@kms_hdmi_inj...@inject-audio.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-rkl-5/igt@kms_hdmi_inj...@inject-audio.html

  * 
{igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][15]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][16], [PASS][17], [PASS][18], [PASS][19], 
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [FAIL][34], [PASS][35], [PASS][36], [PASS][37], 
[PASS][38], [PASS][39], [PASS][40]) ([i915#4386]) -> ([PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], 
[PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59], [PASS][60], 
[PASS][61], [PASS][62], [PASS][63], [PASS][64], [PASS][65])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [23]: 
http

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Use I915_BO_ALLOC_CONTIGUOUS flag for DPT (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/dg2: Use I915_BO_ALLOC_CONTIGUOUS flag for DPT (rev2)
URL   : https://patchwork.freedesktop.org/series/97806/
State : failure

== Summary ==

Applying: drm/i915/dg2: Use I915_BO_ALLOC_CONTIGUOUS flag for DPT
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_dpt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_dpt.c
No changes -- Patch already applied.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: reduce overzealous alignment constraints for GGTT

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/gtt: reduce overzealous alignment constraints for GGTT
URL   : https://patchwork.freedesktop.org/series/100991/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11317_full -> Patchwork_22470_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk7/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22470/shard-glk8/igt@i915_selftest@l...@execlists.html

  
 Suppressed 

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

  * 
{igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22470/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html

  
New tests
-

  New tests have been introduced between CI_DRM_11317_full and 
Patchwork_22470_full:

### New IGT tests (1) ###

  * 
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
- Statuses : 1 pass(s)
- Exec time: [1.28] s

  

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][4], [PASS][5], [PASS][6], [PASS][7], 
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], 
[PASS][20], [PASS][21], [FAIL][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27], [PASS][28]) ([i915#4386]) -> ([PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl3/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl4/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl7/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl7/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl8/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl8/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl8/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl8/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-apl2/boot.htm

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Pimp async flip debugs

2022-03-03 Thread Lisovskiy, Stanislav

On Mon, Feb 14, 2022 at 12:55:32PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Print the offending plane/crtc id+name in the async flip debugs.

Reviewed-by: Stanislav Lisovskiy 

> 
> Cc: Stanislav Lisovskiy 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 63 ++--
>  1 file changed, 44 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 93db8ffa54f8..51ef393ff87b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7541,18 +7541,24 @@ static int intel_async_flip_check_hw(struct 
> intel_atomic_state *state, struct in
>   if (!new_crtc_state->uapi.async_flip)
>   return 0;
>  
> - if (intel_crtc_needs_modeset(new_crtc_state)) {
> - drm_dbg_kms(&i915->drm, "Modeset Required. Async flip not 
> supported\n");
> - return -EINVAL;
> - }
> -
>   if (!new_crtc_state->hw.active) {
> - drm_dbg_kms(&i915->drm, "CRTC inactive\n");
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] not active\n",
> + crtc->base.base.id, crtc->base.name);
>   return -EINVAL;
>   }
> +
> + if (intel_crtc_needs_modeset(new_crtc_state)) {
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] modeset required\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> +
>   if (old_crtc_state->active_planes != new_crtc_state->active_planes) {
>   drm_dbg_kms(&i915->drm,
> - "Active planes cannot be changed during async 
> flip\n");
> + "[CRTC:%d:%s] Active planes cannot be in async 
> flip\n",
> + crtc->base.base.id, crtc->base.name);
>   return -EINVAL;
>   }
>  
> @@ -7593,75 +7599,94 @@ static int intel_async_flip_check_hw(struct 
> intel_atomic_state *state, struct in
>   break;
>   default:
>   drm_dbg_kms(&i915->drm,
> - "Linear memory/CCS does not support async 
> flips\n");
> + "[PLANE:%d:%s] Modifier does not support 
> async flips\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>   }
>  
>   if (new_plane_state->hw.fb->format->num_planes > 1) {
>   drm_dbg_kms(&i915->drm,
> - "Planar formats not supported with async 
> flips\n");
> + "[PLANE:%d:%s] Planar formats do not 
> support async flips\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>   }
>  
>   if (old_plane_state->view.color_plane[0].mapping_stride !=
>   new_plane_state->view.color_plane[0].mapping_stride) {
> - drm_dbg_kms(&i915->drm, "Stride cannot be changed in 
> async flip\n");
> + drm_dbg_kms(&i915->drm,
> + "[PLANE:%d:%s] Stride cannot be changed in 
> async flip\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>   }
>  
>   if (old_plane_state->hw.fb->modifier !=
>   new_plane_state->hw.fb->modifier) {
>   drm_dbg_kms(&i915->drm,
> - "Framebuffer modifiers cannot be changed in 
> async flip\n");
> + "[PLANE:%d:%s] Modifier cannot be changed 
> in async flip\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>   }
>  
>   if (old_plane_state->hw.fb->format !=
>   new_plane_state->hw.fb->format) {
>   drm_dbg_kms(&i915->drm,
> - "Framebuffer format cannot be changed in 
> async flip\n");
> + "[PLANE:%d:%s] Pixel format cannot be 
> changed in async flip\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>   }
>  
>   if (old_plane_state->hw.rotation !=
>   new_plane_state->hw.rotation) {
> - drm_dbg_kms(&i915->drm, "Rotation cannot be changed in 
> async flip\n");
> + drm_dbg_kms(&i915->drm,
> + "[PLANE:%d:%s] Rotation cannot be changed 
> in async flip\n",
> + plane->base.base.id, plane->base.name);
>   return -EINVAL;
>

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Fix the async flip wm0/ddb optimization

2022-03-03 Thread Lisovskiy, Stanislav

On Mon, Feb 14, 2022 at 12:55:31PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The current implementation of the async flip wm0/ddb optimization
> does not work at all. The biggest problem is that we skip the
> whole intel_pipe_update_{start,end}() dance and thus never actually
> complete the commit that is trying to do the wm/ddb change.
> 
> To fix this we need to move the do_async_flip flag to the crtc
> state since we handle commits per-pipe, not per-plane.
> 
> Also since all planes can now be included in the first/last
> "async flip" (which gets converted to a sync flip to do the
> wm/ddb mangling) we need to be more careful when checking if
> the plane state is async flip comptatible. Only planes doing
> the async flip should be checked and other planes are perfectly
> fine not adhereing to any async flip related limitations.
> 
> However for subsequent commits which are actually going do the
> async flip in hardware we want to make sure no other planes
> are in the state. That should never happen assuming we did our
> job correctly, so we'll toss in a WARN to make sure we catch
> any bugs here.

Reviewed-by: Stanislav Lisovskiy 

> 
> Cc: Stanislav Lisovskiy 
> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |  1 +
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  5 +--
>  drivers/gpu/drm/i915/display/intel_crtc.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 40 +++
>  .../drm/i915/display/intel_display_types.h|  6 +--
>  5 files changed, 31 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index e0667d163266..40da7910f845 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -262,6 +262,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->preload_luts = false;
>   crtc_state->inherited = false;
>   crtc_state->wm.need_postvbl_update = false;
> + crtc_state->do_async_flip = false;
>   crtc_state->fb_bits = 0;
>   crtc_state->update_planes = 0;
>   crtc_state->dsb = NULL;
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index bec02333bdeb..df92cb9c7ff6 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -109,7 +109,6 @@ intel_plane_duplicate_state(struct drm_plane *plane)
>   intel_state->ggtt_vma = NULL;
>   intel_state->dpt_vma = NULL;
>   intel_state->flags = 0;
> - intel_state->do_async_flip = false;
>  
>   /* add reference to fb */
>   if (intel_state->hw.fb)
> @@ -492,7 +491,7 @@ void intel_plane_update_arm(struct intel_plane *plane,
>  
>   trace_intel_plane_update_arm(&plane->base, crtc);
>  
> - if (plane_state->do_async_flip)
> + if (crtc_state->do_async_flip && plane->async_flip)
>   plane->async_flip(plane, crtc_state, plane_state, true);
>   else
>   plane->update_arm(plane, crtc_state, plane_state);
> @@ -517,7 +516,7 @@ void intel_update_planes_on_crtc(struct 
> intel_atomic_state *state,
>   struct intel_plane *plane;
>   int i;
>  
> - if (new_crtc_state->uapi.async_flip)
> + if (new_crtc_state->do_async_flip)
>   return;
>  
>   /*
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 08ee3e17ee5c..65827481c1b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -485,7 +485,7 @@ void intel_pipe_update_start(struct intel_crtc_state 
> *new_crtc_state)
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
>   DEFINE_WAIT(wait);
>  
> - if (new_crtc_state->uapi.async_flip)
> + if (new_crtc_state->do_async_flip)
>   return;
>  
>   if (intel_crtc_needs_vblank_work(new_crtc_state))
> @@ -630,7 +630,7 @@ void intel_pipe_update_end(struct intel_crtc_state 
> *new_crtc_state)
>   ktime_t end_vbl_time = ktime_get();
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  
> - if (new_crtc_state->uapi.async_flip)
> + if (new_crtc_state->do_async_flip)
>   return;
>  
>   trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5a8c7816d29e..93db8ffa54f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1231,10 +1231,8 @@ static void intel_crtc_enable_flip_done(struct 
> intel_atomic_state *state,
>   int i;
>  
>   for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
> -

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Check async flip capability early on

2022-03-03 Thread Lisovskiy, Stanislav

On Mon, Feb 14, 2022 at 12:55:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Since the async flip state check is done very late and
> thus it can see potentially all the planes in the state
> (due to the wm/ddb optimization) we need to move the
> "can the requested plane do async flips at all?" check
> much earlier. For this purpose we introduce
> intel_async_flip_check_uapi() that gets called early during
> the atomic check.
> 
> And for good measure we'll throw in a couple of basic checks:
> - is the crtc active?
> - was a modeset flagged?
> - is+was the plane enabled?
> Though atm all of those should be guaranteed by the fact
> that the async flip can only be requested through the legacy
> page flip ioctl.
> 

Reviewed-by: Stanislav Lisovskiy 

> Cc: Stanislav Lisovskiy 
> Fixes: c3639f3be480 ("drm/i915: Use wm0 only during async flips for DG2")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 79 ++--
>  1 file changed, 72 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index baa291e4943f..5a8c7816d29e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7463,7 +7463,7 @@ static void kill_bigjoiner_slave(struct 
> intel_atomic_state *state,
>   * Correspondingly, support is currently added for primary plane only.
>   *
>   * Async flip can only change the plane surface address, so anything else
> - * changing is rejected from the intel_atomic_check_async() function.
> + * changing is rejected from the intel_async_flip_check_hw() function.
>   * Once this check is cleared, flip done interrupt is enabled using
>   * the intel_crtc_enable_flip_done() function.
>   *
> @@ -7473,7 +7473,65 @@ static void kill_bigjoiner_slave(struct 
> intel_atomic_state *state,
>   * correspond to the last vblank and have no relation to the actual time when
>   * the flip done event was sent.
>   */
> -static int intel_atomic_check_async(struct intel_atomic_state *state, struct 
> intel_crtc *crtc)
> +static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct intel_plane_state *old_plane_state;
> + struct intel_plane_state *new_plane_state;
> + struct intel_plane *plane;
> + int i;
> +
> + if (!new_crtc_state->uapi.async_flip)
> + return 0;
> +
> + if (!new_crtc_state->uapi.active) {
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] not active\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> +
> + if (intel_crtc_needs_modeset(new_crtc_state)) {
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] modeset required\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
> +  new_plane_state, i) {
> + if (plane->pipe != crtc->pipe)
> + continue;
> +
> + /*
> +  * TODO: Async flip is only supported through the page flip 
> IOCTL
> +  * as of now. So support currently added for primary plane only.
> +  * Support for other planes on platforms on which supports
> +  * this(vlv/chv and icl+) should be added when async flip is
> +  * enabled in the atomic IOCTL path.
> +  */
> + if (!plane->async_flip) {
> + drm_dbg_kms(&i915->drm,
> + "[PLANE:%d:%s] async flip not supported\n",
> + plane->base.base.id, plane->base.name);
> + return -EINVAL;
> + }
> +
> + if (!old_plane_state->uapi.fb || !new_plane_state->uapi.fb) {
> + drm_dbg_kms(&i915->drm,
> + "[PLANE:%d:%s] no old or new framebuffer\n",
> + plane->base.base.id, plane->base.name);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int intel_async_flip_check_hw(struct intel_atomic_state *state, 
> struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
>   const struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> @@ -7484,6 +7542,9 @@ static int intel_atomic_check_async(struct 
> intel_atomic_state *state, struct int
>   old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
>   new

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Don't skip ddb allocation if data_rate==0

2022-03-03 Thread Lisovskiy, Stanislav

On Mon, Feb 14, 2022 at 12:55:29PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> data_rate==0 no longer means a plane is disabled, it could
> also mean we want to use the minimum ddb allocation for it.
> Hence we can't bail out early during ddb allocation or
> else we'll simply forget to allocate any ddb for such planes.

Reviewed-by: Stanislav Lisovskiy 

> 
> Cc: Stanislav Lisovskiy 
> Fixes: 6a4d8cc6bbbf ("drm/i915: Don't allocate extra ddb during async flip 
> for DG2")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1179bf31f743..ec2de4f13b5e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5114,12 +5114,15 @@ skl_allocate_plane_ddb(struct skl_plane_ddb_iter 
> *iter,
>  const struct skl_wm_level *wm,
>  u64 data_rate)
>  {
> - u16 extra;
> + u16 extra = 0;
>  
> - extra = min_t(u16, iter->size,
> -   DIV64_U64_ROUND_UP(iter->size * data_rate, 
> iter->data_rate));
> - iter->size -= extra;
> - iter->data_rate -= data_rate;
> + if (data_rate) {
> + extra = min_t(u16, iter->size,
> +   DIV64_U64_ROUND_UP(iter->size * data_rate,
> +  iter->data_rate));
> + iter->size -= extra;
> + iter->data_rate -= data_rate;
> + }
>  
>   return wm->min_ddb_alloc + extra;
>  }
> @@ -5162,9 +5165,6 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
> *state,
>   skl_ddb_entry_init(&crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR],
>  alloc->end - iter.total[PLANE_CURSOR], alloc->end);
>  
> - if (iter.data_rate == 0)
> - return 0;
> -
>   /*
>* Find the highest watermark level for which we can satisfy the block
>* requirement of active planes.
> @@ -5203,6 +5203,10 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
> *state,
>   return -EINVAL;
>   }
>  
> + /* avoid the WARN later when we don't allocate any extra DDB */
> + if (iter.data_rate == 0)
> + iter.size = 0;
> +
>   /*
>* Grant each plane the blocks it requires at the highest achievable
>* watermark level, plus an extra share of the leftover blocks
> @@ -5215,20 +5219,10 @@ skl_crtc_allocate_plane_ddb(struct intel_atomic_state 
> *state,
>   if (plane_id == PLANE_CURSOR)
>   continue;
>  
> - /*
> -  * We've accounted for all active planes; remaining planes are
> -  * all disabled.
> -  */
> - if (iter.data_rate == 0)
> - break;
> -
>   iter.total[plane_id] =
>   skl_allocate_plane_ddb(&iter, &wm->wm[level],
>  
> crtc_state->plane_data_rate[plane_id]);
>  
> - if (iter.data_rate == 0)
> - break;
> -
>   iter.uv_total[plane_id] =
>   skl_allocate_plane_ddb(&iter, &wm->uv_wm[level],
>  
> crtc_state->uv_plane_data_rate[plane_id]);
> -- 
> 2.34.1
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl-n: Add stepping info

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915/adl-n: Add stepping info
URL   : https://patchwork.freedesktop.org/series/100995/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11318 -> Patchwork_22472


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (1): fi-pnv-d510 
  Missing(3): fi-bsw-cyan fi-icl-u2 bat-adls-5 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@workarounds:
- {bat-rpls-2}:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-rpls-2/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-rpls-2/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   NOTRUN -> [INCOMPLETE][3] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +57 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#3576]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-adlp-4/igt@i915_pm_...@module-reload.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][8] ([i915#4391]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@workarounds:
- bat-adlp-4: [DMESG-FAIL][10] ([i915#5020]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-adlp-4/igt@i915_selftest@l...@workarounds.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-adlp-4/igt@i915_selftest@l...@workarounds.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][12] ([i915#3576]) -> [PASS][13] +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-adlp-6/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html

  
 Warnings 

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][16] ([i915#4312]) -> [FAIL][17] ([i915#2722] / 
[i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11318/fi-skl-6600u/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22472/fi-skl-6600u/igt@run...@aborted.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#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#5020]: https://gitlab.freedesktop.org/drm/intel/issues/5020
  [i915#5195]: https://gitlab.freedesktop.org/drm/intel/issues/5195


Build changes
-

  * Linux: CI_DRM_11318 -> Patchwork_22472

  CI-20190529: 20190529
  CI_DRM_11318: 58c6bdbe67ccf9c8427ae98b1a05486fe6263fc7 @ 
git://anongit.freedesk

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev5)

2022-03-03 Thread Souza, Jose

On Sun, 2022-02-27 at 05:27 +, Patchwork wrote:
Patch Details
Series: drm/i915/psr: Set "SF Partial Frame Enable" also on full update (rev5)
URL:https://patchwork.freedesktop.org/series/100633/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22427/index.html
CI Bug Log - changes from CI_DRM_11291_full -> Patchwork_22427_full
Summary

SUCCESS

No regressions found.

Participating hosts (11 -> 11)

No changes in participating hosts

Pushed to drm-intel-next, thanks for the patch.

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-apl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 ([i915#4386])

Possible fixes

  *   boot

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add more TMDS clock rate supported by HDMI driver (rev2)

2022-03-03 Thread Patchwork

== Series Details ==

Series: drm/i915: add more TMDS clock rate supported by HDMI driver (rev2)
URL   : https://patchwork.freedesktop.org/series/100866/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11317_full -> Patchwork_22469_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * 
{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-5@pipe-a-edp-1-downscale-with-pixel-format}:
- {shard-rkl}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-rkl-6/igt@kms_plane_scaling@downscale-with-pixel-format-factor-...@pipe-a-edp-1-downscale-with-pixel-format.html

  
New tests
-

  New tests have been introduced between CI_DRM_11317_full and 
Patchwork_22469_full:

### New IGT tests (1) ###

  * 
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
- Statuses : 1 pass(s)
- Exec time: [1.28] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][2], [PASS][3], [PASS][4], [PASS][5], 
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [FAIL][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48]) 
([i915#4392])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk2/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk2/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk3/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk3/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk4/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk4/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22469/shard-glk4/boot.html

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Use I915_BO_ALLOC_CONTIGUOUS flag for DPT

2022-03-03 Thread Matthew Auld

On Thu, 9 Dec 2021 at 17:00, Stanislav Lisovskiy
 wrote:
>
> Do mapping using CONTIGUOUS flag - otherwise
> i915_gem_object_is_contiguous warn is triggered.
>
> Signed-off-by: Stanislav Lisovskiy 

As a temporary fix,
Reviewed-by: Matthew Auld 

> ---
>  drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 963ca7155b06..f66346dcf2d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -244,7 +244,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);
>
> if (HAS_LMEM(i915))
> -   dpt_obj = i915_gem_object_create_lmem(i915, size, 0);
> +   dpt_obj = i915_gem_object_create_lmem(i915, size, 
> I915_BO_ALLOC_CONTIGUOUS);
> else
> dpt_obj = i915_gem_object_create_stolen(i915, size);
> if (IS_ERR(dpt_obj))
> --
> 2.24.1.485.gad05a3d8e5
>

Re: [Intel-gfx] [Kgdb-bugreport] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-03-03 Thread Daniel Thompson

On Thu, Mar 03, 2022 at 03:26:57PM +0800, Xiaomeng Tong wrote:
> On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will be the HEAD's container_of pointer which pointers
> > > to a type-confused struct. Sidenote: The *mis-use* here refers to
> > > mistakely access to other members of the struct, instead of the
> > > list_head member which acutally is the valid HEAD.
> >
> > The problem is that the HEAD's container_of pointer should never
> > be calculated at all.
> > This is what is fundamentally broken about the current definition.
> 
> Yes, the rule is "the HEAD's container_of pointer should never be
> calculated at all outside the loop", but how do you make sure everyone
> follows this rule?

Your formulation of the rule is correct: never run container_of() on HEAD
pointer.

However the rule that is introduced by list_for_each_entry_inside() is
*not* this rule. The rule it introduces is: never access the iterator
variable outside the loop.

Making the iterator NULL on loop exit does follow the rule you proposed
but using a different technique: do not allow HEAD to be stored in the
iterator variable after loop exit. This also makes it impossible to run
container_of() on the HEAD pointer.

> Everyone makes mistakes, but we can eliminate them all from the beginning
> with the help of compiler which can catch such use-after-loop things.

Indeed but if we introduce new interfaces then we don't have to worry
about existing usages and silent regressions. Code will have been
written knowing the loop can exit with the iterator set to NULL.

Sure it is still possible for programmers to make mistakes and
dereference the NULL pointer but C programmers are well training w.r.t.
NULL pointer checking so such mistakes are much less likely than with
the current list_for_each_entry() macro. This risk must be offset
against the way a NULLify approach can lead to more elegant code when we
are doing a list search.

Daniel.

[Intel-gfx] ✓ Fi.CI.BAT: success for Remove usage of list iterator past the loop body (rev5)

2022-03-03 Thread Patchwork

== Series Details ==

Series: Remove usage of list iterator past the loop body (rev5)
URL   : https://patchwork.freedesktop.org/series/100822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11317 -> Patchwork_22471


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 42)
--

  Additional (2): fi-kbl-soraka fi-bdw-5557u 
  Missing(6): shard-tglu fi-bsw-cyan bat-adlp-4 shard-rkl shard-dg1 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-multi-fence:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-bsw-nick/igt@amdgpu/amd_ba...@cs-multi-fence.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#2291])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][6] ([i915#3921])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][12] ([fdo#109271]) +13 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@i915_selftest@live@coherency:
- {bat-rpls-2}:   [DMESG-WARN][13] ([i915#4391]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/bat-rpls-2/igt@i915_selftest@l...@coherency.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/bat-rpls-2/igt@i915_selftest@l...@coherency.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][15] ([i915#2940]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][17] ([i915#3576]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/bat-adlp-6/igt@kms_busy@ba...@flip.html

  
 Warnings 

  * igt@amdgpu/amd_basic@memory-alloc:
- fi-kbl-8809g:   [SKIP][19] ([fdo#109271]) -> [FAIL][20] ([i915#5102])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11317/fi-kbl-8809g/igt@amdgpu/amd_ba...@memory-alloc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22471/fi-kbl-8809g/igt@amdgpu/amd_ba...@memory-alloc.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the

[Intel-gfx] [PATCH] drm/i915/adl-n: Add stepping info

2022-03-03 Thread Tejas Upadhyay

Add ADL-N stepping-substepping info in
accordance to BSpec.

Bspec: 68397

Cc: Matt Roper 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/intel_step.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index 4fd69ecd1481..74e8e4680028 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -131,6 +131,10 @@ static const struct intel_step_info adls_rpls_revids[] = {
[0xC] = { COMMON_GT_MEDIA_STEP(D0), .display_step = STEP_C0 },
 };
 
+static const struct intel_step_info adlp_n_revids[] = {
+   [0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
+};
+
 void intel_step_init(struct drm_i915_private *i915)
 {
const struct intel_step_info *revids = NULL;
@@ -150,6 +154,9 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_XEHPSDV(i915)) {
revids = xehpsdv_revids;
size = ARRAY_SIZE(xehpsdv_revids);
+   } else if (IS_ADLP_N(i915)) {
+   revids = adlp_n_revids;
+   size = ARRAY_SIZE(adlp_n_revids);
} else if (IS_ALDERLAKE_P(i915)) {
revids = adlp_revids;
size = ARRAY_SIZE(adlp_revids);
-- 
2.34.1

1 2 >

1 - 100 of 129 matches

Mail list logo