Re: [Intel-gfx] [PATCH v3] drm/i915: Refactor PAT/object cache handling

2023-07-20 Thread Yang, Fei
>>> [snip]
> @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
> drm_i915_gem_object *obj)

 The code change here looks accurate, but while we're here, I have a
 side question about this function in general...it was originally
 introduced in commit 48004881f693 ("drm/i915: Mark CPU cache as
 dirty when used for
 rendering") which states that GPU rendering ends up in the CPU cache
 (and thus needs a clflush later to make sure it lands in memory).
 That makes sense to me for LLC platforms, but is it really true for
 non-LLC snooping platforms (like MTL) as the commit states?
>>>
>>> For non-LLC platforms objects can be set to 1-way coherent which
>>> means GPU rendering ending up in CPU cache as well, so for non-LLC
>>> platform the logic here should be checking 1-way coherent flag.
>>
>> That's the part that I'm questioning (and not just for MTL, but for
>> all of our other non-LLC platforms too).  Just because there's
>> coherency doesn't mean that device writes landed in the CPU cache.
>> Coherency is also achieved if device writes invalidate the contents of the 
>> CPU cache.
>> I thought our non-LLC snooping platforms were coherent due to
>> write-invalidate rather than write-update, but I can't find it
>> specifically documented anywhere at the moment.  If write-invalidate
>> was used, then there shouldn't be a need for a later clflush either.
>
> [Trying to consolidate by doing a combined reply to the discussion so far.]
>
> On the write-invalidate vs write-update I don't know. If you did not
> find it in bspec then I doubt I would. I can have a browse still.

Matt was correct. Quote Ron Silvas from SW ARCH, "MTL GPU doesn't write to
CPU cache, it simply snoop CPU cache on its way to RAM."

 My understanding
 was that snooping platforms just invalidated the CPU cache to
 prevent future CPU reads from seeing stale data but didn't actually
 stick any new data in there?  Am I off track or is the original
 logic of this function not quite right?

 Anyway, even if the logic of this function is wrong, it's a mistake
 that would only hurt performance
>>>
>>> Yes, this logic will introduce performance impact because it's
>>> missing the checking for obj->pat_set_by_user. For objects with
>>> pat_set_by_user==true, even if the object is snooping or 1-way
>>> coherent, we don't want to enforce a clflush here since the
>>> coherency is supposed to be handled by user space.
>
> What should I add you think to fix it?

I think the simplest would be

if (obj->pat_set_by_user)
return false;

because even checking for incoherent WB is unnecessary, simply no
need for the KMD to initiate a flush if PAT is set by user.

> Add a check for non-coherent WB in gpu_write_needs_clflush as an additional 
> condition for returning false?
>
> And then if Matt is correct write-invalidate is used also !HAS_LLC should 
> just return false?
>
 (flushing more often than we truly need to) rather than
 functionality, so not something we really need to dig into right now
 as part of this patch.

>   if (IS_DGFX(i915))
>   return false;
>
> -/*
> - * For objects created by userspace through GEM_CREATE with pat_index
> - * set by set_pat extension, i915_gem_object_has_cache_level() will
> - * always return true, because the coherency of such object is 
> managed
> - * by userspace. Othereise the call here would fall back to checking
> - * whether the object is un-cached or write-through.
> - */
> -return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
> - i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
> +return i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_UC) != 1 
> &&
> +   i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WT) != 1;
>   }
>>>
>>> [snip]
> @@ -640,15 +640,9 @@ static inline int use_cpu_reloc(const struct 
> reloc_cache *cache,
>   if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
>   return false;
>
> -/*
> - * For objects created by userspace through GEM_CREATE with pat_index
> - * set by set_pat extension, i915_gem_object_has_cache_level() always
> - * return true, otherwise the call would fall back to checking 
> whether
> - * the object is un-cached.
> - */
>   return (cache->has_llc ||
>   obj->cache_dirty ||
> -!i915_gem_object_has_cache_level(obj, I915_CACHE_NONE));
> +i915_gem_object_has_cache_mode(obj,
> + I915_CACHE_MODE_UC) != 1);

 Platforms with relocations and platforms with user-specified PAT
 have no overlap, right?  So a -1 return should be impossible here
 and this is one case where we could just treat the return value as
 a boolean, right?
