Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Convert ct buffer to iosys_map

[Lucas De Marchi]

On Tue, Mar 08, 2022 at 05:38:45PM -0800, Lucas De Marchi wrote:

and in some other places too. I will try to finish the review later.



getting back to the rest now.




tail = (tail + 1) % size;
}
GEM_BUG_ON(tail > size);
@@ -442,13 +471,14 @@ static int ct_write(struct intel_guc_ct *ct,
atomic_sub(len + GUC_CTB_HDR_LEN, >space);

/* now update descriptor */
-   WRITE_ONCE(desc->tail, tail);
+   ct_desc_write(, tail, tail);

return 0;

corrupted:
CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
-desc->head, desc->tail, desc->status);
+ct_desc_read(, head), ct_desc_read(, tail),
+ct_desc_read(, status));
ctb->broken = true;
return -EPIPE;
}
@@ -499,20 +529,21 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;

if (unlikely(ret)) {
-   struct guc_ct_buffer_desc *send = ct->ctbs.send.desc;
-   struct guc_ct_buffer_desc *recv = ct->ctbs.send.desc;
+   struct iosys_map send = ct->ctbs.send.desc_map;
+   struct iosys_map recv = ct->ctbs.recv.desc_map;


you should only do a copy of the struct in places that you need to
(temporarily) increement the mapping or to overly another struct from an
offset of the original

Here you just use it as an alias for read operations, so a pointer would
do fine.



CT_ERROR(ct, "Communication stalled for %lld ms, desc 
status=%#x,%#x\n",
 ktime_ms_delta(ktime_get(), ct->stall_time),
-send->status, recv->status);
+ct_desc_read(, status),
+ct_desc_read(, status));
CT_ERROR(ct, "H2G Space: %u (Bytes)\n",
 atomic_read(>ctbs.send.space) * 4);
-   CT_ERROR(ct, "Head: %u (Dwords)\n", ct->ctbs.send.desc->head);
-   CT_ERROR(ct, "Tail: %u (Dwords)\n", ct->ctbs.send.desc->tail);
+   CT_ERROR(ct, "Head: %u (Dwords)\n", ct_desc_read(, head));
+   CT_ERROR(ct, "Tail: %u (Dwords)\n", ct_desc_read(, tail));
CT_ERROR(ct, "G2H Space: %u (Bytes)\n",
 atomic_read(>ctbs.recv.space) * 4);
-   CT_ERROR(ct, "Head: %u\n (Dwords)", ct->ctbs.recv.desc->head);
-   CT_ERROR(ct, "Tail: %u\n (Dwords)", ct->ctbs.recv.desc->tail);
+   CT_ERROR(ct, "Head: %u\n (Dwords)", ct_desc_read(, head));
+   CT_ERROR(ct, "Tail: %u\n (Dwords)", ct_desc_read(, tail));

ct->ctbs.send.broken = true;
}
@@ -549,18 +580,20 @@ static inline void g2h_release_space(struct intel_guc_ct 
*ct, u32 g2h_len_dw)
static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
{
struct intel_guc_ct_buffer *ctb = >ctbs.send;
-   struct guc_ct_buffer_desc *desc = ctb->desc;
+   struct iosys_map desc = ctb->desc_map;


same thing here, and in other places in this patch. The rest of the
patch seems to have the same pattern as things suggested above.

Lucas De Marchi

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Convert ct buffer to iosys_map

[Lucas De Marchi]

On Mon, Mar 14, 2022 at 11:23:07AM +0530, Siva Mullati wrote:


On 09/03/22 07:08, Lucas De Marchi wrote:

On Tue, Mar 08, 2022 at 03:08:05PM +0530, Mullati Siva wrote:

From: Siva Mullati 

Convert CT commands and descriptors to use iosys_map rather
than plain pointer and save it in the intel_guc_ct_buffer struct.
This will help with ct_write and ct_read for cmd send and receive
after the initialization by abstracting the IO vs system memory.

Signed-off-by: Siva Mullati 
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 170 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   9 +-
2 files changed, 110 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index f01325cd1b62..457deca1c25a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -44,6 +44,11 @@ static inline struct drm_device *ct_to_drm(struct 
intel_guc_ct *ct)
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)

+#define ct_desc_read(desc_map_, field_) \
+    iosys_map_rd_field(desc_map_, 0, struct guc_ct_buffer_desc, field_)


one thing I found useful in intel_guc_ads, was to use the first argument
as the struct type instead of map. That's because then I enforce the
right type to be passed rather than a random iosys_map. See :

#define ads_blob_read(guc_, field_) \
    iosys_map_rd_field(&(guc_)->ads_map, 0, struct __guc_ads_blob, field_)

First arg is expected to be `struct intel_guc *`. Yes, I didn't do this
for info_map_{read,write}, because there were situation in which I had
to pass a info from outside (forcefully from system memory). If you
don't have such case,  I think it would be better to pass the typed
pointer.


understood, will change it as a "typed pointer".

+#define ct_desc_write(desc_map_, field_, val_) \
+    iosys_map_wr_field(desc_map_, 0, struct guc_ct_buffer_desc, field_, val_)
+
/**
 * DOC: CTB Blob
 *
@@ -113,9 +118,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
init_waitqueue_head(>wq);
}

-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
+static void guc_ct_buffer_desc_init(struct iosys_map *desc)


if you can apply the comment above, then leave it as
struct intel_guc_ct_buffer.


yes

{
-    memset(desc, 0, sizeof(*desc));
+    iosys_map_memset(desc, 0, 0, sizeof(struct guc_ct_buffer_desc));
}

static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
@@ -128,17 +133,24 @@ static void guc_ct_buffer_reset(struct 
intel_guc_ct_buffer *ctb)
space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size) - ctb->resv_space;
atomic_set(>space, space);

-    guc_ct_buffer_desc_init(ctb->desc);
+    guc_ct_buffer_desc_init(>desc_map);
}

static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
-   struct guc_ct_buffer_desc *desc,
-   u32 *cmds, u32 size_in_bytes, u32 resv_space)
+   void *desc, void *cmds, u32 size_in_bytes,
+   u32 resv_space, bool lmem)


bool arguments are really hard to read, because you always have to
lookup the function prototype to understand what that is about.


Tried to avoid bool but could not find a better alternative code path.
Please suggest, if you have something.


humn... suggestion as as below:




Here we could turn struct guc_ct_buffer_desc *desc into the map, and let
the caller prepare it for iomem or system memory.


In other words, maybe instead of receiving guc_ct_buffer_desc as
parameter, receiving a struct iosys_map *desc_map. That map can be
created by the caller and then you do:

ctb->desc_map = *desc_map;


Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix renamed struct field

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field
URL   : https://patchwork.freedesktop.org/series/101448/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11372_full -> Patchwork_22590_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_wc@write-wc-read-gtt:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl9/igt@gem_mmap...@write-wc-read-gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl6/igt@gem_mmap...@write-wc-read-gtt.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#4547])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl4/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-apl2/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-apl3/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@basic:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl10/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk9/igt@gem_lmem_swapp...@parallel-random-engines.html
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl4/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_pxp@reject-modify-context-protection-off-2:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-iclb6/igt@gem_...@reject-modify-context-protection-off-2.html

  * igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-tglb7/igt@gen3_render_linear_blits.html

  * igt@i915_pm_dc@dc6-psr:
- 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)
URL   : https://patchwork.freedesktop.org/series/101219/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11372_full -> Patchwork_22589_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * 
igt@kms_plane_scaling@scaler-with-pixel-format-unity-scaling@pipe-c-edp-1-scaler-with-pixel-format:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-iclb6/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-c-edp-1-scaler-with-pixel-format.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-iclb2/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-c-edp-1-scaler-with-pixel-format.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +4 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-apl3/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_eio@kms:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#232])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb7/igt@gem_...@kms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-tglb2/igt@gem_...@kms.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#4547])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-skl7/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_capture@pi@vecs0:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([i915#3371])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-iclb2/igt@gem_exec_capture@p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-iclb4/igt@gem_exec_capture@p...@vecs0.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#2842]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-skl8/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-glk:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-glk9/igt@gem_lmem_swapp...@parallel-random-engines.html
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/shard-kbl6/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Add smem fallback allocation for dpt

[Patchwork]

== Series Details ==

Series: drm/i915/display: Add smem fallback allocation for dpt
URL   : https://patchwork.freedesktop.org/series/101443/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11372_full -> Patchwork_22588_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 12)
--

  Additional (1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@perf@stress-open-close:
- shard-glk:  NOTRUN -> [DMESG-FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-glk2/igt@p...@stress-open-close.html

  
 Suppressed 

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

  * igt@i915_pm_dc@dc5-dpms:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-rkl-5/igt@i915_pm...@dc5-dpms.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-tglb: [PASS][3] -> [FAIL][4] ([i915#232])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb7/igt@gem_...@kms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-tglb8/igt@gem_...@kms.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#4547])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-skl7/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_endless@dispatch@vecs0:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#3778])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb6/igt@gem_exec_endless@dispa...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-tglb5/igt@gem_exec_endless@dispa...@vecs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-kbl:  NOTRUN -> [FAIL][18] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-normal:
- shard-glk:  [PASS][21] -> [DMESG-WARN][22] ([i915#118])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk2/igt@gem_exec_whis...@basic-normal.html
   [22]: 

Re: [Intel-gfx] [PATCH v11 2/5] mei: add support for graphics system controller (gsc) devices

[Ceraolo Spurio, Daniele]

On 3/15/2022 6:11 AM, Alexander Usyskin wrote:

From: Tomas Winkler 

GSC is a graphics system controller, based on CSE, it provides
a chassis controller for graphics discrete cards, as well as it
supports media protection on selected devices.

mei_gsc binds to a auxiliary devices exposed by Intel discrete
driver i915.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
V4: drop debug prints
 replace selects with depends on in Kconfig
V5: Rebase
V6: Rebase
V7: add Greg KH Reviewed-by
V8: Rebase
V9: Rebase
V11: explicitely call devm_free_irq on error path and remove
---
  drivers/misc/mei/Kconfig  |  14 +++
  drivers/misc/mei/Makefile |   3 +
  drivers/misc/mei/gsc-me.c | 194 ++
  drivers/misc/mei/hw-me.c  |  27 +-
  drivers/misc/mei/hw-me.h  |   2 +
  5 files changed, 238 insertions(+), 2 deletions(-)
  create mode 100644 drivers/misc/mei/gsc-me.c

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 0e0bcd0da852..d21486d69df2 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -46,6 +46,20 @@ config INTEL_MEI_TXE
  Supported SoCs:
  Intel Bay Trail
  
+config INTEL_MEI_GSC

+   tristate "Intel MEI GSC embedded device"
+   depends on INTEL_MEI
+   depends on INTEL_MEI_ME
+   depends on X86 && PCI
+   depends on DRM_I915
+   help
+ Intel auxiliary driver for GSC devices embedded in Intel graphics 
devices.
+
+ An MEI device here called GSC can be embedded in an
+ Intel graphics devices, to support a range of chassis
+ tasks such as graphics card firmware update and security
+ tasks.
+
  source "drivers/misc/mei/hdcp/Kconfig"
  source "drivers/misc/mei/pxp/Kconfig"
  
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile

index d8e5165917f2..fb740d754900 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -18,6 +18,9 @@ obj-$(CONFIG_INTEL_MEI_ME) += mei-me.o
  mei-me-objs := pci-me.o
  mei-me-objs += hw-me.o
  
+obj-$(CONFIG_INTEL_MEI_GSC) += mei-gsc.o

+mei-gsc-objs := gsc-me.o
+
  obj-$(CONFIG_INTEL_MEI_TXE) += mei-txe.o
  mei-txe-objs := pci-txe.o
  mei-txe-objs += hw-txe.o
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
new file mode 100644
index ..64b02adf3149
--- /dev/null
+++ b/drivers/misc/mei/gsc-me.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ *
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mei_dev.h"
+#include "hw-me.h"
+#include "hw-me-regs.h"
+
+#include "mei-trace.h"
+
+#define MEI_GSC_RPM_TIMEOUT 500
+
+static int mei_gsc_read_hfs(const struct mei_device *dev, int where, u32 *val)
+{
+   struct mei_me_hw *hw = to_me_hw(dev);
+
+   *val = ioread32(hw->mem_addr + where + 0xC00);
+
+   return 0;
+}
+
+static int mei_gsc_probe(struct auxiliary_device *aux_dev,
+const struct auxiliary_device_id *aux_dev_id)
+{
+   struct mei_aux_device *adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+   struct mei_device *dev;
+   struct mei_me_hw *hw;
+   struct device *device;
+   const struct mei_cfg *cfg;
+   int ret;
+
+   cfg = mei_me_get_cfg(aux_dev_id->driver_data);
+   if (!cfg)
+   return -ENODEV;
+
+   device = _dev->dev;
+
+   dev = mei_me_dev_init(device, cfg);
+   if (IS_ERR(dev)) {
+   ret = PTR_ERR(dev);
+   goto err;
+   }
+
+   hw = to_me_hw(dev);
+   hw->mem_addr = devm_ioremap_resource(device, >bar);
+   if (IS_ERR(hw->mem_addr)) {
+   dev_err(device, "mmio not mapped\n");
+   ret = PTR_ERR(hw->mem_addr);
+   goto err;
+   }
+
+   hw->irq = adev->irq;
+   hw->read_fws = mei_gsc_read_hfs;
+
+   dev_set_drvdata(device, dev);
+
+   ret = devm_request_threaded_irq(device, hw->irq,
+   mei_me_irq_quick_handler,
+   mei_me_irq_thread_handler,
+   IRQF_ONESHOT, KBUILD_MODNAME, dev);
+   if (ret) {
+   dev_err(device, "irq register failed %d\n", ret);
+   goto err;
+   }
+
+   pm_runtime_get_noresume(device);
+   pm_runtime_set_active(device);
+   pm_runtime_enable(device);
+
+   if (mei_start(dev)) {
+   dev_err(device, "init hw failure.\n");
+   ret = -ENODEV;
+   goto irq_err;
+   }
+
+   pm_runtime_set_autosuspend_delay(device, MEI_GSC_RPM_TIMEOUT);
+   pm_runtime_use_autosuspend(device);
+
+   ret = mei_register(dev, device);
+   if (ret)
+   goto register_err;
+
+   

Re: [Intel-gfx] [PATCH v11 1/5] drm/i915/gsc: add gsc as a mei auxiliary device

[Ceraolo Spurio, Daniele]

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ddbc7a685a50..63c56d668963 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -976,6 +976,8 @@
  #define GEN12_COMPUTE2_RING_BASE  0x1e000
  #define GEN12_COMPUTE3_RING_BASE  0x26000
  #define BLT_RING_BASE 0x22000
+#define DG1_GSC_HECI1_BASE 0x00258000
+#define DG1_GSC_HECI2_BASE 0x00259000


You ended up keeping the HECI1 define. Not a blocker, so:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele

  
  
  
diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h

index f9b955810593..576d15a04c9e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -141,6 +141,8 @@ enum intel_ppgtt_type {
func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gt_uc); \
+   func(has_heci_pxp); \
+   func(has_heci_gscfi); \
func(has_guc_deprivilege); \
func(has_l3_dpf); \
func(has_llc); \
diff --git a/include/linux/mei_aux.h b/include/linux/mei_aux.h
new file mode 100644
index ..587f25128848
--- /dev/null
+++ b/include/linux/mei_aux.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2022, Intel Corporation. All rights reserved.
+ */
+#ifndef _LINUX_MEI_AUX_H
+#define _LINUX_MEI_AUX_H
+
+#include 
+
+struct mei_aux_device {
+   struct auxiliary_device aux_dev;
+   int irq;
+   struct resource bar;
+};
+
+#define auxiliary_dev_to_mei_aux_dev(auxiliary_dev) \
+   container_of(auxiliary_dev, struct mei_aux_device, aux_dev)
+
+#endif /* _LINUX_MEI_AUX_H */

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix renamed struct field

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field
URL   : https://patchwork.freedesktop.org/series/101448/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11372 -> Patchwork_22590


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 45)
--

  Additional (1): fi-pnv-d510 
  Missing(5): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- fi-bdw-5557u:   NOTRUN -> [SKIP][2] ([fdo#109271]) +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/fi-bdw-5557u/igt@gem_lmem_swapp...@basic.html

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

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#5341])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][9] ([i915#146] / [i915#])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/fi-bdw-5557u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

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

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {bat-dg2-9}:[DMESG-WARN][11] ([i915#5195]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-dg2-9/igt@gem_exec_gttf...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/bat-dg2-9/igt@gem_exec_gttf...@basic.html

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

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

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

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1436]: 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add logical mapping for video decode engines

[Matthew Brost]

On Wed, Mar 16, 2022 at 04:45:38PM -0700, Lucas De Marchi wrote:
> From: Matthew Brost 
> 
> Add logical mapping for VDBOXs. This mapping is required for
> split-frame workloads, which otherwise fail with
> 
>   -F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK
> 
> ... if the application is using the logical id to reorder the engines and
> then using it for the batch buffer submission. It's not a big problem on
> media version 11 and 12 as they have only 2 instances of VCS and the
> logical to physical mapping is monotonically increasing - if the
> application is not using the logical id.
> 
> Changing it for the previous platforms allows the media driver
> implementation for the next ones (12.50 and above) to be the same,
> checking the logical id. It should also not introduce any bug for the
> old versions of userspace not checking the id.
> 
> The mapping added here is the complete map needed by XEHPSDV. Previous
> platforms with only 2 instances will just use a partial map and should
> still work.
> 
> Cc: Matt Roper 
> Signed-off-by: Matthew Brost 
> [ Extend the mapping to media versions 11 and 12 and give proper
>   justification in the commit message why ]
> Signed-off-by: Lucas De Marchi 

For the changes to the patch / commit message:

Acked-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 8080479f27aa..afa2e61cf729 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -731,12 +731,24 @@ static void populate_logical_ids(struct intel_gt *gt, 
> u8 *logical_ids,
>  
>  static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 class)
>  {
> - int i;
> - u8 map[MAX_ENGINE_INSTANCE + 1];
> + /*
> +  * Logical to physical mapping is needed for proper support
> +  * to split-frame feature.
> +  */
> + if (MEDIA_VER(gt->i915) >= 11 && class == VIDEO_DECODE_CLASS) {
> + static const u8 map[] = { 0, 2, 4, 6, 1, 3, 5, 7 };
>  
> - for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> - map[i] = i;
> - populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
> + populate_logical_ids(gt, logical_ids, class,
> +  map, ARRAY_SIZE(map));
> + } else {
> + int i;
> + u8 map[MAX_ENGINE_INSTANCE + 1];
> +
> + for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> + map[i] = i;
> + populate_logical_ids(gt, logical_ids, class,
> +  map, ARRAY_SIZE(map));
> + }
>  }
>  
>  /**
> -- 
> 2.35.1
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)
URL   : https://patchwork.freedesktop.org/series/101219/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11372 -> Patchwork_22589


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 43)
--

  Missing(6): fi-kbl-soraka shard-tglu fi-hsw-4200u fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][3] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {bat-dg2-9}:[DMESG-WARN][4] ([i915#5195]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-dg2-9/igt@gem_exec_gttf...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/bat-dg2-9/igt@gem_exec_gttf...@basic.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [FAIL][6] ([i915#5323]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][8] ([i915#3576]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22589/bat-adlp-6/igt@kms_busy@ba...@modeset.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5192]: https://gitlab.freedesktop.org/drm/intel/issues/5192
  [i915#5193]: https://gitlab.freedesktop.org/drm/intel/issues/5193
  [i915#5195]: https://gitlab.freedesktop.org/drm/intel/issues/5195
  [i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5275]: https://gitlab.freedesktop.org/drm/intel/issues/5275
  [i915#5276]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Fix renamed struct field

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field
URL   : https://patchwork.freedesktop.org/series/101448/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Fix renamed struct field

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field
URL   : https://patchwork.freedesktop.org/series/101448/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4e997aa6f37e drm/i915: Fix renamed struct field
-:27: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#27: FILE: drivers/gpu/drm/i915/i915_drv.h:925:
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media.ver, \
   INTEL_INFO(i915)->media.rel)

total: 0 errors, 0 warnings, 1 checks, 8 lines checked
7604b41d03ca drm/i915: Add logical mapping for video decode engines

[Intel-gfx] [PATCH 1/2] drm/i915: Fix renamed struct field

[Lucas De Marchi]

Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold
IP version") named "ver" as "arch" and then when it was renamed it
missed the rename on MEDIA_VER_FULL() since it it's currently not used.

Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version")
Cc: José Roberto de Souza 
Cc: Matt Roper 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26df561a4e94..7458b107a1d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -922,7 +922,7 @@ static inline struct intel_gt *to_gt(struct 
drm_i915_private *i915)
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
 
 #define MEDIA_VER(i915)(INTEL_INFO(i915)->media.ver)
-#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media.arch, \
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media.ver, \
   INTEL_INFO(i915)->media.rel)
 #define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
-- 
2.35.1

[Intel-gfx] [PATCH 2/2] drm/i915: Add logical mapping for video decode engines

[Lucas De Marchi]

From: Matthew Brost 

Add logical mapping for VDBOXs. This mapping is required for
split-frame workloads, which otherwise fail with

-F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK

... if the application is using the logical id to reorder the engines and
then using it for the batch buffer submission. It's not a big problem on
media version 11 and 12 as they have only 2 instances of VCS and the
logical to physical mapping is monotonically increasing - if the
application is not using the logical id.

Changing it for the previous platforms allows the media driver
implementation for the next ones (12.50 and above) to be the same,
checking the logical id. It should also not introduce any bug for the
old versions of userspace not checking the id.

The mapping added here is the complete map needed by XEHPSDV. Previous
platforms with only 2 instances will just use a partial map and should
still work.

Cc: Matt Roper 
Signed-off-by: Matthew Brost 
[ Extend the mapping to media versions 11 and 12 and give proper
  justification in the commit message why ]
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 8080479f27aa..afa2e61cf729 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -731,12 +731,24 @@ static void populate_logical_ids(struct intel_gt *gt, u8 
*logical_ids,
 
 static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8 class)
 {
-   int i;
-   u8 map[MAX_ENGINE_INSTANCE + 1];
+   /*
+* Logical to physical mapping is needed for proper support
+* to split-frame feature.
+*/
+   if (MEDIA_VER(gt->i915) >= 11 && class == VIDEO_DECODE_CLASS) {
+   static const u8 map[] = { 0, 2, 4, 6, 1, 3, 5, 7 };
 
-   for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
-   map[i] = i;
-   populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
+   populate_logical_ids(gt, logical_ids, class,
+map, ARRAY_SIZE(map));
+   } else {
+   int i;
+   u8 map[MAX_ENGINE_INSTANCE + 1];
+
+   for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
+   map[i] = i;
+   populate_logical_ids(gt, logical_ids, class,
+map, ARRAY_SIZE(map));
+   }
 }
 
 /**
-- 
2.35.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Add smem fallback allocation for dpt

[Patchwork]

== Series Details ==

Series: drm/i915/display: Add smem fallback allocation for dpt
URL   : https://patchwork.freedesktop.org/series/101443/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11372 -> Patchwork_22588


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 44)
--

  Additional (1): fi-pnv-d510 
  Missing(6): fi-kbl-soraka shard-tglu fi-hsw-4200u fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [FAIL][1] ([i915#5323]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/bat-rpls-2/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][4] -> [DMESG-FAIL][5] ([i915#4494] / 
[i915#4957])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][6] ([i915#3921])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#5341])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][11] ([fdo#109271]) +14 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html

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

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {bat-dg2-9}:[DMESG-WARN][13] ([i915#5195]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/bat-dg2-9/igt@gem_exec_gttf...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22588/bat-dg2-9/igt@gem_exec_gttf...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3637]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)
URL   : https://patchwork.freedesktop.org/series/101219/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev3)
URL   : https://patchwork.freedesktop.org/series/101219/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6da9e3d1f502 drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
-:131: CHECK:SPACING: No space is necessary after a cast
#131: FILE: drivers/gpu/drm/i915/i915_query.c:111:
+   engine = intel_engine_lookup_user(i915, (u8) classinstance.engine_class,

-:132: CHECK:SPACING: No space is necessary after a cast
#132: FILE: drivers/gpu/drm/i915/i915_query.c:112:
+ (u8) classinstance.engine_instance);

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

[Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES

[Matt Atwood]

Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.

v2: fix white space errors
v3: change flags from hosting 2 8 bit numbers to holding a
i915_engine_class_instance struct

Cc: Ashutosh Dixit 
Cc: Matt Roper 
Cc: Joonas Lahtinen 
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/i915_query.c | 68 ++-
 include/uapi/drm/i915_drm.h   | 24 +++
 2 files changed, 65 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..fcb374201edb 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -9,6 +9,7 @@
 #include "i915_drv.h"
 #include "i915_perf.h"
 #include "i915_query.h"
+#include "gt/intel_engine_user.h"
 #include 
 
 static int copy_query_item(void *query_hdr, size_t query_sz,
@@ -28,36 +29,30 @@ static int copy_query_item(void *query_hdr, size_t query_sz,
return 0;
 }
 
-static int query_topology_info(struct drm_i915_private *dev_priv,
-  struct drm_i915_query_item *query_item)
+static int fill_topology_info(const struct sseu_dev_info *sseu,
+ struct drm_i915_query_item *query_item,
+ const u8 *subslice_mask)
 {
-   const struct sseu_dev_info *sseu = _gt(dev_priv)->info.sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
int ret;
 
-   if (query_item->flags != 0)
-   return -EINVAL;
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
 
if (sseu->max_slices == 0)
return -ENODEV;
 
-   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
-
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
   eu_length;
 
-   ret = copy_query_item(, sizeof(topo), total_length,
- query_item);
+   ret = copy_query_item(, sizeof(topo), total_length, query_item);
+
if (ret != 0)
return ret;
 
-   if (topo.flags != 0)
-   return -EINVAL;
-
memset(, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
@@ -69,27 +64,61 @@ static int query_topology_info(struct drm_i915_private 
*dev_priv,
topo.eu_stride = sseu->eu_stride;
 
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
-  , sizeof(topo)))
+, sizeof(topo)))
return -EFAULT;
 
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + sizeof(topo)),
-  >slice_mask, slice_length))
+>slice_mask, slice_length))
return -EFAULT;
 
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
-  sizeof(topo) + slice_length),
-  sseu->subslice_mask, subslice_length))
+sizeof(topo) + slice_length),
+subslice_mask, subslice_length))
return -EFAULT;
 
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
-  sizeof(topo) +
-  slice_length + subslice_length),
-  sseu->eu_mask, eu_length))
+sizeof(topo) +
+slice_length + subslice_length),
+sseu->eu_mask, eu_length))
return -EFAULT;
 
return total_length;
 }
 
+static int query_topology_info(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _gt(dev_priv)->info.sseu;
+
+   if (query_item->flags != 0)
+   return -EINVAL;
+
+   return fill_topology_info(sseu, query_item, sseu->subslice_mask);
+}
+
+static int query_geometry_subslices(struct drm_i915_private *i915,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu;
+   struct intel_engine_cs *engine;
+   struct i915_engine_class_instance classinstance;
+
+   if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+   return -ENODEV;
+
+   classinstance = *((struct i915_engine_class_instance 
*)_item->flags);
+
+   engine = 

[Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

[Juha-Pekka Heikkila]

Add fallback smem allocation for dpt if stolen memory
allocation failed.

Signed-off-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index fb0e7e79e0cd..c8b66433d4db 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -10,6 +10,7 @@
 #include "intel_display_types.h"
 #include "intel_dpt.h"
 #include "intel_fb.h"
+#include "gem/i915_gem_internal.h"
 
 struct i915_dpt {
struct i915_address_space vm;
@@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
void __iomem *iomem;
struct i915_gem_ww_ctx ww;
int err;
+   u64 pin_flags = 0;
+
+   if (i915_gem_object_is_stolen(dpt->obj))
+   pin_flags |= PIN_MAPPABLE; /* for i915_vma_pin_iomap(stolen) */
 
wakeref = intel_runtime_pm_get(>runtime_pm);
atomic_inc(>gpu_error.pending_fb_pin);
@@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
continue;
 
vma = i915_gem_object_ggtt_pin_ww(dpt->obj, , NULL, 0, 4096,
- HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+ pin_flags);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
continue;
@@ -248,10 +253,15 @@ intel_dpt_create(struct intel_framebuffer *fb)
 
size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);
 
-   if (HAS_LMEM(i915))
-   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
-   else
+   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(dpt_obj) && i915_ggtt_has_aperture(to_gt(i915)->ggtt))
dpt_obj = i915_gem_object_create_stolen(i915, size);
+   if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
+   drm_dbg_kms(>drm, "fb: [FB:%d] Allocating dpt from 
smem\n",
+   fb->base.base.id);
+
+   dpt_obj = i915_gem_object_create_internal(i915, size);
+   }
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
 
