[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)
URL   : https://patchwork.freedesktop.org/series/97053/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10948_full -> Patchwork_21710_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1] ([i915#4547])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl7/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][2] -> [FAIL][3] ([i915#2842])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl9/igt@gem_lmem_swapp...@heavy-verify-random.html

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

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

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][9] ([i915#454])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl6/igt@i915_pm...@dc6-dpms.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][10] -> [INCOMPLETE][11] ([i915#3921])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/shard-snb6/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-snb7/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_addfb_basic@small-bo:
- shard-skl:  [PASS][12] -> [DMESG-WARN][13] ([i915#1982])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/shard-skl8/igt@kms_addfb_ba...@small-bo.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl9/igt@kms_addfb_ba...@small-bo.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2521])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/shard-tglb8/igt@kms_async_fl...@alternate-sync-async-flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-tglb6/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3777])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl6/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#3763])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +4 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-skl6/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-apl3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/shard-kbl4/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html

  * 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce Raptor Lake S (rev3)

[Patchwork]

== Series Details ==

Series: Introduce Raptor Lake S (rev3)
URL   : https://patchwork.freedesktop.org/series/96869/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gt/uc/intel_uc.o
drivers/gpu/drm/i915/gt/uc/intel_uc.c: In function ‘uc_expand_default_options’:
drivers/gpu/drm/i915/gt/uc/intel_uc.c:38:31: error: implicit declaration of 
function ‘IS_RAPTORLAKE_S’; did you mean ‘IS_ALDERLAKE_S’? 
[-Werror=implicit-function-declaration]
  if (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915)) {
   ^~~
   IS_ALDERLAKE_S
cc1: all warnings being treated as errors
scripts/Makefile.build:287: recipe for target 
'drivers/gpu/drm/i915/gt/uc/intel_uc.o' failed
make[4]: *** [drivers/gpu/drm/i915/gt/uc/intel_uc.o] Error 1
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1846: recipe for target 'drivers' failed
make: *** [drivers] Error 2

[Intel-gfx] [v3 3/3] drm/i915/rpl-s: Enable guc submission by default

[Anusha Srivatsa]

Though, RPL-S is defined as subplatform of ADL-S, unlike
ADL-S, it has GuC submission by default.

v2: Remove extra parenthesis (Jani)
v3: s/IS_RAPTORLAKE/IS_ADLS_RPLS (Jani)

Cc: Jani Nikula 
Cc: Swathi Dhanavanthri 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 2fef3b0bbe95..6aa843a1c25f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -35,7 +35,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
}
 
/* Intermediate platforms are HuC authentication only */
-   if (IS_ALDERLAKE_S(i915)) {
+   if (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
-- 
2.25.1

[Intel-gfx] [v3 2/3] drm/i915/rpl-s: Add PCH Support for Raptor Lake S

[Anusha Srivatsa]

Add the PCH ID for RPL-S.

v2: Self contained commit message (Jani)

Cc: Jani Nikula 
Cc: Swathi Dhanavanthri 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_pch.c | 1 +
 drivers/gpu/drm/i915/intel_pch.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index d1d4b97b86f5..da8f82c2342f 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -129,6 +129,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
unsigned short id)
return PCH_JSP;
case INTEL_PCH_ADP_DEVICE_ID_TYPE:
case INTEL_PCH_ADP2_DEVICE_ID_TYPE:
+   case INTEL_PCH_ADP3_DEVICE_ID_TYPE:
drm_dbg_kms(_priv->drm, "Found Alder Lake PCH\n");
drm_WARN_ON(_priv->drm, !IS_ALDERLAKE_S(dev_priv) &&
!IS_ALDERLAKE_P(dev_priv));
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index 7c0d83d292dc..6bff77521094 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -57,6 +57,7 @@ enum intel_pch {
 #define INTEL_PCH_JSP2_DEVICE_ID_TYPE  0x3880
 #define INTEL_PCH_ADP_DEVICE_ID_TYPE   0x7A80
 #define INTEL_PCH_ADP2_DEVICE_ID_TYPE  0x5180
+#define INTEL_PCH_ADP3_DEVICE_ID_TYPE  0x7A00
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
-- 
2.25.1

[Intel-gfx] [v3 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake S

[Anusha Srivatsa]

Raptor Lake S(RPL-S) is a version 12
Display, Media and Render. For all i915
purposes it is the same as Alder Lake S (ADL-S).

Introduce RPL-S as a subplatform
of ADL-S. This patch adds PCI ids for RPL-S.

v2: Update PCI IDs.
- Add more description to commit message (Jani)

v3: s/IS_RAPTORLAKE/IS_ADLS_RPLS (Jani)
- Fix comment (Tvrtko)

BSpec: 53655

Cc: Matt Roper 
Cc: Tvrtko Ursulin 
Cc: Swathi Dhanavanthri 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 arch/x86/kernel/early-quirks.c   | 1 +
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.c | 7 +++
 drivers/gpu/drm/i915/intel_device_info.h | 3 +++
 include/drm/i915_pciids.h| 9 +
 6 files changed, 23 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 391a4e2b8604..fd2d3ab38ebb 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[] 
__initconst = {
INTEL_RKL_IDS(_early_ops),
INTEL_ADLS_IDS(_early_ops),
INTEL_ADLP_IDS(_early_ops),
+   INTEL_RPLS_IDS(_early_ops),
 };
 
 struct resource intel_graphics_stolen_res __ro_after_init = DEFINE_RES_MEM(0, 
0);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1bfadd9127fc..88c4fd80dcbe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1469,6 +1469,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G10)
 #define IS_DG2_G11(dev_priv) \
IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G11)
+#define IS_ADLS_RPLS(dev_priv) \
+   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_S, INTEL_SUBPLATFORM_RPL_S)
 #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
 #define IS_BDW_ULT(dev_priv) \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f01cba4ec283..061b2e076373 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1131,6 +1131,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_ADLS_IDS(_s_info),
INTEL_ADLP_IDS(_p_info),
INTEL_DG1_IDS(_info),
+   INTEL_RPLS_IDS(_s_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 6e6b317bc33c..cae51d9dd7ea 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -182,6 +182,10 @@ static const u16 subplatform_portf_ids[] = {
INTEL_ICL_PORT_F_IDS(0),
 };
 
+static const u16 subplatform_rpls_ids[] = {
+   INTEL_RPLS_IDS(0),
+};
+
 static bool find_devid(u16 id, const u16 *p, unsigned int num)
 {
for (; num; num--, p++) {
@@ -218,6 +222,9 @@ void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
} else if (find_devid(devid, subplatform_portf_ids,
  ARRAY_SIZE(subplatform_portf_ids))) {
mask = BIT(INTEL_SUBPLATFORM_PORTF);
+   } else if (find_devid(devid, subplatform_rpls_ids,
+ ARRAY_SIZE(subplatform_rpls_ids))) {
+   mask = BIT(INTEL_SUBPLATFORM_RPL_S);
}
 
if (IS_TIGERLAKE(i915)) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 669f0d26c3c3..2bedf73e0a7d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -110,6 +110,9 @@ enum intel_platform {
 #define INTEL_SUBPLATFORM_G10  0
 #define INTEL_SUBPLATFORM_G11  1
 
+/* ADL-S */
+#define INTEL_SUBPLATFORM_RPL_S0
+
 enum intel_ppgtt_type {
INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index c00ac54692d7..baf3d1d3d566 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -666,4 +666,13 @@
INTEL_VGA_DEVICE(0x46C2, info), \
INTEL_VGA_DEVICE(0x46C3, info)
 
+/* RPL-S */
+#define INTEL_RPLS_IDS(info) \
+   INTEL_VGA_DEVICE(0xA780, info), \
+   INTEL_VGA_DEVICE(0xA781, info), \
+   INTEL_VGA_DEVICE(0xA782, info), \
+   INTEL_VGA_DEVICE(0xA783, info), \
+   INTEL_VGA_DEVICE(0xA788, info), \
+   INTEL_VGA_DEVICE(0xA789, info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.25.1

[Intel-gfx] [v3 0/3] Introduce Raptor Lake S

[Anusha Srivatsa]

Raptor Lake S(RPL-S) is a version 12
Display, Media and Render. For all i915
purposes it is the same as Alder Lake S (ADL-S).

The series introduces it as a subplatform
of ADL-S. The one difference is the GuC
submission which is default on RPL-S but
was not the case with ADL-S.

Anusha Srivatsa (3):
  drm/i915/rpl-s: Add PCI IDS for Raptor Lake S
  drm/i915/rpl-s: Add PCH Support for Raptor Lake S
  drm/i915/rpl-s: Enable guc submission by default

 arch/x86/kernel/early-quirks.c   | 1 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.c | 7 +++
 drivers/gpu/drm/i915/intel_device_info.h | 3 +++
 drivers/gpu/drm/i915/intel_pch.c | 1 +
 drivers/gpu/drm/i915/intel_pch.h | 1 +
 include/drm/i915_pciids.h| 9 +
 9 files changed, 26 insertions(+), 1 deletion(-)

-- 
2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)
URL   : https://patchwork.freedesktop.org/series/97053/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10948 -> Patchwork_21710


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(7): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 
bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][2] -> [INCOMPLETE][3] ([i915#198] / 
[i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

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

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][6] -> [INCOMPLETE][7] ([i915#4432])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

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

  * igt@i915_selftest@live@requests:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][9] ([i915#4391])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-kbl-soraka/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][12] ([i915#2722] / [i915#3363] / 
[i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-skl-6600u/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][13] ([i915#3928] / [i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21710/fi-rkl-guc/igt@run...@aborted.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_10948 -> Patchwork_21710

  CI-20190529: 20190529
  CI_DRM_10948: 2a3a3bac4f6f02af651626eed357bbd13117055a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject 5k on HDR planes for planar fb formats (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev7)
URL   : https://patchwork.freedesktop.org/series/97053/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10948 -> Patchwork_21709


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 34)
--

  Additional (2): fi-kbl-soraka fi-pnv-d510 
  Missing(7): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 
bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][4] -> [FAIL][5] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21709/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

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

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][8] -> [INCOMPLETE][9] ([i915#4432])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10948/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21709/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21709/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][14] ([i915#3363] / [i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21709/fi-skl-6600u/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][15] ([i915#3928] / [i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21709/fi-rkl-guc/igt@run...@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_10948 -> Patchwork_21709

  CI-20190529: 20190529
  CI_DRM_10948: 2a3a3bac4f6f02af651626eed357bbd13117055a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev8)
URL   : https://patchwork.freedesktop.org/series/97053/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
dd6fd0244481 drm/i915: Add PLANE_CUS_CTL restriction in max_width
-:42: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#42: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:424:
+static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
+   int color_plane,

-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:434:
+static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
+   int color_plane,

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

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

v3: Addressed review comments from Ville. Changed names of
HDR and SDR max_width functions to icl_hdr_plane_max_width
and icl_sdr_plane_max_width

v4: Fixed paranthesis alignment. No code change

Reviewed-by: Ville Syrjälä 
Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
---
 .../drm/i915/display/skl_universal_plane.c| 21 +++
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..e717eb58b105 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -420,9 +420,19 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
-  int color_plane,
-  unsigned int rotation)
+static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
+   int color_plane,
+   unsigned int rotation)
+{
+   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+   else
+   return 5120;
+}
+
+static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
+   int color_plane,
+   unsigned int rotation)
 {
return 5120;
 }
@@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
if (DISPLAY_VER(dev_priv) >= 11) {
plane->min_width = icl_plane_min_width;
-   plane->max_width = icl_plane_max_width;
+   if (icl_is_hdr_plane(dev_priv, plane_id))
+   plane->max_width = icl_hdr_plane_max_width;
+   else
+   plane->max_width = icl_sdr_plane_max_width;
plane->max_height = icl_plane_max_height;
plane->min_cdclk = icl_plane_min_cdclk;
} else if (DISPLAY_VER(dev_priv) >= 10) {
-- 
2.33.0

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reject 5k on HDR planes for planar fb formats (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev7)
URL   : https://patchwork.freedesktop.org/series/97053/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
24b77f8800af drm/i915: Add PLANE_CUS_CTL restriction in max_width
-:38: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#38: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:424:
+static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
+  int color_plane,

-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:434:
+static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
   int color_plane,

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

Re: [Intel-gfx] [PATCH] drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()

[John Harrison]

On 11/23/2021 06:45, ravitejax.goud.ta...@intel.com wrote:

From: raviteja goud talla 

Bspec page says "Reset: BUS", Accordingly moving w/a's:
Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
Which will resolve guc enabling error

Cc: John Harrison 
Signed-off-by: raviteja goud talla 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a9727447c037..4f7b598d21b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1231,6 +1231,15 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
GAMT_CHKN_BIT_REG,
GAMT_CHKN_DISABLE_L3_COH_PIPE);
  
+	/* Wa_1407352427:icl,ehl */

+   wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
+   PSDUNIT_CLKGATE_DIS);
+
+   /* Wa_1406680159:icl,ehl */
+   wa_write_or(wal,
+   SUBSLICE_UNIT_LEVEL_CLKGATE,
+   GWUNIT_CLKGATE_DIS);
+
/* Wa_1607087056:icl,ehl,jsl */
if (IS_ICELAKE(i915) ||
IS_JSL_EHL_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
@@ -2272,15 +2281,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
  
-		/* Wa_1407352427:icl,ehl */

-   wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
-   PSDUNIT_CLKGATE_DIS);
-
-   /* Wa_1406680159:icl,ehl */
-   wa_write_or(wal,
-   SUBSLICE_UNIT_LEVEL_CLKGATE,
-   GWUNIT_CLKGATE_DIS);
-
/*
 * Wa_1408767742:icl[a2..forever],ehl[all]
 * Wa_1605460711:icl[a0..c0]

Re: [Intel-gfx] [PATCH i-g-t 6/6] intel_gpu_top: Add a sanity check discovered busy metric is per engine

[Rogozhkin, Dmitry V]

On Fri, 2021-11-19 at 12:59 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Adding a cross-check with ABI config name space and not just relying
> on
> sysfs names.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Dmitry Rogozhkin 
> ---
>  tools/intel_gpu_top.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index 41c59a72c09d..81c724d1fe1c 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -376,6 +376,12 @@ static struct engines *discover_engines(char
> *device)
>   break;
>   }
>  
> + /* Double check config is an engine config. */
> + if (engine->busy.config >= __I915_PMU_OTHER(0)) {
> + free((void *)engine->name);
> + continue;
> + }
> +
>   engine->class = (engine->busy.config &
>(__I915_PMU_OTHER(0) - 1)) >>
>   I915_PMU_CLASS_SHIFT;

This works for me.
Acked-by: Dmitry Rogozhkin 

However, looking to the existing code down below the place where you've
added a fix, it seems to me that 'free((void *)engine->name)' might be
missing on a number of other error paths and on non-error exit path as
well.

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

v3: Addressed review comments from Ville. Changed names of
HDR and SDR max_width functions to icl_hdr_plane_max_width
and icl_sdr_plane_max_width

Reviewed-by: Ville Syrjälä 
Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
---
 .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..e7205a53dc2f 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
+static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
+  int color_plane,
+  unsigned int rotation)
+{
+   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+   else
+   return 5120;
+}
+
+static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
if (DISPLAY_VER(dev_priv) >= 11) {
plane->min_width = icl_plane_min_width;
-   plane->max_width = icl_plane_max_width;
+   if (icl_is_hdr_plane(dev_priv, plane_id))
+   plane->max_width = icl_hdr_plane_max_width;
+   else
+   plane->max_width = icl_sdr_plane_max_width;
plane->max_height = icl_plane_max_height;
plane->min_cdclk = icl_plane_min_cdclk;
} else if (DISPLAY_VER(dev_priv) >= 10) {
-- 
2.33.0

Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Srinivas, Vidya]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 11:40 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Tue, Nov 30, 2021 at 10:42:20PM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > v2: Addressed review comments from Ville. Added separate functions for
> > max_width - for HDR and SDR
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > ---
> >  .../gpu/drm/i915/display/skl_universal_plane.c  | 17
> > +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..d320a3ba1ade 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
> 
> Naming wise I would probably go with icl_hdr_plane_max_width() and
> icl_sdr_plane_max_width().
> 
> Reviewed-by: Ville Syrjälä 

Thank you very much Ville, for the patch review and RB. Have fixed the naming.

Regards
Vidya

> 
> > +  int color_plane,
> > +  unsigned int rotation)
> > +{
> > +   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +   else
> > +   return 5120;
> > +}
> > +
> > +static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct
> > drm_i915_private *dev_priv,
> >
> > if (DISPLAY_VER(dev_priv) >= 11) {
> > plane->min_width = icl_plane_min_width;
> > -   plane->max_width = icl_plane_max_width;
> > +   if (icl_is_hdr_plane(dev_priv, plane_id))
> > +   plane->max_width = icl_plane_max_width_hdr;
> > +   else
> > +   plane->max_width = icl_plane_max_width_sdr;
> > plane->max_height = icl_plane_max_height;
> > plane->min_cdclk = icl_plane_min_cdclk;
> > } else if (DISPLAY_VER(dev_priv) >= 10) {
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

v3: Addressed review comments from Ville. Changed names of
HDR and SDR max_width functions to icl_hdr_plane_max_width
and icl_sdr_plane_max_width

Reviewed-by: Ville Syrjälä 
Signed-off-by: Yashashvi Shantam 
---
 .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..e7205a53dc2f 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
+static int icl_hdr_plane_max_width(const struct drm_framebuffer *fb,
+  int color_plane,
+  unsigned int rotation)
+{
+   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+   else
+   return 5120;
+}
+
+static int icl_sdr_plane_max_width(const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
if (DISPLAY_VER(dev_priv) >= 11) {
plane->min_width = icl_plane_min_width;
-   plane->max_width = icl_plane_max_width;
+   if (icl_is_hdr_plane(dev_priv, plane_id))
+   plane->max_width = icl_hdr_plane_max_width;
+   else
+   plane->max_width = icl_sdr_plane_max_width;
plane->max_height = icl_plane_max_height;
plane->min_cdclk = icl_plane_min_cdclk;
} else if (DISPLAY_VER(dev_priv) >= 10) {
-- 
2.33.0

Re: [Intel-gfx] [PATCH v5] drm/i915: Re-use i915 macros for checking PTEs

[Lucas De Marchi]

On Thu, Nov 18, 2021 at 12:54:32PM -0800, Michael Cheng wrote:

Certain gen8 ppgtt/gtt functions are using _PAGE_RW and _PAGE_PRESENT to check
bits 0 and 1 for PTEs. These macros are defined per architectures, and some
architectures do not have these defined (like arm64). This patch replaces these
two macros with their i915 equivalent implementation.

Signed-off-by: Michael Cheng 



Reviewed-by: Lucas De Marchi 

thanks
Lucas De Marchi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Perform 30ms delay after source OUI write (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev3)
URL   : https://patchwork.freedesktop.org/series/96871/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945_full -> Patchwork_21708_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 10)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: NOTRUN -> [SKIP][1] ([i915#4525])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-iclb7/igt@gem_exec_balan...@parallel-out-fence.html

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

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

  * igt@gem_exec_fair@basic-sync@rcs0:
- shard-kbl:  [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-kbl2/igt@gem_exec_fair@basic-s...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-kbl6/igt@gem_exec_fair@basic-s...@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][8] -> [DMESG-WARN][9] ([i915#118])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html

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

  * igt@gem_render_copy@y-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][11] ([i915#768])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-iclb5/igt@gem_render_c...@y-tiled-to-vebox-y-tiled.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][12] -> [DMESG-WARN][13] ([i915#1436] / 
[i915#716])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-skl5/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2521])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-glk6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-glk5/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3777])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-apl2/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110723])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-iclb5/igt@kms_big...@yf-tiled-64bpp-rotate-270.html

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-apl2/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-kbl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-kbl4/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3886]) +3 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/shard-skl8/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html

  * igt@kms_cdclk@mode-transition:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271]) +26 similar issues
   [21]: 

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Use to_root_gt() to refer to the root tile

[Lucas De Marchi]

On Wed, Dec 01, 2021 at 12:41:08AM +0200, Andi Shyti wrote:

Hi Lucas,

fist of all thanks for taking a look at this, I was eagerly
waiting for reviewers.

On Tue, Nov 30, 2021 at 01:07:30PM -0800, Lucas De Marchi wrote:

On Sun, Nov 28, 2021 at 01:09:26PM +0200, Andi Shyti wrote:
> Starting from a patch from Matt to_root_gt() returns the
> reference to the root tile in order to abstract the root tile
> from th callers.
>
> Being the root tile identified as tile '0', embed the id in the
> name so that i915->gt becomes i915->gt0.
>
> The renaming has been mostly done with the following command and
> some manual fixes.
>
> sed -i -e sed -i 's/\\->gt\./\_root_gt(i915)\->/g' \
>-e sed -i 's/\_priv\->gt\./\_root_gt(dev_priv)\->/g' \
>-e 's/\_priv\->gt/to_root_gt(dev_priv)/g' \
>-e 's/\\->gt/to_root_gt(i915)/g' \
>-e 's/dev_priv\->gt\./to_root_gt(dev_priv)\->/g' \
>-e 's/i915\->gt\./to_root_gt(i915)\->/g' \
>`find drivers/gpu/drm/i915/ -name *.[ch]`
>
> Two small changes have been added to this commit:
>
> 1. intel_reset_gpu() in intel_display.c retreives the gt from
>to_scanout_gt()
> 2. in set_scheduler_caps() the gt is taken from the engine and
>not from i915.

Ideally the non-automatic changes should be in separate patches, before
the ones that can be done by automation. Because then it becomes easier
to apply the final result without conflicts.


OK


This is quite a big diff to merge in one go. Looking at the pending
patches from Michal however I see he had similar changes, split in
sensible chunks..  Could you split your version like that? at least
gt/gem and display would be good to have separate. Or sync with Michal
on how to proceed with these versions Here are his patches:

drm/i915: Remove i915->ggtt
drm/i915: Use to_gt() helper for GGTT accesses
drm/i915: Use to_gt() helper
drm/i915/gvt: Use to_gt() helper
drm/i915/gem: Use to_gt() helper
drm/i915/gt: Use to_gt() helper
drm/i915/display: Use to_gt() helper
drm/i915: Introduce to_gt() helper


I understand... will follow this approach.


This first patch also removed the `struct intel_gt *gt = to_gt(pool)`,
that would otherwise be a leftover in 
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c


One difference from Michal patch is that I am not using the
wrapper

 to_gt(...)

but

 to_root_gt(...)

which was introduced by Matt. To me sounds more meaningful as it
specifies that we are really looking for the root tile and not
any tile.


yes, I think it makes sense, too.  Michal, any comment?  I think you
also had other plans to get the root gt by another helper... ?

Lucas De Marchi

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Store backpointer to GT in uncore

[Andi Shyti]

Hi,

ping! (Lucas?)

> We now support a per-gt uncore, yet we're not able to infer which GT
> we're operating upon.  Let's store a backpointer for now.
> 
> Signed-off-by: Michał Winiarski 
> Signed-off-by: Matt Roper 
> Reviewed-by: Andi Shyti 
> Signed-off-by: Andi Shyti 

can we merge this, meanwhile?

Andi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Drop stealing of bits from i915_sw_fence function pointer (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Drop stealing of bits from i915_sw_fence function pointer 
(rev5)
URL   : https://patchwork.freedesktop.org/series/94924/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945_full -> Patchwork_21706_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 10)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-iclb6/igt@gem_exec_balan...@parallel-out-fence.html

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

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][8] -> [DMESG-WARN][9] ([i915#118])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-skl9/igt@gem_lmem_swapp...@heavy-verify-random.html
- shard-apl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-apl4/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][12] -> [INCOMPLETE][13] ([i915#3921])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-snb6/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-snb7/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3777])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-apl4/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-apl4/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +3 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-skl5/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-kbl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-kbl4/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_ccs:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-iclb6/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_ccs.html

  * igt@kms_cdclk@mode-transition:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271]) +34 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-apl4/igt@kms_cd...@mode-transition.html
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#3742])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/shard-iclb6/igt@kms_cd...@mode-transition.html

  * igt@kms_chamelium@hdmi-aspect-ratio:
- shard-skl:  NOTRUN -> 

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Implement Wa_1508744258"

[Matt Atwood]

On Fri, Nov 19, 2021 at 02:13:53PM +, Souza, Jose wrote:
> On Fri, 2021-11-19 at 06:09 -0800, José Roberto de Souza wrote:
> > This workarounds are causing hangs, because I missed the fact that it
> > needs to be enabled for all cases and disabled when doing a resolve
> > pass.
> > 
> > So KMD only needs to whitelist it and UMD will be the one setting it
> > on per case.
> > 
> > This reverts commit 28ec02c9cbebf3feeaf21a59df9dfbc02bda3362.
> 
> Missed a:
> 
> Fixes: 28ec02c9cbeb ("drm/i915: Implement Wa_1508744258")
> 
> So this can be propagated to older kernels, will add while applying.
> 
> > 
> > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/4145
> > Signed-off-by: José Roberto de Souza 
Reviewed-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ---
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index a9727447c0379..cd2935b9e7c81 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -637,13 +637,6 @@ static void gen12_ctx_workarounds_init(struct 
> > intel_engine_cs *engine,
> >FF_MODE2_GS_TIMER_MASK,
> >FF_MODE2_GS_TIMER_224,
> >0, false);
> > -
> > -   /*
> > -* Wa_14012131227:dg1
> > -* Wa_1508744258:tgl,rkl,dg1,adl-s,adl-p
> > -*/
> > -   wa_masked_en(wal, GEN7_COMMON_SLICE_CHICKEN1,
> > -GEN9_RHWO_OPTIMIZATION_DISABLE);
> >  }
> >  
> >  static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine,
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()

[Patchwork]

== Series Details ==

Series: lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()
URL   : https://patchwork.freedesktop.org/series/97422/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945_full -> Patchwork_21703_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@unwedge-stress:
- shard-iclb: NOTRUN -> [TIMEOUT][1] ([i915#2481] / [i915#3070])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-iclb8/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-skl9/igt@gem_exec_capture@p...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-skl7/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2846])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-glk3/igt@gem_exec_f...@basic-deadline.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-glk9/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.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_10945/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_suspend@basic-s3:
- shard-skl:  [PASS][13] -> [INCOMPLETE][14] ([i915#198])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-skl6/igt@gem_exec_susp...@basic-s3.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-skl8/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked.html

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

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

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

  * igt@i915_pm_backlight@fade_with_dpms:
- shard-kbl:  NOTRUN -> [SKIP][21] ([fdo#109271]) +65 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-kbl4/igt@i915_pm_backlight@fade_with_dpms.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-iclb: [PASS][22] -> [FAIL][23] ([i915#2521])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/shard-iclb4/igt@kms_async_fl...@alternate-sync-async-flip.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/shard-iclb2/igt@kms_async_fl...@alternate-sync-async-flip.html

  

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Use to_root_gt() to refer to the root tile

[Andi Shyti]

Hi Lucas,

fist of all thanks for taking a look at this, I was eagerly
waiting for reviewers.

On Tue, Nov 30, 2021 at 01:07:30PM -0800, Lucas De Marchi wrote:
> On Sun, Nov 28, 2021 at 01:09:26PM +0200, Andi Shyti wrote:
> > Starting from a patch from Matt to_root_gt() returns the
> > reference to the root tile in order to abstract the root tile
> > from th callers.
> > 
> > Being the root tile identified as tile '0', embed the id in the
> > name so that i915->gt becomes i915->gt0.
> > 
> > The renaming has been mostly done with the following command and
> > some manual fixes.
> > 
> > sed -i -e sed -i 's/\\->gt\./\_root_gt(i915)\->/g' \
> > -e sed -i 's/\_priv\->gt\./\_root_gt(dev_priv)\->/g' \
> > -e 's/\_priv\->gt/to_root_gt(dev_priv)/g' \
> > -e 's/\\->gt/to_root_gt(i915)/g' \
> > -e 's/dev_priv\->gt\./to_root_gt(dev_priv)\->/g' \
> > -e 's/i915\->gt\./to_root_gt(i915)\->/g' \
> > `find drivers/gpu/drm/i915/ -name *.[ch]`
> > 
> > Two small changes have been added to this commit:
> > 
> > 1. intel_reset_gpu() in intel_display.c retreives the gt from
> >to_scanout_gt()
> > 2. in set_scheduler_caps() the gt is taken from the engine and
> >not from i915.
> 
> Ideally the non-automatic changes should be in separate patches, before
> the ones that can be done by automation. Because then it becomes easier
> to apply the final result without conflicts.

OK

> This is quite a big diff to merge in one go. Looking at the pending
> patches from Michal however I see he had similar changes, split in
> sensible chunks..  Could you split your version like that? at least
> gt/gem and display would be good to have separate. Or sync with Michal
> on how to proceed with these versions Here are his patches:
> 
>   drm/i915: Remove i915->ggtt
>   drm/i915: Use to_gt() helper for GGTT accesses
>   drm/i915: Use to_gt() helper
>   drm/i915/gvt: Use to_gt() helper
>   drm/i915/gem: Use to_gt() helper
>   drm/i915/gt: Use to_gt() helper
>   drm/i915/display: Use to_gt() helper
>   drm/i915: Introduce to_gt() helper

I understand... will follow this approach.

> This first patch also removed the `struct intel_gt *gt = to_gt(pool)`,
> that would otherwise be a leftover in 
> drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c

One difference from Michal patch is that I am not using the
wrapper

  to_gt(...)

but

  to_root_gt(...)

which was introduced by Matt. To me sounds more meaningful as it
specifies that we are really looking for the root tile and not
any tile.

Thanks again,
Andi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Perform 30ms delay after source OUI write (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev3)
URL   : https://patchwork.freedesktop.org/series/96871/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21708


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 33)
--

  Additional (1): fi-pnv-d510 
  Missing(8): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-adlp-4 
bat-jsl-2 bat-jsl-1 fi-skl-6600u 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

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

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][5] ([i915#1888]) -> [PASS][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][9] ([i915#4432]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][11] ([i915#295]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][13] ([i915#295]) -> [PASS][14] +10 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21708/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.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#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3970]: https://gitlab.freedesktop.org/drm/intel/issues/3970
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4642]: https://gitlab.freedesktop.org/drm/intel/issues/4642


Build changes
-

  * Linux: CI_DRM_10945 -> Patchwork_21708

  CI-20190529: 20190529
  CI_DRM_10945: ac459a8e27b90b5010d6e35302c429c1721016a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21708: e7be49d50a574b25f622f5e5066eee522308 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e7be49d50a57 drm/i915/dp: Perform 30ms delay after source OUI write

== Logs ==

For more details see: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: Perform 30ms delay after source OUI write (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev3)
URL   : https://patchwork.freedesktop.org/series/96871/
State : warning

== Summary ==

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

[Intel-gfx] [PATCH v3] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.

Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.

This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.

V3:
* Move last_oui_write into intel_dp
V2:
* Move panel delays into intel_pps

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only 
SDR for now)")
Cc: Ville Syrjälä 
Cc:  # v5.12+
---
 drivers/gpu/drm/i915/display/intel_display_types.h|  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
 drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
 4 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ea1e8a6e10b0..b9c967837872 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1653,6 +1653,9 @@ struct intel_dp {
struct intel_dp_pcon_frl frl;
 
struct intel_psr psr;
+
+   /* When we last wrote the OUI for eDP */
+   unsigned long last_oui_write;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a424bf69396..5a8206298691 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, 
bool careful)
 
if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
drm_err(>drm, "Failed to write source OUI\n");
+
+   intel_dp->last_oui_write = jiffies;
+}
+
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   drm_dbg_kms(>drm, "Performing OUI wait\n");
+   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
 }
 
 /* If the device supports it, try to set the power state appropriately */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index ce229026dc91..b64145a3869a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state);
 void intel_dp_phy_test(struct intel_encoder *encoder);
 
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
+
 #endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 8b9c925c4c16..62c112daacf2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -36,6 +36,7 @@
 
 #include "intel_backlight.h"
 #include "intel_display_types.h"
+#include "intel_dp.h"
 #include "intel_dp_aux_backlight.h"
 
 /* TODO:
@@ -106,6 +107,8 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector 
*connector)
int ret;
u8 tcon_cap[4];
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
if (ret != sizeof(tcon_cap))
return false;
@@ -204,6 +207,8 @@ intel_dp_aux_hdr_enable_backlight(const struct 
intel_crtc_state *crtc_state,
int ret;
u8 old_ctrl, ctrl;
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_readb(_dp->aux, 
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, _ctrl);
if (ret != 1) {
drm_err(>drm, "Failed to read current backlight control 
mode: %d\n", ret);
-- 
2.33.1

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Use to_root_gt() to refer to the root tile

[Lucas De Marchi]

On Sun, Nov 28, 2021 at 01:09:26PM +0200, Andi Shyti wrote:

Starting from a patch from Matt to_root_gt() returns the
reference to the root tile in order to abstract the root tile
from th callers.

Being the root tile identified as tile '0', embed the id in the
name so that i915->gt becomes i915->gt0.

The renaming has been mostly done with the following command and
some manual fixes.

sed -i -e sed -i 's/\\->gt\./\_root_gt(i915)\->/g' \
-e sed -i 's/\_priv\->gt\./\_root_gt(dev_priv)\->/g' \
-e 's/\_priv\->gt/to_root_gt(dev_priv)/g' \
-e 's/\\->gt/to_root_gt(i915)/g' \
-e 's/dev_priv\->gt\./to_root_gt(dev_priv)\->/g' \
-e 's/i915\->gt\./to_root_gt(i915)\->/g' \
`find drivers/gpu/drm/i915/ -name *.[ch]`

Two small changes have been added to this commit:

1. intel_reset_gpu() in intel_display.c retreives the gt from
   to_scanout_gt()
2. in set_scheduler_caps() the gt is taken from the engine and
   not from i915.


Ideally the non-automatic changes should be in separate patches, before
the ones that can be done by automation. Because then it becomes easier
to apply the final result without conflicts.

This is quite a big diff to merge in one go. Looking at the pending
patches from Michal however I see he had similar changes, split in
sensible chunks..  Could you split your version like that? at least
gt/gem and display would be good to have separate. Or sync with Michal
on how to proceed with these versions Here are his patches:

drm/i915: Remove i915->ggtt
drm/i915: Use to_gt() helper for GGTT accesses
drm/i915: Use to_gt() helper
drm/i915/gvt: Use to_gt() helper
drm/i915/gem: Use to_gt() helper
drm/i915/gt: Use to_gt() helper
drm/i915/display: Use to_gt() helper
drm/i915: Introduce to_gt() helper

This first patch also removed the `struct intel_gt *gt = to_gt(pool)`,
that would otherwise be a leftover in 
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c

thanks
Lucas De Marchi

Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

[Stephen Rothwell]

Hi Maxime,

On Tue, 30 Nov 2021 09:58:31 +0100 Maxime Ripard  wrote:
>
> Unfortunately the merge resolution isn't entirely correct :/
> 
> There's multiple conflicts between those two branches on that file, but
> things went wrong between 16e101051f32 and 0c980a006d3f
> 
> The first one changes the logic a bit for the clk_set_min_rate argument,
> and the second moves the clk_set_min_rate around.
> 
> However, the merge resolution reintroduced the initial clk_set_min_rate
> call line (line 373), without changing the logic of the proper call site
> (line 396).
> 
> This is the patch to fix the resolution:
> 
> -- >8 --  
> --- a/drivers/gpu/drm/vc4/vc4_kms.c   2021-11-30 08:56:28.748524275 +0100
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c   2021-11-29 15:46:11.692151678 +0100
> @@ -365,14 +365,6 @@
>   vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
>   }
> 
> - if (vc4->hvs->hvs5) {
> - unsigned long core_rate = max_t(unsigned long,
> - 5,
> - new_hvs_state->core_clock_rate);
> -
> - clk_set_min_rate(hvs->core_clk, core_rate);
> - }
> -
>   for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
>   struct drm_crtc_commit *commit;
>   int ret;
> @@ -392,8 +384,13 @@
>   old_hvs_state->fifo_state[channel].pending_commit = NULL;
>   }
> 
> - if (vc4->hvs->hvs5)
> - clk_set_min_rate(hvs->core_clk, 5);
> + if (vc4->hvs->hvs5) {
> + unsigned long core_rate = max_t(unsigned long,
> + 5,
> + new_hvs_state->core_clock_rate);
> +
> + clk_set_min_rate(hvs->core_clk, core_rate);
> + }
> 
>   drm_atomic_helper_commit_modeset_disables(dev, state);
> -- >8 --  

Thanks, I have fixed that up in my resolution.

-- 
Cheers,
Stephen Rothwell


pgp0t_CrocJv_.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

On Tue, 2021-11-30 at 12:36 +0200, Jani Nikula wrote:
> On Mon, 29 Nov 2021, Lyude Paul  wrote:
> > While working on supporting the Intel HDR backlight interface, I noticed
> > that there's a couple of laptops that will very rarely manage to boot up
> > without detecting Intel HDR backlight support - even though it's supported
> > on the system. One example of such a laptop is the Lenovo P17 1st
> > generation.
> > 
> > Following some investigation Ville Syrjälä did through the docs they have
> > available to them, they discovered that there's actually supposed to be a
> > 30ms wait after writing the source OUI before we begin setting up the rest
> > of the backlight interface.
> > 
> > This seems to be correct, as adding this 30ms delay seems to have
> > completely fixed the probing issues I was previously seeing. So - let's
> > start performing a 30ms wait after writing the OUI, which we do in a
> > manner
> > similar to how we keep track of PPS delays (e.g. record the timestamp of
> > the OUI write, and then wait for however many ms are left since that
> > timestamp right before we interact with the backlight) in order to avoid
> > waiting any longer then we need to. As well, this also avoids us
> > performing
> > this delay on systems where we don't end up using the HDR backlight
> > interface.
> > 
> > V2:
> > * Move panel delays into intel_pps
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> > (only SDR for now)")
> > Cc: Ville Syrjälä 
> > Cc:  # v5.12+
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_types.h    |  4 
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
> >  drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
> >  4 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ea1e8a6e10b0..ad64f9caa7ff 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1485,6 +1485,7 @@ struct intel_pps {
> > bool want_panel_vdd;
> > unsigned long last_power_on;
> > unsigned long last_backlight_off;
> > +   unsigned long last_oui_write;
> > ktime_t panel_power_off_time;
> > intel_wakeref_t vdd_wakeref;
> >  
> > @@ -1653,6 +1654,9 @@ struct intel_dp {
> > struct intel_dp_pcon_frl frl;
> >  
> > struct intel_psr psr;
> > +
> > +   /* When we last wrote the OUI for eDP */
> > +   unsigned long last_oui_write;
> 
> Now you're adding last_oui_write to both intel_pps and intel_dp, forgot
> to git add? ;)

Yep :P, will send out a different version in a bit
> 
> I guess I'd add this to intel_dp only, because it's not strictly about
> PPS. I just wanted the mechanism to be similar to that.
> 
> >  };
> >  
> >  enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 0a424bf69396..45318891ba07 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp
> > *intel_dp, bool careful)
> >  
> > if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> > sizeof(oui)) < 0)
> > drm_err(>drm, "Failed to write source OUI\n");
> > +
> > +   intel_dp->pps.last_oui_write = jiffies;
> 
> Set to intel_dp->last_oui_write.
> 
> With those fixes,
> 
> Reviewed-by: Jani Nikula 
> 
> 
> > +}
> > +
> > +void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +
> > +   drm_dbg_kms(>drm, "Performing OUI wait\n");
> > +   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
> >  }
> >  
> >  /* If the device supports it, try to set the power state appropriately */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> > b/drivers/gpu/drm/i915/display/intel_dp.h
> > index ce229026dc91..b64145a3869a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> > @@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp
> > *intel_dp,
> >  const struct intel_crtc_state
> > *crtc_state);
> >  void intel_dp_phy_test(struct intel_encoder *encoder);
> >  
> > +void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
> > +
> >  #endif /* __INTEL_DP_H__ */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index 8b9c925c4c16..62c112daacf2 100644
> > --- 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()
URL   : https://patchwork.freedesktop.org/series/97421/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10944_full -> Patchwork_21702_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Use per device iommu check

[Lucas De Marchi]

On Fri, Nov 26, 2021 at 02:14:24PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

With both integrated and discrete Intel GPUs in a system, the current
global check of intel_iommu_gfx_mapped, as done from intel_vtd_active()
may not be completely accurate.

In this patch we add i915 parameter to intel_vtd_active() in order to
prepare it for multiple GPUs and we also change the check away from Intel
specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU
driver) to probing the presence of IOMMU on a specific device using
device_iommu_mapped().