>>>
>
> Hm no, or 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: silence injected failure in the load via GSC path

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/huc: silence injected failure in the load via GSC path
URL   : https://patchwork.freedesktop.org/series/121080/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13401 -> Patchwork_121080v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(2): bat-rpls-2 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-dg1-7:  [PASS][1] -> [FAIL][2] ([i915#7691])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: NOTRUN -> [ABORT][5] ([i915#4983] / [i915#7461] / 
[i915#8347] / [i915#8384])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [ABORT][6] ([i915#8844])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#1845] / [i915#5354]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@cursor_plane_move:
- bat-rplp-1: NOTRUN -> [ABORT][8] ([i915#8434])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-rplp-1/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +37 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [FAIL][10] ([i915#7940]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-guc: [FAIL][12] ([i915#7940]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-skl-guc/igt@i915_pm_...@module-reload.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-skl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [TIMEOUT][14] ([i915#6794] / [i915#7392]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-rpls-1/igt@i915_selftest@l...@mman.html

  
 Warnings 

  * igt@core_auth@basic-auth:
- bat-adlp-11:[ABORT][16] ([i915#4423] / [i915#8011]) -> 
[ABORT][17] ([i915#8011])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-adlp-11/igt@core_a...@basic-auth.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8700k:   [FAIL][18] ([i915#7691]) -> [FAIL][19] ([i915#7940])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [DMESG-WARN][20] ([i915#8937]) -> [ABORT][21] 
([i915#7982])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121080v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-mtlp-6: [DMESG-WARN][22] ([i915#6367] / [i915#8937]) -> 
[DMESG-WARN][23] ([i915#8937])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
   [23]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/huc: silence injected failure in the load via GSC path

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/huc: silence injected failure in the load via GSC path
URL   : https://patchwork.freedesktop.org/series/121080/
State : warning

== Summary ==

Error: dim checkpatch failed
3d5d75464e51 drm/i915/huc: silence injected failure in the load via GSC path
-:32: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#32: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c:178:
+   gt_probe_error(pxp->ctrl_gt, "failed to load 
huc via gsc %d\n", ret);

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




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests (rev7)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests 
(rev7)
URL   : https://patchwork.freedesktop.org/series/117713/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13401 -> Patchwork_117713v7


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 43)
--

  Additional (1): fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@vgem_basic@dmabuf-fence-before:
- fi-kbl-soraka:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-soraka/igt@vgem_ba...@dmabuf-fence-before.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/fi-kbl-soraka/igt@vgem_ba...@dmabuf-fence-before.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-mtlp-6: [PASS][3] -> [DMESG-WARN][4] ([i915#8937])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-mtlp-6/igt@core_a...@basic-auth.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-mtlp-6/igt@core_a...@basic-auth.html

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-7567u:   [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][7] -> [FAIL][8] ([i915#7940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/fi-rkl-11600/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][9] ([i915#6367])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: NOTRUN -> [DMESG-WARN][10] ([i915#6367])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [ABORT][11] ([i915#8844])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#7828])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#1845])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@cursor_plane_move:
- bat-rplp-1: NOTRUN -> [SKIP][14] ([i915#1072]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rplp-1/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][15] ([i915#8434] / [i915#8442] / 
[i915#8668])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][16] ([fdo#109271]) +37 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [DMESG-WARN][17] ([i915#8937]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v7/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][19] ([i915#5334] / [i915#7872]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [20]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix connector HPD polling

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix connector HPD polling
URL   : https://patchwork.freedesktop.org/series/121050/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_121050v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  Additional (1): shard-tglu0 
  Missing(1): pig-kbl-iris 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@syncobj_wait@invalid-multi-wait-unsubmitted-signaled:
- shard-glk:  [PASS][1] -> [TIMEOUT][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-glk2/igt@syncobj_w...@invalid-multi-wait-unsubmitted-signaled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-glk9/igt@syncobj_w...@invalid-multi-wait-unsubmitted-signaled.html

  
 Warnings 

  * igt@i915_selftest@live@gt_tlb:
- shard-mtlp: [DMESG-WARN][3] ([i915#8937]) -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-mtlp-7/igt@i915_selftest@live@gt_tlb.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-mtlp-1/igt@i915_selftest@live@gt_tlb.html

  * igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-glk:  [SKIP][5] ([fdo#109271] / [i915#3886]) -> [TIMEOUT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-glk2/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-glk9/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs.html

  
New tests
-

  New tests have been introduced between CI_DRM_13399_full and 
Patchwork_121050v1_full:

### New IGT tests (4) ###

  * igt@kms_flip@wf_vblank-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html

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

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

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-rkl-7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-mtlp: [PASS][13] -> [FAIL][14] ([i915#8691])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-mtlp-4/igt@i915_pipe_str...@stress-xrgb-untiled.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-mtlp-7/igt@i915_pipe_str...@stress-xrgb-untiled.html

  * igt@i915_pm_rpm@dpms-lpsp:
- shard-rkl:  [PASS][15] -> [SKIP][16] ([i915#1397]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-7/igt@i915_pm_...@dpms-lpsp.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/shard-rkl-2/igt@i915_pm_...@dpms-lpsp.html

  * igt@i915_pm_rpm@dpms-non-lpsp:
- shard-dg2:  [PASS][17] -> [SKIP][18] ([i915#1397])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-2/igt@i915_pm_...@dpms-non-lpsp.html
   [18]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests (rev6)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests 
(rev6)
URL   : https://patchwork.freedesktop.org/series/117713/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13401 -> Patchwork_117713v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-glk-j4005 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@load:
- fi-kbl-soraka:  [PASS][1] -> [INCOMPLETE][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-soraka/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-kbl-soraka/igt@i915_module_l...@load.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-1115g4:  [PASS][3] -> [FAIL][4] ([i915#7940]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-7567u:   [PASS][5] -> [FAIL][6] ([i915#7691])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-7567u/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-kbl-7567u/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][7] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [ABORT][8] ([i915#8844])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_psr@cursor_plane_move:
- bat-rplp-1: NOTRUN -> [SKIP][9] ([i915#1072]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/bat-rplp-1/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][10] ([i915#8434] / [i915#8442] / 
[i915#8668])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][11] ([fdo#109271]) +37 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-guc: [FAIL][12] ([i915#7940]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [FAIL][14] ([i915#7940]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [DMESG-FAIL][16] ([i915#5334] / [i915#7872]) -> 
[PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [TIMEOUT][18] ([i915#6794] / [i915#7392]) -> 
[PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-1: [WARN][20] ([i915#8747]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117713v6/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html

  
 Warnings 

  * igt@i915_module_load@load:
- bat-adlp-11:[DMESG-WARN][22] ([i915#4423]) -> [ABORT][23] 
([i915#4423])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13401/bat-adlp-11/igt@i915_module_l...@load.html
   [23]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hotplug: Reduce SHPD_FILTER to 250us (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/hotplug: Reduce SHPD_FILTER to 250us (rev3)
URL   : https://patchwork.freedesktop.org/series/120722/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_120722v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13399_full and 
Patchwork_120722v3_full:

### New IGT tests (4) ###

  * igt@kms_flip@wf_vblank-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-snb4/igt@gem_ctx_persiste...@legacy-engines-queued.html

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

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-rkl:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-rkl-6/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-glk9/igt@gem_exec_fair@basic-p...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-glk8/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-mtlp: [PASS][7] -> [FAIL][8] ([i915#8691])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-mtlp-4/igt@i915_pipe_str...@stress-xrgb-untiled.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-mtlp-3/igt@i915_pipe_str...@stress-xrgb-untiled.html

  * igt@i915_pm_rpm@gem-execbuf-stress@smem0:
- shard-tglu: [PASS][9] -> [FAIL][10] ([i915#7940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-9/igt@i915_pm_rpm@gem-execbuf-str...@smem0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-tglu-2/igt@i915_pm_rpm@gem-execbuf-str...@smem0.html

  * igt@i915_pm_rpm@i2c:
- shard-dg2:  [PASS][11] -> [FAIL][12] ([i915#8717])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-1/igt@i915_pm_...@i2c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-dg2-2/igt@i915_pm_...@i2c.html

  * igt@i915_pm_rpm@modeset-non-lpsp:
- shard-dg2:  [PASS][13] -> [SKIP][14] ([i915#1397]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-6/igt@i915_pm_...@modeset-non-lpsp.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-dg2-10/igt@i915_pm_...@modeset-non-lpsp.html

  * igt@i915_pm_rps@reset:
- shard-snb:  [PASS][15] -> [INCOMPLETE][16] ([i915#7790])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-snb4/igt@i915_pm_...@reset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-snb1/igt@i915_pm_...@reset.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-mtlp: [PASS][17] -> [FAIL][18] ([i915#5138])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-mtlp-8/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-mtlp-7/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html

  * igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/shard-apl4/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-snb:  NOTRUN -> [SKIP][20] ([fdo#109271]) +194 similar 
issues
   [20]: 

[Intel-gfx] [PATCH] drm/i915/huc: silence injected failure in the load via GSC path

2023-07-20 Thread Daniele Ceraolo Spurio
If we can't load the HuC due to an injected failure, we don't want
to throw and error and trip CI. Using the gt_probe_error macro for
logging ensure that the error is only printed if it wasn't explicitly
injected.

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7061
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 1ce07d7e8769..88215b5efe72 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -9,6 +9,7 @@
 #include 
 
 #include "gem/i915_gem_lmem.h"
+#include "gt/intel_gt_print.h"
 
 #include "i915_drv.h"
 
@@ -174,7 +175,7 @@ static int i915_pxp_tee_component_bind(struct device 
*i915_kdev,
/* load huc via pxp */
ret = intel_huc_fw_load_and_auth_via_gsc(>huc);
if (ret < 0)
-   drm_err(>drm, "failed to load huc via gsc 
%d\n", ret);
+   gt_probe_error(pxp->ctrl_gt, "failed to load 
huc via gsc %d\n", ret);
}
}
 
-- 
2.41.0



[Intel-gfx] [PATCH v7] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

2023-07-20 Thread Alan Previn
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. Selftests shouldn't
care if the proxy-init failed as that should be flagged elsewhere.

Difference from prior versions:
   v7: - Change the fw status to INTEL_UC_FIRMWARE_LOAD_FAIL if the
 proxy-init fails so that intel_gsc_uc_fw_proxy_get_status
 catches it. (Daniele)
   v6: - Add a helper that returns something more than a boolean
 so we selftest can stop waiting if proxy-init hadn't
 completed but failed (Daniele).
   v5: - Move the call to __wait_gsc_proxy_completed from common
 __run_selftests dispatcher to the group-level selftest
 function (Trvtko).
   - change the pr_info to pr_warn if we hit the timeout.
   v4: - Remove generalized waiters function table framework (Tvrtko).
   - Remove mention of CI-framework-timeout from comments (Tvrtko).
   v3: - Rebase to latest drm-tip.
   v2: - Based on internal testing, increase the timeout for gsc-proxy
 specific case to 8 seconds.

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 14 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 13 +++-
 .../gpu/drm/i915/selftests/i915_selftest.c| 31 +++
 4 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index ab1a456f833d..163021705210 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -45,6 +45,20 @@ bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc 
*gsc, bool needs_wakere
   HECI1_FWSTS1_PROXY_STATE_NORMAL;
 }
 
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc)
+{
+   if (!(IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY)))
+   return -ENODEV;
+   if (!intel_uc_fw_is_loadable(>fw))
+   return -ENODEV;
+   if (__intel_uc_fw_status(>fw) == INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return -ENOLINK;
+   if (!intel_gsc_uc_fw_proxy_init_done(gsc, true))
+   return -EAGAIN;
+
+   return 0;
+}
+
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
 {
return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore, false) &
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index ad2167ce9137..bc9dd0de8aaf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -16,5 +16,6 @@ int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, 
const void *data, s
 int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool 
needs_wakeref);
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 034b53a71541..0d3b22a74365 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -62,8 +62,18 @@ static void gsc_work(struct work_struct *work)
}
 
ret = intel_gsc_proxy_request_handler(gsc);
-   if (ret)
+   if (ret) {
+   if (actions & GSC_ACTION_FW_LOAD) {
+   /*
+* A proxy failure right after firmware load 
means the proxy-init
+* step has failed so mark GSC as not usable 
after this
+*/
+   drm_err(>i915->drm,
+   "GSC proxy handler failed to init\n");
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
+   }
goto out_put;
+   }
 
/* mark the GSC FW init as done the first time we run this */
if (actions & GSC_ACTION_FW_LOAD) {
@@ -78,6 +88,7 @@ static void gsc_work(struct work_struct *work)
} else {
drm_err(>i915->drm,
"GSC status reports proxy init not 
complete\n");
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
   

Re: [Intel-gfx] [PATCH v6] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

2023-07-20 Thread Teres Alexis, Alan Previn
On Thu, 2023-07-20 at 14:52 -0700, Ceraolo Spurio, Daniele wrote:
> 
> On 7/20/2023 2:40 PM, Alan Previn wrote:
> > On MTL, if the GSC Proxy init flows haven't completed, submissions to the
> > GSC engine will fail. Those init flows are dependent on the mei's
> > gsc_proxy component that is loaded in parallel with i915 and a
> > worker that could potentially start after i915 driver init is done.
> > 
> > That said, all subsytems that access the GSC engine today does check
> > for such init flow completion before using the GSC engine. However,
> > selftests currently don't wait on anything before starting.
> > 
> > To fix this, add a waiter function at the start of __run_selftests
> > that waits for gsc-proxy init flows to complete. Selftests shouldn't
> > care if the proxy-init failed as that should be flagged elsewhere.
> > 
> > Difference from prior versions:
> > v6: - Add a helper that returns something more than a boolean
> >   so we selftest can stop waiting if proxy-init hadn't
> >   completed but failed (Daniele).

alan:snip
> 

> > +int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc)
> > +{
> > +   if (!(IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY)))
> > +   return -ENODEV;
> > +   if (!intel_uc_fw_is_loadable(>fw))
> > +   return -ENODEV;
> > +   if (__intel_uc_fw_status(>fw) == INTEL_UC_FIRMWARE_LOAD_FAIL)
> 
> You're missing the change to move the FW status to LOAD_FAIL if the 
> proxy fails to initialize. Or are you expecting 
> https://patchwork.freedesktop.org/series/118723/, which included that 
> change, to be merged first?
> 
> Daniele

alan: as per our offline sync, I'll respin this one and move it away from the
other patch (since this is more critical) and we can respin the other after
this is done so we get a smooth merge. Also, as i move that "change fw status
to fail" from that PXP patch to this patch, I'll fix that issue where i missed
the 2nd failure point in the proxy init flow.

Thanks for your help. :)



Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS

2023-07-20 Thread Ceraolo Spurio, Daniele




On 6/29/2023 6:44 PM, Alan Previn wrote:

After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.

Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
  we catch it so that we can change the returned PXP_STATUS
  from "2" (i.e. 'PXP is supported but not yet ready')
  to "-ENODEV". This typically should not happen and if it
  does, we have a platform configuration issue.
- If a PXP arbitration session creation event failed
  due to incorrect firmware version or blocking SOC fusing
  or blocking BIOS configuration (platform reasons that won't
  change if we retry), then reflect that blockage by also
  returning -ENODEV in the GET_PARAM:PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
  supported but non-i915 dependencies (component-driver /
  firmware) we are still pending to complete the init flows.
  In this case, just return "2" immediately (i.e. 'PXP is
  supported but not yet ready').

Difference from prio revs:
   v2: - Use a #define for the default readiness timeout (Vivaik).
   - Improve comments around the failing of proxy-init.
   v1: - Change the commit msg style to be imperative. (Jani)
   - Rename timeout to timeout_ms. (Jani)
   - Fix is_fw_err_platform_config to use higher order
 param (pxp) first. (Jani)

Signed-off-by: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c  | 10 +-
  drivers/gpu/drm/i915/i915_getparam.c   |  2 +-
  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 40 ++
  drivers/gpu/drm/i915/pxp/intel_pxp.h   |  2 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c |  7 ++--
  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  7 ++--
  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  9 +
  7 files changed, 61 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 034b53a71541..21c2b7cce335 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -62,8 +62,16 @@ static void gsc_work(struct work_struct *work)
}
  
  		ret = intel_gsc_proxy_request_handler(gsc);

-   if (ret)
+   if (ret) {
+   if (actions & GSC_ACTION_FW_LOAD) {
+   /*
+* A failure right after firmware load means 
the proxy-init
+* step has failed so mark GSC as not usable 
after this
+*/
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);


Note that proxy init can also fail below if the init_done check returns 
false, so the status needs to be changed in both cases.


Daniele


+   }
goto out_put;
+   }
  
  		/* mark the GSC FW init as done the first time we run this */

if (actions & GSC_ACTION_FW_LOAD) {
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 890f2b382bee..5c3fec63cb4c 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -109,7 +109,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
-   value = intel_pxp_get_readiness_status(i915->pxp);
+   value = intel_pxp_get_readiness_status(i915->pxp, 0);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f34..e3b47525dc60 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,22 +359,46 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(>runtime_pm, wakeref);
  }
  
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)

+{
+   if (__intel_uc_fw_status(>ctrl_gt->uc.huc.fw) == 
INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return true;
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+   __intel_uc_fw_status(>ctrl_gt->uc.gsc.fw) == 
INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return true;
+
+   return false;
+}
+
+static bool pxp_fw_dependencies_completed(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return intel_pxp_gsccs_is_ready_for_sessions(pxp);
+
+   return pxp_component_bound(pxp);
+}
+
  /*
   * this helper is used by both intel_pxp_start and by
   * the GET_PARAM IOCTL that user space calls. Thus, the
   * return values here should match the UAPI spec.
   */
-int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int 

Re: [Intel-gfx] [PATCH v6] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

2023-07-20 Thread Ceraolo Spurio, Daniele




On 7/20/2023 2:40 PM, Alan Previn wrote:

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. Selftests shouldn't
care if the proxy-init failed as that should be flagged elsewhere.

Difference from prior versions:
v6: - Add a helper that returns something more than a boolean
  so we selftest can stop waiting if proxy-init hadn't
  completed but failed (Daniele).
v5: - Move the call to __wait_gsc_proxy_completed from common
  __run_selftests dispatcher to the group-level selftest
  function (Trvtko).
- change the pr_info to pr_warn if we hit the timeout.
v4: - Remove generalized waiters function table framework (Tvrtko).
- Remove mention of CI-framework-timeout from comments (Tvrtko).
v3: - Rebase to latest drm-tip.
v2: - Based on internal testing, increase the timeout for gsc-proxy
  specific case to 8 seconds.

Signed-off-by: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 14 +
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |  1 +
  .../gpu/drm/i915/selftests/i915_selftest.c| 31 +++
  3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index ab1a456f833d..163021705210 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -45,6 +45,20 @@ bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc 
*gsc, bool needs_wakere
   HECI1_FWSTS1_PROXY_STATE_NORMAL;
  }
  
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc)

+{
+   if (!(IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY)))
+   return -ENODEV;
+   if (!intel_uc_fw_is_loadable(>fw))
+   return -ENODEV;
+   if (__intel_uc_fw_status(>fw) == INTEL_UC_FIRMWARE_LOAD_FAIL)


You're missing the change to move the FW status to LOAD_FAIL if the 
proxy fails to initialize. Or are you expecting 
https://patchwork.freedesktop.org/series/118723/, which included that 
change, to be merged first?


Daniele


+   return -ENOLINK;
+   if (!intel_gsc_uc_fw_proxy_init_done(gsc, true))
+   return -EAGAIN;
+
+   return 0;
+}
+
  bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
  {
return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore, false) &
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index ad2167ce9137..bc9dd0de8aaf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -16,5 +16,6 @@ int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, 
const void *data, s
  int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
  bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
  bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool 
needs_wakeref);
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc);
  
  #endif

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..ee79e0809a6d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
  #include 
  
  #include "gt/intel_gt_pm.h"

+#include "gt/uc/intel_gsc_fw.h"
+
  #include "i915_driver.h"
  #include "i915_drv.h"
  #include "i915_selftest.h"
@@ -127,6 +129,31 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
  }
  
+static bool

+__gsc_proxy_init_progressing(struct intel_gsc_uc *gsc)
+{
+   return intel_gsc_uc_fw_proxy_get_status(gsc) == -EAGAIN;
+}
+
+static void
+__wait_gsc_proxy_completed(struct drm_i915_private *i915)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw));
+   /*
+* The gsc proxy component depends on the kernel component driver load 
ordering
+* and in corner cases (the first time after an IFWI flash), 
init-completion
+* firmware flows take longer.
+*/
+   unsigned long timeout_ms = 8000;
+
+   if (need_to_wait && 
wait_for(!__gsc_proxy_init_progressing(>media_gt->uc.gsc),
+timeout_ms))
+ 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Update AUX invalidation sequence (rev8)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev8)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13400 -> Patchwork_119798v8


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-rpls-1: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-rpls-1/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-rpls-1/igt@i915_module_l...@load.html
- bat-adlp-6: [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-adlp-6/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-adlp-6/igt@i915_module_l...@load.html
- bat-adls-5: [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-adls-5/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-adls-5/igt@i915_module_l...@load.html
- bat-dg1-5:  [PASS][7] -> [ABORT][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-dg1-5/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-dg1-5/igt@i915_module_l...@load.html
- bat-dg1-7:  [PASS][9] -> [ABORT][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-dg1-7/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-dg1-7/igt@i915_module_l...@load.html
- bat-adlp-9: [PASS][11] -> [ABORT][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-adlp-9/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-adlp-9/igt@i915_module_l...@load.html
- bat-dg2-11: [PASS][13] -> [ABORT][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-dg2-11/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-dg2-11/igt@i915_module_l...@load.html
- bat-adln-1: [PASS][15] -> [ABORT][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-adln-1/igt@i915_module_l...@load.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-adln-1/igt@i915_module_l...@load.html
- bat-adlm-1: [PASS][17] -> [ABORT][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-adlm-1/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-adlm-1/igt@i915_module_l...@load.html
- fi-tgl-1115g4:  [PASS][19] -> [ABORT][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/fi-tgl-1115g4/igt@i915_module_l...@load.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/fi-tgl-1115g4/igt@i915_module_l...@load.html
- bat-atsm-1: [PASS][21] -> [ABORT][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-atsm-1/igt@i915_module_l...@load.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-atsm-1/igt@i915_module_l...@load.html
- bat-dg2-9:  [PASS][23] -> [ABORT][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-dg2-9/igt@i915_module_l...@load.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-dg2-9/igt@i915_module_l...@load.html
- bat-rpls-2: [PASS][25] -> [ABORT][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-rpls-2/igt@i915_module_l...@load.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-rpls-2/igt@i915_module_l...@load.html
- bat-dg2-8:  [PASS][27] -> [ABORT][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13400/bat-dg2-8/igt@i915_module_l...@load.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v8/bat-dg2-8/igt@i915_module_l...@load.html

  
 Warnings 

  * igt@i915_module_load@load:
- bat-adlp-11:[DMESG-WARN][29] ([i915#4423]) -> [ABORT][30]
   [29]: 

[Intel-gfx] [PATCH v6] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

2023-07-20 Thread Alan Previn
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. Selftests shouldn't
care if the proxy-init failed as that should be flagged elsewhere.

Difference from prior versions:
   v6: - Add a helper that returns something more than a boolean
 so we selftest can stop waiting if proxy-init hadn't
 completed but failed (Daniele).
   v5: - Move the call to __wait_gsc_proxy_completed from common
 __run_selftests dispatcher to the group-level selftest
 function (Trvtko).
   - change the pr_info to pr_warn if we hit the timeout.
   v4: - Remove generalized waiters function table framework (Tvrtko).
   - Remove mention of CI-framework-timeout from comments (Tvrtko).
   v3: - Rebase to latest drm-tip.
   v2: - Based on internal testing, increase the timeout for gsc-proxy
 specific case to 8 seconds.

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 14 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |  1 +
 .../gpu/drm/i915/selftests/i915_selftest.c| 31 +++
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index ab1a456f833d..163021705210 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -45,6 +45,20 @@ bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc 
*gsc, bool needs_wakere
   HECI1_FWSTS1_PROXY_STATE_NORMAL;
 }
 
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc)
+{
+   if (!(IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY)))
+   return -ENODEV;
+   if (!intel_uc_fw_is_loadable(>fw))
+   return -ENODEV;
+   if (__intel_uc_fw_status(>fw) == INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return -ENOLINK;
+   if (!intel_gsc_uc_fw_proxy_init_done(gsc, true))
+   return -EAGAIN;
+
+   return 0;
+}
+
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
 {
return gsc_uc_get_fw_status(gsc_uc_to_gt(gsc)->uncore, false) &
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index ad2167ce9137..bc9dd0de8aaf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -16,5 +16,6 @@ int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, 
const void *data, s
 int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc, bool 
needs_wakeref);
+int intel_gsc_uc_fw_proxy_get_status(struct intel_gsc_uc *gsc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..ee79e0809a6d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
 #include 
 
 #include "gt/intel_gt_pm.h"
+#include "gt/uc/intel_gsc_fw.h"
+
 #include "i915_driver.h"
 #include "i915_drv.h"
 #include "i915_selftest.h"
@@ -127,6 +129,31 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
 }
 
+static bool
+__gsc_proxy_init_progressing(struct intel_gsc_uc *gsc)
+{
+   return intel_gsc_uc_fw_proxy_get_status(gsc) == -EAGAIN;
+}
+
+static void
+__wait_gsc_proxy_completed(struct drm_i915_private *i915)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw));
+   /*
+* The gsc proxy component depends on the kernel component driver load 
ordering
+* and in corner cases (the first time after an IFWI flash), 
init-completion
+* firmware flows take longer.
+*/
+   unsigned long timeout_ms = 8000;
+
+   if (need_to_wait && 
wait_for(!__gsc_proxy_init_progressing(>media_gt->uc.gsc),
+timeout_ms))
+   pr_warn(DRIVER_NAME "Timed out waiting for 
gsc_proxy_completion!\n");
+}
+
 static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -206,6 +233,8 @@ int i915_live_selftests(struct pci_dev *pdev)
if 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update AUX invalidation sequence (rev8)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev8)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update AUX invalidation sequence (rev8)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev8)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim checkpatch failed
696c6b239a71 drm/i915/gt: Cleanup aux invalidation registers
ba3873d2802a drm/i915: Add the has_aux_ccs device property
8cc2211308ad drm/i915/gt: Ensure memory quiesced before invalidation
d1b12d76fbff drm/i915/gt: Rename flags with bit_group_X according to the 
datasheet
54b2cec88008 drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
-:42: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#42: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:302:
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
  ^

total: 0 errors, 0 warnings, 1 checks, 20 lines checked
7778886ca085 drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single 
function
920a67fa76d2 drm/i915/gt: Ensure memory quiesced before invalidation for all 
engines
-:7: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id 'af9e423a8aae', maybe rebased 
or not pulled?
#7: 
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before

total: 0 errors, 1 warnings, 0 checks, 51 lines checked
c9cabd4ec887 drm/i915/gt: Poll aux invalidation register bit on invalidation
854ed4a400db drm/i915/gt: Support aux invalidation on all engines




[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix premature release of request's reusable memory (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix premature release of request's reusable memory (rev3)
URL   : https://patchwork.freedesktop.org/series/120170/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_120170v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@all-busy-check-all:
- shard-dg2:  NOTRUN -> [SKIP][1] ([i915#8414])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@drm_fdi...@all-busy-check-all.html

  * igt@gem_busy@semaphore:
- shard-dg2:  NOTRUN -> [SKIP][2] ([i915#3936])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_b...@semaphore.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-snb1/igt@gem_ctx_persiste...@legacy-engines-queued.html

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-rkl-6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fence@concurrent:
- shard-dg2:  NOTRUN -> [SKIP][9] ([i915#4812])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_exec_fe...@concurrent.html

  * igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#3539] / [i915#4852])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html

  * igt@gem_exec_reloc@basic-wc-read:
- shard-dg2:  NOTRUN -> [SKIP][11] ([i915#3281])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_exec_re...@basic-wc-read.html

  * igt@gem_exec_schedule@reorder-wide:
- shard-dg2:  NOTRUN -> [SKIP][12] ([i915#4537] / [i915#4812])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_exec_sched...@reorder-wide.html

  * igt@gem_fenced_exec_thrash@no-spare-fences-interruptible:
- shard-dg2:  NOTRUN -> [SKIP][13] ([i915#4860])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_fenced_exec_thr...@no-spare-fences-interruptible.html

  * igt@gem_mmap_gtt@basic-small-bo-tiledy:
- shard-dg2:  NOTRUN -> [SKIP][14] ([i915#4077]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_mmap_...@basic-small-bo-tiledy.html

  * igt@gem_pwrite@basic-self:
- shard-dg2:  NOTRUN -> [SKIP][15] ([i915#3282])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_pwr...@basic-self.html

  * igt@gem_set_tiling_vs_blt@tiled-to-untiled:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#4079]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_set_tiling_vs_...@tiled-to-untiled.html

  * igt@gem_userptr_blits@readonly-unsync:
- shard-dg2:  NOTRUN -> [SKIP][17] ([i915#3297])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gem_userptr_bl...@readonly-unsync.html

  * igt@gen7_exec_parse@oacontrol-tracking:
- shard-dg2:  NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gen7_exec_pa...@oacontrol-tracking.html

  * igt@gen9_exec_parse@unaligned-jump:
- shard-dg2:  NOTRUN -> [SKIP][19] ([i915#2856])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/shard-dg2-8/igt@gen9_exec_pa...@unaligned-jump.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-mtlp: [PASS][20] -> [FAIL][21] ([i915#8691])
   [20]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing.

2023-07-20 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we 
are really allowing.
URL   : https://patchwork.freedesktop.org/series/121071/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/121071/revisions/1/mbox/ not 
applied
Applying: drm/xe: Only set PCI d3cold_allowed when we are really allowing.
error: sha1 information is lacking or useless (drivers/gpu/drm/xe/xe_pci.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/xe: Only set PCI d3cold_allowed when we are really 
allowing.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced




[Intel-gfx] [PATCH v7 9/9] drm/i915/gt: Support aux invalidation on all engines

2023-07-20 Thread Andi Shyti
Perform some refactoring with the purpose of keeping in one
single place all the operations around the aux table
invalidation.

With this refactoring add more engines where the invalidation
should be performed.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 58 +++-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  3 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 17 +--
 3 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 3ded597f002a2..30fb4e0af6134 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,9 +165,36 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
 }
 
-u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg)
+static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
 {
-   u32 gsi_offset = gt->uncore->gsi_offset;
+   if (!HAS_AUX_CCS(engine->i915))
+   return INVALID_MMIO_REG;
+
+   switch (engine->id) {
+   case RCS0:
+   return GEN12_CCS_AUX_INV;
+   case BCS0:
+   return GEN12_BCS0_AUX_INV;
+   case VCS0:
+   return GEN12_VD0_AUX_INV;
+   case VCS2:
+   return GEN12_VD2_AUX_INV;
+   case VECS0:
+   return GEN12_VE0_AUX_INV;
+   case CCS0:
+   return GEN12_CCS0_AUX_INV;
+   default:
+   return INVALID_MMIO_REG;
+   }
+}
+
+u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
+{
+   i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
+   u32 gsi_offset = engine->gt->uncore->gsi_offset;
+
+   if (i915_mmio_reg_valid(inv_reg))
+   return cs;
 
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
@@ -201,6 +228,11 @@ static u32 *intel_emit_pipe_control_cs(struct i915_request 
*rq, u32 bit_group_0,
return cs;
 }
 
+static bool gen12_engine_has_aux_inv(struct intel_engine_cs *engine)
+{
+   return i915_mmio_reg_valid(gen12_get_aux_inv_reg(engine));
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
@@ -307,11 +339,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
-   /* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
- GEN12_CCS_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(engine, cs);
 
*cs++ = preparser_disable(false);
intel_ring_advance(rq, cs);
@@ -322,7 +350,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
-   intel_engine_mask_t aux_inv = 0;
u32 cmd_flush = 0;
u32 cmd = 4;
u32 *cs;
@@ -330,15 +357,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915))
-   aux_inv = rq->engine->mask &
- ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-
/*
 * On Aux CCS platforms the invalidation of the Aux
 * table requires quiescing memory traffic beforehand
 */
-   if (aux_inv) {
+   if (gen12_engine_has_aux_inv(rq->engine)) {
cmd += 8; /* for the AUX invalidation */
cmd += 2; /* for the engine quiescing */
 
@@ -381,14 +404,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
 
-   if (aux_inv) { /* hsdes: 1809175790 */
-   if (rq->engine->class == VIDEO_DECODE_CLASS)
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_INV);
-   else
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(rq->engine, cs);
 
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(false);
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index a44eda096557c..867ba697aceb8 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -13,6 +13,7 @@
 #include "intel_gt_regs.h"
 #include "intel_gpu_commands.h"
 

[Intel-gfx] [PATCH v7 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-20 Thread Andi Shyti
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.

Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 36 
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 202d6ff8b5264..b6dd22eb2d9b2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -316,26 +316,40 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
intel_engine_mask_t aux_inv = 0;
-   u32 cmd, *cs;
+   u32 cmd_flush = 0;
+   u32 cmd = 4;
+   u32 *cs;
 
-   cmd = 4;
-   if (mode & EMIT_INVALIDATE) {
+   if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915) &&
-   (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
-   aux_inv = rq->engine->mask &
-   ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-   if (aux_inv)
-   cmd += 4;
-   }
+   if (HAS_AUX_CCS(rq->engine->i915))
+   aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+   if (aux_inv) {
+   cmd += 4; /* for the AUX invalidation */
+   cmd += 2; /* for the engine quiescing */
+
+   cmd_flush = MI_FLUSH_DW;
+
+   if (rq->engine->class == COPY_ENGINE_CLASS)
+   cmd_flush |= MI_FLUSH_DW_CCS;
}
 
cs = intel_ring_begin(rq, cmd);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
+   if (cmd_flush) {
+   *cs++ = cmd_flush;
+   *cs++ = 0;
+   }
+
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(true);
 
-- 
2.40.1



[Intel-gfx] [PATCH v7 8/9] drm/i915/gt: Poll aux invalidation register bit on invalidation

2023-07-20 Thread Andi Shyti
From: Jonathan Cavitt 

For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 17 -
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index b6dd22eb2d9b2..3ded597f002a2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -172,7 +172,15 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
-   *cs++ = MI_NOOP;
+
+   *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
+   MI_SEMAPHORE_REGISTER_POLL |
+   MI_SEMAPHORE_POLL |
+   MI_SEMAPHORE_SAD_EQ_SDD;
+   *cs++ = 0;
+   *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
+   *cs++ = 0;
+   *cs++ = 0;
 
return cs;
 }
@@ -282,10 +290,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
+   count = 8;
if (HAS_AUX_CCS(rq->engine->i915))
-   count = 8 + 4;
-   else
-   count = 8;
+   count += 8;
 
cs = intel_ring_begin(rq, count);
if (IS_ERR(cs))
@@ -332,7 +339,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 * table requires quiescing memory traffic beforehand
 */
if (aux_inv) {
-   cmd += 4; /* for the AUX invalidation */
+   cmd += 8; /* for the AUX invalidation */
cmd += 2; /* for the engine quiescing */
 
cmd_flush = MI_FLUSH_DW;
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5df7cce23197c..2bd8d98d21102 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -121,6 +121,7 @@
 #define   MI_SEMAPHORE_TARGET(engine)  ((engine)<<15)
 #define MI_SEMAPHORE_WAIT  MI_INSTR(0x1c, 2) /* GEN8+ */
 #define MI_SEMAPHORE_WAIT_TOKENMI_INSTR(0x1c, 3) /* GEN12+ */
+#define   MI_SEMAPHORE_REGISTER_POLL   (1 << 16)
 #define   MI_SEMAPHORE_POLL(1 << 15)
 #define   MI_SEMAPHORE_SAD_GT_SDD  (0 << 12)
 #define   MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
-- 
2.40.1



[Intel-gfx] [PATCH v7 4/9] drm/i915/gt: Rename flags with bit_group_X according to the datasheet

2023-07-20 Thread Andi Shyti
In preparation of the next patch align with the datasheet (BSPEC
47112) with the naming of the pipe control set of flag values.
The variable "flags" in gen12_emit_flush_rcs() is applied as a
set of flags called Bit Group 1.

Define also the Bit Group 0 as bit_group_0 where currently only
PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Matt Roper 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 34 +---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 18 -
 2 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 5fbc3f630f32b..7566c89d9def3 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -207,7 +207,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * table requires quiescing memory traffic beforehand
 */
if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
-   u32 flags = 0;
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
int err;
u32 *cs;
 
@@ -215,32 +216,33 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
if (err)
return err;
 
-   flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_FLUSH_L3;
-   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
/* Wa_1409600907:tgl,adl-p */
-   flags |= PIPE_CONTROL_DEPTH_STALL;
-   flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
-   flags |= PIPE_CONTROL_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_ENABLE;
 
-   flags |= PIPE_CONTROL_STORE_DATA_INDEX;
-   flags |= PIPE_CONTROL_QW_WRITE;
+   bit_group_1 |= PIPE_CONTROL_STORE_DATA_INDEX;
+   bit_group_1 |= PIPE_CONTROL_QW_WRITE;
 
-   flags |= PIPE_CONTROL_CS_STALL;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
 
if (!HAS_3D_PIPELINE(engine->i915))
-   flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (engine->class == COMPUTE_CLASS)
-   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   cs = gen12_emit_pipe_control(cs,
-PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
-flags, LRC_PPHWSP_SCRATCH_ADDR);
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
intel_ring_advance(rq, cs);
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 655e5c00ddc27..a44eda096557c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -49,25 +49,29 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs);
 u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg);
 
 static inline u32 *
-__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
+__gen8_emit_pipe_control(u32 *batch, u32 bit_group_0,
+u32 bit_group_1, u32 offset)
 {
memset(batch, 0, 6 * sizeof(u32));
 
-   batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
-   batch[1] = flags1;
+   batch[0] = GFX_OP_PIPE_CONTROL(6) | bit_group_0;
+   batch[1] = bit_group_1;
batch[2] = offset;
 
return batch + 6;
 }
 
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *gen8_emit_pipe_control(u32 *batch,
+ u32 bit_group_1, u32 offset)
 {
-   return __gen8_emit_pipe_control(batch, 0, flags, offset);
+   return __gen8_emit_pipe_control(batch, 0, bit_group_1, offset);
 }
 
-static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, 
u32 offset)
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 bit_group_0,
+   

[Intel-gfx] [PATCH v7 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

2023-07-20 Thread Andi Shyti
Just a trivial refactoring for reducing the number of code
duplicate. This will come at handy in the next commits.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9d050b9a19194..202d6ff8b5264 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
return cs;
 }
 
+static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32 
bit_group_0,
+  u32 bit_group_1, u32 offset)
+{
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 6);
+   if (IS_ERR(cs))
+   return cs;
+
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+   intel_ring_advance(rq, cs);
+
+   return cs;
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
-   u32 *cs;
-
-   /* dummy PIPE_CONTROL + depth flush */
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-   cs = gen12_emit_pipe_control(cs,
-0,
-PIPE_CONTROL_DEPTH_CACHE_FLUSH,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
-   }
+   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
+   intel_emit_pipe_control_cs(rq,
+  0,
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH,
+  LRC_PPHWSP_SCRATCH_ADDR);
 
return 0;
 }
@@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
-   u32 *cs;
 
err = mtl_dummy_pipe_control(rq);
if (err)
@@ -244,13 +251,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-
-   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
}
 
if (mode & EMIT_INVALIDATE) {
-- 
2.40.1



[Intel-gfx] [PATCH v7 5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control

2023-07-20 Thread Andi Shyti
Enable the CCS_FLUSH bit 13 in the control pipe for render and
compute engines in platforms starting from Meteor Lake (BSPEC
43904 and 47112).

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Nirmoy Das 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 7566c89d9def3..9d050b9a19194 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -218,6 +218,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5d143e2a8db03..5df7cce23197c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -299,6 +299,7 @@
 #define   PIPE_CONTROL_QW_WRITE(1<<14)
 #define   PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
 #define   PIPE_CONTROL_DEPTH_STALL (1<<13)
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
 #define   PIPE_CONTROL_WRITE_FLUSH (1<<12)
 #define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH   (1<<12) /* gen6+ */
 #define   PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
-- 
2.40.1



[Intel-gfx] [PATCH v7 3/9] drm/i915/gt: Ensure memory quiesced before invalidation

2023-07-20 Thread Andi Shyti
From: Jonathan Cavitt 

All memory traffic must be quiesced before requesting
an aux invalidation on platforms that use Aux CCS.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0d4d5e0407a2d..5fbc3f630f32b 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -202,7 +202,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 {
struct intel_engine_cs *engine = rq->engine;
 
-   if (mode & EMIT_FLUSH) {
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+   if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
u32 flags = 0;
int err;
u32 *cs;
-- 
2.40.1



[Intel-gfx] [PATCH v7 2/9] drm/i915: Add the has_aux_ccs device property

2023-07-20 Thread Andi Shyti
We always assumed that a device might either have AUX or FLAT
CCS, but this is an approximation that is not always true as it
requires some further per device checks.

Add the "has_aux_ccs" flag in the intel_device_info structure in
order to have a per device flag indicating of the AUX CCS.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Jonathan Cavitt 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/i915_pci.c  | 5 -
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 563efee055602..0d4d5e0407a2d 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915))
+   if (HAS_AUX_CCS(rq->engine->i915))
count = 8 + 4;
else
count = 8;
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915) &&
+   if (HAS_AUX_CCS(rq->engine->i915) &&
(rq->engine->class == VIDEO_DECODE_CLASS ||
 rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask &
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 682ef2b5c7d59..e9cc048b5727a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -848,6 +848,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  * stored in lmem to support the 3D and media compression formats.
  */
 #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
+#define HAS_AUX_CCS(i915)(INTEL_INFO(i915)->has_aux_ccs)
 
 #define HAS_GT_UC(i915)(INTEL_INFO(i915)->has_gt_uc)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fcacdc21643cf..c9ff1d11a9fce 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,8 @@ static const struct intel_device_info jsl_info = {
TGL_CACHELEVEL, \
.has_global_mocs = 1, \
.has_pxp = 1, \
-   .max_pat_index = 3
+   .max_pat_index = 3, \
+   .has_aux_ccs = 1
 
 static const struct intel_device_info tgl_info = {
GEN12_FEATURES,
@@ -775,6 +776,7 @@ static const struct intel_device_info dg2_info = {
 
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
+   .has_aux_ccs = 1,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
 };
@@ -827,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.__runtime.media.ip.ver = 13,
PLATFORM(INTEL_METEORLAKE),
.extra_gt_list = xelpmp_extra_gt,
+   .has_aux_ccs = 1,
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index dbfe6443457b5..93485507506cc 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -151,6 +151,7 @@ enum intel_ppgtt_type {
func(has_reset_engine); \
func(has_3d_pipeline); \
func(has_4tile); \
+   func(has_aux_ccs); \
func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gmd_id); \
-- 
2.40.1



[Intel-gfx] [PATCH v7 0/9] Update AUX invalidation sequence

2023-07-20 Thread Andi Shyti
Hi,

as there are new hardware directives, we need a little adaptation
for the AUX invalidation sequence.

In this version we support all the engines affected by this
change.

The stable backport has some challenges because the original
patch that this series fixes has had more changes in between.

This patch is slowly exploding with code refactorings and
features added and fixed.

Thanks a lot Nirmoy, Andrzej and Matt for your review and for the
fruitful discussions!

Thanks,
Andi

Changelog:
=
v6 -> v7
 - Fix correct sequence applied to the correct engine. A little
   confusion promptly cought by Nirmoy when applying to the VD
   engine the sequence belonging to the compute engines. Thanks a
   lot, Nirmoy!

v5 -> v6
 - Fixed ccs flush in the engines VE and BCS. They are sent as a
   separate command instead of added in the pipe control.
 - Separated the CCS flusing in the pipe control patch with the
   quiescing of the memory. They were meant to be on separate
   patch already in the previous verision, but apparently I
   squashed them by mistake.

v4 -> v5
 - The AUX CCS is added as a device property instead of checking
   against FLAT CCS. This adds the new HAS_AUX_CCS check
   (Patch 2, new).
 - little and trivial refactoring here and there.
 - extended the flags{0,1}/bit_group_{0,1} renaming to other
   functions.
 - Created an intel_emit_pipe_control_cs() wrapper for submitting
   the pipe control.
 - Quiesce memory for all the engines, not just RCS (Patch 6,
   new).
 - The PIPE_CONTROL_CCS_FLUSH is added to all the engines.
 - Remove redundant EMIT_FLUSH_CCS mode flag.
 - Remove unnecessary NOOPs from the command streamer for
   invalidating the CCS table.
 - Use INVALID_MMIO_REG and gen12_get_aux_inv_reg() instad of
   __MMIO(0) and reg.reg.
 - Remove useless wrapper and just use gen12_get_aux_inv_reg().

v3 -> v4
 - A trivial patch 3 is added to rename the flags with
   bit_group_{0,1} to align with the datasheet naming.
 - Patch 4 fixes a confusion I made where the CCS flag was
   applied to the wrong bit group.

v2 -> v3
 - added r-b from Nirmoy in patch 1 and 4.
 - added patch 3 which enables the ccs_flush in the control pipe
   for mtl+ compute and render engines.
 - added redundant checks in patch 2 for enabling the EMIT_FLUSH
   flag.

v1 -> v2
 - add a clean up preliminary patch for the existing registers
 - add support for more engines
 - add the Fixes tag

Andi Shyti (7):
  drm/i915/gt: Cleanup aux invalidation registers
  drm/i915: Add the has_aux_ccs device property
  drm/i915/gt: Rename flags with bit_group_X according to the datasheet
  drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
  drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single
function
  drm/i915/gt: Ensure memory quiesced before invalidation for all
engines
  drm/i915/gt: Support aux invalidation on all engines

Jonathan Cavitt (2):
  drm/i915/gt: Ensure memory quiesced before invalidation
  drm/i915/gt: Poll aux invalidation register bit on invalidation

 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 188 ---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  21 ++-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  16 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  17 +-
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   5 +-
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 8 files changed, 151 insertions(+), 100 deletions(-)

-- 
2.40.1



[Intel-gfx] [PATCH v7 1/9] drm/i915/gt: Cleanup aux invalidation registers

2023-07-20 Thread Andi Shyti
Fix the 'NV' definition postfix that is supposed to be INV.

Take the chance to also order properly the registers based on
their address and call the GEN12_GFX_CCS_AUX_INV address as
GEN12_CCS_AUX_INV like all the other similar registers.

Remove also VD1, VD3 and VE1 registers that don't exist and add
BCS0 and CCS0.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  8 
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  | 16 
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  6 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca1..563efee055602 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -287,8 +287,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
if (!HAS_FLAT_CCS(rq->engine->i915)) {
/* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
+ GEN12_CCS_AUX_INV);
}
 
*cs++ = preparser_disable(false);
@@ -348,10 +348,10 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (aux_inv) { /* hsdes: 1809175790 */
if (rq->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+ cs, GEN12_VD0_AUX_INV);
else
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_NV);
+ cs, GEN12_VE0_AUX_INV);
}
 
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79e..2cdfb2f713d02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -332,9 +332,11 @@
 #define GEN8_PRIVATE_PAT_HI_MMIO(0x40e0 + 4)
 #define GEN10_PAT_INDEX(index) _MMIO(0x40e0 + (index) * 4)
 #define BSD_HWS_PGA_GEN7   _MMIO(0x4180)
-#define GEN12_GFX_CCS_AUX_NV   _MMIO(0x4208)
-#define GEN12_VD0_AUX_NV   _MMIO(0x4218)
-#define GEN12_VD1_AUX_NV   _MMIO(0x4228)
+
+#define GEN12_CCS_AUX_INV  _MMIO(0x4208)
+#define GEN12_VD0_AUX_INV  _MMIO(0x4218)
+#define GEN12_VE0_AUX_INV  _MMIO(0x4238)
+#define GEN12_BCS0_AUX_INV _MMIO(0x4248)
 
 #define GEN8_RTCR  _MMIO(0x4260)
 #define GEN8_M1TCR _MMIO(0x4264)
@@ -342,14 +344,12 @@
 #define GEN8_BTCR  _MMIO(0x426c)
 #define GEN8_VTCR  _MMIO(0x4270)
 
-#define GEN12_VD2_AUX_NV   _MMIO(0x4298)
-#define GEN12_VD3_AUX_NV   _MMIO(0x42a8)
-#define GEN12_VE0_AUX_NV   _MMIO(0x4238)
-
 #define BLT_HWS_PGA_GEN7   _MMIO(0x4280)
 
-#define GEN12_VE1_AUX_NV   _MMIO(0x42b8)
+#define GEN12_VD2_AUX_INV  _MMIO(0x4298)
+#define GEN12_CCS0_AUX_INV _MMIO(0x42c8)
 #define   AUX_INV  REG_BIT(0)
+
 #define VEBOX_HWS_PGA_GEN7 _MMIO(0x4380)
 
 #define GEN12_AUX_ERR_DBG  _MMIO(0x43f4)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1b710102390bf..235f3fab60a98 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1374,7 +1374,7 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context 
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915))
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+ cs, GEN12_CCS_AUX_INV);
 
/* Wa_16014892111 */
if (IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) ||
@@ -1403,10 +1403,10 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+   

Re: [Intel-gfx] [PATCH v6 0/9] Update AUX invalidation sequence

2023-07-20 Thread Andi Shyti
Ops... sorry... I am realizing that I sent again V6... please
ignore this series!

Andi

On Thu, Jul 20, 2023 at 06:44:45PM +0200, Andi Shyti wrote:
> Hi,
> 
> as there are new hardware directives, we need a little adaptation
> for the AUX invalidation sequence.
> 
> In this version we support all the engines affected by this
> change.
> 
> The stable backport has some challenges because the original
> patch that this series fixes has had more changes in between.
> 
> This patch is slowly exploding with code refactorings and
> features added and fixed.
> 
> Thanks a lot Nirmoy, Andrzej and Matt for your review and for the
> fruitful discussions!
> 
> Thanks,
> Andi
> 
> Changelog:
> =
> v5 -> v6
>  - Fixed ccs flush in the engines VE and BCS. They are sent as a
>separate command instead of added in the pipe control.
>  - Separated the CCS flusing in the pipe control patch with the
>quiescing of the memory. They were meant to be on separate
>patch already in the previous verision, but apparently I
>squashed them by mistake.
> 
> v4 -> v5
>  - The AUX CCS is added as a device property instead of checking
>against FLAT CCS. This adds the new HAS_AUX_CCS check
>(Patch 2, new).
>  - little and trivial refactoring here and there.
>  - extended the flags{0,1}/bit_group_{0,1} renaming to other
>functions.
>  - Created an intel_emit_pipe_control_cs() wrapper for submitting
>the pipe control.
>  - Quiesce memory for all the engines, not just RCS (Patch 6,
>new).
>  - The PIPE_CONTROL_CCS_FLUSH is added to all the engines.
>  - Remove redundant EMIT_FLUSH_CCS mode flag.
>  - Remove unnecessary NOOPs from the command streamer for
>invalidating the CCS table.
>  - Use INVALID_MMIO_REG and gen12_get_aux_inv_reg() instad of
>__MMIO(0) and reg.reg.
>  - Remove useless wrapper and just use gen12_get_aux_inv_reg().
> 
> v3 -> v4
>  - A trivial patch 3 is added to rename the flags with
>bit_group_{0,1} to align with the datasheet naming.
>  - Patch 4 fixes a confusion I made where the CCS flag was
>applied to the wrong bit group.
> 
> v2 -> v3
>  - added r-b from Nirmoy in patch 1 and 4.
>  - added patch 3 which enables the ccs_flush in the control pipe
>for mtl+ compute and render engines.
>  - added redundant checks in patch 2 for enabling the EMIT_FLUSH
>flag.
> 
> v1 -> v2
>  - add a clean up preliminary patch for the existing registers
>  - add support for more engines
>  - add the Fixes tag
> 
> Andi Shyti (7):
>   drm/i915/gt: Cleanup aux invalidation registers
>   drm/i915: Add the has_aux_ccs device property
>   drm/i915/gt: Rename flags with bit_group_X according to the datasheet
>   drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single
> function
>   drm/i915/gt: Ensure memory quiesced before invalidation for all
> engines
>   drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
>   drm/i915/gt: Support aux invalidation on all engines
> 
> Jonathan Cavitt (2):
>   drm/i915/gt: Ensure memory quiesced before invalidation
>   drm/i915/gt: Poll aux invalidation register bit on invalidation
> 
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 222 +--
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  21 +-
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   2 +
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  16 +-
>  drivers/gpu/drm/i915/gt/intel_lrc.c  |  17 +-
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  drivers/gpu/drm/i915/i915_pci.c  |   5 +-
>  drivers/gpu/drm/i915/intel_device_info.h |   1 +
>  8 files changed, 186 insertions(+), 99 deletions(-)
> 
> -- 
> 2.40.1


[Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place.

2023-07-20 Thread Rodrigo Vivi
We cannot allow runtime pm suspend after we configured the
d3cold capable and threshold.

Cc: Anshuman Gupta 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 73bcb76c2d42..366ee446af38 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -152,10 +152,12 @@ void xe_pm_init(struct xe_device *xe)
struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
 
drmm_mutex_init(>drm, >d3cold.lock);
-   xe_pm_runtime_init(xe);
+
xe->d3cold.capable = xe_pm_pci_d3cold_capable(pdev);
xe_device_sysfs_init(xe);
xe_pm_set_vram_threshold(xe, DEFAULT_VRAM_THRESHOLD);
+
+   xe_pm_runtime_init(xe);
 }
 
 void xe_pm_runtime_fini(struct xe_device *xe)
-- 
2.41.0



[Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision.

2023-07-20 Thread Rodrigo Vivi
According to Documentation/power/runtime_pm.txt:

int pm_runtime_put(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
  pm_request_idle(dev) and return its result

int pm_runtime_put_autosuspend(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
  pm_request_autosuspend(dev) and return its result

We need to ensure that the idle function is called before suspending
so we take the right d3cold.allowed decision and respect the values
set on vram_d3cold_threshold sysfs. So we need pm_runtime_put()
instead of pm_runtime_put_autosuspend().

Cc: Anshuman Gupta 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index a6459df2599e..73bcb76c2d42 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -144,7 +144,7 @@ static void xe_pm_runtime_init(struct xe_device *xe)
pm_runtime_set_active(dev);
pm_runtime_allow(dev);
pm_runtime_mark_last_busy(dev);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_put(dev);
 }
 
 void xe_pm_init(struct xe_device *xe)
@@ -273,7 +273,7 @@ int xe_pm_runtime_get(struct xe_device *xe)
 int xe_pm_runtime_put(struct xe_device *xe)
 {
pm_runtime_mark_last_busy(xe->drm.dev);
-   return pm_runtime_put_autosuspend(xe->drm.dev);
+   return pm_runtime_put(xe->drm.dev);
 }
 
 int xe_pm_runtime_get_if_active(struct xe_device *xe)
-- 
2.41.0



[Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together.

2023-07-20 Thread Rodrigo Vivi
And let's use the VRAM threshold to keep d3cold temporarily disabled.

With this we have the ability to run D3Cold experiments just by
touching the vram_d3cold_threshold sysfs entry.

Cc: Anshuman Gupta 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_pci.c | 15 +--
 drivers/gpu/drm/xe/xe_pm.c  |  5 +
 drivers/gpu/drm/xe/xe_pm.h  |  7 ++-
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 0c4051f4f746..06759afb4224 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -834,20 +834,7 @@ static int xe_pci_runtime_idle(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
struct xe_device *xe = pdev_to_xe_device(pdev);
 
-   if (!xe->d3cold.capable) {
-   xe->d3cold.allowed = false;
-   } else {
-   xe_pm_d3cold_allowed_toggle(xe);
-
-   /*
-* TODO: d3cold should be allowed (true) if
-* (IS_DGFX(xe) && !xe_device_mem_access_ongoing(xe))
-* but maybe include some other conditions. So, before
-* we can re-enable the D3cold, we need to:
-* 1. rewrite the VRAM save / restore to avoid buffer object 
locks
-*/
-   xe->d3cold.allowed = false;
-   }
+   xe_pm_d3cold_allowed_toggle(xe);
 
return 0;
 }
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 17a69b7af155..a6459df2599e 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -326,6 +326,11 @@ void xe_pm_d3cold_allowed_toggle(struct xe_device *xe)
u64 vram_used;
int i;
 
+   if (!xe->d3cold.capable) {
+   xe->d3cold.allowed = false;
+   return;
+   }
+
for (i = XE_PL_VRAM0; i <= XE_PL_VRAM1; ++i) {
man = ttm_manager_type(>ttm, i);
if (man) {
diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h
index 08a633ce5145..6b9031f7af24 100644
--- a/drivers/gpu/drm/xe/xe_pm.h
+++ b/drivers/gpu/drm/xe/xe_pm.h
@@ -8,7 +8,12 @@
 
 #include 
 
-#define DEFAULT_VRAM_THRESHOLD 300 /* in MB */
+/*
+ * TODO: Threshold = 0 will block D3Cold.
+ *   Before we can move this to a higher value (like 300), we need to:
+ *   1. rewrite the VRAM save / restore to avoid buffer object locks
+ */
+#define DEFAULT_VRAM_THRESHOLD 0 /* in MB */
 
 struct xe_device;
 
-- 
2.41.0



[Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing.

2023-07-20 Thread Rodrigo Vivi
First of all it was strange to see:
if (allowed) {
...
} else {
   D3COLD_ENABLE
}

But besides this misalignment, let's also use the pci
d3cold_allowed useful to us and know that we are not really
allowing d3cold.

Cc: Anshuman Gupta 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 78df43c20cd2..0c4051f4f746 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device *dev)
pci_save_state(pdev);
 
if (xe->d3cold.allowed) {
+   d3cold_toggle(pdev, D3COLD_ENABLE);
pci_disable_device(pdev);
pci_ignore_hotplug(pdev);
pci_set_power_state(pdev, PCI_D3cold);
@@ -823,8 +824,6 @@ static int xe_pci_runtime_resume(struct device *dev)
return err;
 
pci_set_master(pdev);
-   } else {
-   d3cold_toggle(pdev, D3COLD_ENABLE);
}
 
return xe_pm_runtime_resume(xe);
-- 
2.41.0



Re: [Intel-gfx] [PATCH v6 7/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control

2023-07-20 Thread Matt Roper
On Wed, Jul 19, 2023 at 01:07:27PM +0200, Andi Shyti wrote:
> Enable the CCS_FLUSH bit 13 in the control pipe for render and
> compute engines in platforms starting from Meteor Lake (BSPEC
> 43904 and 47112). The VE and BCS engines need to add the flush
> part in their command streamer.
> 
> Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all 
> engines")
> Signed-off-by: Andi Shyti 
> Cc: Jonathan Cavitt 
> Cc: Nirmoy Das 
> Cc:  # v5.8+
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 31 
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 3bedab8d61db1..78bbd55262a2d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -225,6 +225,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>  
>   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
>  
> + /*
> +  * When required, in MTL+ platforms we need to

Nitpick:  let's avoid using "FOO+" as "FOO and beyond."  We already have
formal IP names that include + signs (Xe_LPM+, Xe_LPD+, etc.), so using
it this way can cause confusion.

> +  * set the CCS_FLUSH bit in the pipe control
> +  */
> + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
> +
>   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
>   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
>   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> @@ -309,6 +316,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>  int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
>  {
>   intel_engine_mask_t aux_inv = 0;
> + u32 cmd_flush = 0;
>   u32 cmd = 4;
>   u32 *cs;
>  
> @@ -339,6 +347,13 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
>   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
>   bit_group_1 |= PIPE_CONTROL_CS_STALL;
>  
> + /*
> +  * When required, in MTL+ platforms we need to
> +  * set the CCS_FLUSH bit in the pipe control
> +  */
> + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
> +
>   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
>  LRC_PPHWSP_SCRATCH_ADDR);
>  
> @@ -346,7 +361,18 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
>  
>   case VIDEO_ENHANCEMENT_CLASS:
>   case COMPUTE_CLASS:
> + cmd += 2;
> + cmd_flush = MI_FLUSH_DW;
> +
> + break;
> +

It looks like some of these changes wound up in the wrong patch?
And as Nirmoy pointed out on the other patch, some of the functions and
engine instructions are mixed around here too.


Matt

>   case COPY_ENGINE_CLASS:
> + cmd += 2;
> + /*
> +  * When required, in MTL+ platforms we need to
> +  * set the CCS_FLUSH bit in the pipe control
> +  */
> + cmd_flush = MI_FLUSH_DW | MI_FLUSH_DW_CCS;
>   break;
>   }
>   }
> @@ -355,6 +381,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
>   if (IS_ERR(cs))
>   return PTR_ERR(cs);
>  
> + if (cmd_flush) {
> + *cs++ = cmd_flush;
> + *cs++ = 0;
> + }
> +
>   if (mode & EMIT_INVALIDATE)
>   *cs++ = preparser_disable(true);
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index 5d143e2a8db03..5df7cce23197c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -299,6 +299,7 @@
>  #define   PIPE_CONTROL_QW_WRITE  (1<<14)
>  #define   PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
>  #define   PIPE_CONTROL_DEPTH_STALL   (1<<13)
> +#define   PIPE_CONTROL_CCS_FLUSH (1<<13) /* MTL+ */
>  #define   PIPE_CONTROL_WRITE_FLUSH   (1<<12)
>  #define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH (1<<12) /* gen6+ */
>  #define   PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE  (1<<11) /* MBZ on ILK */
> -- 
> 2.40.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


Re: [Intel-gfx] [PATCH v6 5/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

2023-07-20 Thread Matt Roper
On Wed, Jul 19, 2023 at 01:07:25PM +0200, Andi Shyti wrote:
> Just a trivial refactoring for reducing the number of code
> duplicate. This will come at handy in the next commits.
> 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
>  1 file changed, 23 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 7566c89d9def3..1b1dadacfbf42 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
> *cs, const i915_reg_t inv
>   return cs;
>  }
>  
> +static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32 
> bit_group_0,

This is another case where it gets confusing because this function name
sounds like it's something generic, but it actually only applies to a
small subset of platforms (gen12).

> +u32 bit_group_1, u32 offset)
> +{
> + u32 *cs;
> +
> + cs = intel_ring_begin(rq, 6);
> + if (IS_ERR(cs))
> + return cs;

We're not actually checking for this error at the callsites.  Should we
be checking for it and propagating it farther up the call stack?

> +
> + cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
> +  LRC_PPHWSP_SCRATCH_ADDR);
> + intel_ring_advance(rq, cs);
> +
> + return cs;

This cursor never gets used for anything.  We can probably just make
this function return an int error code.


Matt

> +}
> +
>  static int mtl_dummy_pipe_control(struct i915_request *rq)
>  {
>   /* Wa_14016712196 */
>   if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
> - IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
> - u32 *cs;
> -
> - /* dummy PIPE_CONTROL + depth flush */
> - cs = intel_ring_begin(rq, 6);
> - if (IS_ERR(cs))
> - return PTR_ERR(cs);
> - cs = gen12_emit_pipe_control(cs,
> -  0,
> -  PIPE_CONTROL_DEPTH_CACHE_FLUSH,
> -  LRC_PPHWSP_SCRATCH_ADDR);
> - intel_ring_advance(rq, cs);
> - }
> + IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
> + intel_emit_pipe_control_cs(rq,
> +0,
> +PIPE_CONTROL_DEPTH_CACHE_FLUSH,
> +LRC_PPHWSP_SCRATCH_ADDR);
>  
>   return 0;
>  }
> @@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>   u32 bit_group_0 = 0;
>   u32 bit_group_1 = 0;
>   int err;
> - u32 *cs;
>  
>   err = mtl_dummy_pipe_control(rq);
>   if (err)
> @@ -237,13 +244,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>   else if (engine->class == COMPUTE_CLASS)
>   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
>  
> - cs = intel_ring_begin(rq, 6);
> - if (IS_ERR(cs))
> - return PTR_ERR(cs);
> -
> - cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
> -  LRC_PPHWSP_SCRATCH_ADDR);
> - intel_ring_advance(rq, cs);
> + intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
> +LRC_PPHWSP_SCRATCH_ADDR);
>   }
>  
>   if (mode & EMIT_INVALIDATE) {
> -- 
> 2.40.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


Re: [Intel-gfx] [PATCH v5] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

2023-07-20 Thread Ceraolo Spurio, Daniele




On 7/12/2023 4:12 PM, Alan Previn wrote:

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete.

Difference from prior versions:
v5: - Move the call to __wait_gsc_proxy_completed from common
  __run_selftests dispatcher to the group-level selftest
  function (Trvtko).
- change the pr_info to pr_warn if we hit the timeout.
v4: - Remove generalized waiters function table framework (Tvrtko).
- Remove mention of CI-framework-timeout from comments (Tvrtko).
v3: - Rebase to latest drm-tip.
v2: - Based on internal testing, increase the timeout for gsc-proxy
  specific case to 8 seconds.

Signed-off-by: Alan Previn 
---
  .../gpu/drm/i915/selftests/i915_selftest.c| 26 +++
  1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..b03d03eac3d6 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
  #include 
  
  #include "gt/intel_gt_pm.h"

+#include "gt/uc/intel_gsc_fw.h"
+
  #include "i915_driver.h"
  #include "i915_drv.h"
  #include "i915_selftest.h"
@@ -127,6 +129,26 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
  }
  
+static void

+__wait_gsc_proxy_completed(struct drm_i915_private *i915)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw));
+   /*
+* The gsc proxy component depends on the kernel component driver load 
ordering
+* and in corner cases (the first time after an IFWI flash), 
init-completion
+* firmware flows take longer.
+*/
+   unsigned long timeout_ms = 8000;
+
+   if (need_to_wait &&
+   (wait_for(intel_gsc_uc_fw_proxy_init_done(>media_gt->uc.gsc, 
true),


Small issue here: if proxy init fails, intel_gsc_uc_fw_proxy_init_done 
will keep returning false, so we'll wait for the full 8 secs. Maybe we 
can instead have a proxy_init_status function to differentiate between 
pending/failed/done. This would basically be a generalization of the 
checks you already have in https://patchwork.freedesktop.org/series/118723/.

Patch LGTM apart from this.

Daniele


+   timeout_ms)))
+   pr_warn(DRIVER_NAME "Timed out waiting for 
gsc_proxy_completion!\n");
+}
+
  static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -206,6 +228,8 @@ int i915_live_selftests(struct pci_dev *pdev)
if (!i915_selftest.live)
return 0;
  
+	__wait_gsc_proxy_completed(pdev_to_i915(pdev));

+
err = run_selftests(live, pdev_to_i915(pdev));
if (err) {
i915_selftest.live = err;
@@ -227,6 +251,8 @@ int i915_perf_selftests(struct pci_dev *pdev)
if (!i915_selftest.perf)
return 0;
  
+	__wait_gsc_proxy_completed(pdev_to_i915(pdev));

+
err = run_selftests(perf, pdev_to_i915(pdev));
if (err) {
i915_selftest.perf = err;

base-commit: 57ea1a97c50c63c77e3bfa46ee486e8a451be5e7




Re: [Intel-gfx] [PATCH v6 2/9] drm/i915: Add the has_aux_ccs device property

2023-07-20 Thread Matt Roper
On Wed, Jul 19, 2023 at 01:07:22PM +0200, Andi Shyti wrote:
> We always assumed that a device might either have AUX or FLAT
> CCS, but this is an approximation that is not always true as it
> requires some further per device checks.
> 
> Add the "has_aux_ccs" flag in the intel_device_info structure in
> order to have a per device flag indicating of the AUX CCS.

I think this flag is a bit misnamed/inaccurate at the moment.  AuxCCS in
general has been around for ages.  Bspec 14276 indicates the GT side of
the hardware has had AuxCCS since at least SNB (gen6).  You seem to just
be setting this flag on the platforms where we need to do TLB
invalidation for the AUX (gen12), which is a small subset of the
platforms that had this compression in general.

I kind of feel like the helper function approach might still be simpler
than using a device flag, but if you want to stick with the flag it's
probably best to rename it slightly so that it more accurately reflects
what we're using it for.


Matt

> 
> Signed-off-by: Andi Shyti 
> Cc: Matt Roper 
> Cc: Jonathan Cavitt 
> Cc:  # v5.8+
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 4 ++--
>  drivers/gpu/drm/i915/i915_drv.h  | 1 +
>  drivers/gpu/drm/i915/i915_pci.c  | 5 -
>  drivers/gpu/drm/i915/intel_device_info.h | 1 +
>  4 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 563efee055602..0d4d5e0407a2d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>   else if (engine->class == COMPUTE_CLASS)
>   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
>  
> - if (!HAS_FLAT_CCS(rq->engine->i915))
> + if (HAS_AUX_CCS(rq->engine->i915))
>   count = 8 + 4;
>   else
>   count = 8;
> @@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
>   if (mode & EMIT_INVALIDATE) {
>   cmd += 2;
>  
> - if (!HAS_FLAT_CCS(rq->engine->i915) &&
> + if (HAS_AUX_CCS(rq->engine->i915) &&
>   (rq->engine->class == VIDEO_DECODE_CLASS ||
>rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
>   aux_inv = rq->engine->mask &
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 682ef2b5c7d59..e9cc048b5727a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -848,6 +848,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>   * stored in lmem to support the 3D and media compression formats.
>   */
>  #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
> +#define HAS_AUX_CCS(i915)(INTEL_INFO(i915)->has_aux_ccs)
>  
>  #define HAS_GT_UC(i915)  (INTEL_INFO(i915)->has_gt_uc)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index fcacdc21643cf..c9ff1d11a9fce 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -643,7 +643,8 @@ static const struct intel_device_info jsl_info = {
>   TGL_CACHELEVEL, \
>   .has_global_mocs = 1, \
>   .has_pxp = 1, \
> - .max_pat_index = 3
> + .max_pat_index = 3, \
> + .has_aux_ccs = 1
>  
>  static const struct intel_device_info tgl_info = {
>   GEN12_FEATURES,
> @@ -775,6 +776,7 @@ static const struct intel_device_info dg2_info = {
>  
>  static const struct intel_device_info ats_m_info = {
>   DG2_FEATURES,
> + .has_aux_ccs = 1,
>   .require_force_probe = 1,
>   .tuning_thread_rr_after_dep = 1,
>  };
> @@ -827,6 +829,7 @@ static const struct intel_device_info mtl_info = {
>   .__runtime.media.ip.ver = 13,
>   PLATFORM(INTEL_METEORLAKE),
>   .extra_gt_list = xelpmp_extra_gt,
> + .has_aux_ccs = 1,
>   .has_flat_ccs = 0,
>   .has_gmd_id = 1,
>   .has_guc_deprivilege = 1,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index dbfe6443457b5..93485507506cc 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -151,6 +151,7 @@ enum intel_ppgtt_type {
>   func(has_reset_engine); \
>   func(has_3d_pipeline); \
>   func(has_4tile); \
> + func(has_aux_ccs); \
>   func(has_flat_ccs); \
>   func(has_global_mocs); \
>   func(has_gmd_id); \
> -- 
> 2.40.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tc: some clean-ups in max lane count handling code (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/tc: some clean-ups in max lane count handling code (rev2)
URL   : https://patchwork.freedesktop.org/series/120980/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_120980v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13399_full and 
Patchwork_120980v2_full:

### New IGT tests (4) ###

  * igt@kms_flip@wf_vblank-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@all-busy-check-all:
- shard-dg2:  NOTRUN -> [SKIP][1] ([i915#8414])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@drm_fdi...@all-busy-check-all.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][2] -> [FAIL][3] ([i915#7742])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-dg2:  [PASS][4] -> [ABORT][5] ([i915#7461] / [i915#8211] / 
[i915#8234])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-8/igt@gem_barrier_race@remote-requ...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-3/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_busy@semaphore:
- shard-dg2:  NOTRUN -> [SKIP][6] ([i915#3936])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@gem_b...@semaphore.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglu: [PASS][7] -> [FAIL][8] ([i915#6268])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-tglu-3/igt@gem_ctx_e...@basic-nohangcheck.html

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

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

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-rkl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-rkl-1/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-tglu-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fence@concurrent:
- shard-dg2:  NOTRUN -> [SKIP][15] ([i915#4812])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@gem_exec_fe...@concurrent.html

  * igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#3539] / [i915#4852])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html

  * igt@gem_exec_reloc@basic-wc-read:
- shard-dg2:  NOTRUN -> [SKIP][17] ([i915#3281])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@gem_exec_re...@basic-wc-read.html

  * igt@gem_exec_schedule@reorder-wide:
- shard-dg2:  NOTRUN -> [SKIP][18] ([i915#4537] / [i915#4812])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/shard-dg2-10/igt@gem_exec_sched...@reorder-wide.html

  * igt@gem_fenced_exec_thrash@no-spare-fences-interruptible:
- shard-dg2:  NOTRUN -> [SKIP][19] ([i915#4860])
   [19]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "Revert "drm/i915: Hold reference to intel_context over life of i915_request"" (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Revert "Revert "drm/i915: Hold reference to intel_context over life of 
i915_request"" (rev2)
URL   : https://patchwork.freedesktop.org/series/120990/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_120990v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 9)
--

  Missing(1): pig-kbl-iris 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120990v2_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@plane-upscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-3:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-dg1-13/igt@kms_plane_scaling@plane-upscale-with-pixel-format-factor-0...@pipe-b-hdmi-a-3.html

  
New tests
-

  New tests have been introduced between CI_DRM_13399_full and 
Patchwork_120990v2_full:

### New IGT tests (4) ###

  * igt@kms_flip@wf_vblank-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][2] -> [FAIL][3] ([i915#7742])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_eio@unwedge-stress:
- shard-dg2:  [PASS][5] -> [FAIL][6] ([i915#5784])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-1/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-dg2-1/igt@gem_...@unwedge-stress.html
- shard-snb:  NOTRUN -> [FAIL][7] ([i915#8898])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-snb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_endless@dispatch@ccs0:
- shard-dg2:  [PASS][8] -> [TIMEOUT][9] ([i915#7016])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-7/igt@gem_exec_endless@dispa...@ccs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-dg2-12/igt@gem_exec_endless@dispa...@ccs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-tglu-10/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-rkl-6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-tglu: [PASS][14] -> [ABORT][15] ([i915#7975] / [i915#8213])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-2/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-dg2:  [PASS][16] -> [FAIL][17] ([fdo#103375]) +2 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-10/igt@gem_workarou...@suspend-resume-fd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/shard-dg2-11/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-mtlp: [PASS][18] -> [FAIL][19] ([i915#8691])
   [18]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add DSC PPS readout (rev4)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Add DSC PPS readout (rev4)
URL   : https://patchwork.freedesktop.org/series/120456/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13399_full -> Patchwork_120456v4_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gen9_exec_parse@bb-large:
- shard-apl:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-apl6/igt@gen9_exec_pa...@bb-large.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-apl1/igt@gen9_exec_pa...@bb-large.html

  
New tests
-

  New tests have been introduced between CI_DRM_13399_full and 
Patchwork_120456v4_full:

### New IGT tests (4) ###

  * igt@kms_flip@wf_vblank-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@wf_vblank-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@all-busy-check-all:
- shard-dg2:  NOTRUN -> [SKIP][3] ([i915#8414])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@drm_fdi...@all-busy-check-all.html

  * igt@gem_busy@semaphore:
- shard-dg2:  NOTRUN -> [SKIP][4] ([i915#3936])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@gem_b...@semaphore.html

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

  * igt@gem_eio@unwedge-stress:
- shard-dg2:  [PASS][6] -> [FAIL][7] ([i915#5784])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-dg2-1/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-12/igt@gem_...@unwedge-stress.html
- shard-snb:  NOTRUN -> [FAIL][8] ([i915#8898])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-snb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-tglu-2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-rkl-4/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fence@concurrent:
- shard-dg2:  NOTRUN -> [SKIP][13] ([i915#4812])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@gem_exec_fe...@concurrent.html

  * igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-dg2:  NOTRUN -> [SKIP][14] ([i915#3539] / [i915#4852])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html

  * igt@gem_exec_reloc@basic-wc-read:
- shard-dg2:  NOTRUN -> [SKIP][15] ([i915#3281])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@gem_exec_re...@basic-wc-read.html

  * igt@gem_exec_schedule@reorder-wide:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#4537] / [i915#4812])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/shard-dg2-2/igt@gem_exec_sched...@reorder-wide.html

  * igt@gem_fenced_exec_thrash@no-spare-fences-interruptible:
- shard-dg2:  NOTRUN -> [SKIP][17] ([i915#4860])
   [17]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Update AUX invalidation sequence (rev7)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev7)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_119798v7


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-blb-e6850:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@load:
- bat-rpls-1: [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-rpls-1/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-rpls-1/igt@i915_module_l...@load.html
- bat-adlp-6: [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adlp-6/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-adlp-6/igt@i915_module_l...@load.html
- bat-adls-5: [PASS][7] -> [ABORT][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adls-5/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-adls-5/igt@i915_module_l...@load.html
- bat-dg1-5:  [PASS][9] -> [ABORT][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg1-5/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-dg1-5/igt@i915_module_l...@load.html
- bat-dg1-7:  [PASS][11] -> [ABORT][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg1-7/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-dg1-7/igt@i915_module_l...@load.html
- bat-adlp-9: [PASS][13] -> [ABORT][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adlp-9/igt@i915_module_l...@load.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-adlp-9/igt@i915_module_l...@load.html
- bat-dg2-11: [PASS][15] -> [ABORT][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg2-11/igt@i915_module_l...@load.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-dg2-11/igt@i915_module_l...@load.html
- bat-adln-1: [PASS][17] -> [ABORT][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adln-1/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-adln-1/igt@i915_module_l...@load.html
- bat-adlm-1: [PASS][19] -> [ABORT][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adlm-1/igt@i915_module_l...@load.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-adlm-1/igt@i915_module_l...@load.html
- fi-tgl-1115g4:  [PASS][21] -> [ABORT][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-tgl-1115g4/igt@i915_module_l...@load.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/fi-tgl-1115g4/igt@i915_module_l...@load.html
- bat-atsm-1: [PASS][23] -> [ABORT][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-atsm-1/igt@i915_module_l...@load.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-atsm-1/igt@i915_module_l...@load.html
- bat-dg2-9:  [PASS][25] -> [ABORT][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg2-9/igt@i915_module_l...@load.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-dg2-9/igt@i915_module_l...@load.html
- bat-rpls-2: [PASS][27] -> [ABORT][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-rpls-2/igt@i915_module_l...@load.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119798v7/bat-rpls-2/igt@i915_module_l...@load.html
- bat-dg2-8:  [PASS][29] -> [ABORT][30]
   [29]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update AUX invalidation sequence (rev7)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev7)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update AUX invalidation sequence (rev7)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev7)
URL   : https://patchwork.freedesktop.org/series/119798/
State : warning

== Summary ==

Error: dim checkpatch failed
340830609d2b drm/i915/gt: Cleanup aux invalidation registers
5999b07cb5c4 drm/i915: Add the has_aux_ccs device property
38a4e26e5db5 drm/i915/gt: Ensure memory quiesced before invalidation
c65da5ab7d41 drm/i915/gt: Rename flags with bit_group_X according to the 
datasheet
e2ea44c109c1 drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single 
function
fe1a4250b533 drm/i915/gt: Ensure memory quiesced before invalidation for all 
engines
-:7: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id 'af9e423a8aae', maybe rebased 
or not pulled?
#7: 
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before

total: 0 errors, 1 warnings, 0 checks, 55 lines checked
e45ab12c8520 drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
-:96: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#96: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:302:
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
  ^

total: 0 errors, 0 warnings, 1 checks, 69 lines checked
2c1334aac310 drm/i915/gt: Poll aux invalidation register bit on invalidation
f316791f8e87 drm/i915/gt: Support aux invalidation on all engines




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix connector HPD polling

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix connector HPD polling
URL   : https://patchwork.freedesktop.org/series/121050/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_121050v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [PASS][2] -> [DMESG-WARN][3] ([i915#8937])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: NOTRUN -> [FAIL][4] ([fdo#103375]) +5 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [ABORT][6] ([i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
- fi-kbl-soraka:  [PASS][9] -> [DMESG-FAIL][10] ([i915#5334] / 
[i915#7872])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][11] ([i915#8937]) +22 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][12] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][13] ([i915#6367])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][14] ([i915#6367] / [i915#8937])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: NOTRUN -> [DMESG-WARN][15] ([i915#6367])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-mtlp-8: NOTRUN -> [DMESG-FAIL][16] ([fdo#103375])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][18] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#7828])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][21] ([i915#1845] / [i915#5354]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121050v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * 

[Intel-gfx] [PR] GuC 70.8 for MTL and DG2 + HuC 8.5.1 for MTL

2023-07-20 Thread Daniele Ceraolo Spurio
The following changes since commit d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d:

  Partially revert "amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5" (2023-07-07 
15:24:32 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware dg2_mtl_guc_70.8

for you to fetch changes up to 6f3a37f47d68d5e2108b98a900e4be910e8c7106:

  i915: update DG2 GuC to v70.8.0 (2023-07-20 10:14:57 -0700)


Daniele Ceraolo Spurio (2):
  i915: update to GuC 70.8.0 and HuC 8.5.1 for MTL
  i915: update DG2 GuC to v70.8.0

 WHENCE   |   6 +++---
 i915/dg2_guc_70.bin  | Bin 369600 -> 385856 bytes
 i915/mtl_guc_70.bin  | Bin 303936 -> 308032 bytes
 i915/mtl_huc_gsc.bin | Bin 565248 -> 569344 bytes
 4 files changed, 3 insertions(+), 3 deletions(-)


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix connector HPD polling

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix connector HPD polling
URL   : https://patchwork.freedesktop.org/series/121050/
State : warning

== Summary ==

Error: dim sparse failed
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 connector HPD polling

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix connector HPD polling
URL   : https://patchwork.freedesktop.org/series/121050/
State : warning

== Summary ==

Error: dim checkpatch failed
c3343063ec23 drm/i915: Avoid endless HPD poll detect loop via runtime 
suspend/resume
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect 
cycle")

-:44: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use 
'Link:' or 'Closes:' instead
#44: 
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403

total: 0 errors, 2 warnings, 0 checks, 82 lines checked
87c4cc16c75e drm: Add an HPD poll helper to reschedule the poll work
3573005acea3 drm/i915: Fix HPD polling, reenabling the output poll work as 
needed
32d8d0db4836 drm/i915: Don't change the status of forced connectors during 
hotplug detect
6aadfef5ec03 drm/i915: Don't change the status of forced connectors during HPD 
poll detect




Re: [Intel-gfx] [RFC v5 00/17] DRM cgroup controller with scheduling control and memory stats

2023-07-20 Thread T.J. Mercier
On Thu, Jul 20, 2023 at 3:55 AM Tvrtko Ursulin
 wrote:
>
>
> Hi,
>
> On 19/07/2023 21:31, T.J. Mercier wrote:
> > On Wed, Jul 12, 2023 at 4:47 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>drm.memory.stat
> >>  A nested file containing cumulative memory statistics for the 
> >> whole
> >>  sub-hierarchy, broken down into separate GPUs and separate memory
> >>  regions supported by the latter.
> >>
> >>  For example::
> >>
> >>$ cat drm.memory.stat
> >>card0 region=system total=12898304 shared=0 active=0 
> >> resident=12111872 purgeable=167936
> >>card0 region=stolen-system total=0 shared=0 active=0 resident=0 
> >> purgeable=0
> >>
> >>  Card designation corresponds to the DRM device names and multiple 
> >> line
> >>  entries can be present per card.
> >>
> >>  Memory region names should be expected to be driver specific with 
> >> the
> >>  exception of 'system' which is standardised and applicable for 
> >> GPUs
> >>  which can operate on system memory buffers.
> >>
> >>  Sub-keys 'resident' and 'purgeable' are optional.
> >>
> >>  Per category region usage is reported in bytes.
> >>
> >>   * Feedback from people interested in drm.active_us and drm.memory.stat is
> >> required to understand the use cases and their usefulness (of the 
> >> fields).
> >>
> >> Memory stats are something which was easy to add to my series, since I 
> >> was
> >> already working on the fdinfo memory stats patches, but the question 
> >> is how
> >> useful it is.
> >>
> > Hi Tvrtko,
> >
> > I think this style of driver-defined categories for reporting of
> > memory could potentially allow us to eliminate the GPU memory tracking
> > tracepoint used on Android (gpu_mem_total). This would involve reading
> > drm.memory.stat at the root cgroup (I see it's currently disabled on
>
> I can put it available under root too, don't think there is any
> technical reason to not have it. In fact, now that I look at it again,
> memory.stat is present on root so that would align with my general
> guideline to keep the two as similar as possible.
>
> > the root), which means traversing the whole cgroup tree under the
> > cgroup lock to generate the values on-demand. This would be done
> > rarely, but I still wonder what the cost of that would turn out to be.
>
> Yeah that's ugly. I could eliminate cgroup_lock by being a bit smarter.
> Just didn't think it worth it for the RFC.
>
> Basically to account memory stats for any sub-tree I need the equivalent
> one struct drm_memory_stats per DRM device present in the hierarchy. So
> I could pre-allocate a few and restart if run out of spares, or
> something. They are really small so pre-allocating a good number, based
> on past state or something, should would good enough. Or even total
> number of DRM devices in a system as a pessimistic and safe option for
> most reasonable deployments.
>
> > The drm_memory_stats categories in the output don't seem like a big
> > value-add for this use-case, but no real objection to them being
>
> You mean the fact there are different categories is not a value add for
> your use case because you would only use one?
>
Exactly, I guess that'd be just "private" (or pick another one) for
the driver-defined "regions" where
shared/private/resident/purgeable/active aren't really applicable.
That doesn't seem like a big problem to me since you already need an
understanding of what a driver-defined region means. It's just adding
a requirement to understand what fields are used, and a driver can
document that in the same place as the region itself. That does mean
performing arithmetic on values from different drivers might not make
sense. But this is just my perspective from trying to fit the
gpu_mem_total tracepoint here. I think we could probably change the
way drivers that use it report memory to fit closer into the
drm_memory_stats categories.

> The idea was to align 1:1 with DRM memory stats fdinfo and somewhat
> emulate how memory.stat also offers a breakdown.
>
> > there. I know it's called the DRM cgroup controller, but it'd be nice
> > if there were a way to make the mem tracking part work for any driver
> > that wishes to participate as many of our devices don't use a DRM
> > driver. But making that work doesn't look like it would fit very
>
> Ah that would be a challenge indeed to which I don't have any answers
> right now.
>
> Hm if you have a DRM device somewhere in the chain memory stats would
> still show up. Like if you had a dma-buf producer which is not a DRM
> driver, but then that buffer was imported by a DRM driver, it would show
> up in a cgroup. Or vice-versa. But if there aren't any in the whole
> chain then it would not.
>
Creating a dummy DRM driver underneath an existing driver as an
adaptation layer also came to mind, but yeah... probably not. :)

By the way I still want to try to add tracking for dma-bufs 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: use direct alias for i915 in requests (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: use direct alias for i915 in requests (rev2)
URL   : https://patchwork.freedesktop.org/series/120991/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120991v2


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 43)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@coherency:
- bat-jsl-3:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-jsl-3/igt@i915_selftest@l...@coherency.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-jsl-3/igt@i915_selftest@l...@coherency.html

  * igt@i915_selftest@live@hangcheck:
- bat-jsl-3:  [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-jsl-3/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-jsl-3/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-kbl-soraka/igt@kms_b...@basic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [PASS][6] -> [DMESG-WARN][7] ([i915#8937])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][8] -> [FAIL][9] ([i915#7940]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][10] -> [FAIL][11] ([i915#7940])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][12] -> [DMESG-FAIL][13] ([i915#5334])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
- fi-kbl-soraka:  [PASS][14] -> [DMESG-FAIL][15] ([i915#5334] / 
[i915#7872])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][16] ([i915#8937]) +23 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][17] -> [DMESG-FAIL][18] ([i915#8723])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][19] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [PASS][20] -> [TIMEOUT][21] ([i915#6794] / 
[i915#7392])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120991v2/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][22] ([i915#6367])
   [22]: 

Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects

2023-07-20 Thread Sripada, Radhakrishna
Hi Tvrtko,

> -Original Message-
> From: Tvrtko Ursulin 
> Sent: Thursday, July 20, 2023 2:17 AM
> To: Yang, Fei ; Sripada, Radhakrishna
> ; intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Ville Syrjälä ; 
> Wilson,
> Chris P 
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
> 
> 
> On 19/07/2023 21:53, Yang, Fei wrote:
> >> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>> Dpt objects that are created from internal get evicted when there is
> >>> memory pressure and do not get restored when pinned during scanout.
> >>> The pinned page table entries look corrupted and programming the
> >>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>
> >>> Create DPT objects from shmem and mark the object as dirty when
> >>> pinning so that the object is restored when shrinker evicts an unpinned
> buffer object.
> >>>
> >>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>
> >>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>> for dpt")
> >>> Cc:  # v6.0+
> >>> Cc: Ville Syrjälä 
> >>> Cc: Tvrtko Ursulin 
> >>> Suggested-by: Chris Wilson 
> >>> Signed-off-by: Fei Yang 
> >>> Signed-off-by: Radhakrishna Sripada 
> >>> ---
> >>>drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>>1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> >>>   i915_vma_get(vma);
> >>>   }
> >>>
> >>> +dpt->obj->mm.dirty = true;
> >>> +
> >>>   atomic_dec(>gpu_error.pending_fb_pin);
> >>>   intel_runtime_pm_put(>runtime_pm, wakeref);
> >>>
> >>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>>   dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>>   if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>>   drm_dbg_kms(>drm, "Allocating dpt from smem\n");
> >>> -dpt_obj = i915_gem_object_create_internal(i915, size);
> >>> +dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>>   }
> >>>   if (IS_ERR(dpt_obj))
> >>>   return ERR_CAST(dpt_obj);
> >>
> >> Okay I think I get it after some more looking at the DPT code paths.
> >> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >> are lost when backing store is discarded.
> >>
> >> Changing to shmem object indeed looks the easiest option.
> >>
> >> Some related thoughts:
> >>
> >> 1)
> >> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >> Could you investigate please? On a glance their job was to restore the
> >> PTEs which would be lost from internal objects backing storage. With
> >> shmem objects that content should be preserved.
> >
> > intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> > objects are mapped into, but also the framebuffer objects. I don't have
> > much knowledge on how the framebuffer objects are managed, but the
> suspend
> > resume path still look necessary to me, unless the content of these
> > framebuffer objects are also preserved.
> 
> I don't think it has anything to do with fb content, but you are correct
> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> mapping for DPT FBs across system suspend/resume") reminds me backing
> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> Even though with this patch internal is out of the picture, stolen
> remains and so the issue of losing the page table content remains.
> Perhaps resume could be optimised to only restore PTEs when VM page
> tables are backed by stolen which may win some suspend/resume speed on
> some platforms.

I will have to look into how suspend resume will change with the current flow
as you said it can be looked in a later patch.

> 
> Regards,
> 
> Tvrtko
> 
> >
> >> 2)
> >> I wonder if i915_vma_flush_writes should be used (as a companion of
> >> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
> >> then I am also not sure if it does the right thing for the
> >> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
> >> call __i915_gem_object_flush_map itself for that mapping flavour and
> >> not do the ggtt flushing in that case.
I am not sure if dpt_bind_vma will be called each time during pinning. IMO it 
gets called
Only when the fb object needs to be bind after and unbind(triggered during obj 
destroy).
Do you think if i915_vma_flush_writes should not be used if dpt objects are 
created from internal?
Or should we have a different flavor of i915_vm_pin_iomap that skips 
i915_vma_set_ggtt_write
so that we can drop i915_vma_flush_writes during unpinning 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: use direct alias for i915 in requests (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: use direct alias for i915 in requests (rev2)
URL   : https://patchwork.freedesktop.org/series/120991/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: use direct alias for i915 in requests (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: use direct alias for i915 in requests (rev2)
URL   : https://patchwork.freedesktop.org/series/120991/
State : warning

== Summary ==

Error: dim checkpatch failed
b6ff0087160e drm/i915: use direct alias for i915 in requests
-:138: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#138: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2721:
+   GEM_BUG_ON(intel_vgpu_active(rq->i915));

-:160: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#160: FILE: drivers/gpu/drm/i915/gt/intel_migrate.c:378:
+   GEM_BUG_ON(GRAPHICS_VER(rq->i915) < 8);

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




[Intel-gfx] [PATCH v6 9/9] drm/i915/gt: Support aux invalidation on all engines

2023-07-20 Thread Andi Shyti
Perform some refactoring with the purpose of keeping in one
single place all the operations around the aux table
invalidation.

With this refactoring add more engines where the invalidation
should be performed.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 58 +++-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  3 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 17 +--
 3 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index bedd1586c978f..4fab07de1ab4a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,9 +165,36 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
 }
 
-u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg)
+static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
 {
-   u32 gsi_offset = gt->uncore->gsi_offset;
+   if (!HAS_AUX_CCS(engine->i915))
+   return INVALID_MMIO_REG;
+
+   switch (engine->id) {
+   case RCS0:
+   return GEN12_CCS_AUX_INV;
+   case BCS0:
+   return GEN12_BCS0_AUX_INV;
+   case VCS0:
+   return GEN12_VD0_AUX_INV;
+   case VCS2:
+   return GEN12_VD2_AUX_INV;
+   case VECS0:
+   return GEN12_VE0_AUX_INV;
+   case CCS0:
+   return GEN12_CCS0_AUX_INV;
+   default:
+   return INVALID_MMIO_REG;
+   }
+}
+
+u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
+{
+   i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
+   u32 gsi_offset = engine->gt->uncore->gsi_offset;
+
+   if (i915_mmio_reg_valid(inv_reg))
+   return cs;
 
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
@@ -201,6 +228,11 @@ static u32 *intel_emit_pipe_control_cs(struct i915_request 
*rq, u32 bit_group_0,
return cs;
 }
 
+static bool gen12_engine_has_aux_inv(struct intel_engine_cs *engine)
+{
+   return i915_mmio_reg_valid(gen12_get_aux_inv_reg(engine));
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
@@ -307,11 +339,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
-   /* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
- GEN12_CCS_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(engine, cs);
 
*cs++ = preparser_disable(false);
intel_ring_advance(rq, cs);
@@ -322,7 +350,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
-   intel_engine_mask_t aux_inv = 0;
u32 cmd_flush = 0;
u32 cmd = 4;
u32 *cs;
@@ -330,15 +357,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915))
-   aux_inv = rq->engine->mask &
- ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-
/*
 * On Aux CCS platforms the invalidation of the Aux
 * table requires quiescing memory traffic beforehand
 */
-   if (aux_inv) {
+   if (gen12_engine_has_aux_inv(rq->engine)) {
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
 
@@ -417,14 +440,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
 
-   if (aux_inv) { /* hsdes: 1809175790 */
-   if (rq->engine->class == VIDEO_DECODE_CLASS)
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_INV);
-   else
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(rq->engine, cs);
 
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(false);
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index a44eda096557c..867ba697aceb8 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -13,6 +13,7 @@
 #include "intel_gt_regs.h"
 #include "intel_gpu_commands.h"
 
+struct intel_engine_cs;
 struct intel_gt;

[Intel-gfx] [PATCH v6 8/9] drm/i915/gt: Poll aux invalidation register bit on invalidation

2023-07-20 Thread Andi Shyti
From: Jonathan Cavitt 

For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 17 -
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 78bbd55262a2d..bedd1586c978f 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -172,7 +172,15 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
-   *cs++ = MI_NOOP;
+
+   *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
+   MI_SEMAPHORE_REGISTER_POLL |
+   MI_SEMAPHORE_POLL |
+   MI_SEMAPHORE_SAD_EQ_SDD;
+   *cs++ = 0;
+   *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
+   *cs++ = 0;
+   *cs++ = 0;
 
return cs;
 }
@@ -282,10 +290,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
+   count = 8;
if (HAS_AUX_CCS(rq->engine->i915))
-   count = 8 + 4;
-   else
-   count = 8;
+   count += 8;
 
cs = intel_ring_begin(rq, count);
if (IS_ERR(cs))
@@ -335,7 +342,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
 
-   cmd += 4;
+   cmd += 8;
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5df7cce23197c..2bd8d98d21102 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -121,6 +121,7 @@
 #define   MI_SEMAPHORE_TARGET(engine)  ((engine)<<15)
 #define MI_SEMAPHORE_WAIT  MI_INSTR(0x1c, 2) /* GEN8+ */
 #define MI_SEMAPHORE_WAIT_TOKENMI_INSTR(0x1c, 3) /* GEN12+ */
+#define   MI_SEMAPHORE_REGISTER_POLL   (1 << 16)
 #define   MI_SEMAPHORE_POLL(1 << 15)
 #define   MI_SEMAPHORE_SAD_GT_SDD  (0 << 12)
 #define   MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
-- 
2.40.1



[Intel-gfx] [PATCH v6 7/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control

2023-07-20 Thread Andi Shyti
Enable the CCS_FLUSH bit 13 in the control pipe for render and
compute engines in platforms starting from Meteor Lake (BSPEC
43904 and 47112). The VE and BCS engines need to add the flush
part in their command streamer.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Nirmoy Das 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 31 
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 3bedab8d61db1..78bbd55262a2d 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -225,6 +225,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -309,6 +316,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
intel_engine_mask_t aux_inv = 0;
+   u32 cmd_flush = 0;
u32 cmd = 4;
u32 *cs;
 
@@ -339,6 +347,13 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_CS_STALL;
 
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
   LRC_PPHWSP_SCRATCH_ADDR);
 
@@ -346,7 +361,18 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 
case VIDEO_ENHANCEMENT_CLASS:
case COMPUTE_CLASS:
+   cmd += 2;
+   cmd_flush = MI_FLUSH_DW;
+
+   break;
+
case COPY_ENGINE_CLASS:
+   cmd += 2;
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   cmd_flush = MI_FLUSH_DW | MI_FLUSH_DW_CCS;
break;
}
}
@@ -355,6 +381,11 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (IS_ERR(cs))
return PTR_ERR(cs);
 
+   if (cmd_flush) {
+   *cs++ = cmd_flush;
+   *cs++ = 0;
+   }
+
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(true);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5d143e2a8db03..5df7cce23197c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -299,6 +299,7 @@
 #define   PIPE_CONTROL_QW_WRITE(1<<14)
 #define   PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
 #define   PIPE_CONTROL_DEPTH_STALL (1<<13)
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
 #define   PIPE_CONTROL_WRITE_FLUSH (1<<12)
 #define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH   (1<<12) /* gen6+ */
 #define   PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
-- 
2.40.1



[Intel-gfx] [PATCH v6 6/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-20 Thread Andi Shyti
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.

Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 46 ++--
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1b1dadacfbf42..3bedab8d61db1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -309,19 +309,45 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
intel_engine_mask_t aux_inv = 0;
-   u32 cmd, *cs;
+   u32 cmd = 4;
+   u32 *cs;
 
-   cmd = 4;
-   if (mode & EMIT_INVALIDATE) {
+   if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915) &&
-   (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
-   aux_inv = rq->engine->mask &
-   ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-   if (aux_inv)
-   cmd += 4;
+   if (HAS_AUX_CCS(rq->engine->i915))
+   aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+   if (aux_inv) {
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
+
+   cmd += 4;
+
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   switch (rq->engine->class) {
+   case VIDEO_DECODE_CLASS:
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
+
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
+
+   break;
+
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COMPUTE_CLASS:
+   case COPY_ENGINE_CLASS:
+   break;
}
}
 
-- 
2.40.1



[Intel-gfx] [PATCH v6 4/9] drm/i915/gt: Rename flags with bit_group_X according to the datasheet

2023-07-20 Thread Andi Shyti
In preparation of the next patch align with the datasheet (BSPEC
47112) with the naming of the pipe control set of flag values.
The variable "flags" in gen12_emit_flush_rcs() is applied as a
set of flags called Bit Group 1.

Define also the Bit Group 0 as bit_group_0 where currently only
PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Matt Roper 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 34 +---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 18 -
 2 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 5fbc3f630f32b..7566c89d9def3 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -207,7 +207,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * table requires quiescing memory traffic beforehand
 */
if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
-   u32 flags = 0;
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
int err;
u32 *cs;
 
@@ -215,32 +216,33 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
if (err)
return err;
 
-   flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_FLUSH_L3;
-   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
/* Wa_1409600907:tgl,adl-p */
-   flags |= PIPE_CONTROL_DEPTH_STALL;
-   flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
-   flags |= PIPE_CONTROL_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_ENABLE;
 
-   flags |= PIPE_CONTROL_STORE_DATA_INDEX;
-   flags |= PIPE_CONTROL_QW_WRITE;
+   bit_group_1 |= PIPE_CONTROL_STORE_DATA_INDEX;
+   bit_group_1 |= PIPE_CONTROL_QW_WRITE;
 
-   flags |= PIPE_CONTROL_CS_STALL;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
 
if (!HAS_3D_PIPELINE(engine->i915))
-   flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (engine->class == COMPUTE_CLASS)
-   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   cs = gen12_emit_pipe_control(cs,
-PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
-flags, LRC_PPHWSP_SCRATCH_ADDR);
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
intel_ring_advance(rq, cs);
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 655e5c00ddc27..a44eda096557c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -49,25 +49,29 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs);
 u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg);
 
 static inline u32 *
-__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
+__gen8_emit_pipe_control(u32 *batch, u32 bit_group_0,
+u32 bit_group_1, u32 offset)
 {
memset(batch, 0, 6 * sizeof(u32));
 
-   batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
-   batch[1] = flags1;
+   batch[0] = GFX_OP_PIPE_CONTROL(6) | bit_group_0;
+   batch[1] = bit_group_1;
batch[2] = offset;
 
return batch + 6;
 }
 
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *gen8_emit_pipe_control(u32 *batch,
+ u32 bit_group_1, u32 offset)
 {
-   return __gen8_emit_pipe_control(batch, 0, flags, offset);
+   return __gen8_emit_pipe_control(batch, 0, bit_group_1, offset);
 }
 
-static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, 
u32 offset)
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 bit_group_0,
+   

[Intel-gfx] [PATCH v6 5/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

2023-07-20 Thread Andi Shyti
Just a trivial refactoring for reducing the number of code
duplicate. This will come at handy in the next commits.

Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 7566c89d9def3..1b1dadacfbf42 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
return cs;
 }
 
+static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32 
bit_group_0,
+  u32 bit_group_1, u32 offset)
+{
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 6);
+   if (IS_ERR(cs))
+   return cs;
+
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+   intel_ring_advance(rq, cs);
+
+   return cs;
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
-   u32 *cs;
-
-   /* dummy PIPE_CONTROL + depth flush */
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-   cs = gen12_emit_pipe_control(cs,
-0,
-PIPE_CONTROL_DEPTH_CACHE_FLUSH,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
-   }
+   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
+   intel_emit_pipe_control_cs(rq,
+  0,
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH,
+  LRC_PPHWSP_SCRATCH_ADDR);
 
return 0;
 }
@@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
-   u32 *cs;
 
err = mtl_dummy_pipe_control(rq);
if (err)
@@ -237,13 +244,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-
-   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
}
 
if (mode & EMIT_INVALIDATE) {
-- 
2.40.1



[Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Ensure memory quiesced before invalidation

2023-07-20 Thread Andi Shyti
From: Jonathan Cavitt 

All memory traffic must be quiesced before requesting
an aux invalidation on platforms that use Aux CCS.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0d4d5e0407a2d..5fbc3f630f32b 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -202,7 +202,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 {
struct intel_engine_cs *engine = rq->engine;
 
-   if (mode & EMIT_FLUSH) {
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+   if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
u32 flags = 0;
int err;
u32 *cs;
-- 
2.40.1



[Intel-gfx] [PATCH v6 2/9] drm/i915: Add the has_aux_ccs device property

2023-07-20 Thread Andi Shyti
We always assumed that a device might either have AUX or FLAT
CCS, but this is an approximation that is not always true as it
requires some further per device checks.

Add the "has_aux_ccs" flag in the intel_device_info structure in
order to have a per device flag indicating of the AUX CCS.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Jonathan Cavitt 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/i915_pci.c  | 5 -
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 563efee055602..0d4d5e0407a2d 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915))
+   if (HAS_AUX_CCS(rq->engine->i915))
count = 8 + 4;
else
count = 8;
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915) &&
+   if (HAS_AUX_CCS(rq->engine->i915) &&
(rq->engine->class == VIDEO_DECODE_CLASS ||
 rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask &
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 682ef2b5c7d59..e9cc048b5727a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -848,6 +848,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  * stored in lmem to support the 3D and media compression formats.
  */
 #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
+#define HAS_AUX_CCS(i915)(INTEL_INFO(i915)->has_aux_ccs)
 
 #define HAS_GT_UC(i915)(INTEL_INFO(i915)->has_gt_uc)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fcacdc21643cf..c9ff1d11a9fce 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,8 @@ static const struct intel_device_info jsl_info = {
TGL_CACHELEVEL, \
.has_global_mocs = 1, \
.has_pxp = 1, \
-   .max_pat_index = 3
+   .max_pat_index = 3, \
+   .has_aux_ccs = 1
 
 static const struct intel_device_info tgl_info = {
GEN12_FEATURES,
@@ -775,6 +776,7 @@ static const struct intel_device_info dg2_info = {
 
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
+   .has_aux_ccs = 1,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
 };
@@ -827,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.__runtime.media.ip.ver = 13,
PLATFORM(INTEL_METEORLAKE),
.extra_gt_list = xelpmp_extra_gt,
+   .has_aux_ccs = 1,
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index dbfe6443457b5..93485507506cc 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -151,6 +151,7 @@ enum intel_ppgtt_type {
func(has_reset_engine); \
func(has_3d_pipeline); \
func(has_4tile); \
+   func(has_aux_ccs); \
func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gmd_id); \
-- 
2.40.1



[Intel-gfx] [PATCH v6 0/9] Update AUX invalidation sequence

2023-07-20 Thread Andi Shyti
Hi,

as there are new hardware directives, we need a little adaptation
for the AUX invalidation sequence.

In this version we support all the engines affected by this
change.

The stable backport has some challenges because the original
patch that this series fixes has had more changes in between.

This patch is slowly exploding with code refactorings and
features added and fixed.

Thanks a lot Nirmoy, Andrzej and Matt for your review and for the
fruitful discussions!

Thanks,
Andi

Changelog:
=
v5 -> v6
 - Fixed ccs flush in the engines VE and BCS. They are sent as a
   separate command instead of added in the pipe control.
 - Separated the CCS flusing in the pipe control patch with the
   quiescing of the memory. They were meant to be on separate
   patch already in the previous verision, but apparently I
   squashed them by mistake.

v4 -> v5
 - The AUX CCS is added as a device property instead of checking
   against FLAT CCS. This adds the new HAS_AUX_CCS check
   (Patch 2, new).
 - little and trivial refactoring here and there.
 - extended the flags{0,1}/bit_group_{0,1} renaming to other
   functions.
 - Created an intel_emit_pipe_control_cs() wrapper for submitting
   the pipe control.
 - Quiesce memory for all the engines, not just RCS (Patch 6,
   new).
 - The PIPE_CONTROL_CCS_FLUSH is added to all the engines.
 - Remove redundant EMIT_FLUSH_CCS mode flag.
 - Remove unnecessary NOOPs from the command streamer for
   invalidating the CCS table.
 - Use INVALID_MMIO_REG and gen12_get_aux_inv_reg() instad of
   __MMIO(0) and reg.reg.
 - Remove useless wrapper and just use gen12_get_aux_inv_reg().

v3 -> v4
 - A trivial patch 3 is added to rename the flags with
   bit_group_{0,1} to align with the datasheet naming.
 - Patch 4 fixes a confusion I made where the CCS flag was
   applied to the wrong bit group.

v2 -> v3
 - added r-b from Nirmoy in patch 1 and 4.
 - added patch 3 which enables the ccs_flush in the control pipe
   for mtl+ compute and render engines.
 - added redundant checks in patch 2 for enabling the EMIT_FLUSH
   flag.

v1 -> v2
 - add a clean up preliminary patch for the existing registers
 - add support for more engines
 - add the Fixes tag

Andi Shyti (7):
  drm/i915/gt: Cleanup aux invalidation registers
  drm/i915: Add the has_aux_ccs device property
  drm/i915/gt: Rename flags with bit_group_X according to the datasheet
  drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single
function
  drm/i915/gt: Ensure memory quiesced before invalidation for all
engines
  drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control
  drm/i915/gt: Support aux invalidation on all engines

Jonathan Cavitt (2):
  drm/i915/gt: Ensure memory quiesced before invalidation
  drm/i915/gt: Poll aux invalidation register bit on invalidation

 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 222 +--
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  21 +-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  16 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  17 +-
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   5 +-
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 8 files changed, 186 insertions(+), 99 deletions(-)

-- 
2.40.1



[Intel-gfx] [PATCH v6 1/9] drm/i915/gt: Cleanup aux invalidation registers

2023-07-20 Thread Andi Shyti
Fix the 'NV' definition postfix that is supposed to be INV.

Take the chance to also order properly the registers based on
their address and call the GEN12_GFX_CCS_AUX_INV address as
GEN12_CCS_AUX_INV like all the other similar registers.

Remove also VD1, VD3 and VE1 registers that don't exist and add
BCS0 and CCS0.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  8 
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  | 16 
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  6 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca1..563efee055602 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -287,8 +287,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
if (!HAS_FLAT_CCS(rq->engine->i915)) {
/* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
+ GEN12_CCS_AUX_INV);
}
 
*cs++ = preparser_disable(false);
@@ -348,10 +348,10 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (aux_inv) { /* hsdes: 1809175790 */
if (rq->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+ cs, GEN12_VD0_AUX_INV);
else
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_NV);
+ cs, GEN12_VE0_AUX_INV);
}
 
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79e..2cdfb2f713d02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -332,9 +332,11 @@
 #define GEN8_PRIVATE_PAT_HI_MMIO(0x40e0 + 4)
 #define GEN10_PAT_INDEX(index) _MMIO(0x40e0 + (index) * 4)
 #define BSD_HWS_PGA_GEN7   _MMIO(0x4180)
-#define GEN12_GFX_CCS_AUX_NV   _MMIO(0x4208)
-#define GEN12_VD0_AUX_NV   _MMIO(0x4218)
-#define GEN12_VD1_AUX_NV   _MMIO(0x4228)
+
+#define GEN12_CCS_AUX_INV  _MMIO(0x4208)
+#define GEN12_VD0_AUX_INV  _MMIO(0x4218)
+#define GEN12_VE0_AUX_INV  _MMIO(0x4238)
+#define GEN12_BCS0_AUX_INV _MMIO(0x4248)
 
 #define GEN8_RTCR  _MMIO(0x4260)
 #define GEN8_M1TCR _MMIO(0x4264)
@@ -342,14 +344,12 @@
 #define GEN8_BTCR  _MMIO(0x426c)
 #define GEN8_VTCR  _MMIO(0x4270)
 
-#define GEN12_VD2_AUX_NV   _MMIO(0x4298)
-#define GEN12_VD3_AUX_NV   _MMIO(0x42a8)
-#define GEN12_VE0_AUX_NV   _MMIO(0x4238)
-
 #define BLT_HWS_PGA_GEN7   _MMIO(0x4280)
 
-#define GEN12_VE1_AUX_NV   _MMIO(0x42b8)
+#define GEN12_VD2_AUX_INV  _MMIO(0x4298)
+#define GEN12_CCS0_AUX_INV _MMIO(0x42c8)
 #define   AUX_INV  REG_BIT(0)
+
 #define VEBOX_HWS_PGA_GEN7 _MMIO(0x4380)
 
 #define GEN12_AUX_ERR_DBG  _MMIO(0x43f4)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1b710102390bf..235f3fab60a98 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1374,7 +1374,7 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context 
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915))
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+ cs, GEN12_CCS_AUX_INV);
 
/* Wa_16014892111 */
if (IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) ||
@@ -1403,10 +1403,10 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hotplug: Reduce SHPD_FILTER to 250us (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/hotplug: Reduce SHPD_FILTER to 250us (rev3)
URL   : https://patchwork.freedesktop.org/series/120722/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120722v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [PASS][2] -> [DMESG-WARN][3] ([i915#8937])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8109u:   [PASS][4] -> [FAIL][5] ([i915#7940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8109u/igt@i915_pm_...@basic-pci-d3-state.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/fi-cfl-8109u/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][6] -> [FAIL][7] ([i915#7940]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/fi-skl-guc/igt@i915_pm_...@basic-rte.html
- fi-kbl-7567u:   [PASS][8] -> [FAIL][9] ([i915#7940])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][10] -> [FAIL][11] ([i915#7940])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][12] ([i915#8937]) +23 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][13] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][14] ([i915#6367])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][15] ([i915#6367] / [i915#8937])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: NOTRUN -> [DMESG-WARN][16] ([i915#6367])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][18] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#7828])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][21] ([i915#1845])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120722v3/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@core_auth@basic-auth:
- bat-mtlp-6: [DMESG-WARN][22] ([i915#8937]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@core_a...@basic-auth.html
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix premature release of request's reusable memory (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix premature release of request's reusable memory (rev3)
URL   : https://patchwork.freedesktop.org/series/120170/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120170v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [PASS][1] -> [DMESG-WARN][2] ([i915#8937])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-guc: [PASS][3] -> [FAIL][4] ([i915#7940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-7567u:   [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-tgl-1115g4:  [PASS][7] -> [FAIL][8] ([i915#7940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
- fi-cfl-8700k:   [PASS][9] -> [FAIL][10] ([i915#7940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][11] ([i915#8937]) +23 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-11: [PASS][12] -> [INCOMPLETE][13] ([i915#7913])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][14] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][15] ([i915#6367] / [i915#8937])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: NOTRUN -> [DMESG-WARN][16] ([i915#6367])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][18] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][20] ([i915#1845] / [i915#5354]) +3 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
 Possible fixes 

  * igt@core_auth@basic-auth:
- bat-mtlp-6: [DMESG-WARN][21] ([i915#8937]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@core_a...@basic-auth.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120170v3/bat-mtlp-6/igt@core_a...@basic-auth.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8700k:   [FAIL][23] ([i915#7940]) -> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-20 Thread Nathan Chancellor
On Thu, Jul 20, 2023 at 09:43:05AM +0100, Tvrtko Ursulin wrote:
> 
> On 18/07/2023 22:44, Nathan Chancellor wrote:
> > A proposed update to clang's -Wconstant-logical-operand to warn when the
> > left hand side is a constant shows the following instance in
> > nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
> > such as CONFIG_HZ=300:
> > 
> >drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: warning: use of logical 
> > '&&' with constant operand [-Wconstant-logical-operand]
> >  189 | if (NSEC_PER_SEC % HZ &&
> >  | ~ ^
> >drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: use '&' for a 
> > bitwise operation
> >  189 | if (NSEC_PER_SEC % HZ &&
> >  |   ^~
> >  |   &
> >drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: remove constant 
> > to silence this warning
> >1 warning generated.
> > 
> > Turn this into an explicit comparison against zero to make the
> > expression a boolean to make it clear this should be a logical check,
> > not a bitwise one.
> 
> So -Wconstant-logical-operand only triggers when it is a
> constant but not zero constant? Why does that make sense is not
> a kludge to avoid too much noise?

Yes, the warning purposefully does not trigger when the constant is a 1
or 0 (as those are usually indicative of an intentional logical
operation):

https://github.com/llvm/llvm-project/blob/dfdfd306cfaf54fbc43e2d5eb36489dac3eb9976/clang/lib/Sema/SemaExpr.cpp#L13917-L13919

In this case, it is 100, so I kind of understand why this might be
ambiguous to the compiler.

> Personally, it all feels a bit over the top as a warning,
> since code in both cases should optimise away. And we may end

I do not necessarily disagree, as you can see from the differential
review that I linked in the message, but I also understand it is a fine
line to tread when writing compiler warnings between wanting to catch
as many potential problems as possible and having too much noise for
developers to sift through. I think this is erring on the side of
caution.

> up papering over it if it becomes a default.

diagtool tree tells me this warning is already on by default.

> Then again this patch IMO does make the code more readable, so

I think so too.

> I am happy to take this one via our tree. Or either give ack to
> bring it in via drm-misc-next:
> 
> Acked-by: Tvrtko Ursulin 
> 
> Let me know which route works best.

Thanks for the feedback! Either route is fine with me but if the v3d
patch is going to go in via drm-misc-next, it seems like it would not be
too much trouble to push this one with it.

Cheers,
Nathan


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix premature release of request's reusable memory (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix premature release of request's reusable memory (rev3)
URL   : https://patchwork.freedesktop.org/series/120170/
State : warning

== Summary ==

Error: dim checkpatch failed
9d8a849ef3e3 drm/i915: Fix premature release of request's reusable memory
-:189: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#189: FILE: drivers/gpu/drm/i915/i915_active.c:1089:
+   GEM_BUG_ON(prev == fence);

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix premature release of request's reusable memory (rev3)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix premature release of request's reusable memory (rev3)
URL   : https://patchwork.freedesktop.org/series/120170/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/i915_active.c:1081:9: warning: context imbalance in 
'__i915_active_fence_set' - different lock contexts for basic block




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: some clean-ups in max lane count handling code (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/tc: some clean-ups in max lane count handling code (rev2)
URL   : https://patchwork.freedesktop.org/series/120980/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120980v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#4423] / [i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@debugfs_test@read_all_entries:
- bat-mtlp-6: [PASS][2] -> [DMESG-WARN][3] ([i915#8937])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-mtlp-6/igt@debugfs_test@read_all_entries.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-mtlp-6/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][4] -> [FAIL][5] ([i915#7940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][6] -> [FAIL][7] ([i915#7940])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][8] -> [ABORT][9] ([i915#7913])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][10] ([i915#8937]) +24 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@migrate:
- bat-atsm-1: [PASS][11] -> [DMESG-FAIL][12] ([i915#7699] / 
[i915#7913])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-atsm-1/igt@i915_selftest@l...@migrate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][13] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@mman:
- bat-rpls-2: NOTRUN -> [TIMEOUT][14] ([i915#6794] / [i915#7392])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-2/igt@i915_selftest@l...@mman.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][15] ([i915#6367])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [WARN][16] ([i915#8747])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][18] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#7828])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][21] ([i915#1845])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120980v2/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [SKIP][22] ([i915#1072]) +2 similar issues
   [22]: 

Re: [Intel-gfx] [PATCH v6 6/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-20 Thread Andi Shyti
Hi Nirmoy,

> +   if (aux_inv) {
> +   u32 bit_group_0 = 0;
> +   u32 bit_group_1 = 0;
> +
> +   cmd += 4;
> +
> +   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
> +
> +   switch (rq->engine->class) {
> +   case VIDEO_DECODE_CLASS:
> +   bit_group_1 |= 
> PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> +   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> +   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> +   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
> +   bit_group_1 |= PIPE_CONTROL_CS_STALL;
> +
> +   intel_emit_pipe_control_cs(rq, bit_group_0, 
> bit_group_1,
> +  
> LRC_PPHWSP_SCRATCH_ADDR);
> 
> 
> I think pipe control is only for compute and render engines.
> 
> +
> +   break;
> +
> +   case VIDEO_ENHANCEMENT_CLASS:
> +   case COMPUTE_CLASS:
> 
> Don't think gen12_emit_flush_xcs() will get called for compute engine.
> 
> intel_guc_submission_setup() --> rcs_submission_override() replaces
> gen12_emit_flush_xcs() with gen12_emit_flush_rcs()
> 
> for compute and render.

yes, I made some confusion here... this part is bogus... will try
to clean things up and try again.

Andi


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tc: some clean-ups in max lane count handling code (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: drm/i915/tc: some clean-ups in max lane count handling code (rev2)
URL   : https://patchwork.freedesktop.org/series/120980/
State : warning

== Summary ==

Error: dim checkpatch failed
5fc8008c4eed drm/i915/tc: rename mtl_tc_port_get_pin_assignment_mask()
-:6: WARNING:TYPO_SPELLING: 'assigment' may be misspelled - perhaps 
'assignment'?
#6: 
This function doesn't really return the pin assigment mask, but the
^

total: 0 errors, 1 warnings, 0 checks, 16 lines checked
376b39b1236b drm/i915/tc: make intel_tc_port_get_lane_mask() static
e81351544b4b drm/i915/tc: move legacy code out of the main _max_lane_count() 
func
b1e3a475153c drm/i915/tc: remove "fia" from intel_tc_port_fia_max_lane_count()




[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "Revert "drm/i915: Hold reference to intel_context over life of i915_request"" (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Revert "Revert "drm/i915: Hold reference to intel_context over life of 
i915_request"" (rev2)
URL   : https://patchwork.freedesktop.org/series/120990/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120990v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-guc: [PASS][1] -> [FAIL][2] ([i915#7691])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-x1275:   [PASS][3] -> [SKIP][4] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][5] -> [FAIL][6] ([i915#7940])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-tgl-1115g4:  [PASS][7] -> [FAIL][8] ([i915#7940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
- fi-cfl-8700k:   [PASS][9] -> [FAIL][10] ([i915#7940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][11] ([i915#8937]) +24 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[PASS][12] -> [ABORT][13] ([i915#6217])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][14] -> [DMESG-WARN][15] ([i915#7699])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][16] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][17] ([i915#6367])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#6645])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#7828])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][21] -> [ABORT][22] ([i915#8442] / [i915#8668])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][23] ([i915#1845])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v2/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 

Re: [Intel-gfx] [PATCH v3] drm/i915: Refactor PAT/object cache handling

2023-07-20 Thread Tvrtko Ursulin



[Here let me just focus on the points which did not get further discussion in 
follow ups yet.]

On 19/07/2023 23:31, Matt Roper wrote:

On Wed, Jul 19, 2023 at 01:37:30PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries to improve upon.

Principal change is to invert the per platform cache level to PAT index
table which was added by the referenced commit, and by doing so enable
i915 to understand the cache mode between PAT indices, changing them from
opaque to transparent.

Once we have the inverted table we are able to remove the hidden false
"return true" from i915_gem_object_has_cache_level.

Other changes/fixes/improvements we are able to do:

1)
Replace the enum i915_cache_level with i915_cache_t, composed of a more
detailed representation of each cache mode (base mode plus flags).

For instance this way we are able to express the difference between WB and
1-way coherent WB on Meteorlake. Which in turn enables us to map the i915
"cached" mode to the correct Meteorlake PAT index.

2)
We can cache PAT indices of the caching modes used by the driver itself in
struct drm_i915_private, which eliminates the runtime calls to
i915_gem_get_pat_index from both high- and low-level i915 components.

3)
We can also cache the caching modes used by the driver for coherent
access and for display buffers.

4)
Remove the incorrect references to enum i915_cache_level from low level
PTE encode vfuncs, since those are actually given PAT indices by their
callers.

5)
Because i915 now understands PAT indices, we can remove the overly
aggressive flushing triggered from i915_gem_object_can_bypass_llc() and
limit it to non-coherent write-back mode only.

6)
Finally we are able to replace the platform dependent cache mode to string
code in debugfs and elsewhere by the single implementation based on
i915_cache_t.

v2:
  * Fix PAT-to-cache-mode table for PVC. (Fei)
  * Cache display caching mode too. (Fei)
  * Improve and document criteria in i915_gem_object_can_bypass_llc() (Matt)

v3:
  * Checkpath issues.
  * Cache mode flags check fixed.

Signed-off-by: Tvrtko Ursulin 
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Cc: Chris Wilson 
Cc: Fei Yang 
Cc: Andi Shyti 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../drm/i915/display/intel_plane_initial.c|   3 +-
  drivers/gpu/drm/i915/gem/i915_gem_domain.c|  56 ---
  drivers/gpu/drm/i915/gem/i915_gem_domain.h|   5 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  13 +-
  drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   4 +-
  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  12 +-
  drivers/gpu/drm/i915/gem/i915_gem_object.c| 152 +++---
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  11 +-
  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 116 +
  drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   8 +-
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  11 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  44 ++---
  drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
  .../drm/i915/gem/selftests/huge_gem_object.c  |   4 +-
  .../gpu/drm/i915/gem/selftests/huge_pages.c   |   6 +-
  drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  19 +--
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
  drivers/gpu/drm/i915/gt/intel_ggtt.c  |  33 ++--
  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   4 +-
  drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
  drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +-
  drivers/gpu/drm/i915/gt/intel_migrate.c   |  11 +-
  drivers/gpu/drm/i915/gt/intel_ppgtt.c |   6 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c   |   4 +-
  drivers/gpu/drm/i915/gt/intel_timeline.c  |   2 +-
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
  drivers/gpu/drm/i915/gt/selftest_migrate.c|   9 +-
  drivers/gpu/drm/i915/gt/selftest_reset.c  |  14 +-
  drivers/gpu/drm/i915/gt/selftest_tlb.c|   5 +-
  .../gpu/drm/i915/gt/selftest_workarounds.c|   2 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   8 +-
  drivers/gpu/drm/i915/i915_cache.c |  91 +++
  drivers/gpu/drm/i915/i915_cache.h |  60 +++
  drivers/gpu/drm/i915/i915_debugfs.c   |  53 +-
  drivers/gpu/drm/i915/i915_driver.c|   5 +
  drivers/gpu/drm/i915/i915_drv.h   |   5 +
  drivers/gpu/drm/i915/i915_gem.c   |  21 +--
  drivers/gpu/drm/i915/i915_gpu_error.c |   7 +-
  drivers/gpu/drm/i915/i915_pci.c   |  82 +-
  drivers/gpu/drm/i915/i915_perf.c  |   2 +-
  drivers/gpu/drm/i915/intel_device_info.h  

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "Revert "drm/i915: Hold reference to intel_context over life of i915_request"" (rev2)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Revert "Revert "drm/i915: Hold reference to intel_context over life of 
i915_request"" (rev2)
URL   : https://patchwork.freedesktop.org/series/120990/
State : warning

== Summary ==

Error: dim checkpatch failed
ca8235c2712c Revert "Revert "drm/i915: Hold reference to intel_context over 
life of i915_request""
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#21: 
i915 :00:02.0: [drm:i915_drop_caches_set [i915]] Dropping caches: 
0x005c [0x005c]

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




Re: [Intel-gfx] [PATCH v3] drm/i915: Refactor PAT/object cache handling

2023-07-20 Thread Tvrtko Ursulin



On 20/07/2023 01:22, Matt Roper wrote:

On Wed, Jul 19, 2023 at 05:07:15PM -0700, Yang, Fei wrote:

[snip]

@@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct 
drm_i915_gem_object *obj)


The code change here looks accurate, but while we're here, I have a side
question about this function in general...it was originally introduced
in commit 48004881f693 ("drm/i915: Mark CPU cache as dirty when used for
rendering") which states that GPU rendering ends up in the CPU cache
(and thus needs a clflush later to make sure it lands in memory).  That
makes sense to me for LLC platforms, but is it really true for non-LLC
snooping platforms (like MTL) as the commit states?


For non-LLC platforms objects can be set to 1-way coherent which means
GPU rendering ending up in CPU cache as well, so for non-LLC platform
the logic here should be checking 1-way coherent flag.


That's the part that I'm questioning (and not just for MTL, but for all
of our other non-LLC platforms too).  Just because there's coherency
doesn't mean that device writes landed in the CPU cache.  Coherency is
also achieved if device writes invalidate the contents of the CPU cache.
I thought our non-LLC snooping platforms were coherent due to
write-invalidate rather than write-update, but I can't find it
specifically documented anywhere at the moment.  If write-invalidate was
used, then there shouldn't be a need for a later clflush either.


[Trying to consolidate by doing a combined reply to the discussion so far.]

On the write-invalidate vs write-update I don't know. If you did not 
find it in bspec then I doubt I would. I can have a browse still.



My understanding
was that snooping platforms just invalidated the CPU cache to prevent
future CPU reads from seeing stale data but didn't actually stick any
new data in there?  Am I off track or is the original logic of this
function not quite right?

Anyway, even if the logic of this function is wrong, it's a mistake that
would only hurt performance


Yes, this logic will introduce performance impact because it's missing the
checking for obj->pat_set_by_user. For objects with pat_set_by_user==true,
even if the object is snooping or 1-way coherent, we don't want to enforce
a clflush here since the coherency is supposed to be handled by user space.


What should I add you think to fix it?

Add a check for non-coherent WB in gpu_write_needs_clflush as an 
additional condition for returning false?


And then if Matt is correct write-invalidate is used also !HAS_LLC 
should just return false?



(flushing more often than we truly need to)
rather than functionality, so not something we really need to dig into
right now as part of this patch.


  if (IS_DGFX(i915))
  return false;

-/*
- * For objects created by userspace through GEM_CREATE with pat_index
- * set by set_pat extension, i915_gem_object_has_cache_level() will
- * always return true, because the coherency of such object is managed
- * by userspace. Othereise the call here would fall back to checking
- * whether the object is un-cached or write-through.
- */
-return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
- i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
+return i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_UC) != 1 &&
+   i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WT) != 1;
  }


[snip]

@@ -640,15 +640,9 @@ static inline int use_cpu_reloc(const struct reloc_cache 
*cache,
  if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
  return false;

-/*
- * For objects created by userspace through GEM_CREATE with pat_index
- * set by set_pat extension, i915_gem_object_has_cache_level() always
- * return true, otherwise the call would fall back to checking whether
- * the object is un-cached.
- */
  return (cache->has_llc ||
  obj->cache_dirty ||
-!i915_gem_object_has_cache_level(obj, I915_CACHE_NONE));
+i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_UC) != 1);


Platforms with relocations and platforms with user-specified PAT have no
overlap, right?  So a -1 return should be impossible here and this is
one case where we could just treat the return value as a boolean, right?




Hm no, or maybe. My thinking behind tri-state is to allow a safe option 
for "don't know". In case PAT index to cache mode table is not fully 
populated on some future platform.



My understanding is that the condition here means to say that, if GPU
access is uncached, don't use CPU reloc because the CPU cache might
contain stale data. This condition is sufficient for snooping platforms.
But from MTL onward, the condition show be whether the GPU access is
coherent with CPU. So, we should be checking 1-way coherent flag instead
of UC mode, because even if the GPU access is WB, it's still non-coherent,
thus CPU cache could be out-dated.


Honestly the matrix of caching decision/logic 

[Intel-gfx] ✓ Fi.CI.BAT: success for Add DSC PPS readout (rev4)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Add DSC PPS readout (rev4)
URL   : https://patchwork.freedesktop.org/series/120456/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13399 -> Patchwork_120456v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][2] -> [FAIL][3] ([i915#7940]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/fi-skl-guc/igt@i915_pm_...@basic-rte.html
- bat-adlp-9: [PASS][4] -> [ABORT][5] ([i915#7977] / [i915#8668])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/bat-adlp-9/igt@i915_pm_...@basic-rte.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-adlp-9/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][6] -> [FAIL][7] ([i915#7940])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/fi-cfl-8700k/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][8] -> [DMESG-FAIL][9] ([i915#5334] / 
[i915#7872])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][10] ([i915#8937]) +23 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-mtlp-8/igt@i915_selftest@live@guc_multi_lrc.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][11] ([i915#7699] / [i915#8504] 
/ [i915#8937])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][12] ([i915#6367])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-mtlp-8: NOTRUN -> [DMESG-WARN][13] ([i915#6367] / [i915#8937])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: NOTRUN -> [DMESG-WARN][14] ([i915#6367])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#6645])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: NOTRUN -> [ABORT][16] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#7828])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#7828])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][19] ([i915#1845] / [i915#5354]) +3 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][20] ([i915#1845])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v4/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8700k:   [FAIL][21] ([i915#7940]) -> [PASS][22] +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13399/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
   [22]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add DSC PPS readout (rev4)

2023-07-20 Thread Patchwork
== Series Details ==

Series: Add DSC PPS readout (rev4)
URL   : https://patchwork.freedesktop.org/series/120456/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+drivers/gpu/drm/i915/display/intel_display_types.h:1884:17: warning: 
unreplaced symbol 'encoder'
+drivers/gpu/drm/i915/display/intel_display_types.h:1884:9: warning: 

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

2023-07-20 Thread Andrzej Hajda

On 20.07.2023 11:36, Tvrtko Ursulin wrote:


On 19/07/2023 23:54, Matt Roper wrote:

On Wed, Jul 19, 2023 at 08:28:12AM -0700, Matt Roper wrote:

On Wed, Jul 19, 2023 at 09:01:58AM +0100, Tvrtko Ursulin wrote:


On 18/07/2023 23:27, Matt Roper wrote:

Several workarounds are guarded by IS_MTL_GRAPHICS_STEP.  However none
of these workarounds are actually tied to MTL as a platform; they only
relate to the Xe_LPG graphics IP, regardless of what platform it 
appears

in.  At the moment MTL is the only platform that uses Xe_LPG with IP
versions 12.70 and 12.71, but we can't count on this being true in the
future.  Switch these to use a new IS_GFX_IPVER_STEP() macro instead
that is purely based on IP version.  IS_GFX_IPVER_STEP() is also
GT-based rather than device-based, which will help prevent mistakes
where we accidentally try to apply Xe_LPG graphics workarounds to the
Xe_LPM+ media GT.

Signed-off-by: Matt Roper 
---
   .../drm/i915/display/skl_universal_plane.c    |  4 +-
   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 ++--
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c    |  4 +-
   drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
   drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 52 
++-

   drivers/gpu/drm/i915/gt/uc/intel_guc.c    |  2 +-
   .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
   drivers/gpu/drm/i915/i915_drv.h   |  8 +--
   9 files changed, 46 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c

index 6b01a0b68b97..c13e64fd 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2169,8 +2169,8 @@ static bool skl_plane_has_rc_ccs(struct 
drm_i915_private *i915,

    enum pipe pipe, enum plane_id plane_id)
   {
   /* Wa_14017240301 */
-    if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-    IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+    if (IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, 
STEP_B0) ||
+    IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, 
STEP_B0))


Do we really need/want a combined/long macro like this and not split 
it out

to something like a more readable IS_GFX_IPVER && IS_<...>_STEP?


On this part, wouldn't that make it less readable?  Right now these
conditions are an ||'d list of cases for which the workaround should
apply (relating to various entries in the workaround database).  If we
split the version, stepping, and GT checks out into separate macros
we'll get more complex conditions that are a mix of && and ||.  We can
try that, but my gut feeling is that it's going to be more error-prone
since we'll have to be really careful to always get the parenentheses in
the right places.  Also many people (myself included) are already having
some trouble adjusting to the new idea of GT (primary vs media) being an
important factor that needs to be considered in the workaround
condition; one of the goals with these new macros was to make sure that
got included in the macro so that it couldn't be omitted by accident.


Oh well I don't know.. maybe. It's just that I find that as amount of 
all uppercase blocks grows over a certain limit things become quite an 
eyesore and hard to read. One line of:


if (IS_GFX_IPVER_STEP(i915, IP_VER(12,70), STEP_A0, STEP_B0))

Is already borderline. A few of those on the same line is just hard to 
parse. But your argument also has merit so again, don't know.


What I was suggesting is to maybe have:

IS_GFX_IPVER_STEP(i915, IP_VER(12,70), IP_STEP(A0, B0))

Marginally shorter.

Maybe find a shorted name for IS_GFX_IPVER_STEP?

IS_GFX_IP(i915, IP_VER(12,70), IP_STEP(A0, B0))

?

Too bad we can't have that macro take the stepping argument as optional. 
Or maybe it is possible, I don't know C macro magic that well.


It is possible:

#define IS_GFX_IP(i915, ver, args...) IS_GFX_IP_STEP(i915, ver, args, 
default_step)

#define IS_GFX_IP_STEP(i915, ver, step, ...) definition_ignoring_elipsis

Assuming IP_STEP is just single value.

I am not sure about meaning of steppings in i915, it looks somehow 
special. If it is just another dot in version MAJOR.MINOR.STEP, why not 
extend IP_VER with stepping (ver << 16 & rel << 8 & step):

IP_VER(12)
IP_VER(12,70)
IP_VER(12, 70, A0)

then for example:
IS_IP_VER(gt, IP_VER(12))
IS_IP_VER(gt, IP_VER(12), IP_VER(13))
IS_IP_REL(gt, IP_VER(12, 70))
IS_IP_REL(gt, IP_VER(12, 70), IP_VER(12, 71))
IS_IP_STEP(gt, IP_VER(12, 70, A0))
IS_IP_STEP(gt, IP_VER(12, 70, A0), IP_VER(12, 70, B0))

Regards
Andrzej




Also, if we added GT based macros we could get away with encoding the GT 
type in the macro name. Asking the GT/tile directrly about their IP_VER. 
Not sure how widely applicable tha would be so just a thought.


IS_IP(gt, IP_VER(12, 70))

GT_VER_FULL(gt) == IP_VER(13, 0)

Unless 

[Intel-gfx] [PATCH v2 5/5] drm/i915: Don't change the status of forced connectors during HPD poll detect

2023-07-20 Thread Imre Deak
As described in the previous patch a connector shouldn't change its
status while it's forced to a connected/disconnected state. This can
still happen while running the connector detect function to account for
lost HPD events in a low-power state.

Fix this by reusing the connector detect function which handles a
hotplug event and prevents updating the status for forced connectors as
expected.

Testcase: igt@kms_force_connector_basic@force-connector-state
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 57 ++--
 1 file changed, 53 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 1f6fa3f994feb..e8562f6f8bb44 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -260,9 +260,8 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
intel_runtime_pm_put(_priv->runtime_pm, wakeref);
 }
 
-enum intel_hotplug_state
-intel_encoder_hotplug(struct intel_encoder *encoder,
- struct intel_connector *connector)
+static enum intel_hotplug_state
+intel_hotplug_detect_connector(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
enum drm_connector_status old_status;
@@ -294,6 +293,13 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
return INTEL_HOTPLUG_UNCHANGED;
 }
 
+enum intel_hotplug_state
+intel_encoder_hotplug(struct intel_encoder *encoder,
+ struct intel_connector *connector)
+{
+   return intel_hotplug_detect_connector(connector);
+}
+
 static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
 {
return intel_encoder_is_dig_port(encoder) &&
@@ -634,6 +640,49 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
spin_unlock_irq(_priv->irq_lock);
 }
 
+static void i915_hpd_poll_detect_connectors(struct drm_i915_private *i915)
+{
+   struct drm_connector_list_iter conn_iter;
+   struct intel_connector *connector;
+   struct intel_connector *first_changed_connector = NULL;
+   int changed = 0;
+
+   mutex_lock(>drm.mode_config.mutex);
+
+   if (!i915->drm.mode_config.poll_enabled)
+   goto out;
+
+   drm_connector_list_iter_begin(>drm, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
+   if (!(connector->base.polled & DRM_CONNECTOR_POLL_HPD))
+   continue;
+
+   if (intel_hotplug_detect_connector(connector) != 
INTEL_HOTPLUG_CHANGED)
+   continue;
+
+   changed++;
+
+   if (changed == 1) {
+   drm_connector_get(>base);
+   first_changed_connector = connector;
+   }
+   }
+   drm_connector_list_iter_end(_iter);
+
+out:
+   mutex_unlock(>drm.mode_config.mutex);
+
+   if (!changed)
+   return;
+
+   if (changed == 1)
+   
drm_kms_helper_connector_hotplug_event(_changed_connector->base);
+   else
+   drm_kms_helper_hotplug_event(>drm);
+
+   drm_connector_put(_changed_connector->base);
+}
+
 static void i915_hpd_poll_init_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
@@ -687,7 +736,7 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
 * in the middle of disabling polling
 */
if (!enabled) {
-   drm_helper_hpd_irq_event(_priv->drm);
+   i915_hpd_poll_detect_connectors(dev_priv);
 
intel_display_power_put(dev_priv,
POWER_DOMAIN_DISPLAY_CORE,
-- 
2.37.2



[Intel-gfx] [PATCH v2 4/5] drm/i915: Don't change the status of forced connectors during hotplug detect

2023-07-20 Thread Imre Deak
DRM display connectors forced to a connected/disconnected state via the
drm_connector::force member shouldn't change their status. Atm, this can
still happen in the connector's detect function when called to handle a
hotplug event. This in turn may lead to the GETCONNECTOR ioctl to report
the incorrect state if it's called to return the connector properties
without doing an actual detection (by calling the ioctl with a non-zero
drm_mode_get_connector::count_modes).

Fix the above by updating the connector state during hotplug detect only
if the connector state is not forced.

Testcase: igt@kms_force_connector_basic@force-connector-state
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index d9f0ab1d953b9..1f6fa3f994feb 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -267,14 +267,16 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
struct drm_device *dev = connector->base.dev;
enum drm_connector_status old_status;
u64 old_epoch_counter;
+   int status;
bool ret = false;
 
drm_WARN_ON(dev, !mutex_is_locked(>mode_config.mutex));
old_status = connector->base.status;
old_epoch_counter = connector->base.epoch_counter;
 
-   connector->base.status =
-   drm_helper_probe_detect(>base, NULL, false);
+   status = drm_helper_probe_detect(>base, NULL, false);
+   if (!connector->base.force)
+   connector->base.status = status;
 
if (old_epoch_counter != connector->base.epoch_counter)
ret = true;
-- 
2.37.2



[Intel-gfx] [PATCH v2 3/5] drm/i915: Fix HPD polling, reenabling the output poll work as needed

2023-07-20 Thread Imre Deak
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during runtime suspend or detecting an HPD IRQ storm).

After the above change calling drm_kms_helper_poll_enable() is a nop
after it's been called already and polling for some connectors was
disabled/re-enabled.

Fix this by calling drm_kms_helper_poll_reschedule() added in the
previous patch instead, which reschedules the work whenever expected.

Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled")
Cc: Dmitry Baryshkov 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index dd7eb9fc78610..d9f0ab1d953b9 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -212,7 +212,7 @@ intel_hpd_irq_storm_switch_to_polling(struct 
drm_i915_private *dev_priv)
 
/* Enable polling and queue hotplug re-enabling. */
if (hpd_disabled) {
-   drm_kms_helper_poll_enable(_priv->drm);
+   drm_kms_helper_poll_reschedule(_priv->drm);
mod_delayed_work(dev_priv->unordered_wq,
 _priv->display.hotplug.reenable_work,
 msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
@@ -676,7 +676,7 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
drm_connector_list_iter_end(_iter);
 
if (enabled)
-   drm_kms_helper_poll_enable(_priv->drm);
+   drm_kms_helper_poll_reschedule(_priv->drm);
 
mutex_unlock(_priv->drm.mode_config.mutex);
 
-- 
2.37.2



[Intel-gfx] [PATCH v2 2/5] drm: Add an HPD poll helper to reschedule the poll work

2023-07-20 Thread Imre Deak
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).

This is needed by the next patch fixing HPD polling on i915.

Cc: Dmitry Baryshkov 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_probe_helper.c | 68 --
 include/drm/drm_probe_helper.h |  1 +
 2 files changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 2fb9bf901a2cc..3f479483d7d80 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -262,6 +262,26 @@ static bool drm_kms_helper_enable_hpd(struct drm_device 
*dev)
 }
 
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void reschedule_output_poll_work(struct drm_device *dev)
+{
+   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
+
+   if (dev->mode_config.delayed_event)
+   /*
+* FIXME:
+*
+* Use short (1s) delay to handle the initial delayed event.
+* This delay should not be needed, but Optimus/nouveau will
+* fail in a mysterious way if the delayed event is handled as
+* soon as possible like it is done in
+* drm_helper_probe_single_connector_modes() in case the poll
+* was enabled before.
+*/
+   delay = HZ;
+
+   schedule_delayed_work(>mode_config.output_poll_work, delay);
+}
+
 /**
  * drm_kms_helper_poll_enable - re-enable output polling.
  * @dev: drm_device
@@ -279,37 +299,41 @@ static bool drm_kms_helper_enable_hpd(struct drm_device 
*dev)
  */
 void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
-   bool poll = false;
-   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
-
if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll ||
dev->mode_config.poll_running)
return;
 
-   poll = drm_kms_helper_enable_hpd(dev);
-
-   if (dev->mode_config.delayed_event) {
-   /*
-* FIXME:
-*
-* Use short (1s) delay to handle the initial delayed event.
-* This delay should not be needed, but Optimus/nouveau will
-* fail in a mysterious way if the delayed event is handled as
-* soon as possible like it is done in
-* drm_helper_probe_single_connector_modes() in case the poll
-* was enabled before.
-*/
-   poll = true;
-   delay = HZ;
-   }
-
-   if (poll)
-   schedule_delayed_work(>mode_config.output_poll_work, 
delay);
+   if (drm_kms_helper_enable_hpd(dev) ||
+   dev->mode_config.delayed_event)
+   reschedule_output_poll_work(dev);
 
dev->mode_config.poll_running = true;
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
 
+/**
+ * drm_kms_helper_poll_reschedule - reschedule the output polling work
+ * @dev: drm_device
+ *
+ * This function reschedules the output polling work, after polling for a
+ * connector has been enabled.
+ *
+ * Drivers must call this helper after enabling polling for a connector by
+ * setting %DRM_CONNECTOR_POLL_CONNECT / %DRM_CONNECTOR_POLL_DISCONNECT flags
+ * in drm_connector::polled. Note that after disabling polling by clearing 
these
+ * flags for a connector will stop the output polling work automatically if
+ * the polling is disabled for all other connectors as well.
+ *
+ * The function can be called only after polling has been enabled by calling
+ * drm_kms_helper_poll_init() / drm_kms_helper_poll_enable().
+ */
+void drm_kms_helper_poll_reschedule(struct drm_device *dev)
+{
+   if (dev->mode_config.poll_running)
+   reschedule_output_poll_work(dev);
+}
+EXPORT_SYMBOL(drm_kms_helper_poll_reschedule);
+
 static enum drm_connector_status
 drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
 {
diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
index 4977e0ab72dbb..fad3c4003b2b5 100644
--- a/include/drm/drm_probe_helper.h
+++ b/include/drm/drm_probe_helper.h
@@ -25,6 +25,7 @@ void drm_kms_helper_connector_hotplug_event(struct 
drm_connector *connector);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+void drm_kms_helper_poll_reschedule(struct drm_device *dev);
 bool drm_kms_helper_is_poll_worker(void);
 
 enum drm_mode_status drm_crtc_helper_mode_valid_fixed(struct drm_crtc *crtc,
-- 
2.37.2



[Intel-gfx] [PATCH v2 1/5] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-20 Thread Imre Deak
The issue fixed in

commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect 
cycle")

on VLV, CHV is still present on platforms where the display hotplug
detection functionality is available whenever the device is in D0 state
(hence these platforms switch to HPD polling only when the device is
runtime suspended).

The above commit avoids an endless i915_hpd_poll_init_work() ->
connector detect loop by making sure that by the end of
i915_hpd_poll_init_work() all display power references acquired by the
connector detect functions which can trigger a new cycle (display core
power domain) are dropped. However on platforms where HPD polling is
enabled/disabled only from the runtime suspend/resume handlers, this is
not ensured: for instance eDP VDD, TypeC port PHYs and the runtime
autosuspend delay may still keep the device runtime resumed (via a power
reference acquired during connector detection and hence result in an
endless loop like the above).

Solve the problem described in the above commit on all platforms, by
making sure that a i915_hpd_poll_init_work() -> connector detect
sequence can't take any power reference in the first place which would
trigger a new cycle, instead of relying on these power references to be
dropped by the end of the sequence.

With the default runtime autosuspend delay (10 sec) this issue didn't
happen in practice, since the device remained runtime resumed for the
whole duration of the above sequence. CI/IGT tests however set the
autosuspend delay to 0, which makes the problem visible, see References:
below.

Tested on GLK, CHV.

v2: Don't warn about a requeued work, to account for disabling
polling directly during driver loading, reset and system resume.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_crt.c |  6 --
 drivers/gpu/drm/i915/display/intel_dp.c  |  6 --
 drivers/gpu/drm/i915/display/intel_hdmi.c|  6 --
 drivers/gpu/drm/i915/display/intel_hotplug.c | 22 +++-
 4 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 8090747586877..f66340b4caf0f 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -907,12 +907,6 @@ intel_crt_detect(struct drm_connector *connector,
 out:
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
return status;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 03675620e3ead..fd9859d98bd43 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4957,12 +4957,6 @@ intel_dp_detect(struct drm_connector *connector,
if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
if (!intel_dp_is_edp(intel_dp))
drm_dp_set_subconnector_property(connector,
 status,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 8d1c8abfcffa1..14e133d192ab7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2522,12 +2522,6 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
if (status != connector_status_connected)
cec_notifier_phys_addr_invalidate(intel_hdmi->cec_notifier);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
return status;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 0ff5ed46ae1e7..dd7eb9fc78610 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -25,6 +25,7 @@
 
 #include "i915_drv.h"
 #include "i915_irq.h"
+#include "intel_display_power.h"
 #include "intel_display_types.h"
 #include "intel_hotplug.h"
 #include "intel_hotplug_irq.h"
@@ -638,11 +639,25 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
 display.hotplug.poll_init_work);
struct drm_connector_list_iter conn_iter;
struct intel_connector *connector;
+   intel_wakeref_t 

[Intel-gfx] [PATCH v2 0/5] drm/i915: Fix connector HPD polling

2023-07-20 Thread Imre Deak
This patchset replaces [1], adding two patches to fix a connector
detection issue overriding the state of forced connectors.

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

Imre Deak (5):
  drm/i915: Avoid endless HPD poll detect loop via runtime
suspend/resume
  drm: Add an HPD poll helper to reschedule the poll work
  drm/i915: Fix HPD polling, reenabling the output poll work as needed
  drm/i915: Don't change the status of forced connectors during hotplug
detect
  drm/i915: Don't change the status of forced connectors during HPD poll
detect

 drivers/gpu/drm/drm_probe_helper.c   | 68 ++-
 drivers/gpu/drm/i915/display/intel_crt.c |  6 --
 drivers/gpu/drm/i915/display/intel_dp.c  |  6 --
 drivers/gpu/drm/i915/display/intel_hdmi.c|  6 --
 drivers/gpu/drm/i915/display/intel_hotplug.c | 89 ++--
 include/drm/drm_probe_helper.h   |  1 +
 6 files changed, 127 insertions(+), 49 deletions(-)

-- 
2.37.2



Re: [Intel-gfx] [PATCH v6 6/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-20 Thread Nirmoy Das

Hi Andi,

On 7/19/2023 1:07 PM, Andi Shyti wrote:

Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.

Signed-off-by: Andi Shyti
Cc: Jonathan Cavitt
Cc: Matt Roper
---
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 46 ++--
  1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1b1dadacfbf42..3bedab8d61db1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -309,19 +309,45 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
  int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
  {
intel_engine_mask_t aux_inv = 0;
-   u32 cmd, *cs;
+   u32 cmd = 4;
+   u32 *cs;
  
-	cmd = 4;

-   if (mode & EMIT_INVALIDATE) {
+   if (mode & EMIT_INVALIDATE)
cmd += 2;
  
-		if (HAS_AUX_CCS(rq->engine->i915) &&

-   (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
-   aux_inv = rq->engine->mask &
-   ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-   if (aux_inv)
-   cmd += 4;
+   if (HAS_AUX_CCS(rq->engine->i915))
+   aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand
+*/
+   if (aux_inv) {
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
+
+   cmd += 4;
+
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   switch (rq->engine->class) {
+   case VIDEO_DECODE_CLASS:
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
+
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);



I think pipe control is only for compute and render engines.


+
+   break;
+
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COMPUTE_CLASS:


Don't think gen12_emit_flush_xcs() will get called for compute engine.

intel_guc_submission_setup() --> rcs_submission_override() replaces 
gen12_emit_flush_xcs() with |gen12_emit_flush_rcs()|


|for compute and render.|

|
|

|Regards,|

|Nirmoy
|



+   case COPY_ENGINE_CLASS:
+   break;
}
}
  

Re: [Intel-gfx] [PATCH v6 5/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

2023-07-20 Thread Nirmoy Das
Some of the patches are needed to be backported to v5.8 so I wonder if 
you should do the refactoring later in the series.


I guess best way is to check if you can apply the series in v5.8



On 7/19/2023 1:07 PM, Andi Shyti wrote:

Just a trivial refactoring for reducing the number of code
duplicate. This will come at handy in the next commits.

Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
  1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 7566c89d9def3..1b1dadacfbf42 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
return cs;
  }
  
+static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32 bit_group_0,

+  u32 bit_group_1, u32 offset)
+{
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 6);
+   if (IS_ERR(cs))
+   return cs;
+
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+   intel_ring_advance(rq, cs);
+
+   return cs;
+}
+
  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
/* Wa_14016712196 */
if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
-   u32 *cs;
-
-   /* dummy PIPE_CONTROL + depth flush */
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-   cs = gen12_emit_pipe_control(cs,
-0,
-PIPE_CONTROL_DEPTH_CACHE_FLUSH,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
-   }
+   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
+   intel_emit_pipe_control_cs(rq,
+  0,
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH,
+  LRC_PPHWSP_SCRATCH_ADDR);
  
  	return 0;

  }
@@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
-   u32 *cs;
  
  		err = mtl_dummy_pipe_control(rq);

if (err)
@@ -237,13 +244,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
  
-		cs = intel_ring_begin(rq, 6);

-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-
-   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
}
  
  	if (mode & EMIT_INVALIDATE) {


Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/color: Downscale degamma lut values read from hardware

2023-07-20 Thread Shankar, Uma



> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Monday, July 10, 2023 7:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: jani.nik...@linux.intel.com; Shankar, Uma ; Borah,
> Chaitanya Kumar 
> Subject: [PATCH v2 2/2] drm/i915/color: Downscale degamma lut values read from
> hardware
> 
> For MTL and beyond, convert back the 24 bit lut values read from HW to 16 bit
> values to maintain parity with userspace values. This way we avoid pipe config
> mismatch for pre-csc lut values.
> 
> v2: Add helper function to downscale values (Jani)

Change looks ok to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 15ada7fada96..41666e778c03 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -3456,6 +3456,14 @@ static struct drm_property_blob
> *glk_read_degamma_lut(struct intel_crtc *crtc)
>   for (i = 0; i < lut_size; i++) {
>   u32 val = intel_de_read_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe));
> 
> + /*
> +  * For MTL and beyond, convert back the 24 bit lut values
> +  * read from HW to 16 bit values to maintain parity with
> +  * userspace values
> +  */
> + if (DISPLAY_VER(dev_priv) >= 14)
> + val = change_lut_val_precision(val, 16, 24);
> +
>   lut[i].red = val;
>   lut[i].green = val;
>   lut[i].blue = val;
> --
> 2.25.1



Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/color: Upscale degamma values for MTL

2023-07-20 Thread Shankar, Uma



> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Monday, July 10, 2023 7:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: jani.nik...@linux.intel.com; Shankar, Uma ; Borah,
> Chaitanya Kumar 
> Subject: [PATCH v2 1/2] drm/i915/color: Upscale degamma values for MTL
> 
> MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from
> 16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16 bit
> precision. Until a new uapi comes along to support higher bitdepth, upscale 
> the
> values sent from userland to 24 bit before writing into the HW to continue
> supporting degamma on MTL.
> 
> Add helper function to upscale or downscale lut values. Parameters 'to' and 
> 'from'
> needs to be less than 32. This should be sufficient as currently there are no 
> lut values
> exceeding 32 bit.
> 
> v2: (Jani)
> - Reuse glk_load_degamma_lut()
> - Create a helper function for upscaling values
> 
> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 8966e6560516..15ada7fada96 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1453,6 +1453,16 @@ static int glk_degamma_lut_size(struct drm_i915_private
> *i915)
>   return 35;
>  }
> 
> +/* change_lut_val_precision: helper function to upscale or downscale lut 
> values.

Fix multi line comment style.

Change looks ok to me given the limitations of the UAPI.
Reviewed-by: Uma Shankar 

> + * Parameters 'to' and 'from' needs to be less than 32. This should be
> +sufficient
> + * as currently there are no lut values exceeding 32 bit.
> + **/
> +
> +static u32 change_lut_val_precision(u32 lut_val, int to, int from) {
> + return mul_u32_u32(lut_val, (1 << to)) / (1 << from); }
> +
>  static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
>const struct drm_property_blob *blob)  { @@ -
> 1487,8 +1497,15 @@ static void glk_load_degamma_lut(const struct
> intel_crtc_state *crtc_state,
>* ToDo: Extend to max 7.0. Enable 32 bit input value
>* as compared to just 16 to achieve this.
>*/
> + u32 lut_val;
> +
> + if (DISPLAY_VER(i915) >= 14)
> + lut_val = change_lut_val_precision(lut[i].green, 24, 
> 16);
> + else
> + lut_val = lut[i].green;
> +
>   ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
> -   lut[i].green);
> +   lut_val);
>   }
> 
>   /* Clamp values > 1.0. */
> --
> 2.25.1



Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "Revert "drm/i915: Hold reference to intel_context over life of i915_request""

2023-07-20 Thread Andrzej Hajda



On 19.07.2023 20:58, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:* 	Revert "Revert "drm/i915: Hold reference to intel_context 
over life of i915_request""

*URL:*  https://patchwork.freedesktop.org/series/120990/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120990v1/index.html



  CI Bug Log - changes from CI_DRM_13396 -> Patchwork_120990v1


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_120990v1 absolutely need 
to be

verified manually.

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


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



Participating hosts (42 -> 43)

Additional (2): fi-kbl-soraka bat-rpls-2
Missing (1): fi-snb-2520m


Possible new issues

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



  IGT changes


Possible regressions

 *

igt@debugfs_test@read_all_entries:

  o bat-mtlp-6: PASS


-> DMESG-WARN





Known bug: https://gitlab.freedesktop.org/drm/intel/-/issues/8940


 *
 *

igt@i915_selftest@live@gt_mocs:

  o bat-adlp-9: PASS


-> DMESG-WARN





Occasional bug: https://gitlab.freedesktop.org/drm/intel/-/issues/5830

Does not seems to be related.

Regards
Andrzej


 *


Warnings

  * igt@i915_selftest@live@slpc:
  o bat-mtlp-6: DMESG-WARN


(i915#6367
) ->
DMESG-WARN




Known issues

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



  IGT changes


Issues hit

 *

igt@debugfs_test@basic-hwmon:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#7456 )
 *

igt@fbdev@info:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#1849
 /
i915#2582 )
 *

igt@fbdev@read:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#2582
) +3
similar issues
 *

igt@gem_huc_copy@huc-copy:

  o fi-kbl-soraka: NOTRUN -> SKIP


(fdo#109271
 /
i915#2190 )
 *

igt@gem_lmem_swapping@basic:

  o fi-kbl-soraka: NOTRUN -> SKIP


(fdo#109271
 /
i915#4613
) +3
similar issues
 *

igt@gem_lmem_swapping@verify-random:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#4613
) +3
similar issues
 *

igt@gem_tiled_pread_basic:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#3282 )
 *

igt@i915_pm_backlight@basic-brightness:

  o bat-rpls-2: NOTRUN -> SKIP


(i915#7561 )
 *


[Intel-gfx] [PATCH v2] drm/i915: use direct alias for i915 in requests

2023-07-20 Thread Andrzej Hajda
i915_request contains direct alias to i915, there is no point to go via
rq->engine->i915.

v2: added missing rq.i915 initialization in measure_breadcrumb_dw.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Tvrtko Ursulin 
Acked-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
 drivers/gpu/drm/i915/gt/gen2_engine_cs.c   |  2 +-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 18 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c  |  1 +
 .../drm/i915/gt/intel_execlists_submission.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c| 10 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c|  4 ++--
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_rc6.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c|  4 ++--
 drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
 drivers/gpu/drm/i915/i915_perf.c   |  2 +-
 drivers/gpu/drm/i915/i915_request.c|  2 +-
 drivers/gpu/drm/i915/i915_trace.h  | 10 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c |  2 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c   | 14 +++---
 18 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3208a32561442..5a687a3686bd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2229,8 +2229,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
u32 *cs;
int i;
 
-   if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
-   drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
+   if (GRAPHICS_VER(rq->i915) != 7 || rq->engine->id != RCS0) {
+   drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 1c82caf525c346..8fe0499308ffe5 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -76,7 +76,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
cmd = MI_FLUSH;
if (mode & EMIT_INVALIDATE) {
cmd |= MI_EXE_FLUSH;
-   if (IS_G4X(rq->engine->i915) || GRAPHICS_VER(rq->engine->i915) 
== 5)
+   if (IS_G4X(rq->i915) || GRAPHICS_VER(rq->i915) == 5)
cmd |= MI_INVALIDATE_ISP;
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca1f..3ba20ea030e8d1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -39,11 +39,11 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
 * pipe control.
 */
-   if (GRAPHICS_VER(rq->engine->i915) == 9)
+   if (GRAPHICS_VER(rq->i915) == 9)
vf_flush_wa = true;
 
/* WaForGAMHang:kbl */
-   if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
+   if (IS_KBL_GRAPHICS_STEP(rq->i915, 0, STEP_C0))
dc_flush_wa = true;
}
 
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, 
const i915_reg_t inv
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+   if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
u32 *cs;
 
/* dummy PIPE_CONTROL + depth flush */
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915))
+   if (!HAS_FLAT_CCS(rq->i915))
count = 8 + 4;
else
count = 8;
@@ -285,7 +285,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
+   if (!HAS_FLAT_CCS(rq->i915)) {
/* hsdes: 1809175790 */
cs = gen12_emit_aux_table_inv(rq->engine->gt,
  cs, GEN12_GFX_CCS_AUX_NV);
@@ -307,7 +307,7 @@ int 

Re: [Intel-gfx] [RFC v5 00/17] DRM cgroup controller with scheduling control and memory stats

2023-07-20 Thread Tvrtko Ursulin



Hi,

On 19/07/2023 21:31, T.J. Mercier wrote:

On Wed, Jul 12, 2023 at 4:47 AM Tvrtko Ursulin
 wrote:


   drm.memory.stat
 A nested file containing cumulative memory statistics for the whole
 sub-hierarchy, broken down into separate GPUs and separate memory
 regions supported by the latter.

 For example::

   $ cat drm.memory.stat
   card0 region=system total=12898304 shared=0 active=0 
resident=12111872 purgeable=167936
   card0 region=stolen-system total=0 shared=0 active=0 resident=0 
purgeable=0

 Card designation corresponds to the DRM device names and multiple line
 entries can be present per card.

 Memory region names should be expected to be driver specific with the
 exception of 'system' which is standardised and applicable for GPUs
 which can operate on system memory buffers.

 Sub-keys 'resident' and 'purgeable' are optional.

 Per category region usage is reported in bytes.

  * Feedback from people interested in drm.active_us and drm.memory.stat is
required to understand the use cases and their usefulness (of the fields).

Memory stats are something which was easy to add to my series, since I was
already working on the fdinfo memory stats patches, but the question is how
useful it is.


Hi Tvrtko,

I think this style of driver-defined categories for reporting of
memory could potentially allow us to eliminate the GPU memory tracking
tracepoint used on Android (gpu_mem_total). This would involve reading
drm.memory.stat at the root cgroup (I see it's currently disabled on


I can put it available under root too, don't think there is any 
technical reason to not have it. In fact, now that I look at it again, 
memory.stat is present on root so that would align with my general 
guideline to keep the two as similar as possible.



the root), which means traversing the whole cgroup tree under the
cgroup lock to generate the values on-demand. This would be done
rarely, but I still wonder what the cost of that would turn out to be.


Yeah that's ugly. I could eliminate cgroup_lock by being a bit smarter. 
Just didn't think it worth it for the RFC.


Basically to account memory stats for any sub-tree I need the equivalent 
one struct drm_memory_stats per DRM device present in the hierarchy. So 
I could pre-allocate a few and restart if run out of spares, or 
something. They are really small so pre-allocating a good number, based 
on past state or something, should would good enough. Or even total 
number of DRM devices in a system as a pessimistic and safe option for 
most reasonable deployments.



The drm_memory_stats categories in the output don't seem like a big
value-add for this use-case, but no real objection to them being


You mean the fact there are different categories is not a value add for 
your use case because you would only use one?


The idea was to align 1:1 with DRM memory stats fdinfo and somewhat 
emulate how memory.stat also offers a breakdown.



there. I know it's called the DRM cgroup controller, but it'd be nice
if there were a way to make the mem tracking part work for any driver
that wishes to participate as many of our devices don't use a DRM
driver. But making that work doesn't look like it would fit very


Ah that would be a challenge indeed to which I don't have any answers 
right now.


Hm if you have a DRM device somewhere in the chain memory stats would 
still show up. Like if you had a dma-buf producer which is not a DRM 
driver, but then that buffer was imported by a DRM driver, it would show 
up in a cgroup. Or vice-versa. But if there aren't any in the whole 
chain then it would not.



cleanly into this controller, so I'll just shut up now.


Not all all, good feedback!

Regards,

Tvrtko


Re: [Intel-gfx] [PATCH] drm/i915: use direct alias for i915 in requests

2023-07-20 Thread Andrzej Hajda




On 20.07.2023 12:07, Tvrtko Ursulin wrote:


On 20/07/2023 10:46, Tvrtko Ursulin wrote:


On 19/07/2023 16:07, Andrzej Hajda wrote:

i915_request contains direct alias to i915, there is no point to go via
rq->engine->i915.

Signed-off-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
  drivers/gpu/drm/i915/gt/gen2_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 18 
+-

  .../drm/i915/gt/intel_execlists_submission.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_migrate.c    | 10 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c    |  2 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c    |  4 ++--
  drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/selftest_mocs.c    |  2 +-
  drivers/gpu/drm/i915/gt/selftest_rc6.c |  2 +-
  drivers/gpu/drm/i915/gt/selftest_timeline.c    |  4 ++--
  drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
  drivers/gpu/drm/i915/i915_request.c    |  2 +-
  drivers/gpu/drm/i915/i915_trace.h  | 10 +-
  drivers/gpu/drm/i915/selftests/i915_perf.c |  2 +-
  drivers/gpu/drm/i915/selftests/igt_spinner.c   | 14 +++---
  17 files changed, 42 insertions(+), 42 deletions(-)

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

index d3208a32561442..5a687a3686bd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2229,8 +2229,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)

  u32 *cs;
  int i;
-    if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != 
RCS0) {
-    drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs 
only\n");

+    if (GRAPHICS_VER(rq->i915) != 7 || rq->engine->id != RCS0) {
+    drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
  return -EINVAL;
  }
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c

index 1c82caf525c346..8fe0499308ffe5 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -76,7 +76,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, 
u32 mode)

  cmd = MI_FLUSH;
  if (mode & EMIT_INVALIDATE) {
  cmd |= MI_EXE_FLUSH;
-    if (IS_G4X(rq->engine->i915) || 
GRAPHICS_VER(rq->engine->i915) == 5)

+    if (IS_G4X(rq->i915) || GRAPHICS_VER(rq->i915) == 5)
  cmd |= MI_INVALIDATE_ISP;
  }
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c

index 23857cc08eca1f..3ba20ea030e8d1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -39,11 +39,11 @@ int gen8_emit_flush_rcs(struct i915_request *rq, 
u32 mode)

   * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
   * pipe control.
   */
-    if (GRAPHICS_VER(rq->engine->i915) == 9)
+    if (GRAPHICS_VER(rq->i915) == 9)
  vf_flush_wa = true;
  /* WaForGAMHang:kbl */
-    if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
+    if (IS_KBL_GRAPHICS_STEP(rq->i915, 0, STEP_C0))
  dc_flush_wa = true;
  }
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt 
*gt, u32 *cs, const i915_reg_t inv

  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
  /* Wa_14016712196 */
-    if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-    IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+    if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
+    IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
  u32 *cs;
  /* dummy PIPE_CONTROL + depth flush */
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request 
*rq, u32 mode)

  else if (engine->class == COMPUTE_CLASS)
  flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
-    if (!HAS_FLAT_CCS(rq->engine->i915))
+    if (!HAS_FLAT_CCS(rq->i915))
  count = 8 + 4;
  else
  count = 8;
@@ -285,7 +285,7 @@ int gen12_emit_flush_rcs(struct i915_request 
*rq, u32 mode)
  cs = gen8_emit_pipe_control(cs, flags, 
LRC_PPHWSP_SCRATCH_ADDR);

-    if (!HAS_FLAT_CCS(rq->engine->i915)) {
+    if (!HAS_FLAT_CCS(rq->i915)) {
  /* hsdes: 1809175790 */
  cs = gen12_emit_aux_table_inv(rq->engine->gt,
    cs, GEN12_GFX_CCS_AUX_NV);
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request 
*rq, u32 mode)

  if (mode & EMIT_INVALIDATE) {
  cmd += 2;
-    if (!HAS_FLAT_CCS(rq->engine->i915) &&
+    if (!HAS_FLAT_CCS(rq->i915) &&
  (rq->engine->class == VIDEO_DECODE_CLASS ||
   rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {

[Intel-gfx] [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us

2023-07-20 Thread Suraj Kandpal
On TGP, the RTC (always running) was reduced from 3MHz to 32KHz.
As a result of this change, when HPD active going low pulse or HPD IRQ
is presented and the refclk (19.2MHz) is not toggling already toggling,
there is a 60 to 90us synchronization delay which effectively reduces
the duration of the IRQ pulse to less than the programmed 500us filter
value and the hot plug interrupt is NOT registered.
Solution was to Reduce SHPD_FILTER to 250us for ADL and above.
This solution was derived when the below patch was floated.
[1]https://patchwork.freedesktop.org/patch/532187
and after some internal discussion Ville's suggestion made sense.

Bspec: 68970

Cc: Uma Shankar 
Cc: Ville Syrjala 
Suggested-by: Ville Syrjala 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 4 +++-
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c 
b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
index f95fa793fabb..95a7ea94f417 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
@@ -842,6 +842,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private 
*dev_priv)
 
if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP)
intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT, 
SHPD_FILTER_CNT_500_ADJ);
+   else
+   intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT, 
SHPD_FILTER_CNT_250);
 
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
 
@@ -1049,7 +1051,7 @@ static void mtp_hpd_irq_setup(struct drm_i915_private 
*i915)
enabled_irqs = intel_hpd_enabled_irqs(i915, 
i915->display.hotplug.pch_hpd);
hotplug_irqs = intel_hpd_hotplug_irqs(i915, 
i915->display.hotplug.pch_hpd);
 
-   intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
+   intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_250);
 
mtp_hpd_invert(i915);
ibx_display_interrupt_update(i915, hotplug_irqs, enabled_irqs);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dcf64e32cd54..aefad14ab27a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4939,6 +4939,7 @@
 
 #define SHPD_FILTER_CNT_MMIO(0xc4038)
 #define   SHPD_FILTER_CNT_500_ADJ  0x001D9
+#define   SHPD_FILTER_CNT_250  0x000F8
 
 #define _PCH_DPLL_A  0xc6014
 #define _PCH_DPLL_B  0xc6018
-- 
2.25.1



Re: [Intel-gfx] [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us

2023-07-20 Thread Kandpal, Suraj
> 
> > -Original Message-
> > From: Kandpal, Suraj 
> > Sent: Monday, July 17, 2023 2:54 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Kandpal, Suraj ; Shankar, Uma
> > ; Ville Syrjala 
> > Subject: [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us
> >
> > On TGP, the RTC (always running) was reduced from 3MHz to 32KHz.
> > As a result of this change, when HPD active going low pulse or HPD IRQ
> > is presented and the refclk (19.2MHz) is not toggling already
> > toggling, there is a 60 to 90us synchronization delay which
> > effectively reduces the duration of the IRQ pulse to less than the
> programmed 500us filter value and the hot plug interrupt is NOT registered.
> > Solution was to Reduce SHPD_FILTER to 250us for ADL and above.
> > This solution was derived when the below patch was floated.
> > [1]https://patchwork.freedesktop.org/patch/532187
> > and after some internal discussion Ville's suggestion made sense.
> 
> Looks Good to me. Just add also a Suggested-By tag mentioning Ville.
> Reviewed-by: Uma Shankar 
> 

Sure Uma will do, can you also help with getting this merged

Regards,
Suraj Kandpal
> > Bspec: 68970
> >
> > Cc: Uma Shankar 
> > Cc: Ville Syrjala 
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 4 +++-
> >  drivers/gpu/drm/i915/i915_reg.h  | 1 +
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > index f95fa793fabb..95a7ea94f417 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> > @@ -842,6 +842,8 @@ static void icp_hpd_irq_setup(struct
> > drm_i915_private
> > *dev_priv)
> >
> > if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP)
> > intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT,
> > SHPD_FILTER_CNT_500_ADJ);
> > +   else
> > +   intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT,
> > +SHPD_FILTER_CNT_250);
> >
> > ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
> >
> > @@ -1049,7 +1051,7 @@ static void mtp_hpd_irq_setup(struct
> > drm_i915_private
> > *i915)
> > enabled_irqs = intel_hpd_enabled_irqs(i915, i915-
> >display.hotplug.pch_hpd);
> > hotplug_irqs = intel_hpd_hotplug_irqs(i915,
> > i915->display.hotplug.pch_hpd);
> >
> > -   intel_de_write(i915, SHPD_FILTER_CNT,
> SHPD_FILTER_CNT_500_ADJ);
> > +   intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_250);
> >
> > mtp_hpd_invert(i915);
> > ibx_display_interrupt_update(i915, hotplug_irqs, enabled_irqs); diff
> > --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index dcf64e32cd54..aefad14ab27a
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4939,6 +4939,7 @@
> >
> >  #define SHPD_FILTER_CNT_MMIO(0xc4038)
> >  #define   SHPD_FILTER_CNT_500_ADJ  0x001D9
> > +#define   SHPD_FILTER_CNT_250  0x000F8
> >
> >  #define _PCH_DPLL_A  0xc6014
> >  #define _PCH_DPLL_B  0xc6018
> > --
> > 2.25.1



Re: [Intel-gfx] [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us

2023-07-20 Thread Shankar, Uma



> -Original Message-
> From: Kandpal, Suraj 
> Sent: Monday, July 17, 2023 2:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kandpal, Suraj ; Shankar, Uma
> ; Ville Syrjala 
> Subject: [PATCH] drm/i915/hotplug: Reduce SHPD_FILTER to 250us
> 
> On TGP, the RTC (always running) was reduced from 3MHz to 32KHz.
> As a result of this change, when HPD active going low pulse or HPD IRQ is 
> presented
> and the refclk (19.2MHz) is not toggling already toggling, there is a 60 to 
> 90us
> synchronization delay which effectively reduces the duration of the IRQ pulse 
> to less
> than the programmed 500us filter value and the hot plug interrupt is NOT 
> registered.
> Solution was to Reduce SHPD_FILTER to 250us for ADL and above.
> This solution was derived when the below patch was floated.
> [1]https://patchwork.freedesktop.org/patch/532187
> and after some internal discussion Ville's suggestion made sense.

Looks Good to me. Just add also a Suggested-By tag mentioning Ville.
Reviewed-by: Uma Shankar 

> Bspec: 68970
> 
> Cc: Uma Shankar 
> Cc: Ville Syrjala 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 4 +++-
>  drivers/gpu/drm/i915/i915_reg.h  | 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> index f95fa793fabb..95a7ea94f417 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
> @@ -842,6 +842,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
> 
>   if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP)
>   intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT,
> SHPD_FILTER_CNT_500_ADJ);
> + else
> + intel_uncore_write(_priv->uncore, SHPD_FILTER_CNT,
> +SHPD_FILTER_CNT_250);
> 
>   ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
> 
> @@ -1049,7 +1051,7 @@ static void mtp_hpd_irq_setup(struct drm_i915_private
> *i915)
>   enabled_irqs = intel_hpd_enabled_irqs(i915, 
> i915->display.hotplug.pch_hpd);
>   hotplug_irqs = intel_hpd_hotplug_irqs(i915, 
> i915->display.hotplug.pch_hpd);
> 
> - intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
> + intel_de_write(i915, SHPD_FILTER_CNT, SHPD_FILTER_CNT_250);
> 
>   mtp_hpd_invert(i915);
>   ibx_display_interrupt_update(i915, hotplug_irqs, enabled_irqs); diff 
> --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> dcf64e32cd54..aefad14ab27a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4939,6 +4939,7 @@
> 
>  #define SHPD_FILTER_CNT  _MMIO(0xc4038)
>  #define   SHPD_FILTER_CNT_500_ADJ0x001D9
> +#define   SHPD_FILTER_CNT_2500x000F8
> 
>  #define _PCH_DPLL_A  0xc6014
>  #define _PCH_DPLL_B  0xc6018
> --
> 2.25.1



Re: [Intel-gfx] [PATCH] drm/i915: use direct alias for i915 in requests

2023-07-20 Thread Tvrtko Ursulin



On 20/07/2023 10:46, Tvrtko Ursulin wrote:


On 19/07/2023 16:07, Andrzej Hajda wrote:

i915_request contains direct alias to i915, there is no point to go via
rq->engine->i915.

Signed-off-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
  drivers/gpu/drm/i915/gt/gen2_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 18 +-
  .../drm/i915/gt/intel_execlists_submission.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_migrate.c    | 10 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c    |  2 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c    |  4 ++--
  drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/selftest_mocs.c    |  2 +-
  drivers/gpu/drm/i915/gt/selftest_rc6.c |  2 +-
  drivers/gpu/drm/i915/gt/selftest_timeline.c    |  4 ++--
  drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
  drivers/gpu/drm/i915/i915_request.c    |  2 +-
  drivers/gpu/drm/i915/i915_trace.h  | 10 +-
  drivers/gpu/drm/i915/selftests/i915_perf.c |  2 +-
  drivers/gpu/drm/i915/selftests/igt_spinner.c   | 14 +++---
  17 files changed, 42 insertions(+), 42 deletions(-)

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

index d3208a32561442..5a687a3686bd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2229,8 +2229,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)

  u32 *cs;
  int i;
-    if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
-    drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
+    if (GRAPHICS_VER(rq->i915) != 7 || rq->engine->id != RCS0) {
+    drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
  return -EINVAL;
  }
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c

index 1c82caf525c346..8fe0499308ffe5 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -76,7 +76,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 
mode)

  cmd = MI_FLUSH;
  if (mode & EMIT_INVALIDATE) {
  cmd |= MI_EXE_FLUSH;
-    if (IS_G4X(rq->engine->i915) || 
GRAPHICS_VER(rq->engine->i915) == 5)

+    if (IS_G4X(rq->i915) || GRAPHICS_VER(rq->i915) == 5)
  cmd |= MI_INVALIDATE_ISP;
  }
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c

index 23857cc08eca1f..3ba20ea030e8d1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -39,11 +39,11 @@ int gen8_emit_flush_rcs(struct i915_request *rq, 
u32 mode)

   * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
   * pipe control.
   */
-    if (GRAPHICS_VER(rq->engine->i915) == 9)
+    if (GRAPHICS_VER(rq->i915) == 9)
  vf_flush_wa = true;
  /* WaForGAMHang:kbl */
-    if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
+    if (IS_KBL_GRAPHICS_STEP(rq->i915, 0, STEP_C0))
  dc_flush_wa = true;
  }
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, 
u32 *cs, const i915_reg_t inv

  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
  /* Wa_14016712196 */
-    if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-    IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+    if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
+    IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
  u32 *cs;
  /* dummy PIPE_CONTROL + depth flush */
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, 
u32 mode)

  else if (engine->class == COMPUTE_CLASS)
  flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
-    if (!HAS_FLAT_CCS(rq->engine->i915))
+    if (!HAS_FLAT_CCS(rq->i915))
  count = 8 + 4;
  else
  count = 8;
@@ -285,7 +285,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, 
u32 mode)
  cs = gen8_emit_pipe_control(cs, flags, 
LRC_PPHWSP_SCRATCH_ADDR);

-    if (!HAS_FLAT_CCS(rq->engine->i915)) {
+    if (!HAS_FLAT_CCS(rq->i915)) {
  /* hsdes: 1809175790 */
  cs = gen12_emit_aux_table_inv(rq->engine->gt,
    cs, GEN12_GFX_CCS_AUX_NV);
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, 
u32 mode)

  if (mode & EMIT_INVALIDATE) {
  cmd += 2;
-    if (!HAS_FLAT_CCS(rq->engine->i915) &&
+    if (!HAS_FLAT_CCS(rq->i915) &&
  (rq->engine->class == VIDEO_DECODE_CLASS ||
   rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
  aux_inv = rq->engine->mask &
@@ 

Re: [Intel-gfx] [PATCH] drm/i915: use direct alias for i915 in requests

2023-07-20 Thread Nirmoy Das



On 7/19/2023 5:07 PM, Andrzej Hajda wrote:

i915_request contains direct alias to i915, there is no point to go via
rq->engine->i915.

Signed-off-by: Andrzej Hajda 

Acked-by: Nirmoy Das 

---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
  drivers/gpu/drm/i915/gt/gen2_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 18 +-
  .../drm/i915/gt/intel_execlists_submission.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_migrate.c| 10 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c|  2 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c|  4 ++--
  drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/selftest_mocs.c|  2 +-
  drivers/gpu/drm/i915/gt/selftest_rc6.c |  2 +-
  drivers/gpu/drm/i915/gt/selftest_timeline.c|  4 ++--
  drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
  drivers/gpu/drm/i915/i915_request.c|  2 +-
  drivers/gpu/drm/i915/i915_trace.h  | 10 +-
  drivers/gpu/drm/i915/selftests/i915_perf.c |  2 +-
  drivers/gpu/drm/i915/selftests/igt_spinner.c   | 14 +++---
  17 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3208a32561442..5a687a3686bd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2229,8 +2229,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
u32 *cs;
int i;
  
-	if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {

-   drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
+   if (GRAPHICS_VER(rq->i915) != 7 || rq->engine->id != RCS0) {
+   drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
return -EINVAL;
}
  
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c

index 1c82caf525c346..8fe0499308ffe5 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -76,7 +76,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
cmd = MI_FLUSH;
if (mode & EMIT_INVALIDATE) {
cmd |= MI_EXE_FLUSH;
-   if (IS_G4X(rq->engine->i915) || GRAPHICS_VER(rq->engine->i915) 
== 5)
+   if (IS_G4X(rq->i915) || GRAPHICS_VER(rq->i915) == 5)
cmd |= MI_INVALIDATE_ISP;
}
  
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c

index 23857cc08eca1f..3ba20ea030e8d1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -39,11 +39,11 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
 * pipe control.
 */
-   if (GRAPHICS_VER(rq->engine->i915) == 9)
+   if (GRAPHICS_VER(rq->i915) == 9)
vf_flush_wa = true;
  
  		/* WaForGAMHang:kbl */

-   if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
+   if (IS_KBL_GRAPHICS_STEP(rq->i915, 0, STEP_C0))
dc_flush_wa = true;
}
  
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t inv

  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+   if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
u32 *cs;
  
  		/* dummy PIPE_CONTROL + depth flush */

@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
  
-		if (!HAS_FLAT_CCS(rq->engine->i915))

+   if (!HAS_FLAT_CCS(rq->i915))
count = 8 + 4;
else
count = 8;
@@ -285,7 +285,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  		cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
  
-		if (!HAS_FLAT_CCS(rq->engine->i915)) {

+   if (!HAS_FLAT_CCS(rq->i915)) {
/* hsdes: 1809175790 */
cs = gen12_emit_aux_table_inv(rq->engine->gt,
  cs, GEN12_GFX_CCS_AUX_NV);
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
  
-		if 

Re: [Intel-gfx] [PATCH] drm/i915: use direct alias for i915 in requests

2023-07-20 Thread Tvrtko Ursulin



On 19/07/2023 16:07, Andrzej Hajda wrote:

i915_request contains direct alias to i915, there is no point to go via
rq->engine->i915.

Signed-off-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
  drivers/gpu/drm/i915/gt/gen2_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 18 +-
  .../drm/i915/gt/intel_execlists_submission.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_migrate.c| 10 +-
  .../gpu/drm/i915/gt/intel_ring_submission.c|  2 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c|  4 ++--
  drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  2 +-
  drivers/gpu/drm/i915/gt/selftest_mocs.c|  2 +-
  drivers/gpu/drm/i915/gt/selftest_rc6.c |  2 +-
  drivers/gpu/drm/i915/gt/selftest_timeline.c|  4 ++--
  drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
  drivers/gpu/drm/i915/i915_request.c|  2 +-
  drivers/gpu/drm/i915/i915_trace.h  | 10 +-
  drivers/gpu/drm/i915/selftests/i915_perf.c |  2 +-
  drivers/gpu/drm/i915/selftests/igt_spinner.c   | 14 +++---
  17 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3208a32561442..5a687a3686bd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2229,8 +2229,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
u32 *cs;
int i;
  
-	if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {

-   drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
+   if (GRAPHICS_VER(rq->i915) != 7 || rq->engine->id != RCS0) {
+   drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
return -EINVAL;
}
  
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c

index 1c82caf525c346..8fe0499308ffe5 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -76,7 +76,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
cmd = MI_FLUSH;
if (mode & EMIT_INVALIDATE) {
cmd |= MI_EXE_FLUSH;
-   if (IS_G4X(rq->engine->i915) || GRAPHICS_VER(rq->engine->i915) 
== 5)
+   if (IS_G4X(rq->i915) || GRAPHICS_VER(rq->i915) == 5)
cmd |= MI_INVALIDATE_ISP;
}
  
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c

index 23857cc08eca1f..3ba20ea030e8d1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -39,11 +39,11 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
 * pipe control.
 */
-   if (GRAPHICS_VER(rq->engine->i915) == 9)
+   if (GRAPHICS_VER(rq->i915) == 9)
vf_flush_wa = true;
  
  		/* WaForGAMHang:kbl */

-   if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
+   if (IS_KBL_GRAPHICS_STEP(rq->i915, 0, STEP_C0))
dc_flush_wa = true;
}
  
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t inv

  static int mtl_dummy_pipe_control(struct i915_request *rq)
  {
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+   if (IS_MTL_GRAPHICS_STEP(rq->i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(rq->i915, P, STEP_A0, STEP_B0)) {
u32 *cs;
  
  		/* dummy PIPE_CONTROL + depth flush */

@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
  
-		if (!HAS_FLAT_CCS(rq->engine->i915))

+   if (!HAS_FLAT_CCS(rq->i915))
count = 8 + 4;
else
count = 8;
@@ -285,7 +285,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  		cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
  
-		if (!HAS_FLAT_CCS(rq->engine->i915)) {

+   if (!HAS_FLAT_CCS(rq->i915)) {
/* hsdes: 1809175790 */
cs = gen12_emit_aux_table_inv(rq->engine->gt,
  cs, GEN12_GFX_CCS_AUX_NV);
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
  
-		if (!HAS_FLAT_CCS(rq->engine->i915) &&

+   if 

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

2023-07-20 Thread Tvrtko Ursulin



On 19/07/2023 23:54, Matt Roper wrote:

On Wed, Jul 19, 2023 at 08:28:12AM -0700, Matt Roper wrote:

On Wed, Jul 19, 2023 at 09:01:58AM +0100, Tvrtko Ursulin wrote:


On 18/07/2023 23:27, Matt Roper wrote:

Several workarounds are guarded by IS_MTL_GRAPHICS_STEP.  However none
of these workarounds are actually tied to MTL as a platform; they only
relate to the Xe_LPG graphics IP, regardless of what platform it appears
in.  At the moment MTL is the only platform that uses Xe_LPG with IP
versions 12.70 and 12.71, but we can't count on this being true in the
future.  Switch these to use a new IS_GFX_IPVER_STEP() macro instead
that is purely based on IP version.  IS_GFX_IPVER_STEP() is also
GT-based rather than device-based, which will help prevent mistakes
where we accidentally try to apply Xe_LPG graphics workarounds to the
Xe_LPM+ media GT.

Signed-off-by: Matt Roper 
---
   .../drm/i915/display/skl_universal_plane.c|  4 +-
   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 ++--
   drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
   drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
   drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 52 ++-
   drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
   .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
   drivers/gpu/drm/i915/i915_drv.h   |  8 +--
   9 files changed, 46 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 6b01a0b68b97..c13e64fd 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2169,8 +2169,8 @@ static bool skl_plane_has_rc_ccs(struct drm_i915_private 
*i915,
 enum pipe pipe, enum plane_id plane_id)
   {
/* Wa_14017240301 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, STEP_B0) ||
+   IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, STEP_B0))


Do we really need/want a combined/long macro like this and not split it out
to something like a more readable IS_GFX_IPVER && IS_<...>_STEP?


On this part, wouldn't that make it less readable?  Right now these
conditions are an ||'d list of cases for which the workaround should
apply (relating to various entries in the workaround database).  If we
split the version, stepping, and GT checks out into separate macros
we'll get more complex conditions that are a mix of && and ||.  We can
try that, but my gut feeling is that it's going to be more error-prone
since we'll have to be really careful to always get the parenentheses in
the right places.  Also many people (myself included) are already having
some trouble adjusting to the new idea of GT (primary vs media) being an
important factor that needs to be considered in the workaround
condition; one of the goals with these new macros was to make sure that
got included in the macro so that it couldn't be omitted by accident.


Oh well I don't know.. maybe. It's just that I find that as amount of 
all uppercase blocks grows over a certain limit things become quite an 
eyesore and hard to read. One line of:


if (IS_GFX_IPVER_STEP(i915, IP_VER(12,70), STEP_A0, STEP_B0))

Is already borderline. A few of those on the same line is just hard to 
parse. But your argument also has merit so again, don't know.


What I was suggesting is to maybe have:

IS_GFX_IPVER_STEP(i915, IP_VER(12,70), IP_STEP(A0, B0))

Marginally shorter.

Maybe find a shorted name for IS_GFX_IPVER_STEP?

IS_GFX_IP(i915, IP_VER(12,70), IP_STEP(A0, B0))

?

Too bad we can't have that macro take the stepping argument as optional. 
Or maybe it is possible, I don't know C macro magic that well.


Also, if we added GT based macros we could get away with encoding the GT 
type in the macro name. Asking the GT/tile directrly about their IP_VER. 
Not sure how widely applicable tha would be so just a thought.


IS_IP(gt, IP_VER(12, 70))

GT_VER_FULL(gt) == IP_VER(13, 0)

Unless that falls apart with that GT is not a tile story.

Regards,

Tvrtko




Matt



Adding Jani since we were discussing this direction over the past few weeks.

Hm.. macro trickery for stepping ranges to make it more compact? Like making
the STEP_ prefix be prepended by the macro. Don't know..


One other thing that we could consider if some of these things are
getting too long is eliminating IP_VER() and using the "versionx100"
scheme that Xe and Mesa use.  On one hand that makes me a bit nervous
since GMD_ID's release number is 8 bits and could go past 100 on future
platforms, which would break the scheme (and we're already up to .71 on
MTL).  But on the other hand it does make the code simpler and shorter
and we can always wait and see if we ever 

[Intel-gfx] [PATCH v3] drm/i915: Fix premature release of request's reusable memory

2023-07-20 Thread Janusz Krzysztofik
Infinite waits for completion of GPU activity have been observed in CI,
mostly inside __i915_active_wait(), triggered by igt@gem_barrier_race or
igt@perf@stress-open-close.  Root cause analysis, based of ftrace dumps
generated with a lot of extra trace_printk() calls added to the code,
revealed loops of request dependencies being accidentally built,
preventing the requests from being processed, each waiting for completion
of another one's activity.

After we substitute a new request for a last active one tracked on a
timeline, we set up a dependency of our new request to wait on completion
of current activity of that previous one.  While doing that, we must take
care of keeping the old request still in memory until we use its
attributes for setting up that await dependency, or we can happen to set
up the await dependency on an unrelated request that already reuses the
memory previously allocated to the old one, already released.  Combined
with perf adding consecutive kernel context remote requests to different
user context timelines, unresolvable loops of await dependencies can be
built, leading do infinite waits.

We obtain a pointer to the previous request to wait upon when we
substitute it with a pointer to our new request in an active tracker,
e.g. in intel_timeline.last_request.  In some processing paths we protect
that old request from being freed before we use it by getting a reference
to it under RCU protection, but in others, e.g.  __i915_request_commit()
-> __i915_request_add_to_timeline() -> __i915_request_ensure_ordering(),
we don't.  But anyway, since the requests' memory is SLAB_FAILSAFE_BY_RCU,
that RCU protection is not sufficient against reuse of memory.

We could protect i915_request's memory from being prematurely reused by
calling its release function via call_rcu() and using rcu_read_lock()
consequently, as proposed in v1.  However, that approach leads to
significant (up to 10 times) increase of SLAB utilization by i915_request
SLAB cache.  Another potential approach is to take a reference to the
previous active fence.

When updating an active fence tracker, we first lock the new fence,
substitute a pointer of the current active fence with the new one, then we
lock the substituted fence.  With this approach, there is a time window
after the substitution and before the lock when the request can be
concurrently released by an interrupt handler and its memory reused, then
we may happen to lock and return a new, unrelated request.

Always get a reference to the current active fence first, before
replacing it with a new one.  Having it protected from premature release
and reuse, lock it and then replace with the new one but only if not
yet signalled via a potential concurrent interrupt nor replaced with
another one by a potential concurrent thread, otherwise retry, starting
from getting a reference to the new current one.  Adjust users to not
get a reference to the previous active fence themselves and always put the
reference got by __i915_active_fence_set() when no longer needed.

v3: Fix lockdep splat reports and other issues caused by incorrect use of
try_cmpxchg() (use (cmpxchg() != prev) instead)
v2: Protect request's memory by getting a reference to it in favor of
delegating its release to call_rcu() (Chris)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8211
Fixes: df9f85d8582e ("drm/i915: Serialise i915_active_fence_set() with itself")
Suggested-by: Chris Wilson 
Signed-off-by: Janusz Krzysztofik 
Cc:  # v5.6+
---
 drivers/gpu/drm/i915/i915_active.c  | 99 -
 drivers/gpu/drm/i915/i915_request.c | 11 
 2 files changed, 81 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 8ef93889061a6..5ec293011d990 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -449,8 +449,11 @@ int i915_active_add_request(struct i915_active *ref, 
struct i915_request *rq)
}
} while (unlikely(is_barrier(active)));
 
-   if (!__i915_active_fence_set(active, fence))
+   fence = __i915_active_fence_set(active, fence);
+   if (!fence)
__i915_active_acquire(ref);
+   else
+   dma_fence_put(fence);
 
 out:
i915_active_release(ref);
@@ -469,13 +472,9 @@ __i915_active_set_fence(struct i915_active *ref,
return NULL;
}
 
-   rcu_read_lock();
prev = __i915_active_fence_set(active, fence);
-   if (prev)
-   prev = dma_fence_get_rcu(prev);
-   else
+   if (!prev)
__i915_active_acquire(ref);
-   rcu_read_unlock();
 
return prev;
 }
@@ -1019,10 +1018,11 @@ void i915_request_add_active_barriers(struct 
i915_request *rq)
  *
  * Records the new @fence as the last active fence along its timeline in
  * this active tracker, moving the tracking callbacks from the previous
- * fence onto this one. Returns 

Re: [Intel-gfx] [PATCH 13/19] drm/i915/dp: Avoid left shift of DSC output bpp by 4

2023-07-20 Thread Lisovskiy, Stanislav
On Thu, Jul 13, 2023 at 04:03:40PM +0530, Ankit Nautiyal wrote:
> To make way for fractional bpp support, avoid left shifting the
> output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
>  2 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 9d2d05da594b..a7d58eb914c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -812,11 +812,7 @@ u16 intel_dp_dsc_get_max_compressed_bpp(struct 
> drm_i915_private *i915,
>  
>   bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel, 
> pipe_bpp);
>  
> - /*
> -  * Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> -  * fractional part is 0
> -  */
> - return bits_per_pixel << 4;
> + return bits_per_pixel;
>  }
>  
>  u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> @@ -1206,7 +1202,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>   
> mode->hdisplay,
>   bigjoiner,
>   
> output_format,
> - pipe_bpp, 
> 64) >> 4;
> + pipe_bpp, 
> 64);
>   dsc_slice_count =
>   intel_dp_dsc_get_slice_count(intel_dp,
>target_clock,
> @@ -1812,7 +1808,7 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>
> pipe_config->pipe_bpp);
>  
>   pipe_config->dsc.compressed_bpp = min_t(u16,
> - 
> dsc_max_compressed_bpp >> 4,
> + 
> dsc_max_compressed_bpp,
>   output_bpp);
>   }
>   pipe_config->dsc.slice_count = dsc_dp_slice_count;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index dff4717edbd0..4895d6242915 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -982,7 +982,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector 
> *connector,
>   
> mode->hdisplay,
>   bigjoiner,
>   
> INTEL_OUTPUT_FORMAT_RGB,
> - pipe_bpp, 
> 64) >> 4;
> + pipe_bpp, 
> 64);

Reviewed-by: Stanislav Lisovskiy 

>   dsc_slice_count =
>   intel_dp_dsc_get_slice_count(intel_dp,
>target_clock,
> -- 
> 2.40.1
> 


  1   2   >