-- 
2.28.0

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch] (rev2)
URL   : https://patchwork.freedesktop.org/series/101426/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11370_full -> Patchwork_22587_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_workarounds@suspend-resume-context:
- {shard-tglu}:   NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-tglu-1/igt@gem_workarou...@suspend-resume-context.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_mm@all@replace:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3] ([i915#1373] / 
[i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-skl6/igt@drm_mm@a...@replace.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-skl2/igt@drm_mm@a...@replace.html

  * igt@gem_ccs@ctrl-surf-copy:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-tglb7/igt@gem_...@ctrl-surf-copy.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-iclb8/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  NOTRUN -> [FAIL][6] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-fds:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118]) +3 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-glk6/igt@gem_exec_whis...@basic-fds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-glk5/igt@gem_exec_whis...@basic-fds.html

  * igt@gem_lmem_swapping@parallel-multi:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-tglb7/igt@gem_lmem_swapp...@parallel-multi.html

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-apl4/igt@gem_lmem_swapp...@parallel-random-verify.html

  * igt@gem_userptr_blits@vma-merge:
- shard-glk:  NOTRUN -> [FAIL][19] ([i915#3318])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-glk2/igt@gem_userptr_bl...@vma-merge.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-skl:  [PASS][20] -> [INCOMPLETE][21] ([i915#4939] / 
[i915#5129])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11370/shard-skl4/igt@gem_workarou...@suspend-resume-context.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/shard-skl9/igt@gem_workarou...@suspend-resume-context.html

  * 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: preempt and reset based on reset domain

[kernel test robot]

Hi Tejas,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next v5.17-rc8 next-20220316]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Tejas-Upadhyay/drm-i915-gt-preempt-engine-to-idle-before-reset/20220316-215054
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a005 
(https://download.01.org/0day-ci/archive/20220317/202203170430.cdmfrpye-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
a6ec1e3d798f8eab43fb3a91028c6ab04e115fcb)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/06139e9768f3f8e43bf061ae6292feb7daf07944
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Tejas-Upadhyay/drm-i915-gt-preempt-engine-to-idle-before-reset/20220316-215054
git checkout 06139e9768f3f8e43bf061ae6292feb7daf07944
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2524:7: warning: 
>> variable 'err' is used uninitialized whenever 'if' condition is false 
>> [-Wsometimes-uninitialized]
   if (READ_ONCE(el->pending[0])) {
   ^
   include/asm-generic/rwonce.h:47:28: note: expanded from macro 'READ_ONCE'
   #define READ_ONCE(x)\
   ^
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2538:9: note: 
uninitialized use occurs here
   return err;
  ^~~
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2524:3: note: remove 
the 'if' if its condition is always true
   if (READ_ONCE(el->pending[0])) {
   ^~~
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2489:6: warning: 
variable 'err' is used uninitialized whenever 'if' condition is false 
[-Wsometimes-uninitialized]
   if (*el->active) { /* preempt to idle required */
   ^~~
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2538:9: note: 
uninitialized use occurs here
   return err;
  ^~~
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2489:2: note: remove 
the 'if' if its condition is always true
   if (*el->active) { /* preempt to idle required */
   ^
   drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2462:9: note: 
initialize the variable 'err' to silence this warning
   int err;
  ^
   = 0
   2 warnings generated.


vim +2524 drivers/gpu/drm/i915/gt/intel_execlists_submission.c

c3b2b6ffcd31318 Chris Wilson   2022-03-16  2453  
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2454  /* XXX return error and force 
a full reset if we fail to
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2455   * preempt-to-idle
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2456   */
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2457  static int 
execlists_suspend(struct intel_engine_cs *engine)
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2458  {
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2459 struct 
i915_sched_engine *se = engine->sched_engine;
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2460 struct 
intel_engine_execlists * const el = >execlists;
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2461 unsigned long timeout;
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2462 int err;
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2463  
06139e9768f3f8e Tejas Upadhyay 2022-03-16  2464 if 
(!intel_engine_pm_get_if_awake(engine))
06139e9768f3f8e Tejas Upadhyay 2022-03-16  2465 return 0;
06139e9768f3f8e Tejas Upadhyay 2022-03-16  2466 ENGINE_TRACE(engine, 
"supending active engine\n");
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2467 /* Stop further 
submissions, but listen for our own preempt-to-idle */
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2468 
tasklet_disable(>tasklet);
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2469 se->tasklet.callback = 
suspend_tasklet;
c3b2b6ffcd31318 Chris Wilson   2022-03-16  2470 
taskle

[Intel-gfx] 2022 X.Org Foundation Membership deadline for voting in the election

[Lyude Paul]

The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding the election schedule and nominating process to the
membership shortly.

Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
upcoming election is 31 March 2022 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:
https://members.x.org/

Lyude Paul, on behalf of the X.Org elections committee

[Intel-gfx] 2022 X.Org Board of Directors Elections Nomination period is NOW

[Lyude Paul]

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

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

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

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

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

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

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch] (rev2)
URL   : https://patchwork.freedesktop.org/series/101426/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11370 -> Patchwork_22587


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 44)
--

  Additional (10): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-dg2-8 bat-dg2-9 
bat-adlp-6 bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1 
  Missing(4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@write:
- bat-dg1-5:  NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@fb...@write.html

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

  * igt@gem_exec_gttfill@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][3] ([i915#4086])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-6/igt@gem_exec_gttf...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][4] ([i915#4086])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@gem_exec_gttf...@basic.html

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

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

  * igt@gem_mmap@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#4083])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-6/igt@gem_m...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#4083])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][9] ([i915#4077]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-6/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4077]) +2 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#4079]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([i915#4079]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-6/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5:  NOTRUN -> [SKIP][13] ([i915#1155])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#1155])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22587/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

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

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

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

  * igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][21] ([i915#4212]) +7 similar issues
   [21]: 

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

[Yang, Fei]

>> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
>> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> index 1c82caf525c3..0ec4986e4805 100644
>> --- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> @@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32 
>> mode)
>>   
>>  intel_ring_advance(rq, cs);
>>   
>> +/* hsdes: 1809175790. No fixup needed for gen2 */
>> +rq->aux_inv_fixup = NULL;
>
> Same thing that Stuart mentioned - would it not work for instance to 
> initialize this in __i915_request_create?

I didn't try __i915_request_create because there is code like the following in 
the driver, and I'm not sure how many such allocation is there. I will give it 
a shot.
struct measure_breadcrumb {
struct i915_request rq;
struct intel_ring ring;
u32 cs[2048];
};

static int measure_breadcrumb_dw(struct intel_context *ce)
{
struct intel_engine_cs *engine = ce->engine;
struct measure_breadcrumb *frame;
int dw;

GEM_BUG_ON(!engine->gt->scratch);

frame = kzalloc(sizeof(*frame), GFP_KERNEL);
if (!frame)
return -ENOMEM;

frame->rq.engine = engine;
frame->rq.context = ce;
...
}
>> +
>>  return 0;
>>   }
>>   

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 09:34:58PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Don't just mask off all the PSF GV points when SAGV gets disabled.
> > > > This should in fact cause the Pcode to reject the request since
> > > > at least one PSF point must remain enabled at all times.
> > > 
> > > Good point, however I think this is not the full fix:
> > > 
> > > BSpec says:
> > > 
> > > "At least one GV point of each type must always remain unmasked."
> > > 
> > > and
> > > 
> > > "The GV point of each type providing the highest bandwidth 
> > >  for display must always remain unmasked."
> > > 
> > > So I guess we should then also choose thr PSF GV point with
> > > the highest bandwidth as well.
> > 
> > The spec says PSF GV is fast enough to now stall the display data
> > fetch so we don't need to restrict the PSF points here.
> 
> But why it asks to ensure that we have the PSF GV of highest bandwidth to
> stay always unmasked then?
> 
> Stan

Reviewed-by: Stanislav Lisovskiy 

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch] (rev2)
URL   : https://patchwork.freedesktop.org/series/101426/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Reject excessive SAGV block time

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> If the mailbox returns an exceesively large SAGV block time let's just
> reject it. This avoids having to worry about overflows when we add the
> SAGV block time to the wm0 latency.
> 
> We shall put the limit arbitrarily at U16_MAX. >65msec latency
> doesn't really make sense to me in any case.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 36f5bccabf64..166246fa27e4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3716,6 +3716,12 @@ static void intel_sagv_init(struct drm_i915_private 
> *i915)
>   drm_dbg_kms(>drm, "SAGV supported: %s, original SAGV block time: 
> %u us\n",
>   str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
>  
> + /* avoid overflow when adding with wm0 latency/etc. */
> + if (drm_WARN(>drm, i915->sagv_block_time_us > U16_MAX,
> +  "Excessive SAGV block time %u, ignoring\n",
> +  i915->sagv_block_time_us))
> + i915->sagv_block_time_us = 0;
> +
>   if (!intel_has_sagv(i915))
>   i915->sagv_block_time_us = 0;
>  }
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915: Rename QGV request/response bits

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Name all the ICL_PCODE_SAGV_DE_MEM_SS_CONFIG request/response
> bits in a manner that we can actually understand what they're
> doing.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_bw.c |  9 +
>  drivers/gpu/drm/i915/i915_reg.h | 18 --
>  2 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index b794545ff81d..395e48930b08 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -124,8 +124,8 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private 
> *dev_priv,
>   /* bspec says to keep retrying for at least 1 ms */
>   ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
>   points_mask,
> - ICL_PCODE_POINTS_RESTRICTED_MASK,
> - ICL_PCODE_POINTS_RESTRICTED,
> + ICL_PCODE_REP_QGV_MASK | 
> ADLS_PCODE_REP_PSF_MASK,
> + ICL_PCODE_REP_QGV_SAFE | 
> ADLS_PCODE_REP_PSF_SAFE,
>   1);
>  
>   if (ret < 0) {
> @@ -833,7 +833,7 @@ static u16 icl_qgv_points_mask(struct drm_i915_private 
> *i915)
>   if (num_psf_gv_points > 0)
>   psf_points = GENMASK(num_psf_gv_points - 1, 0);
>  
> - return ADLS_QGV_PT(qgv_points) | ADLS_PSF_PT(psf_points);
> + return ICL_PCODE_REQ_QGV_PT(qgv_points) | 
> ADLS_PCODE_REQ_PSF_PT(psf_points);
>  }
>  
>  static int intel_bw_check_data_rate(struct intel_atomic_state *state, bool 
> *changed)
> @@ -1000,7 +1000,8 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>* actually accepts as a parameter.
>*/
>   new_bw_state->qgv_points_mask =
> - ~(ADLS_QGV_PT(qgv_points) | ADLS_PSF_PT(psf_points)) &
> + ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
> +   ADLS_PCODE_REQ_PSF_PT(psf_points)) &
>   icl_qgv_points_mask(dev_priv);
>  
>   /*
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 48a12f6c19b4..504499fad97d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6720,12 +6720,18 @@
>  #define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)  (((point) << 
> 16) | (0x1 << 8))
>  #define ADL_PCODE_MEM_SS_READ_PSF_GV_INFO((0) | (0x2 << 8))
>  #define   ICL_PCODE_SAGV_DE_MEM_SS_CONFIG0xe
> -#define ICL_PCODE_POINTS_RESTRICTED  0x0
> -#define ICL_PCODE_POINTS_RESTRICTED_MASK 0xf
> -#define   ADLS_QGV_PT_MASK   REG_GENMASK(7, 0)
> -#define   ADLS_QGV_PT(x) 
> REG_FIELD_PREP(ADLS_QGV_PT_MASK, (x))
> -#define   ADLS_PSF_PT_MASK   REG_GENMASK(10, 8)
> -#define   ADLS_PSF_PT(x) 
> REG_FIELD_PREP(ADLS_PSF_PT_MASK, (x))
> +#define ICL_PCODE_REP_QGV_MASK   REG_GENMASK(1, 0)
> +#define ICL_PCODE_REP_QGV_SAFE   
> REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 0)
> +#define ICL_PCODE_REP_QGV_POLL   
> REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 1)
> +#define ICL_PCODE_REP_QGV_REJECTED   
> REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 2)
> +#define ADLS_PCODE_REP_PSF_MASK  REG_GENMASK(3, 2)
> +#define ADLS_PCODE_REP_PSF_SAFE  
> REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 0)
> +#define ADLS_PCODE_REP_PSF_POLL  
> REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 1)
> +#define ADLS_PCODE_REP_PSF_REJECTED  
> REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 2)
> +#define ICL_PCODE_REQ_QGV_PT_MASKREG_GENMASK(7, 0)
> +#define ICL_PCODE_REQ_QGV_PT(x)  
> REG_FIELD_PREP(ICL_PCODE_REQ_QGV_PT_MASK, (x))
> +#define ADLS_PCODE_REQ_PSF_PT_MASK   REG_GENMASK(10, 8)
> +#define ADLS_PCODE_REQ_PSF_PT(x) 
> REG_FIELD_PREP(ADLS_PCODE_REQ_PSF_PT_MASK, (x))
>  #define   GEN6_PCODE_READ_D_COMP 0x10
>  #define   GEN6_PCODE_WRITE_D_COMP0x11
>  #define   ICL_PCODE_EXIT_TCCOLD  0x12
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Probe whether SAGV works on pre-icl

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:43PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Instead of leaving the SAGV enable/disable to the first commit
> let's try to disable it first thing to see if we can do it or
> not (disabling SAGV is a safe thing to at any time). This avoids
> running the code in this funny intermediate state where we don't
> know if SAGV is available or not.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 906501d6b298..36f5bccabf64 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -57,6 +57,8 @@
>  #include "vlv_sideband.h"
>  #include "../../../platform/x86/intel_ips.h"
>  
> +static int intel_disable_sagv(struct drm_i915_private *dev_priv);
> +
>  struct drm_i915_clock_gating_funcs {
>   void (*init_clock_gating)(struct drm_i915_private *i915);
>  };
> @@ -3697,6 +3699,18 @@ intel_sagv_block_time(struct drm_i915_private 
> *dev_priv)
>  
>  static void intel_sagv_init(struct drm_i915_private *i915)
>  {
> + if (!intel_has_sagv(i915))
> + i915->sagv_status = I915_SAGV_NOT_CONTROLLED;
> +
> + /*
> +  * Probe to see if we have working SAGV control.
> +  * For icl+ this was already determined by intel_bw_init_hw().
> +  */
> + if (DISPLAY_VER(i915) < 11)
> + intel_disable_sagv(i915);
> +
> + drm_WARN_ON(>drm, i915->sagv_status == I915_SAGV_UNKNOWN);
> +
>   i915->sagv_block_time_us = intel_sagv_block_time(i915);
>  
>   drm_dbg_kms(>drm, "SAGV supported: %s, original SAGV block time: 
> %u us\n",
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2 5/8] drm/i915: Rename pre-icl SAGV enable/disable functions

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Give the pre-icl SAGV control functions a skl_ prefix instead
> of the intel_ prefix to make it a bit more clear that they
> are not some kind of universal things that can be called on
> any platform. Also make the functions void since we never
> use the return value anyway.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 32 ++--
>  1 file changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 166246fa27e4..bd936d4c5b0f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -57,7 +57,7 @@
>  #include "vlv_sideband.h"
>  #include "../../../platform/x86/intel_ips.h"
>  
> -static int intel_disable_sagv(struct drm_i915_private *dev_priv);
> +static void skl_sagv_disable(struct drm_i915_private *dev_priv);
>  
>  struct drm_i915_clock_gating_funcs {
>   void (*init_clock_gating)(struct drm_i915_private *i915);
> @@ -3707,7 +3707,7 @@ static void intel_sagv_init(struct drm_i915_private 
> *i915)
>* For icl+ this was already determined by intel_bw_init_hw().
>*/
>   if (DISPLAY_VER(i915) < 11)
> - intel_disable_sagv(i915);
> + skl_sagv_disable(i915);
>  
>   drm_WARN_ON(>drm, i915->sagv_status == I915_SAGV_UNKNOWN);
>  
> @@ -3737,16 +3737,15 @@ static void intel_sagv_init(struct drm_i915_private 
> *i915)
>   *  - All planes can enable watermarks for latencies >= SAGV engine block 
> time
>   *  - We're not using an interlaced display configuration
>   */
> -static int
> -intel_enable_sagv(struct drm_i915_private *dev_priv)
> +static void skl_sagv_enable(struct drm_i915_private *dev_priv)
>  {
>   int ret;
>  
>   if (!intel_has_sagv(dev_priv))
> - return 0;
> + return;
>  
>   if (dev_priv->sagv_status == I915_SAGV_ENABLED)
> - return 0;
> + return;
>  
>   drm_dbg_kms(_priv->drm, "Enabling SAGV\n");
>   ret = snb_pcode_write(dev_priv, GEN9_PCODE_SAGV_CONTROL,
> @@ -3761,26 +3760,24 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
>   if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
>   drm_dbg(_priv->drm, "No SAGV found on system, ignoring\n");
>   dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
> - return 0;
> + return;
>   } else if (ret < 0) {
>   drm_err(_priv->drm, "Failed to enable SAGV\n");
> - return ret;
> + return;
>   }
>  
>   dev_priv->sagv_status = I915_SAGV_ENABLED;
> - return 0;
>  }
>  
> -static int
> -intel_disable_sagv(struct drm_i915_private *dev_priv)
> +static void skl_sagv_disable(struct drm_i915_private *dev_priv)
>  {
>   int ret;
>  
>   if (!intel_has_sagv(dev_priv))
> - return 0;
> + return;
>  
>   if (dev_priv->sagv_status == I915_SAGV_DISABLED)
> - return 0;
> + return;
>  
>   drm_dbg_kms(_priv->drm, "Disabling SAGV\n");
>   /* bspec says to keep retrying for at least 1 ms */
> @@ -3795,14 +3792,13 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
>   if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
>   drm_dbg(_priv->drm, "No SAGV found on system, ignoring\n");
>   dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
> - return 0;
> + return;
>   } else if (ret < 0) {
>   drm_err(_priv->drm, "Failed to disable SAGV (%d)\n", ret);
> - return ret;
> + return;
>   }
>  
>   dev_priv->sagv_status = I915_SAGV_DISABLED;
> - return 0;
>  }
>  
>  static void skl_sagv_pre_plane_update(struct intel_atomic_state *state)
> @@ -3815,7 +3811,7 @@ static void skl_sagv_pre_plane_update(struct 
> intel_atomic_state *state)
>   return;
>  
>   if (!intel_can_enable_sagv(i915, new_bw_state))
> - intel_disable_sagv(i915);
> + skl_sagv_disable(i915);
>  }
>  
>  static void skl_sagv_post_plane_update(struct intel_atomic_state *state)
> @@ -3828,7 +3824,7 @@ static void skl_sagv_post_plane_update(struct 
> intel_atomic_state *state)
>   return;
>  
>   if (intel_can_enable_sagv(i915, new_bw_state))
> - intel_enable_sagv(i915);
> + skl_sagv_enable(i915);
>  }
>  
>  static void icl_sagv_pre_plane_update(struct intel_atomic_state *state)
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Unconfuses QGV vs. PSF point masks

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use separate bitmasks for QGV vs. PSF GV points during
> the computation. Makes the whole thing a lot less confusing.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 35 -
>  drivers/gpu/drm/i915/i915_reg.h |  3 ++-
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index adf58c58513b..b794545ff81d 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -820,7 +820,7 @@ static u16 icl_qgv_points_mask(struct drm_i915_private 
> *i915)
>  {
>   unsigned int num_psf_gv_points = i915->max_bw[0].num_psf_gv_points;
>   unsigned int num_qgv_points = i915->max_bw[0].num_qgv_points;
> - u16 mask = 0;
> + u16 qgv_points = 0, psf_points = 0;
>  
>   /*
>* We can _not_ use the whole ADLS_QGV_PT_MASK here, as PCode rejects
> @@ -828,12 +828,12 @@ static u16 icl_qgv_points_mask(struct drm_i915_private 
> *i915)
>* So need to operate only with those returned from PCode.
>*/
>   if (num_qgv_points > 0)
> - mask |= REG_GENMASK(num_qgv_points - 1, 0);
> + qgv_points = GENMASK(num_qgv_points - 1, 0);
>  
>   if (num_psf_gv_points > 0)
> - mask |= REG_GENMASK(num_psf_gv_points - 1, 0) << 
> ADLS_PSF_PT_SHIFT;
> + psf_points = GENMASK(num_psf_gv_points - 1, 0);
>  
> - return mask;
> + return ADLS_QGV_PT(qgv_points) | ADLS_PSF_PT(psf_points);
>  }
>  
>  static int intel_bw_check_data_rate(struct intel_atomic_state *state, bool 
> *changed)
> @@ -890,7 +890,7 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>   unsigned int data_rate;
>   unsigned int num_active_planes;
>   int i, ret;
> - u32 allowed_points = 0;
> + u16 qgv_points = 0, psf_points = 0;
>   unsigned int max_bw_point = 0, max_bw = 0;
>   unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
>   unsigned int num_psf_gv_points = dev_priv->max_bw[0].num_psf_gv_points;
> @@ -948,7 +948,7 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>   max_bw = max_data_rate;
>   }
>   if (max_data_rate >= data_rate)
> - allowed_points |= REG_FIELD_PREP(ADLS_QGV_PT_MASK, 
> BIT(i));
> + qgv_points |= BIT(i);
>  
>   drm_dbg_kms(_priv->drm, "QGV point %d: max bw %d required 
> %d\n",
>   i, max_data_rate, data_rate);
> @@ -958,7 +958,7 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>   unsigned int max_data_rate = adl_psf_bw(dev_priv, i);
>  
>   if (max_data_rate >= data_rate)
> - allowed_points |= REG_FIELD_PREP(ADLS_PSF_PT_MASK, 
> BIT(i));
> + psf_points |= BIT(i);
>  
>   drm_dbg_kms(_priv->drm, "PSF GV point %d: max bw %d"
>   " required %d\n",
> @@ -970,20 +970,18 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>* left, so if we couldn't - simply reject the configuration for obvious
>* reasons.
>*/
> - if ((allowed_points & ADLS_QGV_PT_MASK) == 0) {
> + if (qgv_points == 0) {
>   drm_dbg_kms(_priv->drm, "No QGV points provide sufficient 
> memory"
>   " bandwidth %d for display configuration(%d active 
> planes).\n",
>   data_rate, num_active_planes);
>   return -EINVAL;
>   }
>  
> - if (num_psf_gv_points > 0) {
> - if ((allowed_points & ADLS_PSF_PT_MASK) == 0) {
> - drm_dbg_kms(_priv->drm, "No PSF GV points provide 
> sufficient memory"
> - " bandwidth %d for display configuration(%d 
> active planes).\n",
> - data_rate, num_active_planes);
> - return -EINVAL;
> - }
> + if (num_psf_gv_points > 0 && psf_points == 0) {
> + drm_dbg_kms(_priv->drm, "No PSF GV points provide 
> sufficient memory"
> + " bandwidth %d for display configuration(%d active 
> planes).\n",
> + data_rate, num_active_planes);
> + return -EINVAL;
>   }
>  
>   /*
> @@ -992,16 +990,17 @@ int intel_bw_atomic_check(struct intel_atomic_state 
> *state)
>* cause.
>*/
>   if (!intel_can_enable_sagv(dev_priv, new_bw_state)) {
> - allowed_points &= ADLS_PSF_PT_MASK;
> - allowed_points |= BIT(max_bw_point);
> + qgv_points = BIT(max_bw_point);
>   drm_dbg_kms(_priv->drm, "No SAGV, using single QGV point 
> %d\n",
>   

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Rework SAGV block time probing

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> I'd like to see the SAGV block time we got from the mailbox
> in the logs regardless of whether other factors prevent the
> use of SAGV.
> 
> So let's adjust the code to always query the SAGV block time,
> log it, and then reset it if SAGV is not actually supported.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 36 +++--
>  1 file changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 40a3094e55ca..906501d6b298 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3670,8 +3670,8 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
>   dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
>  }
>  
> -static void
> -skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
> +static u32
> +intel_sagv_block_time(struct drm_i915_private *dev_priv)
>  {
>   if (DISPLAY_VER(dev_priv) >= 12) {
>   u32 val = 0;
> @@ -3680,23 +3680,30 @@ skl_setup_sagv_block_time(struct drm_i915_private 
> *dev_priv)
>   ret = snb_pcode_read(dev_priv,
>GEN12_PCODE_READ_SAGV_BLOCK_TIME_US,
>, NULL);
> - if (!ret) {
> - dev_priv->sagv_block_time_us = val;
> - return;
> + if (ret) {
> + drm_dbg_kms(_priv->drm, "Couldn't read SAGV block 
> time!\n");
> + return 0;
>   }
>  
> - drm_dbg(_priv->drm, "Couldn't read SAGV block time!\n");
> + return val;
>   } else if (DISPLAY_VER(dev_priv) == 11) {
> - dev_priv->sagv_block_time_us = 10;
> - return;
> - } else if (DISPLAY_VER(dev_priv) == 9) {
> - dev_priv->sagv_block_time_us = 30;
> - return;
> + return 10;
> + } else if (DISPLAY_VER(dev_priv) == 9 && !IS_LP(dev_priv)) {
> + return 30;
>   } else {
> - MISSING_CASE(DISPLAY_VER(dev_priv));
> + return 0;
>   }
> +}
>  
> - dev_priv->sagv_block_time_us = 0;
> +static void intel_sagv_init(struct drm_i915_private *i915)
> +{
> + i915->sagv_block_time_us = intel_sagv_block_time(i915);
> +
> + drm_dbg_kms(>drm, "SAGV supported: %s, original SAGV block time: 
> %u us\n",
> + str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
> +
> + if (!intel_has_sagv(i915))
> + i915->sagv_block_time_us = 0;
>  }
>  
>  /*
> @@ -8175,8 +8182,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
>   else if (GRAPHICS_VER(dev_priv) == 5)
>   ilk_get_mem_freq(dev_priv);
>  
> - if (intel_has_sagv(dev_priv))
> - skl_setup_sagv_block_time(dev_priv);
> + intel_sagv_init(dev_priv);
>  
>   /* For FIFO watermark updates */
>   if (DISPLAY_VER(dev_priv) >= 9) {
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled

[Lisovskiy, Stanislav]

On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn't true, and it'll allow us to:
> - use the same code regardless of older vs. newer platform
> - wm latencies already treat 0 as disabled, so this fits well
>   with other related code
> - make it a bit more clear when SAGV is used vs. not
> - avoid overflows from adding U32_MAX with a u16 wm0 latency value
>   which could cause us to miscalculate the SAGV watermarks on tgl+
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ee31c9590a7..40a3094e55ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private 
> *dev_priv)
>   MISSING_CASE(DISPLAY_VER(dev_priv));
>   }
>  
> - /* Default to an unusable block time */
> - dev_priv->sagv_block_time_us = -1;
> + dev_priv->sagv_block_time_us = 0;
>  }
>  
>  /*
> @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct 
> intel_crtc_state *crtc_state,
>   result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
>   result->enable = true;
>  
> - if (DISPLAY_VER(dev_priv) < 12)
> + if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
>   result->can_sagv = latency >= dev_priv->sagv_block_time_us;
>  }
>  
> @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct 
> intel_crtc_state *crtc_state,
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>   struct skl_wm_level *sagv_wm = _wm->sagv.wm0;
>   struct skl_wm_level *levels = plane_wm->wm;
> - unsigned int latency = dev_priv->wm.skl_latency[0] + 
> dev_priv->sagv_block_time_us;
> + unsigned int latency = 0;
> +
> + if (dev_priv->sagv_block_time_us)
> + latency = dev_priv->sagv_block_time_us + 
> dev_priv->wm.skl_latency[0];
>  
>   skl_compute_plane_wm(crtc_state, plane, 0, latency,
>wm_params, [0],
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup

[Navare, Manasi]

On Wed, Mar 16, 2022 at 09:48:17AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2022, Manasi Navare  wrote:
> > This patch abstracts pieces of hsw_crtc_enable corresponding to different
> > Bspec enable sequence steps into separate functions.
> > This helps to call them in a specific order for bigjoiner master/slave
> > in a cleaner fashion.
> 
> So does this contain only refactoring or functional changes also? One or
> the other at a time, please, not both.

No this is only refactor, no functional changes here

> 
> Also looks like hsw_crtc_* have accumulated just way too many checks for
> platforms instead of having a clean break at e.g. display 9 and/or 11.

These checks were already part of hsw_crtc_enable() function that I have just 
moved to a separate
function. How do you recommend removing these checks?

> 
> Adding references to "enable sequence step 8" is not helpful because
> it's platform specific. (Yeah, I know there are existing references like
> this, but they're also suspect.)

Yes agree, may be I will add the comment for what actually the step 7/8 does?

Manasi

> 
> 
> BR,
> Jani.
> 
> 
> >
> > Cc: Ville Syrjälä 
> > Cc: Animesh Manna 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
> >  1 file changed, 66 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index eb49973621f0..d8e6466c9fa0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const struct 
> > intel_crtc_state *crtc_state)
> > intel_de_write(dev_priv, reg, val);
> >  }
> >  
> > -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> > -const struct intel_crtc_state 
> > *crtc_state)
> > -{
> > -   struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> > -
> > -   /*
> > -* Enable sequence steps 1-7 on bigjoiner master
> > -*/
> > -   if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > -   intel_encoders_pre_pll_enable(state, master_crtc);
> > -
> > -   if (crtc_state->shared_dpll)
> > -   intel_enable_shared_dpll(crtc_state);
> > -
> > -   if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > -   intel_encoders_pre_enable(state, master_crtc);
> > -}
> > -
> >  static void hsw_configure_cpu_transcoder(const struct intel_crtc_state 
> > *crtc_state)
> >  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const 
> > struct intel_crtc_state *crtc_sta
> > hsw_set_transconf(crtc_state);
> >  }
> >  
> > -static void hsw_crtc_enable(struct intel_atomic_state *state,
> > -   struct intel_crtc *crtc)
> > +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> > +   const struct intel_crtc_state *crtc_state)
> >  {
> > -   const struct intel_crtc_state *new_crtc_state =
> > -   intel_atomic_get_new_crtc_state(state, crtc);
> > -   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > -   enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > -   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> > -   bool psl_clkgate_wa;
> > -
> > -   if (drm_WARN_ON(_priv->drm, crtc->active))
> > -   return;
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >  
> > -   if (!new_crtc_state->bigjoiner_pipes) {
> > -   intel_encoders_pre_pll_enable(state, crtc);
> > +   /*
> > +* Enable sequence steps 1 - 7 on all pipes
> > +*/
> > +   intel_encoders_pre_pll_enable(state, crtc);
> > +   if (crtc_state->shared_dpll)
> > +   intel_enable_shared_dpll(crtc_state);
> >  
> > -   if (new_crtc_state->shared_dpll)
> > -   intel_enable_shared_dpll(new_crtc_state);
> > +   intel_encoders_pre_enable(state, crtc);
> > +}
> >  
> > -   intel_encoders_pre_enable(state, crtc);
> > -   } else {
> > -   icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
> > -   }
> > +static void hsw_crtc_post_pll_enable(struct intel_atomic_state *state,
> > +const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> > +   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +   bool psl_clkgate_wa;
> >  
> > -   intel_dsc_enable(new_crtc_state);
> > +   /*
> > +* Enable sequence step 8
> > +*/
> > +   intel_dsc_enable(crtc_state);
> >  
> > if (DISPLAY_VER(dev_priv) >= 13)
> > -   intel_uncompressed_joiner_enable(new_crtc_state);
> > +   

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as an error

[Vudum, Lakshminarayana]

I have re-opened this issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/2995

Lakshmi.

-Original Message-
From: Auld, Matthew  
Sent: Wednesday, March 16, 2022 2:15 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] 
drm/i915/lmem: don't treat small BAR as an error