This will return true both for IOMMU pass-through and address translation
modes which matches the current behaviour. If in the future we wanted to
distinguish between these two modes we could either use
iommu_get_domain_for_dev() and check for __IOMMU_DOMAIN_PAGING bit
indicating address translation, or ask for a new API to be exported from
the IOMMU core code.

v2:
 * Check for dmar translation specifically, not just iommu domain. (Baolu)

v3:
* Go back to plain "any domain" check for now, rewrite commit message.

v4:
* Use device_iommu_mapped. (Robin, Baolu)

Signed-off-by: Tvrtko Ursulin 
Cc: Lu Baolu 
Cc: Lucas De Marchi 
Cc: Robin Murphy 
Acked-by: Robin Murphy 
Reviewed-by: Lu Baolu 


this last version looks pretty clean.

Also, for patches touching gem / gt we should Cc dri-devel. I'm leaving
the patch below for reference and Cc'ing it. Small nit below,
but can be ignored.


---
drivers/gpu/drm/i915/display/intel_bw.c  |  2 +-
drivers/gpu/drm/i915/display/intel_display.c |  2 +-
drivers/gpu/drm/i915/display/intel_fbc.c |  2 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c   |  2 +-
drivers/gpu/drm/i915/gem/i915_gemfs.c|  2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c |  4 ++--
drivers/gpu/drm/i915/i915_debugfs.c  |  1 +
drivers/gpu/drm/i915/i915_driver.c   |  7 +++
drivers/gpu/drm/i915/i915_drv.h  | 13 +++--
drivers/gpu/drm/i915/i915_gpu_error.c|  5 +
drivers/gpu/drm/i915/intel_device_info.c | 14 +-
drivers/gpu/drm/i915/intel_pm.c  |  2 +-
12 files changed, 25 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index abec394f6869..2da4aacc956b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -634,7 +634,7 @@ static unsigned int intel_bw_data_rate(struct 
drm_i915_private *dev_priv,
for_each_pipe(dev_priv, pipe)
data_rate += bw_state->data_rate[pipe];

-   if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active())
+   if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
data_rate = data_rate * 105 / 100;