On 16/03/2022 00:38, Patchwork wrote:
> *Patch Details*
> *Series:* series starting with [CI,1/7] drm/i915/lmem: don't treat small 
> BAR as an error
> *URL:*https://patchwork.freedesktop.org/series/101398/ 
> 
> *State:*  failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/index.html
> 
> 
> 
>   CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22576_full
> 
> 
> Summary
> 
> *FAILURE*
> 
> Serious unknown changes coming with Patchwork_22576_full absolutely 
> need to be verified manually.
> 
> If you think the reported changes have nothing to do with the changes 
> introduced in Patchwork_22576_full, please notify your bug team to 
> allow them to document this new failure mode, which will reduce false 
> positives in CI.
> 
> 
> Participating hosts (13 -> 13)
> 
> No changes in participating hosts
> 
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_22576_full:
> 
> 
>   IGT changes
> 
> 
> Possible regressions
> 
>   * igt@kms_sequence@queue-busy:
>   o shard-skl: PASS
> 
> 
> -> FAIL
> 
>  gt@kms_seque...@queue-busy.html>

Looks to be unrelated.

> 
> 
> Suppressed
> 
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
> 
>   *
> 
> igt@gem_ccs@block-copy-inplace:
> 
>   o {shard-dg1}: NOTRUN -> SKIP
> 
> 
>   *
> 
> igt@gem_eio@in-flight-suspend:
> 
>   o {shard-rkl}: PASS
> 
> 
> -> FAIL
> 
>  igt@gem_...@in-flight-suspend.html>
> 
> 
> Known issues
> 
> Here are the changes found in Patchwork_22576_full that come from 
> known
> issues:
> 
> 
>   IGT changes
> 
> 
> Issues hit
> 
>   *
> 
> igt@feature_discovery@chamelium:
> 
>   o shard-iclb: NOTRUN -> SKIP
> 
> 
> ([fdo#111827])
>   *
> 
> igt@gem_eio@unwedge-stress:
> 
>   o
> 
> shard-tglb: PASS
> 
> 
> -> FAIL
> 
> 
> ([i915#232])
> 
>   o
> 
> shard-skl: PASS
> 
> 
> -> TIMEOUT
> 
> 
> ([i915#3063])
> 
>   *
> 
> igt@gem_exec_fair@basic-deadline:
> 
>   o shard-skl: NOTRUN -> FAIL
> 
> 
> ([i915#2846])
>   *
> 
> igt@gem_exec_fair@basic-none-vip@rcs0:
> 
>   o shard-tglb: PASS
> 
> 
> -> FAIL
> 
> 
> ([i915#2842])
>   *
> 
> igt@gem_exec_fair@basic-none@vecs0:
> 
>   o shard-apl: PASS
> 
> 
> -> FAIL
> 
> 
> ([i915#2842])
>   *
> 
> igt@gem_exec_fair@basic-pace-solo@rcs0:
> 
>   o shard-iclb: PASS
> 
> 
> -> FAIL
> 
> 
>  

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as an error

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as 
an error
URL   : https://patchwork.freedesktop.org/series/101398/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22576_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-rkl-1/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-rkl-4/igt@gem_...@in-flight-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#232])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-tglb7/igt@gem_...@unwedge-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-tglb8/igt@gem_...@unwedge-stress.html
- shard-skl:  [PASS][6] -> [TIMEOUT][7] ([i915#3063])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-skl4/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-skl7/igt@gem_...@unwedge-stress.html

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

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-tglb3/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-iclb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-iclb8/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html

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

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk:  [PASS][18] -> [DMESG-WARN][19] ([i915#118])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-glk9/igt@gem_exec_whis...@basic-fds-forked-all.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-glk5/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-iclb2/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-apl2/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-skl:  NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613]) +4 
similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/shard-skl4/igt@gem_lmem_swapp...@parallel-random.html

  * 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Refactor slpc shared data access to use iosys_map

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor slpc shared data access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/101430/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11368_full -> Patchwork_22585_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 10)
--

  Missing(2): shard-rkl shard-tglu 

Possible new issues
---

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

### Piglit changes ###

 Possible regressions 

  * spec@ext_transform_feedback@query-primitives_written-bufferrange:
- pig-kbl-iris:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/pig-kbl-iris/spec@ext_transform_feedback@query-primitives_written-bufferrange.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

Re: [Intel-gfx] [RFC PATCH 5/7] drm/ttm: add range busy check for range manager

[Robert Beckett]

On 16/03/2022 14:39, Christian König wrote:

Am 16.03.22 um 15:26 schrieb Robert Beckett:


[SNIP]
this is where I replace an existing range check via drm_mm with the 
range check I added in this patch.


Mhm, I still don't get the use case from the code, but I don't think it 
matters any more.


I suppose we could add another drm_mm range tracker just for testing 
and shadow track each allocation in the range, but that seemed like 
a lot of extra infrastructure for no general runtime use.


I have no idea what you mean with that.


I meant as a potential solution to tracking allocations without a 
range check, we would need to add something external. e.g. adding a 
shadow drm_mm range tracker, or a bitmask across the range, or stick 
objects in a list etc.


Ah! So you are trying to get access to the drm_mm inside the 
ttm_range_manager and not add some additional range check function! Now 
I got your use case.


well, specifically I was trying to avoid having to get access to the drm_mm.
I wanted to maintain an abstract interface at the resource manager 
level, hence the rfc to ask if we could add a range check to 
ttm_resource_manager_func.


I don't like the idea of code external to ttm having to poke in to the 
implementation details of the manager to get it's underlying drm_mm.




would you mind explaining the rationale for removing range checks? 
It seems to me like a natural fit for a memory manager


TTM manages buffer objects and resources, not address space. The 
lpfn/fpfn parameter for the resource allocators are actually used as 
just two independent parameters and not define any range. We just 
keep the names for historical reasons.


The only places we still use and compare them as ranges are 
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already 
have patches to clean up those and move them into the backend 
resource handling.


except the ttm_range_manager seems to still use them as a range 
specifier.


Yeah, because the range manager is the backend which handles ranges 
using the drm_mm :)


If the general design going forward is to not consider ranges, how 
would you recommend constructing buffers around pre-allocated regions 
e.g. uefi frame buffers who's range is dictated externally?


Call ttm_bo_mem_space() with the fpfn/lpfn filled in as required. See 
function amdgpu_bo_create_kernel_at() for an example.


ah, I see, thanks.

To allow similar code to before, which was conceptually just trying to 
see if a range was currently free, would you be okay with a new 
ttm_bo_mem_try_space, which does not do the force to evict, but instead 
returns -EBUSY?


If so, the test can try to alloc, and immediately free if successful 
which would imply it was free.




Regards,
Christian.





Regards,
Christian.





Regards,
Christian.



Signed-off-by: Robert Beckett 
---
  drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
  include/drm/ttm/ttm_range_manager.h |  3 +++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c

index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct 
ttm_device *bdev,

  return 0;
  }
  EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated 
with a range

+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false 
otherwise.

+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn)
+{
+    struct ttm_range_manager *rman = to_range_manager(man);
+    struct drm_mm *mm = >mm;
+
+    if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn 
+ 1) - 1))

+    return true;
+    return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h 
b/include/drm/ttm/ttm_range_manager.h

index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int 
ttm_range_man_fini(struct ttm_device *bdev,
  BUILD_BUG_ON(__builtin_constant_p(type) && type >= 
TTM_NUM_MEM_TYPES);

  return ttm_range_man_fini_nocheck(bdev, type);
  }
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn);
  #endif

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gt: preempt engine to idle before reset

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gt: preempt engine to idle before 
reset
URL   : https://patchwork.freedesktop.org/series/101432/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11368 -> Patchwork_22586


Summary
---

  **FAILURE**

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

Participating hosts (48 -> 44)
--

  Additional (4): bat-rpls-1 bat-dg2-9 bat-dg1-6 bat-dg1-5 
  Missing(8): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 
shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-snb-2600/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-snb-2600/igt@core_hotunp...@unbind-rebind.html
- fi-snb-2520m:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-snb-2520m/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-snb-2520m/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_hangman@error-state-basic:
- fi-kbl-guc: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-kbl-guc/igt@i915_hang...@error-state-basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-kbl-guc/igt@i915_hang...@error-state-basic.html
- fi-kbl-8809g:   [PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-kbl-8809g/igt@i915_hang...@error-state-basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-kbl-8809g/igt@i915_hang...@error-state-basic.html
- bat-dg1-5:  NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/bat-dg1-5/igt@i915_hang...@error-state-basic.html
- fi-cfl-8700k:   [PASS][10] -> [FAIL][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-cfl-8700k/igt@i915_hang...@error-state-basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-cfl-8700k/igt@i915_hang...@error-state-basic.html
- fi-kbl-x1275:   [PASS][12] -> [FAIL][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-kbl-x1275/igt@i915_hang...@error-state-basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-kbl-x1275/igt@i915_hang...@error-state-basic.html
- fi-skl-6700k2:  [PASS][14] -> [FAIL][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-skl-6700k2/igt@i915_hang...@error-state-basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-skl-6700k2/igt@i915_hang...@error-state-basic.html
- fi-skl-guc: [PASS][16] -> [FAIL][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-skl-guc/igt@i915_hang...@error-state-basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-skl-guc/igt@i915_hang...@error-state-basic.html
- fi-kbl-7567u:   [PASS][18] -> [FAIL][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-kbl-7567u/igt@i915_hang...@error-state-basic.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-kbl-7567u/igt@i915_hang...@error-state-basic.html
- fi-glk-j4005:   [PASS][20] -> [FAIL][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-glk-j4005/igt@i915_hang...@error-state-basic.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-glk-j4005/igt@i915_hang...@error-state-basic.html
- fi-cfl-guc: [PASS][22] -> [FAIL][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-cfl-guc/igt@i915_hang...@error-state-basic.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-cfl-guc/igt@i915_hang...@error-state-basic.html
- fi-tgl-1115g4:  [PASS][24] -> [FAIL][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-tgl-1115g4/igt@i915_hang...@error-state-basic.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22586/fi-tgl-1115g4/igt@i915_hang...@error-state-basic.html
- fi-bxt-dsi: [PASS][26] -> [FAIL][27]
   [26]: 

Re: [Intel-gfx] [PATCH] drm/i915: Reject unsupported TMDS rates on ICL+

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, March 11, 2022 11:29 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Subject: [Intel-gfx] [PATCH] drm/i915: Reject unsupported TMDS rates on ICL+
> 
> From: Ville Syrjälä 
> 
> ICL+ PLLs can't genenerate certain frequencies. Running the PLL
> algorithms through for all frequencies 25-594MHz we see a gap just above 500
> MHz. Specifically 500-522.8MHZ for TC PLLs, and 500-533.2 MHz for combo PHY
> PLLs. Reject those frequencies hdmi_port_clock_valid() so that we properly 
> filter
> out unsupported modes and/or color depths for HDMI.
> 
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5247
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Mika Kahola 

> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index f3e688f739f3..a4a6f8bd2841 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1837,6 +1837,7 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
> bool has_hdmi_sink)
>  {
>   struct drm_i915_private *dev_priv = intel_hdmi_to_i915(hdmi);
> + enum phy phy = intel_port_to_phy(dev_priv,
> +hdmi_to_dig_port(hdmi)->base.port);
> 
>   if (clock < 25000)
>   return MODE_CLOCK_LOW;
> @@ -1857,6 +1858,14 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
>   if (IS_CHERRYVIEW(dev_priv) && clock > 216000 && clock < 24)
>   return MODE_CLOCK_RANGE;
> 
> + /* ICL+ combo PHY PLL can't generate 500-533.2 MHz */
> + if (intel_phy_is_combo(dev_priv, phy) && clock > 50 && clock <
> 533200)
> + return MODE_CLOCK_RANGE;
> +
> + /* ICL+ TC PHY PLL can't generate 500-532.8 MHz */
> + if (intel_phy_is_tc(dev_priv, phy) && clock > 50 && clock < 532800)
> + return MODE_CLOCK_RANGE;
> +
>   /*
>* SNPS PHYs' MPLLB table-based programming can only handle a fixed
>* set of link rates.
> --
> 2.34.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/gt: preempt engine to idle before reset

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gt: preempt engine to idle before 
reset
URL   : https://patchwork.freedesktop.org/series/101432/
State : warning

== Summary ==

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

Re: [Intel-gfx] [RFC PATCH 5/7] drm/ttm: add range busy check for range manager

[Robert Beckett]

On 16/03/2022 13:43, Christian König wrote:

Am 16.03.22 um 14:19 schrieb Robert Beckett:



On 16/03/2022 09:54, Christian König wrote:

Am 15.03.22 um 19:04 schrieb Robert Beckett:

RFC: do we want this to become a generic interface in
ttm_resource_manager_func?

RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range


Well completely NAK to that. Why do you need that?

The long term goal is to completely remove the range checks from TTM 
instead.


ah, I did not know that.
I wanted it just to enable parity with a selftest that checks whether 
a range is allocated before initializing a given range with test data 
behind the allocator's back. It needs to check the range so that it 
doesn't destroy in use data.


Mhm, of hand that doesn't sounds like a valid test case. Do you have the 
code at hand?


https://patchwork.freedesktop.org/patch/478347/?series=101396=1
this is where I replace an existing range check via drm_mm with the 
range check I added in this patch.






I suppose we could add another drm_mm range tracker just for testing 
and shadow track each allocation in the range, but that seemed like a 
lot of extra infrastructure for no general runtime use.


I have no idea what you mean with that.


I meant as a potential solution to tracking allocations without a range 
check, we would need to add something external. e.g. adding a shadow 
drm_mm range tracker, or a bitmask across the range, or stick objects in 
a list etc.






would you mind explaining the rationale for removing range checks? It 
seems to me like a natural fit for a memory manager


TTM manages buffer objects and resources, not address space. The 
lpfn/fpfn parameter for the resource allocators are actually used as 
just two independent parameters and not define any range. We just keep 
the names for historical reasons.


The only places we still use and compare them as ranges are 
ttm_resource_compat() and ttm_bo_eviction_valuable() and I already have 
patches to clean up those and move them into the backend resource handling.


except the ttm_range_manager seems to still use them as a range specifier.

If the general design going forward is to not consider ranges, how would 
you recommend constructing buffers around pre-allocated regions e.g. 
uefi frame buffers who's range is dictated externally?




Regards,
Christian.





Regards,
Christian.



Signed-off-by: Robert Beckett 
---
  drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
  include/drm/ttm/ttm_range_manager.h |  3 +++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c

index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct 
ttm_device *bdev,

  return 0;
  }
  EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated 
with a range

+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false 
otherwise.

+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn)
+{
+    struct ttm_range_manager *rman = to_range_manager(man);
+    struct drm_mm *mm = >mm;
+
+    if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn + 
1) - 1))

+    return true;
+    return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h 
b/include/drm/ttm/ttm_range_manager.h

index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int 
ttm_range_man_fini(struct ttm_device *bdev,
  BUILD_BUG_ON(__builtin_constant_p(type) && type >= 
TTM_NUM_MEM_TYPES);

  return ttm_range_man_fini_nocheck(bdev, type);
  }
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn);
  #endif

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Refactor slpc shared data access to use iosys_map

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor slpc shared data access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/101430/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11368 -> Patchwork_22585


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (48 -> 44)
--

  Additional (4): bat-rpls-1 bat-dg2-9 bat-dg1-6 bat-dg1-5 
  Missing(8): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 
shard-rkl shard-dg1 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-dg1-5:  NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@fb...@eof.html

  * igt@gem_exec_gttfill@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][2] ([i915#4086])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@gem_exec_gttf...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][3] ([i915#4086])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@gem_exec_gttf...@basic.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][4] ([i915#4083])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][5] ([i915#4083])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-6:  NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@gem_tiled_pread_basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][9] ([i915#4079]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#1155])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#1155])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

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

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

  * igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#4212]) +7 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@kms_addfb_ba...@addfb25-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#4215])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
- bat-dg1-6:  NOTRUN -> [SKIP][16] ([i915#4215])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#4212]) +7 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_busy@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#4303])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@kms_b...@basic.html

  * igt@kms_chamelium@dp-hpd-fast:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([fdo#111827]) +8 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-5/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- bat-dg1-6:  NOTRUN -> [SKIP][20] ([fdo#111827]) +8 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22585/bat-dg1-6/igt@kms_chamel...@hdmi-edid-read.html

  * 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Refactor slpc shared data access to use iosys_map

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor slpc shared data access to use iosys_map
URL   : https://patchwork.freedesktop.org/series/101430/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)

[Tvrtko Ursulin]

On 16/03/2022 07:37, Kasireddy, Vivek wrote:

Hi Tvrtko,



On 15/03/2022 07:28, Kasireddy, Vivek wrote:

Hi Tvrtko, Daniel,



On 11/03/2022 09:39, Daniel Vetter wrote:

On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy  wrote:


On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.

This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.

Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.

Here is the ftrace snippet that shows the source of the ~10ms latency:
 i915_gem_object_pin_to_display_plane() {
0.102 us   |i915_gem_object_set_cache_level();
   i915_gem_object_ggtt_pin_ww() {
0.390 us   |  i915_vma_instance();
0.178 us   |  i915_vma_misplaced();
 i915_vma_unbind() {
 __i915_active_wait() {
0.082 us   |i915_active_acquire_if_busy();
0.475 us   |  }
 intel_runtime_pm_get() {
0.087 us   |intel_runtime_pm_acquire();
0.259 us   |  }
 __i915_active_wait() {
0.085 us   |i915_active_acquire_if_busy();
0.240 us   |  }
 __i915_vma_evict() {
   ggtt_unbind_vma() {
 gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us |  }
10508.516 us |   }

v2: Instead of using bigjoiner checks, determine whether a scanout
   buffer is too big by checking to see if it is possible to map
   two of them into the ggtt.

v3 (Ville):
- Count how many fb objects can be fit into the available holes
 instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.

v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.

v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
 map into the aperture.
- Account for guard pages while calculating the total size required
 for the object.
- Do not subject all objects to the heuristic check and instead
 consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.

v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
 preserve the existing behavior.

v7: (Ville)
- Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
 size < ggtt->mappable_end / 4 checks.
- Drop the redundant check that is based on previous heuristic.

v8:
- Make sure that we are holding the mutex associated with ggtt vm
 as we traverse the hole nodes.

v9: (Tvrtko)
- Use mutex_lock_interruptible_nested() instead of mutex_lock().

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Tvrtko Ursulin 
Cc: Manasi Navare 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
1 file changed, 94 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9747924cc57b..e0d731b3f215 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,6 +49,7 @@
#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -882,6 +883,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
   spin_unlock(>vma.lock);
}

+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)


Tvrtko asked 

[Intel-gfx] [PATCH 2/2] drm/i915/gt: preempt and reset based on reset domain

[Tejas Upadhyay]

When we have shared reset domains, as we the engine
may be indirectly coupled to the stalled engine, and
we need to idle the current context to prevent
collateral damage.

Suggested-by: Chris Wilson 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/gt/intel_engine.h   | 3 ++-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 ++
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 7 ++-
 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c  | 2 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 ++--
 drivers/gpu/drm/i915/selftests/i915_request.c| 5 ++---
 7 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1c0ab05c3c40..a6ea0cdd8b53 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -282,7 +282,8 @@ intel_engine_has_preempt_reset(const struct intel_engine_cs 
*engine)
if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT)
return false;
 
-   return intel_engine_has_preemption(engine);
+   return intel_engine_has_preemption(engine) &&
+  !intel_engine_has_shared_reset_domain(engine);
 }
 
 #define FORCE_VIRTUAL  BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 8080479f27aa..b28120f0158a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -472,7 +472,13 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
 static void __setup_engine_capabilities(struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
+   enum intel_engine_id id;
+   struct intel_engine_cs *e;
 
+   for_each_engine(e, engine->gt, id)
+   if ((e->reset_domain & engine->reset_domain) &&
+   e->id != engine->id)
+   engine->flags |= I915_ENGINE_HAS_SHARED_RESET_DOMAIN;
if (engine->class == VIDEO_DECODE_CLASS) {
/*
 * HEVC support is present on first engine instance
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 194155de900d..d27103b23318 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -531,6 +531,8 @@ struct intel_engine_cs {
 #define I915_ENGINE_HAS_RCS_REG_STATE  BIT(9)
 #define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
 #define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
+#define I915_ENGINE_HAS_SHARED_RESET_DOMAIN BIT(9)
+
unsigned int flags;
 
/*
@@ -598,6 +600,12 @@ intel_engine_supports_stats(const struct intel_engine_cs 
*engine)
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
 }
 
+static inline bool
+intel_engine_has_shared_reset_domain(const struct intel_engine_cs *engine)
+{
+   return engine->flags & I915_ENGINE_HAS_SHARED_RESET_DOMAIN;
+}
+
 static inline bool
 intel_engine_has_preemption(const struct intel_engine_cs *engine)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 006e2d9a53e3..9dda02956494 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2461,6 +2461,9 @@ static int execlists_suspend(struct intel_engine_cs 
*engine)
unsigned long timeout;
int err;
 
+   if (!intel_engine_pm_get_if_awake(engine))
+   return 0;
+   ENGINE_TRACE(engine, "supending active engine\n");
/* Stop further submissions, but listen for our own preempt-to-idle */
tasklet_disable(>tasklet);
se->tasklet.callback = suspend_tasklet;
@@ -2524,12 +2527,14 @@ static int execlists_suspend(struct intel_engine_cs 
*engine)
}
}
 
-   return 0;
+   goto out;
 
 err:
tasklet_disable(>tasklet);
se->tasklet.callback = execlists_submission_tasklet;
tasklet_enable(>tasklet);
+out:
+   intel_engine_pm_put(engine);
return err;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
index 273d440a53e3..939bbea7ce1b 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
@@ -356,7 +356,7 @@ static int live_heartbeat_off(void *arg)
return 0;
 
for_each_engine(engine, gt, id) {
-   if (!intel_engine_has_preemption(engine))
+   if (!intel_engine_has_preempt_reset(engine))
continue;
 
err = __live_heartbeat_off(engine);
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 09f8cd2d0e2c..3eb3496cfb7e 

[Intel-gfx] [PATCH 1/2] drm/i915/gt: preempt engine to idle before reset

[Tejas Upadhyay]

From: Chris Wilson 

We need to be able to suspend execution along an
engine and flush any active contexts away from
the HW, back into the execution queue. This is
done using a preempt-to-idle, disabling the
submission backed while sending a preemption
request to ELSP. Unpon completion of the context
switch into the preemption context, we know the
existing contexts are now idle.

This is useful for reset, as it means we can
proceed knowing that the engine is idle or hung
(and so needs a reset).

Suggested-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |   4 +-
 .../drm/i915/gt/intel_execlists_submission.c  | 131 +-
 drivers/gpu/drm/i915/gt/intel_reset.c |   9 ++
 3 files changed, 142 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index eac20112709c..194155de900d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -237,6 +237,7 @@ struct intel_engine_execlists {
 */
struct rb_root_cached virtual;
 
+   struct intel_context *preempt_context;
/**
 * @csb_write: control register for Context Switch buffer
 *
@@ -445,8 +446,9 @@ struct intel_engine_cs {
void(*irq_disable)(struct intel_engine_cs *engine);
void(*irq_handler)(struct intel_engine_cs *engine, u16 iir);
 
-   void(*sanitize)(struct intel_engine_cs *engine);
+   int (*suspend)(struct intel_engine_cs *engine);
int (*resume)(struct intel_engine_cs *engine);
+   void(*sanitize)(struct intel_engine_cs *engine);
 
struct {
void (*prepare)(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index e1470bb60f34..006e2d9a53e3 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2440,6 +2440,125 @@ static void execlists_submission_tasklet(struct 
tasklet_struct *t)
rcu_read_unlock();
 }
 
+static void suspend_tasklet(struct tasklet_struct *t)
+{
+   struct i915_sched_engine *se = from_tasklet(se, t, tasklet);
+   struct intel_engine_cs * const engine = se->private_data;
+   struct i915_request *post[EXECLIST_MAX_PORTS];
+
+   rcu_read_lock();
+   post_process_csb(post, process_csb(engine, post));
+   rcu_read_unlock();
+}
+
+/* XXX return error and force a full reset if we fail to
+ * preempt-to-idle
+ */
+static int execlists_suspend(struct intel_engine_cs *engine)
+{
+   struct i915_sched_engine *se = engine->sched_engine;
+   struct intel_engine_execlists * const el = >execlists;
+   unsigned long timeout;
+   int err;
+
+   /* Stop further submissions, but listen for our own preempt-to-idle */
+   tasklet_disable(>tasklet);
+   se->tasklet.callback = suspend_tasklet;
+   tasklet_enable(>tasklet);
+
+   /*
+* We have to wait for the HW to complete a pending context switch
+* before we can write to ELS[PQ] again. Otherwise the behaviour
+* is undefined...
+*
+* If the engine is truly hung, it will neither clear pending
+* nor respond to our preemption request. In the later case,
+* we have the dilemma of how to restore hang detection...
+*/
+   timeout = jiffies + HZ / 2;
+   while (READ_ONCE(el->pending[0]) && time_before(jiffies, timeout))
+   intel_engine_flush_submission(engine);
+   if (READ_ONCE(el->pending[0])) {
+   err = -EBUSY;
+   goto err;
+   }
+
+   if (*el->active) { /* preempt to idle required */
+   struct i915_request **pending = el->pending;
+   struct intel_context *ce = el->preempt_context;
+   u64 desc;
+   int n;
+
+   /* Always submit an empty / idle context */
+   desc = lrc_update_regs(ce, engine, ce->ring->tail);
+
+   /*
+* As we submit a dummy context, we will get two events.
+* First a preemption of the running context, causing us
+* to promote el->pending to el->inflight. And then
+* we will receive a completion event as our context
+* idles.
+*
+* We can use any dummy request here for tracking the
+* preemption events.
+*/
+   execlists_schedule_in(*el->active, 0);
+   *pending++ = i915_request_get(*el->active);
+   *pending++ = NULL;
+
+   /* Tell the HW to preempt to our special context */
+   for (n = execlists_num_ports(el); --n; )
+   

Re: [Intel-gfx] [RFC PATCH 5/7] drm/ttm: add range busy check for range manager

[Robert Beckett]

On 16/03/2022 09:54, Christian König wrote:

Am 15.03.22 um 19:04 schrieb Robert Beckett:

RFC: do we want this to become a generic interface in
ttm_resource_manager_func?

RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range


Well completely NAK to that. Why do you need that?

The long term goal is to completely remove the range checks from TTM 
instead.


ah, I did not know that.
I wanted it just to enable parity with a selftest that checks whether a 
range is allocated before initializing a given range with test data 
behind the allocator's back. It needs to check the range so that it 
doesn't destroy in use data.


I suppose we could add another drm_mm range tracker just for testing and 
shadow track each allocation in the range, but that seemed like a lot of 
extra infrastructure for no general runtime use.


would you mind explaining the rationale for removing range checks? It 
seems to me like a natural fit for a memory manager




Regards,
Christian.



Signed-off-by: Robert Beckett 
---
  drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
  include/drm/ttm/ttm_range_manager.h |  3 +++
  2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c

index 8cd4f3fb9f79..5662627bb933 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -206,3 +206,24 @@ int ttm_range_man_fini_nocheck(struct ttm_device 
*bdev,

  return 0;
  }
  EXPORT_SYMBOL(ttm_range_man_fini_nocheck);
+
+/**
+ * ttm_range_man_range_busy - Check whether anything is allocated 
with a range

+ *
+ * @man: memory manager to check
+ * @fpfn: first page number to check
+ * @lpfn: last page number to check
+ *
+ * Return: true if anything allocated within the range, false otherwise.
+ */
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn)
+{
+    struct ttm_range_manager *rman = to_range_manager(man);
+    struct drm_mm *mm = >mm;
+
+    if (__drm_mm_interval_first(mm, PFN_PHYS(fpfn), PFN_PHYS(lpfn + 
1) - 1))

+    return true;
+    return false;
+}
+EXPORT_SYMBOL(ttm_range_man_range_busy);
diff --git a/include/drm/ttm/ttm_range_manager.h 
b/include/drm/ttm/ttm_range_manager.h

index 7963b957e9ef..86794a3f9101 100644
--- a/include/drm/ttm/ttm_range_manager.h
+++ b/include/drm/ttm/ttm_range_manager.h
@@ -53,4 +53,7 @@ static __always_inline int ttm_range_man_fini(struct 
ttm_device *bdev,
  BUILD_BUG_ON(__builtin_constant_p(type) && type >= 
TTM_NUM_MEM_TYPES);

  return ttm_range_man_fini_nocheck(bdev, type);
  }
+
+bool ttm_range_man_range_busy(struct ttm_resource_manager *man,
+  unsigned fpfn, unsigned lpfn);
  #endif

Re: [Intel-gfx] [PATCH 07/22] drm/gma500: Use drm_mode_copy()

[Patrik Jakobsson]

On Fri, Feb 18, 2022 at 11:04 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, )
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(, )
> |
> - memcpy(, E, S)
> + drm_mode_copy(, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Patrik Jakobsson 
> Signed-off-by: Ville Syrjälä 

Looks good. Thanks!
Acked-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 36c7c2686c90..79fc602b35bc 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -385,12 +385,8 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
> if (!gma_power_begin(dev, true))
> return 0;
>
> -   memcpy(_crtc->saved_mode,
> -   mode,
> -   sizeof(struct drm_display_mode));
> -   memcpy(_crtc->saved_adjusted_mode,
> -   adjusted_mode,
> -   sizeof(struct drm_display_mode));
> +   drm_mode_copy(_crtc->saved_mode, mode);
> +   drm_mode_copy(_crtc->saved_adjusted_mode, adjusted_mode);
>
> list_for_each_entry(connector, _config->connector_list, head) {
> if (!connector->encoder || connector->encoder->crtc != crtc)
> --
> 2.34.1
>

[Intel-gfx] [PATCH 1/1] drm/i915/guc: Convert slpc to iosys_map

[Mullati Siva]

From: Siva Mullati 

Convert slpc shared data to use iosys_map rather than
plain pointer and save it in the intel_guc_slpc struct.
This will help with in read and update slpc shared data
after the slpc init by abstracting the IO vs system memory.

Signed-off-by: Siva Mullati 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 79 +++
 .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |  5 +-
 2 files changed, 47 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 9f032c65a488..3a9ec6b03ceb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -14,6 +14,13 @@
 #include "gt/intel_gt_regs.h"
 #include "gt/intel_rps.h"
 
+#define slpc_blob_read(slpc_, field_) \
+  iosys_map_rd_field(&(slpc_)->slpc_map, 0, \
+  struct slpc_shared_data, field_)
+#define slpc_blob_write(slpc_, field_, val_) \
+   iosys_map_wr_field(&(slpc_)->slpc_map, 0, \
+   struct slpc_shared_data, field_, val_)
+
 static inline struct intel_guc *slpc_to_guc(struct intel_guc_slpc *slpc)
 {
return container_of(slpc, struct intel_guc, slpc);
@@ -52,50 +59,50 @@ void intel_guc_slpc_init_early(struct intel_guc_slpc *slpc)
slpc->selected = __guc_slpc_selected(guc);
 }
 
-static void slpc_mem_set_param(struct slpc_shared_data *data,
+static void slpc_mem_set_param(struct intel_guc_slpc *slpc,
   u32 id, u32 value)
 {
+   u32 bits = slpc_blob_read(slpc, override_params.bits[id >> 5]);
+
GEM_BUG_ON(id >= SLPC_MAX_OVERRIDE_PARAMETERS);
/*
 * When the flag bit is set, corresponding value will be read
 * and applied by SLPC.
 */
-   data->override_params.bits[id >> 5] |= (1 << (id % 32));
-   data->override_params.values[id] = value;
+   bits |= (1 << (id % 32));
+   slpc_blob_write(slpc, override_params.bits[id >> 5], bits);
+   slpc_blob_write(slpc, override_params.values[id], value);
 }
 
-static void slpc_mem_set_enabled(struct slpc_shared_data *data,
+static void slpc_mem_set_enabled(struct intel_guc_slpc *slpc,
 u8 enable_id, u8 disable_id)
 {
/*
 * Enabling a param involves setting the enable_id
 * to 1 and disable_id to 0.
 */
-   slpc_mem_set_param(data, enable_id, 1);
-   slpc_mem_set_param(data, disable_id, 0);
+   slpc_mem_set_param(slpc, enable_id, 1);
+   slpc_mem_set_param(slpc, disable_id, 0);
 }
 
-static void slpc_mem_set_disabled(struct slpc_shared_data *data,
+static void slpc_mem_set_disabled(struct intel_guc_slpc *slpc,
  u8 enable_id, u8 disable_id)
 {
/*
 * Disabling a param involves setting the enable_id
 * to 0 and disable_id to 1.
 */
-   slpc_mem_set_param(data, disable_id, 1);
-   slpc_mem_set_param(data, enable_id, 0);
+   slpc_mem_set_param(slpc, disable_id, 1);
+   slpc_mem_set_param(slpc, enable_id, 0);
 }
 
 static u32 slpc_get_state(struct intel_guc_slpc *slpc)
 {
-   struct slpc_shared_data *data;
-
GEM_BUG_ON(!slpc->vma);
 
-   drm_clflush_virt_range(slpc->vaddr, sizeof(u32));
-   data = slpc->vaddr;
+   drm_clflush_virt_range(slpc->slpc_map.vaddr, sizeof(u32));
 
-   return data->header.global_state;
+   return slpc_blob_read(slpc, header.global_state);
 }
 
 static int guc_action_slpc_set_param(struct intel_guc *guc, u8 id, u32 value)
@@ -156,7 +163,7 @@ static int slpc_query_task_state(struct intel_guc_slpc 
*slpc)
drm_err(>drm, "Failed to query task state (%pe)\n",
ERR_PTR(ret));
 
-   drm_clflush_virt_range(slpc->vaddr, SLPC_PAGE_SIZE_BYTES);
+   drm_clflush_virt_range(slpc->slpc_map.vaddr, SLPC_PAGE_SIZE_BYTES);
 
return ret;
 }
@@ -243,10 +250,11 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
struct drm_i915_private *i915 = slpc_to_i915(slpc);
u32 size = PAGE_ALIGN(sizeof(struct slpc_shared_data));
int err;
+   void *vaddr;
 
GEM_BUG_ON(slpc->vma);
 
-   err = intel_guc_allocate_and_map_vma(guc, size, >vma, (void 
**)>vaddr);
+   err = intel_guc_allocate_and_map_vma(guc, size, >vma, (void 
**));
if (unlikely(err)) {
drm_err(>drm,
"Failed to allocate SLPC struct (err=%pe)\n",
@@ -254,6 +262,12 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
return err;
}
 
+   if (i915_gem_object_is_lmem(slpc->vma->obj))
+   iosys_map_set_vaddr_iomem(>slpc_map,
+ (void __iomem *)vaddr);
+   else
+   iosys_map_set_vaddr(>slpc_map, vaddr);
+
slpc->max_freq_softlimit = 0;
slpc->min_freq_softlimit = 0;
 
@@ -335,40 +349,37 @@ 

[Intel-gfx] [PATCH 0/1] drm/i915/guc: Refactor slpc shared data access to use iosys_map

[Mullati Siva]

From: Siva Mullati 

This is continuation to the original patch series to use iosys map
APIs to use slpc shared data commands and descriptors.
https://patchwork.freedesktop.org/series/99711/

Siva Mullati (1):
  drm/i915/guc: Convert slpc to iosys_map

 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 79 +++
 .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |  5 +-
 2 files changed, 47 insertions(+), 37 deletions(-)

-- 
2.33.0

Re: [Intel-gfx] [PATCH v2] drm: Fix a infinite loop condition when order becomes 0

[Matthew Auld]

On 16/03/2022 06:34, Arunpravin Paneer Selvam wrote:

handle a situation in the condition order-- == min_order,
when order = 0 and min_order = 0, leading to order = -1,
it now won't exit the loop. To avoid this problem,
added a order check in the same condition, (i.e)
when order is 0, we return -ENOSPC

v2: use full name in email program and in Signed-off tag

Signed-off-by: Arunpravin Paneer Selvam 
---
  drivers/gpu/drm/drm_buddy.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
  
-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {


It shouldn't be possible to enter an infinite loop here, without first 
tripping up the BUG_ON(order < min_order) further up, and for that, as 
we discussed here[1], it sounded like the conclusion was to rather add a 
simple check somewhere in drm_buddy_alloc_blocks() to reject any size 
not aligned to the min_page_size?


[1] https://patchwork.freedesktop.org/patch/477414/?series=101108=1


err = -ENOSPC;
goto err_free;
}

base-commit: 3bd60c0259406c5ca3ce5cdc958fb910ad4b8175

Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2022-03-14 17:35:17)
> 
> On 12/03/2022 04:16, Matt Atwood wrote:
> > On Thu, Mar 10, 2022 at 12:26:12PM +, Tvrtko Ursulin wrote:
> >>
> >> On 10/03/2022 05:18, Matt Atwood wrote:
> >>> Newer platforms have DSS that aren't necessarily available for both
> >>> geometry and compute, two queries will need to exist. This introduces
> >>> the first, when passing a valid engine class and engine instance in the
> >>> flags returns a topology describing geometry.
> >>>
> >>> v2: fix white space errors
> >>>
> >>> Cc: Ashutosh Dixit 
> >>> Cc: Matt Roper 
> >>> Cc: Joonas Lahtinen 
> >>> UMD (mesa): 
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
> >>> Signed-off-by: Matt Atwood 



> >>> @@ -2714,6 +2715,9 @@ struct drm_i915_query_item {
> >>>  *  - DRM_I915_QUERY_PERF_CONFIG_LIST
> >>>  *  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> >>>  *  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> >>> +*
> >>> +* When query_id == DRM_I915_QUERY_GEOMETRY_SUBSLICES must have bits 
> >>> 0:7 set
> >>> +* as a valid engine class, and bits 8:15 must have a valid engine 
> >>> instance.
> >>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
> 
> Yes, shrug... Neither I can't guess if we are ever likely to hit a 
> problem by having fewer bits for class:instance here compared to other 
> uapi, or if stuffing struct i915_engine_class_instance into flags would 
> just be too ugly. I mean there is option to define a new struct and not 
> use flags at all but that's probably to complicated for what it is.
> 
> Anyone else with an opinion? Consistency or should be fine even like it is?

Stuffing a full i915_engine_class_instance was definitely intended when
putting it into the flags was suggested.

If that is hit with a complication, the next proposed alternative was a
new struct. That's why the query interface was made easily extensible,
after all...

Regards, Joonas

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Fix a infinite loop condition when order becomes 0 (rev2)

[Patchwork]

== Series Details ==

Series: drm: Fix a infinite loop condition when order becomes 0 (rev2)
URL   : https://patchwork.freedesktop.org/series/101360/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11367_full -> Patchwork_22582_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 12)
--

  Missing(1): shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#5327])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb5/igt@gem_...@block-copy-compressed.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2410])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][6] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/shard-iclb2/igt@gem_exec_fair@basic-p...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb7/igt@gem_exec_fair@basic-p...@bcs0.html

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

  * igt@gem_lmem_swapping@basic:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-skl6/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-iclb: NOTRUN -> [SKIP][11] ([i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb3/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@random-engines:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-apl2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-skl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@create-regular-buffer:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#4270])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb5/igt@gem_...@create-regular-buffer.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-y-tiled-ccs:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#768])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb3/igt@gem_render_c...@y-tiled-mc-ccs-to-y-tiled-ccs.html

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb5/igt@gem_soft...@evict-snoop-interruptible.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109289])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb3/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@unaligned-access:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#2856])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb5/igt@gen9_exec_pa...@unaligned-access.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#454])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/shard-iclb1/igt@i915_pm...@dc6-dpms.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-iclb3/igt@i915_pm...@dc6-dpms.html
- shard-skl:  NOTRUN -> [FAIL][21] ([i915#454])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/shard-skl10/igt@i915_pm...@dc6-dpms.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: NOTRUN -> [FAIL][22] ([i915#454])
   [22]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch]

[Patchwork]

== Series Details ==

Series: drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch]
URL   : https://patchwork.freedesktop.org/series/101426/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11368 -> Patchwork_22584


Summary
---

  **FAILURE**

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

Participating hosts (46 -> 38)
--

  Missing(8): fi-kbl-soraka fi-bxt-dsi shard-tglu fi-hsw-4200u bat-dg2-8 
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22584/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [DMESG-FAIL][4] ([i915#4391]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22584/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][6] ([i915#5278]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22584/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

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

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}:   [DMESG-WARN][10] ([i915#3576]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11368/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22584/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

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

  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278


Build changes
-

  * Linux: CI_DRM_11368 -> Patchwork_22584

  CI-20190529: 20190529
  CI_DRM_11368: 66b3d1ac616565206cddf4327ca7c102b651b032 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6382: a6a5a178cb1cbe0dab8d8d092a4aee932ccb93cc @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22584: f82b9b89e964c72c35d932a9401e980a01037e81 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f82b9b89e964 drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch]

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch]

[Patchwork]

== Series Details ==

Series: drm/i915: move i915_gem_object_needs_bit17_swizzle() to 
i915_gem_tiling.[ch]
URL   : https://patchwork.freedesktop.org/series/101426/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915 writeback private framework

[Patchwork]

== Series Details ==

Series: i915 writeback private framework
URL   : https://patchwork.freedesktop.org/series/101425/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11368 -> Patchwork_22583


Summary
---

  **FAILURE**

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

Participating hosts (45 -> 39)
--

  Additional (1): bat-adls-5 
  Missing(7): fi-kbl-soraka fi-hsw-4200u bat-dg2-8 fi-bsw-cyan fi-ctg-p8600 
fi-pnv-d510 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-bwr-2160:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-bwr-2160/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@runner@aborted:
- {fi-rkl-11600}: NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-rkl-11600/igt@run...@aborted.html
- {bat-jsl-2}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/bat-jsl-2/igt@run...@aborted.html
- {fi-jsl-1}: NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-jsl-1/igt@run...@aborted.html
- {bat-jsl-1}:NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/bat-jsl-1/igt@run...@aborted.html
- {fi-ehl-2}: NOTRUN -> [FAIL][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-ehl-2/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@runner@aborted:
- fi-snb-2600:NOTRUN -> [FAIL][7] ([i915#2426])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-snb-2600/igt@run...@aborted.html
- fi-ilk-650: NOTRUN -> [FAIL][8] ([i915#2426])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-ilk-650/igt@run...@aborted.html
- fi-kbl-x1275:   NOTRUN -> [FAIL][9] ([i915#2426])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-kbl-x1275/igt@run...@aborted.html
- fi-bsw-kefka:   NOTRUN -> [FAIL][10] ([i915#3690])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-bsw-kefka/igt@run...@aborted.html
- fi-bdw-gvtdvm:  NOTRUN -> [FAIL][11] ([i915#2426])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-bdw-gvtdvm/igt@run...@aborted.html
- fi-cfl-8700k:   NOTRUN -> [FAIL][12] ([i915#2426])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-cfl-8700k/igt@run...@aborted.html
- fi-cfl-8109u:   NOTRUN -> [FAIL][13] ([i915#2426])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-cfl-8109u/igt@run...@aborted.html
- fi-glk-dsi: NOTRUN -> [FAIL][14] ([i915#2426] / [k.org#202321])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-glk-dsi/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][15] ([i915#3690])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-bsw-nick/igt@run...@aborted.html
- fi-kbl-8809g:   NOTRUN -> [FAIL][16] ([i915#2426])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-kbl-8809g/igt@run...@aborted.html
- fi-snb-2520m:   NOTRUN -> [FAIL][17] ([i915#2426])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-snb-2520m/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][18] ([i915#2426])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-bdw-5557u/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][19] ([i915#5317])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-hsw-4770/igt@run...@aborted.html
- fi-kbl-7500u:   NOTRUN -> [FAIL][20] ([i915#2426])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-kbl-7500u/igt@run...@aborted.html
- fi-kbl-guc: NOTRUN -> [FAIL][21] ([i915#2426])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-kbl-guc/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][22] ([i915#2426])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22583/fi-rkl-guc/igt@run...@aborted.html
- fi-ivb-3770:

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

[Tvrtko Ursulin]

On 04/03/2022 22:14, fei.y...@intel.com wrote:

From: Fei Yang 

GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With this patch, auxiliary table invalidation is done only for the
engine executing the request. And the mmio address for the aux_inv
register is set after the engine instance becomes certain.

Signed-off-by: Chris Wilson 
Signed-off-by: Fei Yang 
---
  drivers/gpu/drm/i915/gt/gen2_engine_cs.c  |  9 +++
  drivers/gpu/drm/i915/gt/gen6_engine_cs.c  |  9 +++
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 61 ---
  .../drm/i915/gt/intel_execlists_submission.c  | 35 +++
  drivers/gpu/drm/i915/i915_request.h   |  2 +
  5 files changed, 82 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 1c82caf525c3..0ec4986e4805 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32 mode)
  
  	intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen2 */

+   rq->aux_inv_fixup = NULL;


Same thing that Stuart mentioned - would it not work for instance to 
initialize this in __i915_request_create?



+
return 0;
  }
  
@@ -123,6 +126,9 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  	intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen4 rcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -138,6 +144,9 @@ int gen4_emit_flush_vcs(struct i915_request *rq, u32 mode)

*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen4 vcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c

index 5e65550b4dfb..efe51c4662fe 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -137,6 +137,9 @@ int gen6_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen6 */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -208,6 +211,9 @@ static int mi_flush_dw(struct i915_request *rq, u32 flags)
  
  	intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen6 */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -347,6 +353,9 @@ int gen7_emit_flush_rcs(struct i915_request *rq, u32 mode)

*cs++ = 0;
intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen7 rcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c

index b1b9c3fd7bf9..b6374cf53314 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -73,6 +73,9 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  	intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen8 rcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -106,6 +109,9 @@ int gen8_emit_flush_xcs(struct i915_request *rq, u32 mode)

*cs++ = 0; /* value */
intel_ring_advance(rq, cs);
  
+	/* hsdes: 1809175790. No fixup needed for gen8 xcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq, u32 mode)

intel_ring_advance(rq, cs);
}
  
+	/* hsdes: 1809175790. No fixup needed for gen11 rcs */

+   rq->aux_inv_fixup = NULL;
+
return 0;
  }
  
@@ -165,30 +174,6 @@ static u32 preparser_disable(bool state)

return MI_ARB_CHECK | 1 << 8 | state;
  }
  
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)

-{
-   static const i915_reg_t vd[] = {
-   GEN12_VD0_AUX_NV,
-   GEN12_VD1_AUX_NV,
-   GEN12_VD2_AUX_NV,
-   GEN12_VD3_AUX_NV,
-   };
-
-   static const i915_reg_t ve[] = {
-   GEN12_VE0_AUX_NV,
-   GEN12_VE1_AUX_NV,
-   };
-
-   if (engine->class == VIDEO_DECODE_CLASS)
-   return vd[engine->instance];
-
-   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
-   return ve[engine->instance];
-
-   GEM_BUG_ON("unknown aux_inv reg\n");
-   return INVALID_MMIO_REG;
-}
-
  static u32 *gen12_emit_aux_table_inv(const i915_reg_t 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915 writeback private framework

[Patchwork]

== Series Details ==

Series: i915 writeback private framework
URL   : https://patchwork.freedesktop.org/series/101425/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 writeback private framework

[Patchwork]

== Series Details ==

Series: i915 writeback private framework
URL   : https://patchwork.freedesktop.org/series/101425/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
91a1acb1ae9e drm/i915: Creating writeback pipeline to bypass drm_writeback 
framework
-:25: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#25: 
new file mode 100644

-:59: CHECK:LINE_SPACING: Please don't use multiple blank lines
#59: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:30:
+
+

-:72: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to 
avoid precedence issues
#72: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:43:
+#define fence_to_wb_connector(x) container_of(x->lock, \
+ struct intel_writeback_connector, 
\
+ fence_lock)

-:111: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#111: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:82:
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_FB_ID",

-:130: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#130: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:101:
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_OUT_FENCE_PTR", 0,

-:145: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#145: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:116:
+int intel_writeback_connector_init(struct drm_device *dev,
+struct intel_writeback_connector *wb_connector,

-:168: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#168: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:139:
+   ret = drm_encoder_init(dev, wb_connector->encoder,
+   _writeback_encoder_funcs,

-:176: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#176: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:147:
+   ret = drm_connector_init(dev, connector, con_funcs,
+   DRM_MODE_CONNECTOR_WRITEBACK);

-:181: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#181: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:152:
+   ret = drm_connector_attach_encoder(connector,
+   wb_connector->encoder);

-:191: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#191: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:162:
+   snprintf(wb_connector->timeline_name,
+   sizeof(wb_connector->timeline_name),

-:195: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#195: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:166:
+   drm_object_attach_property(>base,
+   i915->wb_out_fence_ptr_property, 0);

-:198: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#198: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:169:
+   drm_object_attach_property(>base,
+   i915->wb_fb_id_property, 0);

-:201: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#201: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:172:
+   drm_object_attach_property(>base,
+   i915->wb_pixel_formats_property,

-:217: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#217: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:188:
+void intel_writeback_queue_job(struct intel_writeback_connector *wb_connector,
+   struct drm_connector_state *conn_state)

-:233: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#233: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:204:
+int intel_writeback_set_fb(struct drm_connector_state *conn_state,
+struct drm_framebuffer *fb)

-:276: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#276: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:247:
+intel_writeback_signal_completion(struct intel_writeback_connector 
*wb_connector,
+   int status)

-:284: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#284: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:255:
+   job = list_first_entry_or_null(_connector->job_queue,
+   struct intel_writeback_job,

-:321: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#321: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:292:
+   dma_fence_init(fence, _writeback_fence_ops,
+   _connector->fence_lock, wb_connector->fence_context,

-:378: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#378: FILE: 

[Intel-gfx] [PATCH v2] drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch]

[Jani Nikula]

Move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] as a
i915_gem_object function related to tiling. Also un-inline while at it;
does not seem like this is a function needed in hot paths.

v2: i915_gem_tiling.[ch] instead of intel_ggtt_fencing.[ch] (Chris)

Cc: Tvrtko Ursulin 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gem/i915_gem_phys.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 3 ++-
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 8 
 drivers/gpu/drm/i915/gem/i915_gem_tiling.h | 2 ++
 drivers/gpu/drm/i915/i915_drv.h| 9 -
 5 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c 
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index ca6faffcc496..0d0e46dae559 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -14,6 +14,7 @@
 #include "i915_drv.h"
 #include "i915_gem_object.h"
 #include "i915_gem_region.h"
+#include "i915_gem_tiling.h"
 #include "i915_scatterlist.h"
 
 static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 3a1c782ed791..c7541dc687c1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -12,8 +12,9 @@
 
 #include "gem/i915_gem_region.h"
 #include "i915_drv.h"
-#include "i915_gemfs.h"
 #include "i915_gem_object.h"
+#include "i915_gem_tiling.h"
+#include "i915_gemfs.h"
 #include "i915_scatterlist.h"
 #include "i915_trace.h"
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index d6adda5bf96b..80ac0db1ae8c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -219,6 +219,14 @@ i915_gem_object_fence_prepare(struct drm_i915_gem_object 
*obj,
return ret;
 }
 
+bool i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+   return to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 
&&
+   i915_gem_object_is_tiled(obj);
+}
+
 int
 i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
   unsigned int tiling, unsigned int stride)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.h 
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.h
index 9924196a8139..6bd5751abf28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.h
@@ -8,8 +8,10 @@
 
 #include 
 
+struct drm_i915_gem_object;
 struct drm_i915_private;
 
+bool i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_object *obj);
 u32 i915_gem_fence_size(struct drm_i915_private *i915, u32 size,
unsigned int tiling, unsigned int stride);
 u32 i915_gem_fence_alignment(struct drm_i915_private *i915, u32 size,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26df561a4e94..a9aceb08fcd1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1486,15 +1486,6 @@ void i915_gem_driver_release(struct drm_i915_private 
*dev_priv);
 
 int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
 
-/* i915_gem_tiling.c */
-static inline bool i915_gem_object_needs_bit17_swizzle(struct 
drm_i915_gem_object *obj)
-{
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-
-   return to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 
&&
-   i915_gem_object_is_tiled(obj);
-}
-
 /* intel_device_info.c */
 static inline struct intel_device_info *
 mkwrite_device_info(struct drm_i915_private *dev_priv)
-- 
2.30.2

[Intel-gfx] [RFC PATCH 3/3] drm/i915: Enabling WD Transcoder

[Suraj Kandpal]

Adding support for writeback transcoder to start capturing frames using
interrupt mechanism

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  85 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   9 +
 .../drm/i915/display/intel_display_types.h|  20 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 996 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 drivers/gpu/drm/i915/i915_reg.h   | 137 +++
 13 files changed, 1351 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 087bd9d1b397..5ee32513a945 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -287,6 +287,7 @@ i915-y += \
display/intel_vdsc.o \
display/intel_vrr.o \
display/intel_wb_connector.o\
+   display/intel_wd.o\
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..ae08db164f73 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector 
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index eb49973621f0..72a6faa9045b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -111,6 +111,7 @@
 #include "intel_sprite.h"
 #include "intel_tc.h"
 #include "intel_vga.h"
+#include "intel_wd.h"
 #include "i9xx_plane.h"
 #include "skl_scaler.h"
 #include "skl_universal_plane.h"
@@ -1544,6 +1545,72 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
}
 }
 
+static void intel_queue_writeback_job(struct intel_atomic_state *state,
+   struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+{
+   struct drm_connector_state *new_conn_state;
+   struct drm_connector *connector;
+   struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
+   struct intel_wd *intel_wd;
+   struct intel_connector *intel_connector;
+   struct intel_digital_connector_state *intel_conn_state;
+   struct intel_encoder *encoder;
+   int i;
+
+   for_each_intel_encoder_with_wd(>drm, encoder) {
+   intel_wd = enc_to_intel_wd(encoder);
+
+   if (intel_wd->wd_crtc != intel_crtc)
+   return;
+
+   }
+
+   for_each_new_connector_in_state(>base, connector, new_conn_state,
+   i) {
+   intel_conn_state = 
to_intel_digital_connector_state(new_conn_state);
+   if (!intel_conn_state->job)
+   continue;
+   intel_connector = to_intel_connector(connector);
+   intel_writeback_queue_job(_connector->wb_conn, 
new_conn_state);
+   drm_dbg_kms(>drm, "queueing writeback job\n");
+   }
+}
+
+static void intel_find_writeback_connector(struct intel_atomic_state *state,
+   struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+{
+   struct drm_connector_state *new_conn_state;
+   struct drm_connector *connector;
+   struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
+   struct intel_wd *intel_wd;
+   struct intel_encoder *encoder;
+   int i;
+
+   for_each_intel_encoder_with_wd(>drm, encoder) {
+   intel_wd = enc_to_intel_wd(encoder);
+
+   if (intel_wd->wd_crtc != intel_crtc)
+   return;
+
+   }
+
+   for_each_new_connector_in_state(>base, connector, new_conn_state,
+   i) {
+   struct intel_connector *intel_connector;
+
+   intel_connector = to_intel_connector(connector);
+   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s]: status: %s\n",
+   connector->base.id, connector->name,
+   
drm_get_connector_status_name(connector->status));
+   encoder = 

[Intel-gfx] [RFC PATCH 2/3] drm/i915: Define WD trancoder for i915

[Suraj Kandpal]

Adding WD Types, WD transcoder to enum list and WD Transcoder offsets

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_display.h   | 6 ++
 drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 8513703086b7..8c93a5de8e07 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -119,6 +119,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+   TRANSCODER_WD_0,
+   TRANSCODER_WD_1,
 
I915_MAX_TRANSCODERS
 };
@@ -140,6 +142,10 @@ static inline const char *transcoder_name(enum transcoder 
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+   case TRANSCODER_WD_0:
+   return "WD 0";
+   case TRANSCODER_WD_1:
+   return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d84e82f3eab9..dbd8b79bdf88 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -78,6 +78,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+   INTEL_OUTPUT_WD = 12,
 };
 
 enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ddbc7a685a50..6396afd77209 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2023,6 +2023,8 @@
 #define TRANSCODER_EDP_OFFSET 0x6f000
 #define TRANSCODER_DSI0_OFFSET 0x6b000
 #define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET  0x6e000
+#define TRANSCODER_WD1_OFFSET  0x6e800
 
 #define HTOTAL(trans)  _MMIO_TRANS2(trans, _HTOTAL_A)
 #define HBLANK(trans)  _MMIO_TRANS2(trans, _HBLANK_A)
-- 
2.35.1

[Intel-gfx] [RFC PATCH 1/3] drm/i915: Creating writeback pipeline to bypass drm_writeback framework

[Suraj Kandpal]

Changes to create a i915 private pipeline to enable the WD transcoder
without relying on the current drm_writeback framework.

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
 .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 4 files changed, 399 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1a771ee5b1d0..087bd9d1b397 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -286,6 +286,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+   display/intel_wb_connector.o\
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_wb_connector.c 
b/drivers/gpu/drm/i915/display/intel_wb_connector.c
new file mode 100644
index ..526b3e7530e0
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_wb_connector.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2022 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Suraj Kandpal 
+ * Arun Murthy 
+ *
+ */
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "intel_wb_connector.h"
+#include "intel_display_types.h"
+
+#define fence_to_wb_connector(x) container_of(x->lock, \
+ struct intel_writeback_connector, 
\
+ fence_lock)
+
+static const char *intel_writeback_fence_get_driver_name(struct dma_fence 
*fence)
+{
+   struct intel_writeback_connector *wb_connector =
+   fence_to_wb_connector(fence);
+
+   return wb_connector->base->dev->driver->name;
+}
+
+static const char *
+intel_writeback_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct intel_writeback_connector *wb_connector =
+   fence_to_wb_connector(fence);
+
+   return wb_connector->timeline_name;
+}
+
+static bool intel_writeback_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops intel_writeback_fence_ops = {
+   .get_driver_name = intel_writeback_fence_get_driver_name,
+   .get_timeline_name = intel_writeback_fence_get_timeline_name,
+   .enable_signaling = intel_writeback_fence_enable_signaling,
+};
+
+static int intel_create_writeback_properties(struct drm_device *dev)
+{
+   struct drm_property *prop;
+   struct drm_i915_private *i915 = to_i915(dev);
+
+   if (!i915->wb_fb_id_property) {
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_FB_ID",
+   DRM_MODE_OBJECT_FB);
+   if (!prop)
+   return -ENOMEM;
+   i915->wb_fb_id_property = prop;
+   }
+
+   if (!i915->wb_pixel_formats_property) {
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+   DRM_MODE_PROP_ATOMIC |
+   DRM_MODE_PROP_IMMUTABLE,
+   "WRITEBACK_PIXEL_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   i915->wb_pixel_formats_property = prop;
+   }
+
+   if (!i915->wb_out_fence_ptr_property) {
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_OUT_FENCE_PTR", 0,
+  

[Intel-gfx] [RFC PATCH 0/3] i915 writeback private framework

[Suraj Kandpal]

A patch series was floated in the drm mailing list which aimed to change
the drm_connector and drm_encoder fields to pointer in the
drm_connector_writeback structure, this received a huge pushback from
the community but since i915 expects each connector present in the
drm_device list to be a intel_connector but drm_writeback framework
forces us to use a drm_connector which is not embedded in
intel_connector the current drm_writeback framework becomes very
unfeasible to us as it would mean a lot of checks at a lot of places
to take into account the above issue. One of the solutions is to
make our own writeback pipeline bypassing one provided by drm
which is what these patches do.

Suraj Kandpal (3):
  drm/i915: Creating writeback pipeline to bypass drm_writeback
framework
  drm/i915: Define WD trancoder for i915
  drm/i915: Enabling WD Transcoder

 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  85 +-
 drivers/gpu/drm/i915/display/intel_display.h  |  15 +
 .../drm/i915/display/intel_display_types.h|  21 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
 .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
 drivers/gpu/drm/i915/display/intel_wd.c   | 996 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
 drivers/gpu/drm/i915/i915_drv.h   |   5 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 drivers/gpu/drm/i915/i915_reg.h   | 139 +++
 15 files changed, 1759 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

-- 
2.35.1

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/opregion: Cond dgfx opregion func registration

[Jani Nikula]

On Sun, 20 Feb 2022, Anshuman Gupta  wrote:
> DGFX ASLS and OPROM OpRegion are only supported on the GFX Cards,
> which supports Display Engine. Register opregion function accordingly
> using the HAS_DISPLAY(). And early return intel_opregion_setup()
> if no opregion func to avoid NULL pointer oops.
>
> v2:
> - Change the commit log.
>
> Cc: Badal Nilawar 
> Cc: Jani Nikula 
> Cc: Uma Shankar 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_opregion.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index eca2d3a4f72b..562161a929d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -894,6 +894,9 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   BUILD_BUG_ON(sizeof(struct opregion_asle) != 0x100);
>   BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
>  
> + if (!opregion->opregion_func)
> + return 0;
> +
>   INIT_WORK(>asle_work, asle_work);
>  
>   base = opregion->opregion_func->alloc_opregion(dev_priv);
> @@ -1348,9 +1351,9 @@ int intel_opregion_init(struct drm_i915_private *i915)
>  {
>   struct intel_opregion *opregion = >opregion;
>  
> - if (IS_DGFX(i915))
> + if (IS_DGFX(i915) && HAS_DISPLAY(i915))
>   opregion->opregion_func = _opregion_func;
> - else
> + else if (!IS_DGFX(i915))
>   opregion->opregion_func = _opregion_func;

IOW, and IMO much clearer:

if (dgfx) {
if (has_dislay)
...
} else {
...
}

>  
>   return intel_opregion_setup(i915);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/opregion: Abstract opregion function

[Jani Nikula]

On Sun, 20 Feb 2022, Anshuman Gupta  wrote:
> Abstract opregion operations like get opregion base, get rvda and
> opregion cleanup in form of i915_opregion_ops.
> This will be required to converge igfx and dgfx opregion.
>
> v2:
> - Keep only function pointer abstraction stuff. [Jani]
> - Add alloc_rvda error handling.
>
> v3:
> - Added necessary credit to Manasi for static analysis fix around
>   drm_WARN_ON(>drm, !opregion->asls || !opregion->header)
>
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
> Cc: Badal Nilawar 
> Cc: Uma Shankar 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_opregion.c | 179 +-
>  drivers/gpu/drm/i915/display/intel_opregion.h |   3 +
>  2 files changed, 134 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 9b56064ddb5d..94eb7c23fcb4 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -138,6 +138,13 @@ struct opregion_asle_ext {
>   u8 rsvd[764];
>  } __packed;
>  
> +struct i915_opregion_func {
> + void *(*alloc_opregion)(struct drm_i915_private *i915);
> + void *(*alloc_rvda)(struct drm_i915_private *i915);
> + void (*free_rvda)(struct drm_i915_private *i915);
> + void (*free_opregion)(struct drm_i915_private *i915);
> +};
> +
>  /* Driver readiness indicator */
>  #define ASLE_ARDY_READY  (1 << 0)
>  #define ASLE_ARDY_NOT_READY  (0 << 0)
> @@ -876,10 +883,7 @@ static int intel_load_vbt_firmware(struct 
> drm_i915_private *dev_priv)
>  static int intel_opregion_setup(struct drm_i915_private *dev_priv)
>  {
>   struct intel_opregion *opregion = _priv->opregion;
> - struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - u32 asls, mboxes;
> - char buf[sizeof(OPREGION_SIGNATURE)];
> - int err = 0;
> + u32 mboxes;
>   void *base;
>   const void *vbt;
>   u32 vbt_size;
> @@ -890,27 +894,12 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   BUILD_BUG_ON(sizeof(struct opregion_asle) != 0x100);
>   BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
>  
> - pci_read_config_dword(pdev, ASLS, );
> - drm_dbg(_priv->drm, "graphic opregion physical addr: 0x%x\n",
> - asls);
> - if (asls == 0) {
> - drm_dbg(_priv->drm, "ACPI OpRegion not supported!\n");
> - return -ENOTSUPP;
> - }
> -
>   INIT_WORK(>asle_work, asle_work);
>  
> - base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
> - if (!base)
> - return -ENOMEM;
> + base = opregion->opregion_func->alloc_opregion(dev_priv);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>  
> - memcpy(buf, base, sizeof(buf));
> -
> - if (memcmp(buf, OPREGION_SIGNATURE, 16)) {
> - drm_dbg(_priv->drm, "opregion signature mismatch\n");
> - err = -EINVAL;
> - goto err_out;
> - }
>   opregion->header = base;
>   opregion->lid_state = base + ACPI_CLID;
>  
> @@ -970,23 +959,10 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>  
>   if (opregion->header->over.major >= 2 && opregion->asle &&
>   opregion->asle->rvda && opregion->asle->rvds) {
> - resource_size_t rvda = opregion->asle->rvda;
> -
> - /*
> -  * opregion 2.0: rvda is the physical VBT address.
> -  *
> -  * opregion 2.1+: rvda is unsigned, relative offset from
> -  * opregion base, and should never point within opregion.
> -  */
> - if (opregion->header->over.major > 2 ||
> - opregion->header->over.minor >= 1) {
> - drm_WARN_ON(_priv->drm, rvda < OPREGION_SIZE);
> -
> - rvda += asls;
> - }
>  
> - opregion->rvda = memremap(rvda, opregion->asle->rvds,
> -   MEMREMAP_WB);
> + opregion->rvda = opregion->opregion_func->alloc_rvda(dev_priv);
> + if (IS_ERR(opregion->rvda))
> + goto mbox4_vbt;
>  
>   vbt = opregion->rvda;
>   vbt_size = opregion->asle->rvds;
> @@ -999,11 +975,12 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   } else {
>   drm_dbg_kms(_priv->drm,
>   "Invalid VBT in ACPI OpRegion (RVDA)\n");
> - memunmap(opregion->rvda);
> - opregion->rvda = NULL;
> + opregion->opregion_func->free_rvda(dev_priv);
>   }
>   }
>  
> +mbox4_vbt:
> +
>   vbt = base + OPREGION_VBT_OFFSET;
>   /*
>* The VBT specification says that if the ASLE ext mailbox is not used
> @@ -1028,9 +1005,6 @@ static int intel_opregion_setup(struct 

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/opregion: Abstract opregion function

[Jani Nikula]

On Sun, 20 Feb 2022, Anshuman Gupta  wrote:
> Abstract opregion operations like get opregion base, get rvda and
> opregion cleanup in form of i915_opregion_ops.
> This will be required to converge igfx and dgfx opregion.
>
> v2:
> - Keep only function pointer abstraction stuff. [Jani]
> - Add alloc_rvda error handling.
>
> v3:
> - Added necessary credit to Manasi for static analysis fix around
>   drm_WARN_ON(>drm, !opregion->asls || !opregion->header)
>
> Cc: Jani Nikula 
> Cc: Rodrigo Vivi 
> Cc: Badal Nilawar 
> Cc: Uma Shankar 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_opregion.c | 179 +-
>  drivers/gpu/drm/i915/display/intel_opregion.h |   3 +
>  2 files changed, 134 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 9b56064ddb5d..94eb7c23fcb4 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -138,6 +138,13 @@ struct opregion_asle_ext {
>   u8 rsvd[764];
>  } __packed;
>  
> +struct i915_opregion_func {
> + void *(*alloc_opregion)(struct drm_i915_private *i915);
> + void *(*alloc_rvda)(struct drm_i915_private *i915);
> + void (*free_rvda)(struct drm_i915_private *i915);
> + void (*free_opregion)(struct drm_i915_private *i915);
> +};
> +
>  /* Driver readiness indicator */
>  #define ASLE_ARDY_READY  (1 << 0)
>  #define ASLE_ARDY_NOT_READY  (0 << 0)
> @@ -876,10 +883,7 @@ static int intel_load_vbt_firmware(struct 
> drm_i915_private *dev_priv)
>  static int intel_opregion_setup(struct drm_i915_private *dev_priv)
>  {
>   struct intel_opregion *opregion = _priv->opregion;
> - struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - u32 asls, mboxes;
> - char buf[sizeof(OPREGION_SIGNATURE)];
> - int err = 0;
> + u32 mboxes;
>   void *base;
>   const void *vbt;
>   u32 vbt_size;
> @@ -890,27 +894,12 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   BUILD_BUG_ON(sizeof(struct opregion_asle) != 0x100);
>   BUILD_BUG_ON(sizeof(struct opregion_asle_ext) != 0x400);
>  
> - pci_read_config_dword(pdev, ASLS, );
> - drm_dbg(_priv->drm, "graphic opregion physical addr: 0x%x\n",
> - asls);
> - if (asls == 0) {
> - drm_dbg(_priv->drm, "ACPI OpRegion not supported!\n");
> - return -ENOTSUPP;
> - }
> -
>   INIT_WORK(>asle_work, asle_work);
>  
> - base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
> - if (!base)
> - return -ENOMEM;
> + base = opregion->opregion_func->alloc_opregion(dev_priv);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>  
> - memcpy(buf, base, sizeof(buf));
> -
> - if (memcmp(buf, OPREGION_SIGNATURE, 16)) {
> - drm_dbg(_priv->drm, "opregion signature mismatch\n");
> - err = -EINVAL;
> - goto err_out;
> - }
>   opregion->header = base;
>   opregion->lid_state = base + ACPI_CLID;
>  
> @@ -970,23 +959,10 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>  
>   if (opregion->header->over.major >= 2 && opregion->asle &&
>   opregion->asle->rvda && opregion->asle->rvds) {
> - resource_size_t rvda = opregion->asle->rvda;
> -
> - /*
> -  * opregion 2.0: rvda is the physical VBT address.
> -  *
> -  * opregion 2.1+: rvda is unsigned, relative offset from
> -  * opregion base, and should never point within opregion.
> -  */
> - if (opregion->header->over.major > 2 ||
> - opregion->header->over.minor >= 1) {
> - drm_WARN_ON(_priv->drm, rvda < OPREGION_SIZE);
> -
> - rvda += asls;
> - }
>  
> - opregion->rvda = memremap(rvda, opregion->asle->rvds,
> -   MEMREMAP_WB);
> + opregion->rvda = opregion->opregion_func->alloc_rvda(dev_priv);

It's a basic principle of interfaces to do corresponding things at the
same abstraction level.

Now, you set opregion->rvda at the level that calls ->alloc_rvda,
however ->free_rvda accesses opregion->rvda directly.

Similarly for ->alloc_opregion and ->free_opregion.

> + if (IS_ERR(opregion->rvda))
> + goto mbox4_vbt;
>  
>   vbt = opregion->rvda;
>   vbt_size = opregion->asle->rvds;
> @@ -999,11 +975,12 @@ static int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   } else {
>   drm_dbg_kms(_priv->drm,
>   "Invalid VBT in ACPI OpRegion (RVDA)\n");
> - memunmap(opregion->rvda);
> - opregion->rvda = NULL;
> + 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as an error

[Matthew Auld]

On 16/03/2022 00:38, Patchwork wrote:

*Patch Details*
*Series:*	series starting with [CI,1/7] drm/i915/lmem: don't treat small 
BAR as an error
*URL:*	https://patchwork.freedesktop.org/series/101398/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22576/index.html 




  CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22576_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_22576_full absolutely need 
to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22576_full, please notify your bug team to allow 
them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

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



  IGT changes


Possible regressions

  * igt@kms_sequence@queue-busy:
  o shard-skl: PASS


-> FAIL




Looks to be unrelated.




Suppressed

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

  *

igt@gem_ccs@block-copy-inplace:

  o {shard-dg1}: NOTRUN -> SKIP


  *

igt@gem_eio@in-flight-suspend:

  o {shard-rkl}: PASS


-> FAIL




Known issues

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



  IGT changes


Issues hit

  *

igt@feature_discovery@chamelium:

  o shard-iclb: NOTRUN -> SKIP


([fdo#111827])
  *

igt@gem_eio@unwedge-stress:

  o

shard-tglb: PASS


-> FAIL


([i915#232])

  o

shard-skl: PASS


-> TIMEOUT


([i915#3063])

  *

igt@gem_exec_fair@basic-deadline:

  o shard-skl: NOTRUN -> FAIL


([i915#2846])
  *

igt@gem_exec_fair@basic-none-vip@rcs0:

  o shard-tglb: PASS


-> FAIL


([i915#2842])
  *

igt@gem_exec_fair@basic-none@vecs0:

  o shard-apl: PASS


-> FAIL


([i915#2842])
  *

igt@gem_exec_fair@basic-pace-solo@rcs0:

  o shard-iclb: PASS


-> FAIL


([i915#2842]) +1 similar issue
  *

igt@gem_exec_fair@basic-pace@rcs0:

  o shard-kbl: PASS


-> FAIL


([i915#2842]) +2 similar issues
  *

igt@gem_exec_params@secure-non-root:

  o shard-iclb: NOTRUN -> SKIP


([fdo#112283])
  *

igt@gem_exec_whisper@basic-fds-forked-all:

  o shard-glk: PASS

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix a infinite loop condition when order becomes 0 (rev2)

[Patchwork]

== Series Details ==

Series: drm: Fix a infinite loop condition when order becomes 0 (rev2)
URL   : https://patchwork.freedesktop.org/series/101360/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11367 -> Patchwork_22582


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 40)
--

  Additional (1): bat-jsl-2 
  Missing(6): shard-tglu fi-hsw-4200u fi-ctg-p8600 shard-rkl shard-dg1 
fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/bat-rpls-2/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- {bat-rpls-2}:   [DMESG-WARN][3] ([i915#4391]) -> [PASS][4] +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11367/bat-rpls-2/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22582/bat-rpls-2/igt@core_hotunp...@unbind-rebind.html

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

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

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5087]: https://gitlab.freedesktop.org/drm/intel/issues/5087
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_11367 -> Patchwork_22582

  CI-20190529: 20190529
  CI_DRM_11367: 3d6f714029289bc11200d65feae049183a93bfa6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6382: a6a5a178cb1cbe0dab8d8d092a4aee932ccb93cc @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22582: 2219781b2efc99c7c5287a1d23718bf3b28b76cc @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2219781b2efc drm: Fix a infinite loop condition when order becomes 0

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus

[Intel]

Hi, Michael, others.

This is the response from Linus last time we copied that already 
pre-existing wbinvd_on_all_cpus() macro to another place in the driver:


https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html

My first interpretation of this is that even if there currently are 
similar patterns in drm_cache.c, we shouldn't introduce more, 
encouraging other drivers to use incoherent IO.


Other than that I think we should move whatever wbinvds we can over to 
the ranged versions, unless that is proven to be a performance drop.


Finally for any wbinvds left in our driver, ensure that they are never 
executed for any gpu where we provide full coherency. That is all 
discrete gpus (and to be discussed integrated gpus moving forward).


Might be that drm maintainers want to chime in here with other views.

Thanks,

Thomas



On 3/15/22 17:59, Michael Cheng wrote:

+Daniel for additional feedback!

On 2022-03-14 4:06 p.m., Michael Cheng wrote:


On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:

On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel) 
wrote:

Hi, Michael,

On 2/22/22 18:26, Michael Cheng wrote:

This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.

Signed-off-by: Michael Cheng 


Linus has been pretty clear that he won't accept patches that add 
macros that works on one arch and warns on others anymore in i915 
and I figure even less so in drm code.


So we shouldn't try to move this out to drm. Instead we should 
restrict the wbinvd() inside our driver to integrated and X86 only. 
For discrete on all architectures we should be coherent and hence 
not be needing wbinvd().


the warn is there to guarantee we don't forget a code path. However
simply adding the warning is the real issue: we should rather guarantee
we can't take that code path. I.e., as you said refactor the code to
guarantee it works on discrete without that logic.

$ git grep wbinvd_on_all_cpus -- drivers/gpu/drm/
drivers/gpu/drm/drm_cache.c:    if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c:    if (wbinvd_on_all_cpus())
drivers/gpu/drm/drm_cache.c:    if (wbinvd_on_all_cpus())

drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:  * Currently we 
just do a heavy handed wbinvd_on_all_cpus() here since

drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: wbinvd_on_all_cpus();

It looks like we actually go through this on other discrete 
graphics. Is

this missing an update like s/IS_DG1/IS_DGFX/? Or should we be doing
something else?

drivers/gpu/drm/i915/gem/i915_gem_pm.c:#define 
wbinvd_on_all_cpus() \

drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();

Those are for suspend. Revert ac05a22cd07a ("drm/i915/gem: 
Almagamate clflushes on suspend")

or extract that part to a helper function and implement it differently
for arches != x86?

drivers/gpu/drm/i915/gem/i915_gem_pm.c: wbinvd_on_all_cpus();

Probably take a similar approach to the suspend case?

drivers/gpu/drm/i915/gt/intel_ggtt.c: wbinvd_on_all_cpus();


For a helper function, I have a #define for all non x86 architecture 
that gives a warn on [1] within drm_cache.h Or would it be better to 
implement a helper function instead?


[1]. https://patchwork.freedesktop.org/patch/475750/?series=1=5



This one comes from 64b95df91f44 ("drm/i915: Assume exclusive access 
to objects inside resume")
Shouldn't that be doing the invalidate if the write domain is 
I915_GEM_DOMAIN_CPU


In the end I think the warning would be ok if it was the cherry on top,
to guarantee we don't take those paths. We should probably have a
warn_once() to avoid spamming the console. But we  also have to rework
the code to guarantee we are the only ones who may eventually get that
warning, and not the end user.
Could we first add the helper function/#define for now, and rework 
the code in a different patch series?


Lucas De Marchi



Thanks,

/Thomas

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/display: Add sleep for power state connector

[Jani Nikula]

On Tue, 15 Mar 2022, Vinod Govindapillai  wrote:
> From: Mohammed Khajapasha 
>
> Add 2sec sleep for power state connector when a monitor
> is in power sleep state before atomic commit enable.

We're absolutely not adding a sleep like this.

> Monitors like LG 27UL650-W, 27UK850 goes into power
> sleep state and generates long duration hotplug events
> even the monitor connected for display, sleep for 2sec
> for power state monitor become available before enable
> atomic commit.

Again, will need a better description of the failure mode and/or a
detailed bug report to even suggest a better alternative.

BR,
Jani.

>
> Signed-off-by: Mohammed Khajapasha 
> Signed-off-by: Vinod Govindapillai 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 80 
>  drivers/gpu/drm/i915/display/intel_display.h |  8 ++
>  2 files changed, 88 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 54db81c2cce6..a793f4234460 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -224,6 +224,81 @@ static int intel_compute_global_watermarks(struct 
> intel_atomic_state *state)
>   return 0;
>  }
>  
> +static void
> +intel_connectors_wakeup_hpd_suppress(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + struct i915_hotplug *hpd = >hotplug;
> + bool do_delay = false;
> + struct intel_connector *connector;
> + struct intel_digital_connector_state *conn_state;
> + int i;
> +
> + if (!hpd->suppress_wakeup_hpd_enabled)
> + return;
> +
> + for_each_new_intel_connector_in_state(state, connector,
> +   conn_state, i) {
> + struct intel_crtc *crtc = to_intel_crtc(conn_state->base.crtc);
> + struct intel_crtc_state *crtc_state;
> +
> + if (!crtc || !intel_connector_needs_modeset(state,
> + >base))
> + continue;
> +
> + crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> + if (!crtc_state->hw.active)
> + continue;
> +
> + if (!intel_connector_need_suppress_wakeup_hpd(connector))
> + continue;
> +
> + if (time_is_before_jiffies64(connector->disabled_time +
> +  msecs_to_jiffies(MSEC_PER_SEC * 
> 10))) {
> + drm_dbg_kms(>drm,
> + "[CONNECTOR:%d:%s] Suppress wakeup HPD for 
> 2 secs\n",
> + connector->base.base.id, 
> connector->base.name);
> + do_delay = true;
> + }
> + }
> +
> + if (do_delay)
> + msleep(2 * MSEC_PER_SEC);
> +}
> +
> +static void
> +intel_connectors_wakeup_hpd_track_disabling(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + struct i915_hotplug *hpd = >hotplug;
> + struct intel_connector *connector;
> + struct intel_digital_connector_state *conn_state;
> + int i;
> +
> + if (!hpd->suppress_wakeup_hpd_enabled)
> + return;
> +
> + for_each_old_intel_connector_in_state(state, connector,
> +   conn_state, i) {
> + struct intel_crtc *crtc = to_intel_crtc(conn_state->base.crtc);
> + struct intel_crtc_state *crtc_state;
> +
> + if (!crtc || !intel_connector_needs_modeset(state,
> + >base))
> + continue;
> +
> + crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
> + if (!crtc_state->hw.active)
> + continue;
> +
> + drm_dbg_kms(>drm,
> + "[CONNECTOR:%d:%s] Update disabled time for wakeup 
> HPD handling\n",
> + connector->base.base.id, connector->base.name);
> +
> + connector->disabled_time = get_jiffies_64();
> + }
> +}
> +
>  /* returns HPLL frequency in kHz */
>  int vlv_get_hpll_vco(struct drm_i915_private *dev_priv)
>  {
> @@ -8517,6 +8592,8 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   }
>   }
>  
> + intel_connectors_wakeup_hpd_track_disabling(state);
> +
>   intel_commit_modeset_disables(state);
>  
>   /* FIXME: Eventually get rid of our crtc->config pointer */
> @@ -8560,6 +8637,9 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>   dev_priv->display->commit_modeset_enables(state);
>  
> + /* sleep for 2sec for power state connector become available */
> + 

Re: [Intel-gfx] [RFC PATCH 1/2] drm/i915/display: Add disable wait time for power state connector

[Jani Nikula]

On Tue, 15 Mar 2022, Vinod Govindapillai  wrote:
> From: Mohammed Khajapasha 
>
> Add connector disable wait time for a power state connector
> for monitor power sleep state.
>
> Monitors like LG 27UL650-W, 27UK850 goes into power sleep state
> and generates long duration hotplug events even the monitor
> connected for display, create a debugfs entry to enable sleep
> while monitor is in power sleep state with hotplug event.

Basically this patch adds three things that don't have any connection
between them in code, and don't actually achieve any of the things
mentioned in the commit message. Apart from adding the debugfs, but it's
not used for anything.

More comments inline.

BR,
Jani.

>
> Signed-off-by: Mohammed Khajapasha 
> Signed-off-by: Vinod Govindapillai 
> ---
>  .../gpu/drm/i915/display/intel_connector.c|  3 +
>  .../drm/i915/display/intel_display_debugfs.c  | 58 +++
>  .../drm/i915/display/intel_display_debugfs.h  |  7 +++
>  .../drm/i915/display/intel_display_types.h|  2 +
>  drivers/gpu/drm/i915/i915_drv.h   |  2 +
>  5 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index c65f95a9a1ec..d7ad62df30e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -126,6 +126,9 @@ int intel_connector_register(struct drm_connector 
> *connector)
>  
>   intel_connector_debugfs_add(intel_connector);
>  
> + intel_connector->disabled_time =
> + get_jiffies_64() - msecs_to_jiffies(MSEC_PER_SEC * 10);
> +

In this patch, this is just unused code.

>   return 0;
>  
>  err_backlight:
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 41b81d5dd5f4..e3fc42b53ea9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -26,6 +26,17 @@
>  #include "intel_psr.h"
>  #include "intel_sprite.h"
>  
> +struct {
> + /* manufacturer and product code of connector from edid data */
> + u8 edid_manuf_code[2];
> + u8 edid_prod_code[2];
> +} wakeup_hpd_monitor_list[] = {
> + /* LG 27UL650-W, 27UK850 */
> + {{0x1e, 0x6d}, {0x06, 0x77}},
> + {{0x1e, 0x6d}, {0x07, 0x77}},
> + {{0x26, 0xcd}, {0x40, 0x66}},
> +};
> +
>  static inline struct drm_i915_private *node_to_i915(struct drm_info_node 
> *node)
>  {
>   return to_i915(node->minor->dev);
> @@ -2021,6 +2032,52 @@ static const struct file_operations 
> i915_fifo_underrun_reset_ops = {
>   .llseek = default_llseek,
>  };
>  
> +bool intel_connector_need_suppress_wakeup_hpd(struct intel_connector 
> *connector)
> +{
> + int i;
> + struct edid *edid = connector->detect_edid;
> +
> + if (!edid)
> + return false;
> +
> + for (i = 0; i < ARRAY_SIZE(wakeup_hpd_monitor_list); i++) {
> + if (*((u16 *)_hpd_monitor_list[i].edid_manuf_code) !=
> + *((u16 *)>mfg_id))
> + continue;
> +
> + if (*((u16 *)_hpd_monitor_list[i].edid_prod_code) !=
> + *((u16 *)>prod_code))
> + continue;
> +
> + return true;
> + }
> +
> + return false;
> +}

Please let's not duplicate the EDID quirk mechanism from drm_edid.c.

> +
> +static int i915_suppress_wakeup_hpd_set(void *data, u64 val)
> +{
> + struct drm_i915_private *i915 = data;
> +
> + drm_dbg(>drm, "Suppress wakeup HPDs enabled: %s\n", yesno(val));
> +
> + i915->hotplug.suppress_wakeup_hpd_enabled = val;
> +
> + return 0;
> +}
> +
> +static int i915_suppress_wakeup_hpd_get(void *data, u64 *val)
> +{
> + struct drm_i915_private *i915 = data;
> +
> + *val = i915->hotplug.suppress_wakeup_hpd_enabled;
> +
> + return 0;
> +}

So this debugfs file is completely separated from the quirk thing above,
which seems odd. Up to the caller to handle all of them?

> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_suppress_wakeup_hpd_fops, 
> i915_suppress_wakeup_hpd_get,
> + i915_suppress_wakeup_hpd_set, "%llu\n");
> +
>  static const struct drm_info_list intel_display_debugfs_list[] = {
>   {"i915_frontbuffer_tracking", i915_frontbuffer_tracking, 0},
>   {"i915_ips_status", i915_ips_status, 0},
> @@ -2055,6 +2112,7 @@ static const struct {
>   {"i915_ipc_status", _ipc_status_fops},
>   {"i915_drrs_ctl", _drrs_ctl_fops},
>   {"i915_edp_psr_debug", _edp_psr_debug_fops},
> + {"i915_suppress_wakeup_hpd", _suppress_wakeup_hpd_fops}
>  };
>  
>  void intel_display_debugfs_register(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.h 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> index d3a79c07c384..58be26fcdf46 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
> +++ 

Re: [Intel-gfx] [RFC PATCH 0/2] suppress the wrong long hotplug events

[Jani Nikula]

On Tue, 15 Mar 2022, Vinod Govindapillai  wrote:
> Monitors like LG 27UL650-W, 27UK850 goes into power sleep state
> and generates long duration hotplug events even when the monitor
> is connected for display. Here is a proposal to detect and
> suppress such hotplug events by "sleep" for 2 secs for power
> state monitor become available before enable atomic commit.

I don't understand the failure mode. Please elaborate. Do we have a bug
report?

BR,
Jani.

> A debugfs entry is created to enable the suppression of the
> hotplug event in such scenarios.
>
> Cc: Imre Deak 
>
> Mohammed Khajapasha (2):
>   drm/i915/display: Add disable wait time for power state connector
>   drm/i915/display: Add sleep for power state connector
>
>  .../gpu/drm/i915/display/intel_connector.c|  3 +
>  drivers/gpu/drm/i915/display/intel_display.c  | 80 +++
>  drivers/gpu/drm/i915/display/intel_display.h  |  8 ++
>  .../drm/i915/display/intel_display_debugfs.c  | 58 ++
>  .../drm/i915/display/intel_display_debugfs.h  |  7 ++
>  .../drm/i915/display/intel_display_types.h|  2 +
>  drivers/gpu/drm/i915/i915_drv.h   |  2 +
>  7 files changed, 160 insertions(+)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 19/22] drm/i915: Use drm_mode_copy()

[Jani Nikula]

On Fri, 18 Feb 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
>
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
>
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
>
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
>
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, )
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
>
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(, )
> |
> - memcpy(, E, S)
> + drm_mode_copy(, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 74c5a99ab276..661e36435793 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5506,8 +5506,10 @@ intel_crtc_copy_uapi_to_hw_state_modeset(struct 
> intel_atomic_state *state,
>  
>   crtc_state->hw.enable = crtc_state->uapi.enable;
>   crtc_state->hw.active = crtc_state->uapi.active;
> - crtc_state->hw.mode = crtc_state->uapi.mode;
> - crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> + drm_mode_copy(_state->hw.mode,
> +   _state->uapi.mode);
> + drm_mode_copy(_state->hw.adjusted_mode,
> +   _state->uapi.adjusted_mode);
>   crtc_state->hw.scaling_filter = crtc_state->uapi.scaling_filter;
>  
>   intel_crtc_copy_uapi_to_hw_state_nomodeset(state, crtc);
> @@ -5584,9 +5586,12 @@ copy_bigjoiner_crtc_state_modeset(struct 
> intel_atomic_state *state,
>   memset(_crtc_state->hw, 0, sizeof(slave_crtc_state->hw));
>   slave_crtc_state->hw.enable = master_crtc_state->hw.enable;
>   slave_crtc_state->hw.active = master_crtc_state->hw.active;
> - slave_crtc_state->hw.mode = master_crtc_state->hw.mode;
> - slave_crtc_state->hw.pipe_mode = master_crtc_state->hw.pipe_mode;
> - slave_crtc_state->hw.adjusted_mode = 
> master_crtc_state->hw.adjusted_mode;
> + drm_mode_copy(_crtc_state->hw.mode,
> +   _crtc_state->hw.mode);
> + drm_mode_copy(_crtc_state->hw.pipe_mode,
> +   _crtc_state->hw.pipe_mode);
> + drm_mode_copy(_crtc_state->hw.adjusted_mode,
> +   _crtc_state->hw.adjusted_mode);
>   slave_crtc_state->hw.scaling_filter = 
> master_crtc_state->hw.scaling_filter;
>  
>   copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 18/22] drm/i915: Use drm_mode_init() for on-stack modes

[Jani Nikula]

On Fri, 18 Feb 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Initialize on-stack modes with drm_mode_init() to guarantee
> no stack garbage in the list head, or that we aren't copying
> over another mode's list head.
>
> Based on the following cocci script, with manual fixups:
> @decl@
> identifier M;
> expression E;
> @@
> - struct drm_display_mode M = E;
> + struct drm_display_mode M;
>
> @@
> identifier decl.M;
> expression decl.E;
> statement S, S1;
> @@
> struct drm_display_mode M;
> ... when != S
> + drm_mode_init(, );
> +
> S1
>
> @@
> expression decl.E;
> @@
> - &*E
> + E
>
> Signed-off-by: Ville Syrjälä 

I wonder if that cocci could be added to scripts/coccinelle or something
to detect anyone adding new ones?

Anyway,

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 740620ef07ad..74c5a99ab276 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6898,8 +6898,9 @@ intel_crtc_update_active_timings(const struct 
> intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct drm_display_mode adjusted_mode =
> - crtc_state->hw.adjusted_mode;
> + struct drm_display_mode adjusted_mode;
> +
> + drm_mode_init(_mode, _state->hw.adjusted_mode);
>  
>   if (crtc_state->vrr.enable) {
>   adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase (rev3)

[Jani Nikula]

On Tue, 15 Mar 2022, "Srivatsa, Anusha"  wrote:
> Checked the logs, a lot of machines not showing tests results even though 
> igt_run.txt shows as PASS for most. The boot log shows ACL errors in 
> /var/log/journal/ , sending the series again.

If you don't need a rebase or change anything, you know you can just hit
the retest button via the patchwork link.

BR,
Jani.

>
> Anusha
>
> From: Patchwork 
> Sent: Friday, March 11, 2022 12:55 AM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase 
> (rev3)
>
> Patch Details
> Series:
>
> Add CDCLK checks to atomic check phase (rev3)
>
> URL:
>
> https://patchwork.freedesktop.org/series/101068/
>
> State:
>
> failure
>
> Details:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/index.html
>
> CI Bug Log - changes from CI_DRM_11350 -> Patchwork_22540
> Summary
>
> FAILURE
>
> Serious unknown changes coming with Patchwork_22540 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_22540, 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_22540/index.html
>
> Participating hosts (48 -> 27)
>
> Additional (2): fi-kbl-soraka fi-pnv-d510
> Missing (23): fi-rkl-11600 bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-apl-guc 
> bat-rpls-2 shard-dg1 fi-bdw-5557u shard-tglu fi-adl-ddr5 fi-glk-dsi 
> fi-kbl-7500u fi-ctg-p8600 fi-skl-6700k2 fi-skl-guc fi-cfl-8700k fi-hsw-4200u 
> fi-bsw-cyan fi-cfl-guc fi-kbl-x1275 fi-cfl-8109u shard-rkl fi-bdw-samus
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in Patchwork_22540:
>
> IGT changes
> Possible regressions
>
>   *   igt@gem_exec_suspend@basic-s0@smem:
>
>  *   fi-bsw-nick: 
> PASS
>  -> 
> INCOMPLETE
>  *   fi-glk-j4005: 
> PASS
>  -> 
> INCOMPLETE
>  *   fi-rkl-guc: 
> PASS
>  -> 
> INCOMPLETE
>  *   fi-bsw-kefka: 
> PASS
>  -> 
> INCOMPLETE
>  *   fi-bsw-n3050: 
> PASS
>  -> 
> INCOMPLETE
>  *   fi-bxt-dsi: 
> PASS
>  -> 
> INCOMPLETE
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
>   *   igt@gem_exec_suspend@basic-s0@smem:
>
>  *   {fi-ehl-2}: 
> PASS
>  -> 
> INCOMPLETE
>  *   {fi-jsl-1}: 
> PASS
>  -> 
> INCOMPLETE
>  *   {fi-tgl-dsi}: 
> PASS
>  -> 
> INCOMPLETE
>  *   {bat-adlp-6}: 
> PASS
>  -> 
> INCOMPLETE
>
>   *   igt@runner@aborted:
>
>  *   {bat-jsl-1}: NOTRUN -> 
> FAIL
>
> Known issues
>
> Here are the changes found in 

Re: [Intel-gfx] [PATCH] drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup

[Jani Nikula]

On Tue, 15 Mar 2022, Manasi Navare  wrote:
> This patch abstracts pieces of hsw_crtc_enable corresponding to different
> Bspec enable sequence steps into separate functions.
> This helps to call them in a specific order for bigjoiner master/slave
> in a cleaner fashion.

So does this contain only refactoring or functional changes also? One or
the other at a time, please, not both.

Also looks like hsw_crtc_* have accumulated just way too many checks for
platforms instead of having a clean break at e.g. display 9 and/or 11.

Adding references to "enable sequence step 8" is not helpful because
it's platform specific. (Yeah, I know there are existing references like
this, but they're also suspect.)


BR,
Jani.


>
> Cc: Ville Syrjälä 
> Cc: Animesh Manna 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 125 ++-
>  1 file changed, 66 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index eb49973621f0..d8e6466c9fa0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1865,24 +1865,6 @@ static void hsw_set_frame_start_delay(const struct 
> intel_crtc_state *crtc_state)
>   intel_de_write(dev_priv, reg, val);
>  }
>  
> -static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> -  const struct intel_crtc_state 
> *crtc_state)
> -{
> - struct intel_crtc *master_crtc = intel_master_crtc(crtc_state);
> -
> - /*
> -  * Enable sequence steps 1-7 on bigjoiner master
> -  */
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - intel_encoders_pre_pll_enable(state, master_crtc);
> -
> - if (crtc_state->shared_dpll)
> - intel_enable_shared_dpll(crtc_state);
> -
> - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> - intel_encoders_pre_enable(state, master_crtc);
> -}
> -
>  static void hsw_configure_cpu_transcoder(const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -1910,70 +1892,73 @@ static void hsw_configure_cpu_transcoder(const struct 
> intel_crtc_state *crtc_sta
>   hsw_set_transconf(crtc_state);
>  }
>  
> -static void hsw_crtc_enable(struct intel_atomic_state *state,
> - struct intel_crtc *crtc)
> +static void hsw_crtc_pre_pll_enable(struct intel_atomic_state *state,
> + const struct intel_crtc_state *crtc_state)
>  {
> - const struct intel_crtc_state *new_crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> - enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> - bool psl_clkgate_wa;
> -
> - if (drm_WARN_ON(_priv->drm, crtc->active))
> - return;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> - if (!new_crtc_state->bigjoiner_pipes) {
> - intel_encoders_pre_pll_enable(state, crtc);
> + /*
> +  * Enable sequence steps 1 - 7 on all pipes
> +  */
> + intel_encoders_pre_pll_enable(state, crtc);
> + if (crtc_state->shared_dpll)
> + intel_enable_shared_dpll(crtc_state);
>  
> - if (new_crtc_state->shared_dpll)
> - intel_enable_shared_dpll(new_crtc_state);
> + intel_encoders_pre_enable(state, crtc);
> +}
>  
> - intel_encoders_pre_enable(state, crtc);
> - } else {
> - icl_ddi_bigjoiner_pre_enable(state, new_crtc_state);
> - }
> +static void hsw_crtc_post_pll_enable(struct intel_atomic_state *state,
> +  const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> + bool psl_clkgate_wa;
>  
> - intel_dsc_enable(new_crtc_state);
> + /*
> +  * Enable sequence step 8
> +  */
> + intel_dsc_enable(crtc_state);
>  
>   if (DISPLAY_VER(dev_priv) >= 13)
> - intel_uncompressed_joiner_enable(new_crtc_state);
> + intel_uncompressed_joiner_enable(crtc_state);
>  
> - intel_set_pipe_src_size(new_crtc_state);
> + intel_set_pipe_src_size(crtc_state);
>   if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> - bdw_set_pipemisc(new_crtc_state);
> + bdw_set_pipemisc(crtc_state);
>  
> - if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
> + if (!intel_crtc_is_bigjoiner_slave(crtc_state) &&
>   !transcoder_is_dsi(cpu_transcoder))
> - 

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)

[Kasireddy, Vivek]

Hi Tvrtko,

> 
> On 15/03/2022 07:28, Kasireddy, Vivek wrote:
> > Hi Tvrtko, Daniel,
> >
> >>
> >> On 11/03/2022 09:39, Daniel Vetter wrote:
> >>> On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy  
> >>> wrote:
> 
>  On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
>  more framebuffers/scanout buffers results in only one that is mappable/
>  fenceable. Therefore, pageflipping between these 2 FBs where only one
>  is mappable/fenceable creates latencies large enough to miss alternate
>  vblanks thereby producing less optimal framerate.
> 
>  This mainly happens because when i915_gem_object_pin_to_display_plane()
>  is called to pin one of the FB objs, the associated vma is identified
>  as misplaced and therefore i915_vma_unbind() is called which unbinds and
>  evicts it. This misplaced vma gets subseqently pinned only when
>  i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
>  results in a latency of ~10ms and happens every other vblank/repaint 
>  cycle.
>  Therefore, to fix this issue, we try to see if there is space to map
>  at-least two objects of a given size and return early if there isn't. 
>  This
>  would ensure that we do not try with PIN_MAPPABLE for any objects that
>  are too big to map thereby preventing unncessary unbind.
> 
>  Testcase:
>  Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
>  with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
>  a frame ~7ms before the next vblank, the latencies seen between atomic
>  commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
>  it misses the vblank every other frame.
> 
>  Here is the ftrace snippet that shows the source of the ~10ms latency:
>  i915_gem_object_pin_to_display_plane() {
>  0.102 us   |i915_gem_object_set_cache_level();
>    i915_gem_object_ggtt_pin_ww() {
>  0.390 us   |  i915_vma_instance();
>  0.178 us   |  i915_vma_misplaced();
>  i915_vma_unbind() {
>  __i915_active_wait() {
>  0.082 us   |i915_active_acquire_if_busy();
>  0.475 us   |  }
>  intel_runtime_pm_get() {
>  0.087 us   |intel_runtime_pm_acquire();
>  0.259 us   |  }
>  __i915_active_wait() {
>  0.085 us   |i915_active_acquire_if_busy();
>  0.240 us   |  }
>  __i915_vma_evict() {
>    ggtt_unbind_vma() {
>  gen8_ggtt_clear_range() {
>  10507.255 us |}
>  10507.689 us |  }
>  10508.516 us |   }
> 
>  v2: Instead of using bigjoiner checks, determine whether a scanout
>    buffer is too big by checking to see if it is possible to map
>    two of them into the ggtt.
> 
>  v3 (Ville):
>  - Count how many fb objects can be fit into the available holes
>  instead of checking for a hole twice the object size.
>  - Take alignment constraints into account.
>  - Limit this large scanout buffer check to >= Gen 11 platforms.
> 
>  v4:
>  - Remove existing heuristic that checks just for size. (Ville)
>  - Return early if we find space to map at-least two objects. (Tvrtko)
>  - Slightly update the commit message.
> 
>  v5: (Tvrtko)
>  - Rename the function to indicate that the object may be too big to
>  map into the aperture.
>  - Account for guard pages while calculating the total size required
>  for the object.
>  - Do not subject all objects to the heuristic check and instead
>  consider objects only of a certain size.
>  - Do the hole walk using the rbtree.
>  - Preserve the existing PIN_NONBLOCK logic.
>  - Drop the PIN_MAPPABLE check while pinning the VMA.
> 
>  v6: (Tvrtko)
>  - Return 0 on success and the specific error code on failure to
>  preserve the existing behavior.
> 
>  v7: (Ville)
>  - Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
>  size < ggtt->mappable_end / 4 checks.
>  - Drop the redundant check that is based on previous heuristic.
> 
>  v8:
>  - Make sure that we are holding the mutex associated with ggtt vm
>  as we traverse the hole nodes.
> 
>  v9: (Tvrtko)
>  - Use mutex_lock_interruptible_nested() instead of mutex_lock().
> 
>  Cc: Ville Syrjälä 
>  Cc: Maarten Lankhorst 
>  Cc: Tvrtko Ursulin 
>  Cc: Manasi Navare 
>  Reviewed-by: Tvrtko Ursulin 
>  Signed-off-by: Vivek Kasireddy 
>  ---
> drivers/gpu/drm/i915/i915_gem.c | 128 +++-
> 1 file changed, 94 insertions(+), 34 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>  

[Intel-gfx] Small bar recovery vs compressed content on DG2

[Thomas Hellström]

Hi!

Do we somehow need to clarify in the headers the semantics for this?

From my understanding when discussing the CCS migration series with 
Ram, the kernel will never do any resolving (compressing / 
decompressing) migrations or evictions which basically implies the 
following:


*) Compressed data must have LMEM only placement, otherwise the GPU 
would read garbage if accessing from SMEM.
*) Compressed data can't be assumed to be mappable by the CPU, because 
in order to ensure that on small BAR, the placement needs to be LMEM+SMEM.
*) Neither can compressed data be part of a CAPTURE buffer, because that 
requires the data to be CPU-mappable.


Are we (and user-mode drivers) OK with these restrictions, or do we need 
to rethink?


Thanks,

Thomas

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

[Yang, Fei]

>>> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> index e1470bb60f34..7e8552414275 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> @@ -1258,6 +1258,34 @@ static bool completed(const struct i915_request 
>>> *rq)
>>> return __i915_request_is_complete(rq);  }
>>>  
>>> +static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine) {
>>> +   static const i915_reg_t vd[] = {
>>> +   GEN12_VD0_AUX_NV,
>>> +   GEN12_VD1_AUX_NV,
>>> +   GEN12_VD2_AUX_NV,
>>> +   GEN12_VD3_AUX_NV,
>>> +   };
>>> +
>>> +   static const i915_reg_t ve[] = {
>>> +   GEN12_VE0_AUX_NV,
>>> +   GEN12_VE1_AUX_NV,
>>> +   };
>>> +
>>> +   if (engine->class == VIDEO_DECODE_CLASS) {
>>> +   GEM_BUG_ON(engine->instance >= ARRAY_SIZE(vd));
>>> +   return vd[engine->instance];
>>> +   }
>>> +
>>> +   if (engine->class == VIDEO_ENHANCEMENT_CLASS) {
>>> +   GEM_BUG_ON(engine->instance >= ARRAY_SIZE(ve));
>>> +   return ve[engine->instance];
>>> +   }
>>> +
>>> +   GEM_BUG_ON("unknown aux_inv reg\n");
>>> +   return INVALID_MMIO_REG;
>>> +}
>>> +
>>>  static void execlists_dequeue(struct intel_engine_cs *engine)
>> 
>> So in the previous implementation, this "worked" for both execlists and guc 
>> submission. But how will this work now for GuC based submission?
>> This flow and the address of the engine is owned by the GuC.
>>
>> If we are going to say this is an execlist only requirement (e.g.
>> platforms using GuC submission don't need this workaround), you should add 
>> an if (!using guc submission) in the sequence you added to the various 
>> emit_flush() routines above.
>
> Good point.
> I didn't consider GuC submission because Chrome doesn't enable GuC for TGL. 
> But it is true that the implementation will have problem with GuC submission.
> I'm not sure if it's possible for i915 to know which engine will eventually 
> carry out the request because it might be scheduled by GuC. I will need to 
> investigate.

I think the same can be done in intel_guc_submission.c after 
__i915_request_submit(rq) calls.

>> Thanks,
>> Stuart

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

[Paul Menzel]

Dear Arunprivin,


Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:


On 15/03/22 9:14 pm, Paul Menzel wrote:



Am 15.03.22 um 16:42 schrieb Arunpravin:


On 15/03/22 2:35 pm, Paul Menzel wrote:



Am 15.03.22 um 10:01 schrieb Arunpravin:


On 15/03/22 1:49 pm, Paul Menzel wrote:



Am 14.03.22 um 20:40 schrieb Arunpravin:

handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC

Signed-off-by: Arunpravin 


Please use your full name.

okay


You might also configure that in your email program.

yes


Not done yet though. ;-)


done in v2 :)

---
 drivers/gpu/drm/drm_buddy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c


In what tree is that file?


drm-tip - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3Dreserved=0
drm-misc-next - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3Dreserved=0


Thank Outlook. Now everybody feels safe.


@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
 
-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}


Thank you for the hint. So the whole function is:

do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);

do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);

if (!IS_ERR(block))
break;

if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);

mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(>link, );

pages -= BIT(order);

if (!pages)
break;
} while (1);

Was the BUG_ON triggered for your case?

BUG_ON(order < min_order);

no, this BUG_ON is not triggered for this bug


Please give more details.


there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.


Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.


please check v2, yes when min_order is 0, the above said situation may
occur.And, since the order is unsigned int, I think it will not trigger
the BUG_ON(order < min_order) when order becomes -1. Hence I think we
needed a check !order to exit the loop.


Thank you for clarifying this. I still do not understand it though. With

order = fls(pages) - 1;
min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);

is zorder` always non-negative? Let’s assume it is. Also, can min_order 
get “negative” (wraps around)?


I would add BUG_ON statements for these cases?

BUG_ON(fls(pages) - 1 < 1);
BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);

Assuming “negative” is not possible, your case can only happen if 
`order` and `min_order` are 0, right? If `order` is greater than 0, and 
`min_order` is 0, the 

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: General multicast steering updates (rev2)

[Patchwork]

== Series Details ==

Series: i915: General multicast steering updates (rev2)
URL   : https://patchwork.freedesktop.org/series/101367/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22574_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_bad_reloc@negative-reloc-bltcopy:
- {shard-rkl}:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-rkl-2/igt@gem_bad_re...@negative-reloc-bltcopy.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-rkl-5/igt@gem_bad_re...@negative-reloc-bltcopy.html

  * igt@gem_ccs@block-copy-inplace:
- {shard-dg1}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-dg1-12/igt@gem_...@block-copy-inplace.html

  * igt@gem_exec_schedule@submit-early-slice@vecs0:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-dg1-15/igt@gem_exec_schedule@submit-early-sl...@vecs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][5] ([fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-iclb2/igt@feature_discov...@chamelium.html

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

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

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-tglb5/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-apl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-iclb3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-iclb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2851])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html

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

  * igt@gem_exec_whisper@basic-fds:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-glk1/igt@gem_exec_whis...@basic-fds.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22574/shard-glk3/igt@gem_exec_whis...@basic-fds.html

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-kbl:  [PASS][22] -> [INCOMPLETE][23] ([i915#5268])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11365/shard-kbl6/igt@gem_exec_whis...@basic-fds-forked-all.html