return data_rate;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b2d51cd79d6c..1ef77ba7f645 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1293,7 +1293,7 @@ static bool needs_async_flip_vtd_wa(const struct 
intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);

-   return crtc_state->uapi.async_flip && intel_vtd_active() &&
+   return crtc_state->uapi.async_flip && intel_vtd_active(i915) &&
(DISPLAY_VER(i915) == 9 || IS_BROADWELL(i915) || 
IS_HASWELL(i915));
}

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index d0c34bc3af6c..614e8697c068 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1677,7 +1677,7 @@ static int intel_sanitize_fbc_option(struct 
drm_i915_private *i915)
static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
{
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
-   if (intel_vtd_active() &&
+   if (intel_vtd_active(i915) &&
(IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
drm_info(>drm,
 "Disabling framebuffer compression (FBC) to prevent screen 
flicker with VT-d enabled\n");
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 80680395bb3b..bce03d74a0b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -399,7 +399,7 @@ static int i915_gem_init_stolen(struct intel_memory_region 
*mem)
return 0;
}

-   if (intel_vtd_active() && GRAPHICS_VER(i915) < 8) {
+   if (intel_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(>drm,
   "%s, disabling use of stolen memory\n",
   "DMAR active");
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c 
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index dbdbdc344d87..11cd66d183e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reject 5k on HDR planes for planar fb formats (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev5)
URL   : https://patchwork.freedesktop.org/series/97053/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21707


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 33)
--

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

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- fi-bxt-dsi: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-bxt-dsi/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21707/fi-bxt-dsi/boot.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21707/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

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

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#146])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21707/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][7] ([i915#1888]) -> [PASS][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21707/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][11] ([i915#295]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21707/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547


Build changes
-

  * Linux: CI_DRM_10945 -> Patchwork_21707

  CI-20190529: 20190529
  CI_DRM_10945: ac459a8e27b90b5010d6e35302c429c1721016a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21707: 09f89f851e74a41e4b1850611f1e98e839b588ed @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

09f89f851e74 drm/i915: Add PLANE_CUS_CTL restriction in max_width

== Logs ==

Re: [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On 11/30/21 19:12, Thomas Hellström wrote:

On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:

Am 30.11.21 um 15:35 schrieb Thomas Hellström:

On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:

Am 30.11.21 um 13:56 schrieb Thomas Hellström:

On 11/30/21 13:42, Christian König wrote:

Am 30.11.21 um 13:31 schrieb Thomas Hellström:

[SNIP]

Other than that, I didn't investigate the nesting fails
enough to
say I can accurately review this. :)

Basically the problem is that within enable_signaling()
which
is
called with the dma_fence lock held, we take the dma_fence
lock
of
another fence. If that other fence is a dma_fence_array, or
a
dma_fence_chain which in turn tries to lock a
dma_fence_array
we hit
a splat.

Yeah, I already thought that you constructed something like
that.

You get the splat because what you do here is illegal, you
can't
mix
dma_fence_array and dma_fence_chain like this or you can end
up
in a
stack corruption.

Hmm. Ok, so what is the stack corruption, is it that the
enable_signaling() will end up with endless recursion? If so,
wouldn't
it be more usable we break that recursion chain and allow a
more
general use?

The problem is that this is not easily possible for
dma_fence_array
containers. Just imagine that you drop the last reference to the
containing fences during dma_fence_array destruction if any of
the
contained fences is another container you can easily run into
recursion
and with that stack corruption.

Indeed, that would require some deeper surgery.


That's one of the major reasons I came up with the
dma_fence_chain
container. This one you can chain any number of elements together
without running into any recursion.


Also what are the mixing rules between these? Never use a
dma-fence-chain as one of the array fences and never use a
dma-fence-array as a dma-fence-chain fence?

You can't add any other container to a dma_fence_array, neither
other
dma_fence_array instances nor dma_fence_chain instances.

IIRC at least technically a dma_fence_chain can contain a
dma_fence_array if you absolutely need that, but Daniel, Jason
and I
already had the same discussion a while back and came to the
conclusion
to avoid that as well if possible.

Yes, this is actually the use-case. But what I can't easily
guarantee
is that that dma_fence_chain isn't fed into a dma_fence_array
somewhere
else. How do you typically avoid that?

Meanwhile I guess I need to take a different approach in the driver
to
avoid this altogether.

Jason and I came up with a deep dive iterator for his use case, but I
think we don't want to use that any more after my dma_resv rework.

In other words when you need to create a new dma_fence_array you
flatten
out the existing construct which is at worst case
dma_fence_chain->dma_fence_array->dma_fence.

Ok, Are there any cross-driver contract here, Like every driver using a
dma_fence_array need to check for dma_fence_chain and flatten like
above?

/Thomas


Oh, and a follow up question:

If there was a way to break the recursion on final put() (using the same 
basic approach as patch 2 in this series uses to break recursion in 
enable_signaling()), so that none of these containers did require any 
special treatment, would it be worth pursuing? I guess it might be 
possible by having the callbacks drop the references rather than the 
loop in the final put. + a couple of changes in code iterating over the 
fence pointers.


/Thomas




Regards,
Christian.


/Thomas



Regards,
Christian.


/Thomas





Regards,
Christian.


But I'll update the commit message with a typical splat.

/Thomas

Re: [Intel-gfx] [PATCH] drm/i915: Skip remap_io_mapping() for non-x86 platforms

[Lucas De Marchi]

On Mon, Nov 22, 2021 at 06:01:42PM +0530, Mullati Siva wrote:

From: Siva Mullati 

Only hw that supports mappable aperture would hit this path
vm_fault_gtt/vm_fault_tmm, So we never hit this function
remap_io_mapping() in discrete, So skip this code for non-x86
architectures.

Signed-off-by: Siva Mullati 
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c |  1 +
drivers/gpu/drm/i915/i915_drv.h  |  8 --
drivers/gpu/drm/i915/i915_mm.c   |  1 +
drivers/gpu/drm/i915/i915_mm.h   | 32 
4 files changed, 34 insertions(+), 8 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_mm.h

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 65fc6ff5f59d..39bb15eafc07 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -17,6 +17,7 @@
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
#include "i915_gem_mman.h"
+#include "i915_mm.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
#include "i915_gem_ttm.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1bfadd9127fc..7ae0f0cc6866 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1967,14 +1967,6 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);

-/* i915_mm.c */
-int remap_io_mapping(struct vm_area_struct *vma,
-unsigned long addr, unsigned long pfn, unsigned long size,
-struct io_mapping *iomap);
-int remap_io_sg(struct vm_area_struct *vma,
-   unsigned long addr, unsigned long size,
-   struct scatterlist *sgl, resource_size_t iobase);
-
static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
{
if (GRAPHICS_VER(i915) >= 11)
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 666808cb3a32..f4df15fe7cf8 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -27,6 +27,7 @@


#include "i915_drv.h"
+#include "i915_mm.h"

struct remap_pfn {
struct mm_struct *mm;
diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
new file mode 100644
index ..1d3bbb9cbf43
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_mm.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_MM_H__
+#define __I915_MM_H__
+
+#include 
+
+struct vm_area_struct;
+struct io_mapping;
+struct scatterlist;
+
+#if IS_ENABLED(CONFIG_X86)
+int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,
+   struct io_mapping *iomap);
+#else
+static inline int remap_io_mapping(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long pfn, unsigned long size,
+   struct io_mapping *iomap)
+{


would probably be good to add:

pr_err("Architecture has no remap_io_mapping() and shouldn't be calling this 
function\n");
WARN_ON_ONCE(1);

the same way that is done in drivers/gpu/drm/drm_cache.c

Other than that:


Reviewed-by: Lucas De Marchi 

Since you're adding this header, can you follow up with one additional
patch to move the rest of the prototypes off i915_drv.h and into this
new header?


thanks
Lucas De Marchi



+   return 0;
+}
+#endif
+
+int remap_io_sg(struct vm_area_struct *vma,
+   unsigned long addr, unsigned long size,
+   struct scatterlist *sgl, resource_size_t iobase);
+
+#endif /* __I915_MM_H__ */
--
2.33.0

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reject 5k on HDR planes for planar fb formats (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev5)
URL   : https://patchwork.freedesktop.org/series/97053/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
09f89f851e74 drm/i915: Add PLANE_CUS_CTL restriction in max_width
-:34: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#34: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:424:
+static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
+  int color_plane,

-:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#44: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:434:
+static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
   int color_plane,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop stealing of bits from i915_sw_fence function pointer (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Drop stealing of bits from i915_sw_fence function pointer 
(rev5)
URL   : https://patchwork.freedesktop.org/series/94924/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21706


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 33)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

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

  
 Possible fixes 

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

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][8] ([i915#4432]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][10] ([i915#295]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21706/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547


Build changes
-

  * Linux: CI_DRM_10945 -> Patchwork_21706

  CI-20190529: 20190529
  CI_DRM_10945: ac459a8e27b90b5010d6e35302c429c1721016a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21706: 6f01e9cabea11f4250687a596f3727220db8d610 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6f01e9cabea1 drm/i915: Drop stealing of bits from i915_sw_fence function pointer

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 00/16] drm/i915: Remove short term pins from execbuf.

[Tvrtko Ursulin]

On 30/11/2021 11:17, Maarten Lankhorst wrote:

On 30-11-2021 09:54, Tvrtko Ursulin wrote:


Hi,

On 29/11/2021 13:47, Maarten Lankhorst wrote:

New version of the series, with feedback from previous series added.


If there was a cover letter sent for this work in the past could you please 
keep attaching it? Or if there wasn't, could you please write one?

I am worried about two things. First is that we need to have a high level 
overview of the rules/design changes documented so third party people have any 
hope of getting code right after this lands. (Where we are, where we are going, 
how we will get there, how far did we get and when we will get to the end.)

Second is that when parts of the series land piecemeal (Which they have in this 
right, right?), it gets very hard to write up a maintainer level changelog.


The preparation part is to ensure we always hold vma->obj->resv when unbinding.

The first preparation series ensured vma->obj always existed. This was not the 
case for mock gtt and gen6 aliasing gtt. This allowed us to remove all the special 
handling for those uncommon cases, and actually enforce we can always take that 
lock. This part is merged.


Sounds good. But also mention the high level motivation for why we 
always want to hold vma->obj->resv when unbinding in the introduction as 
well.




Patch 2-11 in this series adds the vma->obj->resv to eviction and shrinker. 
Those are the only parts where we don't take the lock yet.

After that, we always hold the lock when required, and we can start requiring the 
obj-> resv lock when unbinding. This is completed in patch 15.

With that fixed, removing short term pins can be done, because for unbind we now 
always take obj->resv, so holding obj->resv during execbuf submission is 
sufficient, and all short term pinning can be removed.


I'd also like the cover letter to contain a high level description on 
_why_ is removing short term pins needed or beneficial.


What was the flow and object lifetimes so far, and what it will be going 
forward etc.




We only pin temporarily when calling i915_gem_evict_vm in execbuf, which could 
also be handled in theory by just marking all objects as unpinned.

As a bonus, using TTM for delayed eviction on all objects becomes easy, just 
need to get rid of i915_active in i915_vma, as it keeps the object refcount 
alive.

Remainder is removing refcount to i915_vma, to make it a real


Sounds on the right track with maybe a bit more text so the readers can 
easily understand it on the higher level.





But in any case, even on the mundane process level, we need to have cover 
letters for any non trivial work was the conclusion since some time ago.


Here you go! I hope it explains the reasoning.


It is on the right track. I think just needs to be expanded a bit with 
high level direction and plan, pointing out where in the grand scheme 
this series is. And then don't forget to add the improved text as cover 
letter when sending next time please.


Regards,

Tvrtko

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftest: Disable IRQ for timestamp calculation (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/selftest: Disable IRQ for timestamp calculation (rev3)
URL   : https://patchwork.freedesktop.org/series/96853/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10943_full -> Patchwork_21701_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_fenced_exec_thrash@too-many-fences:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-snb4/igt@gem_fenced_exec_thr...@too-many-fences.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-snb5/igt@gem_fenced_exec_thr...@too-many-fences.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-iclb6/igt@gem_exec_balan...@parallel-out-fence.html

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

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-kbl7/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-kbl7/igt@gem_exec_fair@basic-none-r...@rcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

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

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

  * igt@i915_suspend@debugfs-reader:
- shard-kbl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-kbl2/igt@i915_susp...@debugfs-reader.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-kbl4/igt@i915_susp...@debugfs-reader.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3777]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-kbl3/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-32bpp-rotate-0:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-glk4/igt@kms_big...@y-tiled-32bpp-rotate-0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-glk2/igt@kms_big...@y-tiled-32bpp-rotate-0.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][19] ([i915#3743])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/shard-skl9/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  * 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Drop stealing of bits from i915_sw_fence function pointer (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Drop stealing of bits from i915_sw_fence function pointer 
(rev5)
URL   : https://patchwork.freedesktop.org/series/94924/
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 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
> Am 30.11.21 um 15:35 schrieb Thomas Hellström:
> > On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
> > > Am 30.11.21 um 13:56 schrieb Thomas Hellström:
> > > > On 11/30/21 13:42, Christian König wrote:
> > > > > Am 30.11.21 um 13:31 schrieb Thomas Hellström:
> > > > > > [SNIP]
> > > > > > > Other than that, I didn't investigate the nesting fails
> > > > > > > enough to
> > > > > > > say I can accurately review this. :)
> > > > > > Basically the problem is that within enable_signaling()
> > > > > > which
> > > > > > is
> > > > > > called with the dma_fence lock held, we take the dma_fence
> > > > > > lock
> > > > > > of
> > > > > > another fence. If that other fence is a dma_fence_array, or
> > > > > > a
> > > > > > dma_fence_chain which in turn tries to lock a
> > > > > > dma_fence_array
> > > > > > we hit
> > > > > > a splat.
> > > > > Yeah, I already thought that you constructed something like
> > > > > that.
> > > > > 
> > > > > You get the splat because what you do here is illegal, you
> > > > > can't
> > > > > mix
> > > > > dma_fence_array and dma_fence_chain like this or you can end
> > > > > up
> > > > > in a
> > > > > stack corruption.
> > > > Hmm. Ok, so what is the stack corruption, is it that the
> > > > enable_signaling() will end up with endless recursion? If so,
> > > > wouldn't
> > > > it be more usable we break that recursion chain and allow a
> > > > more
> > > > general use?
> > > The problem is that this is not easily possible for
> > > dma_fence_array
> > > containers. Just imagine that you drop the last reference to the
> > > containing fences during dma_fence_array destruction if any of
> > > the
> > > contained fences is another container you can easily run into
> > > recursion
> > > and with that stack corruption.
> > Indeed, that would require some deeper surgery.
> > 
> > > That's one of the major reasons I came up with the
> > > dma_fence_chain
> > > container. This one you can chain any number of elements together
> > > without running into any recursion.
> > > 
> > > > Also what are the mixing rules between these? Never use a
> > > > dma-fence-chain as one of the array fences and never use a
> > > > dma-fence-array as a dma-fence-chain fence?
> > > You can't add any other container to a dma_fence_array, neither
> > > other
> > > dma_fence_array instances nor dma_fence_chain instances.
> > > 
> > > IIRC at least technically a dma_fence_chain can contain a
> > > dma_fence_array if you absolutely need that, but Daniel, Jason
> > > and I
> > > already had the same discussion a while back and came to the
> > > conclusion
> > > to avoid that as well if possible.
> > Yes, this is actually the use-case. But what I can't easily
> > guarantee
> > is that that dma_fence_chain isn't fed into a dma_fence_array
> > somewhere
> > else. How do you typically avoid that?
> > 
> > Meanwhile I guess I need to take a different approach in the driver
> > to
> > avoid this altogether.
> 
> Jason and I came up with a deep dive iterator for his use case, but I
> think we don't want to use that any more after my dma_resv rework.
> 
> In other words when you need to create a new dma_fence_array you
> flatten 
> out the existing construct which is at worst case 
> dma_fence_chain->dma_fence_array->dma_fence.

Ok, Are there any cross-driver contract here, Like every driver using a
dma_fence_array need to check for dma_fence_chain and flatten like
above?

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > > Regards,
> > > Christian.
> > > 
> > > > /Thomas
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > Regards,
> > > > > Christian.
> > > > > 
> > > > > > But I'll update the commit message with a typical splat.
> > > > > > 
> > > > > > /Thomas
> > 
> 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Drop stealing of bits from i915_sw_fence function pointer (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Drop stealing of bits from i915_sw_fence function pointer 
(rev5)
URL   : https://patchwork.freedesktop.org/series/94924/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6f01e9cabea1 drm/i915: Drop stealing of bits from i915_sw_fence function pointer
-:8: WARNING:TYPO_SPELLING: 'seperate' may be misspelled - perhaps 'separate'?
#8: 
seperate fields for function pointer and flags. If using two different


-:128: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & 
recovery code rather than BUG() or BUG_ON()
#128: FILE: drivers/gpu/drm/i915/i915_sw_fence.c:244:
+   BUG_ON(!fn);

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

Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Ville Syrjälä]

On Tue, Nov 30, 2021 at 10:42:20PM +0530, Vidya Srinivas wrote:
> PLANE_CUS_CTL has a restriction of 4096 width even though
> PLANE_SIZE and scaler size registers supports max 5120.
> Take care of this restriction in max_width.
> 
> Without this patch, when 5k content is sent on HDR plane
> with NV12 content, FIFO underrun is seen and screen blanks
> out.
> 
> v2: Addressed review comments from Ville. Added separate
> functions for max_width - for HDR and SDR
> 
> Signed-off-by: Vidya Srinivas 
> Signed-off-by: Yashashvi Shantam 
> ---
>  .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 28890876bdeb..d320a3ba1ade 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct 
> drm_framebuffer *fb,
>   }
>  }
>  
> -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> +static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,

Naming wise I would probably go with icl_hdr_plane_max_width() and 
icl_sdr_plane_max_width().

Reviewed-by: Ville Syrjälä 

> +int color_plane,
> +unsigned int rotation)
> +{
> + if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> + return 4096;
> + else
> + return 5120;
> +}
> +
> +static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
>  int color_plane,
>  unsigned int rotation)
>  {
> @@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
> *dev_priv,
>  
>   if (DISPLAY_VER(dev_priv) >= 11) {
>   plane->min_width = icl_plane_min_width;
> - plane->max_width = icl_plane_max_width;
> + if (icl_is_hdr_plane(dev_priv, plane_id))
> + plane->max_width = icl_plane_max_width_hdr;
> + else
> + plane->max_width = icl_plane_max_width_sdr;
>   plane->max_height = icl_plane_max_height;
>   plane->min_cdclk = icl_plane_min_cdclk;
>   } else if (DISPLAY_VER(dev_priv) >= 10) {
> -- 
> 2.33.0

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject 5k on HDR planes for planar fb formats (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev4)
URL   : https://patchwork.freedesktop.org/series/97053/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21705


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 33)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21705/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][3] -> [FAIL][4] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21705/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

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

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][8] ([i915#1888]) -> [PASS][9] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21705/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][12] ([i915#4432]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21705/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][14] ([i915#295]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21705/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547


Build changes
-

  * Linux: CI_DRM_10945 -> Patchwork_21705

  CI-20190529: 20190529
  CI_DRM_10945: ac459a8e27b90b5010d6e35302c429c1721016a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21705: 2930434c940dc9667d2b86a145091fcdeb4e9230 @ 

Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Srinivas, Vidya]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 10:00 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> ; Yashashvi, Shantam
> 
> Subject: Re: [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width
> 
> On Tue, Nov 30, 2021 at 09:35:34PM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Take care of this restriction in max_width.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out.
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > Change-Id: If629c478ba044c8bde633de9f0fc638aa6c44233
> > ---
> >  .../gpu/drm/i915/display/intel_display_types.h  |  3 ++-
> > .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +
> >  2 files changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ea1e8a6e10b0..0455ea340329 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1358,7 +1358,8 @@ struct intel_plane {
> > int (*min_width)(const struct drm_framebuffer *fb,
> >  int color_plane,
> >  unsigned int rotation);
> > -   int (*max_width)(const struct drm_framebuffer *fb,
> > +   int (*max_width)(struct intel_plane *plane,
> > +const struct drm_framebuffer *fb,
> >  int color_plane,
> >  unsigned int rotation);
> > int (*max_height)(const struct drm_framebuffer *fb, diff --git
> > a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 28890876bdeb..a49829c5a863 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -313,7 +313,8 @@ static int skl_plane_min_cdclk(const struct
> intel_crtc_state *crtc_state,
> > return DIV_ROUND_UP(pixel_rate * num, den);  }
> >
> > -static int skl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int skl_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -352,7 +353,8 @@ static int skl_plane_max_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int glk_plane_max_width(const struct drm_framebuffer *fb,
> > +static int glk_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > @@ -420,10 +422,17 @@ static int icl_plane_min_width(const struct
> drm_framebuffer *fb,
> > }
> >  }
> >
> > -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> > +static int icl_plane_max_width(struct intel_plane *plane,
> > +   const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> >  {
> > +   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > +
> > +   if (icl_is_hdr_plane(dev_priv, plane->id) &&
> 
> We could just have separate functions for hdr and sdr planes instead.

Thank you very much Ville, for the patch review. Have added two different 
functions as suggested.
Can you kindly have a check.
Sorry - Not sure why, I don't see the change reflect in patchwork website 
although I am seeing the mail. 

Regards
Vidya

> 
> > +   intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> > +   return 4096;
> > +
> > return 5120;
> >  }
> >
> > @@ -1377,7 +1386,7 @@ static int intel_plane_max_width(struct
> intel_plane *plane,
> >  unsigned int rotation)
> >  {
> > if (plane->max_width)
> > -   return plane->max_width(fb, color_plane, rotation);
> > +   return plane->max_width(plane, fb, color_plane, rotation);
> > else
> > return INT_MAX;
> >  }
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
---
 .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..d320a3ba1ade 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
+static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
+  int color_plane,
+  unsigned int rotation)
+{
+   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+   else
+   return 5120;
+}
+
+static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
if (DISPLAY_VER(dev_priv) >= 11) {
plane->min_width = icl_plane_min_width;
-   plane->max_width = icl_plane_max_width;
+   if (icl_is_hdr_plane(dev_priv, plane_id))
+   plane->max_width = icl_plane_max_width_hdr;
+   else
+   plane->max_width = icl_plane_max_width_sdr;
plane->max_height = icl_plane_max_height;
plane->min_cdclk = icl_plane_min_cdclk;
} else if (DISPLAY_VER(dev_priv) >= 10) {
-- 
2.33.0

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reject 5k on HDR planes for planar fb formats (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev4)
URL   : https://patchwork.freedesktop.org/series/97053/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2930434c940d drm/i915: Add PLANE_CUS_CTL restriction in max_width
-:30: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#30: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:424:
+static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
+  int color_plane,

-:40: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#40: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:434:
+static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
   int color_plane,

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Attempt to avoid dma-fence-[chain|array] lockdep splats

[Patchwork]

== Series Details ==

Series: Attempt to avoid dma-fence-[chain|array] lockdep splats
URL   : https://patchwork.freedesktop.org/series/97410/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10943_full -> Patchwork_21700_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#198]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-skl9/igt@gem_ctx_isolation@preservation...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-iclb5/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2846])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-glk2/igt@gem_exec_f...@basic-deadline.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-glk7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html

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

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

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

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-apl6/igt@i915_susp...@sysfs-reader.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-apl3/igt@i915_susp...@sysfs-reader.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2521])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/shard-iclb8/igt@kms_async_fl...@alternate-sync-async-flip.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-iclb1/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][18] ([i915#3743]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-skl5/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +10 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-skl5/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-kbl2/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#3689])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/shard-tglb3/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_ccs.html
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#109278])
   

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
---
 .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..d320a3ba1ade 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -420,7 +420,17 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
+static int icl_plane_max_width_hdr(const struct drm_framebuffer *fb,
+  int color_plane,
+  unsigned int rotation)
+{
+   if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+   else
+   return 5120;
+}
+
+static int icl_plane_max_width_sdr(const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -2108,7 +2118,10 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
if (DISPLAY_VER(dev_priv) >= 11) {
plane->min_width = icl_plane_min_width;
-   plane->max_width = icl_plane_max_width;
+   if (icl_is_hdr_plane(dev_priv, plane_id))
+   plane->max_width = icl_plane_max_width_hdr;
+   else
+   plane->max_width = icl_plane_max_width_sdr;
plane->max_height = icl_plane_max_height;
plane->min_cdclk = icl_plane_min_cdclk;
} else if (DISPLAY_VER(dev_priv) >= 10) {
-- 
2.33.0

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reject 5k on HDR planes for planar fb formats (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev2)
URL   : https://patchwork.freedesktop.org/series/97053/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21704


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 33)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-snb-2520m:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-snb-2520m/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-snb-2520m/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

  * igt@runner@aborted:
- fi-snb-2520m:   NOTRUN -> [FAIL][5] ([i915#2426] / [i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-snb-2520m/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][6] ([i915#1888]) -> [PASS][7] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][10] ([i915#4432]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][12] ([i915#4269]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
- fi-cfl-8109u:   [DMESG-FAIL][14] ([i915#295]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21704/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432


Build changes
-

  * Linux: 

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()

[Patchwork]

== Series Details ==

Series: lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()
URL   : https://patchwork.freedesktop.org/series/97422/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10945 -> Patchwork_21703


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 32)
--

  Missing(8): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 
bat-adlp-4 bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [FAIL][5] ([i915#1888]) -> [PASS][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-FAIL][9] ([i915#295]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10945/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21703/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312


Build changes
-

  * Linux: CI_DRM_10945 -> Patchwork_21703

  CI-20190529: 20190529
  CI_DRM_10945: ac459a8e27b90b5010d6e35302c429c1721016a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21703: 1f78708e5ae47e3df0877c430639309e27e45e8a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1f78708e5ae4 lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Reject 5k on HDR planes for planar fb formats (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev2)
URL   : https://patchwork.freedesktop.org/series/97053/
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: Reject 5k on HDR planes for planar fb formats (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats (rev2)
URL   : https://patchwork.freedesktop.org/series/97053/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
84c898254500 drm/i915: Add PLANE_CUS_CTL restriction in max_width
-:16: ERROR:GERRIT_CHANGE_ID: Remove Gerrit Change-Id's before submitting 
upstream
#16: 
Change-Id: If629c478ba044c8bde633de9f0fc638aa6c44233

-:42: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#42: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:317:
+static int skl_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,

-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:357:
+static int glk_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,

-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:426:
+static int icl_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,

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

Re: [Intel-gfx] [PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API

[Christoph Hellwig]

I still think this goes into the wrong direction.

Something closer to your first version that also saves away the
gvt->mmio.mmio_attribute flags in the core i915 module, and which
splits the MMIO table into one that contains just the offset, size
and flags (core i915) and one that has the read-only mask and handlers
(gvt) would be much simpler and not create this super-tight coupling
between core i915 and gvt.

Bonus points for moving your new intel_gvt_hw_state structure out
of struct intel_gvt and into struct i915_virtual_gpu.

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Update error capture code to avoid using the current vma state

[Vudum, Lakshminarayana]

Filed this issue and re-reported
https://gitlab.freedesktop.org/drm/intel/-/issues/4664
igt@kms_flip@busy-flip@b-edp1 - incomplete - No warnings/errors

Thanks,
Lakshmi.

From: Thomas Hellström 
Sent: Monday, November 29, 2021 9:46 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Update error capture code to 
avoid using the current vma state

On Tue, 2021-11-30 at 01:50 +, Patchwork wrote:
Patch Details
Series:

drm/i915: Update error capture code to avoid using the current vma state

URL:

https://patchwork.freedesktop.org/series/97385/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/index.html

CI Bug Log - changes from CI_DRM_10939_full -> Patchwork_21696_full
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21696_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 -> 10)

Missing (1): pig-kbl-iris

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_flip@busy-flip@b-edp1:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE


Lakshmi,

This failure is unrelated.

Thanks,
Thomas




Known issues

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

CI changes
Possible fixes

  *   boot:

 *   shard-skl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 ([i915#4337]) -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().

[Sebastian Andrzej Siewior]

On 2021-11-19 17:04:00 [+0100], Daniel Vetter wrote:
> Yeah if we can simplify this with reverts then I'm all for this.
> 
> Acked-by: Daniel Vetter 
> 
> I've asked drm/i915 maintainers to check

Thanks. Should I repost my queue (excluding this one) or should wait
until this one has been taken care?

> -Daniel

Sebastian

Re: [Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Ville Syrjälä]

On Tue, Nov 30, 2021 at 09:35:34PM +0530, Vidya Srinivas wrote:
> PLANE_CUS_CTL has a restriction of 4096 width even though
> PLANE_SIZE and scaler size registers supports max 5120.
> Take care of this restriction in max_width.
> 
> Without this patch, when 5k content is sent on HDR plane
> with NV12 content, FIFO underrun is seen and screen blanks
> out.
> 
> Signed-off-by: Vidya Srinivas 
> Signed-off-by: Yashashvi Shantam 
> Change-Id: If629c478ba044c8bde633de9f0fc638aa6c44233
> ---
>  .../gpu/drm/i915/display/intel_display_types.h  |  3 ++-
>  .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ea1e8a6e10b0..0455ea340329 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1358,7 +1358,8 @@ struct intel_plane {
>   int (*min_width)(const struct drm_framebuffer *fb,
>int color_plane,
>unsigned int rotation);
> - int (*max_width)(const struct drm_framebuffer *fb,
> + int (*max_width)(struct intel_plane *plane,
> +  const struct drm_framebuffer *fb,
>int color_plane,
>unsigned int rotation);
>   int (*max_height)(const struct drm_framebuffer *fb,
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 28890876bdeb..a49829c5a863 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -313,7 +313,8 @@ static int skl_plane_min_cdclk(const struct 
> intel_crtc_state *crtc_state,
>   return DIV_ROUND_UP(pixel_rate * num, den);
>  }
>  
> -static int skl_plane_max_width(const struct drm_framebuffer *fb,
> +static int skl_plane_max_width(struct intel_plane *plane,
> + const struct drm_framebuffer *fb,
>  int color_plane,
>  unsigned int rotation)
>  {
> @@ -352,7 +353,8 @@ static int skl_plane_max_width(const struct 
> drm_framebuffer *fb,
>   }
>  }
>  
> -static int glk_plane_max_width(const struct drm_framebuffer *fb,
> +static int glk_plane_max_width(struct intel_plane *plane,
> + const struct drm_framebuffer *fb,
>  int color_plane,
>  unsigned int rotation)
>  {
> @@ -420,10 +422,17 @@ static int icl_plane_min_width(const struct 
> drm_framebuffer *fb,
>   }
>  }
>  
> -static int icl_plane_max_width(const struct drm_framebuffer *fb,
> +static int icl_plane_max_width(struct intel_plane *plane,
> + const struct drm_framebuffer *fb,
>  int color_plane,
>  unsigned int rotation)
>  {
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> +
> + if (icl_is_hdr_plane(dev_priv, plane->id) &&

We could just have separate functions for hdr and sdr planes instead.

> + intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> + return 4096;
> +
>   return 5120;
>  }
>  
> @@ -1377,7 +1386,7 @@ static int intel_plane_max_width(struct intel_plane 
> *plane,
>unsigned int rotation)
>  {
>   if (plane->max_width)
> - return plane->max_width(fb, color_plane, rotation);
> + return plane->max_width(plane, fb, color_plane, rotation);
>   else
>   return INT_MAX;
>  }
> -- 
> 2.33.0

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915: Reject 5k on HDR planes for planar fb formats

[Srinivas, Vidya]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Tuesday, November 30, 2021 3:01 PM
> To: Srinivas, Vidya 
> Cc: intel-gfx@lists.freedesktop.org; Yashashvi, Shantam
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Reject 5k on HDR planes for planar
> fb formats
> 
> On Thu, Nov 18, 2021 at 11:55:16AM +0530, Vidya Srinivas wrote:
> > PLANE_CUS_CTL has a restriction of 4096 width even though PLANE_SIZE
> > and scaler size registers supports max 5120.
> > Reject 5k on HDR plane for planar formats like NV12 to let the user
> > space know about it.
> >
> > Without this patch, when 5k content is sent on HDR plane with NV12
> > content, FIFO underrun is seen and screen blanks out. Issue is seen on
> > both TGL and ADL platforms.
> >
> > Signed-off-by: Vidya Srinivas 
> > Signed-off-by: Yashashvi Shantam 
> > ---
> >  drivers/gpu/drm/i915/display/skl_scaler.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
> > b/drivers/gpu/drm/i915/display/skl_scaler.c
> > index 37eabeff8197..e2e52f5dca3b 100644
> > --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> > +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> > @@ -86,6 +86,7 @@ static u16 skl_scaler_calc_phase(int sub, int scale,
> > bool chroma_cosited)  #define ICL_MAX_DST_H 4096  #define
> > SKL_MIN_YUV_420_SRC_W 16  #define SKL_MIN_YUV_420_SRC_H 16
> > +#define MAX_CUSCTL_W 4096
> >
> >  static int
> >  skl_update_scaler(struct intel_crtc_state *crtc_state, bool
> > force_detach, @@ -221,6 +222,14 @@ int skl_update_scaler_plane(struct
> intel_crtc_state *crtc_state,
> > bool force_detach = !fb || !plane_state->uapi.visible;
> > bool need_scaler = false;
> >
> > +   /* PLANE_CUS_CTL size max 4096 */
> > +   if (icl_is_hdr_plane(dev_priv, intel_plane->id) &&
> > +   fb && intel_format_info_is_yuv_semiplanar(fb->format, fb-
> >modifier) &&
> > +   (drm_rect_width(_state->uapi.src) >> 16) >
> MAX_CUSCTL_W) {
> > +   DRM_ERROR("HDR chroma upsampler size exceeds
> limits\n");
> > +   return -EINVAL;
> > +   }
> 
> Wrong place. Should go into the plane->max_width() hook. There also seems
> to be a minimum height requirement for the CUS which we're not checking
> either.
> 
Thank you very much Ville for the patch review. Have moved the check to 
max_width.
Minimum horizontal should be 8 and vertical should be 4 - Haven't added in this 
yet.
Can you kindly have a check please 
https://patchwork.freedesktop.org/patch/464727/

Regards
Vidya

> > +
> > /* Pre-gen11 and SDR planes always need a scaler for planar
> formats. */
> > if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
> > fb && intel_format_info_is_yuv_semiplanar(fb->format,
> > fb->modifier))
> > --
> > 2.33.0
> 
> --
> Ville Syrjälä
> Intel

[Intel-gfx] [PATCH] drm/i915: Add PLANE_CUS_CTL restriction in max_width

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
Change-Id: If629c478ba044c8bde633de9f0fc638aa6c44233
---
 .../gpu/drm/i915/display/intel_display_types.h  |  3 ++-
 .../gpu/drm/i915/display/skl_universal_plane.c  | 17 +
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ea1e8a6e10b0..0455ea340329 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1358,7 +1358,8 @@ struct intel_plane {
int (*min_width)(const struct drm_framebuffer *fb,
 int color_plane,
 unsigned int rotation);
-   int (*max_width)(const struct drm_framebuffer *fb,
+   int (*max_width)(struct intel_plane *plane,
+const struct drm_framebuffer *fb,
 int color_plane,
 unsigned int rotation);
int (*max_height)(const struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 28890876bdeb..a49829c5a863 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -313,7 +313,8 @@ static int skl_plane_min_cdclk(const struct 
intel_crtc_state *crtc_state,
return DIV_ROUND_UP(pixel_rate * num, den);
 }
 
-static int skl_plane_max_width(const struct drm_framebuffer *fb,
+static int skl_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -352,7 +353,8 @@ static int skl_plane_max_width(const struct drm_framebuffer 
*fb,
}
 }
 
-static int glk_plane_max_width(const struct drm_framebuffer *fb,
+static int glk_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
@@ -420,10 +422,17 @@ static int icl_plane_min_width(const struct 
drm_framebuffer *fb,
}
 }
 
-static int icl_plane_max_width(const struct drm_framebuffer *fb,
+static int icl_plane_max_width(struct intel_plane *plane,
+   const struct drm_framebuffer *fb,
   int color_plane,
   unsigned int rotation)
 {
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+
+   if (icl_is_hdr_plane(dev_priv, plane->id) &&
+   intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+   return 4096;
+
return 5120;
 }
 
@@ -1377,7 +1386,7 @@ static int intel_plane_max_width(struct intel_plane 
*plane,
 unsigned int rotation)
 {
if (plane->max_width)
-   return plane->max_width(fb, color_plane, rotation);
+   return plane->max_width(plane, fb, color_plane, rotation);
else
return INT_MAX;
 }
-- 
2.33.0

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update error capture code to avoid using the current vma state

[Patchwork]

== Series Details ==

Series: drm/i915: Update error capture code to avoid using the current vma state
URL   : https://patchwork.freedesktop.org/series/97385/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10939_full -> Patchwork_21696_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 10)
--

  Missing(1): pig-kbl-iris 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][1], [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], [FAIL][21], [PASS][22], [PASS][23], 
[PASS][24]) ([i915#4337]) -> ([PASS][25], [PASS][26], [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])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl10/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl10/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl10/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10939/shard-skl1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl10/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl10/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl10/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl9/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl9/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl9/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl8/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl8/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl8/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl7/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl7/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl6/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl6/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl6/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl5/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/shard-skl4/boot.html
   [44]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl-n: Enable ADL-N platform

[Patchwork]

== Series Details ==

Series: drm/i915/adl-n: Enable ADL-N platform
URL   : https://patchwork.freedesktop.org/series/97406/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10942_full -> Patchwork_21699_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()
URL   : https://patchwork.freedesktop.org/series/97421/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10944 -> Patchwork_21702


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 33)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [PASS][6] -> [DMESG-FAIL][7] ([i915#295])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10944/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21702/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  
 Possible fixes 

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [INCOMPLETE][10] ([i915#198]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10944/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21702/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

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


Build changes
-

  * Linux: CI_DRM_10944 -> Patchwork_21702

  CI-20190529: 20190529
  CI_DRM_10944: 3f02d234c7c506f93f23eaf7f28d9837e39a20bb @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21702: a6b1837f6c7f16375bc199b6f5177e63c1d27b46 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a6b1837f6c7f drm/i915/gem: Fix a NULL pointer dereference in 
igt_request_rewind()

== Logs ==

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

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

[Jani Nikula]

Hi Dave & Daniel -

drm-intel-next-2021-11-30:
drm/i915 feature pull for v5.17:

Features and functionality:
- Implement per-lane DP drive settings for ICL+ (Ville)
- Enable runtime pm autosuspend by default (Tilak Tangudu)
- ADL-P DSI support (Vandita)
- Add support for pipe C and D DMC firmware (Anusha)
- Implement (near)atomic gamma LUT updates via vblank workers (Ville)
- Split plane updates to noarm+arm phases (Ville)
- Remove the CCS FB stride restrictions on ADL-P (Imre)
- Add PSR selective fetch support for biplanar formats (Jouni)
- Add support for display audio codec keepalive (Kai)
- VRR platform support for display 11 (Manasi)

Refactoring and cleanups:
- FBC refactoring and cleanups preparing for multiple FBC instances (Ville)
- PCH modeset refactoring, move to its own file (Ville)
- Refactor and simplify handling of modifiers (Imre)
- PXP cleanups (Ville)
- Display header and include refactoring (Jani)
- Some register macro cleanups (Ville)
- Refactor DP HDMI DFP limit code (Ville)

Fixes:
- Disable DSB usage for now due to incorrect gamma LUT updates (Ville)
- Check async flip state of every crtc and plane only once (José)
- Fix DPT FB suspend/resume (Imre)
- Fix black screen on reboot due to disabled DP++ TMDS output buffers (Ville)
- Don't request GMBUS to generate irqs when called while irqs are off (Ville)
- Fix type1 DVI DP dual mode adapter heuristics for modern platforms (Ville)
- Fix fix integer overflow in 128b/132b data rate calculation (Jani)
- Fix bigjoiner state readout (Ville)
- Build fix for non-x86 (Siva)
- PSR fixes (José, Jouni, Ville)
- Disable ADL-P underrun recovery (José)
- Fix DP link parameter usage before valid DPCD (Imre)
- VRR vblank and frame counter fixes (Ville)
- Fix fastsets on TypeC ports following a non-blocking modeset (Imre)
- Compiler warning fixes (Nathan Chancellor)
- Fix DSI HS mode commands (William Tseng)
- Error return fixes (Dan Carpenter)
- Update memory bandwidth calculations (Radhakrishna)
- Implement WM0 cursor WA for DG2 (Stan)
- Fix DSI Double pixelclock on read-back for dual-link panels (Hans de Goede)
- HDMI 2.1 PCON FRL configuration fixes (Ankit)

Merges:
- DP link training delay helpers, via topic branch (Jani)
- Backmerge drm-next (Jani)

BR,
Jani.

The following changes since commit 136057256686de39cc3a07c2e39ef6bc43003ff6:

  Linux 5.16-rc2 (2021-11-21 13:47:39 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-11-30

for you to fetch changes up to 74ba89c08e309bfeb2b2f401bf588ab54a1542fe:

  drm/i915: Fix DPT suspend/resume on !HAS_DISPLAY platforms (2021-11-29 
22:21:29 +0200)


drm/i915 feature pull for v5.17:

Features and functionality:
- Implement per-lane DP drive settings for ICL+ (Ville)
- Enable runtime pm autosuspend by default (Tilak Tangudu)
- ADL-P DSI support (Vandita)
- Add support for pipe C and D DMC firmware (Anusha)
- Implement (near)atomic gamma LUT updates via vblank workers (Ville)
- Split plane updates to noarm+arm phases (Ville)
- Remove the CCS FB stride restrictions on ADL-P (Imre)
- Add PSR selective fetch support for biplanar formats (Jouni)
- Add support for display audio codec keepalive (Kai)
- VRR platform support for display 11 (Manasi)

Refactoring and cleanups:
- FBC refactoring and cleanups preparing for multiple FBC instances (Ville)
- PCH modeset refactoring, move to its own file (Ville)
- Refactor and simplify handling of modifiers (Imre)
- PXP cleanups (Ville)
- Display header and include refactoring (Jani)
- Some register macro cleanups (Ville)
- Refactor DP HDMI DFP limit code (Ville)

Fixes:
- Disable DSB usage for now due to incorrect gamma LUT updates (Ville)
- Check async flip state of every crtc and plane only once (José)
- Fix DPT FB suspend/resume (Imre)
- Fix black screen on reboot due to disabled DP++ TMDS output buffers (Ville)
- Don't request GMBUS to generate irqs when called while irqs are off (Ville)
- Fix type1 DVI DP dual mode adapter heuristics for modern platforms (Ville)
- Fix fix integer overflow in 128b/132b data rate calculation (Jani)
- Fix bigjoiner state readout (Ville)
- Build fix for non-x86 (Siva)
- PSR fixes (José, Jouni, Ville)
- Disable ADL-P underrun recovery (José)
- Fix DP link parameter usage before valid DPCD (Imre)
- VRR vblank and frame counter fixes (Ville)
- Fix fastsets on TypeC ports following a non-blocking modeset (Imre)
- Compiler warning fixes (Nathan Chancellor)
- Fix DSI HS mode commands (William Tseng)
- Error return fixes (Dan Carpenter)
- Update memory bandwidth calculations (Radhakrishna)
- Implement WM0 cursor WA for DG2 (Stan)
- Fix DSI Double pixelclock on read-back for dual-link panels (Hans de Goede)
- HDMI 2.1 PCON FRL configuration fixes (Ankit)

Merges:
- DP link training delay helpers, via topic branch (Jani)
- Backmerge drm-next (Jani)

Re: [Intel-gfx] [PATCH] drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()

[Tvrtko Ursulin]

On 30/11/2021 14:15, Zhou Qingyang wrote:

In igt_request_rewind(), mock_context(i915, "A") is assigned to ctx[0]
and used in i915_gem_context_get_engine(). There is a dereference
of ctx[0] in i915_gem_context_get_engine(), which could lead to a NULL
pointer dereference on failure of mock_context(i915, "A") .

So as mock_context(i915, "B").

Although this bug is not serious for it belongs to testing code, it is
better to be fixed to avoid unexpected failure in testing.

Fix this bugs by adding checks about ctx[0] and ctx[1].

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_DRM_I915_SELFTEST=y show no new warnings,
and our static analyzer no longer warns about this code.

Fixes: ca883c304f54 ("drm/i915/selftests: Pass intel_context to mock_request")


I think it is this one instead:

591c0fb85d1c ("drm/i915: Exercise request cancellation using a mock selftest")

Fix looks correct so:

Reviewed-by: Tvrtko Ursulin 

Thanks for the patch!

Regards,

Tvrtko

P.S.
Although Fixes: is probably a bit over the top since it is selftests only so 
I'll probably drop it while applying.


Signed-off-by: Zhou Qingyang 
---
  drivers/gpu/drm/i915/selftests/i915_request.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
b/drivers/gpu/drm/i915/selftests/i915_request.c
index d67710d10615..d6fc7b892793 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -209,6 +209,10 @@ static int igt_request_rewind(void *arg)
int err = -EINVAL;
  
  	ctx[0] = mock_context(i915, "A");

+   if (!ctx[0]) {
+   err = -ENOMEM;
+   goto err_ctx_0;
+   }
  
  	ce = i915_gem_context_get_engine(ctx[0], RCS0);

GEM_BUG_ON(IS_ERR(ce));
@@ -223,6 +227,10 @@ static int igt_request_rewind(void *arg)
i915_request_add(request);
  
  	ctx[1] = mock_context(i915, "B");

+   if (!ctx[1]) {
+   err = -ENOMEM;
+   goto err_ctx_1;
+   }
  
  	ce = i915_gem_context_get_engine(ctx[1], RCS0);

GEM_BUG_ON(IS_ERR(ce));
@@ -261,9 +269,11 @@ static int igt_request_rewind(void *arg)
i915_request_put(vip);
  err_context_1:
mock_context_close(ctx[1]);
+err_ctx_1:
i915_request_put(request);
  err_context_0:
mock_context_close(ctx[0]);
+err_ctx_0:
mock_device_flush(i915);
return err;
  }

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove short term pins from execbuf. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove short term pins from execbuf. (rev2)
URL   : https://patchwork.freedesktop.org/series/97371/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10942_full -> Patchwork_21698_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/shard-tglb6/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/shard-tglb3/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-tglb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/shard-tglb8/igt@gem_pp...@blt-vs-render-ctx0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/shard-tglb1/igt@gem_pp...@blt-vs-render-ctx0.html

  * igt@gem_softpin@softpin:
- shard-snb:  [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/shard-snb6/igt@gem_soft...@softpin.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/shard-snb2/igt@gem_soft...@softpin.html

  
 Suppressed 

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

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- {shard-rkl}:[PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/shard-rkl-1/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/shard-rkl-4/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_ppgtt@blt-vs-render-ctx0:
- {shard-rkl}:[PASS][9] -> [FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/shard-rkl-6/igt@gem_pp...@blt-vs-render-ctx0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/shard-rkl-6/igt@gem_pp...@blt-vs-render-ctx0.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

Re: [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On Tue, 2021-11-30 at 14:26 +0100, Christian König wrote:
> Am 30.11.21 um 13:56 schrieb Thomas Hellström:
> > 
> > On 11/30/21 13:42, Christian König wrote:
> > > Am 30.11.21 um 13:31 schrieb Thomas Hellström:
> > > > [SNIP]
> > > > > Other than that, I didn't investigate the nesting fails
> > > > > enough to 
> > > > > say I can accurately review this. :)
> > > > 
> > > > Basically the problem is that within enable_signaling() which
> > > > is 
> > > > called with the dma_fence lock held, we take the dma_fence lock
> > > > of 
> > > > another fence. If that other fence is a dma_fence_array, or a 
> > > > dma_fence_chain which in turn tries to lock a dma_fence_array
> > > > we hit 
> > > > a splat.
> > > 
> > > Yeah, I already thought that you constructed something like that.
> > > 
> > > You get the splat because what you do here is illegal, you can't
> > > mix 
> > > dma_fence_array and dma_fence_chain like this or you can end up
> > > in a 
> > > stack corruption.
> > 
> > Hmm. Ok, so what is the stack corruption, is it that the 
> > enable_signaling() will end up with endless recursion? If so,
> > wouldn't 
> > it be more usable we break that recursion chain and allow a more 
> > general use?
> 
> The problem is that this is not easily possible for dma_fence_array 
> containers. Just imagine that you drop the last reference to the 
> containing fences during dma_fence_array destruction if any of the 
> contained fences is another container you can easily run into
> recursion 
> and with that stack corruption.

Indeed, that would require some deeper surgery.

> 
> That's one of the major reasons I came up with the dma_fence_chain 
> container. This one you can chain any number of elements together 
> without running into any recursion.
> 
> > Also what are the mixing rules between these? Never use a 
> > dma-fence-chain as one of the array fences and never use a 
> > dma-fence-array as a dma-fence-chain fence?
> 
> You can't add any other container to a dma_fence_array, neither other
> dma_fence_array instances nor dma_fence_chain instances.
> 
> IIRC at least technically a dma_fence_chain can contain a 
> dma_fence_array if you absolutely need that, but Daniel, Jason and I 
> already had the same discussion a while back and came to the
> conclusion 
> to avoid that as well if possible.

Yes, this is actually the use-case. But what I can't easily guarantee
is that that dma_fence_chain isn't fed into a dma_fence_array somewhere
else. How do you typically avoid that?

Meanwhile I guess I need to take a different approach in the driver to
avoid this altogether.

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > 
> > > > But I'll update the commit message with a typical splat.
> > > > 
> > > > /Thomas
> > > 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest: Disable IRQ for timestamp calculation (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/selftest: Disable IRQ for timestamp calculation (rev3)
URL   : https://patchwork.freedesktop.org/series/96853/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10943 -> Patchwork_21701


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka:  [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/fi-kbl-soraka/igt@i915_pm_...@module-reload.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][4] -> [DMESG-WARN][5] ([i915#4269])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][6] ([i915#4432]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21701/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432


Build changes
-

  * Linux: CI_DRM_10943 -> Patchwork_21701

  CI-20190529: 20190529
  CI_DRM_10943: f506b61984977c7785a54b8860720bfb5334aa08 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21701: cf5015ce5beee9fb7f992684a23719f344335c60 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cf5015ce5bee drm/i915/selftest: Disable IRQ for timestamp calculation

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Attempt to avoid dma-fence-[chain|array] lockdep splats

[Patchwork]

== Series Details ==

Series: Attempt to avoid dma-fence-[chain|array] lockdep splats
URL   : https://patchwork.freedesktop.org/series/97410/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10943 -> Patchwork_21700


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#4433])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#4269])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-rkl-guc: [FAIL][5] ([i915#3928] / [i915#4312]) -> [FAIL][6] 
([i915#2426] / [i915#3928] / [i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10943/fi-rkl-guc/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21700/fi-rkl-guc/igt@run...@aborted.html

  
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4433]: https://gitlab.freedesktop.org/drm/intel/issues/4433


Build changes
-

  * Linux: CI_DRM_10943 -> Patchwork_21700

  CI-20190529: 20190529
  CI_DRM_10943: f506b61984977c7785a54b8860720bfb5334aa08 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21700: 185999e31f8f0463e2ad850652473fc03f82b17b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

185999e31f8f dma-fence: Avoid excessive recursive fence locking from 
enable_signaling() callbacks
641529efe715 dma-fence: Avoid establishing a locking order between fence classes

== Logs ==

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

Re: [Intel-gfx] [PATCH 04/20] drm/i915/fbc: Relocate intel_fbc_override_cfb_stride()

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, November 24, 2021 1:37 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/20] drm/i915/fbc: Relocate
> intel_fbc_override_cfb_stride()
> 
> From: Ville Syrjälä 
> 
> Move intel_fbc_override_cfb_stride() next to its cousins.
> Helps with later patches.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Mika Kahola 

> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 42 
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8bde3681b96e..6368dddf977c 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -142,6 +142,27 @@ static unsigned int intel_fbc_cfb_size(struct intel_fbc
> *fbc,
>   return lines * intel_fbc_cfb_stride(fbc, cache);  }
> 
> +static u16 intel_fbc_override_cfb_stride(struct intel_fbc *fbc,
> +  const struct intel_fbc_state_cache
> *cache) {
> + unsigned int stride = _intel_fbc_cfb_stride(cache);
> + unsigned int stride_aligned = intel_fbc_cfb_stride(fbc, cache);
> +
> + /*
> +  * Override stride in 64 byte units per 4 line segment.
> +  *
> +  * Gen9 hw miscalculates cfb stride for linear as
> +  * PLANE_STRIDE*512 instead of PLANE_STRIDE*64, so
> +  * we always need to use the override there.
> +  */
> + if (stride != stride_aligned ||
> + (DISPLAY_VER(fbc->i915) == 9 &&
> +  cache->fb.modifier == DRM_FORMAT_MOD_LINEAR))
> + return stride_aligned * 4 / 64;
> +
> + return 0;
> +}
> +
>  static u32 i8xx_fbc_ctl(struct intel_fbc *fbc)  {
>   const struct intel_fbc_reg_params *params = >params; @@ -
> 950,27 +971,6 @@ static bool intel_fbc_cfb_size_changed(struct intel_fbc *fbc)
>   fbc->compressed_fb.size * fbc->limit;  }
> 
> -static u16 intel_fbc_override_cfb_stride(struct intel_fbc *fbc,
> -  const struct intel_fbc_state_cache
> *cache)
> -{
> - unsigned int stride = _intel_fbc_cfb_stride(cache);
> - unsigned int stride_aligned = intel_fbc_cfb_stride(fbc, cache);
> -
> - /*
> -  * Override stride in 64 byte units per 4 line segment.
> -  *
> -  * Gen9 hw miscalculates cfb stride for linear as
> -  * PLANE_STRIDE*512 instead of PLANE_STRIDE*64, so
> -  * we always need to use the override there.
> -  */
> - if (stride != stride_aligned ||
> - (DISPLAY_VER(fbc->i915) == 9 &&
> -  cache->fb.modifier == DRM_FORMAT_MOD_LINEAR))
> - return stride_aligned * 4 / 64;
> -
> - return 0;
> -}
> -
>  static bool intel_fbc_can_enable(struct intel_fbc *fbc)  {
>   struct drm_i915_private *i915 = fbc->i915;
> --
> 2.32.0

Re: [Intel-gfx] [PATCH 03/20] drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, November 24, 2021 1:37 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/20] drm/i915/fbc: Nuke lots of crap from
> intel_fbc_state_cache
> 
> From: Ville Syrjälä 
> 
> There's no need to store all this stuff in intel_fbc_state_cache.
> Just check it all against the plane/crtc states and store only what we need.
> Probably more should get nuked still, but this is a start.
> 
> So what we'll do is:
> - each plane will check its own state and update its local
>   no_fbc_reason
> - the per-plane no_fbc_reason (if any) then gets propagated
>   to the cache->no_fbc_reason while doing the actual update
> - fbc->no_fbc_reason gets updated in the end with either
>   the value from the cache or directly from frontbuffer
>   tracking
> 
> It's still a bit messy, but should hopefuly get cleaned up more in the 
> future. At
> least now we can observe each plane's reasons for rejecting FBC now more
> consistently, and we don't have so mcuh redundant state store all over the
> place.
> 
> v2: store no_fbc_reason per-plane instead of per-pipe
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Mika Kahola 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |   5 +-
>  .../drm/i915/display/intel_display_types.h|   4 +-
>  drivers/gpu/drm/i915/display/intel_fbc.c  | 341 --
>  drivers/gpu/drm/i915/display/intel_fbc.h  |   3 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  20 +-
>  5 files changed, 166 insertions(+), 207 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b2d51cd79d6c..520a87c814a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8039,7 +8039,6 @@ static int intel_atomic_check(struct drm_device *dev,
>   if (ret)
>   goto fail;
> 
> - intel_fbc_choose_crtc(dev_priv, state);
>   ret = intel_compute_global_watermarks(state);
>   if (ret)
>   goto fail;
> @@ -8071,6 +8070,10 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   if (ret)
>   goto fail;
> 
> + ret = intel_fbc_atomic_check(state);
> + if (ret)
> + goto fail;
> +
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>   new_crtc_state, i) {
>   if (new_crtc_state->uapi.async_flip) { diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ea1e8a6e10b0..5df477dfb8cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -687,6 +687,8 @@ struct intel_plane_state {
> 
>   /* Clear Color Value */
>   u64 ccval;
> +
> + const char *no_fbc_reason;
>  };
> 
>  struct intel_initial_plane_config {
> @@ -1117,8 +1119,6 @@ struct intel_crtc_state {
> 
>   bool crc_enabled;
> 
> - bool enable_fbc;
> -
>   bool double_wide;
> 
>   int pbn;
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 083c0cab4847..8bde3681b96e 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -43,6 +43,7 @@
>  #include "i915_drv.h"
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
> +#include "intel_cdclk.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_fbc.h"
> @@ -58,20 +59,6 @@ struct intel_fbc_funcs {
>   void (*set_false_color)(struct intel_fbc *fbc, bool enable);  };
> 
> -/*
> - * For SKL+, the plane source size used by the hardware is based on the value
> we
> - * write to the PLANE_SIZE register. For BDW-, the hardware looks at the 
> value
> - * we wrote to PIPESRC.
> - */
> -static void intel_fbc_get_plane_source_size(const struct 
> intel_fbc_state_cache
> *cache,
> - int *width, int *height)
> -{
> - if (width)
> - *width = cache->plane.src_w;
> - if (height)
> - *height = cache->plane.src_h;
> -}
> -
>  /* plane stride in pixels */
>  static unsigned int intel_fbc_plane_stride(const struct intel_plane_state
> *plane_state)  { @@ -796,9 +783,13 @@ void intel_fbc_cleanup(struct
> drm_i915_private *i915)
>   mutex_unlock(>lock);
>  }
> 
> -static bool stride_is_valid(struct drm_i915_private *i915,
> - u64 modifier, unsigned int stride)
> +static bool stride_is_valid(const struct intel_plane_state
> +*plane_state)
>  {
> + struct drm_i915_private *i915 = to_i915(plane_state->uapi.plane->dev);
> + const struct drm_framebuffer *fb = plane_state->hw.fb;
> + unsigned int stride = intel_fbc_plane_stride(plane_state) *
> + fb->format->cpp[0];
> +
>   /* This should have been 

[Intel-gfx] [PATCH] drm/i915/selftest: Disable IRQ for timestamp calculation

[Anshuman Gupta]

gt_pm selftest calculates engine ticks cycles and wall time
cycles by delta of respective engine elapsed TIMESTAMP and ktime
for period of 1000us.
It compares the engine ticks cycles with wall time cycles.

Disable local cpu interrupt so that interrupt handler does not
switch out the thread during measure_clocks() and prevent
miscalculation of engine tick cycles.

v2:
- nuke preempt_{disable,enable}, as disable_local_irq()
  disable the preemption. (Chris)

Cc: Chris P Wilson 
Cc: Badal Nilawar 
Cc: Ashutosh Dixit 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index b9441217ca3d..55c5cdb99f45 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -43,7 +43,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
int i;
 
for (i = 0; i < 5; i++) {
-   preempt_disable();
+   local_irq_disable();
cycles[i] = -ENGINE_READ_FW(engine, RING_TIMESTAMP);
dt[i] = ktime_get();
 
@@ -51,7 +51,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
 
dt[i] = ktime_sub(ktime_get(), dt[i]);
cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
-   preempt_enable();
+   local_irq_enable();
}
 
/* Use the median of both cycle/dt; close enough */
-- 
2.26.2

Re: [Intel-gfx] [PATCH 02/20] drm/i915/fbc: Pass whole plane state to intel_fbc_min_limit()

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, November 24, 2021 1:37 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/20] drm/i915/fbc: Pass whole plane state to
> intel_fbc_min_limit()
> 
> From: Ville Syrjälä 
> 
> No reason to burden the caller with the details on how the minimum
> compression limit is calculated, so just pass in the whole plane state 
> instead of
> just the cpp value.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Mika Kahola 

> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index d0c34bc3af6c..083c0cab4847 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -679,8 +679,10 @@ static u64 intel_fbc_stolen_end(struct
> drm_i915_private *i915)
>   return min(end, intel_fbc_cfb_base_max(i915));  }
> 
> -static int intel_fbc_min_limit(int fb_cpp)
> +static int intel_fbc_min_limit(const struct intel_plane_state
> +*plane_state)
>  {
> + int fb_cpp = plane_state->hw.fb ? plane_state->hw.fb->format->cpp[0]
> :
> +0;
> +
>   return fb_cpp == 2 ? 2 : 1;
>  }
> 
> @@ -1466,8 +1468,7 @@ static void intel_fbc_enable(struct intel_atomic_state
> *state,
> 
>   cache = >state_cache;
> 
> - min_limit = intel_fbc_min_limit(plane_state->hw.fb ?
> - plane_state->hw.fb->format->cpp[0] :
> 0);
> + min_limit = intel_fbc_min_limit(plane_state);
> 
>   mutex_lock(>lock);
> 
> --
> 2.32.0

Re: [Intel-gfx] [PATCH 01/20] drm/i915/fbc: Eliminate racy intel_fbc_is_active() usage

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Wednesday, November 24, 2021 1:37 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 01/20] drm/i915/fbc: Eliminate racy
> intel_fbc_is_active() usage
> 
> From: Ville Syrjälä 
> 
> The ilk fbc watermark computation uses intel_fbc_is_active() which is racy 
> since
> we don't know whether FBC will be enabled or not at some point. So let's just
> assume it will be if both HAS_FBC() and the modparam agree.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Mika Kahola 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 01fa3fac1b57..18fbdd204a93 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3369,13 +3369,8 @@ static void ilk_wm_merge(struct drm_i915_private
> *dev_priv,
>   }
> 
>   /* ILK: LP2+ must be disabled when FBC WM is disabled but FBC enabled
> */
> - /*
> -  * FIXME this is racy. FBC might get enabled later.
> -  * What we should check here is whether FBC can be
> -  * enabled sometime later.
> -  */
> - if (DISPLAY_VER(dev_priv) == 5 && !merged->fbc_wm_enabled &&
> - intel_fbc_is_active(_priv->fbc)) {
> + if (DISPLAY_VER(dev_priv) == 5 && HAS_FBC(dev_priv) &&
> + dev_priv->params.enable_fbc && !merged->fbc_wm_enabled) {
>   for (level = 2; level <= max_level; level++) {
>   struct intel_wm_level *wm = >wm[level];
> 
> --
> 2.32.0

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Attempt to avoid dma-fence-[chain|array] lockdep splats

[Patchwork]

== Series Details ==

Series: Attempt to avoid dma-fence-[chain|array] lockdep splats
URL   : https://patchwork.freedesktop.org/series/97410/
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 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On 11/30/21 13:42, Christian König wrote:

Am 30.11.21 um 13:31 schrieb Thomas Hellström:

[SNIP]
Other than that, I didn't investigate the nesting fails enough to 
say I can accurately review this. :)


Basically the problem is that within enable_signaling() which is 
called with the dma_fence lock held, we take the dma_fence lock of 
another fence. If that other fence is a dma_fence_array, or a 
dma_fence_chain which in turn tries to lock a dma_fence_array we hit 
a splat.


Yeah, I already thought that you constructed something like that.

You get the splat because what you do here is illegal, you can't mix 
dma_fence_array and dma_fence_chain like this or you can end up in a 
stack corruption.


Hmm. Ok, so what is the stack corruption, is it that the 
enable_signaling() will end up with endless recursion? If so, wouldn't 
it be more usable we break that recursion chain and allow a more general 
use?


Also what are the mixing rules between these? Never use a 
dma-fence-chain as one of the array fences and never use a 
dma-fence-array as a dma-fence-chain fence?


/Thomas






Regards,
Christian.



But I'll update the commit message with a typical splat.

/Thomas

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl-n: Enable ADL-N platform

[Patchwork]

== Series Details ==

Series: drm/i915/adl-n: Enable ADL-N platform
URL   : https://patchwork.freedesktop.org/series/97406/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10942 -> Patchwork_21699


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 33)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21699/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][4] -> [DMESG-WARN][5] ([i915#4269])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21699/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@coherency:
- fi-snb-2520m:   [DMESG-FAIL][7] ([i915#4610]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/fi-snb-2520m/igt@i915_selftest@l...@coherency.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21699/fi-snb-2520m/igt@i915_selftest@l...@coherency.html

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

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4610]: https://gitlab.freedesktop.org/drm/intel/issues/4610
  [i915#750]: https://gitlab.freedesktop.org/drm/intel/issues/750


Build changes
-

  * Linux: CI_DRM_10942 -> Patchwork_21699

  CI-20190529: 20190529
  CI_DRM_10942: eb48595dbe341b866d6175a0d11099b284e7bd43 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6295: 2d7f671b872ed856a97957051098974be2380019 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21699: 39db60e0b083b417f3788af90b9b228eecd39ef7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

39db60e0b083 drm/i915/adl-n: Enable ADL-N platform

== Logs ==

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

Re: [Intel-gfx] [PATCH] lib/stackdepot: always do filter_irq_stacks() in stack_depot_save()

[Vlastimil Babka]

On 11/30/21 10:57, Marco Elver wrote:
> The non-interrupt portion of interrupt stack traces before interrupt
> entry is usually arbitrary. Therefore, saving stack traces of interrupts
> (that include entries before interrupt entry) to stack depot leads to
> unbounded stackdepot growth.
> 
> As such, use of filter_irq_stacks() is a requirement to ensure
> stackdepot can efficiently deduplicate interrupt stacks.
> 
> Looking through all current users of stack_depot_save(), none (except
> KASAN) pass the stack trace through filter_irq_stacks() before passing
> it on to stack_depot_save().
> 
> Rather than adding filter_irq_stacks() to all current users of
> stack_depot_save(), it became clear that stack_depot_save() should
> simply do filter_irq_stacks().

Agree.

> Signed-off-by: Marco Elver 

Acked-by: Vlastimil Babka 

Thanks.

> ---
>  lib/stackdepot.c  | 13 +
>  mm/kasan/common.c |  1 -
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index b437ae79aca1..519c7898c7f2 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -305,6 +305,9 @@ EXPORT_SYMBOL_GPL(stack_depot_fetch);
>   * (allocates using GFP flags of @alloc_flags). If @can_alloc is %false, 
> avoids
>   * any allocations and will fail if no space is left to store the stack 
> trace.
>   *
> + * If the stack trace in @entries is from an interrupt, only the portion up 
> to
> + * interrupt entry is saved.
> + *
>   * Context: Any context, but setting @can_alloc to %false is required if
>   *  alloc_pages() cannot be used from the current context. Currently
>   *  this is the case from contexts where neither %GFP_ATOMIC nor
> @@ -323,6 +326,16 @@ depot_stack_handle_t __stack_depot_save(unsigned long 
> *entries,
>   unsigned long flags;
>   u32 hash;
>  
> + /*
> +  * If this stack trace is from an interrupt, including anything before
> +  * interrupt entry usually leads to unbounded stackdepot growth.
> +  *
> +  * Because use of filter_irq_stacks() is a requirement to ensure
> +  * stackdepot can efficiently deduplicate interrupt stacks, always
> +  * filter_irq_stacks() to simplify all callers' use of stackdepot.
> +  */
> + nr_entries = filter_irq_stacks(entries, nr_entries);
> +
>   if (unlikely(nr_entries == 0) || stack_depot_disable)
>   goto fast_exit;
>  
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 8428da2aaf17..efaa836e5132 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -36,7 +36,6 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags, bool 
> can_alloc)
>   unsigned int nr_entries;
>  
>   nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 0);
> - nr_entries = filter_irq_stacks(entries, nr_entries);
>   return __stack_depot_save(entries, nr_entries, flags, can_alloc);
>  }
>  
> 

Re: [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On 11/30/21 13:19, Thomas Hellström wrote:

The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:

1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks of dma_fence_chain and
dma_fence_array.
2) Reverse signal order, which is used by __i915_active_fence_set().

Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
and 2) does not imply 1), and also 1) makes locking order between
different containers confusing.

Establish 2) and fix up the signal_on_any mode by calling
enable_signaling() on such fences unlocked at creation.

Cc: linaro-mm-...@lists.linaro.org
Cc: dri-de...@lists.freedesktop.org
Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
  drivers/dma-buf/dma-fence-array.c | 13 +++--
  drivers/dma-buf/dma-fence-chain.c |  3 +-
  drivers/dma-buf/dma-fence.c   | 79 +--
  include/linux/dma-fence.h |  3 ++
  4 files changed, 69 insertions(+), 29 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 3e07f961e2f3..0322b92909fe 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence 
*fence)
 * insufficient).
 */
dma_fence_get(>base);
-   if (dma_fence_add_callback(array->fences[i], [i].cb,
-  dma_fence_array_cb_func)) {
+   if (dma_fence_add_callback_nested(array->fences[i], [i].cb,
+ dma_fence_array_cb_func)) {
int error = array->fences[i]->error;
  
  			dma_fence_array_set_pending_error(array, error);

@@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
  {
struct dma_fence_array *array;
size_t size = sizeof(*array);
+   struct dma_fence *fence;
  
  	/* Allocate the callback structures behind the array. */

size += num_fences * sizeof(struct dma_fence_array_cb);
@@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
if (!array)
return NULL;
  
+	fence = >base;

spin_lock_init(>lock);
-   dma_fence_init(>base, _fence_array_ops, >lock,
+   dma_fence_init(fence, _fence_array_ops, >lock,
   context, seqno);
init_irq_work(>work, irq_dma_fence_array_work);
  
@@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,

atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
  
-	array->base.error = PENDING_ERROR;

+   fence->error = PENDING_ERROR;
+
+   if (signal_on_any)
+   dma_fence_enable_sw_signaling(fence);


Oh, this looks strange. Was meant to call the 
dma_fence_array_enable_signaling() without the lock held here.


/Thomas

Re: [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

On 11/30/21 13:25, Maarten Lankhorst wrote:

On 30-11-2021 13:19, Thomas Hellström wrote:

The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:

1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks of dma_fence_chain and
dma_fence_array.
2) Reverse signal order, which is used by __i915_active_fence_set().

Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
and 2) does not imply 1), and also 1) makes locking order between
different containers confusing.

Establish 2) and fix up the signal_on_any mode by calling
enable_signaling() on such fences unlocked at creation.

Cc: linaro-mm-...@lists.linaro.org
Cc: dri-de...@lists.freedesktop.org
Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
  drivers/dma-buf/dma-fence-array.c | 13 +++--
  drivers/dma-buf/dma-fence-chain.c |  3 +-
  drivers/dma-buf/dma-fence.c   | 79 +--
  include/linux/dma-fence.h |  3 ++
  4 files changed, 69 insertions(+), 29 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 3e07f961e2f3..0322b92909fe 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence 
*fence)
 * insufficient).
 */
dma_fence_get(>base);
-   if (dma_fence_add_callback(array->fences[i], [i].cb,
-  dma_fence_array_cb_func)) {
+   if (dma_fence_add_callback_nested(array->fences[i], [i].cb,
+ dma_fence_array_cb_func)) {
int error = array->fences[i]->error;
  
  			dma_fence_array_set_pending_error(array, error);

@@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
  {
struct dma_fence_array *array;
size_t size = sizeof(*array);
+   struct dma_fence *fence;
  
  	/* Allocate the callback structures behind the array. */

size += num_fences * sizeof(struct dma_fence_array_cb);
@@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
if (!array)
return NULL;
  
+	fence = >base;

spin_lock_init(>lock);
-   dma_fence_init(>base, _fence_array_ops, >lock,
+   dma_fence_init(fence, _fence_array_ops, >lock,
   context, seqno);
init_irq_work(>work, irq_dma_fence_array_work);
  
@@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,

atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
  
-	array->base.error = PENDING_ERROR;

+   fence->error = PENDING_ERROR;
+
+   if (signal_on_any)
+   dma_fence_enable_sw_signaling(fence);
  
  	return array;

  }
diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 1b4cb3e5cec9..0518e53880f6 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -152,7 +152,8 @@ static bool dma_fence_chain_enable_signaling(struct 
dma_fence *fence)
struct dma_fence *f = chain ? chain->fence : fence;
  
  		dma_fence_get(f);

-   if (!dma_fence_add_callback(f, >cb, dma_fence_chain_cb)) {
+   if (!dma_fence_add_callback_nested(f, >cb,
+  dma_fence_chain_cb)) {
dma_fence_put(fence);
return true;
}
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..90a3d5121746 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -610,6 +610,37 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
  }
  EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
  
+static int __dma_fence_add_callback(struct dma_fence *fence,

+   struct dma_fence_cb *cb,
+   dma_fence_func_t func,
+   int nest_level)
+{
+   unsigned long flags;
+   int ret = 0;
+
+   if (WARN_ON(!fence || !func))
+   return -EINVAL;
+
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   INIT_LIST_HEAD(>node);
+   return -ENOENT;
+   }
+
+   spin_lock_irqsave_nested(fence->lock, flags, 0);

Forgot to hook up nest_level here?


Ah Yes :)



+
+   if (__dma_fence_enable_signaling(fence)) {
+   cb->func = func;
+   list_add_tail(>node, >cb_list);
+   } else {
+   INIT_LIST_HEAD(>node);
+   ret = -ENOENT;
+   }
+
+   spin_unlock_irqrestore(fence->lock, flags);
+
+   return ret;
+}
+
  /**
   * dma_fence_add_callback - add a callback to be called when the fence
   * is 

Re: [Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Maarten Lankhorst]

On 30-11-2021 13:19, Thomas Hellström wrote:
> The locking order for taking two fence locks is implicitly defined in
> at least two ways in the code:
>
> 1) Fence containers first and other fences next, which is defined by
> the enable_signaling() callbacks of dma_fence_chain and
> dma_fence_array.
> 2) Reverse signal order, which is used by __i915_active_fence_set().
>
> Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
> and 2) does not imply 1), and also 1) makes locking order between
> different containers confusing.
>
> Establish 2) and fix up the signal_on_any mode by calling
> enable_signaling() on such fences unlocked at creation.
>
> Cc: linaro-mm-...@lists.linaro.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Christian König 
> Signed-off-by: Thomas Hellström 
> ---
>  drivers/dma-buf/dma-fence-array.c | 13 +++--
>  drivers/dma-buf/dma-fence-chain.c |  3 +-
>  drivers/dma-buf/dma-fence.c   | 79 +--
>  include/linux/dma-fence.h |  3 ++
>  4 files changed, 69 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c 
> b/drivers/dma-buf/dma-fence-array.c
> index 3e07f961e2f3..0322b92909fe 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct 
> dma_fence *fence)
>* insufficient).
>*/
>   dma_fence_get(>base);
> - if (dma_fence_add_callback(array->fences[i], [i].cb,
> -dma_fence_array_cb_func)) {
> + if (dma_fence_add_callback_nested(array->fences[i], [i].cb,
> +   dma_fence_array_cb_func)) {
>   int error = array->fences[i]->error;
>  
>   dma_fence_array_set_pending_error(array, error);
> @@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int 
> num_fences,
>  {
>   struct dma_fence_array *array;
>   size_t size = sizeof(*array);
> + struct dma_fence *fence;
>  
>   /* Allocate the callback structures behind the array. */
>   size += num_fences * sizeof(struct dma_fence_array_cb);
> @@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int 
> num_fences,
>   if (!array)
>   return NULL;
>  
> + fence = >base;
>   spin_lock_init(>lock);
> - dma_fence_init(>base, _fence_array_ops, >lock,
> + dma_fence_init(fence, _fence_array_ops, >lock,
>  context, seqno);
>   init_irq_work(>work, irq_dma_fence_array_work);
>  
> @@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int 
> num_fences,
>   atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
>   array->fences = fences;
>  
> - array->base.error = PENDING_ERROR;
> + fence->error = PENDING_ERROR;
> +
> + if (signal_on_any)
> + dma_fence_enable_sw_signaling(fence);
>  
>   return array;
>  }
> diff --git a/drivers/dma-buf/dma-fence-chain.c 
> b/drivers/dma-buf/dma-fence-chain.c
> index 1b4cb3e5cec9..0518e53880f6 100644
> --- a/drivers/dma-buf/dma-fence-chain.c
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -152,7 +152,8 @@ static bool dma_fence_chain_enable_signaling(struct 
> dma_fence *fence)
>   struct dma_fence *f = chain ? chain->fence : fence;
>  
>   dma_fence_get(f);
> - if (!dma_fence_add_callback(f, >cb, dma_fence_chain_cb)) {
> + if (!dma_fence_add_callback_nested(f, >cb,
> +dma_fence_chain_cb)) {
>   dma_fence_put(fence);
>   return true;
>   }
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 066400ed8841..90a3d5121746 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -610,6 +610,37 @@ void dma_fence_enable_sw_signaling(struct dma_fence 
> *fence)
>  }
>  EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
>  
> +static int __dma_fence_add_callback(struct dma_fence *fence,
> + struct dma_fence_cb *cb,
> + dma_fence_func_t func,
> + int nest_level)
> +{
> + unsigned long flags;
> + int ret = 0;
> +
> + if (WARN_ON(!fence || !func))
> + return -EINVAL;
> +
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
> + INIT_LIST_HEAD(>node);
> + return -ENOENT;
> + }
> +
> + spin_lock_irqsave_nested(fence->lock, flags, 0);
Forgot to hook up nest_level here?
> +
> + if (__dma_fence_enable_signaling(fence)) {
> + cb->func = func;
> + list_add_tail(>node, >cb_list);
> + } else {
> + INIT_LIST_HEAD(>node);
> + ret = -ENOENT;
> + }
> +
> + spin_unlock_irqrestore(fence->lock, flags);
> +
> +   

[Intel-gfx] [RFC PATCH 2/2] dma-fence: Avoid excessive recursive fence locking from enable_signaling() callbacks

[Thomas Hellström]

Some dma-fence containers lock other fence's locks from their
enable_signaling() callbacks. We allow one level of nesting from
the dma_fence_add_callback_nested() function, but we would also like to
allow for example dma_fence_chain to point to a dma_fence_array and
vice versa, even though that would create additional levels of nesting.

To do that we need to break longer recursive chains of fence locking and
we can do that either by deferring dma_fence_add_callback_nested() to
a worker for affected fences or to call enable_signaling() early on
affected fences. Opt for the latter, and define a
DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT for fence classes that takes fence
locks recursively from within their enable_signaling() callback.

Note that a user could of course also call enable_signaling() manually
on these fences before publishing them, but this solution attempts to
do that only when necessary.

Cc: Christian König 
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Thomas Hellström 
---
 drivers/dma-buf/dma-fence-array.c | 12 +++-
 drivers/dma-buf/dma-fence-chain.c |  9 +
 include/linux/dma-fence.h |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 0322b92909fe..63ae9909bcfa 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -178,8 +178,18 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
 
fence->error = PENDING_ERROR;
 
-   if (signal_on_any)
+   set_bit(DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT, >flags);
+
+   if (signal_on_any) {
dma_fence_enable_sw_signaling(fence);
+   } else {
+   int i;
+
+   for (i = 0; i < num_fences; i++, fences++)
+   if (test_bit(DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT,
+&(*fences)->flags))
+   dma_fence_enable_sw_signaling(*fences);
+   }
 
return array;
 }
diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 0518e53880f6..b4012dbef0c9 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -255,5 +255,14 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
 
dma_fence_init(>base, _fence_chain_ops,
   >lock, context, seqno);
+
+   set_bit(DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT, >base.flags);
+   if (test_bit(DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT, >flags)) {
+   /*
+* Disable further calls into @fence's enable_signaling
+* To prohibit further recursive locking
+*/
+   dma_fence_enable_sw_signaling(fence);
+   }
 }
 EXPORT_SYMBOL(dma_fence_chain_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 405cd83936f6..48bf5e14636e 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -99,6 +99,7 @@ enum dma_fence_flag_bits {
DMA_FENCE_FLAG_SIGNALED_BIT,
DMA_FENCE_FLAG_TIMESTAMP_BIT,
DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+   DMA_FENCE_FLAG_LOCK_RECURSIVE_BIT,
DMA_FENCE_FLAG_USER_BITS, /* must always be last member */
 };
 
-- 
2.31.1

[Intel-gfx] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

[Thomas Hellström]

The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:

1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks of dma_fence_chain and
dma_fence_array.
2) Reverse signal order, which is used by __i915_active_fence_set().

Now 1) implies 2), except for the signal_on_any mode of dma_fence_array
and 2) does not imply 1), and also 1) makes locking order between
different containers confusing.

Establish 2) and fix up the signal_on_any mode by calling
enable_signaling() on such fences unlocked at creation.

Cc: linaro-mm-...@lists.linaro.org
Cc: dri-de...@lists.freedesktop.org
Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
 drivers/dma-buf/dma-fence-array.c | 13 +++--
 drivers/dma-buf/dma-fence-chain.c |  3 +-
 drivers/dma-buf/dma-fence.c   | 79 +--
 include/linux/dma-fence.h |  3 ++
 4 files changed, 69 insertions(+), 29 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 3e07f961e2f3..0322b92909fe 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -84,8 +84,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence 
*fence)
 * insufficient).
 */
dma_fence_get(>base);
-   if (dma_fence_add_callback(array->fences[i], [i].cb,
-  dma_fence_array_cb_func)) {
+   if (dma_fence_add_callback_nested(array->fences[i], [i].cb,
+ dma_fence_array_cb_func)) {
int error = array->fences[i]->error;
 
dma_fence_array_set_pending_error(array, error);
@@ -158,6 +158,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
 {
struct dma_fence_array *array;
size_t size = sizeof(*array);
+   struct dma_fence *fence;
 
/* Allocate the callback structures behind the array. */
size += num_fences * sizeof(struct dma_fence_array_cb);
@@ -165,8 +166,9 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
if (!array)
return NULL;
 
+   fence = >base;
spin_lock_init(>lock);
-   dma_fence_init(>base, _fence_array_ops, >lock,
+   dma_fence_init(fence, _fence_array_ops, >lock,
   context, seqno);
init_irq_work(>work, irq_dma_fence_array_work);
 
@@ -174,7 +176,10 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;
 
-   array->base.error = PENDING_ERROR;
+   fence->error = PENDING_ERROR;
+
+   if (signal_on_any)
+   dma_fence_enable_sw_signaling(fence);
 
return array;
 }
diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 1b4cb3e5cec9..0518e53880f6 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -152,7 +152,8 @@ static bool dma_fence_chain_enable_signaling(struct 
dma_fence *fence)
struct dma_fence *f = chain ? chain->fence : fence;
 
dma_fence_get(f);
-   if (!dma_fence_add_callback(f, >cb, dma_fence_chain_cb)) {
+   if (!dma_fence_add_callback_nested(f, >cb,
+  dma_fence_chain_cb)) {
dma_fence_put(fence);
return true;
}
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..90a3d5121746 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -610,6 +610,37 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence)
 }
 EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
 
+static int __dma_fence_add_callback(struct dma_fence *fence,
+   struct dma_fence_cb *cb,
+   dma_fence_func_t func,
+   int nest_level)
+{
+   unsigned long flags;
+   int ret = 0;
+
+   if (WARN_ON(!fence || !func))
+   return -EINVAL;
+
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   INIT_LIST_HEAD(>node);
+   return -ENOENT;
+   }
+
+   spin_lock_irqsave_nested(fence->lock, flags, 0);
+
+   if (__dma_fence_enable_signaling(fence)) {
+   cb->func = func;
+   list_add_tail(>node, >cb_list);
+   } else {
+   INIT_LIST_HEAD(>node);
+   ret = -ENOENT;
+   }
+
+   spin_unlock_irqrestore(fence->lock, flags);
+
+   return ret;
+}
+
 /**
  * dma_fence_add_callback - add a callback to be called when the fence
  * is signaled
@@ -635,33 +666,33 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
 int dma_fence_add_callback(struct 

[Intel-gfx] [RFC PATCH 0/2] Attempt to avoid dma-fence-[chain|array] lockdep splats

[Thomas Hellström]

Introducing more usage of dma-fence-chain and dma-fence-array in the
i915 driver we start to hit lockdep splats due to the recursive fence
locking in the dma-fence-chain and dma-fence-array containers.
This is a humble suggestion to try to establish a dma-fence locking order
(patch 1) and to avoid excessive recursive locking in these containers
(patch 2)

Thomas Hellström (2):
  dma-fence: Avoid establishing a locking order between fence classes
  dma-fence: Avoid excessive recursive fence locking from
enable_signaling() callbacks

 drivers/dma-buf/dma-fence-array.c | 23 +++--
 drivers/dma-buf/dma-fence-chain.c | 12 -
 drivers/dma-buf/dma-fence.c   | 79 +--
 include/linux/dma-fence.h |  4 ++
 4 files changed, 89 insertions(+), 29 deletions(-)

Cc: linaro-mm-...@lists.linaro.org
Cc: dri-de...@lists.freedesktop.org
Cc: Christian König 

-- 
2.31.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/adl-n: Enable ADL-N platform

[Patchwork]

== Series Details ==

Series: drm/i915/adl-n: Enable ADL-N platform
URL   : https://patchwork.freedesktop.org/series/97406/
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/adl-n: Enable ADL-N platform

[Patchwork]

== Series Details ==

Series: drm/i915/adl-n: Enable ADL-N platform
URL   : https://patchwork.freedesktop.org/series/97406/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
39db60e0b083 drm/i915/adl-n: Enable ADL-N platform
-:98: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#98: FILE: include/drm/i915_pciids.h:670:
+#define INTEL_ADLN_IDS(info) \
+   INTEL_VGA_DEVICE(0x46D0, info), \
+   INTEL_VGA_DEVICE(0x46D1, info), \
+   INTEL_VGA_DEVICE(0x46D2, info)

-:98: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#98: FILE: include/drm/i915_pciids.h:670:
+#define INTEL_ADLN_IDS(info) \
+   INTEL_VGA_DEVICE(0x46D0, info), \
+   INTEL_VGA_DEVICE(0x46D1, info), \
+   INTEL_VGA_DEVICE(0x46D2, info)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove short term pins from execbuf. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove short term pins from execbuf. (rev2)
URL   : https://patchwork.freedesktop.org/series/97371/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10942 -> Patchwork_21698


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 34)
--

  Additional (1): fi-icl-u2 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-2 
bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html

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

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

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

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

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

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

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

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

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

  
 Possible fixes 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [INCOMPLETE][15] ([i915#198] / [i915#4547]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@i915_selftest@live@coherency:
- fi-snb-2520m:   [DMESG-FAIL][17] ([i915#4610]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10942/fi-snb-2520m/igt@i915_selftest@l...@coherency.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21698/fi-snb-2520m/igt@i915_selftest@l...@coherency.html

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [INCOMPLETE][19] ([i915#4432]) -> [PASS][20]
   [19]: 

Re: [Intel-gfx] [RE]: [PATCH v3 10/10] vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev

[Liu, Yi L]

> From: Eric Farman 
> Sent: Tuesday, November 30, 2021 1:18 AM
> 
> On Wed, 2021-11-24 at 12:25 +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe 
> > > Sent: Fri, 1 Oct 2021 14:52:51 -0300
> > >
> > > The css_driver's main purpose is to create/destroy the mdev and
> > > relay the
> > > shutdown, irq, sch_event, and chp_event css_driver ops to the
> > > single
> > > created vfio_device, if it exists.
> > >
> > > Reframe the boundary where the css_driver domain switches to the
> > > vfio
> > > domain by using rcu to read and refcount the vfio_device out of the
> > > sch's
> > > drvdata. The mdev probe/remove will manage the drvdata of the
> > > parent.
> > >
> > > The vfio core code refcounting thus guarantees that when a
> > > css_driver
> > > callback is running the vfio_device is registered, simplifying the
> > > understanding of the whole lifecycle.
> > >
> > > Finally the vfio_ccw_private is allocated/freed during probe/remove
> > > of the
> > > mdev like any other vfio_device struct.
> >
> > Hi Eric,
> >
> > how about the status of this patch?
> 
> Hi YiLiu,
> 
> To be honest I never got this far in the series, as the middle of the
> series got into some more involved rework than I had the bandwidth to
> consider. Not sure I'll be able to do anything with it before the year
> end holiday, but I've noted your interest in getting this in line with
> the rest of vfio_device so I don't drop it too far down the list.

thanks. look forward to your further thoughts on it. e.g. the rework
things and gaps in this cleanup.

Regards,
Yi Liu

> Thanks,
> Eric
> 
> > I found it is a good clean up to make
> > vfio ccw behave same with other vfio_device users. Also, I'd like to
> > do a clean up to consolidate the vfio_device allocation which needs the
> > vfio ccw private allocation happen in the mdev probe. So it would be nice
> > to build the cleanup based on this patch.
> >
> > Regards,
> > Yi Liu
> >
> > > Signed-off-by: Jason Gunthorpe 
> > > ---
> > >  drivers/s390/cio/vfio_ccw_drv.c | 67 ++---
> > > 
> > >  drivers/s390/cio/vfio_ccw_ops.c | 40 +++--
> > >  drivers/s390/cio/vfio_ccw_private.h | 23 +-
> > >  3 files changed, 69 insertions(+), 61 deletions(-)
> > >
> > > diff --git a/drivers/s390/cio/vfio_ccw_drv.c
> > > b/drivers/s390/cio/vfio_ccw_drv.c
> > > index 18ad047811d111..c5582fc9c46c9e 100644
> > > --- a/drivers/s390/cio/vfio_ccw_drv.c
> > > +++ b/drivers/s390/cio/vfio_ccw_drv.c
> > > @@ -86,13 +86,19 @@ static void vfio_ccw_crw_todo(struct
> > > work_struct *work)
> > >   */
> > >  static void vfio_ccw_sch_irq(struct subchannel *sch)
> > >  {
> > > - struct vfio_ccw_private *private = dev_get_drvdata(>dev);
> > > + struct vfio_ccw_private *private = vfio_ccw_get_priv(sch);
> > > +
> > > + /* IRQ should not be delivered after the mdev is destroyed */
> > > + if (WARN_ON(!private))
> > > + return;
> > >
> > >   inc_irq_stat(IRQIO_CIO);
> > >   vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
> > > + vfio_device_put(>vdev);
> > >  }
> > >
> > > -static struct vfio_ccw_private *vfio_ccw_alloc_private(struct
> > > subchannel *sch)
> > > +struct vfio_ccw_private *vfio_ccw_alloc_private(struct mdev_device
> > > *mdev,
> > > + struct subchannel *sch)
> > >  {
> > >   struct vfio_ccw_private *private;
> > >
> > > @@ -100,6 +106,8 @@ static struct vfio_ccw_private
> > > *vfio_ccw_alloc_private(struct subchannel *sch)
> > >   if (!private)
> > >   return ERR_PTR(-ENOMEM);
> > >
> > > + vfio_init_group_dev(>vdev, >dev,
> > > + _ccw_dev_ops);
> > >   private->sch = sch;
> > >   mutex_init(>io_mutex);
> > >   private->state = VFIO_CCW_STATE_CLOSED;
> > > @@ -145,11 +153,12 @@ static struct vfio_ccw_private
> > > *vfio_ccw_alloc_private(struct subchannel *sch)
> > >   kfree(private->cp.guest_cp);
> > >  out_free_private:
> > >   mutex_destroy(>io_mutex);
> > > + vfio_uninit_group_dev(>vdev);
> > >   kfree(private);
> > >   return ERR_PTR(-ENOMEM);
> > >  }
> > >
> > > -static void vfio_ccw_free_private(struct vfio_ccw_private
> > > *private)
> > > +void vfio_ccw_free_private(struct vfio_ccw_private *private)
> > >  {
> > >   struct vfio_ccw_crw *crw, *temp;
> > >
> > > @@ -164,14 +173,14 @@ static void vfio_ccw_free_private(struct
> > > vfio_ccw_private *private)
> > >   kmem_cache_free(vfio_ccw_io_region, private->io_region);
> > >   kfree(private->cp.guest_cp);
> > >   mutex_destroy(>io_mutex);
> > > - kfree(private);
> > > + vfio_uninit_group_dev(>vdev);
> > > + kfree_rcu(private, rcu);
> > >  }
> > >
> > >  static int vfio_ccw_sch_probe(struct subchannel *sch)
> > >  {
> > >   struct pmcw *pmcw = >schib.pmcw;
> > > - struct vfio_ccw_private *private;
> > > - int ret = -ENOMEM;
> > > + int ret;
> > >
> > >   if (pmcw->qf) {
> > >   dev_warn(>dev, "vfio: ccw: does not support QDIO:
> > > %s\n",
> > > @@ -179,15 +188,9 @@ static int vfio_ccw_sch_probe(struct
> > > 

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Remove short term pins from execbuf. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove short term pins from execbuf. (rev2)
URL   : https://patchwork.freedesktop.org/series/97371/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_gem_evict.c:110: warning: Function parameter or 
member 'ww' not described in 'i915_gem_evict_something'
./drivers/gpu/drm/i915/i915_gem_evict.c:281: warning: Function parameter or 
member 'ww' not described in 'i915_gem_evict_for_node'
./drivers/gpu/drm/i915/i915_gem_evict.c:393: warning: Function parameter or 
member 'ww' not described in 'i915_gem_evict_vm'
./drivers/gpu/drm/i915/i915_gem_gtt.c:100: warning: Function parameter or 
member 'ww' not described in 'i915_gem_gtt_reserve'
./drivers/gpu/drm/i915/i915_gem_gtt.c:192: warning: Function parameter or 
member 'ww' not described in 'i915_gem_gtt_insert'

Re: [Intel-gfx] [v2 3/3] drm/i915/rpl-s: Enable guc submission by default

[Jani Nikula]

On Tue, 30 Nov 2021, "Srivatsa, Anusha"  wrote:
>> -Original Message-
>> From: Jani Nikula 
>> Sent: Monday, November 22, 2021 3:28 PM
>> To: Srivatsa, Anusha ; intel-
>> g...@lists.freedesktop.org; Tvrtko Ursulin ;
>> Syrjala, Ville ; Vivi, Rodrigo
>> ; Joonas Lahtinen
>> 
>> Cc: Srivatsa, Anusha ; Dhanavanthri, Swathi
>> 
>> Subject: Re: [v2 3/3] drm/i915/rpl-s: Enable guc submission by default
>> 
>> On Fri, 19 Nov 2021, Anusha Srivatsa  wrote:
>> > Though, RPL-S is defined as subplatform of ADL-S, unlike ADL-S, it has
>> > GuC submission by default.
>> >
>> > v2: Remove extra parenthesis (Jani)
>> >
>> > Cc: Jani Nikula 
>> > Cc: Swathi Dhanavanthri 
>> > Signed-off-by: Anusha Srivatsa 
>> > ---
>> >  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> > index 2fef3b0bbe95..6aa843a1c25f 100644
>> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> > @@ -35,7 +35,7 @@ static void uc_expand_default_options(struct intel_uc
>> *uc)
>> >}
>> >
>> >/* Intermediate platforms are HuC authentication only */
>> > -  if (IS_ALDERLAKE_S(i915)) {
>> > +  if (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915)) {
>> 
>> I know I looked through the previous version, but I only realized this now.
>> The above just feels wrong. Like, if it's ADL-S it obviously can't be RPL-S, 
>> so
>> why the check.
>> 
>> We've had this type of thing before when IS_VALLEYVIEW() used to mean
>> VLV || CHV, and you'd have these really confusing checks:
>> 
>>  if (IS_VALLEYVIEW() && !IS_CHERRYVIEW())
>> 
>> We had to change that later on, and it was pretty annoying.
>> 
>> I'm really sorry I didn't spot this before, but I firmly believe adding a 
>> platform
>> check macro IS_RAPTORLAKE_S() as a subplatform check is the wrong thing
>> to do.
>> 
>> I think there are maybe three options:
>> 
>> 1) Add RPL-S as a full blown platform of its own. Convert
>>IS_ALDERLAKE_S() checks to IS_ALDERLAKE_S() || IS_RAPTORLAKE_S(). If
>>we think there's going to be more differences than just the guc
>>submission, this is the way to go.
>
> No. there is nothing else different between the 2 platforms.
>
>> 2) Add RPL-S as a subplatform of ADL-S like here, but then don't add a
>>platform macro IS_RAPTORLAKE_S(). Make the check something that
>>conveys the subplatform idea. See all the users of IS_SUBPLATFORM()
>>in i915_drv.h; for example IS_DG2_G10(). It's obvious it's a DG2 but
>>subtype G10. So maybe IS_ADLS_RPLS(), I don't know.
>
> I am trying to understand what this will serve. The above check will change 
> from 
> (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915) to (IS_ALDERLAKE_S(i915) && 
> !IS_ADLS_RPLS(i915). Agreed it will make the fact that RPLS is subplatform of 
> ADLS a lot clear. Is that what you are suggesting?

Yes, that's the whole point. It is confusing that a check that looks
like a platform check is in fact a sub-platform check.

My primary concern here is what it looks like to the reader, and let's
face it, we have so many platforms and developers that everyone isn't
going to automatically remember RPL-S is a sub-platform of ADL-S.


BR,
Jani.


>
>
> Anusha
>> 3) Add RPL-S PCI IDs as ADL-S with separate device info, but add a
>>feature flag for the guc submission default. Then RPL-S does not
>>exist as a platform or subplatform in code, rather as ADL-S, but the
>>difference is recorded via flags.
>> 
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>> 
>> >i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
>> >return;
>> >}
>> 
>> --
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove short term pins from execbuf. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove short term pins from execbuf. (rev2)
URL   : https://patchwork.freedesktop.org/series/97371/
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: Remove short term pins from execbuf. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove short term pins from execbuf. (rev2)
URL   : https://patchwork.freedesktop.org/series/97371/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d65c71e4c92c drm/i915: Remove unused bits of i915_vma/active api
fadb5f274a4c drm/i915: Change shrink ordering to use locking around unbinding.
-:28: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#28: FILE: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:40:
+static int drop_pages(struct drm_i915_gem_object *obj,
+  unsigned long shrink, bool trylock_vm)

total: 0 errors, 0 warnings, 1 checks, 52 lines checked
9fceaa51b585 drm/i915: Remove pages_mutex and 
intel_gtt->vma_ops.set/clear_pages members, v2.
7b675e7d0598 drm/i915: Take object lock in i915_ggtt_pin if ww is not set
ae6ba039701c drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2.
7a6579de7714 drm/i915: Ensure gem_contexts selftests work with unbind changes.
7f406571a8b2 drm/i915: Take trylock during eviction, v2.
-:92: CHECK:LINE_SPACING: Please don't use multiple blank lines
#92: FILE: drivers/gpu/drm/i915/i915_gem_evict.c:250:
 
+

total: 0 errors, 0 warnings, 1 checks, 109 lines checked
09d297c5af88 drm/i915: Pass trylock context to callers
-:399: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#399: FILE: drivers/gpu/drm/i915/i915_vma.c:1463:
if (mutex_lock_interruptible(>mutex) == 0) {
+

total: 0 errors, 0 warnings, 1 checks, 446 lines checked
bbd7fe8346e2 drm/i915: Ensure i915_vma tests do not get -ENOSPC with the 
locking changes.
2fa114f12b15 drm/i915: Make i915_gem_evict_vm work correctly for already locked 
objects
987f5b2664da drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new 
ENOSPC errors
1a3c1ee723a0 drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for 
i915_vma_unbind
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
We want to remove more members of i915_vma, which requires the locking to be

total: 0 errors, 1 warnings, 0 checks, 314 lines checked
8e3854a73b6d drm/i915: Require object lock when freeing pages during destruction
bec379c96571 drm/i915: Remove assert_object_held_shared
32e3349d5f17 drm/i915: Remove support for unlocked i915_vma unbind
af771ff7d089 drm/i915: Remove short-term pins from execbuf, v5.

Re: [Intel-gfx] [PATCH v2 00/16] drm/i915: Remove short term pins from execbuf.

[Maarten Lankhorst]

On 30-11-2021 09:54, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 29/11/2021 13:47, Maarten Lankhorst wrote:
>> New version of the series, with feedback from previous series added.
>
> If there was a cover letter sent for this work in the past could you please 
> keep attaching it? Or if there wasn't, could you please write one?
>
> I am worried about two things. First is that we need to have a high level 
> overview of the rules/design changes documented so third party people have 
> any hope of getting code right after this lands. (Where we are, where we are 
> going, how we will get there, how far did we get and when we will get to the 
> end.)
>
> Second is that when parts of the series land piecemeal (Which they have in 
> this right, right?), it gets very hard to write up a maintainer level 
> changelog.

The preparation part is to ensure we always hold vma->obj->resv when unbinding.

The first preparation series ensured vma->obj always existed. This was not the 
case for mock gtt and gen6 aliasing gtt. This allowed us to remove all the 
special handling for those uncommon cases, and actually enforce we can always 
take that lock. This part is merged.

Patch 2-11 in this series adds the vma->obj->resv to eviction and shrinker. 
Those are the only parts where we don't take the lock yet.

After that, we always hold the lock when required, and we can start requiring 
the obj-> resv lock when unbinding. This is completed in patch 15.

With that fixed, removing short term pins can be done, because for unbind we 
now always take obj->resv, so holding obj->resv during execbuf submission is 
sufficient, and all short term pinning can be removed.

We only pin temporarily when calling i915_gem_evict_vm in execbuf, which could 
also be handled in theory by just marking all objects as unpinned.

As a bonus, using TTM for delayed eviction on all objects becomes easy, just 
need to get rid of i915_active in i915_vma, as it keeps the object refcount 
alive.

Remainder is removing refcount to i915_vma, to make it a real

> But in any case, even on the mundane process level, we need to have cover 
> letters for any non trivial work was the conclusion since some time ago. 

Here you go! I hope it explains the reasoning.

~Maarten

[Intel-gfx] [PATCH] drm/i915/adl-n: Enable ADL-N platform

[Tejas Upadhyay]

Adding PCI device ids and enabling ADL-N platform.
ADL-N from i915 point of view is subplatform of ADL-P.

BSpec: 68397

Signed-off-by: Tejas Upadhyay 
---
 arch/x86/kernel/early-quirks.c   | 1 +
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.c | 7 +++
 drivers/gpu/drm/i915/intel_device_info.h | 3 +++
 include/drm/i915_pciids.h| 5 +
 6 files changed, 19 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 391a4e2b8604..b9800d9f11b0 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[] 
__initconst = {
INTEL_RKL_IDS(_early_ops),
INTEL_ADLS_IDS(_early_ops),
INTEL_ADLP_IDS(_early_ops),
+   INTEL_ADLN_IDS(_early_ops),
 };
 
 struct resource intel_graphics_stolen_res __ro_after_init = DEFINE_RES_MEM(0, 
0);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1bfadd9127fc..e8fd98064692 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1463,6 +1463,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
 #define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_S)
 #define IS_ALDERLAKE_P(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_P)
+#define IS_ALDERLAKE_N(dev_priv) \
+   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N)
 #define IS_XEHPSDV(dev_priv) IS_PLATFORM(dev_priv, INTEL_XEHPSDV)
 #define IS_DG2(dev_priv)   IS_PLATFORM(dev_priv, INTEL_DG2)
 #define IS_DG2_G10(dev_priv) \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f01cba4ec283..9b816eddbcaf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1130,6 +1130,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_RKL_IDS(_info),
INTEL_ADLS_IDS(_s_info),
INTEL_ADLP_IDS(_p_info),
+   INTEL_ADLN_IDS(_p_info),
INTEL_DG1_IDS(_info),
{0, 0, 0}
 };
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 6e6b317bc33c..5d04dea5bd01 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -182,6 +182,10 @@ static const u16 subplatform_portf_ids[] = {
INTEL_ICL_PORT_F_IDS(0),
 };
 
+static const u16 subplatform_n_ids[] = {
+   INTEL_ADLN_IDS(0),
+};
+
 static bool find_devid(u16 id, const u16 *p, unsigned int num)
 {
for (; num; num--, p++) {
@@ -218,6 +222,9 @@ void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
} else if (find_devid(devid, subplatform_portf_ids,
  ARRAY_SIZE(subplatform_portf_ids))) {
mask = BIT(INTEL_SUBPLATFORM_PORTF);
+   } else if (find_devid(devid, subplatform_n_ids,
+ ARRAY_SIZE(subplatform_n_ids))) {
+   mask = BIT(INTEL_SUBPLATFORM_N);
}
 
if (IS_TIGERLAKE(i915)) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 669f0d26c3c3..d4d2d230d04a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -110,6 +110,9 @@ enum intel_platform {
 #define INTEL_SUBPLATFORM_G10  0
 #define INTEL_SUBPLATFORM_G11  1
 
+/* ADL */
+#define INTEL_SUBPLATFORM_N0
+
 enum intel_ppgtt_type {
INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index c00ac54692d7..5de540db8269 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -666,4 +666,9 @@
INTEL_VGA_DEVICE(0x46C2, info), \
INTEL_VGA_DEVICE(0x46C3, info)
 
+/* ADL-N */
+#define INTEL_ADLN_IDS(info) \
+   INTEL_VGA_DEVICE(0x46D0, info), \
+   INTEL_VGA_DEVICE(0x46D1, info), \
+   INTEL_VGA_DEVICE(0x46D2, info)
 #endif /* _I915_PCIIDS_H */
-- 
2.31.1

Re: [Intel-gfx] [v2 3/3] drm/i915/rpl-s: Enable guc submission by default

[Srivatsa, Anusha]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, November 22, 2021 3:28 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org; Tvrtko Ursulin ;
> Syrjala, Ville ; Vivi, Rodrigo
> ; Joonas Lahtinen
> 
> Cc: Srivatsa, Anusha ; Dhanavanthri, Swathi
> 
> Subject: Re: [v2 3/3] drm/i915/rpl-s: Enable guc submission by default
> 
> On Fri, 19 Nov 2021, Anusha Srivatsa  wrote:
> > Though, RPL-S is defined as subplatform of ADL-S, unlike ADL-S, it has
> > GuC submission by default.
> >
> > v2: Remove extra parenthesis (Jani)
> >
> > Cc: Jani Nikula 
> > Cc: Swathi Dhanavanthri 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 2fef3b0bbe95..6aa843a1c25f 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -35,7 +35,7 @@ static void uc_expand_default_options(struct intel_uc
> *uc)
> > }
> >
> > /* Intermediate platforms are HuC authentication only */
> > -   if (IS_ALDERLAKE_S(i915)) {
> > +   if (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915)) {
> 
> I know I looked through the previous version, but I only realized this now.
> The above just feels wrong. Like, if it's ADL-S it obviously can't be RPL-S, 
> so
> why the check.
> 
> We've had this type of thing before when IS_VALLEYVIEW() used to mean
> VLV || CHV, and you'd have these really confusing checks:
> 
>   if (IS_VALLEYVIEW() && !IS_CHERRYVIEW())
> 
> We had to change that later on, and it was pretty annoying.
> 
> I'm really sorry I didn't spot this before, but I firmly believe adding a 
> platform
> check macro IS_RAPTORLAKE_S() as a subplatform check is the wrong thing
> to do.
> 
> I think there are maybe three options:
> 
> 1) Add RPL-S as a full blown platform of its own. Convert
>IS_ALDERLAKE_S() checks to IS_ALDERLAKE_S() || IS_RAPTORLAKE_S(). If
>we think there's going to be more differences than just the guc
>submission, this is the way to go.

No. there is nothing else different between the 2 platforms.

> 2) Add RPL-S as a subplatform of ADL-S like here, but then don't add a
>platform macro IS_RAPTORLAKE_S(). Make the check something that
>conveys the subplatform idea. See all the users of IS_SUBPLATFORM()
>in i915_drv.h; for example IS_DG2_G10(). It's obvious it's a DG2 but
>subtype G10. So maybe IS_ADLS_RPLS(), I don't know.

I am trying to understand what this will serve. The above check will change 
from 
(IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915) to (IS_ALDERLAKE_S(i915) && 
!IS_ADLS_RPLS(i915). Agreed it will make the fact that RPLS is subplatform of 
ADLS a lot clear. Is that what you are suggesting?


Anusha
> 3) Add RPL-S PCI IDs as ADL-S with separate device info, but add a
>feature flag for the guc submission default. Then RPL-S does not
>exist as a platform or subplatform in code, rather as ADL-S, but the
>difference is recorded via flags.
> 
> 
> BR,
> Jani.
> 
> 
> 
> 
> > i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> > return;
> > }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Perform 30ms delay after source OUI write

[Jani Nikula]

On Mon, 29 Nov 2021, Lyude Paul  wrote:
> While working on supporting the Intel HDR backlight interface, I noticed
> that there's a couple of laptops that will very rarely manage to boot up
> without detecting Intel HDR backlight support - even though it's supported
> on the system. One example of such a laptop is the Lenovo P17 1st
> generation.
>
> Following some investigation Ville Syrjälä did through the docs they have
> available to them, they discovered that there's actually supposed to be a
> 30ms wait after writing the source OUI before we begin setting up the rest
> of the backlight interface.
>
> This seems to be correct, as adding this 30ms delay seems to have
> completely fixed the probing issues I was previously seeing. So - let's
> start performing a 30ms wait after writing the OUI, which we do in a manner
> similar to how we keep track of PPS delays (e.g. record the timestamp of
> the OUI write, and then wait for however many ms are left since that
> timestamp right before we interact with the backlight) in order to avoid
> waiting any longer then we need to. As well, this also avoids us performing
> this delay on systems where we don't end up using the HDR backlight
> interface.
>
> V2:
> * Move panel delays into intel_pps
>
> Signed-off-by: Lyude Paul 
> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface 
> (only SDR for now)")
> Cc: Ville Syrjälä 
> Cc:  # v5.12+
> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h|  4 
>  drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
>  drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
>  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
>  4 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ea1e8a6e10b0..ad64f9caa7ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1485,6 +1485,7 @@ struct intel_pps {
>   bool want_panel_vdd;
>   unsigned long last_power_on;
>   unsigned long last_backlight_off;
> + unsigned long last_oui_write;
>   ktime_t panel_power_off_time;
>   intel_wakeref_t vdd_wakeref;
>  
> @@ -1653,6 +1654,9 @@ struct intel_dp {
>   struct intel_dp_pcon_frl frl;
>  
>   struct intel_psr psr;
> +
> + /* When we last wrote the OUI for eDP */
> + unsigned long last_oui_write;

Now you're adding last_oui_write to both intel_pps and intel_dp, forgot
to git add? ;)

I guess I'd add this to intel_dp only, because it's not strictly about
PPS. I just wanted the mechanism to be similar to that.

>  };
>  
>  enum lspcon_vendor {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a424bf69396..45318891ba07 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, 
> bool careful)
>  
>   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
> < 0)
>   drm_err(>drm, "Failed to write source OUI\n");
> +
> + intel_dp->pps.last_oui_write = jiffies;

Set to intel_dp->last_oui_write.

With those fixes,

Reviewed-by: Jani Nikula 


> +}
> +
> +void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + drm_dbg_kms(>drm, "Performing OUI wait\n");
> + wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
>  }
>  
>  /* If the device supports it, try to set the power state appropriately */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index ce229026dc91..b64145a3869a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp 
> *intel_dp,
>const struct intel_crtc_state *crtc_state);
>  void intel_dp_phy_test(struct intel_encoder *encoder);
>  
> +void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
> +
>  #endif /* __INTEL_DP_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 8b9c925c4c16..62c112daacf2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -36,6 +36,7 @@
>  
>  #include "intel_backlight.h"
>  #include "intel_display_types.h"
> +#include "intel_dp.h"
>  #include "intel_dp_aux_backlight.h"
>  
>  /* TODO:
> @@ -106,6 +107,8 @@ intel_dp_aux_supports_hdr_backlight(struct 
> intel_connector *connector)
>   int ret;
>   u8 tcon_cap[4];
>  
> + 

Re: [Intel-gfx] [v2 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake S

[Srivatsa, Anusha]

> -Original Message-
> From: Tvrtko Ursulin 
> Sent: Monday, November 22, 2021 3:49 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [v2 1/3] drm/i915/rpl-s: Add PCI IDS for Raptor Lake 
> S
> 
> 
> On 20/11/2021 00:29, Anusha Srivatsa wrote:
> > Raptor Lake S(RPL-S) is a version 12
> > Display, Media and Render. For all i915 purposes it is the same as
> > Alder Lake S (ADL-S).
> >
> > Introduce RPL-S as a subplatform
> > of ADL-S. This patch adds PCI ids for RPL-S.
> >
> > v2: Update PCI IDs.
> > - Add more description to commit message (Jani)
> >
> > BSpec: 53655
> > Cc: Matt Roper 
> > Cc: Swathi Dhanavanthri 
> > Cc: Jani Nikula 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >   arch/x86/kernel/early-quirks.c   | 1 +
> >   drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> >   drivers/gpu/drm/i915/i915_pci.c  | 1 +
> >   drivers/gpu/drm/i915/intel_device_info.c | 7 +++
> >   drivers/gpu/drm/i915/intel_device_info.h | 3 +++
> >   include/drm/i915_pciids.h| 9 +
> >   6 files changed, 23 insertions(+)
> >
> > diff --git a/arch/x86/kernel/early-quirks.c
> > b/arch/x86/kernel/early-quirks.c index 391a4e2b8604..fd2d3ab38ebb
> > 100644
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> > @@ -554,6 +554,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> > INTEL_RKL_IDS(_early_ops),
> > INTEL_ADLS_IDS(_early_ops),
> > INTEL_ADLP_IDS(_early_ops),
> > +   INTEL_RPLS_IDS(_early_ops),
> >   };
> >
> >   struct resource intel_graphics_stolen_res __ro_after_init =
> > DEFINE_RES_MEM(0, 0); diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 1bfadd9127fc..c53da07255c5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1469,6 +1469,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> > IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G10)
> >   #define IS_DG2_G11(dev_priv) \
> > IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> > +#define IS_RAPTORLAKE_S(dev_priv) \
> > +   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL)
> >   #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > (INTEL_DEVID(dev_priv) & 0xFF00) ==
> 0x0C00)
> >   #define IS_BDW_ULT(dev_priv) \
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index f01cba4ec283..061b2e076373
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -1131,6 +1131,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_ADLS_IDS(_s_info),
> > INTEL_ADLP_IDS(_p_info),
> > INTEL_DG1_IDS(_info),
> > +   INTEL_RPLS_IDS(_s_info),
> > {0, 0, 0}
> >   };
> >   MODULE_DEVICE_TABLE(pci, pciidlist); diff --git
> > a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 6e6b317bc33c..565b50c3f34f 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -182,6 +182,10 @@ static const u16 subplatform_portf_ids[] = {
> > INTEL_ICL_PORT_F_IDS(0),
> >   };
> >
> > +static const u16 subplatform_rpl_ids[] = {
> > +   INTEL_RPLS_IDS(0),
> > +};
> > +
> >   static bool find_devid(u16 id, const u16 *p, unsigned int num)
> >   {
> > for (; num; num--, p++) {
> > @@ -218,6 +222,9 @@ void intel_device_info_subplatform_init(struct
> drm_i915_private *i915)
> > } else if (find_devid(devid, subplatform_portf_ids,
> >   ARRAY_SIZE(subplatform_portf_ids))) {
> > mask = BIT(INTEL_SUBPLATFORM_PORTF);
> > +   } else if (find_devid(devid, subplatform_rpl_ids,
> > + ARRAY_SIZE(subplatform_rpl_ids))) {
> > +   mask = BIT(INTEL_SUBPLATFORM_RPL);
> > }
> >
> > if (IS_TIGERLAKE(i915)) {
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index 669f0d26c3c3..186e773fd0da 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -110,6 +110,9 @@ enum intel_platform {
> >   #define INTEL_SUBPLATFORM_G10 0
> >   #define INTEL_SUBPLATFORM_G11 1
> >
> > +/* RPL */
> > +#define INTEL_SUBPLATFORM_RPL  0
> 
> Comment is wrong as said before. Comment should say to which platform
> the subplatform bits apply. It cannot apply to itself since RPL platform does
> not exist.
That is correct. Good catch. I ll fix this.

Thanks Tvrtko.
Anusha
> 
> Regards,
> 
> Tvrtko
> 
> > +
> >   enum intel_ppgtt_type {
> > INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
> > INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING, diff --git
> > a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index
> > c00ac54692d7..baf3d1d3d566 100644
> > --- a/include/drm/i915_pciids.h
> > 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/xelpd: Enable Pipe Degamma

[Jani Nikula]

On Tue, 30 Nov 2021, Ville Syrjälä  wrote:
> On Mon, Nov 29, 2021 at 06:19:52PM +0200, Jani Nikula wrote:
>> On Fri, 26 Nov 2021, Uma Shankar  wrote:
>> > Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
>> > to incorparate the extended lut size for XE_LPD.
>> >
>> > v2: Added a helper for degamma lut size (Ville)
>> >
>> > Signed-off-by: Uma Shankar 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
>> >  1 file changed, 11 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
>> > b/drivers/gpu/drm/i915/display/intel_color.c
>> > index 42fe549ef6fe..de3ded1e327a 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_color.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
>> > @@ -808,6 +808,14 @@ static void bdw_load_luts(const struct 
>> > intel_crtc_state *crtc_state)
>> >}
>> >  }
>> >  
>> > +static int glk_degamma_lut_size(struct drm_i915_private *i915)
>> > +{
>> > +  if (DISPLAY_VER(i915) >= 13)
>> > +  return 131;
>> > +  else
>> > +  return 35;
>> > +}
>> > +
>> 
>> Why do we have both a function with hardcoded values and device info
>> members for this?
>
> The device info stuff just needs to get nuked. The size of the LUTs
> depends on the gamma mode which we already select dynamically (and
> if/when we get thre new uapi ironed out it'll become even more
> dynamic), so trying to represent it with a single number in device 
> info is futile.

Works for me, I just like to have the single point of truth instead of
split all over the place. Not against adding this now, but let's not
forget to follow up with the cleanup.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/xelpd: Enable Pipe Degamma

[Ville Syrjälä]

On Fri, Nov 26, 2021 at 01:57:49AM +0530, Uma Shankar wrote:
> Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
> to incorparate the extended lut size for XE_LPD.
> 
> v2: Added a helper for degamma lut size (Ville)
> 
> Signed-off-by: Uma Shankar 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 42fe549ef6fe..de3ded1e327a 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -808,6 +808,14 @@ static void bdw_load_luts(const struct intel_crtc_state 
> *crtc_state)
>   }
>  }
>  
> +static int glk_degamma_lut_size(struct drm_i915_private *i915)
> +{
> + if (DISPLAY_VER(i915) >= 13)
> + return 131;
> + else
> + return 35;
> +}
> +
>  static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -827,8 +835,8 @@ static void glk_load_degamma_lut(const struct 
> intel_crtc_state *crtc_state)
>  
>   for (i = 0; i < lut_size; i++) {
>   /*
> -  * First 33 entries represent range from 0 to 1.0
> -  * 34th and 35th entry will represent extended range
> +  * First lut_size entries represent range from 0 to 1.0
> +  * 3 additional lut entries will represent extended range
>* inputs 3.0 and 7.0 respectively, currently clamped
>* at 1.0. Since the precision is 16bit, the user
>* value can be directly filled to register.
> @@ -844,7 +852,7 @@ static void glk_load_degamma_lut(const struct 
> intel_crtc_state *crtc_state)
>   }
>  
>   /* Clamp values > 1.0. */
> - while (i++ < 35)
> + while (i++ < glk_degamma_lut_size(dev_priv))
>   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
>  
>   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/xelpd: Add Pipe Color Lut caps to platform config

[Ville Syrjälä]

On Fri, Nov 26, 2021 at 01:57:50AM +0530, Uma Shankar wrote:
> XE_LPD has 128 Lut entries for Degamma, with additional 3 entries for
> extended range. It has 511 entries for gamma with additional 2 entries
> for extended range.
> 
> v2: Updated lut size for 10bit gamma, added lut_tests (Ville)
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f01cba4ec283..22eae330f075 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -938,7 +938,11 @@ static const struct intel_device_info adl_s_info = {
>  
>  #define XE_LPD_FEATURES \
>   .abox_mask = GENMASK(1, 0), 
> \
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 0 },
> \
> + .color = { .degamma_lut_size = 128, .gamma_lut_size = 1024, 
> \
> +.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING |  
> \
> + DRM_COLOR_LUT_EQUAL_CHANNELS,   
> \
> +.gamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, 
> \

The 10bit mode doesn't interpolate so it can handle non-decreasing
values just fine.

With the gamma_lut_tests part dropped this is
Reviewed-by: Ville Syrjälä 

> + },  
> \
>   .dbuf.size = 4096,  
> \
>   .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
> \
>   BIT(DBUF_S4),   
> \
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/xelpd: Enable Pipe Degamma

[Ville Syrjälä]

On Mon, Nov 29, 2021 at 06:19:52PM +0200, Jani Nikula wrote:
> On Fri, 26 Nov 2021, Uma Shankar  wrote:
> > Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
> > to incorparate the extended lut size for XE_LPD.
> >
> > v2: Added a helper for degamma lut size (Ville)
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 42fe549ef6fe..de3ded1e327a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -808,6 +808,14 @@ static void bdw_load_luts(const struct 
> > intel_crtc_state *crtc_state)
> > }
> >  }
> >  
> > +static int glk_degamma_lut_size(struct drm_i915_private *i915)
> > +{
> > +   if (DISPLAY_VER(i915) >= 13)
> > +   return 131;
> > +   else
> > +   return 35;
> > +}
> > +
> 
> Why do we have both a function with hardcoded values and device info
> members for this?

The device info stuff just needs to get nuked. The size of the LUTs
depends on the gamma mode which we already select dynamically (and
if/when we get thre new uapi ironed out it'll become even more
dynamic), so trying to represent it with a single number in device 
info is futile.

-- 
Ville Syrjälä
Intel